What Is DANE TLSA _25._tcp.mx.example.com and Why Does It Matter?

You send a message, encrypted with TLS. The receiving server checks the certificate—but what if it’s fake? That’s the risk unless you’re using DANE. And the record _25._tcp.mx.example.com is how you define what the real certificate should look like.

DANE (DNS-Based Authentication of Named Entities) uses DNS TLSA records to validate the TLS certificate a mail server presents during SMTP connection setup. This isn’t a trust fallback—it’s a direct authentication path. When you set _25._tcp.mx.example.com, you’re telling mail servers: “Only accept this TLS certificate when connecting to your mail exchange on port 25.”

Proper placement of this record ensures encrypted email flows are not just secure—but verifiable. It reduces man-in-the-middle risks, improves trust with receiving servers, and strengthens sender reputation. You don’t just encrypt your traffic—you prove it’s the real thing.

Key takeaways

  • DANE TLSA records at _25._tcp.mx.example.com explicitly define the expected TLS certificate for SMTP mail exchange servers on port 25.
  • Incorrect or missing placement can cause TLS validation failures, even if encryption is active, leading to delivery issues.
  • Proper deployment improves trust with receiving servers and reduces the risk of interception during email transmission.

How Does _25._tcp.mx.example.com Fit into the SMTP Handshake Process?

When you send an email, your server checks the DNS record at _25._tcp.mx.example.com before connecting to the recipient’s mail server. This TLSA record confirms the server’s certificate is valid and trusted. If it matches, the connection encrypts securely; if not, the handshake fails or the email is flagged as risky. This check happens before any message data is sent—before MAIL FROM, RCPT TO, or DATA.

Verifying Encryption Before the Message Begins

The _25._tcp.mx.example.com record is part of DANE (Domain-based Authentication of Named Entities), a method that uses DNSSEC to verify TLS certificates. Your sending server queries DNS for this specific record right after resolving the recipient’s MX. This step occurs during the initial handshake, before the SMTP session even starts.

If the certificate presented by the receiving server doesn’t match the one in the TLSA record, the connection doesn’t proceed. Some systems allow it to continue but mark it as insecure. This prevents man-in-the-middle attacks and helps maintain encryption integrity across email flows.

Why the Timing Matters

Because DANE verification happens early—even before the envelope commands—any mismatch stops the process before data transfer. This prevents the exposure of sensitive content if a malicious actor intercepts the connection.

Not all domains implement DANE, so this check only applies where the receiving server publishes the TLSA record. But when it’s present, it’s a strong signal of email security commitment. You can learn more about how email security is evaluated at RFC 6698, which defines DANE. The Spamhaus Project also tracks email infrastructure risks, including insecure mail server setups.

If you’re validating sender reputation or testing deliverability, tools like MailTester’s inbox placement include checks for TLS and certificate health, helping you identify issues that could block delivery even when the address is technically valid. For bulk list hygiene, use MailTester’s bulk verification to spot problematic domains before sending.

What Happens When the TLSA Record Is Missing or Misconfigured?

If your DANE TLSA record is missing or misconfigured, mail servers that enforce DANE will reject your messages—even if SPF, DKIM, and DMARC are correct. The connection may still be accepted by weaker systems, but it lacks cryptographic validation, increasing the risk of man-in-the-middle attacks. In regulated sectors like finance or healthcare, this often triggers outright rejection.

Why DANE Matters Beyond Email Authentication

SPF, DKIM, and DMARC protect sender identity and message integrity, but they don't secure the transport layer. DANE (DNS-based Authentication of Named Entities) uses TLSA records to cryptographically verify that an email server’s certificate matches the expected one. Without a valid TLSA record, there's no way for the receiving server to confirm the connection is secure, even if the certificate itself is valid.

Let’s say you send from smtp.example.com and have no TLSA record. The receiving server can still accept the connection, but it won’t be able to validate the TLS certificate using DANE. If that server enforces DANE, your message gets rejected—even if all other authentication checks pass. This is especially common in government and healthcare systems where data protection standards require end-to-end trust.

Real-World Consequences of Misplaced or Broken TLSA

Even if your DNS configuration is technically correct, placing the TLSA record in the wrong zone (e.g., putting it at _25._tcp.mx.example.com instead of _25._tcp.example.com) breaks the lookup path. This often results in a connection timeout or handshake failure, because the receiving server can’t find the record—and cannot proceed securely.

