MTA-STS checker
Mail between servers is encrypted when both sides agree to it, and an attacker in the middle can make them not agree. MTA-STS is how a domain says that its mail must arrive encrypted or not at all. Check a domain you control and see whether the policy is published and whether it is enforced.
Watched, not just checked
This is one scan of one layer, run once. In AYAsec the same check runs on a schedule across every asset you own, and you are told the day a grade drops.
What MTA-STS is, in one paragraph
When one mail server delivers to another, it starts in plain text and asks to switch to TLS. An attacker who sits in the path can remove that request, and the two servers carry on unencrypted without anybody noticing. MTA-STS closes that gap. Your domain publishes a short TXT record and a policy file on a web address of its own; a sending server that supports it fetches the policy, remembers it, and then delivers only to the mail servers named in it and only over a TLS connection with a valid certificate.
Five reasons to check your own MTA-STS
01
Encryption that an attacker can switch off is not encryption
Opportunistic TLS protects against someone reading mail passively. It does not protect against someone who is willing to interfere, because the downgrade is silent. MTA-STS is the control that turns "usually encrypted" into "refused unless encrypted".
02
The record alone does nothing
The TXT record only tells senders that a policy exists. The policy itself lives at https://mta-sts.yourdomain/.well-known/mta-sts.txt, and it has to be reachable, with a valid certificate on that name. A record without a working policy file is the commonest way to think you are protected when you are not.
03
Testing mode is a starting point, not a destination
A policy has a mode: none, testing or enforce. In testing mode senders still deliver when the check fails and only report it. That is the right way to begin, and many domains stay there for years. Only enforce stops a downgraded delivery.
04
A policy that lists the wrong mail servers refuses your own mail
The policy names the MX hosts allowed to receive mail for the domain. Move to a new mail provider without updating it and senders that enforce the policy will not deliver to the new servers at all. This is also the risk of a long max_age: a wrong policy stays cached by senders for as long as you promised.
05
TLS-RPT is how you find out
TLS reporting is a second TXT record that tells senders where to send daily reports about delivery failures and policy problems. Without it an enforced policy fails in silence, and the first sign of a problem is a customer whose mail never arrived.
Know the day your policy changes
An MTA-STS setup is a record, a web address, a certificate and a list of mail servers, and each of them has a different owner.
Scheduled scans turn that into a difference you are told about: the policy file stopped loading, the certificate on the policy name expired, the mode went from enforce back to testing. Alerts arrive in-app, by e-mail, or through Slack, Teams, Jira or a webhook.
Step 01
Name the domain
A domain you control, added to your AYAsec account. Ownership is checked before anything is dispatched - AYAsec will not schedule scans against infrastructure you have not demonstrated control of, and proving it takes one DNS record. The quick check above skips this: no account, no verification, just IP rate-limiting and a rule that the target has to be a public address.
Step 02
Let the check run
The record and the policy file are public, so this reads rather than probes. It fetches them the way a sending mail server would.
Step 03
Read the result
Findings arrive ordered by severity and scored A+ to F. A missing policy and a policy in testing mode are not sitting in the same undifferentiated list.
What this is part of
MTA-STS is one of several mail-related records AYAsec checks as part of its DNS scan, alongside SPF, DKIM, DMARC, TLS-RPT and DNSSEC. It is one scan, and this page is about one part of what it looks at.
DNS carries 20% of the composite grade. The others are HTTP at 30%, TLS and ports at 20% each, and domain credibility at 10%. All of them together are what attack surface management means in practice.
Questions before you check
What may I check?
Infrastructure you own or are contracted to test. The quick check above doesn't verify that for you - it only rate-limits by IP and refuses to target anything but a public address. Add the domain to an AYAsec account instead, and control is verified before anything scheduled runs: a legal boundary as much as a practical one, since an unverified scan is of no use to you as evidence either.
MTA-STS is public. Why does this need verification?
The record and the policy are public and the check is read-only, so the check itself is harmless. Verification is about what happens next: a domain in your AYAsec account is monitored, graded and kept in your history, and none of that should be possible for a domain that is not yours.
Does MTA-STS protect mail that I send?
No. It protects mail sent to your domain. Whether a message you send is protected depends on the policy of the receiving domain and on your own mail server honouring it.
What is the difference between MTA-STS and DANE?
Both aim at the same downgrade problem. DANE depends on DNSSEC and publishes the certificate in DNS; MTA-STS relies on a policy over HTTPS and an ordinary certificate. MTA-STS is simpler to deploy and is supported by the large providers.
How do I move safely from testing to enforce?
Publish the policy in testing mode with TLS-RPT switched on, read the reports for a few weeks, fix what they show - usually a certificate or an MX name that does not match - and only then change the mode and raise max_age.
Do you keep the results?
Not the quick check above - it lives in memory for about fifteen minutes so you can read it once, then it's gone. That's a deliberate privacy choice, not a limitation: nobody but you ever sees that scan, and you can download the full result before it expires. Add the domain to an AYAsec account instead, and every scan is kept - a series that tells you which edit broke it. Retention depends on your plan.
Keep the history, not just the result
Run the full DNS check against your own domains, on a schedule, with every change flagged to whoever needs to see it.