Why Email Delivery Fails Even When You’re Doing Everything Right

You’ve set up SPF, DKIM, and DMARC. Your bounce rate is low. Your open rates are solid. And yet, some emails still vanish into the void—or end up in spam folders without warning.

That’s not a fluke. It’s often the result of a gap in the email delivery chain: the SMTP transport layer. Even with strong authentication, a single misstep in how mail is actually transmitted can break delivery before it starts.

DANE and MTA-STS are two standards built to close that gap—but they work in fundamentally different ways, and understanding the difference is key to consistent inbox placement.

Key takeaways

  • DANE and MTA-STS address different layers of SMTP security: DANE protects the transport layer via TLS certificates, while MTA-STS enforces TLS use through policy.
  • MTA-STS is widely adopted but requires strict configuration and fails gracefully if missing; DANE is more robust but less common due to DNS complexity.
  • Neither standard replaces proper email authentication, but both reduce the risk of man-in-the-middle attacks during delivery—critical for reliable inbox placement.

What Is DANE for SMTP? How It Secures Your Email Transport

DANE (DNS-Based Authentication of Named Entities) uses DNSSEC to verify that the TLS certificate presented by an incoming mail server during an SMTP handshake is legitimate and issued for the correct domain. It eliminates reliance on third-party certificate authorities by letting you control trust via DNS records. Without DNSSEC in place, DANE cannot function — it's a dependency, not a workaround.

How DANE Works in Practice

When your server connects to another mail server via SMTP, it checks the receiving server’s TLS certificate. Normally, this trust is managed by a certificate authority. With DANE, you instead publish a cryptographic hash of the certificate in your DNS records using a TLSA record. The receiving server uses DNSSEC to validate that this record is genuine and matches the certificate it receives. If it doesn't, the connection is dropped.

This means you’re not just trusting a CA — you’re trusting a DNS record you control. It prevents man-in-the-middle attacks where an attacker presents a forged certificate. DANE is especially valuable for organizations that send sensitive or high-volume email — it directly strengthens transport security at the protocol level.

Why DNSSEC Is Non-Negotiable

DANE only works if DNSSEC is active on the domain’s DNS zone. DNSSEC signs the DNS records to prevent spoofing and tampering. If DNSSEC isn’t configured, an attacker could alter the TLSA record, and DANE can’t detect it because it lacks the cryptographic integrity check.

Many domains don’t enable DNSSEC, which limits DANE adoption. But for those that do, it’s a powerful layer of protection. The IETF’s RFC 6698 defines DANE, and major mail providers (like Gmail) support it when available. Still, it’s not widely deployed — and not always necessary for basic deliverability.

For most businesses, the primary concerns are correct SPF, DKIM, and DMARC configuration. DANE sits at the edge of this stack, offering transport-level hardening. You can’t enforce DANE on external domains, but you can use it for outbound sends to domains that support it.

If you’re managing sender reputation, inbox placement, or trying to reduce delivery risks, validating your own domain’s configuration is crucial. You can check for issues in your DNS and email infrastructure with tools like bulk verification or inbox placement testing, both of which help spot configuration gaps early.

How MTA-STS Works: A Simpler Alternative to DANE

MTA-STS is a DNS-based protocol that forces email servers to use TLS encryption when sending mail to a domain, bypassing optional or weak TLS settings. It uses a published policy file in DNS (via a TXT record) to tell your mail server: “only connect securely, no matter what.” This makes it simpler and more practical than DANE, which relies on complex PKI infrastructure. Unlike DANE, MTA-STS doesn’t require certificates to be signed by a specific trusted authority, reducing setup friction and making it widely adoptable.

How the Policy Works in Practice

When your email server sends mail to a domain with MTA-STS enabled, it checks the domain’s DNS for a policy TXT record. That record tells the sending server, “This domain only accepts TLS-secured connections.” Even if the receiving server advertises unencrypted delivery, your server will refuse to connect unless TLS is enforced. This stops downgrade attacks and ensures your messages always arrive encrypted in transit.

