DMARC-policy: none, quarantine eller reject - hva bør domenet ditt bruke?
Mange domeneeiere har publisert en DMARC-post uten å vite hvilken policy den faktisk kjører med, og dmarc policy not enabled er fortsatt normalen for de fleste virksomhetsdomener. Denne artikkelen forklarer forskjellen mellom none, quarantine og reject, og viser en trygg vei fram til dmarc policy of reject uten å skade svarraten i kalde B2B-kampanjer.
- DMARC policy avgjør hva mottakerserveren gjør med e-post som feiler SPF/DKIM-alignment - ikke om meldingen ser ut som spam
- None er overvåking, quarantine sender mistenkelig post til søppelpost, reject avviser den helt
- Start alltid med none og rua-rapporter før du strammer inn til quarantine eller reject
- Å hoppe rett til reject er den vanligste årsaken til at legitime kalde kampanjer forsvinner
- Bruk et eget avsendersubdomene for kalde B2B-utsendelser, med egen policy adskilt fra hoveddomenet
Hva DMARC policy faktisk styrer for et B2B-avsenderdomene
DMARC (Domain-based Message Authentication, Reporting and Conformance) bygger videre på SPF og DKIM, men det er policy-taggen i DMARC-posten - p=none, p=quarantine eller p=reject - som faktisk bestemmer hva mottakerens e-postserver gjør med meldinger som feiler autentisering. Mange har hørt begrepet DMARC, men har aldri sjekket hvilken policy domenet faktisk kjører med. dmarc policy not enabled dukker stadig opp som funn når man kjører en teknisk sjekk av et avsenderdomene - posten mangler helt, eller den står på none uten at noen noensinne har strammet den inn.
For en virksomhet som driver målrettet B2B-utsendelse - få e-poster per dag, til navngitte kontakter hos spesifikke selskaper - er valget av dmarc policy en balansegang. For løs policy beskytter ikke domenet mot at noen sender phishing eller falske fakturaer i firmaets navn til egne kunder og partnere. For streng policy, satt opp uten forarbeid, kan stoppe legitime meldinger - inkludert svar fra potensielle kunder som havner i søppelpost eller aldri kommer fram.
Teknisk sett publiseres DMARC-posten som en TXT-post på _dmarc.domene.no. Den inneholder policy-taggen sammen med instruksjoner om rapportering (rua), alignment-krav (adkim, aspf) og eventuelt hvor stor andel av trafikken policyen skal gjelde for (pct).
De tre DMARC-policyene: none, quarantine og reject
none er overvåkingsmodus. Ingen melding blir avvist eller flyttet til søppelpost på grunn av DMARC alene - domeneeieren mottar bare aggregerte rapporter om hvem som sender e-post i domenets navn, og om de består SPF/DKIM-alignment. Dette er riktig startpunkt for nesten alle, men problemet oppstår når none blir en permanent tilstand i stedet for en midlertidig observasjonsfase.
quarantine ber mottakerens e-postserver behandle meldinger som feiler alignment som mistenkelige, typisk ved å sende dem til spam-mappen i stedet for innboksen. Det er et mellomsteg som gir reell beskyttelse uten den harde konsekvensen av en fullstendig avvisning.
reject er den strengeste av de tre. Mottaksserveren avviser meldingen fullstendig - avsenderen får ofte en bounce tilbake, og mottakeren ser aldri meldingen. dmarc policy of reject er sluttmålet for de fleste virksomheter som vil beskytte domenet sitt mot spoofing, men den forutsetter at absolutt all legitim post - inkludert fra CRM, faktureringssystem og cold email-verktøy - er korrekt autentisert med SPF og/eller DKIM i alignment med avsenderdomenet.
- none - kun overvåking og rapportering, ingen effekt på levering
- quarantine - mistenkelig post sendes til søppelpost hos mottaker
- reject - mistenkelig post avvises fullstendig av mottakerserveren
Tallene er indikative, basert på praksis fra gjennomgang av avsenderdomener i målrettede B2B-kampanjer, ikke en offisiell undersøkelse.
Slik strammer du inn DMARC policy steg for steg
Innstrammingen bør alltid følge samme rekkefølge, uansett hvor mye selskapet haster med å beskytte domenet: none, deretter quarantine, deretter reject - med reell overvåking mellom hvert steg.
- Publiser p=none med pct=100 og aktiver rua-rapportering i minst 2-4 uker
- Identifiser alle systemer som sender e-post i domenets navn: cold email-verktøy, nyhetsbrev-ESP, CRM, faktureringssystem, support-plattform
- Sørg for at hvert system enten er inkludert i SPF-posten eller DKIM-signerer med riktig alignment mot avsenderdomenet
- Når rapportene viser 100 % pass fra alle kjente kilder over minst to påfølgende uker, gå til p=quarantine med pct=25-50 %
- Øk pct til 100 for quarantine, overvåk videre, og gå deretter til p=reject - gjerne med lav pct først dersom mottakersystemene støtter det
Et typisk DNS-oppsett midt i innstrammingen kan se slik ut: _dmarc.nordiskhandel.no TXT v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-reports@nordiskhandel.no; adkim=r; aspf=r - her står posten på quarantine for halvparten av trafikken, med avslappet alignment (r) mens man fortsatt rydder opp i tredjepartsavsendere.
Hva innstramming faktisk gjør med leveringsevnen
Frykten for at reject-policy skal ødelegge leveringsevnen er ofte overdrevet - så lenge SPF og DKIM faktisk er korrekt satt opp for alle avsenderkilder før policyen strammes inn. Problemet oppstår nesten alltid når et glemt system, som et gammelt nyhetsbrev-verktøy eller en automatisert varslingstjeneste, ikke er dekket og plutselig blir avvist eller karantenesatt sammen med resten av trafikken.
For kalde B2B-kampanjer spesifikt, hvor volumet per dag er lavt og personaliseringen høy, er det ekstra viktig at reject-policyen ikke rammer selve cold email-verktøyet. En rask sjekk av rua-rapportene før og etter hver innstramming avslører dette umiddelbart.
Indikative tall fra praksis med målrettede B2B-utsendelser - faktisk resultat avhenger av domenets alder, IP-rykte og innholdet i meldingene.
Vanlige feil med DMARC policy i kalde kampanjer
De fleste problemene med DMARC oppstår ikke i selve DNS-oppsettet, men i rekkefølgen og tempoet innstrammingen skjer i.
- Hopper rett til dmarc policy of reject uten å sjekke rua-rapporter først, og stopper dermed egne kampanjer eller partneres nyhetsbrev over natten
- Setter opp et eget subdomene for cold email uten å bekrefte at DKIM-signaturen faktisk er i alignment med det subdomenet
- Lar policyen stå på none i årevis - i praksis dmarc policy not enabled - uten noen reell beskyttelse mot at noen sender phishing i selskapets navn
- Forveksler DMARC med et spamfilter: DMARC autentiserer avsenderen, det vurderer verken innhold, tone eller om meldingen oppfattes som spam
- Setter strict alignment (adkim=s, aspf=s) før alle tredjepartsverktøy faktisk signerer med eksakt domenenavn, noe som feiler legitim post unødvendig
Sjekkliste: Slik håndterer LDM DMARC policy for kalde B2B-utsendelser
LDM anbefaler kunder å bruke et dedikert avsendersubdomene for kalde B2B-kampanjer, adskilt fra hoveddomenets transaksjons- og markedsføringspost, med sin egen DMARC policy og eget rykte å bygge opp.
- Verifiser SPF og DKIM for alle avsenderverktøy før policyen strammes inn et hakk
- Start alltid med p=none og rua-overvåking i minst 2-4 uker før neste steg
- Trapp opp til quarantine, deretter reject, med gradvis økende pct
- Bruk separate subdomener per kampanjetype for å isolere domenerykte
- Gjennomgå rua-rapportene månedlig, ikke bare ved førstegangs oppsett
- Følg markedsføringslovens krav til B2B-utsendelser, inkludert tydelig avsenderidentitet og enkel avmelding, som et selvstendig krav ved siden av selve autentiseringen
Ofte stilte spørsmål
Hva betyr dmarc policy not enabled i praksis?
Det betyr enten at domenet mangler en DMARC-post helt, eller at posten står på p=none uten at noen noensinne har strammet den inn videre. Domenet mottar da ingen reell beskyttelse mot at andre sender e-post i dets navn, selv om SPF og DKIM kan være på plass.
Bør vi gå rett til dmarc policy of reject?
Nei. Gå alltid via none og quarantine først, med minst 2-4 uker overvåking i hvert trinn, slik at alle legitime avsenderkilder er bekreftet før meldinger begynner å bli avvist.
Skader en streng DMARC policy leveringsevnen for cold email?
Ikke når SPF og DKIM er korrekt satt opp og i alignment med avsenderdomenet. Problemer oppstår nesten utelukkende når et glemt tredjepartsverktøy ikke er dekket og blir rammet sammen med resten av trafikken.
Hva er forskjellen mellom SPF, DKIM og DMARC?
SPF lister hvilke servere som har lov til å sende e-post for domenet. DKIM legger en kryptografisk signatur på meldingen. DMARC kobler de to sammen, krever alignment mot avsenderdomenet, og bestemmer via policy-taggen hva som skjer når en melding feiler.
Er DMARC lovpålagt for norske selskaper?
Nei, DMARC er ikke et eget lovkrav i Norge, men flere store postkasseleverandører krever det i praksis for pålitelig levering. Markedsføringsloven regulerer separat hvordan B2B-e-post skal identifisere avsender og tilby avmelding, uavhengig av teknisk autentisering.
Trenger vi DMARC hvis vi allerede bruker et cold email-verktøy?
Ja. Verktøyet håndterer selve utsendelsen, men DMARC-policyen eies av domenet, ikke verktøyet, og beskytter domenet også mot misbruk fra andre kilder enn den kalde kampanjen.
Vil du bruke dette i din outreach?
Vi viser hvordan det fungerer for ditt segment og produkt — før arbeidet starter.
Snakk med oss