technisch · antwoord met bronnen
Authenticated Received Chain (ARC) uitgelegd
Authenticated Received Chain (ARC) is een standaard voor e-mailauthenticatie waarmee tussenliggende mailservers de resultaten van SPF-, DKIM- en DMARC-controles kunnen ondertekenen. Zo kan de uiteindelijk ontvangende server bij een doorgestuurde e-mail de oorspronkelijke authenticatiestatus vertrouwen, ook als het doorsturen de oorspronkelijke SPF- of DKIM-handtekeningen heeft gebroken.
Hoe ARC technisch werkt
ARC voegt drie specifieke headers aan een e-mail toe wanneer die een tussenliggende server passeert. De ARC-Seal- authentication levert een digitale handtekening over de ARC-Message-Seal, die de ARC-Authentication-Results bevat. Deze keten vormt een verifieerbaar verslag van de authenticatiestatus bij elke hop. Wordt een bericht doorgestuurd, dan kan de volgende server de ARC-keten verifiëren en zien dat het bericht legitiem was voordat de doorstuurder de envelope of headers aanpaste.
Belang voor e-mailafzenders
ARC is cruciaal voor afzenders van wie de e-mails vaak door gebruikers of mailinglijsten worden doorgestuurd. Zonder ARC verandert een doorstuurder vaak het afzenderadres of past hij de berichttekst aan, waardoor SPF en DKIM falen. Heeft de afzender een strikt DMARC-beleid met reject, dan worden deze legitieme doorgestuurde e-mails geblokkeerd. ARC biedt de uiteindelijke ontvanger een mechanisme om een DMARC-fout te negeren als een vertrouwde tussenliggende server het bericht al heeft gevalideerd.
Operationele aandachtspunten en veelgemaakte fouten
Een veelgemaakte fout is aannemen dat ARC DKIM of SPF vervangt. ARC is een aanvullende laag die van die protocollen afhankelijk is. Het werkt alleen als de tussenliggende server ARC ondersteunt en de uiteindelijk ontvangende server de ARC-sealer vertrouwt. Afzenders moeten nog steeds de gratis tools van SendHQ (https://sendhq.cc/tools) gebruiken om te controleren of hun primaire DKIM- en SPF-records correct zijn geconfigureerd, voordat ze voor doorstuurscenario's op ARC vertrouwen.
Concreet implementatievoorbeeld
Neem een gebruiker die werkmail doorstuurt naar een persoonlijk Gmail-account. De werkserver ondertekent de mail met DKIM. De doorstuurserver ontvangt hem, valideert DKIM en voegt een ARC-seal toe. Wanneer Gmail de mail ontvangt, faalt de oorspronkelijke SPF-controle, omdat de doorstuurserver geen geautoriseerde afzender is. Gmail ziet echter de ARC-seal van de vertrouwde doorstuurder, verifieert het oorspronkelijke DKIM-resultaat dat in de ARC-header is opgeslagen en levert de mail af in plaats van hem te weigeren.
Samenspel tussen ARC en DMARC
ARC fungeert als vangnet voor DMARC. Waar DMARC de huidige staat van het bericht beoordeelt, levert ARC een historisch verslag van de authenticatie. Faalt de huidige DMARC-controle, maar bestaat er een geldige ARC-keten van een vertrouwde bron, dan kan de ontvangende mail transfer agent ervoor kiezen het DMARC-beleid te negeren en het bericht te accepteren. Dat vermindert false positives in spamfilters.
Vragen die teams stellen
Vervangt ARC DMARC?
Nee, ARC vervangt DMARC niet. Het biedt een manier om authenticatieresultaten te bewaren, zodat DMARC nauwkeuriger kan worden beoordeeld nadat een bericht is doorgestuurd.
Wie moet ARC implementeren?
ARC wordt vooral geïmplementeerd door tussenpartijen in de mailketen, zoals beheerders van mailinglijsten, doorstuurdiensten en zakelijke e-mailgateways.
Houdt ARC alle spam tegen?
Nee, ARC is bedoeld om te voorkomen dat legitieme doorgestuurde mail als spam wordt gemarkeerd, niet om spam zelf tegen te houden. Het is afhankelijk van vertrouwen tussen de sealer en de ontvanger.
Ondersteunen alle e-mailproviders ARC?
De meeste grote providers, zoals Gmail en Microsoft 365, ondersteunen ARC, maar bij kleinere mailservers en oudere systemen verschilt de adoptie.
Primaire bronnen
- RFC 8617: The Authenticated Received Chain (ARC) — RFC Editor
- RFC 7489: Domain-based Message Authentication, Reporting and Conformance — RFC Editor
- RFC 6376: DomainKeys Identified Mail — RFC Editor