DANE and MTA-STS
Enforced SMTP encryption, no compromise

SMTP was built without encryption, and it shows

SMTP dates back to 1982. Transport encryption was bolted on much later, in 2002, with the StartTLS extension — and in opportunistic mode: two mail servers will only encrypt the session if both advertise support. If the negotiation fails, or if an on-path attacker strips the STARTTLS line from the server response, the two MTAs silently fall back to plaintext.

That is the downgrade attack: the message is delivered, the user gets no warning, but the contents — password resets, invoices, contracts, confidential data — travel readable over the public Internet. Italian PEC has the same exposure on the SMTP-to-SMTP segment outside the PEC circuit, and any ordinary business email flow is at risk.

SPF, DKIM and DMARC solve a different problem: they prove that the sender is authorised and that the message has not been altered. They do not stop the message from being read in transit. What is needed are additional protocols that make encryption mandatory and verifiable: MTA-STS and DANE.

MTA-STS: policy over HTTPS

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) is the practical answer. The recipient domain publishes a policy that tells sending servers: «when you send me mail, you must use TLS with one of these mail servers and a valid certificate». The policy has three components:

• 1TXT record — _mta-sts.example.com declares the policy version and changes whenever the policy is updated, so that sending servers know when to re-fetch the file.
• 2HTTPS policy file — published at https://mta-sts.example.com/.well-known/mta-sts.txt, listing the authorised mail servers and the enforcement level (none, testing, enforce). Policy validation relies on the public HTTPS PKI: no DNSSEC required.
• 3TLS-RPT (RFC 8460)— a dedicated TXT record pointing to a reporting address where sending servers send daily reports of TLS-related delivery failures. Without TLS-RPT you are flying blind, and switching MTA-STS to enforce is risky.

The standard rollout is: start in testing, collect TLS-RPT reports for two or three weeks, fix any mismatch between DNS records and certificates, and only then switch to enforce. In enforce, compliant sending servers will refuse delivery if encryption cannot be established or if the certificate does not match one of the declared mail servers.

DANE for SMTP: anchored in DNS

DANE (DNS-based Authentication of Named Entities, RFC 7672 for SMTP) tackles the same problem from a different angle. Instead of publishing the policy over HTTPS, DANE publishes a DNS record of type TLSA that directly binds the certificate (or its public key) to the mail server name. When a sending MTA is about to open a TLS connection to the recipient, it fetches the TLSA record and verifies that the presented certificate matches.

The catch: the TLSA record must be signed with DNSSEC, otherwise any intermediate resolver could tamper with it. DANE for SMTP requires DNSSEC end-to-end on the recipient domain and on the domains of its mail servers (MX records). That is the main brake on adoption: in Italy DNSSEC is still poorly deployed and not all registrars support it without manual activation.

When it is in place, DANE is technically more robust than MTA-STS: it does not depend on the public HTTPS PKI (which has had its share of historical compromises), and it does not require the sending server to make a separate HTTPS request to fetch the policy. Everything happens at the DNS layer.

What changed: Exchange Online enables outbound DANE

Microsoft brought outbound SMTP DANE with DNSSEC into general availability in Exchange Online in early 2025. In practice: every Microsoft 365 tenant that sends mail to external domains with valid TLSA records now has encryption enforced and verified by Microsoft. If the recipient certificate does not match the TLSA record, delivery fails with an explicit NDR instead of silently falling back to plaintext.

Inbound support (the ability for an Exchange Online tenant to publish its own TLSA records for Microsoft mail servers) is still on the roadmap. MTA-STS, on the other hand, has been supported in both directions for several years: Microsoft 365 tenants can publish their MTA-STS policy and Microsoft mail servers honour the MTA-STS policies of recipients.

Google Workspace has comparable MTA-STS support in both directions and supports outbound DANE. The practical consequence is that most of the world's email traffic today honours MTA-STS and DANE on outbound: publishing at least an MTA-STS policy for your own domain is no longer a theoretical exercise — it is real protection.

A sensible rollout path for your organisation

For almost every organisation, the practical order is:

• First: SPF, DKIM and DMARC— the prerequisite for everything else. Without proper email authentication, MTA-STS and DANE only solve half the problem. You can verify them with our DIG online tool or have them managed by our email security service.
• Next: MTA-STS with TLS-RPT— low complexity, high return. Publish a TXT record, an HTTPS policy file and a TLS-RPT record. Start in testing for two or three weeks and switch to enforce once the reports are clean.
• Then: evaluate DANE— it makes sense if the domain already runs DNSSEC or if the organisation has elevated security requirements (public sector, healthcare, finance, NIS2 supply chain). For many domains the first step is enabling DNSSEC through their DNS management service.
• In parallel: an email security gateway— MTA-STS and DANE protect the transport, not the content. Phishing, BEC and malicious attachments still flow through encrypted connections. For that you need an email security gateway.

Pitfalls to avoid

Three recurring mistakes we regularly see on real domains:

• Publishing MTA-STS straight in enforce without a testing phase and without TLS-RPT. Result: when a mail server certificate expires or rotates, inbound mail from Gmail and Microsoft 365 is rejected for days before anyone notices.
• Publishing TLSA records without DNSSEC enabled. The record exists, but sending servers ignore it because it is unsigned. The protection is only apparent.
• Forgetting to update the TLSA record at certificate renewal. If TLSA points to the certificate hash and the certificate changes, TLS connections are rejected. Pre-publication and rotation of the new TLSA record must be planned ahead of the renewal.

How AtWorkStudio handles deployment

The standard email stack on the domains we manage includes SPF, DKIM, DMARC, MTA-STS, TLS-RPT and BIMI. For clients who want to go further with DANE we first enable DNSSEC (compatibility with their registrar and DNS provider permitting), publish TLSA in 2 1 1 mode with pre-publication of the new record ahead of certificate renewal, and set up continuous monitoring of TLS-RPT reports.

AtWorkStudio has been operating from Piacenza, Italy since 2000. We hold ISO/IEC 27001, 27017, 27018 and ISO 9001 certifications, with ACN (Italian National Cybersecurity Agency) qualification for our cloud services. We are members of Clusit (Italian Association for Information Security) and affiliated with Confindustria Piacenza in the RICT cluster.

Frequently asked questions