MTA-STS en TLS-RPT: zo dwing je versleutelde e-mail in transport af in 2026

SPF, DKIM en DMARC garanderen dat een e-mail werkelijk van jouw domein komt en onderweg niet gemanipuleerd is. Wat ze niet doen, is afdwingen dat het bericht versleuteld over de lijn gaat. Dat gat dichten MTA-STS (RFC 8461) en TLS-RPT (RFC 8460), twee complementaire standaarden die het laatste zwakke punt in de SMTP-keten afdekken: het transportkanaal zelf.

Wat MTA-STS en TLS-RPT in het kort doen

• MTA-STS vertelt verzendende mailservers dat zij jouw domein alleen via TLS mogen bereiken, en wijst expliciet de hostnames en certificaten aan die geldig zijn.
• TLS-RPT zorgt dat diezelfde verzenders dagelijks rapporten sturen over geslaagde en mislukte TLS-verbindingen, zodat jij verkeer naar jouw domein kunt monitoren.

Samen voorkomen ze stille downgrade-aanvallen waarbij een aanvaller de STARTTLS-onderhandeling sloopt en e-mail in plaintext doorlaat.

Waarom is dit nodig?

Standaard SMTP gebruikt STARTTLS opportunistisch: als beide servers het ondersteunen, wordt de verbinding versleuteld, anders niet. Dat lijkt veilig, maar het is broos. Een aanvaller die zich tussen twee mailservers nestelt (bijvoorbeeld via BGP-hijacking of een gecompromitteerde router) kan de regel 250 STARTTLS uit de SMTP-banner verwijderen. De verzender denkt dan dat TLS niet beschikbaar is en valt terug op onversleutelde overdracht, zonder dat iemand het merkt.

MTA-STS lost dit op door het beleid van het ontvangende domein vooraf bekend te maken, los van de SMTP-sessie zelf, via HTTPS en DNS.

Hoe werkt MTA-STS technisch?

MTA-STS combineert drie elementen: een DNS-record, een policy-bestand en een vaste hostnaamconventie.

1. Het DNS-record

Op _mta-sts.voorbeeld.nl publiceer je een TXT-record dat aangeeft dat er een beleid bestaat en wanneer het laatst is gewijzigd:

_mta-sts.voorbeeld.nl.    IN    TXT    "v=STSv1; id=20260514T0900"

De id is een versie-identificatie. Verandert het beleid, dan verhoog je deze waarde. Verzendende servers cachen het beleid op basis van deze id.

2. Het policy-bestand

Op de URL https://mta-sts.voorbeeld.nl/.well-known/mta-sts.txt publiceer je het eigenlijke beleid:

version: STSv1
mode: enforce
mx: mail1.voorbeeld.nl
mx: mail2.voorbeeld.nl
max_age: 604800

De relevante regels:

• version: STSv1 is verplicht.
• mode: heeft drie waarden: none (geen actie), testing (rapporteer maar lever toch af) en enforce (weiger zonder geldige TLS).
• mx: somt de toegestane MX-hostnames op. Wildcards (*.voorbeeld.nl) zijn toegestaan.
• max_age: bepaalt in seconden hoe lang de cache geldig is. Aanbevolen: minstens 604.800 (één week), maximaal 31.557.600 (één jaar).

3. De hostnaamconventie

De policy moet beschikbaar zijn op een speciale subdomein-host: mta-sts.voorbeeld.nl. Dat is een afspraak in RFC 8461 en mag dus geen CNAME zijn naar een derde partij die je beleid niet onder controle heeft (tenzij dat een bewuste hosted-MTA-STS-dienst is).

Hoe werkt TLS-RPT?

TLS-RPT is veel simpeler: één DNS-record met daarin een of meerdere rapportagebestemmingen.

_smtp._tls.voorbeeld.nl.    IN    TXT    "v=TLSRPTv1; rua=mailto:tls-reports@voorbeeld.nl"

Verzendende mailservers sturen vervolgens dagelijkse JSON-rapporten (gecomprimeerd als .json.gz) waarin elke succesvolle en gefaalde TLS-verbinding wordt beschreven. De rua-tag accepteert ook https://-endpoints voor wie liever direct in een tool ingest.

Voorbeeldfragment uit een TLS-RPT-rapport

{
  "organization-name": "Google",
  "date-range": { "start-datetime": "2026-05-13T00:00:00Z", "end-datetime": "2026-05-14T00:00:00Z" },
  "policies": [{
    "policy": { "policy-type": "sts", "policy-domain": "voorbeeld.nl" },
    "summary": { "total-successful-session-count": 1284, "total-failure-session-count": 3 },
    "failure-details": [{ "result-type": "validation-failure", "sending-mta-ip": "203.0.113.5", "failed-session-count": 3 }]
  }]
}