Let’s say you’re sending to example.com. Your MTA first looks up mta-sts.example.com in DNS. If it finds a valid policy, it applies the rules—like requiring TLS v1.2 or higher—before proceeding. The policy can also specify a reporting endpoint, so your server can log any failures or unexpected connection attempts.

Because MTA-STS policies are published in DNS and updated by domain owners, they’re easy to maintain. As of 2022, over 50% of the top 100 email domains supported MTA-STS, according to a IETF draft and adoption data from major email providers. It’s now a recommended practice in industry-standard guidance from organizations like the Email Security Group.

Unlike DANE, which uses DNSSEC to validate certificates and requires complex certificate validation chains, MTA-STS focuses only on transport encryption. You don’t need to manage certificate chains or trust anchors. This simplicity makes it far easier to deploy at scale, especially for businesses with multiple outbound sending sources.

If you’re managing email lists and want to ensure your emails are being sent securely, you can verify delivery infrastructure with tools that test both encryption and deliverability. For example, you can test inbox placement to see if your messages are reaching inboxes with proper encryption, or use our API to validate recipient domains before sending. These tools help you identify domains that don’t enforce TLS, even if they appear valid otherwise.

DANE vs MTA-STS: The Core Difference in How They Operate

You're choosing between DANE and MTA-STS to secure your email transport: DANE cryptographically validates TLS certificates using DNSSEC, making it stronger but harder to deploy; MTA-STS enforces TLS encryption without DNSSEC, which is easier to implement but only guarantees encryption, not certificate authenticity. MTA-STS is widely adopted today; DANE remains niche due to DNSSEC complexity.

DANE: Certification Authenticity via DNSSEC

DANE (DNS-based Authentication of Named Entities) uses DNSSEC to verify that a TLS certificate presented by a mail server is the one the domain owner intends to use. This prevents man-in-the-middle attacks by cryptographically linking the certificate to the domain’s DNS records. But it requires DNSSEC to be active across the entire DNS resolution path — a condition not met by most domains.

Because DNSSEC adoption is still limited, DANE deployment is rare. The technical overhead — signing DNS zones, maintaining trust chains, and ensuring consistency — makes it impractical for most organizations. Even major providers like Google and Microsoft only use DANE in selected environments, confirming its niche status. For deeper context on DNSSEC’s role, see the IETF’s formal specification RFC 6698.

MTA-STS: Simpler TLS Enforcement

MTA-STS (Mail Transfer Agent Strict Transport Security) doesn't require DNSSEC. Instead, it relies on a published policy in DNS that tells mail servers: “Only connect over TLS.” The policy itself isn’t cryptographically signed, but the mechanism is straightforward: a domain publishes a TXT record with an STS policy, and sending servers check it before transmission.

This simplicity is why MTA-STS has seen better adoption, especially among email platforms using modern infrastructure. It doesn’t validate the certificate’s authenticity — it only enforces encryption — but it still dramatically reduces the risk of plaintext email interception. It’s a practical middle ground: effective, deployable by most admins, and widely supported by major providers.

If your goal is to reduce delivery failures and improve inbox placement by enforcing secure transport, MTA-STS is the most achievable route today. You can test its impact with real-time verification tools. See how your list performs under secure transport checks with our inbox placement feature.

You can and should use DANE and MTA-STS together. They serve different but complementary roles: MTA-STS enforces TLS encryption and prevents downgrade attacks, while DANE ensures the TLS certificate is valid and trusted via DNS-based validation. Together, they create layered protection that significantly hardens your email infrastructure against interception and spoofing.

How They Work in Practice

