---
title: "TLSA Record Explained: How SPF, DNSSEC & DANE Strengthen Email Security | AutoSPF"
description: "Learn how TLSA records, SPF, DNSSEC, and DANE work together to secure email, prevent spoofing, validate certificates, and strengthen SMTP security."
image: "https://autospf.com/og/blog/tlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security.png"
canonical: "https://autospf.com/blog/tlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security/"
---

Quick Answer

A TLSA record is a DNS record used with DANE and DNSSEC to verify an email server's TLS certificate during SMTP. Combined with SPF, DKIM, and DMARC, it strengthens email authentication, prevents spoofing, and protects encrypted email delivery.

Share 

[ ](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fautospf.com%2Fblog%2Ftlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security%2F "Share on LinkedIn") [ ](https://twitter.com/intent/tweet?text=TLSA%20Record%20Explained%3A%20How%20SPF%2C%20DNSSEC%20%26%20DANE%20Strengthen%20Email%20Security&url=https%3A%2F%2Fautospf.com%2Fblog%2Ftlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security%2F "Share on X/Twitter") [ ](https://www.facebook.com/sharer/sharer.php?u=https%3A%2F%2Fautospf.com%2Fblog%2Ftlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security%2F "Share on Facebook") [ ](https://reddit.com/submit?url=https%3A%2F%2Fautospf.com%2Fblog%2Ftlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security%2F&title=TLSA%20Record%20Explained%3A%20How%20SPF%2C%20DNSSEC%20%26%20DANE%20Strengthen%20Email%20Security "Share on Reddit") [ ](mailto:?subject=TLSA%20Record%20Explained%3A%20How%20SPF%2C%20DNSSEC%20%26%20DANE%20Strengthen%20Email%20Security&body=Check out this article: https%3A%2F%2Fautospf.com%2Fblog%2Ftlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security%2F "Share via Email") 

![SPF DNSSEC DANE protection](https://media.mailhop.org/autospf/spf-flatterning-2017-1784623019822.jpg) 

## What TLSA Records Are and How They Fit Into Email Security

Email security relies on multiple technologies that protect different stages of mail delivery. Most administrators are familiar with [Sender Policy Framework (SPF)](https://autospf.com/blog/what-is-spf-email-a-guide-to-sender-validation-technology/) for preventing sender spoofing, but secure email transport requires additional protections. DNSSEC ensures DNS records cannot be tampered with, while DANE uses TLSA records to **verify mail server certificates** during encrypted SMTP connections.

Together, SPF, [DNSSEC](https://www.internetsociety.org/deploy360/dnssec/), and DANE create a layered security model that protects email from spoofing, DNS manipulation, and man-in-the-middle attacks. This guide explains how these technologies work together, when you need them, and why SPF remains the foundation of **email authentication**.

Teams building a broader [Email Security](https://autospf.com/10-reasons-for-regular-spf-record-checks-in-cybersecurity/dkim-record-check/) program should understand that TLSA records do not replace SPF, DKIM, or DMARC. Instead, they strengthen the transport layer of email authentication and **protect the mail flow** between sending and receiving systems.

### How a TLSA record is structured

A [TLSA record](https://support.dnsimple.com/articles/tlsa-record/) is published in public DNS using a specific owner name format:

```
_<port>._<protocol>.<hostname>
```

For SMTP over port 25, a TLSA record for a host might look like:

```
25.tcp.mail.example.com
```

That hostname is usually derived from the domain’s [MX record](https://www.cloudns.net/wiki/article/12/). A sending server performs [DNS lookups](https://www.digicert.com/faq/dns/how-does-dns-lookup-work) for the recipient domain’s MX record, then queries the TLSA record associated with the selected **mail exchanger**.![Kitterman Spf 6772](https://media.mailhop.org/autospf/kitterman-spf-6772-1784623431055.jpg)

#### The four core TLSA fields

A TLSA record contains four key parts:

1. Certificate usage field
2. Selector field
3. Matching type field
4. Certificate association data

Together, these fields tell the sending [Mail Transfer Agent](https://www.icontact.com/define/mail-transfer-agent/) what certificate material to expect during Transport Layer Security negotiation.

#### Usage values: PKIX and DANE modes

The certificate usage field defines how **certificate validation** should work. Common values include:

- **PKIX-TA:** Uses a Public CA trust anchor with the normal X.509 trust chain
- **PKIX-EE:** Matches the end-entity certificate while still relying on PKIX validation
- **DANE-TA:** Uses a DNSSEC-protected certificate trust anchor
- **DANE-EE:** Matches the end-entity certificate directly through DANE

For SMTP, DANE-EE is widely used because it can reduce dependence on a traditional Public CA while still providing **strong protection through DNSSEC**.

#### Selector and matching type

_The selector field specifies whether the TLSA record applies to the full X.509 certificate or only the Subject Public Key Info_. The matching type field defines whether the certificate association data is stored in full or as a digest, such as a [SHA-256](https://cheapsslsecurity.com/p/how-does-sha-256-work/) hash or SHA-512 hash.

The resulting [Certificate Association](https://www.hyperbots.com/glossary/certificate-association) Data is what the sending server compares against the certificate presented during the TLS handshake.

## SPF Records Explained: Verifying Authorized Sending Servers

SPF, or Sender Policy Framework, is an email authentication mechanism that allows a domain owner to publish which servers are authorized to send mail for that domain. While a TLSA record protects the encrypted SMTP connection, SPF focuses on [email spoofing](https://www.infosecurity-magazine.com/news/infosec2025-email-domains-spoofing/) prevention by checking whether the sending **IP address** is allowed.![Spf Validator 1028](https://media.mailhop.org/autospf/spf-validator-1028-1784623896171.jpg)A typical SPF record is a TXT record in DNS. For example:

```
v=spf1 include:spf.protection.outlook.com -all
```

For **Microsoft 365 or Office 365**, organizations often include Microsoft’s SPF mechanism to authorize Exchange Online to send on their behalf.

### How SPF works during SMTP protocol checks

During the SMTP protocol transaction, the receiving server evaluates the envelope sender domain. It performs a DNS query to retrieve the **SPF policy** and checks whether the connecting IP address is authorized.

If the connecting server is not listed, the message may fail SPF. Depending on the receiving system’s policies and the sender’s DMARC configuration, this may contribute to quarantine, rejection, or an [NDR (Non-Delivery Report)](https://inc42.com/glossary/non-delivery-report-ndr/).

SPF supports email authentication, but it has limits. It does not validate the visible From header by itself, and forwarding can break SPF alignment unless carefully handled.

### SPF alongside DKIM and DMARC

SPF is strongest when combined with DomainKeys Identified Mail, commonly known as DKIM, and Domain-based Message Authentication Reporting and Conformance, or DMARC. SPF verifies authorized infrastructure, DKIM uses public key cryptography to sign messages, and [DMARC](https://autospf.com/blog/from-monitoring-to-enforcement-building-a-scalable-dmarc-strategy/) tells receivers how to handle alignment failures.

In this layered model, SPF helps stop email spoofing, **DKIM protects** message integrity, and DMARC provides a reporting and enforcement framework. DANE and a TLSA record then add protection for the transport path itself.

## Managing SPF Records Efficiently

![Spf Lookup 8209](https://media.mailhop.org/autospf/spf-lookup-8209-1784624194749.jpg)As organizations adopt Microsoft 365, Google Workspace, Amazon SES, SendGrid, HubSpot, Mailchimp, and other email platforms, SPF records become increasingly difficult to manage. **Multiple include mechanisms**, DNS lookup limits, and changing sender infrastructure can lead to authentication failures if records are not maintained.

[AutoSPF](https://autospf.com/) helps simplify SPF management by identifying unnecessary includes, keeping records within DNS lookup limits, and making it easier to maintain accurate SPF policies as email infrastructure evolves. While TLSA, DNSSEC, and DANE enhance transport security, maintaining a healthy **SPF record** remains a foundational step in protecting email authentication.

## DNSSEC as the Trust Layer: Protecting DNS Records From Tampering

DNSSEC is the foundation that makes DANE trustworthy. Without DNSSEC, an attacker could tamper with the DNS response for an MX record or TLSA record and redirect email to a hostile server. With DNSSEC, DNS data is cryptographically signed so a validating resolver can detect modification.

This is critical because DANE relies on DNS as a source of certificate truth. If the underlying [DNS infrastructure](https://medium.com/@ayushi.khare20/demystifying-dns-infrastructure-the-backbone-of-the-internet-700719da22ab) is not protected, the TLSA record cannot **provide reliable certificate validation**.

### Why DNSSEC matters for email authentication

Email depends heavily on DNS. A receiving system’s MX record tells other domains where to send messages. SPF, DKIM, DMARC, [MTA-STS](https://mailflowauthority.com/definitions/what-is-mta-sts), and DANE all rely on DNS-based policies or keys. That makes the integrity of DNS infrastructure central to modern email authentication.

DNSSEC protects these resource records through digital signatures. When a domain uses zone signing, each **signed record** can be validated back through a chain of trust to the DNS root.

#### Recursive resolver validation

A validating recursive **DNS resolver** checks DNSSEC signatures before returning answers to the sending system. If validation fails, the resolver treats the data as bogus rather than trustworthy.

This protects against forged DNS responses, poisoned caches, and other attacks on public DNS. _In the context of man-in-the-middle attacks, DNSSEC helps prevent attackers from substituting a fake MX record, malicious TLSA record, or downgraded DNS response._

## DANE and TLSA in Practice: Binding Certificates to Domains

![Spf Record Check 9766](https://media.mailhop.org/autospf/spf-record-check-9766-1784624292039.jpg)DANE is defined for SMTP in [RFC 7672](https://rfc-annotations.research.icann.org/rfc7672.html), published by the [Internet Engineering Task Force (IETF)](https://cyberhoot.com/cybrary/internet-engineering-task-force-ietf/). It extends Transport Layer Security by using DNSSEC-protected TLSA records to authenticate the receiving mail server’s certificate.

With DANE, a sending server first looks up the recipient domain’s MX record. It then checks whether the MX host has a valid TLSA record. If the TLSA record exists and is DNSSEC validated, the sender uses it during the **TLS handshake** to confirm that the certificate presented by the remote server is the expected one.

### How DANE changes SMTP protocol behavior

Traditional SMTP with opportunistic TLS encrypts when possible but may continue without strong identity verification if certificate validation fails. DANE changes that behavior. If DANE is present and valid, the sending server must enforce the TLSA record. If the certificate does not match, the sender should treat it as an SMTP DANE failure and defer or fail delivery rather than risk interception.

That is how DANE helps prevent man-in-the-middle attacks against the SMTP protocol. The attacker cannot simply present another certificate unless it matches the **DNSSEC-protected TLSA record**.

### DANE, MTA-STS, and Microsoft environments

MTA-STS, defined in RFC 8461, is another transport security standard. It lets a domain publish a domain policy requiring TLS for inbound mail. Unlike DANE, MTA-STS does not require DNSSEC; it relies on HTTPS policy hosting and [Web PKI](https://www.encryptionconsulting.com/web-pki-trust-framework/) certificate validation.

Microsoft supports transport security improvements across Exchange Online, and administrators may encounter **DANE, MTA-STS, and TLS reporting** guidance in the Microsoft Tech Community or product documentation. In a Microsoft 365 tenant, an IT Pro may manage an Accepted Domain in the Microsoft 365 Admin Center, verify domain status, and use [Exchange Online PowerShell](https://www.techtarget.com/searchwindowsserver/tutorial/How-to-use-PowerShell-for-Exchange-Online-monitoring) or PowerShell to inspect mail settings.

Administrators may also test connectivity with tools such as Microsoft Remote Connectivity Analyzer. _Example lab domains such as Contosotest.com, routing names such as Mx.microsoft, and older infrastructure like Windows Server 2012 R2 may appear in documentation or migration scenarios, but production DANE depends on correct DNSSEC, MX, TLS, and certificate configuration at the authoritative DNS provider or DNS registrar._

## How SPF, DNSSEC, and DANE Work Together to Strengthen Email Authentication

SPF, DNSSEC, and DANE solve different problems, but together they create a stronger email authentication and **transport security model**.

- **SPF answers the question:** “Is this sending server authorized to send for this domain?”
- **DNSSEC answers the question:** “Can I trust the DNS records I received?”
- **DANE answers the question:** “Does this receiving mail server’s TLS certificate match the DNSSEC-protected TLSA record?”

When combined, these controls improve both **sender validation** and transport protection. SPF helps with email spoofing prevention, DNSSEC secures the DNS infrastructure, and DANE uses the TLSA record to strengthen [Transport Layer Security](https://www.cloudflare.com/learning/ssl/transport-layer-security-tls/) for SMTP delivery.![Spf Flatterning 9733](https://media.mailhop.org/autospf/spf-flatterning-9733-1784624486162.jpg)

### Layered protection across mail flow

A typical secure mail flow might look like this:

1. The sending server queries DNS for the recipient domain’s MX record.
2. The DNSSEC-validating resolver confirms that the MX record is authentic.
3. The sender looks up the TLSA record for the **MX host**.
4. DNSSEC validates the TLSA record.
5. The sender opens an SMTP connection and negotiates Transport Layer Security.
6. The remote server presents an X.509 certificate.
7. The sender compares the certificate or Subject Public Key Info against the TLSA record.
8. Separately, the receiver checks **SPF, DKIM, and DMARC** for sender identity and policy alignment.

This layered approach reduces the risk of [man-in-the-middle attacks](https://www.malwarebytes.com/blog/news/2018/07/when-three-isnt-a-crowd-man-in-the-middle-mitm-attacks-explained), unauthorized sending, certificate substitution, and DNS tampering.

### Operational considerations for administrators

Administrators should avoid publishing a TLSA record until DNSSEC is correctly deployed and monitored. Broken DNSSEC can cause delivery failures, and an incorrect TLSA record can trigger an SMTP DANE failure. _Likewise, if an organization changes certificates but forgets to update the TLSA record, legitimate email delivery may be interrupted._

For resilient routing, some domains use more than one MX record, including a fallback MX record. Each MX host that supports DANE needs its own accurate TLSA record. If one MX record is DANE-enabled and another is not, the organization should understand how sending systems will **evaluate policy and routing**.

SPF also requires ongoing maintenance. Cloud senders, marketing platforms, helpdesk systems, and Microsoft Exchange Online services must be included properly. Overly broad **SPF policies** weaken protection, while missing senders can cause authentication failures.![Spf Permerror 6402](https://media.mailhop.org/autospf/spf-permerror-6402-1784623342044.jpg)

### Practical implementation checklist

A practical deployment plan should include:

- Confirm the domain’s authoritative [DNS provider](https://grokipedia.com/page/List%5Fof%5Fmanaged%5FDNS%5Fproviders) supports DNSSEC and TLSA resource records.
- Enable DNSSEC with proper zone signing and validate the chain of trust.
- Publish accurate MX record values before adding DANE.
- Generate the TLSA record from the active X.509 certificate or [Subject Public Key](https://stackoverflow.com/questions/74687281/understanding-subject-public-key-info-definition-and-indentation) Info.
- Use a SHA-256 hash for common TLSA deployments unless a specific standard requires otherwise.
- Maintain SPF for all authorized sending platforms, including Exchange Online where applicable.
- Align SPF with DKIM and DMARC to **strengthen email authentication**.
- Monitor for delivery issues, certificate rotations, domain status changes, and NDR events.
- Compare DANE with MTA-STS requirements where both email security standards apply.

SPF, DNSSEC, TLSA, and DANE each protect different parts of email communication. SPF authorizes sending servers, DNSSEC protects DNS records from tampering, and DANE uses TLSA records to verify [mail server](https://www.activecampaign.com/glossary/mail-server) certificates during encrypted SMTP delivery. Together with DKIM and DMARC, they create a layered defense that improves email authentication, transport security, and **protection against spoofing** and interception.

![Brad Slavin](https://media.mailhop.org/autospf/images/authors/brad-slavin.jpg) 

[ Brad Slavin ](/authors/brad-slavin/) 

General Manager

Founder and General Manager of DuoCircle. Product strategy and commercial lead for AutoSPF's 2,000+ customer base.

[LinkedIn Profile →](https://www.linkedin.com/in/bradslavin) 

## Ready to get started?

Try AutoSPF free — no credit card required.

[ Book a Demo ](/book-a-demo/) 

## Related Articles

[  Intermediate 6m  10 Reasons Why DIY-ing SPF isn’t a Good Choice for Companies  Apr 4, 2024 ](/blog/10-reasons-diy-ing-spf-isnt-good-choice-for-companies/)[  Intermediate 5m  The 12.4 billion shield for your email communications: Why DMARC software is the unsung hero in the war against phishing actors!  Nov 19, 2025 ](/blog/12-4-billion-dmarc-software-shield-protecting-email-from-phishing-actors/)[  Intermediate 3m  3 points to consider before setting your SPF record to -all (HardFail)  May 22, 2025 ](/blog/3-points-to-consider-before-setting-your-spf-record-hardfail/)[  Intermediate 3m  5 key contributors to the development of the Sender Policy Framework  Nov 12, 2024 ](/blog/5-key-contributors-to-sender-policy-framework-development/)

```json
{"@context":"https://schema.org","@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138897474","https://www.linkedin.com/company/autospf","https://x.com/autospf01","https://www.g2.com/products/autospf/reviews"],"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://autospf.com/contact-us/"},"knowsAbout":["SPF Record Flattening","Sender Policy Framework","Email Authentication","DNS Management","DMARC","DKIM"]}
```

```json
{"@context":"https://schema.org","@type":"WebSite","name":"AutoSPF","url":"https://autospf.com","description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","publisher":{"@type":"Organization","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]}}}
```

```json
{"@context":"https://schema.org","@type":"BlogPosting","headline":"TLSA Record Explained: How SPF, DNSSEC & DANE Strengthen Email Security","description":"Learn how TLSA records, SPF, DNSSEC, and DANE work together to secure email, prevent spoofing, validate certificates, and strengthen SMTP security.","url":"https://autospf.com/blog/tlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security/","datePublished":"2026-07-21T00:00:00.000Z","dateModified":"2026-07-21T00:00:00.000Z","dateCreated":"2026-07-21T00:00:00.000Z","author":{"@type":"Person","@id":"https://autospf.com/authors/brad-slavin/#person","name":"Brad Slavin","url":"https://autospf.com/authors/brad-slavin/","jobTitle":"General Manager","description":"Brad Slavin is the founder and General Manager of DuoCircle, the company behind AutoSPF, DMARC Report, Phish Protection, and Mailhop. He founded DuoCircle in 2014 to solve the SPF 10-DNS-lookup problem at scale and has led the company's growth to 2,000+ customers. Brad's focus is product strategy, customer relationships, and the commercial and compliance side of email authentication (DPAs, SLAs, enterprise procurement) rather than hands-on DNS engineering.","image":"https://media.mailhop.org/autospf/images/authors/brad-slavin.jpg","knowsAbout":["Email Security Strategy","SaaS Product Management","Enterprise Compliance","Customer Success","Email Deliverability Business"],"worksFor":{"@type":"Organization","name":"AutoSPF","url":"https://autospf.com"},"sameAs":["https://www.linkedin.com/in/bradslavin"]},"publisher":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com","logo":{"@type":"ImageObject","url":"https://autospf.com/images/autospf-logo.png"},"description":"Automatic SPF flattening and email authentication management. Resolve SPF lookup limits, flatten SPF records, and maintain email deliverability across all your domains.","parentOrganization":{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138883901","name":"DuoCircle LLC","url":"https://www.duocircle.com","sameAs":["https://www.wikidata.org/wiki/Q138883901","https://www.crunchbase.com/organization/duocircle-llc","https://www.linkedin.com/company/duocircle","https://github.com/duocircle"],"subOrganization":[{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138898167","name":"DMARC Report","url":"https://dmarcreport.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897474","name":"AutoSPF","url":"https://autospf.com"},{"@type":"Organization","@id":"https://www.wikidata.org/wiki/Q138897912","name":"Phish Protection","url":"https://www.phishprotection.com"}]},"sameAs":["https://www.wikidata.org/wiki/Q138897474","https://www.linkedin.com/company/autospf","https://x.com/autospf01","https://www.g2.com/products/autospf/reviews"],"contactPoint":{"@type":"ContactPoint","contactType":"customer support","url":"https://autospf.com/contact-us/"},"knowsAbout":["SPF Record Flattening","Sender Policy Framework","Email Authentication","DNS Management","DMARC","DKIM"]},"mainEntityOfPage":{"@type":"WebPage","@id":"https://autospf.com/blog/tlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security/"},"articleSection":"intermediate","keywords":"","image":{"@type":"ImageObject","url":"https://media.mailhop.org/autospf/spf-flatterning-2017-1784623019822.jpg","caption":"SPF DNSSEC DANE protection"},"speakable":{"@type":"SpeakableSpecification","cssSelector":[".answer-block","h1"]}}
```

```json
{"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://autospf.com/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://autospf.com/blog/"},{"@type":"ListItem","position":3,"name":"Intermediate","item":"https://autospf.com/intermediate/"},{"@type":"ListItem","position":4,"name":"TLSA Record Explained: How SPF, DNSSEC & DANE Strengthen Email Security","item":"https://autospf.com/blog/tlsa-record-explained-how-spf-dnssec-dane-strengthen-email-security/"}]}
```