Dergelijke rapporten zijn de enige betrouwbare manier om te zien of een bepaalde verzender problemen heeft met jouw certificaten of TLS-versies, voordat je naar enforce-mode overstapt.

De drie MTA-STS modes

Verschil met DANE voor SMTP

Veel organisaties vragen zich af of MTA-STS DANE vervangt. Het korte antwoord: ze lossen hetzelfde probleem op, met andere middelen.

Beide standaarden mogen naast elkaar bestaan en versterken elkaar wanneer je DNSSEC al hebt staan.

Welke providers ondersteunen MTA-STS in 2026?

• Google Workspace en Gmail controleren MTA-STS bij elk extern domein en hebben het zelf actief.
• Microsoft Exchange Online heeft MTA-STS in 2023 publiekelijk geïntroduceerd en check sindsdien op externe domeinen.
• Yahoo Mail publiceert een eigen beleid en respecteert dat van anderen.
• Apple iCloud Mail en de grotere Nederlandse providers (KPN, Tele2 en cloud-mailproviders) ondersteunen MTA-STS in toenemende mate.

Stappenplan voor implementatie

1. Zorg dat al je MX-hosts een geldig TLS-certificaat hebben van een publiek vertrouwde CA, met de juiste hostname.
2. Publiceer het beleid op https://mta-sts.jouwdomein.nl/.well-known/mta-sts.txt met mode testing.
3. Publiceer het DNS-record _mta-sts.jouwdomein.nl met versie-id.
4. Publiceer het TLS-RPT-record op _smtp._tls.jouwdomein.nl met een werkende rua-mailbox of API-endpoint.
5. Verzamel minstens 4 tot 8 weken aan rapporten en los geconstateerde validation- of negotiation-failures op.
6. Zet mode op enforce en verhoog de id-waarde zodat verzendcaches verlopen.
7. Monitor structureel. Zet een alert op certificaten met minder dan 14 dagen geldigheid en op een onverwacht stijgend failure-percentage in TLS-RPT.

Veelgemaakte fouten

• CNAME naar een derde partij zonder eigen controle op mta-sts.jouwdomein.nl. Geef altijd voorrang aan zelf gehoste of expliciet hosted-MTA-STS-diensten.
• HTTPS-certificaat op de policy-host vergeten. Verzenders eisen dat ook de HTTPS-verbinding naar het policy-bestand valideert.
• Mode te snel op enforce zetten. Zonder rapporten loop je het risico dat legitieme verzenders met oudere TLS-stacks worden geweigerd.
• Geen TLS-RPT. Zonder rapporten merk je problemen pas wanneer een gebruiker klaagt dat een mail niet aankwam.
• MX-hostnames vergeten in policy. Een nieuwe MX (bijvoorbeeld na migratie) moet in zowel DNS als policy verschijnen voordat je hem in gebruik neemt.

Veelgestelde vragen

Heb ik DNSSEC nodig voor MTA-STS?

Nee. MTA-STS leunt op het bestaande Web PKI-systeem en op HTTPS naar de policy-host. Dat maakt het laagdrempeliger dan DANE.

Wat gebeurt er als mijn policy-bestand even niet bereikbaar is?

Verzenders gebruiken de gecachete versie tot max_age verloopt. Daarom is het belangrijk een ruime max_age te kiezen en de policy-host hoog beschikbaar te houden.

Wat is het verschil tussen none en geen MTA-STS hebben?

none is een actieve uitspraak: 'er is geen geldig beleid'. Verzenders zullen jou dan exact zo behandelen als een domein zonder MTA-STS. Het is nuttig om een eerder beleid expliciet in te trekken.

Hoe lees ik TLS-RPT-rapporten?

De rapporten zijn JSON, vaak gecomprimeerd als .json.gz. Een handvol open-source tools en commerciële diensten zoals DNSWatcher kunnen ze inlezen en omzetten naar dashboards.

Geldt MTA-STS ook voor uitgaande e-mail?

MTA-STS-beleid geldt voor inkomende e-mail naar jouw domein. Voor uitgaande verbindingen ben jij juist de verzendende kant: je MTA controleert dan het beleid van de ontvanger. Beide rollen draaien zo via dezelfde standaard.

Conclusie

MTA-STS en TLS-RPT vullen het laatste gat in de e-mailbeveiligingsketen: het transportkanaal zelf. Waar SPF, DKIM en DMARC bewijzen wie de afzender is, garanderen MTA-STS en TLS-RPT dat het bericht onderweg niet in plaintext valt en dat je inzicht hebt in wat er werkelijk gebeurt op de SMTP-verbinding. De implementatie kost weinig (een handvol DNS-records, één HTTPS-pagina, een rapportagemailbox) en de winst is groot: aanvallers verliezen een populaire angle die in opportunistic-TLS-only-setups vaak nog open ligt. Wie zijn DMARC al op reject heeft staan, doet er goed aan deze laatste laag nog dit kwartaal toe te voegen.