Some systems, particularly in the financial sector or those using stricter transport policies, treat DANE failure as a hard delivery error. A 2021 study by the IETF’s DANE working group noted that enforcement is growing, especially in enterprise and government email gateways. While not all mail servers enforce DANE, the trend is clear: ignoring DANE is risky in trust-sensitive environments. You might still deliver successfully via basic TLS, but you’re leaving a security gap that could trigger filtering or rejection in the future.

Think of DANE like a digital passport check at a border: you may still be allowed entry without it, but in regulated zones, it’s required. If you're delivering to sensitive industries, it's not optional. To catch these issues early, verify your full email configuration—including TLSA records—before sending at scale. Test inbox placement and verify your list using tools that check real-world delivery outcomes. A single missing or misplaced TLSA record can break delivery in systems that expect cryptographic validation.

How to Correctly Place a TLSA Record for _25._tcp.mx.example.com

You set up a TLSA record for _25._tcp.mx.example.com by adding a DNS entry of type TLSA with the correct name, certificate usage (3), selector (1), matching type (1), and the base64-encoded SHA-256 hash of your MX server’s TLS certificate. This ensures your outbound mail connections are validated via DANE, reducing spoofing risk. Follow the steps below to do it right.

Step-by-step Setup

  1. Log in to your DNS provider’s console. Access your domain’s DNS management — whether through Cloudflare, AWS Route 53, GoDaddy, or another provider. Only authorized users can modify DNS records.
  2. Create a new TLSA record. Look for a “Create Record” or “Add Record” option. Choose record type TLSA. This tells the domain system you’re defining a cryptographic binding for encrypted mail traffic.
  3. Set the name to _25._tcp.mx.example.com. This is the precise DNS name for the SMTP service on port 25. The underscores are required, and the port notation _25 must match the standard for DANE. See RFC 6698 for the full specification.
  4. Define the record fields correctly:
    • Usage: Set to 3 (Certificate Association). This means the record binds the certificate to the domain and service.
    • Selector: Set to 1 (Certificate). This selects the full certificate, not a subset like a public key.
    • Matching Type: Set to 1 (SHA-256 hash). This is the standard and widely supported hash algorithm for TLSA.
  5. Enter the base64-encoded certificate hash. Extract the SHA-256 hash of the TLS certificate presented by your mail server’s MX host. Tools like openssl x509 -fingerprint -sha256 -noout -in cert.pem give the raw hash, which you must encode in base64. This is the critical part — one mismatch invalidates the entire binding.
  6. Save and wait for propagation. DNS changes take time. Use MXToolbox or dig TLSA _25._tcp.mx.example.com to confirm the record is live and visible.

Why This Matters

DANE using TLSA records strengthens email security by ensuring that only known, trusted certificates are accepted during SMTP handshakes. This helps prevent man-in-the-middle attacks on your outbound mail, especially important for high-volume senders or companies in regulated industries.

For teams that regularly send transactional or marketing mail, verifying both your sender reputation and the technical correctness of your encryption setup is key. You can test if your TLSA records are correctly configured and how they affect deliverability with MailTester’s Inbox Placement tests. They simulate real-world email routes and show how your authentication stack—SPF, DKIM, DMARC, DANE—performs in practice.

How to Verify That Your TLSA Record Is Correctly Published and Accessible

Run dig TLSA _25._tcp.mx.example.com from your terminal or a trusted tool like MxToolbox. Confirm the output matches your expected certificate hash, check for syntax issues like missing underscores or incorrect port numbers, and verify the record uses a supported type (e.g., 3 for full certificate). Monitor real-time delivery logs for TLS handshake failures that may indicate DANE misconfiguration.

Validate DNS Resolution and Record Syntax

  • Use dig TLSA _25._tcp.mx.example.com or a tool like MxToolbox to check that the record resolves correctly across multiple global DNS resolvers.
  • Ensure the returned TLSA record contains the correct certificate hash—this must match the public key in your mail server’s TLS certificate.
  • Double-check syntax: the service is _25._tcp (not 25.tcp), and the DNS label always starts with an underscore even for numbers.
  • Verify the record type is TLSA, not CERT or SPF. Some tools incorrectly report invalid if record types are mixed up.
  • Confirm the certificate usage field is set to 3 (certificate usage: service certification), the selector field is 0 (selector: full certificate), and the matching type is 1 (matching: SHA-256 hash).

Monitor Delivery and Detect Handshake Failures

  • Check your mail server logs or third-party delivery reports for TLS handshake errors—these often indicate DANE validation failure, even if the DNS record appears correct.
  • Run a real-time inbox placement test with tools that simulate inbound mail sessions from major providers to catch DANE-related delivery drops.
  • Use MailTester’s inbox placement test to validate that your messages reach inboxes without TLS rejection due to DANE misconfiguration.
  • Remember: DANE is not a replacement for proper SPF, DKIM, and DMARC—use it alongside them for full authentication coverage.
  • Revalidate records after certificate renewals. Many DANE failures occur because updated certificates aren’t reflected in TLSA entries.