MTA-STS is designed to force encrypted connections between mail servers by requiring a TLS connection or rejecting the message. It’s configured through a policy file published in DNS. DANE, defined in RFC 6698, adds cryptographic verification by allowing the receiving server to check the certificate against a DNSSEC-signed TLSA record. This means even if an attacker controls a certificate authority, they can’t spoof the certificate without also controlling your DNSSEC chain.

Let’s say an attacker tries to intercept email from your domain. MTA-STS stops them from downgrading to unencrypted SMTP. Even if they trick the system into accepting a forged certificate, DANE would catch it—because the certificate wouldn’t match the TLSA record in your DNS zone. One failure doesn't break the entire chain. The other layer still protects.

This dual approach isn’t just theoretical. Major email providers like Google and Microsoft use both mechanisms in their infrastructure. The Internet Engineering Task Force (IETF) has emphasized that layered security models like this are the most effective way to defend against modern threats. You can learn more about how DANE is implemented in RFC 6698, and how MTA-STS is defined in RFC 8461.

Better Verification, Better Deliverability

Even if your policy setup is flawless, bad email addresses in your list can still lead to bounces, spam complaints, and damaged sender reputation—especially if they’re catch-all domains or disposable email addresses. That’s why checking your email list with a tool like bulk verification is essential. Our service detects invalid, risky, and role-based email addresses before you send, reducing the chance of hard bounces and protecting your domain’s reputation.

When you’re validating mail server policies like MTA-STS and DANE, you’re defending against technical threats. But when you clean your list, you’re defending against operational ones. Together, they form a complete defense: one protects the transmission path, the other ensures the recipients are real and valid. You can manage this with real-time verification via our API, or integrate with tools like Mailchimp or HubSpot using our integrations. For best results, combine policy enforcement with list hygiene.

When DANE Is Required: Real-World Use Cases Where It’s Necessary

Use DANE when email security demands absolute trust in certificates—like in government services, financial institutions, or regulated industries where a man-in-the-middle attack could compromise sensitive data. It’s necessary when DNSSEC is already deployed and your infrastructure supports it, and when compliance frameworks like FedRAMP or PCI DSS explicitly require it. If your organization handles encrypted communications and zero tolerance for certificate spoofing, DANE is not just helpful—it’s required.

When You Can’t Afford Certificate Trust Risks

  • Government agencies issuing secure communications must use DANE to eliminate reliance on third-party certificate authorities—a requirement in many national security standards.
  • Financial institutions handling transactions or sensitive customer data often deploy DANE to prevent certificate impersonation, especially in regulated environments where non-repudiation is critical.
  • Healthcare providers under HIPAA or similar regulations use DANE to ensure that encrypted email channels are not compromised during transit.

When DNSSEC and Infrastructure Are Already in Place

  • DANE only works if DNSSEC is validated across your domain—meaning you must already have DNSSEC signed records and validate them in your DNS resolvers.
  • Without DNSSEC, DANE can’t enforce trust. Trying to enable it without it is pointless and risks breakage—your mail flow will fail if DANE is misconfigured.
  • Major platforms like Google and Microsoft use DANE internally for internal mail transport, showing it’s viable at scale—but only when infrastructure is mature enough to support it.

Let’s be clear: DANE isn’t a plug-and-play fix. It's a hardening layer that only applies where the underlying trust model is already secure. If your domain doesn’t use DNSSEC, or your mail stack doesn’t support RFC 6698 (which defines DANE), you’re better off focusing on SPF, DKIM, and DMARC first. Those are more universally applicable and easier to debug.

Still, if you're in a high-integrity sector, DANE can be the final piece. For organizations aiming for maximum compliance with standards like FedRAMP (which requires strong cryptographic verification) or PCI DSS (which mandates secure email for cardholder data), DANE isn’t optional—it’s part of the security baseline.

“DANE provides a cryptographic trust path from DNS to TLS certificate, bypassing traditional CA trust models. This is vital in environments where CA compromise is unacceptable.” — IETF RFC 6698

