Sådan beskytter SPF, DKIM og DMARC din cold email mod spamfilteret

Hvis dine cold emails til danske B2B-beslutningstagere ryger i spam, er årsagen sjældent teksten - det er ofte manglende eller forkert opsat SPF, DKIM og DMARC. Denne guide forklarer de tre DNS-records i almindeligt sprog: hvad de gør, hvordan du sætter dem op, og hvordan du tester at de virker, før du sender en eneste kampagne.

Hvorfor din afsenderadresse alene ikke er nok

Når du sender en personlig, målrettet cold email til en indkøbschef hos en dansk mellemstor virksomhed, ser modtagerens mailserver ikke din gode hensigt - den ser kun tekniske signaler. Google Workspace, Microsoft 365 og danske hostingudbydere som Simply.com eller One.com tjekker automatisk, om afsenderdomænet kan bevise sin identitet, før mailen overhovedet vises i indbakken.

De tre signaler, der afgør dette, er SPF, DKIM og DMARC - tre separate DNS-records, der tilsammen svarer på spørgsmålet: er denne mail virkelig sendt af den, den udgiver sig for at være, og er den blevet ændret undervejs? Uden dem kan selv den mest velskrevne og relevante cold email til en reel beslutningstager ende i spamfilteret, fordi domænet aldrig har bevist sin ægthed.

SPF: en liste over hvem der må sende for dit domæne

SPF (Sender Policy Framework) er en DNS TXT-record på dit domæne, der lister de servere og tjenester, som har lov til at sende mail på dine vegne. Når en modtagerserver får en mail fra f.eks. post@byggemontage.dk, slår den SPF-recorden op og tjekker, om den afsendende IP-adresse står på den godkendte liste.

Forskellen mellem ~all og -all er vigtig: ~all beder modtageren om at være mistænksom over for uautoriserede afsendere (soft fail), mens -all beder om hård afvisning. De fleste B2B-afsendere bør starte med ~all under opsætning og skifte til -all, når alle legitime afsendere er bekræftet i recorden.

DKIM: en digital signatur, der beviser at mailen er uændret

DKIM (DomainKeys Identified Mail) tilføjer en kryptografisk signatur til hver udgående mail. Din mailudbyder eller dit cold email-værktøj signerer mailen med en privat nøgle, og modtagerserveren tjekker signaturen mod den offentlige nøgle, som ligger i en DNS-record under et selector - typisk noget i stil med selector1._domainkey.dinvirksomhed.dk.

Hvis blot ét tegn i mailen ændres undervejs - hvilket kan ske via visse relæ-servere eller mellemled - fejler signaturen, og mailen mister sin DKIM-godkendelse. Det er derfor vigtigt at bruge det DKIM-selector, som netop den tjeneste du sender igennem, stiller til rådighed, og ikke blande flere afsendertjenester på samme selector.

DMARC: politikken der binder SPF og DKIM sammen

DMARC (Domain-based Message Authentication, Reporting and Conformance) er den tredje og ofte glemte record. Den fortæller modtagerserveren, hvad den skal gøre, hvis en mail fejler SPF eller DKIM - og lige så vigtigt: den kræver alignment, altså at domænet i SPF eller DKIM matcher det synlige afsenderdomæne i From-feltet.

Politikken p= har tre niveauer: none (kun overvågning, ingen håndhævelse), quarantine (fejlede mails sendes til spam) og reject (fejlede mails afvises helt). Til cold email-domæner anbefales p=none i de første 2-4 uger, mens du læser rapporterne og bekræfter at al legitim mail består - derefter skiftes til quarantine.

Hvad autentificering betyder for indbakke-placering

Forskellen mellem et domæne med korrekt SPF, DKIM og DMARC og et domæne uden er ikke kosmetisk - den er den enkeltstående faktor, der oftest afgør om en cold email-kampagne overhovedet bliver læst. Tallene nedenfor er indikative erfaringstal fra målrettede B2B-kampagner, ikke en garanti, men de viser mønsteret tydeligt.

Typiske fejl, når virksomheder sætter records op

De fleste problemer med SPF, DKIM og DMARC skyldes ikke manglende viden, men små, gentagne fejl i opsætningen.

• To SPF-records på samme domæne - kun én er tilladt, resten ignoreres eller fejler helt.
• For mange includes i SPF, så man rammer DNS-opslagsgrænsen på 10 og recorden stopper med at virke.
• DKIM-selector fra en gammel afsendertjeneste, der ikke længere bruges, mens den nye tjeneste aldrig blev tilføjet.
• DMARC sat direkte til p=reject uden at have kigget på rapporterne først - legitim mail som fakturaer eller nyhedsbreve begynder pludselig at blive afvist.
• Cold email sendt fra et hoveddomæne uden separat sending-subdomæne, så en fejl kan skade hele virksomhedens mailleverance, inklusive fakturaer og supportmails.

Sådan tester og vedligeholder du opsætningen

Før du sender en eneste cold email-kampagne, bør du gennemføre en konkret spf dkim dmarc test - ikke kun kigge på DNS-opslag, men sende en rigtig testmail til en ekstern adresse og tjekke mailheaders for at se, om SPF, DKIM og DMARC alle viser pass.

Hos LDM er dette et fast trin, før en dansk B2B-kunde begynder at sende: vi verificerer SPF, DKIM og DMARC på sending-domænet, varmer det op med stigende volumen, og følger svar- og bounce-rater i CRM'et, så autentificeringen og selve kampagnen kan vurderes hver for sig, hvis noget går galt.

• Brug et gratis online-værktøj til at verificere SPF-, DKIM- og DMARC-records, før første udsendelse.
• Send en test til en Gmail- og en Outlook-adresse og tjek headers for spf=pass, dkim=pass og dmarc=pass.
• Læs DMARC-rapporterne mindst ugentligt de første måneder for at fange uautoriserede afsendere eller fejl.
• Brug et separat sending-subdomæne til cold email, adskilt fra hoveddomænets faktura- og supportmail.
• Hæv DMARC-politikken gradvist: none, dernæst quarantine, og først til sidst reject - aldrig direkte til reject.

Ofte stillede spørgsmål