Sådan læser og opsætter du en DMARC-record til B2B cold email
De fleste sælgere har hørt ordet DMARC, men få kan forklare forskellen på en DMARC record og en DMARC policy — eller hvorfor den forkerte rækkefølge kan sende hele cold email-kampagnen i spam på en formiddag. Her får du den nøgterne udgave: hvad recorden faktisk indeholder, hvordan du bruger en DMARC policy generator uden at gætte dig frem, og hvordan du når frem til DMARC policy of reject uden at miste svar fra rigtige beslutningstagere.
- En DMARC record er DNS-teksten; policyen (p=) er kun én værdi inde i den
- DMARC bygger oven på SPF og DKIM — uden dem virker DMARC email authentication ikke
- Spring aldrig direkte til p=reject uden mindst 2–4 ugers monitorering på p=none
- En DMARC policy generator forhindrer syntaksfejl, men erstatter ikke alignment-tjek
- Cold email bør sendes fra et dedikeret subdomæne, så hovedomdomænets DMARC ikke rammes
Hvad er egentlig en DMARC record og en DMARC policy?
En DMARC record er en almindelig DNS TXT-post placeret på _dmarc.dindomæne.dk. Den fortæller modtagerens mailserver, hvad den skal gøre, hvis en indkommende e-mail hævder at komme fra dit domæne, men ikke består SPF- eller DKIM-alignment. Det er selve mekanismen bag DMARC email authentication: den lukker hullet mellem 'afsenderadressen ser rigtig ud' og 'afsenderadressen er faktisk verificeret'.
Policyen er kun ét felt i recorden — tagget p=. Den kan have tre værdier: none (overvåg, men gør ikke noget), quarantine (send til spam) eller reject (afvis mailen helt). Forveksles de to begreber, ender virksomheder tit med at slå p=reject til, fordi de tror det 'bare er endnu en indstilling', uden at have set rapporterne først.
For en B2B-virksomhed som f.eks. en dansk SaaS-leverandør med et outbound-team, er konsekvensen konkret: uden DMARC kan konkurrenter eller svindlere spoofe dit domæne og sende falske fakturaer eller phishing i dit navn — hvilket i praksis skader afsenderomdømmet for al din legitime cold email, fordi modtagerens mailserver begynder at koble domænet sammen med mistænkelig trafik.
Sådan opsætter du en DMARC record trin for trin
Rækkefølgen er vigtigere end selve syntaksen. De fleste fejl opstår, fordi et team springer trin 1 og 2 over og går direkte til en stram policy.
En DMARC policy generator (der findes flere gratis online) er fin til at undgå tastefejl i rua-adressen eller pct-tagget, men den kan ikke se, hvilke af dine egne systemer der reelt sender mail på vegne af domænet. Det arbejde skal du selv gøre først.
- Kortlæg alle systemer der sender mail fra domænet: mailserver, CRM, marketingværktøj, cold email-platform, fakturasystem
- Verificér at hvert system har korrekt SPF-inkludering og en gyldig DKIM-nøgle knyttet til det domæne eller subdomæne, det sender fra
- Brug en DMARC policy generator til at bygge selve recorden, men sæt policy til p=none i første omgang
- Peg rua= på en adresse, du (eller LDM) faktisk læser rapporter fra — ellers er monitoreringen værdiløs
- Vent mindst 2–4 uger og gennemgå aggregerede rapporter, før du rører ved policyen igen
Tal er indikative, baseret på erfaring fra opsætning af DMARC på B2B cold email-domæner — ikke en formel undersøgelse.
DMARC policy of reject — sådan gør du det uden at miste svar
DMARC policy of reject er slutmålet, fordi det er den eneste policy, der reelt stopper spoofing. Men reject betyder også, at enhver mail der fejler alignment bliver kasseret uden varsel — også selvom det egentlig var en legitim mail, du bare havde glemt at godkende i SPF.
For cold email er risikoen konkret: hvis dit salgsteam sender fra hoveddomænet, og en enkelt cold email-integration mangler korrekt DKIM-signering, kan reject-policyen kassere netop de mails, du bruger flest ressourcer på at få skrevet og personaliseret. Løsningen er en trinvis rejse — ikke en genvej.
Hos LDM anbefaler vi desuden, at cold outreach altid sendes fra et separat subdomæne (f.eks. mail.dinvirksomhed.dk) med sin egen DMARC-record. Så kan hovedomdomænet gå i p=reject for at stoppe phishing, mens outreach-subdomænet kører sin egen, lidt mere forsigtige policy og varm-op-plan, uden at de to påvirker hinanden.
Indikative erfaringstal fra opsætning af DMARC på domæner brugt til målrettet B2B-outreach.
En dansk konsulentvirksomhed, Nordisk Rådgivning ApS, satte deres hoveddomæne direkte til p=reject en fredag for at 'lukke hullet hurtigt'. Mandag opdagede salgschefen, at 18 svar fra prospekter i deres aktive kampagne var blevet afvist af modtagernes mailservere, fordi et gammelt tilbudssystem manglede DKIM. Løsningen blev at rulle tilbage til p=quarantine, rette DKIM på tilbudssystemet, og først skifte til reject tre uger senere.
Typiske fejl med DMARC record ved B2B cold email
De fleste problemer skyldes ikke selve DMARC-teknologien, men rækkefølgen og manglen på opfølgning på rapporterne.
- At sætte pct=100 og p=reject samtidig, uden nogensinde at have læst en eneste aggregeret rapport
- At sende cold email fra samme domæne som transaktionsmail og interne systemer, så én fejl rammer alt på én gang
- At glemme, at forwarding (f.eks. når en prospekt videresender din mail internt) ofte bryder SPF — DKIM-alignment er derfor vigtigere at få rigtigt
- At tro en DMARC policy generator garanterer korrekt opsætning, uden selv at tjekke at SPF og DKIM allerede er på plads
- At ændre policy uden at varsle det interne salgsteam, som så ikke kan forklare pludselige svarudfald over for kunder
Sådan holder LDM DMARC og cold email adskilt — en tjekliste
Når vi sætter en ny B2B-outreach-kampagne op for en kunde, er DMARC en del af den tekniske forberedelse, ikke en eftertanke. Målet er, at domænets samlede afsenderomdømme beskyttes af en stram policy, mens selve outreach-trafikken kører isoleret og kan varmes op i sit eget tempo.
Det er ikke et spørgsmål om at 'omgå' spamfiltre — det er det modsatte: jo tydeligere DMARC email authentication viser, at afsenderen er verificeret og konsekvent, jo mindre grund har modtagerens mailserver til at behandle en velskrevet, personlig B2B-mail som støj.
- Dedikeret subdomæne til cold email, adskilt fra hoveddomænets transaktions- og interne mail
- SPF og DKIM verificeret for hvert afsendende system, før DMARC-policyen strammes
- p=none i mindst 2–4 uger med aktiv gennemgang af rapporter, derefter p=quarantine
- p=reject først når rapporterne viser 0 uforklarede fejl i to sammenhængende uger
- Løbende overvågning, så nye værktøjer (CRM-integrationer, signaturprogrammer) altid tilføjes til SPF/DKIM, før de sender mail
Ofte stillede spørgsmål
Hvad er forskellen på en DMARC policy og en DMARC record?
Recorden er hele DNS TXT-posten under _dmarc.dindomæne.dk. Policyen er kun ét tag inde i den (p=), som bestemmer om fejlende mail overvåges, sendes til spam eller afvises.
Kan jeg bruge en DMARC policy generator uden teknisk viden?
Ja, til selve syntaksen. Men generatoren kan ikke se, hvilke af dine systemer der reelt sender mail på vegne af domænet — den del af kortlægningen skal du eller din IT-partner lave manuelt først.
Hvorfor må jeg ikke starte direkte med DMARC policy of reject?
Fordi enhver legitim mail, der endnu ikke er korrekt registreret i SPF eller DKIM, bliver kasseret uden varsel. Uden en overvågningsperiode på p=none opdager du først fejlene, når svar fra vigtige prospekter simpelthen udebliver.
Kan DMARC blokere legitim cold email fra mit eget salgsteam?
Ja, hvis afsendersystemet ikke er korrekt SPF- eller DKIM-godkendt, og policyen står på reject. Det er netop derfor cold email bør sendes fra et isoleret subdomæne med sin egen, gradvist strammet policy.
Hvor tit skal jeg tjekke DMARC-rapporterne?
Mindst ugentligt i overvågningsfasen (p=none), og igen straks efter enhver ændring af policy. Når domænet er stabilt på p=reject, er en månedlig gennemgang typisk nok, medmindre I tilføjer nye afsendersystemer.
Behøver jeg et separat subdomæne til B2B cold email?
Det anbefales stærkt. Så kan hovedomdomænet køre en stram DMARC policy of reject for at stoppe spoofing, mens outreach-subdomænet varmes op og finjusteres, uden at én fejl rammer al virksomhedens mail.
Vil du bruge det her i din outreach?
Vi viser, hvordan det virker for dit segment og produkt — inden arbejdet går i gang.
Tal med os