Use cases like these are why DANE persists despite its complexity. It’s not for everyone, but for those who need absolute assurance in certificate trust, it’s the only choice. Before you jump in, validate your DNSSEC setup, assess your MTA compatibility, and ensure your team can manage the increased operational burden.

You can validate email infrastructure as part of broader deliverability health checks. For large-scale testing, bulk verification helps ensure domains and MX records are correctly configured—critical when rolling out DANE across hundreds of addresses.

MTA-STS for the Majority: A Practical, Deployable Solution

You don’t need DNSSEC to secure your outbound email. MTA-STS is the most effective, widely deployable way to enforce encrypted SMTP connections for the majority of organizations today. It requires only a few DNS records and works across existing infrastructure without complex upgrades. This means stronger protection against man-in-the-middle attacks and reduced risk of messages being intercepted—without the overhead of DANE.

Why MTA-STS Wins for Most Organizations

Most email operators can’t or won’t implement DNSSEC, the foundational requirement for DANE. MTA-STS bypasses that hurdle entirely, making it a realistic, scalable solution. You don’t need to re-architect your mail system or wait for DNSSEC rollout across partners. It works today, with existing tools like SendGrid, Mailchimp, and AWS SES—many of which already support it. If you use modern email infrastructure, MTA-STS is likely already compatible.

Let’s be clear: DANE offers stronger guarantees, but only in environments where DNSSEC is trusted and deployed. That’s not the norm. MTA-STS, by contrast, operates within the current email ecosystem. It doesn’t require trust in DNS integrity—only that you and your recipients publish and follow a simple policy. That’s why it’s been adopted by large providers and is the industry-standard path for email encryption enforcement. The IETF’s specifications RFC 8461 reflect this pragmatic approach.

Securing the Chain Without Overhauling It

When you publish an MTA-STS policy, you tell sending servers: “Only connect via TLS, or don’t connect at all.” This prevents downgrades to unencrypted sessions, reducing exposure to eavesdropping during transit. It doesn’t stop phishing or spoofing on its own—but in combination with SPF, DKIM, and DMARC, it closes a critical gap in the email security stack.

Even if your current setup doesn’t support MTA-STS yet, the transition is low-effort. You publish the policy, test it with tools like MXToolbox, and monitor results. If you’re already sending bulk emails, validating your list quality with tools like bulk verification helps identify invalid or insecure delivery endpoints early. Real-time integration via our API keeps your data clean and your sender reputation healthy.

So, if you’re looking for strong, practical email encryption without waiting for DNSSEC adoption, MTA-STS is your best bet. It’s not perfect—but it’s deployable, effective, and growing. For most teams, it’s the difference between good security and no security at all.

How to Set Up MTA-STS: A Step-by-Step Process

You can set up MTA-STS by publishing a policy file at https://mta-sts.yourdomain.com, adding a DNS TXT record that points to it, configuring your outbound MTA to check the policy before sending, and testing the setup with tools like MxToolbox or the Emaillistchecker.io deliverability API. Each step ensures your email sessions use enforced TLS, reducing the risk of interception.

Step 1: Publish Your MTA-STS Policy File

Create a JSON file with your policy, including the version, mode (set to enforce for full TLS requirement), and max_age (typically 86400 seconds, or 24 hours). Save it at https://mta-sts.yourdomain.com. This file tells receiving MTAs how you want your messages secured. The policy is only effective if it’s reachable and correctly formatted.

Step 2: Add the DNS TXT Record

Add a TXT record to your DNS zone with the name mta-sts.yourdomain.com and the value pointing to your policy file’s location. The record should be: policy=mta-sts.yourdomain.com. This tells mail servers where to find your policy file. Without this, receivers won’t know to check the policy, and TLS enforcement won’t apply.

Step 3: Configure Your MTA to Query the Policy

