SPF, DKIM og DMARC er tre oppføringer i DNS som avgjør om andre kan sende e-post som ser ut til å komme fra bedriftens domene. SPF lister opp hvilke servere som får sende for domenet, DKIM gir hver e-post en digital signatur, og DMARC forteller Gmail, Outlook og andre mottakere hva de skal gjøre med e-post som ikke består kontrollen.
Innføringen er overkommelig for en bedrift med Microsoft 365 og en håndfull andre systemer, men rekkefølgen er avgjørende. Kartlegg alt som sender e-post i bedriftens navn, slå på DKIM og start DMARC i overvåkingsmodus. Stram inn først når rapportene viser at all legitim e-post består. Ellers kan fakturaer og ordrebekreftelser havne i søppelpost eller bli avvist.
Av redaksjonen i Bedriftsabonnement.no. Artikkelen bygger på IETF-standardene RFC 7208, RFC 6376 og RFC 9989, dokumentasjon fra Microsoft, avsenderkravene til Google og Yahoo, NSMs grunnprinsipper for IKT-sikkerhet og veiledning fra Digdir, Nettvett og Helse- og kommuneCERT. Alt er kontrollert 27. september 2026.
Kort fortalt
- SPF sier hvilke servere som får sende for domenet, DKIM signerer e-posten, og DMARC krever at minst én av dem samsvarer med avsenderadressen mottakeren ser.
- Gmail og Yahoo har krevd autentisering av avsendere siden februar 2024. Outlook.com har avvist e-post fra store avsendere uten godkjent oppsett siden 5. mai 2025.
- Microsoft 365 signerer ikke e-post med bedriftens eget domene før DKIM er slått på for domenet.
- Gå fra
p=nonetilp=quarantine, og vurderp=rejectførst når rapportene har vært rene over tid. - DMARC stopper forfalskning av akkurat deres domene, men ikke domener som ligner eller kontoer en angriper har tatt over.
Hva de tre oppføringene gjør
En e-post har to avsenderadresser, omtrent som et brev har én adresse på konvolutten og én i brevhodet. Serverne bruker konvoluttadressen underveis, mens mottakeren ser adressen i Fra-feltet. SPF og DKIM krever ikke at de to hører sammen. Derfor kan en svindler i prinsippet skrive daglig.leder@dittfirma.no i Fra-feltet og likevel bestå en SPF-kontroll for et helt annet domene. DMARC tetter det hullet.
SPF
Sender Policy Framework er en TXT-oppføring som lister opp IP-adresser og tjenester som får sende e-post for domenet. Den avsluttes med en regel for alt annet, vanligvis -all (avvis) eller ~all (merk som tvilsom).
DKIM
DomainKeys Identified Mail er en digital signatur. Avsendersystemet signerer e-posten med en privat nøkkel, og mottakeren henter den offentlige nøkkelen fra DNS under ._domainkey for å kontrollere at e-posten kommer fra domenet og ikke er endret. Signaturen overlever som regel videresending. Det gjør ikke SPF.
DMARC
DMARC ligger på _dmarc.dittfirma.no. En e-post består når SPF eller DKIM består og det kontrollerte domenet samsvarer med domenet i Fra-feltet. Oppføringen sier også hva mottakeren skal gjøre med e-post som feiler, og hvor rapportene skal sendes.
| Type | Navn (vert) | Eksempelverdi | Hva den gjør |
|---|---|---|---|
| TXT | @ (selve domenet) | v=spf1 include:spf.protection.outlook.com -all | SPF. Bare Microsoft 365 får sende for domenet. |
| CNAME | selector1._domainkey | selector1-dittfirma-no._domainkey.dittfirma.onmicrosoft.com | DKIM for Microsoft 365. En tilsvarende oppføring lages for selector2. |
| TXT | nyhetsbrev._domainkey | v=DKIM1; k=rsa; p=MIIBIjANBgkq… | DKIM for et eksternt system. Selektor og nøkkel kommer fra leverandøren. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@dittfirma.no | DMARC i overvåkingsmodus ber ikke om karantene eller avvisning. Mottakerne kan likevel bruke egne filtre; rua ber dem om rapporter, men de er ikke forpliktet til å sende. |
| TXT | @ og _dmarc på et ubrukt domene | v=spf1 -all og v=DMARC1; p=reject; | Sier at domenet aldri sender e-post. |
Hvorfor det haster nå
To forhold gjør saken mer presserende enn før. De store e-posttjenestene krever autentisering for å levere e-post, og forfalskede avsendere brukes i svindel mot bedrifter.
Kravene fra Google, Yahoo og Microsoft
Google og Yahoo har siden februar 2024 krevd SPF eller DKIM av alle som sender til privatkontoene deres. Store avsendere må ha både SPF og DKIM og i tillegg DMARC på minst p=none, og domenet i Fra-feltet må samsvare med SPF- eller DKIM-domenet. Hos Google blir den som sender rundt 5 000 meldinger i døgnet til Gmail-kontoer fra samme hoveddomene, varig klassifisert som masseavsender, og fra november 2025 har Google trappet opp håndhevingen med avvisninger. Microsoft stiller tilsvarende krav til domener som sender over 5 000 e-poster i døgnet til Outlook.com, Hotmail, Live.com og MSN, og har siden 5. mai 2025 avvist e-post som ikke oppfyller dem. At mottakeren har lagt avsenderen på listen over trygge avsendere, hjelper ikke.
| Mottaker | Hvem kravet gjelder | Autentisering som kreves | Gjelder fra |
|---|---|---|---|
| Gmail (privatkontoer) | Alle avsendere | SPF eller DKIM | 1. februar 2024 |
| Gmail (privatkontoer) | Rundt 5 000 meldinger eller mer per døgn fra samme hoveddomene | SPF, DKIM og DMARC (p=none holder), samsvar med SPF eller DKIM | 1. februar 2024, strengere fra november 2025 |
| Yahoo | Alle avsendere | SPF eller DKIM | Februar 2024, gradvis |
| Yahoo | Masseavsendere, uten oppgitt volumgrense | SPF, DKIM og DMARC på minst p=none, som må bestås | Februar 2024, gradvis |
| Outlook.com, Hotmail, Live.com, MSN | Domener som sender over 5 000 e-poster per døgn | SPF og DKIM må bestå, DMARC på minst p=none med samsvar | 5. mai 2025, avvisning med feilkode 550 5.7.515 |
Kravene gjelder e-post til privatkontoer, og Google presiserer at de ikke gjelder Google Workspace-kontoer. Men fakturaer, ordrebekreftelser og nyhetsbrev går også til privatpersoner med gmail.com- og hotmail.com-adresser, og grunnkravet om SPF eller DKIM gjelder uansett volum.
Hovedgrunnen er svindel
For en norsk bedrift er leveringsevne likevel ikke den viktigste grunnen. Den viktigste er at domenet ikke skal kunne brukes mot kunder, leverandører og egne ansatte. Nettvett beskriver direktørsvindel som e-post eller SMS fra noen som utgir seg for å være i ledelsen, for å få en økonomimedarbeider til å betale en faktura eller overføre penger raskt. Microsoft oppgir at SPF, DKIM og DMARC skal hindre forfalskede avsendere i nettopp slik svindel, i phishing og i løsepengeangrep.
NSM skrev i 2018 at et flertall av IKT-hendelsene de ser, starter med en forfalsket e-post. Tiltak 2.8.1 i NSMs grunnprinsipper for IKT-sikkerhet ber virksomheter bruke DMARC, DKIM, SPF og DNSSEC for å avsløre forfalskede avsendere, og Digdir har anbefalt DMARC for offentlige virksomheter siden 2018. Svindlerne bruker også telefon og SMS, som vi omtaler i artikkelen om telefonsvindel mot bedrifter.
Kartlegg alt som sender e-post i bedriftens navn
Selve DNS-oppføringen er rask å lage. Det som tar tid, er å finne alle systemene som sender e-post med bedriftens adresse. DMARC-standarden peker på at det i alt annet enn de enkleste oppsettene er lett å overse en server eller en tredjepart som sender på bedriftens vegne.
| Kilde | Typisk adresse | Dette må avklares |
|---|---|---|
| Microsoft 365 | Ansatte og fellespostbokser | At SPF har Microsofts include og at DKIM er slått på |
| Regnskaps- og fakturasystem | faktura@ | Om det sender fra egne servere, og hvilke SPF- og DKIM-oppføringer det krever |
| Nyhetsbrevverktøy | nyheter@ | DKIM for deres domene, gjerne på et underdomene |
| CRM og salgsverktøy | Selgernes adresser | Om e-posten går via Microsoft 365 eller via leverandøren |
| Nettbutikk og booking | ordre@ og booking@ | SPF og DKIM fra leverandøren |
| Kontaktskjema på nettsiden | post@ | Om skjemaet sender via webhotellet uten DKIM |
| Skanner og andre enheter | skanner@ | Om enheten sender via Microsoft 365 eller fra egen IP-adresse |
Microsoft anbefaler å legge tjenester dere ikke styrer selv, som nyhetsbrev, på et underdomene som nyheter.dittfirma.no. Problemer der går da ikke ut over domenet de ansatte bruker, og underdomenet får sin egen SPF-oppføring med egen grense for oppslag. Underdomener trenger egen SPF og DKIM, men arver DMARC fra hoveddomenet.
SPF tåler bare ti DNS-oppslag
SPF-standarden (RFC 7208) setter en grense på ti DNS-oppslag per kontroll. Mekanismene include, a, mx, ptr og exists og modifikatoren redirect teller, mens ip4, ip6 og all ikke gjør det. Går oppføringen over grensen, blir resultatet en permanent feil (permerror), og SPF feiler. Oppslagene hekter seg dessuten sammen. Microsoft forklarer at en include som peker videre til tre nye, koster fire oppslag. Noen få skytjenester kan derfor være nok til å sprenge grensen.
Hvert domene kan bare ha én SPF-oppføring, og to oppføringer som begge starter med v=spf1, gir også permerror. Det kan skje når en ny leverandør ber om en SPF-oppføring og noen lager en ny i stedet for å flette den inn i den gamle. Blir oppføringen for lang, flytt tjenester til underdomener, fjern tjenester dere ikke bruker, eller erstatt en include med faste IP-adresser for leverandører som dokumenterer stabile adresser. Det siste skal ikke gjøres for Microsoft 365, der IP-adressene ifølge Microsoft endres ofte.
Microsoft anbefaler -all når DKIM og DMARC er på plass. RFC 9989 minner om at enkelte mottakere kan avvise e-post på SPF-feil før DMARC vurderes, og at slike avvisninger ikke vises i rapportene. Et forsiktig valg er ~all under kartleggingen og -all når rapportene er rene.
Slik slår dere på DKIM i Microsoft 365
Microsoft 365 signerer automatisk e-post fra startdomenet som slutter på onmicrosoft.com, men ikke fra bedriftens eget domene før DKIM er satt opp. Uten det kan DMARC bare lene seg på SPF. Microsoft Learn beskriver fremgangsmåten slik.
- Gå til security.microsoft.com og videre til Email & collaboration, Policies & rules, Threat policies og Email authentication settings. Velg fanen DKIM.
- Velg domenet og forsøk å slå på signering. Portalen viser da verdiene for to CNAME-oppføringer.
- Opprett
selector1._domainkeyogselector2._domainkeyhos DNS-leverandøren, med verdiene nøyaktig slik portalen viser dem. - Når Microsoft har funnet oppføringene, slår dere på «Sign messages for this domain with DKIM signatures».
- Send en e-post til en ekstern konto og kontroller at feltet DKIM-Signature har
d=satt til deres domene.
Kopier alltid verdiene fra portalen. Nye domener har siden mai 2025 fått et format som slutter på dkim.mail.microsoft, mens eldre domener beholder formatet som slutter på onmicrosoft.com. Google krever DKIM-nøkler på minst 1024 bit og anbefaler 2048. I Microsoft 365 er 1024 bit standard ved oppsett med PowerShell, men nøkkelen kan byttes til 2048 bit med Rotate-DkimSigningConfig og -KeySize 2048. En rotasjon tar fire døgn. Eksterne systemer trenger egne DKIM-nøkler med egen selektor. Resten av administrasjonen står i guiden om Microsoft 365 for bedrifter.
Innfør DMARC i tre trinn
Microsoft anbefaler å gå fra p=none via p=quarantine til p=reject, og å ta hoveddomenet til slutt. RFC 9989, den nye DMARC-standarden fra mai 2026, sier at det kan ta mange måneder med rapporter før en bedrift er sikker på at all egen e-post er riktig autentisert.
| Trinn | Policy | Hva dere gjør | Gå videre når |
|---|---|---|---|
| 1. Overvåking | p=none | Leser rapportene og retter SPF og DKIM for legitime kilder | All legitim e-post består, og tidligst etter en måned |
| 2. Karantene | p=quarantine | Følger med på e-post som havner i søppelpost | Rapportene har vært rene minst like lenge |
| 3. Avvisning | p=reject | Leser rapporter, særlig når nye systemer tas i bruk | Passer ikke for alle domener, se under |
Rapportene er poenget med overvåkingsfasen
Med rua i oppføringen ber dere mottakerne sende samlerapporter. RFC 9989 anbefaler at rapporter sendes minst daglig, men mottakerne er ikke forpliktet til å sende dem. Rapportene er XML-filer med IP-adressene som har sendt e-post med domenet deres, og om de besto. Både Microsoft og Helse- og kommuneCERT anbefaler et verktøy eller en tjeneste som gjør rapportene lesbare, og Microsoft råder til å sende dem til en egen postboks eller gruppe, ikke til en enkeltperson. Microsofts veiledning viser fortsatt taggen pct, som bruker policyen på en andel av e-posten. RFC 9989 har fjernet pct fordi mottakerne sjelden fulgte den presist, og innført t=y som testflagg. Bygg derfor innføringen på tid og rapporter.
Når p=reject ikke passer
Microsoft kaller p=reject det mest effektive vernet når alle legitime kilder er på plass. RFC 9989 er mer forsiktig. Domener der vanlige brukere kan skrive til e-postlister, bør ikke ha p=reject, fordi e-post via lister og videresending kan feile DMARC. Velger man likevel p=reject, bør p=none og p=quarantine ha stått minst en måned hver, og e-posten må være DKIM-signert.
For mange mindre bedrifter kan p=quarantine derfor være et fornuftig endepunkt for hoveddomenet. Domener som aldri sender e-post, bør derimot ha v=spf1 -all og p=reject. Microsoft og Helse- og kommuneCERT anbefaler dette, og Digdir anbefaler offentlige virksomheter å markere slike domener med SPF. Brukes ikke startdomenet på onmicrosoft.com til e-post, bør det også få en DMARC-oppføring, som legges inn i administrasjonssenteret for Microsoft 365.
Få DMARC på plass uten å stoppe egen e-post
Vi hjelper bedrifter med kartlegging av avsendere, DKIM i Microsoft 365 og trinnvis innføring av DMARC gjennom etablerte IT-partnere.
Få hjelp med e-postsikkerhetenFeil som stopper legitim e-post
Microsofts feilsøkingsveiledning og standardene peker på noen feil det lønner seg å sjekke først.
- To SPF-oppføringer på samme domene, som gir permerror.
- Skrivefeil i SPF, som punktum etter domenenavnet,
include=i stedet forinclude:eller mellomrom etter kolon. - DKIM mangler for eget domene, slik at DMARC står og faller på SPF, som ofte ryker ved videresending.
- Tjenester som legger til bunntekst eller endrer innholdet underveis og dermed bryter DKIM-signaturen.
- Rapporter som går til en innboks ingen leser.
- DMARC som blir stående på
p=none. Yahoo skriver at avsendere med problemer med forfalskning uansett bør hap=quarantineellerp=reject. - Et hopp rett til
p=rejectfør et glemt fakturasystem er oppdaget. - Glemte domener, som gamle domener og .com-varianten av firmanavnet, og manglende DMARC på onmicrosoft.com-domenet.
Slik gjør dere en DMARC-sjekk
Den raskeste kontrollen er å slå opp oppføringene. Kommandoen nslookup -type=txt _dmarc.dittfirma.no viser DMARC, og samme kommando mot domenet viser SPF. Det finnes også gratis sjekkverktøy på nett. Helse- og kommuneCERT viser for eksempel til internet.nl, et initiativ fra den nederlandske Internet Standards Platform, som tester DMARC, DKIM, SPF, DNSSEC og STARTTLS.
Et godkjent resultat betyr at oppføringene er gyldige, ikke at alle systemene er dekket. Send derfor en e-post fra hvert system til en ekstern konto og se på feltet Authentication-Results i meldingshodet. Står det dmarc=pass, er kilden i orden. Den mest fullstendige sjekken er likevel rapportene over tid, fordi de også viser e-post fra systemer dere ikke visste om.
Dette beskytter de tre oppføringene ikke mot
DMARC stopper bare forfalskning av det eksakte domenet. RFC 9989 sier selv at standarden ikke dekker domener som ligner visuelt, eller misbruk av visningsnavnet i Fra-feltet. Nettvett beskriver hvordan svindlere registrerer domener med bedriftens navn og bruker .com i stedet for .no. En e-post fra dittfirma-no.com, eller med visningsnavnet «Daglig leder» over en Gmail-adresse, berøres ikke av DMARC-oppføringen deres.
Det samme gjelder en kapret konto. Har en angriper passordet til en ansatt, sendes e-posten fra deres egen Microsoft 365 og består alle tre kontrollene, fordi DMARC autentiserer domener og ikke personer. Vernet er tofaktorinnlogging, overvåking av pålogginger og en fast rutine der endringer i kontonummer bekreftes over telefon til et kjent nummer, aldri et nummer fra selve e-posten, slik også Nettvett råder. Dette hører hjemme i en helhetlig plan for IT-sikkerheten i bedriften.
Anbefalt neste steg
Begynn med tiltakene som ikke stopper noe. Lag listen over alle avsendersystemer, slå på DKIM i Microsoft 365 og publiser v=DMARC1; p=none med rapporter til en egen postboks. Legg v=spf1 -all og p=reject på domener som aldri sender e-post. Les rapportene i minst en måned før dere går til p=quarantine. Har ingen internt ansvar for DNS og Microsoft 365, er dette en naturlig oppgave i en IT-supportavtale eller hos en fast leverandør av IT-drift.
Kilder
Kontrollert 27. september 2026.
- RFC 7208, Sender Policy Framework (SPF), IETF. Grensen på ti DNS-oppslag, hvilke mekanismer som teller, og permerror ved mer enn én SPF-oppføring.
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures, IETF. Hvordan DKIM-signaturen virker, og at offentlige nøkler ligger under _domainkey i DNS.
- RFC 9989, Domain-Based Message Authentication, Reporting, and Conformance (DMARC), IETF, mai 2026. Gjeldende DMARC-standard. Start med p=none, fjerning av pct og innføring av t=y, råd om p=reject for domener med vanlige brukere og e-postlister, tidlig avvisning ved SPF -all, og at DMARC ikke dekker lignende domener, visningsnavn eller autentisering av personer.
- RFC 7489, DMARC, RFC Editor. Den opprinnelige DMARC-spesifikasjonen fra 2015, nå erstattet av RFC 9989, RFC 9990 og RFC 9991.
- Email sender guidelines, Google. Krav til alle avsendere og til avsendere av 5 000 meldinger eller mer per døgn fra 1. februar 2024, samsvarskrav og DKIM-nøkkel på minst 1024 bit med 2048 bit anbefalt.
- Email sender guidelines FAQ, Google. Definisjonen av masseavsender, telling per hoveddomene, permanent status, strengere håndheving fra november 2025 og at kravene ikke gjelder Google Workspace-kontoer.
- Sender Best Practices, Yahoo Sender Hub. Krav til alle avsendere og masseavsendere fra februar 2024.
- FAQs, Yahoo Sender Hub. At Yahoo ikke oppgir volumgrense for masseavsendere, og at avsendere med forfalskningsproblemer bør ha p=quarantine eller p=reject.
- Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders, Microsoft Tech Community. Kravene for domener med over 5 000 e-poster per døgn, avvisning fra 5. mai 2025 med 550 5.7.515, at trygge avsendere ikke unntas, anbefalt trinnvis innføring og at p=reject er mest effektivt når alle legitime kilder er på plass.
- Fix NDR error «550 5.7.515» in Outlook.com, Microsoft Support. At kravene gjelder Outlook.com, Hotmail, Live.com og MSN, og hvordan resultatet leses i meldingshodet.
- Set up SPF to identify valid email sources, Microsoft Learn. SPF for Microsoft 365, anbefalingen om -all, oppslag som teller, nestede include-er, underdomener, vanlige syntaksfeil og at Microsoft 365 ikke skal erstattes med faste IP-adresser.
- Set up DKIM to sign mail from your cloud domain, Microsoft Learn. DKIM for eget domene, fremgangsmåten i Defender-portalen, CNAME-formatet fra mai 2025, nøkkellengde og rotasjon på fire døgn.
- Set up DMARC to validate the From address domain, Microsoft Learn. DMARC-syntaks, trinnvis innføring, pct, samlerapporter, egen postboks for rapporter og oppføringer for ubrukte domener og onmicrosoft.com.
- Email authentication in Microsoft 365, Microsoft Learn. At SPF, DKIM og DMARC skal hindre forfalskede avsendere i direktørsvindel (BEC), phishing og løsepengeangrep, og at tjenester som endrer e-post underveis, kan bryte DKIM og DMARC.
- Beskytt e-post og nettleser, NSMs grunnprinsipper for IKT-sikkerhet 2.1. Tiltak 2.8.1 om DMARC, DKIM, SPF og DNSSEC.
- Sikrere epost med DMARC, NSM. NSMs vurdering fra 2018 av at et flertall av IKT-hendelser starter med forfalsket e-post.
- Grunnleggande datakommunikasjon, Digdir. Anbefalingen til offentlige virksomheter fra 1. november 2018 om DMARC med SPF eller DKIM, og SPF for domener som ikke sender e-post.
- Direktørsvindel (CEO-fraud), Nettvett. Hvordan direktørsvindel foregår, bruk av lignende domener og råd om å bekrefte betalinger på en annen kanal.
- DMARC, Helse- og kommuneCERT (Norsk helsenett). Råd om p=reject for domener som ikke sender e-post, verktøy for rapporter og internet.nl som testverktøy.
- Test your email, Internet.nl og About Internet.nl. At e-posttesten omfatter DMARC, DKIM, SPF, DNSSEC og STARTTLS, og hvem som står bak verktøyet.
Forbehold: Avsenderkravene til Google, Yahoo og Microsoft kan endres, og tjenestene håndhever dem etter egne vurderinger. DNS-eksemplene gjelder et fiktivt domene og skal ikke kopieres direkte. Bruk verdiene fra Microsoft og de andre leverandørene deres. Endringer i SPF, DKIM og DMARC påvirker e-postleveransen og bør gjøres av noen som kjenner bedriftens oppsett. Artikkelen er generell informasjon og ingen garanti mot svindel.
