arc=fail i dine DMARC-rapporter
arc=fail opstår hos den, der videresender mailen — ikke hos dig. Her er hvad ARC gør, hvorfor kæden brækker, og hvad du som afsender faktisk kan rette.
Når du ser:
arc=fail
så betyder det, at en videresendende server (fx mailingliste, auto-forward, antivirus-gateway, journaling-hop osv.) ikke har kunnet validere ARC-kæden.
ARC bruges til at bevare autentificeringsresultater gennem forwarding og består af AAR, AMS og ARC-Seal. Hvis en af disse dele ikke kan valideres, får du arc=fail.
Dette stemmer overens med den dokumenterede funktion: ARC bevarer authentication, men mislykkes hvis forwarding ændrer mailen eller kæden ikke er korrekt signeret.
Forwarding kan ødelægge SPF og DKIM, og ARC skal så redde kæden – hvis det mislykkes, giver det fejl. trndigital.com github.com
Men det vigtige er:
ARC evalueres af modtagerens server, ikke af din server som afsender.
❌ Så hvad kan DU som afsender ikke gøre noget ved?
Du kan ikke rette:
- Hvis en ekstern videresender ændrer mailens content og brækker DKIM
- Hvis deres server ikke understøtter ARC
- Hvis forwarding-serveren har forkert konfiguration
- Hvis deres ARC-seal er udløbet, forkert signeret eller mangler
- Hvis modtagerens mailserver ignorerer ARC, accepterer eller afviser det
Alt dette er dokumenteret i den tekniske forklaring på forwarding-problemer og hvordan ARC forsøger – men ikke altid kan – at bevare autentificering. github.com
Med andre ord: ARC er et forwarding-problem, ikke et afsenderproblem.
✅ Hvad kan DU faktisk gøre noget ved?
Selvom du ikke kan kontrollere ARC-fail direkte, kan du sikre at din ende er fuldstændig korrekt, så ARC-kæden får et stabilt udgangspunkt.
Du kan:
1️⃣ Sikre at DKIM-signaturen er stabil og stærk
- Brug 2048-bit nøgler
- Brug moderne DKIM-canonicalization, fx
relaxed/relaxed
(Dette understøttes af email-autentifikationsprincipperne fra Microsoft Learn) techcommun...rosoft.com
Hvorfor hjælper det?
Hvis forwarding kun ændrer få headers, men ikke brækker DKIM, er ARC ofte slet ikke nødvendig.
2️⃣ Sørg for korrekt SPF og alignment
- Alle dine legitime afsenderservere skal være i SPF
- Undgå SPF-rekorder med +all eller for mange includes
SPF er et centralt krav for DMARC og påvirker ARC’s baseline. techcommun...rosoft.com
3️⃣ DMARC-policy bør være korrekt
- Start med
p=noneunder test - Gå senere til
quarantineellerreject
DMARC alignment understøtter ARC’s funktion, fordi ARC bygger videre på disse resultater. techcommun...rosoft.com
4️⃣ Opsæt ARC på dine egne mail-hop, hvis du har dem
Hvis du fx bruger:
- en mailgateway
- spamfilter
- routing før udgående mail
- journaling eller arkivering
Så skal din egen infrastruktur også ARC-signere for at undgå kædebrud.
Hvis du ikke signerer ARC selv, kan kæden gå i stykker tidligt.
5️⃣ Undgå at bruge systemer der ændrer mails unødigt
Forwarding og content-modifikation er hovedårsagen til ARC-fail.
Suped beskriver tydeligt at videregivelse ændrer mailens headers og body, hvilket ødelægger DKIM og dermed også ARC-kæder. github.com
Hvis du selv kontrollerer nogen af de mellem-hops, kan du reducere header-manipulation.
🟥 Skal du være bekymret over arc=fail?
Ofte nej.
ARC er valgfrit, og selv ved arc=fail vil mange modtagende systemer ikke afvise mailen, så længe:
- SPF eller DKIM passer
- DMARC alignment er OK
- ARC-fail ikke overskriver de oprindelige autentificeringer
Microsoft Learn bekræfter, at ARC er et ekstra lag, ikke en erstatning for SPF, DKIM og DMARC. techcommun...rosoft.com
Kun tjenester der kræver ARC (fx visse Google/Yahoo politikker for forwarded mail) kan vælge at reagere på det.
⭐ Konklusion
arc=fail er næsten aldrig noget du som afsender kan rette direkte, fordi fejlen opstår på en mellemserver, der videresender eller ændrer mailen.
Men du kan sikre:
- robuste DKIM-signaturer
- korrekte SPF-optegnelser
- korrekt DMARC alignment
- ARC-signering i egne hops
…så dine mails har bedst chance for at overleve forwarding-kæderne.