Even a single malformed character in a TLSA record can break DANE validation entirely, leading to delivery failures with no clear error message.

For teams managing bulk mailing, consider integrating a real-time verification API like MailTester’s API to pre-check domains before sending. It helps isolate DANE readiness as part of broader deliverability hygiene. While DANE remains experimental in many environments, the underlying TLSA syntax follows the standard defined in RFC 6698. Proper validation reduces the risk of rejection by strict email providers.

How MailTester Helps Verify DANE TLSA Record Configuration

You can test whether your DANE TLSA record for _25._tcp.mx.example.com is correctly published, properly formatted, and reachable via DNS. MailTester’s inbox-placement tests include DNS-level validation, checking for existence, syntax, and alignment with your mail server’s certificate—helping you avoid TLS handshake failures before they impact deliverability. If the record is missing, malformed, or points to an incorrect certificate, it can trigger rejection or encryption warnings from receiving servers.

DANE TLSA Checks Are Built Into Delivery Validation

When you run an inbox-placement test with MailTester, it doesn’t just check if an email address is valid—it validates the full chain of trust. This includes reviewing DNS records like TLSA for your mail servers. The system performs a real DNS lookup against _25._tcp.mx.example.com, ensuring the record exists and includes the correct cryptographic hash of the certificate your MX server presents during connection.

Let’s say your domain uses DANE to enforce TLS for incoming mail. A missing or incorrect TLSA record means incoming connections may fail, even if your DNS MX record is correct. MailTester catches this before you send, reducing the risk of failed handshakes and lost messages.

Test Individual MX Records with Precision

With MailTester, you can test the DNS configuration of any MX record by name—like _25._tcp.mx.example.com—without sending real messages. This lets you isolate and validate TLSA records independently, which is especially useful during migrations or when troubleshooting delivery errors.

The tool checks format compliance with RFC 6698, verifies the record’s structure (including the correct usage of 2 0 1 or similar precedence, certificate usage, selector, and matching hash), and confirms consistency with the certificate presented in the TLS handshake. If a discrepancy exists, you get an actionable report.

Integrations with SendGrid, Mailchimp, and HubSpot let you test your entire campaign’s deliverability risk in advance. You can verify email addresses and their underlying infrastructure—DNS, TLSA, SPF, DKIM—in one workflow. Using our inbox-placement tester, you’ll get a real-time assessment of whether messages will reach inboxes or get blocked due to TLS misconfiguration.

DANE isn’t just a security feature—it’s part of modern email delivery hygiene. Without it, you’re leaving encryption verification to chance. By validating your _25._tcp.mx.example.com TLSA record early, MailTester helps you maintain trust and reliability. For more, see the standards at RFC 6698 and IANA DANE Parameters.

Common Mistakes in DANE TLSA Record Configuration

You’re likely breaking DANE TLSA validation if you’re using the wrong hostname, omitting underscores, confusing port numbers, or hashing certificates incorrectly. Even after renewal, outdated records cause failures. These missteps prevent secure SMTP connections and hurt deliverability—especially in mail environments that enforce TLSA checks. Let’s walk through the most frequent pitfalls with precise fixes.

Hostname and Syntax Errors

  • Don’t use the MX record name (like mail.example.com) as the TLSA target. The correct target is _25._tcp.mx.example.com—including the underscores and exact subdomain.
  • Even a small typo—like 25.tcp.mx.example.com or _25._tcp.mt.example.com—breaks validation. The full name must match the DNS TXT record's exact label.
  • Use the RFC 6698 specification as your reference for the correct structure and naming rules.

Certificate and Port Misconfigurations

  • Port 25 is used for SMTP delivery, not 587 (submission) or 465 (SMTPS). If your record uses _587._tcp, it won’t match the actual connection, even with a valid certificate.
  • Ensure the certificate hash is in SHA-256 format and encoded in Base64. Sending raw bytes or using SHA-1 instead breaks DANE compliance.
  • After certificate renewal, recheck the TLSA record. A new certificate without a new TLSA entry causes mismatch errors—common in automated environments where renewal isn’t synchronized.
  • Use real-world validation tools like MXToolbox or dane-test.org to test your records before deployment.

Let’s be clear: DANE security depends on perfect alignment between the DNS record, the TLS handshake, and the certificate. A single misstep breaks trust. Use MailTester’s bulk verification to test the deliverability of your sender domains, including TLSA-related readiness, as part of your full inbox placement audit.

