What the standard says
NIST’s email security guidance recommends encrypting mail as it moves between servers, alongside SPF, DKIM and DMARC for proving who sent it [1]. Mail servers do this with STARTTLS, a step where two servers agree to switch an ordinary connection to an encrypted one [2]. On its own, that’s a high barrier against someone quietly listening in [2]. The weak spot is that it’s opportunistic: servers encrypt if both sides offer it, and Microsoft notes it’s commonly used that way rather than required [3]. Someone sitting in the path can delete the “I support encryption” offer or redirect the connection, which is called a downgrade attack [2].
Three optional settings close that gap.
MTA-STS (Mail Transfer Agent Strict Transport Security) is a published policy that tells sending servers to require encryption and a valid certificate when they deliver to you. You publish a short DNS record named _mta-sts and a small text file on a web address starting with mta-sts. [2] In enforce mode, senders that support it won’t deliver over a connection that fails those checks [2]. Exchange Online checks other domains’ policies automatically on outgoing mail, and you can publish a policy for your own domain, but Microsoft can’t host the policy file for you [4]. Google Workspace supports it too, and Gmail honors other domains’ enforced policies when sending [5].
TLS-RPT (SMTP TLS Reporting) is a DNS record named _smtp._tls that asks sending servers for daily reports on how many encrypted deliveries to you succeeded or failed [6]. The reports help spot both attacks and honest misconfigurations [6]. Google recommends adding TLS reporting first, then MTA-STS [7].
DNSSEC (DNS Security Extensions) adds digital signatures to your DNS records so other servers can check the answers really came from you [8]. If a signature doesn’t check out, the server throws the answer away and returns an error instead [8]. It proves answers are genuine; it doesn’t hide them [8]. The domain owner has to turn it on with their DNS provider, and the matching key information usually goes to the parent zone through the registrar [8].
DNSSEC also unlocks DANE (DNS-based Authentication of Named Entities), which Microsoft supports for mail coming into Exchange Online [3]. Microsoft says DANE and MTA-STS serve the same purpose; DANE relies on DNSSEC, while MTA-STS relies on regular certificate authorities [3].
What you’ll hear
“Your email isn’t encrypted without these.”
That’s not quite right. Most mail between servers is already encrypted with STARTTLS when both sides support it [2]. What MTA-STS adds is a guarantee: senders won’t quietly fall back to an unencrypted connection [2]. The fair version: these settings make encryption required, not possible.
“Turn on DNSSEC everywhere today.”
The instinct is right; signed DNS answers can’t be forged [8]. But signing has to stay correct. Microsoft lists a broken chain between the registrar and DNS provider, and expired signatures, as common DNSSEC failures that cause incoming mail to be held, and its fix is to turn DNSSEC off at the DNS provider [3]. Do it carefully, with a plan, not in a rush.
What the numbers say
We couldn’t find a reliable public statistic from a standards body or vendor on how many small businesses use MTA-STS, TLS-RPT or DNSSEC. Instead, here are the numbers the standards and platforms actually publish:
3 modes: an MTA-STS policy can be set to enforce, testing (report problems but still deliver) or none (turn it off) [2].
31,557,600 seconds, about one year: the longest a sending server may remember your MTA-STS policy [2]. Microsoft’s example testing policy uses one week [4].
1 day: the period each TLS-RPT report covers, midnight to midnight UTC [6].
Up to 24 hours: how long Google says DNS changes for these records can take to take effect [7].
About 24 hours: how long Exchange Online keeps retrying mail that fails DANE checks before sending it back [3].
What we’ve seen
We haven’t run into this yet.
Putting it together
These settings fill a narrow gap: making sure mail to you can’t be quietly downgraded and your DNS can’t be forged. They matter most once SPF, DKIM and DMARC are solid. Start MTA-STS in testing mode with TLS reporting on, and treat DNSSEC as a planned change with your DNS provider.
What good looks like
SPF, DKIM and DMARC done first.
A TLS-RPT record sending reports to a mailbox someone actually reads.
An MTA-STS policy that starts in testing mode and moves to enforce after a few clean weeks of reports.
The MTA-STS policy file hosted somewhere reliable, with its certificate kept current.
DNSSEC turned on only where the registrar and DNS provider both support it, with a written plan for changing providers.
Questions for your IT resource
Are SPF, DKIM and DMARC set up and passing for our domain?
Do our registrar and DNS provider support DNSSEC, and are they the same company?
Where would we host the MTA-STS policy file, and who renews its certificate?
Who would read TLS reports, and how often?
If we turn on DNSSEC, what’s the plan if we ever move DNS providers?
Related learning
What is DMARC?
DMARC is a DNS record that tells other mail servers what to do with email that claims to come from your domain but can’t prove it.
What is SPF, and why one record matters
SPF is a DNS record that lists the servers and services allowed to send email for your domain. Receiving mail servers check it to decide whether a message really came from someone you approved.
Who holds the keys to your domain and website?
Your domain registrar, DNS provider and web host each have a login, and whoever holds those logins controls your website and where your email is delivered. Give each one its own strong password, turn on MFA, and know who has access.
Sources
NIST, SP 800-177 Rev. 1, Trustworthy Email, February 2019. (checked 2026-10-08)
IETF, RFC 8461: SMTP MTA Strict Transport Security (MTA-STS), September 2018. (checked 2026-10-08)
Microsoft, How SMTP DNS-based Authentication of Named Entities (DANE) works, Microsoft Learn. (checked 2026-10-08)
Microsoft, Enhance mail flow with MTA-STS, Microsoft Learn, updated July 2026. (checked 2026-10-08)
Google, About MTA-STS and TLS reporting, Google Workspace Help, updated October 2026. (checked 2026-10-08)
IETF, RFC 8460: SMTP TLS Reporting, September 2018. (checked 2026-10-08)
Google, Turn on MTA-STS and TLS reporting, Google Workspace Help, updated October 2026. (checked 2026-10-08)
ICANN, DNSSEC: What Is It and Why Is It Important?, ICANN. (checked 2026-10-08)
How we rate these. Our judgment from real setups, applied the same way on every page. Cost: $ = no new spend or under $25/month · $$ = a modest monthly tool or a short project · $$$ = new hardware, licensing, or a larger project. Effort: Light = one sitting · Moderate = setup plus follow-up over days or weeks · Heavy = planning, testing and staff changes. Outlined marks show how far it can go for some businesses. N/A = doesn’t apply to this topic. Time to fix: how long the first useful step takes, then how long until it’s fully done. Ratings are typical averages, not quotes. Time to fix: the filled dot is when the first useful step lands, the hollow dot is when it’s fully done. Who can do it: highlighted chips are who can reasonably handle it.