MTA-STS & TLS-RPT
STARTTLS can be stripped by anyone in the path. MTA-STS closes that hole — if the record, the policy file and your MX records all agree.
DNS record
present
Policy file
fetched
Mode
enforce
TLS-RPT
present
Warnings
- Short max_age (86,400 seconds)A short cache is sensible while rolling out, but once stable it weakens the guarantee: an attacker who blocks the policy fetch only has to wait this long. A week or more is the usual target.
Worth knowing
- Policy lists 2 pattern(s) with no matching MXaspmx.l.google.com, *.aspmx.l.google.com — usually a retired host. Harmless, but worth tidying so the policy stays readable.
Looking good
- Policy is in enforce modeSenders that honour MTA-STS will refuse to deliver over an unauthenticated connection.
- TLS-RPT reporting is configuredDaily summaries of TLS negotiation failures go to mailto:sts-reports@google.com.
- Every MX host is covered by the policyAll 1 MX records match an mx pattern in the policy file.
DNS record
_mta-sts.google.com
v=STSv1; id=20210803T010101;
Policy file
https://mta-sts.google.com/.well-known/mta-sts.txt · 118 bytes
version: STSv1 mode: enforce mx: smtp.google.com mx: aspmx.l.google.com mx: *.aspmx.l.google.com max_age: 86400
MX coverage
Every host that accepts your mail has to match an mx: pattern in the policy. In enforce mode, one that doesn’t is mail that will not be delivered.
| Priority | Host | Covered by policy |
|---|---|---|
| 10 | smtp.google.com | yes |
TLS-RPT record
_smtp._tls.google.com
v=TLSRPTv1;rua=mailto:sts-reports@google.com
Also check this domain’s DMARC & SPF, DKIM keys or the certificates its mail servers present.