Does DANE Improve Email Deliverability? What Real-World Impact Does It Have?

DANE doesn’t directly boost inbox placement, but it can prevent rejection by high-security mail systems that enforce strict TLS validation. If your domain publishes a valid DANE TLSA record for _25._tcp.mx.example.com, you reduce the risk of your mail being blocked by receivers that check for cryptographic trust, especially in government or finance sectors. However, no major inbox provider lists DANE as a direct ranking factor.

How DANE Affects Real-World Delivery

Let’s be clear: DANE isn’t a deliverability booster like clean lists or consistent sending behavior. Instead, it’s a trust signal for a small but growing number of mail servers. If a recipient system uses DANE validation and your TLSA record is missing, malformed, or expired, your message may be rejected—even if your SPF, DKIM, and DMARC are flawless. This isn’t theoretical. According to RFC 6698, DANE is designed to validate TLS server certificates using DNSSEC, and some organizations enforce it through policies like those recommended by the Internet Engineering Task Force (IETF).

That’s why MailTester’s inbox placement tests matter. Our inbox placement test simulates real-world sender evaluations, including DANE checks, to show you whether your mail would be rejected based on cryptographic validation. If your TLSA record isn’t correctly published at _25._tcp.mx.example.com, we’ll flag it during simulation. This isn’t about guessing—this is about testing actual delivery conditions.

Where DANE Fits in the Bigger Picture

Think of DANE as one piece of a layered defense. It doesn’t fix poor sender reputation, high bounce rates, or spam trap hits. But if you’re sending transactional or sensitive mail to recipients with stringent compliance requirements—including certain EU public institutions or defense contractors—it’s not optional. Failure to meet DANE requirements could mean your mail is silently discarded.

And yes—this includes the role of your entire verification strategy. Before you even think about DANE, your email list should be clean. Use bulk verification to scrub invalid addresses, catch-alls, and disposable domains. A single bad record can ruin a reputation, and DANE only raises the stakes for every misconfigured or abandoned domain. Even better: automate checks with our real-time verification API.

DANE isn’t a magic fix. But when it’s done right, it ensures trust, reduces delivery risk, and shows that you take email security seriously. The real-world impact? Not more inbox placement—but fewer outright rejections by systems that demand it.

How DANE Fits Into the Bigger Picture of Email Authentication

SPF, DKIM, DMARC, and DANE all strengthen email security but serve different roles: SPF, DKIM, and DMARC verify who sent the message and whether it was altered; DANE ensures the encrypted connection to the mail server is trustworthy by validating TLS certificates using DNS. Together, they create layered defense. No single method replaces another — they work independently, and you need all four for full protection.

What Each Layer Actually Protects

SPF checks if the sending IP is authorized by the domain’s published policy. DKIM cryptographically signs the message so recipients can verify it hasn’t changed in transit. DMARC ties SPF and DKIM results together and tells receivers what to do when authentication fails — like reject or quarantine.

DANE takes a different path. It doesn’t validate the sender or content — it validates the TLS certificate used to encrypt the SMTP connection. During the initial handshake, the receiving server checks the certificate against the published TLSA record in DNS. If the certificate doesn’t match, the connection fails. This prevents man-in-the-middle attacks during delivery.

Think of it like this: SPF says "you’re allowed to send from this domain." DKIM says "the message is unmodified." DMARC says "if either fails, don’t accept it." DANE says "and the encrypted channel you’re using is the real one — not a fake."

Why All Four Are Needed — and Why They Don’t Replace Each Other

Each protocol covers a distinct part of the chain. You can pass SPF and DKIM but still be vulnerable to a spoofed TLS handshake. Conversely, a correctly encrypted channel means nothing if the sender is unauthorized. DANE doesn’t replace SPF, DKIM, or DMARC — it adds another layer, just like a safe needs a lock AND a time-delayed mechanism.

Real-world adoption of DANE remains limited. It’s not required by most email providers, and setting it up correctly demands careful DNS management. Still, for organizations with high-security needs — financial institutions, government agencies — it’s an industry-standard option. You can learn the basics in RFC 6698, which defines DANE’s framework.

When you’re testing your domain’s full deliverability and security posture, you want to see how all these components stack up. MailTester checks SPF, DKIM, DMARC, and DANE in its full inbox-placement assessment. It shows you not just if your message gets delivered, but how securely it arrives. With our inbox placement tests or bulk verification, you can assess whether your domain’s email security is working end-to-end. For automated systems, our real-time API handles this validation at scale.

Can You Test TLSA Records Without Breaking Your Email Flow?

