Slik verifiserer du at SPF, DKIM og DMARC faktisk fungerer
Å publisere SPF-, DKIM- og DMARC-poster i DNS er bare halve jobben – det garanterer ikke at postkasseleverandøren faktisk stoler på domenet ditt. Mange norske selskaper oppdager først at en DKIM-selector mangler eller at DMARC-posten er feil formatert etter at en cold email-kampanje har havnet i spam. Denne artikkelen viser hvordan du gjennomfører en reell spf dkim dmarc test før du sender én eneste e-post til en potensiell kunde.
- En riktig satt opp post i DNS er ikke det samme som en fungerende autentisering – test alltid mot ekte innboks
- Microsoft 365 krever manuell aktivering av DKIM per domene, noe mange norske selskaper glemmer
- En dmarc generator m365 reduserer syntaksfeil, men erstatter ikke overvåking av rapportene
- Test i minst 5–7 dager med p=none før du strammer inn DMARC-policyen
- Kjør en email spf dkim dmarc test hver gang du legger til en ny avsenderplattform eller ESP
Hvorfor testing er nødvendig – ikke bare oppsett
For B2B cold email med lave daglige volumer og høy grad av personalisering er domenets rykte skjørt. Én feilkonfigurert autentiseringspost er nok til at Outlook eller Gmail begynner å sortere selv velskrevne, relevante e-poster som spam. Fordi cold email sendes til mottakere som ikke har bedt om kontakten fra før, får leverandørene ekstra grunn til å granske avsenderen nøye – da må tekniske signaler stemme.
Mange norske virksomheter bruker Microsoft 365 eller Google Workspace som e-postplattform, og legger deretter til en tredjeparts utsendelsestjeneste for kampanjer. Det skaper flere avsenderkilder for samme domene, og dermed flere steder testen kan avdekke feil: SPF-posten som mangler et include, DKIM-selectoren som aldri ble publisert, eller DMARC-posten som peker til en feil rapport-e-post.
En spf dkim dmarc test er derfor ikke en engangsjobb ved lansering, men noe du kjører hver gang oppsettet endres – nytt domene, ny ESP, nytt subdomene for kampanjer.
Test SPF: verifiser hvem som får sende for domenet
Start med å slå opp TXT-posten for domenet med et DNS-verktøy (dig, nslookup eller et nettbasert oppslag). Se etter at det kun finnes én SPF-post – to separate 'v=spf1'-poster på samme domene gjør autentiseringen ugyldig, en av de vanligste feilene ved spf dkim dmarc testen.
Sjekk deretter at alle avsenderkilder er inkludert: M365 bruker vanligvis include:spf.protection.outlook.com, Google Workspace bruker include:_spf.google.com, og eventuell kampanjeplattform legger til sitt eget include. Husk at SPF har en grense på 10 DNS-oppslag – for mange nøstede includes gjør at posten feiler stille (permerror) uten noen tydelig varsel.
Send så en reell test-e-post til en konto du kontrollerer (Gmail eller Outlook), åpne e-postens fullstendige header ('Vis original' i Gmail), og se etter linjen 'spf=pass' i Authentication-Results. Det er den eneste måten å vite at posten faktisk virker fra avsenderens infrastruktur – ikke bare at DNS-oppslaget ser riktig ut.
Test DKIM: verifiser signaturen ende-til-ende
DKIM signerer selve e-postinnholdet, så testen må bekrefte at signaturen både finnes og validerer korrekt hos mottaker. Slå opp selectoren i DNS (for eksempel selector1._domainkey.dittfirma.no for M365) og bekreft at den returnerer en gyldig offentlig nøkkel.
Den vanligste fellen for norske selskaper på Microsoft 365: DKIM er ikke aktivert som standard. Du må selv publisere to CNAME-poster og aktivere signering i Microsoft 365 Defender – uten dette steget sender domenet uten DKIM selv om SPF ser fint ut.
Bekreft resultatet i samme header du brukte for SPF: se etter 'dkim=pass' og at domenet i 'd='-taggen matcher avsenderdomenet ditt (ikke ESP-ens eget domene). Gjør denne kontrollen for hver avsenderplattform du bruker – hovedkontoen og kampanjeplattformen kan ha ulike selectorer.
Test DMARC: policy, alignment og rapporter
DMARC-posten ligger på _dmarc.dittfirma.no og bestemmer hva som skjer når SPF eller DKIM ikke stemmer med avsenderdomenet (alignment). Start alltid med p=none slik at du samler data uten å risikere at legitim e-post avvises mens du fortsatt tester.
Fordi syntaksen er streng og lite tilgivende for skrivefeil, er en dmarc generator m365 et fornuftig hjelpemiddel for å bygge posten riktig første gang – spesielt rua-adressen for aggregerte rapporter og riktig pct-verdi. Generatoren erstatter derimot ikke jobben med faktisk å lese rapportene som kommer inn.
Etter noen dager mottar du XML-rapporter fra store postkasseleverandører som viser hvilke kilder som sender på vegne av domenet, og om de består alignment. Et verktøy som leser disse rapportene lesbart (for eksempel dmarcian eller et lignende dashbord) gjør det mulig å oppdage uautoriserte avsendere før du strammer inn policyen til quarantine eller reject.
Eksempel på en fungerende DMARC-post i testfasen: v=DMARC1; p=none; rua=mailto:dmarc-rapporter@dittfirma.no; pct=100; aspf=r; adkim=r – merk at p=none betyr overvåking uten håndheving, og at rua-adressen må være en postkasse du faktisk leser.
Referanseverdier: hva kjennetegner et sunt oppsett
Når du kjører en email spf dkim dmarc test på et modent, riktig konfigurert domene, bør nesten alle utgående e-poster bestå alle tre sjekkene. Under er indikative andeler fra praksis med B2B cold email-kampanjer, gruppert etter hvor komplett autentiseringsoppsettet er.
Tallene viser hvorfor et ufullstendig oppsett straffer seg mer enn proporsjonalt: å legge til DKIM etter SPF gir et stort hopp i innboks-plassering, og DMARC-alignment på toppen gir den siste, avgjørende tilliten hos postkasseleverandøren.
Tallene er indikative erfaringsverdier fra målrettede B2B-kampanjer, ikke garanterte resultater for ethvert domene eller enhver postkasseleverandør.
Vanlige feil som testen avdekker
De fleste feilene som ødelegger leveringsdyktigheten for cold email er små og lette å overse i selve DNS-postene, men de blir tydelige så snart du faktisk tester mot en ekte innboks.
- To separate SPF-poster på samme domene i stedet for én sammenslått post
- For mange nøstede DNS-oppslag i SPF, over grensen på 10
- DKIM aldri aktivert i Microsoft 365-administrasjonen selv om CNAME-postene er publisert
- DMARC satt til p=reject dag én, uten en periode med p=none for overvåking først
- Videresending av e-post internt som bryter SPF-alignment fordi DKIM ikke er konfigurert for å tåle det
- Kampanjeplattformen bruker et helt annet avsenderdomene enn hoveddomenet, uten egen autentisering
Sjekkliste før du starter en cold email-kampanje
Før en kampanje går ut til nye B2B-mottakere, bør oppsettet være verifisert på nytt – ikke antatt å fortsatt være riktig fra sist gang.
Hos LDM kjøres denne kontrollen som fast rutine før hver kampanjeoppstart: vi sender testmeldinger til flere store postkasseleverandører, leser autentiseringsheaderne manuelt, og følger DMARC-rapportene i minst en uke før volumet trappes opp. Det er en enkel, billig kontroll sammenlignet med kostnaden ved at et helt domene mister avsenderrykte.
- Kjør dig/nslookup mot SPF-, DKIM- og DMARC-postene og bekreft at kun én post finnes per type
- Send testmeldinger til Gmail og Outlook og sjekk 'spf=pass', 'dkim=pass', 'dmarc=pass' i headeren
- Bekreft at DKIM-domenet i d=-taggen matcher avsenderdomenet, ikke ESP-ens domene
- Behold p=none i minst 5–7 dager og les de innkommende DMARC-rapportene før du strammer inn
- Gjenta testen ved hver endring: nytt subdomene, ny kampanjeplattform, ny ESP-integrasjon
Ofte stilte spørsmål
Hvor lenge bør jeg teste før jeg starter en kampanje for fullt?
Sett DMARC til p=none og la det stå i minst 5–7 dager mens du leser de innkommende rapportene. Det gir tid til å oppdage avvik uten å risikere at legitim e-post avvises av mottakere.
Er SPF alene nok for en spf dkim dmarc test?
Nei. SPF alene bekrefter kun at avsenderserveren er godkjent, ikke at innholdet ikke er endret underveis. DKIM og DMARC-alignment sammen gir langt høyere tillit hos postkasseleverandøren, som vist i tallene over.
Hva er forskjellen på å bruke en dmarc generator m365 og å skrive posten selv?
En generator hjelper deg unngå syntaksfeil i selve DNS-posten og foreslår riktige verdier for rua og pct. Den erstatter derimot ikke jobben med å faktisk lese rapportene som kommer inn etterpå og justere policyen basert på dem.
Kan jeg teste uten å sende e-post til reelle kunder?
Ja. Send testmeldinger til postkasser du selv kontrollerer hos flere store leverandører (Gmail, Outlook), og les headerne der. Det gir samme informasjon som en reell utsendelse, uten å risikere kunderelasjonen.
Hva skjer hvis autentiseringen feiler midt i en kampanje?
Postkasseleverandøren begynner å sortere e-postene til spam eller avviser dem helt, og domenets rykte kan ta uker å gjenopprette. Derfor er det billigere å teste på forhånd enn å feilsøke midt i en aktiv utsendelse.
Må jeg sette DMARC til p=reject?
Ikke fra starten. De fleste B2B-avsendere trapper opp gradvis: p=none for overvåking, deretter p=quarantine når rapportene viser at alle legitime kilder består alignment, og til slutt p=reject om ønskelig.
Vil du bruke dette i din outreach?
Vi viser hvordan det fungerer for ditt segment og produkt — før arbeidet starter.
Snakk med oss