dotvitals

No MTA-STS policy published

MediumConfirmedemail.mta-sts.no-record

What this check looks for

Mail sent to your domain is encrypted only if the sending server happens to try. An attacker positioned on the network can strip that encryption and read the messages, and nothing detects it.

Why it matters

MTA-STS is what lets you insist that mail to your domain is delivered over TLS to a server you named. Without it, encryption of inbound mail is best-effort and silently downgradable.

When the check passes, your report says: “MTA-STS is published, so senders must encrypt mail to you”.

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
medium
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 the whole score is calculated

How to fix it

Publish an MTA-STS policy, starting in testing mode.

Until you do, inbound mail can be downgraded to plaintext by anyone on the network path.

  1. Generate the policy file listing your current MX hosts.

  2. Host it at https://mta-sts.‹domain›/.well-known/mta-sts.txt with a valid certificate for that hostname.

  3. Publish v=STSv1; id=<timestamp> at _mta-sts.‹domain›.

  4. Start with mode: testing and pair it with TLS-RPT so you see failures before they block mail.

  5. After a few weeks of clean reports, change the mode to enforce and update the policy id.

How to confirm it worked

  • dig +short TXT _mta-sts.‹domain› — expect a v=STSv1 record

  • curl -s https://mta-sts.‹domain›/.well-known/mta-sts.txt — expect the policy file

The configuration to publish
_mta-sts.{{domain}}. 3600 IN TXT "v=STSv1; id={{policyId}}"

# https://mta-sts.{{domain}}/.well-known/mta-sts.txt
version: STSv1
mode: testing
mx: {{mxHost}}
max_age: 604800

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.

Remediation by platform

Cloudflare Pages
Create a Pages project serving a single file at /.well-known/mta-sts.txt with Content-Type: text/plain, then add a CNAME for mta-sts.‹domain› pointing at it.
nginx
server {
  listen 443 ssl;
  server_name mta-sts.‹domain›;
  location = /.well-known/mta-sts.txt {
    default_type text/plain;
    alias /var/www/mta-sts/mta-sts.txt;
  }
}
Technical detail

No TXT record was found at _mta-sts.‹domain›. Per RFC 8461 §3.1, MTA-STS requires both that record and a policy file served at https://mta-sts.‹domain›/.well-known/mta-sts.txt. Without a policy, SMTP STARTTLS remains opportunistic: an active attacker removes the STARTTLS capability from the server greeting and the sender delivers in plaintext.

Standards and references

Test this on your domain

Run the check that produces this finding, on its own, against any domain.

Open the email mta sts checkerBuild the fix

Other email mta sts checks