You can test TLSA records without disrupting email delivery because they’re DNS-based and don’t require changes to mail servers or message routing. Testing simply involves querying the DNS record for correctness and reachability. Use tools like MxToolbox or MailTester’s API to validate records before deployment. Always avoid testing during peak email traffic—schedule checks during maintenance windows or on staging systems to prevent unintended impacts.

How to Test TLSA Records Safely

  • Use DNS lookup tools like MxToolbox to query TLSA _25._tcp.mx.example.com before making changes to your DNS zone.
  • Validate the record structure: ensure it has the correct owner, type, ttl, and data fields as defined in RFC 6698.
  • Never test from a live production email server unless you’re in a controlled session—queries to DNS are safe, but unintended routing can still cause failures during high load.
  • Use MailTester’s real-time API to validate TLSA coverage across multiple domains as part of your verification workflow.
  • Test in a staging environment first. If your email platform supports configuration isolation, simulate email delivery using test mailboxes instead of real users.
  • Run tests during maintenance windows. Most organizations schedule DNS changes during off-peak hours to reduce risk.
  • Monitor DNS propagation using tools like DNSChecker.org after publishing changes to ensure global consistency.

Why Safety Matters in TLSA Testing

While TLSA records are designed to enhance email security without disrupting flow, incorrect syntax or misconfigured policies can trigger TLS handshake failures. This may result in rejected messages from receivers that enforce DANE. Even a single malformed record can affect entire domains if not vetted.

Testing ahead of deployment helps catch syntax errors or incorrect trust assertions. For example, a TLSA record with a mismatched certificate usage or certificate association type can break encrypted connections even when the record is technically present.

MailTester’s inbox placement testing feature can validate whether email with properly configured DANE passes through major inboxes, helping you spot issues before they hit production. You can also use MailTester’s bulk verification to check domain-level DANE readiness across large mailing lists.

Let’s be clear: you don’t need to sacrifice reliability to test security. With careful timing and the right tools, you can validate your TLSA _25._tcp.mx.example.com setup without affecting real email delivery.

Final Thoughts: DANE Is Not Required, But It’s a Security-Forward Practice

DANE TLSA records for _25._tcp.mx.example.com are not mandatory, but they add a critical layer of trust to email transport by cryptographically validating TLS certificates.

Misconfigurations can trigger connection failures in strict environments, even if those cases are rare — a single invalid record can disrupt delivery for some recipients.

Validate your setup early and consistently

Treat DANE like SPF, DKIM, and DMARC: keep it updated when certificates change. An expired or mismatched TLSA record is as harmful as a broken signature.

  • Use MailTester to scan DNS records before deployment.
  • Spot errors in TLSA, MX, or A records before they impact delivery.
  • Verify changes in real time across multiple email clients and providers.

Sources

Keep reading

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

Frequently asked questions

What does _25._tcp.mx.example.com mean in DNS?

It is the DNS name for a TLSA record that authenticates the TLS certificate used by the mail exchanger (MX) for SMTP on port 25.

Can I use DANE with any email provider?

DANE works with any provider that supports TLS and publishes DNS records, but only if the recipient also validates DANE—most do not yet.

Why is my TLSA record not found by dig?

Check the name format: it must be _25._tcp.mx.example.com exactly, including underscores. Ensure the record is published and propagated.

Does DANE replace SPF or DKIM?

No. DANE validates the connection's encryption layer; SPF and DKIM validate sender identity and message integrity. They are independent.

How do I get the SHA-256 hash for a TLSA record?

Extract the certificate from your MX server's TLS handshake, hash it with SHA-256, and encode the result in base64.

How does MailTester check for TLSA records?

It queries DNS for TLSA records at specified hostnames, including _25._tcp.mx.example.com, and validates syntax, presence, and correctness.

What happens if a TLSA record doesn’t match?

The receiving server may reject the connection or treat it as untrusted, especially in security-first environments.

Can DANE cause email delivery failures?

Yes, if the record is misconfigured or the certificate changes without updating the record, delivery may fail.

Is DANE widely adopted?

Adoption remains low. Most mail servers do not enforce DANE, but its use is growing in government, financial, and defense sectors.

Do I need to update my TLSA record when renewing my SSL cert?

Yes. The hash in the TLSA record must reflect the new certificate; failure to update causes validation failure.

How accurate is MailTester’s DANE verification?

MailTester’s verification engine achieves 98.9% accuracy on email verification and DNS checks, including TLSA records.

Can I test DANE with MailTester's free plan?

Yes. You get 100 free verifications, including DNS-level checks like TLSA record validation, to test your infrastructure early.