MTA-STS en TLS-RPT: wat ze doen en of u ze nodig hebt
MTA-STS is een beleid waarmee u aan verzendende servers zegt dat mail naar uw domein enkel via een versleutelde en geverifieerde TLS-verbinding afgeleverd mag worden. TLS-RPT is het rapportagekanaal daarbij: verzenders sturen u dagelijks een verslag van verbindingen die niet aan dat beleid voldeden. Beide beschermen de mail die u ontvangt; voor de mail die u verstuurt, hebt u vooral een verzendserver nodig die deze beleidsregels bij de ontvanger respecteert.
Het probleem dat ze oplossen
Mail tussen servers gaat al jaren grotendeels versleuteld, via STARTTLS. Maar STARTTLS is opportunistisch: de verzendende server vraagt of de ontvanger versleuteling ondersteunt, en als het antwoord uitblijft of het certificaat niet klopt, valt hij stilzwijgend terug op een onversleutelde verbinding. Iemand die tussen beide servers zit, kan die vraag wegfilteren en de mail in leesbare vorm laten passeren. MTA-STS neemt die terugvaloptie weg: als uw beleid op "enforce" staat, mag een verzender die de versleuteling niet rond krijgt, de mail niet afleveren.
Hoe MTA-STS werkt
Het bestaat uit twee delen die u zelf publiceert:
- Een DNS-record op _mta-sts.uwdomein.be met een versie en een id. Het id verandert u telkens als u het beleid aanpast; verzenders weten zo dat ze het opnieuw moeten ophalen.
- Een beleidsbestand op https://mta-sts.uwdomein.be/.well-known/mta-sts.txt. Daarin staan de modus (none, testing of enforce), de mailservers die voor uw domein mogen ontvangen, en hoelang een verzender het beleid mag onthouden.
Dat tweede deel verklaart waarom MTA-STS via HTTPS gaat en niet enkel via DNS: het certificaat van die webpagina bewijst dat het beleid echt van uw domein komt, zonder dat DNSSEC nodig is. Het alternatief, DANE, doet hetzelfde via DNS maar vereist wél DNSSEC op uw domein, wat in de praktijk bij veel Belgische registrars en hostingpakketten niet standaard aanstaat.
Hoe TLS-RPT werkt
TLS-RPT is één DNS-record op _smtp._tls.uwdomein.be met een adres waarop u rapporten wilt ontvangen. Verzenders die het ondersteunen (waaronder de grote providers) sturen u dan één keer per dag een verslag met per verzendende server hoeveel verbindingen slaagden en hoeveel mislukten, en waarom: certificaat verlopen, servernaam komt niet overeen, STARTTLS niet aangeboden, beleid niet ophaalbaar.
Dat rapport is de reden om met TLS-RPT te beginnen nog vóór u MTA-STS afdwingt. Het vertelt u of er verzenders zijn die uw mail straks níét meer kunnen afleveren als u de modus op enforce zet. Vergelijk het met DMARC: eerst kijken, dan verscherpen. Hoe u dat leest, staat in ons artikel over DMARC-rapportage; de logica is dezelfde.
Hebt u het nodig?
Dat hangt af van welke kant van de verbinding u bekijkt.
Als ontvanger
Ontvangt uw domein gevoelige mail (personeelsdossiers, medische gegevens, juridische correspondentie, betaalinstructies), dan is MTA-STS een goedkope bescherming tegen het onderscheppen van mail onderweg. Voor een domein dat vooral nieuwsbrieven en bestelbevestigingen ontvangt, is de winst kleiner, maar het kost weinig: een DNS-record, een klein statisch bestand op een subdomein met geldig certificaat, en een mailbox voor de rapporten.
Als verzender
MTA-STS op uw eigen domein verandert niets aan de mail die u verstuurt. Wat wél telt: de server waarmee u verstuurt, moet het MTA-STS-beleid van de ontvanger controleren en respecteren, en moet zelf een correct TLS-certificaat hebben. Verstuurt u via een SMTP relay, dan is dat de verantwoordelijkheid van de relay. Vraag het na als u het niet zeker weet: een verzender die het beleid negeert, wordt bij een ontvanger met enforce-modus geweigerd, en dat ziet u dan als bounce.
Een praktisch stappenplan
- Zet het TLS-RPT-record en laat de rapporten enkele weken binnenkomen op een adres dat iemand ook echt leest.
- Publiceer het MTA-STS-beleid in modus testing. Verzenders melden dan afwijkingen in de rapporten maar leveren nog gewoon af.
- Los wat u in de rapporten ziet op: meestal een mailserver die niet in het beleid stond, of een certificaat dat op een andere naam staat.
- Zet de modus op enforce en verhoog het id in het DNS-record.
- Kijk maandelijks naar de rapporten en controleer bij elke wijziging van uw mailservers of het beleidsbestand nog klopt.
Wie een gehost mailplatform gebruikt, vindt de servernamen voor het beleid bij de MX-instellingen van dat platform. Wie zelf mailservers beheert, moet het certificaat van die servers bewaken: een verlopen certificaat betekent met enforce-modus dat externe mail niet meer binnenkomt.
Wat het niet doet
MTA-STS zegt niets over wie mail namens u mag versturen; daarvoor blijven SPF, DKIM en DMARC nodig. Het beschermt ook niet de weg van de ontvangende server naar de mailbox van de lezer, en het versleutelt de inhoud niet op de server zelf. Het sluit één specifiek lek: de onversleutelde terugval tussen twee mailservers.
Veelgestelde vragen
Is MTA-STS verplicht?
Nee. Het is een aanbeveling die de grote providers ondersteunen, geen voorwaarde om af te leveren. Voor sommige sectoren en aanbestedingen wordt het wel steeds vaker gevraagd.
Kan ik MTA-STS zetten als mijn mail bij Microsoft 365 of Google Workspace staat?
Ja. U publiceert het beleid zelf, met de MX-servers van dat platform erin. Beide platformen hebben geldige certificaten op die servers.
Wat als ik enkel verstuur en niets ontvang op dat domein?
Dan heeft MTA-STS voor dat domein weinig zin. Besteed uw tijd dan aan authenticatie en deliverability; dat is waar uw uitgaande mail op beoordeeld wordt.