Set up your outbound MTA (like Postfix or Exim) to query the MTA-STS policy before sending. This requires enabling MTA-STS support in your mail server software. When configured, your MTA will look up the policy, validate it, and reject delivery if TLS is not available. This prevents any cleartext email transmission.

Step 4: Test and Monitor Your Setup

Verify the configuration using tools like MxToolbox’s MTA-STS checker or the Emaillistchecker.io inbox placement test. These tools confirm your policy is accessible, properly formatted, and enforced. Regular testing helps catch misconfigurations before they cause delivery issues.

MTA-STS is an industry-standard way to enforce TLS encryption. It’s described in RFC 8461, which outlines how MTA-STS works at the protocol level. When implemented correctly, it reduces the chance of email interception, especially for high-sensitivity messages.

For teams managing large lists, pairing MTA-STS with email verification helps reduce the risk of sending to invalid or insecure addresses. Use the bulk verification tool to clean your list before relying on MTA-STS, ensuring your secure transport doesn’t waste effort on non-deliverable addresses.

Why DANE Adoption Is Still Low: The DNSSEC Barrier

DANE is rarely used because DNSSEC—its foundational requirement—is still adopted by fewer than half the domains on the public internet. Without DNSSEC, DANE cannot validate TLS certificates, making it infeasible for most email senders. This creates a chicken-and-egg problem: DNSSEC adoption is low because DANE hasn’t driven demand, and DANE remains unused because DNSSEC isn't widespread.

Infrastructure Dependencies Block Widespread Use

Deploying DANE isn’t just a DNS change—it requires coordination across DNS providers, zone administrators, and recursive resolvers. Even if your domain supports DNSSEC, your outgoing mail server must be configured to enforce it, and the receiving side must support DANE validation. Most mail providers don’t enforce it, and few organizations have the infrastructure to do it reliably.

Most senders don’t control the full stack. They rely on third-party providers (like SendGrid or Mailchimp) for delivery, and those platforms don’t universally support DANE enforcement. That makes it risky to deploy DANE in isolation—mistakes can break delivery, and troubleshooting is complex.

Configuration Risk Outweighs Benefit

When DANE is misconfigured—say, a TXT record is wrong or a certificate doesn’t match—it can cause legitimate mail to be rejected outright. That’s a real business cost: a single failed verification can lead to lost leads, declined transactions, or customer complaints. For most organizations, the risk of delivery failure exceeds the security benefit, especially since many threat models don’t justify the effort.

Even when properly set up, DANE is only enforced by a subset of recipients. According to data from the Internet Society’s DNSSEC Deployment Survey, DNSSEC adoption across top-level domains remains below 50% globally. That means DANE is effective for only a small fraction of email traffic. With limited return on investment, most senders avoid it entirely.

For email teams focused on inbox placement and deliverability, the effort is rarely worth it. Instead, they focus on proven methods: warming sender reputation, maintaining clean lists, and using verified infrastructure. Tools like bulk email verification help prevent delivery issues long before they reach the server level.

How Email Verification Strengthens Your DANE or MTA-STS Strategy

You can’t rely on DANE or MTA-STS to fix a bad email list. If your list contains invalid, catch-all, or role-based addresses, transport security will fail—not because of encryption, but because the address doesn’t exist or isn’t reachable. Validating your list first ensures DANE and MTA-STS protocols work on real, deliverable inboxes, reducing false positives and avoidable delivery failures.

Why Security Protocols Fail on Bad Lists

Even with strong transport security like MTA-STS or DANE, your message won’t reach the inbox if the address is invalid or points to a catch-all. These protocols assume the recipient exists and is willing to accept mail. If the address doesn’t, you’ll see a hard bounce—even if the encryption handshake succeeds. That means your DMARC reports grow noisy, and your sender reputation suffers from unexpected delivery failures.

Let’s say you apply MTA-STS to a list with 20% invalid addresses. The MTA-STS policy enforces encrypted delivery, but the delivery still fails because the address doesn’t exist—your system doesn’t know it’s invalid. That’s a silent failure that damages your reputation and increases risk.

