MTA-STS

Deze gids maakt deel uit van onze gids over e-mailauthenticatie. Gerelateerd: BIMI en DKIM vs DMARC.

MTA-STS (SMTP MTA Strict Transport Security) is een standaard waarmee een domein kan vereisen dat inkomende e-mail wordt bezorgd via versleutelde, geauthenticeerde TLS, waardoor downgrade- en man-in-the-middle-aanvallen worden voorkomen. TLS-RPT is de bijbehorende rapportagestandaard, die dagelijkse rapporten verzamelt over TLS-bezorgfouten. MTA-STS beschermt de transportlaag en vult SPF, DKIM en DMARC aan, die de afzender authenticeren in plaats van de verbinding.

Het probleem dat MTA-STS oplost

Wanneer twee mailservers berichten uitwisselen via SMTP, onderhandelen ze normaal gesproken over versleuteling met STARTTLS. Het addertje onder het gras is dat STARTTLS opportunistisch is: de verzendende server vraagt of de ontvanger TLS ondersteunt, en als het antwoord nee is, valt hij stilletjes terug op platte tekst. Die vraag en dat antwoord gebeuren in het openbaar, wat betekent dat een aanvaller die tussen de twee servers is gepositioneerd het STARTTLS-commando uit het gesprek kan strippen. De verzendende server denkt dan dat de ontvanger geen TLS-ondersteuning heeft en bezorgt het bericht onversleuteld, of maakt verbinding met een impostor-server die een vervalst certificaat presenteert.

Dit staat bekend als downgrade- en man-in-the-middle-aanvallen. Omdat SMTP eerst voor interoperabiliteit en pas later voor beveiliging is ontworpen, was er historisch geen manier voor een ontvangend domein om te zeggen “versleutel e-mail naar mij altijd, en weiger te bezorgen als je dat niet kunt.” MTA-STS vult precies dat gat. Het laat een domein een beleid publiceren dat verklaart dat inkomende e-mail moet worden bezorgd via TLS, met een geldig certificaat dat overeenkomt met een van de gepubliceerde MX-hosts. Verzendende servers die MTA-STS ondersteunen, respecteren het beleid en zullen een bericht liever uitstellen of bouncen dan het in cleartext te verzenden.

Hoe MTA-STS werkt

MTA-STS berust op twee onderdelen die samenwerken: een DNS TXT-record dat het beleid aankondigt, en een via HTTPS gehost beleidsbestand dat het definieert.

Publiceer eerst een TXT-record bij _mta-sts.yourdomain.com. Dit record signaleert dat er een beleid bestaat en draagt een ID dat verandert telkens wanneer je het beleid bijwerkt, zodat verzendende servers weten wanneer ze het opnieuw moeten ophalen.

_mta-sts.yourdomain.com.  IN  TXT  "v=STSv1; id=20260910T120000;"

Serveer ten tweede het beleidsbestand via HTTPS op een vaste, bekende locatie: https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. De HTTPS-vereiste is belangrijk omdat het certificaat op die host bewijst dat het beleid authentiek is en niet onderweg is gemanipuleerd.

version: STSv1
mode: enforce
mx: mail.yourdomain.com
mx: *.yourdomain.com
max_age: 604800

De mx-regels sommen elke hostnaam op die jouw e-mail mag ontvangen, overeenkomend met jouw MX-records. max_age vertelt verzendende servers hoe lang ze het beleid moeten cachen, in seconden (604800 is één week). Een langere cache is beter bestand tegen een aanvaller die kortstondig DNS kan manipuleren, dus een waarde van ten minste een paar dagen wordt aanbevolen zodra je vertrouwen hebt in jouw configuratie.

Enforce- versus testing-modus

Het mode-veld in het beleidsbestand bepaalt hoe strikt het beleid wordt toegepast, en het is de belangrijkste knop bij het uitrollen van MTA-STS.

Begin met mode: testing. In testing-modus evalueren verzendende servers jouw beleid maar blokkeren ze nooit de bezorging wanneer het faalt. In plaats daarvan rapporteren ze, in combinatie met TLS-RPT hieronder, mislukkingen aan je terug. Hierdoor kun je verkeerd geconfigureerde MX-hosts, verlopen certificaten of hostnaam-mismatches ontdekken zonder ooit een legitiem bericht te verliezen.

