DMARC-rapporten siger fail — hvad det betyder, og hvad du gør

Kort svar: “Fail” i en DMARC-rapport betyder, at en mail med dit domæne som afsender hverken bestod SPF eller DKIM med et domæne, der matcher afsenderadressen. Det er ikke i sig selv et problem: oftest er det en tjeneste, du selv bruger, som mangler opsætning, videresendt post eller spam, der misbruger dit navn og allerede bliver stoppet. Grupper rapporterne efter afsender, ret de legitime tjenester med SPF, DKIM og brandet afsendelse, og stram derefter politikken trinvis.

Fagligt gennemgået: 2. oktober 2026

Formålet med at starte på p=none er netop at se, hvem der sender i dit navn, før du begynder at afvise. Rapporterne er dit overblik over alle systemer, der bruger domænet – også dem, ingen huskede.

Denne guide forklarer, hvordan du læser rapporten, hvad de typiske fund betyder, og hvordan du kommer sikkert fra observation til afvisning.

Før du ændrer noget: Skift ikke politikken til p=quarantine eller p=reject, før du kender alle legitime afsendere. Notér den nuværende DMARC-, SPF- og DKIM-opsætning, så du kan rulle en ændring tilbage, hvis legitime mails begynder at forsvinde.

Sådan hænger DMARC sammen

DMARC bygger på to andre kontroller. SPF fortæller, hvilke servere der må sende for domænet. DKIM lægger en kryptografisk signatur på mailen. DMARC kræver, at mindst én af dem består og passer med domænet i afsenderadressen (From), som modtageren ser. Det sidste hedder alignment.

En typisk DMARC-record ligger som en TXT-post på _dmarc.dinside.dk:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r

rua= er adressen, der modtager de samlede rapporter. adkim=r og aspf=r betyder afslappet alignment, hvor et underdomæne som mail.dinside.dk godkendes for dinside.dk. Grundopsætningen står i SPF, DKIM og DMARC forklaret for virksomheder.

1. Læs rapporten rigtigt

Rapporterne er XML og svære at læse i hånden. Brug en tjeneste, der viser dem som en tabel. Et enkelt udsnit ser sådan ud:

<row>
  <source_ip>203.0.113.25</source_ip>
  <count>42</count>
  <policy_evaluated>
    <disposition>none</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>

Det, du skal kigge efter, er:

• Afsender-IP – hvem sendte? Slå IP-adressen op, så du kan se, hvilken tjeneste den tilhører.
• Antal – 42 mails fra én IP er et system; én enkelt mail fra en ukendt IP er typisk spam.
• SPF-resultat – er den server nævnt i din SPF-post?
• DKIM-resultat – var beskeden signeret, og med hvilket domæne?
• Alignment – passer domænet i afsenderadressen med det, der blev godkendt?
• Disposition – hvad gjorde modtageren: none, quarantine eller reject.

2. Placér hver afsender i en kasse

Når rapporten er læst, ender langt de fleste “fail” i en af fem kasser, og hver har sin løsning.

Kombination	Typisk årsag	Hvad du gør
Kendt afsender, SPF fail, DKIM fail	En tjeneste, du selv bruger, er ikke sat op	Tilføj tjenesten i SPF, og aktivér DKIM hos tjenesten
SPF pass, DKIM pass, alignment fail	Tjenesten sender med sit eget domæne	Slå brandet afsendelse (custom domain) til hos tjenesten
SPF fail, DKIM pass med alignment	Videresendt post	Intet – DMARC består, når én af dem består med alignment
Ukendt IP, begge fail, få mails	Spam, der misbruger dit domæne	Stram politikken, når de legitime afsendere er på plads
Din egen webserver, begge fail	WordPress eller webshop sender med PHP mail	Send via SMTP fra en rigtig postkasse

1. Kendt afsender, begge fail: et nyhedsbrevssystem, et CRM eller et fakturasystem sender i dit navn uden at være sat op. Tilføj dens include i SPF, og aktivér DKIM i tjenestens indstillinger – den beder dig typisk oprette 1–3 CNAME-poster.

