MTA-STS och TLS-RPT, förklarat

SPF, DKIM och DMARC skyddar mot e-post som förfalskas i ert namn. MTA-STS skyddar något annat: vägen e-posten tar från avsändarens server till er. Utan det är den vägen bara krypterad så länge ingen lägger sig i.

Därför räcker inte krypteringen mellan e-postservrar.

E-postservrar krypterar sina anslutningar med STARTTLS: den mottagande servern erbjuder kryptering och avsändaren tackar ja. Men erbjudandet skickas oskyddat. En angripare som kan placera sig mellan servrarna kan ta bort det, och då levererar avsändaren i klartext utan något felmeddelande. Avsändaren kan inte heller veta vilket certifikat er server ska visa upp, så även ett förfalskat certifikat godtas.

MTA-STS täpper till båda luckorna. Ni publicerar, över HTTPS, vilka servrar som tar emot er e-post och att de måste nås över TLS med ett giltigt certifikat. En avsändare som stöder MTA-STS vägrar då att leverera på något annat sätt.

Två delar: en TXT-post och en policyfil.

TXT-posten på _mta-sts talar om att det finns en policy, och ger den ett id:

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20261114080000Z"

Själva policyn är en kort textfil på en fast adress under underdomänen mta-sts:

https://mta-sts.example.com/.well-known/mta-sts.txt

version: STSv1
mode: enforce
mx: mail1.example.com
mx: mail2.example.com
max_age: 604800

• mode är testing, enforce eller none. I läget testing rapporterar avsändarna fel men levererar ändå; det är bara enforce som skyddar något.
• mx listar servrarna som får ta emot er e-post, en per rad. De måste täcka alla värdar i era MX-poster. Ett jokertecken som *.example.net matchar precis en etikett längst till vänster.
• max_age är hur länge, i sekunder, avsändarna sparar policyn. RFC 8461 tillåter upp till 31 557 600 (ett år) och räknar med veckor eller mer vid normal drift.
• id i TXT-posten är högst 32 bokstäver och siffror. Datum och tid fungerar bra. Avsändarna hämtar policyn på nytt när id ändras eller när deras sparade kopia går ut.

Filen måste levereras över HTTPS med ett giltigt certifikat för mta-sts. följt av er domän, utan omdirigeringar: RFC 8461 förbjuder avsändarna att följa dem.

TLS-RPT: få veta när leveransen misslyckas.

TLS-rapportering är en enda TXT-post på _smtp._tls. Den ber avsändande servrar att skicka en daglig sammanställning av sina anslutningar till er domän, även de som misslyckades:

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

Rapporterna kommer som komprimerad JSON, oftast en per avsändande organisation och dygn. De anger orsaken till varje fel, till exempel starttls-not-supported, certificate-expired, certificate-host-mismatch eller sts-policy-fetch-error. Utan dem syns varken ett trasigt certifikat eller en attack mot er e-post; med MTA-STS i läget enforce är de också första tecknet på att viss e-post inte kommer fram.

Inför det i fyra steg.

1. Publicera TLS-RPT. Det ändrar ingenting i leveransen, så det är säkert från första dagen.
2. Publicera policyn i läget testing, med ett kort max_age, till exempel 86400 (ett dygn), och därefter TXT-posten på _mta-sts.
3. Läs rapporterna i några veckor. Åtgärda varje fel från en server som ska ta emot er e-post: ett certifikat som inte stämmer med värdnamnet, ett utgånget certifikat eller en MX-värd som saknas i policyn.
4. Byt till enforce och höj max_age till en vecka eller mer. Ändra policyfilen först och id sedan, så att ingen avsändare sparar en gammal policy.

Både Google Workspace och Microsoft rekommenderar att börja i läget testing. Microsofts guide för Exchange Online ger en färdig policy för domäner vars MX pekar på Exchange Online (mx: *.mail.protection.outlook.com), och varnar för att jokertecknet gäller just deras tjänst och inte ska kopieras för andra leverantörer. Microsoft skriver också att Exchange Online inte kan lagra policyfilen åt er, så den behöver en liten egen HTTPS-webbplats på underdomänen mta-sts.

När något ändras.

• Byte av e-postleverantör: lägg till de nya MX-värdarna i policyn (filen först, sedan ett nytt id) innan ni ändrar MX-posterna, och ta bort de gamla först efter flytten.
• Något går sönder i läget enforce: byt policyn till testing och ändra id. Avsändarna slutar tillämpa den så snart de hämtar den igen, och rapporterna fortsätter komma.
• Ta bort MTA-STS: publicera mode: none med ett kort max_age och ett nytt id, vänta tills det gamla max_age har passerat och ta sedan bort TXT-posten och policyfilen.

Vanliga misstag.

• En policy som blir kvar i läget testing. Den rapporterar, men skyddar ingenting.
• En MX-värd som saknas i policyn, ofta en reservserver eller en värd som lagts till senare. I läget enforce levererar avsändarna inte till den.
• Policyfilen ändras utan nytt id. Avsändarna behåller den gamla policyn tills dess max_age har gått ut.
• En omdirigering eller ett saknat certifikat på mta-sts., till exempel när underdomänen pekar på en webbplats som skickar besökaren vidare. Avsändarna behandlar då policyn som otillgänglig.
• Att börja tillämpa policyn innan rapporterna har lästs.

Det här kontrollerar TrustSek.

Kontrollen läser era poster på _mta-sts och _smtp._tls och hämtar policyfilen för att läsa läget. Den försöker inte leverera e-post.

En domän utan MTA-STS-policy ger inget fynd i kontrollen. Båda kontrollerna gäller bara domäner som tar emot e-post, så en domän utan MX-poster, eller med en null-MX, bedöms inte på dem. Ni kan läsa alla tre posterna för valfri domän med den kostnadsfria MTA-STS- och DNSSEC-kontrollen. De ingår i modulen för e-postsäkerhet, tillsammans med DKIM, SPF och DMARC.

Frågor

Skyddar MTA-STS e-posten jag skickar?

Nej. Den skyddar e-post som skickas till er domän. Om er utgående e-post är skyddad beror på mottagarens policy och på att er leverantör följer den. Både Exchange Online och Gmail gör det när de skickar.

Kan läget enforce stoppa legitim e-post?

Bara från avsändare som stöder MTA-STS, och bara när er server inte klarar kontrollen: ingen TLS, ett ogiltigt certifikat eller en värd som policyn inte listar. Avsändare utan stöd för MTA-STS levererar som tidigare. Därför kommer testperioden med TLS-rapporter först.

Kräver MTA-STS DNSSEC?

Nej. Det bygger på HTTPS och vanliga webbcertifikat i stället. DANE för SMTP (RFC 7672) gör samma jobb med DNSSEC-signerade poster. En domän kan publicera båda.

Skyddas det första meddelandet till en ny mottagare?

Inte helt. En avsändare som aldrig har hämtat er policy har ännu inget att tillämpa, så skyddet börjar när policyn har sparats. Därför spelar ett långt max_age roll när ni väl tillämpar policyn.

Kontrollera er domäns e-postsäkerhet

Se om er domän tillämpar MTA-STS och rapporterar TLS-fel, tillsammans med DMARC, SPF och resten av bedömningen utifrån.

Er domän

Kontrollera er domän

Gratis, inget konto behövs. Tar ungefär 30 sekunder.