SPF, DKIM og DMARC forklart

SPF, DKIM og DMARC gjør ikke e-post usvindelbar, men de lar mottakeren kontrollere om domenet i Fra-feltet brukes på en måte domeneeieren har godkjent. Det er viktig både for levering og for å begrense misbruk av bedriftens navn.

Den vanskelige delen er sjelden å lime inn tre DNS-poster. Først må dere finne alle systemene som sender e-post: ansattes innbokser, fakturaprogrammet, CRM, nyhetsbrev, kontaktskjema, nettbutikk, supportsystem og automatiske varsler. En oversett avsender kan slutte å levere når DMARC strammes inn.

Kort forklart

DMARC består når minst én av disse veiene virker:

1. SPF består, og SPF-domenet er på linje med domenet i Fra-feltet.
2. DKIM består, og signeringsdomenet er på linje med domenet i Fra-feltet.

Det er derfor misvisende å si at en melding må bestå både SPF og DKIM. Det er likevel klokt å konfigurere begge. Videresending kan bryte SPF, mens enkelte endringer gjort av e-postlister og sikkerhetssystemer kan bryte DKIM.

SPF godkjenner sendende systemer

SPF, Sender Policy Framework, publiseres som en TXT-post. Mottakeren sammenligner IP-adressen som leverer meldingen med reglene for domenet i SMTP-kommandoen MAIL FROM. Hvis returadressen er tom, brukes normalt domenet fra HELO eller EHLO.

Dette er en viktig presisering: SPF sjekker ikke automatisk adressen som vises ved siden av avsendernavnet i e-postprogrammet. Den synlige adressen kommer fra meldingshodets From-felt. DMARC er laget for å knytte den synlige identiteten til et SPF- eller DKIM-resultat.

En enkel, illustrerende SPF-post kan se slik ut:

v=spf1 ip4:192.0.2.10 include:mailleverandor.example -all

Eksemplet skal ikke kopieres. Bruk bare verdier leverandørene deres dokumenterer, og kontroller at en gammel leverandør ikke blir stående med tillatelse etter at avtalen er avsluttet.

Regler som gjør SPF robust

• Publiser bare én SPF-post for samme navn. Flere TXT-poster som begynner med v=spf1 gir permanent feil, ikke ekstra sikkerhet.
• Samle alle legitime avsendere i den samme posten.
• Ikke bruk +all. Det godkjenner i praksis alle avsendere.
• Hold kontroll på mekanismer som utløser DNS-oppslag. SPF-evaluering har en grense på ti slike oppslag.
• Ikke anta at include bare teller som ett oppslag. Leverandørens post kan inkludere flere nivåer under seg.
• Fjern avsendertjenester som ikke lenger brukes.

Se den separate guiden om SPF-poster og vanlige syntaksfeil og hvordan dere unngår grensen på ti SPF-oppslag før en omfattende post settes i produksjon.

SPF kan feile etter vanlig videresending fordi mottakeren ser IP-adressen til videresenderen, ikke den opprinnelige avsenderen. Dette er en grunn til at DKIM bør være en selvstendig, alignet vei til DMARC-bestått.

DKIM signerer meldingen med et domene

DKIM, DomainKeys Identified Mail, legger en kryptografisk signatur i utgående e-post. Sendesystemet bruker en privat nøkkel. Mottakeren henter den offentlige nøkkelen fra DNS og kontrollerer signaturen.

Et DKIM-oppslag bruker et selector-navn, for eksempel:

vymo2026._domainkey.dittfirma.no

Selector-navnet står i s=-feltet i DKIM-signaturen, mens signeringsdomenet står i d=. Den offentlige nøkkelen kan ligge i en TXT-post, eller leverandøren kan be dere opprette en CNAME til et navn leverandøren styrer.

DKIM viser at et system med tilgang til den private nøkkelen signerte meldingen, og at de signerte delene ikke er endret etterpå. Det er ikke kryptering. Det beviser heller ikke at innholdet er sant, eller at personen i Fra-feltet faktisk skrev meldingen.

Hver avsender må signere riktig

Det holder ikke at hovedinnboksen signerer. Kontroller hver strøm separat:

Bruk mer enn én selector når leverandøren støtter nøkkelrotasjon. Da kan en ny nøkkel publiseres og tas i bruk før den gamle fjernes. Slett først den gamle offentlige nøkkelen når meldinger signert med den ikke lenger kan være under levering eller behandling.

Les mer om DKIM-selector, nøkler og rotasjon . Private DKIM-nøkler skal aldri sendes til support eller legges i DNS.

DMARC beskytter domenet brukeren ser

DMARC, Domain-based Message Authentication, Reporting, and Conformance, vurderer domenet i det synlige From-feltet. En TXT-post publiseres på _dmarc.dittfirma.no og uttrykker hva domeneeieren ønsker at mottakere skal gjøre når meldingen ikke består DMARC.

En overvåkingspost kan se slik ut:

v=DMARC1; p=none; rua=mailto:dmarc-rapporter@dittfirma.no

De tre vanlige policyene er:

Mottakeren gjør alltid sin egen helhetsvurdering. En DMARC-policy er et sterkt signal, ikke en fjernkontroll som tvinger alle mottakere til identisk behandling.

Alignment er koblingen mange overser

En melding kan ha spf=pass og likevel feile DMARC. Det skjer hvis SPF består for et annet domene enn det brukeren ser. Det samme gjelder en gyldig DKIM-signatur fra et ikke-alignet domene.

Anta at brukeren ser faktura@dittfirma.no i Fra-feltet:

