Which provider supports DANE and MTA-STS? Overview of all 27 hosts
Which email provider supports DANE and MTA-STS? Complete overview of all 27 hosts with detailed reasoning and direct guides.
Last updated: July 2026
In short: Transport layer security protects your emails against downgrade and MitM attacks. While almost all 27 providers in our matrix support the foundational SPF, DKIM, and DMARC mechanisms, inbound DANE is only possible with 3 providers (Mailcow, Microsoft 365, Infomaniak), and managed MTA-STS is supported by only 3 providers (Google Workspace, Mailcow, Microsoft 365). Below is the comprehensive comparison of all 27 providers with detailed explanations.
While SPF, DKIM, and DMARC ensure that senders cannot be forged and messages arrive intact, DANE and MTA-STS protect the transport layer (SMTP) between participating mail servers. They enforce an encrypted TLS connection and prevent man-in-the-middle (MitM) and downgrade attacks.
Whether you can deploy these modern transport security standards depends directly on your email hosting provider and its underlying technical architecture. Our provider hub reveals that typical shared hosts lack the necessary infrastructure—such as DNSSEC-signed TLSA records on their shared mail servers or an HTTPS certificate for the required policy subdomain.
Complete table: DANE and MTA-STS across all 27 providers
The table below lists the exact status of all 27 providers in our technical matrix for inbound DANE (via TLSA records) and managed MTA-STS (via policy hosting and DNS records).
Technical breakdown and architecture analysis
1. Why most shared hosts cannot offer DANE
For inbound DANE to work, the official mail servers of your hosting provider (e.g., at IONOS, Strato, All-Inkl, or OVHcloud) must be signed with DNSSEC and publish valid TLSA records in DNS that bind their TLS certificates. As explained in our guide DANE for email: who can use it, large shared hosting providers currently do not publish TLSA records for their shared mail exchangers (MX):
- IONOS, Strato, All-Inkl, checkdomain, domainfactory, united-domains: The official mail servers lack TLSA records (
MX has no TLSA; see overview). Deploying DANE for customer domains on these shared MX clusters is technically impossible. - Gandi, OVHcloud, GoDaddy, o2switch, LWS, DonDominio, Dinahosting, cdmon, Raiola Networks, Hostinger, webgo, dogado: Similarly, these providers do not maintain TLSA records on their default mail servers (
MX has no TLSA; see overview). - one.com: While the mail server pods publish TLSA records, because the zone is unsigned (no DS record present), DANE remains ineffective (
MX pods publish TLSA but zone is unsigned). - Hetzner DNS, Netcup, Cloudflare, Amazon Route 53: As DNS specialists (or when using only DNS zones without managed mailboxes), these providers provide full DNSSEC and TLSA support in their DNS control panels. However, because they do not operate managed mailboxes for your domain, DANE is only applicable when you operate your own dedicated mail server (
only via own MX; see overview).
2. Why Google Workspace and Microsoft 365 take different approaches
The two major cloud email platforms diverge significantly on transport layer security:
- Microsoft 365 (Exchange Online): Microsoft supports both inbound DANE and MTA-STS. You can enable DANE for your custom domain using DNSSEC and PowerShell commands (DANE/DNSSEC setup at Microsoft 365). At the same time, Microsoft offers full support for managed MTA-STS (MTA-STS at Microsoft 365).
- Google Workspace: Google does not publish TLSA records for its standard mail exchangers (
no inbound DANE; uses MTA-STS (see overview)). Instead, Google relies entirely on MTA-STS as its primary standard for enforcing encrypted transport (MTA-STS setup at Google Workspace).
3. Why managed MTA-STS is impractical on most shared hosts
MTA-STS requires more than just a DNS TXT record; it also requires a policy text file (mta-sts.txt) hosted precisely at the subdomain mta-sts.yourdomain.com over HTTPS with a valid SSL/TLS certificate. As detailed in MTA-STS at shared hosts, this presents a major operational hurdle on standard shared hosting environments (no managed MTA-STS; see mta-sts-shared-hosting):
- Providers such as IONOS, Strato, All-Inkl, Netcup, OVHcloud, Hostinger, one.com, and dogado do not provide an automated service to host and maintain this policy subdomain and its certificate.
- To deploy MTA-STS on these shared platforms, you must manually create a dedicated subdomain, assign web hosting, and maintain the SSL certificate, or rely on third-party policy hosting services.
4. Self-hosted servers: Complete control with Mailcow
When you require maximum transport security and want to run both DANE and MTA-STS concurrently, running your own mail server is the most complete solution.
With Mailcow, you operate your own containerized mail suite. Because you maintain full administrative control over the DNS zone and the TLS certificates on your MX server (mail.yourdomain.com), Mailcow automatically generates the exact TLSA records needed for DANE and serves the full policy for MTA-STS directly from its UI (MTA-STS with Mailcow).
Verify your configuration with Kuveris
No matter which hosting provider or transport standard you select, always verify your domain configuration using the free Kuveris scanner after making DNS updates. The scanner performs an instant analysis of your entire email security stack—checking SPF, DKIM, DMARC, and verifying immediately whether your domain has valid DANE TLSA records and a working MTA-STS policy.
Further reading
- RFC 6698 — DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA (retrieved: July 17, 2026)
- RFC 8461 — SMTP MTA Strict Transport Security (MTA-STS) (retrieved: July 17, 2026)
- DANE for email: who can use it — Comprehensive guide to TLSA and DNSSEC requirements
- MTA-STS at shared hosts — Technical analysis of HTTPS policy hosting on shared platforms
- Email-security setup guides by provider — Overview of all 27 providers and step-by-step setup guides