DMARC-policy för cold email: från none till reject utan att tappa leverabilitet
En DMARC-post med p=none skyddar ingenting – den bara samlar rapporter medan spoofade mejl fortsätter fram till mottagarnas inkorgar i ditt domännamn. För B2B-team som skickar cold email är rätt dmarc quarantine policy skillnaden mellan att bygga en pålitlig avsändardomän och att bli nästa varningsflagg i mottagarens säkerhetsfilter. Den här guiden går igenom skillnaden mellan none, quarantine och reject, korrekt dmarc policy syntax och en trappstegsplan som inte spränger leveransgraden.
- p=none skyddar inte mot spoofing, det bara loggar – skannrar flaggar detta som dmarc quarantine/reject policy not enabled
- p=quarantine är den säkraste startpunkten för aktiva domäner: falska mejl hamnar i skräppost istället för inkorgen
- p=reject ska bara sättas efter minst 2–4 veckors ren rapportering utan oautentiserade legitima avsändare
- Korrekt dmarc policy syntax kräver alignment i både SPF och DKIM – inte bara ett giltigt DNS-record
- Separata sändande subdomäner för cold email gör policy-eskalering säkrare och snabbare
Varför en aktiv DMARC-policy avgör om cold email-domänen din överlever
DMARC (Domain-based Message Authentication, Reporting and Conformance) bygger vidare på SPF och DKIM men lägger till en sak de saknar: en instruktion till mottagarens server om vad som ska hända när ett mejl inte klarar autentisering i rätt domän. Utan den instruktionen – alltså utan en aktiv dmarc quarantine policy eller reject-policy – vet Gmail, Outlook och företagens egna säkerhetsfilter inte om ett spoofat mejl från din domän ska stoppas eller släppas fram.
För en B2B-avsändare som skickar riktad cold email till namngivna kontakter på specifika företag är detta extra kritiskt. Din domän är ditt varumärke i mottagarens inkorg, och en obeskyddad domän är en öppen inbjudan till spoofing – vilket i sin tur skadar avsändarens rykte hos samma mottagningsservrar du försöker nå med legitima kampanjer.
Många säkerhetsverktyg och DMARC-skannrar – till exempel de som inköpare eller IT-avdelningar kör innan de svarar på ett B2B-erbjudande – flaggar en post med enbart p=none som dmarc quarantine/reject policy not enabled. Det är i praktiken samma sak som att inte ha någon DMARC-policy alls: rapporteringen fungerar, men skyddet gör det inte.
DMARC policy syntax: så bygger du en korrekt post
En DMARC-post ligger som en TXT-post på _dmarc.dindoman.se och följer en strikt dmarc policy syntax. Grundformen är v=DMARC1; p=quarantine; rua=mailto:dmarc-rapporter@dindoman.se; pct=100; adkim=r; aspf=r. Varje tagg har en specifik funktion, och ett vanligt fel är att blanda ihop policyn för huvuddomänen med den för subdomäner.
Ett vanligt syntaxfel är att glömma semikolon mellan taggarna eller att sätta p=reject utan att pct= någonsin testats stegvis, vilket gör att hela eskaleringen sker på en gång istället för kontrollerat.
- v=DMARC1 – obligatorisk, måste stå först och exakt så
- p= – policyn för huvuddomänen: none, quarantine eller reject
- sp= – separat policy för subdomäner, annars ärver de p=
- pct= – hur stor andel av det felande mejlflödet policyn tillämpas på, bra för gradvis utrullning
- rua= – mailadress för sammanfattande dagliga rapporter (aggregate)
- ruf= – mailadress för detaljerade rapporter per mejl (forensic, används sällan idag)
- adkim= / aspf= – strikt (s) eller avslappnad (r) alignment mellan From-domänen och DKIM/SPF-domänen
None, quarantine eller reject – vad respektive nivå faktiskt gör
p=none är ett observationsläge: mottagarservern rapporterar tillbaka vad som händer men agerar inte annorlunda mot mejl som misslyckas med autentisering. Det är rätt startpunkt precis när du satt upp DMARC, men om den ligger kvar i månader är det de facto samma som dmarc policy not enabled för alla praktiska syften – domänen är fortsatt öppen för spoofing.
p=quarantine ber mottagarservern behandla misslyckade mejl med misstänksamhet, typiskt genom att skicka dem till skräppost istället för inkorgen. Det är den rekommenderade startnivån för en domän som faktiskt skickar B2B-cold email, eftersom den ger verkligt skydd utan att riskera att tappa legitim trafik permanent om något är felkonfigurerat.
p=reject instruerar mottagarservern att avvisa mejlet helt – inget skräppostfilter, inget alternativ, avsändarservern får en bounce direkt i SMTP-sessionen. Det är den starkaste nivån och slutmålet för en väletablerad avsändardomän, men den ska bara sättas efter att du är säker på att alla legitima källor (CRM, kalenderverktyg, supportsystem, LDM:s sändningsinfrastruktur) är korrekt autentiserade.
Siffrorna är riktvärden från praktisk erfarenhet av B2B-sändningsdomäner, inte en formell studie.
Trappstegsplanen: från p=none till p=reject utan att skada leveransen
Rätt dmarc quarantine policy för en cold email-domän hoppar aldrig direkt till p=reject, inte ens om domänen känns 'ren'. Rätt ordning är att låta rapporteringen (rua) samla in minst två till fyra veckors data på p=none, gå igenom varje avsändande källa som dyker upp i rapporterna och rätta SPF- och DKIM-alignment innan policyn skärps.
Nästa steg är p=quarantine; pct=25, som bara tillämpar den nya policyn på en fjärdedel av det felande flödet. Om inga legitima avsändare drabbas höjer du pct= stegvis till 50, sedan 100. Först när quarantine-nivån har kört på pct=100 utan överraskningar i minst två veckor är det dags att byta p= till reject och upprepa samma pct-trappa.
För cold email-domäner rekommenderar vi dessutom en separat sändande subdomän, till exempel mail.dindoman.se, med egen DMARC-post och egen sp=-policy. Det gör att en eventuell felkonfiguration i cold email-flödet aldrig kan påverka huvuddomänens fakturor, kundsupport eller interna mejl – och att du kan skärpa policyn på subdomänen snabbare eftersom blastradien är mindre.
Vanliga misstag med dmarc quarantine/reject policy not enabled
Det vanligaste misstaget är passivitet: DMARC-posten sätts upp en gång med p=none och glöms bort. Rapporterna samlas i en inkorg ingen läser, och domänen förblir i praktiken oskyddad i åratal – exakt det tillstånd säkerhetsverktyg flaggar som dmarc quarantine/reject policy not enabled.
- Sätta p=reject direkt utan att ha granskat rapporter – tredjepartsverktyg som fakturasystem eller nyhetsbrev slutar levereras utan förvarning
- Glömma sp= för subdomäner, vilket gör att en gammal eller övergiven subdomän ärver en policy den aldrig testats mot
- Blanda strikt alignment (adkim=s, aspf=s) med en avsändarinfrastruktur som roterar mellan flera undermängder av domännamnet
- Låta rua-rapporterna gå till en adress ingen bevakar, vilket gör att man missar när en ny legitim avsändare börjar felautentiseras
- Använda samma DMARC-post och policy för både transaktionsmejl och cold email-trafik istället för att separera dem på subdomänsnivå
Checklista: så sätter LDM DMARC-policy för cold email-domäner
När vi sätter upp sändningsdomäner för B2B-cold email följer vi samma logik som för varumärkesskydd i stort, men anpassad för domäner som ska bygga rykte snabbt utan att brännas.
- Egen sändande subdomän per kampanjtyp eller varumärke, aldrig huvuddomänen för kalla utskick
- SPF och DKIM verifierade och alignade innan någon DMARC-policy sätts högre än none
- p=quarantine som standard från dag ett på nya sändningsdomäner, inte none, eftersom domänen ändå är ny och har lågt förtroende att förlora
- rua-rapporter till en adress som faktiskt granskas veckovis under uppvärmningsfasen
- Eskalering till p=reject; pct=100 tidigast efter fyra till sex veckors ren trafik, aldrig kopplat till en kampanjdeadline
Vanliga frågor
Vad är skillnaden mellan p=quarantine och p=reject i praktiken?
Quarantine skickar mejl som misslyckas med autentisering till mottagarens skräppostmapp, medan reject stoppar dem helt redan i SMTP-sessionen. Quarantine ger ett säkerhetsnät om något är felkonfigurerat, reject ger inget sådant nät men starkast skydd.
Ska jag sätta p=reject direkt på en helt ny domän?
Nej. Börja med p=none i två till fyra veckor för att samla rapporter, gå sedan till quarantine med stegvis ökande pct=, och reservera reject för när alla legitima avsändarkällor är bekräftat korrekta.
Vad betyder det när ett verktyg flaggar dmarc quarantine/reject policy not enabled?
Det betyder att domänens DMARC-post bara har p=none, eller saknas helt, så inget faktiskt skydd mot spoofing tillämpas trots att rapportering kan vara aktiv. Åtgärden är att höja policyn till minst quarantine efter att rapporterna granskats.
Påverkar en sträng DMARC-policy min leveransgrad för legitim cold email?
Bara om din egen sändningsinfrastruktur inte är korrekt SPF/DKIM-alignad. En korrekt konfigurerad avsändardomän med p=reject levererar precis lika bra som en med p=none – policyn straffar bara mejl som inte klarar autentisering.
Behöver varje subdomän en egen DMARC-post?
Nej, subdomäner ärver huvuddomänens p= om inget annat anges, men du kan sätta en separat sp=-tagg i huvuddomänens post för att ge subdomäner en egen policynivå, till exempel strängare för en aktiv cold email-subdomän.
Hur ofta bör jag granska DMARC-rapporterna efter att reject är aktiverat?
Månadsvis räcker normalt när policyn är stabil, men varje gång du lägger till en ny avsändarkälla – ett nytt CRM, en ny mejlleverantör eller ett nytt kampanjverktyg – bör du granska rapporterna extra tätt under de första veckorna.
Vill du använda det här i din outreach?
Vi visar hur det fungerar för ditt segment och din produkt — innan arbetet börjar.
Prata med oss