MTA-STS en DANE: hoe mailtransportbeveiliging wordt afgesloten
Bijna elke mailserver kan StartTLS: de server zegt dat hij TLS kan, de verzender zegt ja, en de verbinding wordt versleuteld. Maar "kan" is geen "moet" — een aanvaller die onderweg één stapje lager drukt, krijgt een platte verbinding waar een versleutelde bedoeld was, en niemand ziet het. Tegen dat downgrade-spel zijn twee standaarden gebouwd, en ze zeggen allebei iets anders: MTA-STS is een beleid, DANE is een belofte op papier.
MTA-STS en DANE meet beide kanten voor één domein in één keer: de aankondiging en het beleid van RFC 8461, regel voor regel naast je eigen MX gelegd, en de TLSA-pinnen van RFC 6698 vergeleken met het certificaat dat je mailserver werkelijk toont — opgehaald met één STARTTLS-handshake, zonder mail te versturen.
Dit artikel leest wat elke standaard van je vraagt, waar de valkuilen zitten — redirects, max_age, certificaatwissels — en wanneer een hoog cijfer echt iets betekent. De DNS-leesacties eromheen, SPF en DMARC, staan in SPF, DKIM en DMARC; hier gaat het om de verbinding zelf.
1. MTA-STS: eerst een aankondiging, dan een beleid
MTA-STS (RFC 8461) bestaat uit twee delen. Het eerste staat in DNS: één TXT-record op _mta-sts.jedomein.nl, met precies v=STSv1 en een id — een versieringloze aankondiging dat er beleid is. Het tweede staat op HTTPS: de policy zelf, op https://mta-sts.jedomein.nl/.well-known/mta-sts.txt, met drie regels die ertoe doen: mode (none, testing of enforce), mx (welke mailservers het beleid toelaat) en max_age (hoe lang een ontvanger het beleid mag naklinken).
De details zijn het beleid: de policy mag niet via een redirect bereikt worden — RFC 8461 zegt dat redirects niet gevolgd mogen worden, dus een meukverwijzing telt als fout. max_age mag niet boven 31.557.600 (een jaar) uitkomen. En de mx-regels moeten bij je echte MX passen: een beleid dat jou eigen mailserver niet noemt, wordt door een correcte ontvanger geweigerd — precies de fout die voor downgrades openbaar is. De tool legt al die regels naast je MX en zegt welke regel struikelt.
2. DANE: een pin op je certificaat
DANE voor mail (RFC 6698) zet één of meer TLSA-records op _25._tcp.mail.jedomein.nl. Zo'n record noemt vier dingen: welke rol het certificaat speelt (usage), welk deel van het certificaat gepind wordt (selector: de hele der of de publieke sleutel), hoe het vergeleken wordt (matching: hash of ruwe bytes) en de vingerafdruk zelf. usage 3 (DANE-EE) pinnt het certificaat van de server zelf — dat is de vorm die zonder CA-vertrouwen kan en dus de sterkste.
usage 0–2 pinnt een certificaat van een certificerende instantie, en dat is een ander gesprek: dan vertrouw je alsnog de keten eronder. Een TLSA-meting is pas een vergelijking als er iets tegenover staat: de tool doet daarvoor precies één protocolregel op poort 25 — STARTTLS — laat de TLS-handshake lopen en legt de vingerafdrukken van wat de server toont naast elke pin. Geen pin op een mailserver? Dan wordt die mailserver niet eens benaderd: geen socket, geen meting, n/b.
3. De valkuil: elke certificaatwissel is een DNS-moment
Een pin is een belofte die je handmatig waarmaakt. Laat je certificaat verlopen en vervang je het door een ander — dan staat er in DNS een pin op een certificaat dat niet meer bestaat, en elke correcte ontvanger die DANE volgt, zal je mail wijzen of falen op TLS. Dat is geen bug van DANE, dat is de functie: een pin die niet meer klopt, klopt niet. Na élke certificaatwissel moet de TLSA-record dus opnieuw gezet worden, en een certificaat dat automatisch rouleert (bijvoorbeeld bij Let's Encrypt met wisselende sleutels) vraagt om een plan: pin de publieke sleutel die blijft, of pin via selector en matching op iets dat stabiel is.
Max_age is hetzelfde moment in de andere richting: een te lange termijn (boven een jaar) verbiedt het beleid, een te korte (bijv. onder een dag) maakt elke DNS-wijziging een race. Praktisch: test eerst — mode testing laat ontvangers het beleid lezen en rapporteren zonder mail te weigeren — en zet daarna enforce. En houd TLS-RPT aan: daar melden ontvangers wat hun TLS-pogingen kostten, zodat je ziet of het beleid werkt in plaats van hoopt.
4. Wat het cijfer wel en niet zegt
De tool oordeelt wat hij gemeten heeft: beleid aanwezig en bruikbaar, mx-regels die bij je MX passen, pinnen die overeenkomen met het live-certificaat. Een A betekent: wat DNS belooft, komt overeen met wat je mailserver toont. Het betekent niet dat élke verzender het beleid volgt — MTA-STS is pas een slot als beide kanten het ondersteunen, en DANE wordt maar door een handvol providers echt afgedwongen.
Begin bij de meetkant: MTA-STS en DANE voor beleid en pinnen, Mailbeveiliging voor wat er verder in je mail-DNS staat (MTA-STS-lezen, TLS-RPT, DKIM), en Mailpoorten om te zien of poort 25 überhaupt reageert. Die drie samen zijn de hele TLS-laag van je mail, en geen van drieën verstuur ooit iets.