De reis van een e-mail: van Verzenden tot inbox
Je drukt op Verzenden en een paar seconden later staat je mail bij de ander in de inbox. Of in de spammap. Of je krijgt een bounce met een onbegrijpelijke foutcode. Wat er in die seconden gebeurt, draait nog steeds op SMTP, een protocol uit 1982 dat is ontworpen voor een netwerk waarin iedereen elkaar vertrouwde.
Hieronder volg je één mail van alice@example.nl naar bob@example.com. De domeinen zijn voorbeelddomeinen, maar de dialoog in de balk onder het plaatje is precies wat mailservers tegen elkaar zeggen.
From: alice@example.nl To: bob@example.com Subject: Offerte
de client voegt Date: en Message-ID: toe; er is nog niets verstuurd
Een brief met een envelop
Je mailclient maakt van je tekst een bericht volgens RFC 5322: headers als From:, To:, Subject:, Date: en Message-ID:, een lege regel en dan de body. Dat is de brief. Pas bij het versturen komt er een envelop omheen, en die envelop staat los van wat er in de brief staat. Dat verschil verklaart straks waarom phishing zo makkelijk is.
Submission: inloggen op poort 587
Je client levert de mail niet zelf af bij de ontvanger. Hij geeft hem aan de mailserver van je eigen provider, via submission op poort 587. De client zegt EHLO, de server biedt STARTTLS aan, de verbinding wordt versleuteld en pas dan volgt AUTH met je gebruikersnaam en wachtwoord (of een OAuth-token).
Het alternatief is poort 465, waar TLS vanaf het eerste byte aanstaat. RFC 8314 geeft daar sinds 2018 zelfs de voorkeur aan. Poort 25 is voor verkeer tussen servers; veel providers blokkeren uitgaand verkeer daarop vanaf thuisaansluitingen, juist tegen spam.
De uitgaande server ondertekent
De uitgaande server (de MTA) zet de mail in de wachtrij en plaatst er een DKIM-handtekening op. Hij berekent een hash van de body (bh=) en ondertekent die samen met een lijst headers, waaronder altijd From:, met een privésleutel. In de header staan het domein (d=example.nl) en een selector (s=mail2026). De publieke sleutel staat in DNS op mail2026._domainkey.example.nl.
Waar woont de mail van example.com?
Om de ontvanger te vinden, vraagt de MTA het MX-record van example.com op. Dat geeft een of meer mailservers met een prioriteit; het laagste getal wordt eerst geprobeerd. Is er geen MX, dan valt SMTP terug op het A- of AAAA-record van het domein zelf. Een domein dat helemaal geen mail wil ontvangen, publiceert een null MX: 0 ..
Poort 25 en STARTTLS
De MTA opent een TCP-verbinding naar mx.example.com op poort 25. De ontvanger groet met 220, de verzender zegt EHLO mail.example.nl, en als de ontvanger STARTTLS aanbiedt, wordt de verbinding versleuteld.
Maar dat is opportunistisch: biedt de server het niet aan, of haalt iemand onderweg die regel weg, dan gaat de mail meestal gewoon onversleuteld. MTA-STS en DANE dichten dat gat. En TLS versleutelt alleen de verbinding. Wie de mail echt heeft geschreven, weet de ontvanger daarmee nog steeds niet.
Envelop en brief zijn twee dingen
Nu volgt de envelop: MAIL FROM:<bounce@example.nl> en RCPT TO:<bob@example.com>. Daarna DATA, en dan de hele brief inclusief de From:-header die Bob straks ziet. Een punt op een lege regel sluit af, de server antwoordt 250 OK.
Kijk naar het plaatje: het envelope-adres (ook wel Return-Path) en de zichtbare From: zijn verschillend. SMTP controleert geen van beide. Je kunt in DATA elke From: zetten die je wilt, en daarom kan iedereen een afzender vervalsen.
SPF en DKIM
SPF zoekt het TXT-record van het envelope-domein op en kijkt of het verzendende IP-adres daarin staat. Let op: dat is het domein uit MAIL FROM, niet de From: die jij ziet. Een SPF-record mag bij het evalueren maximaal 10 DNS-lookups veroorzaken (include, a, mx, redirect en een paar andere tellen mee); daarboven volgt permerror.
DKIM haalt de publieke sleutel op via de selector en controleert de handtekening. Klopt de body-hash niet meer, dan faalt DKIM.
DMARC: horen ze bij de afzender?
SPF en DKIM zeggen alleen dat een domein de mail heeft goedgekeurd, niet dat het het domein in From: is. Daarvoor is er DMARC. Het record op _dmarc.example.nl eist alignment: SPF of DKIM moet slagen voor hetzelfde domein als de zichtbare From:. Standaard is dat relaxed, waarbij hetzelfde organisatiedomein genoeg is, zodat mail.example.nl telt voor example.nl. Met aspf=s of adkim=s wordt het strict: exact hetzelfde domein.
Eén geslaagde, aligned controle is genoeg. Hier slagen ze allebei, dus de mail gaat naar de inbox.
Speel zelf
Kies hierboven een scenario en een policy. Bij de vervalste From: slagen SPF en DKIM keurig, maar voor het domein van de oplichter; DMARC faalt. Bij doorgestuurd breekt SPF, omdat het IP-adres van de doorstuurder niet in het SPF-record staat, maar DKIM overleeft en DMARC slaagt dus toch. Een mailinglijst die het onderwerp aanpast, breekt DKIM ook.
De policy bepaalt wat er met een DMARC-fail gebeurt: p=none rapporteert alleen, p=quarantine betekent meestal de spammap en bij p=reject weigert de ontvanger de mail doorgaans al tijdens de SMTP-sessie, met een 550. Het blijft een verzoek aan de ontvanger: die beslist uiteindelijk zelf.
Wat niet in het plaatje past
Google en Yahoo maakten het verplicht. Sinds 1 februari 2024 moet wie meer dan 5.000 mails per dag naar Gmail stuurt SPF én DKIM hebben, een DMARC-record met minimaal p=none, een From: die aligned is met SPF of DKIM, een spamklachtenpercentage onder 0,3 procent en one-click unsubscribe voor marketingmail. Yahoo stelt vrijwel dezelfde eisen, zonder een harde grens in aantallen te noemen.
Mailinglijsten en doorsturen. Omdat lijsten DKIM breken, herschrijven veel lijstservers bij een domein met p=reject de From: naar hun eigen adres. ARC (RFC 8617) laat een tussenstation vastleggen welke controles het zag, zodat de ontvanger dat kan meewegen.
DMARC is vernieuwd. In mei 2026 verscheen RFC 9989 als opvolger van RFC 7489. De tag pct verdwijnt, er komt een testmodus t=y voor in de plaats, en het organisatiedomein wordt voortaan via een tree walk in DNS bepaald in plaats van via de Public Suffix List.
Zelf proberen
Alles wat de ontvanger opzoekt, kun je zelf opvragen:
dig MX google.com # 10 smtp.google.com.
dig TXT google.com # v=spf1 include:_spf.google.com ~all
dig TXT _dmarc.google.com # v=DMARC1; p=reject; rua=mailto:...
dig TXT <selector>._domainkey.<domein>
Gemeten op 24 september 2026. Grappig detail: dig MX example.com geeft 0 ., een null MX. De voorbeelddomeinen ontvangen dus echt geen mail.
Voor DKIM heb je de selector nodig. Die vind je in een ontvangen mail: open de bron (in Gmail: Origineel weergeven) en zoek naar s= in de DKIM-Signature-header. Daar staat ook de uitslag van de ontvanger:
Authentication-Results: mx.example.com;
dkim=pass header.d=example.nl header.s=mail2026;
spf=pass smtp.mailfrom=example.nl;
dmarc=pass (p=REJECT) header.from=example.nl
Tot slot
Wat me steeds weer verbaast: de controles zijn allemaal achteraf bijgebouwd op een protocol dat vertrouwen als uitgangspunt had. SPF en DKIM hebben elk een eigen gat, en pas DMARC met zijn alignment knoopt ze aan de afzender die je ziet. Heb je een eigen domein, zoek dan eens je DMARC-record op. Staat daar niets, dan kan iedereen vandaag nog mail versturen die van jou lijkt te komen.