Waarom de e-mail die je naar jezelf doorstuurde in spam terechtkwam

Stel een automatische doorstuurregeling in van je oude account naar je nieuwe, en een deel van die e-mails verdwijnt stilletjes naar spam — niet omdat je provider stuk is, maar omdat doorsturen aangeeft wie de boodschap verstuurt zonder de cryptografische verificatie aan te passen. SPF checkt de verkeerde server, het DMARC-verdict slaat om naar fail, en een legitieme e-mail die je jezelf hebt gestuurd wordt in quarantaine geplaatst. De oplossing heeft een naam: ARC, gedefinieerd in RFC 8617 terug in 2019.

Waarom doet doorsturen mijn mail SPF-checks mislukken?

Omdat SPF de laatste server checkt die het bericht heeft doorgegeven, en doorsturen verandert die server. SPF — Sender Policy Framework — is een DNS-record die aangeeft welke IP-adressen e-mail voor een domein mogen versturen. Wanneer bank.com je een kwitantie stuurt, checkt de ontvangende server: kwam dit van een IP die bank.com heeft goedgekeurd? Ja. Pass.

Nu stuur je die kwitantie van je Gmail naar je nieuwe adres door. Googles servers geven het door. De uiteindelijk ontvangende server voert de SPF-check uit en vraagt: mag Google e-mail voor bank.com versturen? Nee, dat mag niet. SPF faalt. Googles eigen Workspace-documentatie legt dit duidelijk uit — doorgestuurde berichten falen SPF omdat de doorstuur-server niet in de SPF-record van het originele domein staat. Niets werd vervalst. De check kijkt alleen maar naar de verkeerde hop.

Dus waarom gaat dat naar spam?

DMARC. SPF dat faalt was vroeger nog te overleven; DMARC maakte ervan een verdict. DMARC verbindt SPF en DKIM en vertelt ontvangers wat ze moeten doen als beide falen: niets doen, in quarantaine plaatsen, of weigeren. Tegen 2024 hadden grote afzenders geen keuze — Google en Yahoo begonnen DMARC te verplichten voor iedereen die meer dan 5.000 berichten per dag naar hun gebruikers stuurt.

DKIM, de andere pijler, is een handtekening in het bericht ingebakken. In theorie overleeft het doorsturen, omdat het de inhoud ondertekent, niet de route. In de praktijk breekt alles wat het bericht aanraakt het. Een mailinglijst die een voettekst toevoegt met "je bent geabonneerd, meld je hier af", een server die de onderwerpregel herschrijft, zelfs een verandering in hoe een regel wordt verpakt — de handtekening klopt niet meer, en DKIM faalt ook. Nu zijn beide pijlers neer, DMARC zegt fail, en je eigen kwitantie ligt in de prullemand.

Wat is ARC en lost het dit eigenlijk op?

ARC — Authenticated Received Chain, RFC 8617 — laat een eerlijke doorstuurder betuigen dat de mail authenticatie doorstond voordat het het aanraakte. De doorstuur-server markeert het bericht met een verzegeld record dat zegt "toen dit mij bereikt, waren SPF en DKIM geldig — vertrouw mijn woord voor het stuk dat je niet kunt verifiëren." De uiteindelijk ontvanger, als hij die doorstuurder vertrouwt, kan de DMARC-fail negeren en bezorgen.

De vangst zit in "als hij vertrouwt". ARC is geen wachtwoord; het is een reputatiesysteem. Een ontvanger weegt af of de ARC-afzegeler een bekende, goed gedragende operator is. Google zet ARC-headers in en eert ze van afzenders die het vertrouwt, daarom overleeft een Gmail-naar-Gmail-doorstuur meestal wel terwijl een doorstuur via een oud universiteitsrelay dat niet doet.

Als je het doorsturen zelf beheert, helpen twee concrete stappen. Gebruik Server-Side Redirect / SRS-stijl herschrijven als je host dat aanbiedt, waardoor de envelop-afzender wordt herschreven zodat SPF tegen jouw doorstuurder wordt gecheckt in plaats van tegen het originele domein. En geef voorrang aan doorsturen tussen providers die beide ARC ondersteunen. Als je accounts aan het consolideren bent en je wilt dat de bestemming de authenticatierotzooi zelf afhandelt, dat is precies het soort loodgieterswerk waar een AI-e-mailplatform voor is gebouwd.

Wanneer moet ik mijn provider niet meer de schuld geven?

Wanneer het patroon "alleen doorgestuurde mail faalt" is, doet je provider het correct — het protocol is het probleem. Hier is de aanwijzing: open de kopteksten van het vermiste bericht en zoek naar de regel Authentication-Results. Als je spf=fail ziet naast een verzend-IP dat tot een doorstuurder behoort in plaats van tot de originele afzender, dan checkt SPF de verkeerde hop. Als dkim=fail op e-mail verschijnt die via een lijst of relay ging die berichten bewerkt, dan is het een verminkte handtekening, geen vervalsing.

De oncomfortabele waarheid is dat e-mailauthenticatie over twee decennia laag voor laag is aangeboord op een systeem dat nooit aannamen dat iemand zou liegen. SPF kwam in 2006, DKIM in 2007, DMARC in 2015, ARC in 2019 — elk een gat dichttimmeren dat het vorige openbrak. Doorsturen is de naad waar alle vier tegen elkaar schuren, en je inbox is waar je de wrijving voelt.