2. Alignment fail: tjenesten sender med sit eget domæne i Return-Path eller DKIM-signaturen. SPF og DKIM består, men ikke for dit domæne. Løsningen hedder “custom domain”, “domain authentication” eller “brandet afsendelse” hos tjenesten.

3. Videresendelse: SPF fejler næsten altid, når en mail videresendes, fordi den sendes videre fra en anden server. Derfor er DKIM vigtig: signaturen overlever normalt videresendelsen. Nogle udbydere bruger desuden ARC til at bevare godkendelsen gennem videresendelse og mailinglister.

4. Misbrug: ukendte IP-adresser, få mails, begge fail. Det er spam med dit domæne som afsender, og det er her, p=reject får værdi. Se spoofing og DMARC-stramning.

5. Din egen webserver: WordPress eller en webshop sender med PHP mail direkte fra webserveren. Sæt SMTP op på en rigtig postkasse – se mails fra WordPress i spam.

3. Pas på SPF-grænsen på ti opslag

Hver gang du tilføjer en tjeneste med include:, tæller den – og de includes, tjenesten selv indeholder, tæller med. SPF tillader højst ti DNS-opslag i alt. Bliver der flere, giver posten “permerror”, og så fejler SPF for alle afsendere, også dem, der var i orden i går.

Det er en klassisk grund til, at DMARC-rapporter pludselig bliver røde, efter man har tilføjet et nyt værktøj. Tjek antallet med et SPF-værktøj, fjern tjenester, I ikke bruger længere, og erstat includes med IP-adresser, hvor tjenesten oplyser faste adresser. De store mailplatforme bruger selv flere opslag gennem deres includes, så pladsen er mindre, end den ser ud. Den detaljerede fremgangsmåde står i SPF-fejlen “too many DNS lookups”.

Der må kun være én SPF-post på domænet. To TXT-poster, der begge starter med v=spf1, giver også permerror.

4. Tjek DKIM for hver afsender

DKIM sættes op pr. tjeneste. Hver tjeneste har sin egen selector, og den offentlige nøgle ligger i DNS på selector._domainkey.dinside.dk. Du kan kontrollere, at nøglen findes:

dig TXT selector1._domainkey.dinside.dk +short
dig TXT _dmarc.dinside.dk +short

Brug 2048-bit nøgler, hvor tjenesten tilbyder det. Får du en testmail fra tjenesten, så åbn den fulde header og find linjen Authentication-Results. Der står dkim=pass og hvilket domæne (header.d=) der signerede. Er det tjenestens domæne og ikke dit, er det alignment, der mangler.

5. Stram op i en realistisk tidsplan

Få alle legitime afsendere med i SPF, og slå DKIM til for dem. Når rapporterne er rene i et par uger, kan du gå videre:

v=DMARC1; p=none;       → observér
v=DMARC1; p=quarantine; → læg i spam
v=DMARC1; p=reject;     → afvis helt

Spring ikke direkte til p=reject. Så begynder legitime mails at forsvinde, og det opdager man typisk først, når en kunde ikke har fået sin faktura.

• Uge 1–2: p=none med rua= til en rapporttjeneste. Saml en liste over alle afsendere – der er næsten altid to-tre, ingen huskede.
• Uge 3–4: sæt SPF og DKIM op for hver legitim afsender, og slå brandet afsendelse til, hvor alignment fejler. Målet er, at praktisk taget al legitim post består.
• Uge 5–6: p=quarantine; t=y. Flaget t=y markerer, at politikken er i test: modtagere, der følger den nye standard, behandler quarantine som none og reject som quarantine. Du ser altså konsekvensen i rapporterne, før mails rammes for alvor. Fjern flaget, når rapporterne fortsat er rene.
• Uge 7+: p=reject, først med t=y og derefter uden. Behold rapporterne – nye tjenester kommer til, og de skal ind i SPF, før de sender.