Zodra jouw rapporten een week of twee schoon terugkomen, schakel je over naar mode: enforce. Nu zullen verzendende servers weigeren e-mail te bezorgen die niet via geauthenticeerde TLS naar een vermelde MX-host kan worden verzonden. Een derde waarde, mode: none, schakelt het beleid effectief uit en wordt gebruikt om MTA-STS netjes buiten gebruik te stellen. Ga altijd doelbewust van testing naar enforce, nooit haastig omgekeerd.

TLS-RPT: rapportage

MTA-STS op zichzelf vertelt je niets over hoe de bezorging verloopt. TLS-RPT (SMTP TLS Reporting) is het feedbackkanaal. Je publiceert een tweede TXT-record bij _smtp._tls.yourdomain.com dat een adres benoemt dat aggregaatrapporten zou moeten ontvangen.

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

Deelnemende verzendende servers sturen je een dagelijks JSON-rapport dat succesvolle en mislukte TLS-sessies naar jouw domein samenvat, inclusief de reden voor elke mislukking, zoals een certificaat dat niet valideerde of een STARTTLS-onderhandeling die werd gestript. Deze rapporten zijn wat testing-modus nuttig maakt, en ze blijven waardevol in enforce-modus als vroegtijdig waarschuwingssysteem voor het verlopen van certificaten of MX-wijzigingen. Veel teams leiden het rua-adres naar een monitoringdashboard in plaats van een menselijke inbox.

Waar het past naast SPF, DKIM en DMARC

Het is gemakkelijk om MTA-STS op één hoop te gooien met de andere afkortingen, maar het lost een ander probleem op. SPF, DKIM en DMARC authenticeren de afzender en beantwoorden “komt dit bericht echt van het domein dat het beweert?” MTA-STS beveiligt de verbinding en beantwoordt “wordt dit bericht privé en naar de juiste server bezorgd?” Je wilt beide. Een bericht kan perfect geauthenticeerd zijn en toch onderweg worden onderschept, en een perfect versleutelde verbinding kan nog steeds een vervalst bericht dragen.

Voor het volledige beeld van afzenderauthenticatie, zie onze gids over e-mailauthenticatie. MTA-STS past van nature bij die standaarden als een toevoeging op de transportlaag, en zodra je die op orde hebt, is BIMI nog een geavanceerde laag die het overwegen waard is, waarmee je een geverifieerd merklogo kunt tonen in ondersteunende inboxen.

Veelgestelde vragen

Wat is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) is een standaard waarmee een domein kan vereisen dat inkomende e-mail wordt bezorgd via versleutelde, geauthenticeerde TLS. Het publiceert een DNS-record en een via HTTPS gehost beleidsbestand zodat verzendende servers versleuteling afdwingen en weigeren terug te vallen op platte tekst, waardoor downgrade- en man-in-the-middle-aanvallen tegen SMTP worden geblokkeerd.

Wat is het verschil tussen MTA-STS en TLS-RPT?

MTA-STS is de handhavingsstandaard: het definieert het beleid dat TLS-bezorging vereist. TLS-RPT is de rapportagestandaard: het definieert een DNS-record en JSON-rapportformaat zodat verzendende servers je dagelijkse samenvattingen sturen van TLS-bezorgsuccessen en -mislukkingen. Je zet ze samen in, waarbij je TLS-RPT gebruikt om een MTA-STS-beleid veilig te valideren voordat je het afdwingt.

Is MTA-STS verplicht?

Nee, MTA-STS is niet verplicht, en e-mail werkt zonder. Het wordt echter sterk aanbevolen voor elk domein dat gevoelige e-mail verwerkt, omdat het een reëel gat dicht dat SPF, DKIM en DMARC niet aanpakken. Het eerst in testing-modus implementeren brengt geen bezorgrisico met zich mee, dus er is weinig reden om het niet te adopteren.

Vervangt MTA-STS SPF, DKIM of DMARC?

Nee. MTA-STS werkt op een andere laag. SPF, DKIM en DMARC authenticeren de afzender en detecteren spoofing, terwijl MTA-STS de transportverbinding beveiligt zodat e-mail privé naar de juiste server wordt bezorgd. Het zijn complementaire maatregelen, en een goed beschermd domein zet ze allemaal samen in in plaats van de een boven de ander te kiezen.