Sådan opsætter du en DMARC record, der beskytter din cold email-afsendelse

Mange B2B-virksomheder opsætter SPF og DKIM, men glemmer den record der faktisk fortæller Google og Microsoft, hvad de skal gøre med mail, der fejler – DMARC. Uden en korrekt DMARC record kan andre afsende falske mails fra dit domæne, og din egen cold email risikerer at lande i spam, selvom SPF og DKIM er sat op korrekt. Her får du konkrete DMARC record-eksempler til kopiering, en trin-for-trin guide til opsætning, og en gennemgang af hvordan du bruger et DMARC test tool til at følge fremdriften.

Hvorfor cold email fra eget domæne kræver en DMARC record

SPF og DKIM fortæller Gmail, Outlook og andre mailservere, at en besked rent teknisk er godkendt til at blive sendt fra dit domæne eller signeret med din nøgle. Men ingen af de to fortæller modtageren, hvad der skal ske, hvis en mail ikke består testen – og det er præcis det, en DMARC record gør. Uden den er det op til hver enkelt mailudbyders egne, ofte uigennemsigtige regler at afgøre, om en mail fra dit domæne er legitim.

For virksomheder der sender cold email er det særligt vigtigt, fordi I dagligt sender fra jeres domæne til fremmede indbakker hos Microsoft 365 og Google Workspace – de to udbydere der i praksis sætter standarden for, hvad der opfattes som troværdig afsendelse. En manglende eller svag DMARC record er et af de signaler, spamfiltre lægger vægt på, fordi den både øger risikoen for at nogen udgiver sig for jeres domæne i phishingmails og signalerer, at domænet ikke er fuldt vedligeholdt.

Mange danske B2B-virksomheder har SPF sat op til deres CRM eller nyhedsbrevsværktøj, men har aldrig tilføjet en DMARC record, fordi den ikke er påkrævet for at sende mail – kun for at beskytte domænet mod misbrug. Det betyder i praksis, at hvem som helst kan forsøge at sende mail, der ser ud til at komme fra jer, uden at modtageren nødvendigvis afviser den.

Sådan opsætter du en DMARC record trin for trin

Opsætningen bør altid ske i en rækkefølge, der sikrer, at du aldrig blokerer din egen legitime post, mens du strammer beskyttelsen.

• Bekræft at SPF er sat korrekt op og holder sig under grænsen på 10 DNS-opslag.
• Bekræft at DKIM-nøglen er publiceret, og at afsenderplatformen (fx dit cold email-værktøj) rent faktisk signerer med den.
• Opret en TXT-record på _dmarc.dit-domæne.dk med p=none som første skridt.
• Angiv en rua-adresse, så du modtager aggregerede rapporter dagligt.
• Overvåg rapporterne i 2-4 uger, og ret fejl i SPF- eller DKIM-alignment, du opdager undervejs.
• Hæv gradvist til p=quarantine, og brug pct= til en delvis udrulning.
• Afslut med p=reject, når rapporterne konsekvent viser 100% aligned mail.

DMARC record-eksempler til kopiering

En DMARC record er en enkelt TXT-record på _dmarc.dit-domæne.dk, og de fleste felter er valgfrie ud over v= og p=. Her er, hvad hvert felt betyder, efterfulgt af konkrete DMARC record-eksempler du kan kopiere og tilpasse til dit eget domæne.

• v=DMARC1 – identificerer recorden som DMARC, altid det første felt.
• p= – politikken for hoveddomænet: none (kun overvågning), quarantine (send til spam) eller reject (afvis helt).
• rua= – mailadresse der modtager daglige aggregerede rapporter i XML-format.
• ruf= – mailadresse der modtager forensiske rapporter om enkelte fejlende mails, bruges sjældnere.
• pct= – hvor stor en andel af den fejlende mail politikken skal gælde for, til gradvis udrulning.
• adkim= / aspf= – strict (s) eller relaxed (r) alignment mellem afsenderdomæne og SPF/DKIM-domæne.
• sp= – separat politik for underdomæner, hvis de skal afvige fra hoveddomænets.

Sådan bruger du et DMARC test tool og laver et DMARC policy lookup

Når recorden er publiceret, er næste skridt at bekræfte, at den faktisk virker, og at læse de rapporter den genererer. Et hurtigt DMARC policy lookup laves med kommandoen dig TXT _dmarc.dit-domæne.dk +short, som viser den record verden rent faktisk ser – ikke den du tror, du har gemt. Et gratis DMARC test tool online gør det samme uden terminal og validerer samtidig syntaksen, så en tastefejl i pct= eller p= ikke går ubemærket hen.

De aggregerede rapporter (rua) kommer som XML-filer fra Google, Microsoft og andre store udbydere, typisk en gang i døgnet per afsender. De færreste læser XML direkte – de fleste DMARC test tools eller dedikerede overvågningstjenester omsætter dem til en tabel, der viser, hvilke IP-adresser der sender på dit domænes vegne, og om de består SPF- og DKIM-alignment. Det er her, du opdager glemte afsendere som et gammelt marketingværktøj eller en medarbejders private mailklient, der stadig sender via domænet uden at være med i SPF-recorden.

Typiske fejl der ødelægger leverancen

De fleste DMARC-problemer opstår ikke i selve DNS-syntaksen, men i rækkefølgen og tempoet i udrulningen.

• To eller flere DMARC records på samme domæne – kun én er tilladt, ellers ignoreres den ofte af mailudbyderen.
• At hoppe direkte til p=reject uden først at have læst rapporterne og rettet alignment-fejl.
• At glemme sp= for underdomæner, så et glemt underdomæne kan sende uautoriseret mail.
• At bruge et cold email-værktøj, der ikke understøtter DKIM-signering med eget domæne.
• At sende cold email fra hoveddomænet uden opvarmning, så DMARC-skærpelsen rammer et domæne med i forvejen lavt omdømme.
• Ikke at handle på rua- og ruf-rapporter, så recorden opsættes og glemmes.

Sådan arbejder vi med DMARC hos LDM

Når vi sætter cold email op for en kunde hos LDM, adskiller vi altid selve outreach-afsendelsen fra virksomhedens hoveddomæne – typisk via et dedikeret underdomæne som send.nordiskhandel.dk. Det betyder, at en eventuel fejl i DMARC-udrulningen aldrig rammer den daglige interne mail eller kundekommunikationen på hoveddomænet.

• SPF, DKIM og DMARC verificeres, før den første cold email-kampagne sendes fra et nyt underdomæne.
• Underdomænet varmes op med stigende volumen, samtidig med at DMARC-politikken skærpes trinvist.
• Aggregerede rapporter gennemgås ugentligt i opstartsfasen, derefter månedligt.
• sp= sættes eksplicit, så uventede underdomæner ikke kan misbruges uden at blive opdaget.
• Hoveddomænets p=reject rører aldrig cold email-trafikken, fordi den ligger på et separat underdomæne.

Ofte stillede spørgsmål