MTA-STS DNS record is malformed
What this check looks for
The DNS record that announces your MTA-STS policy cannot be read, so senders never look for the policy file. The protection is switched off even though the policy is published.
Why it matters
Everything downstream of this record is ignored: the policy file could be perfect and no sender would ever fetch it.
When the check passes, your report says: “The MTA-STS DNS record is well formed, so senders find the policy”.
What it costs your score
When this check fails it removes 10 points from your Email transport score, before the status, confidence and repeat multipliers are applied. Email transport carries a weight of 8 in the overall score.
It shares the email-transport.mta-sts family ceiling of 25 points: however many findings that family produces, together they cannot remove more than that from Email transport. One underlying problem showing up in several places is still one problem.
- Severity
- high
- Default confidence
- confirmed
- Status when triggered
- fail
- Deduction
- 10 points
- Family cap
- email-transport.mta-sts · 25
- Category
- Email transport
- Module
- Email mta sts
- Fix owned by
- user
- In the ruleset since
- 2026.09
How to fix it
Republish a single, valid _mta-sts TXT record.
Senders that cannot parse the record never fetch the policy, so no delivery is protected.
Publish exactly one TXT record at
_mta-sts.‹domain›in the formv=STSv1; id=<value>.Delete any other TXT record at that name.
Change the
idvalue every time you change the policy file — that is how senders learn to re-fetch it.
How to confirm it worked
dig +short TXT _mta-sts.‹domain› — expect exactly one record starting v=STSv1
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
Parsing _mta-sts.‹domain› failed: ‹parse error›. RFC 8461 §3.1 requires a single TXT record beginning with v=STSv1 followed by an id= tag of 1-32 alphanumeric characters. Two common faults are more than one TXT record at the name (the record set is then ignored) and an id that is never changed, which leaves senders caching a policy long after it was replaced.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.