Standardinnstillingen er avslappet alignment. Da kan et underdomene og organisasjonsdomenet være på linje. Med streng alignment, angitt som aspf=s eller adkim=s, må domenene være identiske. Strengere er ikke automatisk bedre; det kan gjøre legitime underdomener unødvendig vanskelige å drifte.

En trygg innføringsplan

1. Lag et avsenderregister

Be økonomi, salg, marked, kundeservice og IT oppgi alle systemer som sender med bedriftens domene i Fra-feltet. Søk også i DNS, gamle leverandøravtaler og mottatte meldingshoder. Registrer for hver strøm:

• synlig Fra-domene
• SMTP-returdomene
• DKIM-domene og selector
• ansvarlig internt
• leverandør og avtalestatus
• hvordan en testmelding sendes

Et regneark er nok. Poenget er at dere kan forklare hver legitim kilde i DMARC-rapportene.

2. Rett SPF uten å bryte aktive avsendere

Slå sammen eventuelle duplikate SPF-poster. Kontroller leverandørenes nåværende dokumentasjon, og tell hele oppslagskjeden. Test både positive og negative tilfeller. En gammel nyhetsbrevtjeneste skal ikke godkjennes bare fordi den kanskje tas i bruk igjen.

3. Aktiver alignet DKIM overalt

Send en reell test fra hver e-poststrøm til en ekstern postkasse. Kontroller leverandørens meldingsdetaljer eller originale meldingshode. Se etter dkim=pass, riktig header.d= og riktig selector. Ikke stol på et DKIM-oppslag alene; nøkkelen kan finnes selv om sendesystemet ikke signerer.

4. Start DMARC med rapportering dere faktisk leser

Publiser p=none med en fungerende rua-adresse. Aggregerte rapporter er maskinlesbare XML-filer og bør normalt behandles av et rapportverktøy, ikke leses manuelt i innboksen. De viser blant annet kilde-IP, volum, SPF- og DKIM-resultater og alignment.

En rapportert kilde er ikke automatisk legitim bare fordi navnet ser kjent ut. Koble den til avsenderregisteret og en eier i bedriften. Undersøk ukjente kilder før dere godkjenner dem i SPF eller gir dem DKIM-oppsett.

5. Rett legitime feil før policyen strammes

Skill mellom:

• en ekte tjeneste som mangler alignment
• en gammel tjeneste som skal fjernes
• videresendt eller listebehandlet e-post
• faktisk forfalskning av domenet

Følg rapportene over en representativ periode. Månedsslutt, fakturakjøring, kampanjer og sesongbaserte utsendinger må være med. En rolig uke dekker sjelden hele avsenderbildet.

6. Gå kontrollert til enforcement

Gå først til p=quarantine når legitime strømmer består. Følg med på leveringsfeil og rapporter videre. Vurder deretter p=reject ut fra faktisk bruk, inkludert e-postlister og videresending som kan påvirke ansatte.

Eldre guider anbefaler ofte pct= for gradvis innføring. Den taggen er historisk i gjeldende DMARC-standard. RFC 9989 innførte t=y som testmodus, men kompatibilitet med mottakere må vurderes fordi eldre implementasjoner kan ignorere ukjente tagger. Den mest forutsigbare overgangen er fortsatt å bruke p=none, rette feil, prøve p=quarantine og først deretter vurdere p=reject.

Slik tester dere en melding

DNS-oppslag viser hva som er publisert. En testmelding viser hva som faktisk skjer.

1. Send fra én konkret tjeneste til en ekstern mottaker.
2. Åpne mottakerens visning av originalmelding eller meldingshode.
3. Finn Authentication-Results lagt til av mottakersystemet.
4. Kontroller SPF-resultat og returdomene.
5. Kontroller DKIM-resultat, d= og selector.
6. Kontroller at DMARC består og hvilket domene som ble evaluert.
7. Gjenta for hver avsenderstrøm.

Ikke stol på en tilfeldig Authentication-Results-linje som allerede lå i meldingen før mottak. Slike hoder kan forfalskes. Bruk resultatene mottakerens eget system viser som betrodde.

Feil som gir falsk trygghet

«SPF står til pass, da er domenet beskyttet.» Ikke nødvendigvis. SPF kan bestå for et returdomene som ikke samsvarer med synlig Fra-domene.

«DKIM-nøkkelen finnes i DNS, så DKIM virker.» Ikke nødvendigvis. Utgående meldinger må faktisk signeres, signaturen må bestå, og domenet må aligne for DMARC.

«DMARC p=none stopper spoofing.» Nei. Den gir synlighet, men uttrykker ingen quarantine- eller reject-policy.

«p=reject garanterer at falsk e-post avvises.» Nei. Mottakere bruker lokal policy og andre signaler, og forvekslingsdomener som ditt-firma.no omfattes ikke av policyen for dittfirma.no.

«Autentisering garanterer innboksen.» Nei. Omdømme, klager, volum, innhold og mottakerens filtrering teller fortsatt. Riktig autentisering er et nødvendig fundament, ikke en leveringsgaranti.

Gjeldende teknisk grunnlag

DMARC ble oppdatert i mai 2026. RFC 9989 erstatter RFC 7489 og beskriver policy, alignment og innføring. Aggregerte rapporter er skilt ut i RFC 9990 . SPF er definert i RFC 7208 , og DKIM i RFC 6376 med senere oppdateringer.

Vil dere ha profesjonelle adresser på eget domene, kan dere se Vymos e-postpakker og priser . Har dere allerede et oppsett som feiler, send domenenavnet og de offentlige testresultatene via kundeservice . Del aldri passord eller private DKIM-nøkler.