Fejlen "DMARC verification failed": trin-for-trin fejlfinding for B2B cold email

Når en modtagerserver returnerer "dmarc verification failed", er det sjældent en tilfældighed – det er et konkret tegn på, at SPF eller DKIM ikke matcher det domæne, mails afsendes fra. For B2B cold email er konsekvensen direkte: dårligere placering i indbakken, lavere open rate og i værste fald hård bounce. Denne guide viser, hvordan du laver et dmarc verification check trin for trin og retter de mest almindelige årsager, før de skader dit afsenderdomæne.

Hvad betyder "DMARC verification failed" – og hvorfor rammer det cold email hårdest

DMARC (Domain-based Message Authentication, Reporting and Conformance) tjekker ikke selv, om en mail er ægte. Den bruger to eksisterende mekanismer – SPF og DKIM – og kræver, at mindst én af dem både passerer og er "aligned" med domænet i From-headeren, altså det domæne modtageren rent faktisk ser i indbakken. Når en modtagerserver svarer med dmarc verification failed, betyder det typisk, at SPF godkendte afsenderserveren, men på et andet domæne end From-headeren, eller at DKIM-signaturen slet ikke matchede eller manglede.

Cold email er særligt udsat, fordi mange afsendere bruger dedikerede sende-domæner, sub-domæner eller tredjepartsplatforme til at holde hoveddomænet rent. Det er en god strategi – men kun hvis SPF og DKIM konfigureres korrekt for hvert enkelt afsenderdomæne. Glemmer man en DNS-post på et nyt sub-domæne, opdager man det først, når leveringsraten pludselig falder, eller når Gmail og Outlook begynder at markere kampagnen som spam.

Sådan laver du et dmarc verification check trin for trin

Et grundigt dmarc verification check kræver mere end at slå en enkelt DNS-post op. Følg denne rækkefølge, hver gang du sætter et nyt afsenderdomæne op eller fejlfinder et eksisterende:

• Slå DMARC-posten op med dig kommando: dig TXT _dmarc.dit-domæne.dk – bekræft at der overhovedet findes en post, og læs policy-værdien (p=none, p=quarantine eller p=reject).
• Tjek SPF-posten (dig TXT dit-domæne.dk) og optæl DNS-lookups – SPF fejler automatisk, hvis der er mere end 10 lookups i kæden.
• Bekræft DKIM-selectoren fra din sending-platform er publiceret korrekt: dig TXT selector._domainkey.dit-domæne.dk.
• Send en dmarc test mail til en mailboks, du selv kontrollerer, og læs de rå headers – kig efter Authentication-Results med spf=pass, dkim=pass og dmarc=pass.
• Brug et dmarc check online-værktøj til at validere resultatet uafhængigt af din egen mailserver, så du udelukker lokale fejl.
• Kontrollér, at From-domænet i afsendte mails matcher det domæne, SPF/DKIM er sat op for – ikke et andet, lignende domæne.

Hvor kommer fejlen typisk fra i praksis

I daglig fejlfinding på B2B cold email-domæner går årsagerne igen i et forholdsvis fast mønster. Manglende eller forkert DKIM-signering står for langt de fleste tilfælde – ofte fordi et cold email-værktøj sender via egen infrastruktur uden at signere med kundens domæne, eller fordi selectoren aldrig blev publiceret i DNS efter opsætning.

Herefter kommer alignment-problemer: SPF passerer teknisk, men på envelope-from-domænet (f.eks. et bounce-domæne fra sending-værktøjet) i stedet for det synlige From-domæne. Det er en klassisk fælde, fordi alt ser fint ud, indtil man specifikt tjekker alignment.

Typiske fejl der udløser DMARC verification failed

De fleste fejl skyldes ikke mangel på viden om DMARC, men detaljer der overses under opsætning eller ved skift af sending-værktøj.

• At antage, at én DMARC-post på hoveddomænet automatisk dækker alle sub-domæner brugt til cold email.
• At skifte cold email-platform uden at opdatere DKIM-selectoren i DNS – gammel selector bliver stående og skaber forvirring.
• At bruge samme From-adresse fra flere forskellige sending-værktøjer samtidig uden at hvert værktøj har sin egen SPF/DKIM-opsætning.
• At sætte p=reject i DMARC-posten, før man har bekræftet, at alle legitime afsenderkilder passerer alignment konsekvent.
• At forveksle en dmarc test online, der kun tjekker DNS-syntaks, med en reel afsendelsestest der viser faktisk alignment.
• At ignorere RUA-rapporter, fordi de er svære at læse i rå XML-format, og dermed overse et gentaget fejlmønster over uger.

Tjekliste: fra fejl til fast leveringsevne

Når du har identificeret årsagen, følg en fast rækkefølge for at rette den uden at skabe nye problemer undervejs.

• Ret DKIM-signeringen først – det er den mest robuste alignment-mekanisme, fordi den overlever videresendelse i modsætning til SPF.
• Publicér DKIM-selectoren korrekt i DNS, og bekræft med et nyt dmarc email check, at dkim=pass vises i mail-headers.
• Ret SPF-alignment ved at sikre, at envelope-from-domænet matcher (eller er sub-domæne af) From-domænet, ikke sending-værktøjets eget domæne.
• Behold DMARC-policy på p=none i mindst 1-2 uger efter en rettelse, mens du overvåger RUA-rapporter for konsekvent pass.
• Hæv først policy til p=quarantine, og senere p=reject, når rapporterne viser stabilt pass fra alle legitime kilder.
• Genkør en dmarc test mail til flere modtagerdomæner (Gmail, Outlook, en lokal dansk udbyder) for at bekræfte, at alignment holder på tværs af platforme.

Sådan håndterer vi DMARC-fejlfinding hos LDM

Hos LDM sætter vi aldrig et nyt afsenderdomæne op til cold email uden at bekræfte SPF, DKIM og DMARC-alignment separat for det pågældende domæne – aldrig kun for hoveddomænet. Hvert kampagnedomæne får sin egen kontrolleret opvarmning, og vi overvåger RUA-rapporterne løbende i stedet for kun at reagere, når leveringsraten allerede er faldet.

Princippet er det samme, uanset værktøj: DMARC skal beskytte domænets omdømme, ikke bruges som en genvej til at "omgå spamfiltre". En mail, der reelt kommer fra en legitim afsender med korrekt alignment, ser aldrig ud som spam for modtagerserveren – og det er hele pointen med at fejlfinde disse fejl grundigt frem for at slukke symptomer.

Ofte stillede spørgsmål