Use Verification to Pre-Filter Your List

That’s where email verification comes in. Before enabling DANE or MTA-STS, run your list through a bulk verification tool like Emaillistchecker.io’s bulk verification. It checks for syntax, domain validity, and mailbox existence—flagging invalid addresses, catch-alls, and role accounts like admin@ or sales@ before a single message is sent.

Catch-all domains accept all emails, making them a common target for spammers. If you send to one, you may trigger spam filters or be marked as a poor sender—even if you use MTA-STS. Role accounts are often ignored or filtered out by recipients' email systems. Sending to them wastes bandwidth and harms your sender reputation.

DANE and MTA-STS are designed to work with trusted, real-world inboxes. You’re not adding security to a full list—you’re adding it to a clean one. That’s why verification isn’t just a filtering step; it’s a prerequisite for trust-based protocols.

According to the RFC 8461 specification for MTA-STS, compliance assumes the client can deliver to the target domain. If the address is invalid, compliance is irrelevant. The same applies to DANE—your keys must match an actual, existing mailbox. RFC 8461 outlines this expectation clearly: only valid addresses should be included in secure transport setups.

Conclusion: Choose MTA-STS First, DANE When You’re Ready

MTA-STS is the most practical foundation for secure email transport today. It’s widely supported, requires no changes to DNS infrastructure beyond TXT records, and provides immediate protection against man-in-the-middle attacks on SMTP connections.

DANE vs. MTA-STS: A Reality Check

DANE offers stronger cryptographic validation by using DNSSEC to verify TLS certificates. But it only works when DNSSEC is already deployed across the entire chain of authority — a rare setup outside large enterprise or government environments.

  • MTA-STS: Active today, simple to implement, effective immediately.
  • DANE: Stronger in theory, but dependent on DNSSEC adoption — not yet viable for most senders.

For most senders, starting with MTA-STS, combined with accurate list hygiene and ongoing deliverability monitoring, delivers the best return on effort and technical investment. DANE remains a future option — not a current necessity.

Sources

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does DANE require DNSSEC?

Yes. DANE relies on DNSSEC to authenticate TLS certificates published in DNS. Without DNSSEC, DANE cannot operate.

Can MTA-STS work without DNSSEC?

Yes. MTA-STS does not require DNSSEC—it uses standard DNS TXT records to publish transport policies.

Is DANE more secure than MTA-STS?

DANE offers stronger cryptographic validation, but only when DNSSEC is fully adopted. MTA-STS is more practical and widely supported.

Why isn’t DANE widely used yet?

DANE requires DNSSEC, which has low global adoption. It’s complex to deploy and risky to misconfigure.

What happens if my MTA-STS policy fails to resolve?

Your outbound MTA may fall back to unencrypted SMTP, increasing exposure. Always test policies before enabling enforcement.

Can I use DANE and MTA-STS on the same domain?

Yes. Using both enhances security—MTA-STS enforces encryption, DANE verifies certificate trust.

How do I test my MTA-STS setup?

Use MxToolbox or the Emaillistchecker.io inbox placement test to validate policy resolution and encryption enforcement.

Does email verification help with DANE or MTA-STS?

Yes. Validating your list reduces bounce rates and helps avoid sender reputation issues, especially when enforcing strict transport policies.

What’s the biggest downside of MTA-STS?

If misconfigured, it can block legitimate traffic. It also doesn’t verify certificate authenticity—only encryption.

Is DANE part of the IETF standard?

Yes. DANE is defined in RFC 6698 and is a formal IETF standard, but implementation is limited.

Should I enable DANE now?

Only if your domain already uses DNSSEC at scale. Otherwise, start with MTA-STS and upgrade later.

What is a TLSA record?

A TLSA record is a DNS record used in DANE to publish a hash of the TLS certificate that a mail server must present.