Den nye DMARC-standard (RFC 9989 fra maj 2026) har fjernet det gamle pct=, som blev brugt til at håndhæve politikken på en procentdel af mailene, fordi modtagerne håndterede det forskelligt. Ikke alle modtagere følger den nye standard endnu, så i en overgangsperiode kan det give mening at bruge både pct= og t=y, fx p=quarantine; pct=25; t=y. Ældre modtagere læser pct=, nyere læser t=y. Lad være med at regne med, at et gammelt pct= alene beskytter dig mod at ramme legitim post.

Underdomæner

Politikken gælder som udgangspunkt også underdomæner. Vil du have en anden regel for dem, bruges sp=. Den nye standard har desuden np= til underdomæner, der slet ikke findes – en oplagt plads til reject, fordi ingen legitim post kommer derfra.

Hvis rapporterne ikke kommer

• Kontrollér, at rua= står korrekt med mailto: foran adressen.
• Sendes rapporterne til en adresse på et andet domæne, skal det domæne give tilladelse med en TXT-post som dinside.dk._report._dmarc.rapportdomæne.dk. Rapporttjenester opretter den normalt selv.
• Rapporterne kommer typisk én gang i døgnet fra hver modtager. Giv det et par dage.
• Har domænet næsten ingen udgående post, kommer der tilsvarende få rapporter.

Gør DMARC til en del af driften

Gør det til en del af rutinen, når et system skiftes ud: en ny fakturaplatform eller et nyt bookingsystem skal i SPF og have DKIM, før den første mail sendes – ikke når kunderne begynder at spørge, hvor fakturaen blev af.

Google og Yahoo har siden februar 2024 krævet SPF, DKIM og en DMARC-post af afsendere, der sender mere end omkring 5.000 mails om dagen til deres brugere, og Microsoft har stillet lignende krav til Outlook.com siden maj 2025. Også mindre afsendere uden DMARC risikerer at blive behandlet hårdere i spamfiltrene. Se Gmail afviser din mail, hvis afvisningerne allerede er begyndt.

Mail hosting hos Hostious har spam- og virusfilter og ubegrænset antal postkasser, og dansk support kan hjælpe med at få SPF, DKIM og DMARC sat rigtigt op for dit domæne.

Læs også

• Hub: Mail: fejl og fejlfinding – alle guides om emnet samlet ét sted
• SPF, DKIM og DMARC forklaret for virksomheder
• SPF-fejlen “too many DNS lookups”
• Nogen sender mails fra dit domæne: spoofing og DMARC-stramning
• Mails fra WordPress ryger i spam
• Mail hosting hos Hostious – erhvervsmail uden begrænsning på antal postkasser

Ofte stillede spørgsmål om DMARC fail

Skal jeg reagere på hver eneste fail?

Nej. Kig efter mønstre. Enkeltstående fejl fra ukendte IP-adresser er ofte spam, der bliver stoppet – det er systemet, der virker.

Hvor sender jeg rapporterne hen?

Til en adresse, nogen faktisk læser – eller til en tjeneste, der samler dem. En ubrugt postkasse gør DMARC til pynt.

Hvorfor fejler SPF pludselig for alle afsendere?

Sandsynligvis fordi SPF-posten overskrider grænsen på ti DNS-opslag efter en ny include. Resultatet er permerror, som får alle afsendere til at fejle. Tæl opslagene med et SPF-værktøj, fjern ubrugte tjenester, og brug IP-adresser i stedet for includes, hvor det er muligt.

Hvad betyder alignment i DMARC?

At domænet i afsenderadressen (From) skal matche det domæne, SPF eller DKIM godkendte. Sender en tjeneste med sit eget domæne i signaturen, består SPF og DKIM måske, men alignment fejler. Løsningen er brandet afsendelse med dit eget domæne hos tjenesten.

Kan jeg stadig bruge pct= til en gradvis udrulning?

Den nye DMARC-standard fra maj 2026 har fjernet pct= og indført t=y, som får modtagerne til at håndhæve politikken et trin mildere. Da ikke alle modtagere følger standarden endnu, kan du i en periode bruge begge og fjerne dem, når rapporterne er rene.