DMARC Analyzer

TL;DR

• DANE for SMTP (RFC 7672) authenticates the receiving SMTP server certificate using a TLSA record published in DNSSEC-signed DNS. The sender validates the STARTTLS certificate against the TLSA association before delivering mail.
• TLSA record location: _25._tcp.<mx-hostname> - port + protocol + the MX target hostname, underscore-prefixed.
• Canonical TLSA shape: 3 1 1 = Usage 3 (DANE-EE) + Selector 1 (SubjectPublicKeyInfo) + MatchingType 1 (SHA-256). The 64-character hex RDATA is the SHA-256 hash of the server certificate's SPKI.
• DNSSEC is mandatory. DANE without DNSSEC is meaningless - validating senders treat unsigned TLSA records as absent. The recipient zone must be signed end-to-end up to the root.
• Defeats STARTTLS stripping and SMTP MX downgrade attacks. An attacker who can rewrite SMTP responses on the wire cannot trick the sender into a plaintext delivery when DANE is enforced.
• Receiving-side adopters: Google (consumer Gmail since 2024), Microsoft 365, ProtonMail, Posteo, mailbox.org, Comcast, GMX, web.de, US .gov sector under BOD 18-01, German federal email under BSI TR-03108.
• Sending-side adopters: Google Workspace, Microsoft 365 (outbound since 2022), Comcast, Posteo, mailbox.org, ProtonMail, Hetzner. Postfix 3.0+ is the canonical receiver implementation.
• Single most common mistake: publishing the TLSA record without signing the zone with DNSSEC. The records are silently ignored by every validating sender.
• Coexists with MTA-STS (RFC 8461) - publish both for maximum coverage. See the comparison page for the decision matrix.

1. Overview: what DANE for SMTP solves

SMTP transport security has a structural problem: the STARTTLS command that upgrades a plaintext SMTP session to a TLS-encrypted one is advertised IN the plaintext part of the conversation. An attacker on the network path between sender and recipient can rewrite the server's EHLO response to remove the STARTTLS capability, and the sender, seeing no offer, falls back to plaintext delivery. The body, headers, and authentication data all travel in cleartext.

Even when STARTTLS succeeds, opportunistic TLS accepts almost any certificate - mismatched Common Name, self-signed, expired - because the alternative is plaintext delivery. An attacker who can manipulate DNS or BGP can route mail to an attacker-controlled MX with an attacker certificate and the sender will happily deliver over a TLS channel terminated at the attacker.

DANE for SMTP fixes both problems by binding the expected certificate to a DNSSEC-signed record at the MX hostname. The sender looks up _25._tcp.<mx> for a TLSA record, validates the DNSSEC chain on both the MX and TLSA lookups, and uses the resulting association to validate the STARTTLS certificate. If validation succeeds, mail is delivered over the authenticated TLS channel. If validation fails (and DNSSEC is secure), mail delivery aborts with a transient error - the sender refuses to deliver to an unauthenticated server.

DANE is older than MTA-STS (DANE TLSA is RFC 6698 from 2012; the SMTP profile in RFC 7672 is from 2015) and was the IETF's first attempt at SMTP transport authentication. MTA-STS (RFC 8461, 2018) was designed as a DANE-alternative that does not require DNSSEC. The two standards explicitly coexist - see MTA-STS vs DANE for SMTP for the comparison.

2. The threat model DANE addresses

DANE for SMTP defends the STARTTLS handshake against an attacker who can manipulate DNS responses, SMTP responses, or BGP routing. The specific attacks DANE blocks:

2.1 STARTTLS stripping

The attacker rewrites the SMTP server's EHLO response on the wire to remove the STARTTLS capability. The sender, seeing no offer, delivers in plaintext. Without DANE the sender cannot distinguish "server does not support TLS" from "attacker stripped the STARTTLS advertisement". With DANE the sender knows from the TLSA record that the recipient REQUIRES TLS - if STARTTLS is missing, the sender aborts delivery rather than falling back to plaintext.

2.2 SMTP MX downgrade

The attacker rewrites the DNS MX response to point the sender at an attacker-controlled mail server with an attacker certificate. Without DANE the sender accepts the certificate under opportunistic-TLS rules and delivers the message. With DANE the sender validates the DNSSEC chain on the MX record - if the chain is bogus (forged), delivery aborts; if it is secure, the sender uses the TLSA records at the attacker's MX hostname, which the attacker cannot publish without breaking DNSSEC for the victim zone.

2.3 Certificate substitution

The attacker terminates the TLS connection with a different valid certificate - one issued for a different name, or a self-signed cert, or a cert from a compromised CA. Without DANE the sender accepts the substitute under opportunistic TLS. With DANE the sender hashes the presented SPKI, compares to the TLSA RDATA, and aborts delivery if the hashes differ.

2.4 Compromised CA

A CA in the public root store mis-issues a certificate for the victim domain. Without DANE (and without CAA records and without certificate transparency monitoring), the mis-issued cert is trusted by the sender. With DANE Usage 3 (DANE-EE), the CA chain is NOT consulted - the TLSA record asserts the expected key directly, cutting the CA out of the trust path. A compromised CA cannot subvert a DANE-protected MX.

3. The three moving pieces

DANE for SMTP consists of three independent components that must all be correct for delivery to succeed:

3.1 DNSSEC-signed zone

The recipient zone must be DNSSEC-signed end-to-end up to the root. The MX records, the TLSA records, and every link in the chain (parent zone DS record, root signature) must validate. DNSSEC validation is the cryptographic integrity layer that gives the TLSA record its authenticity - without DNSSEC the TLSA RDATA is just an unauthenticated string an attacker can forge.

Common DNSSEC implementations: RFC 4033 (architecture), RFC 4034 (records), RFC 4035 (protocol). Managed DNS providers that support DNSSEC signing: Route 53, Cloudflare, Google Cloud DNS, DigitalOcean, Hetzner, Gandi, Hover, INWX. Self-hosted options: BIND dnssec-policy auto-signing, Knot DNS, PowerDNS with auto-signing.

3.2 TLSA resource record

The TLSA record is the DNS type defined in RFC 6698 (IANA-assigned RR type 52). It is published at a name constructed from the port and protocol of the protected service: for SMTP the standard location is _25._tcp.<mx-hostname>. One TLSA record per MX hostname; if a domain has multiple MX records at different priorities, each MX target needs its own TLSA record set.

3.3 STARTTLS-capable SMTP server

The receiving SMTP server must terminate STARTTLS with a certificate whose key matches the published TLSA association. The certificate does NOT need to be from a public CA when Usage is 3 (DANE-EE) - DANE explicitly supports self-signed certificates because the TLSA record IS the trust assertion. Major MTAs that work correctly with DANE on the inbound side: Postfix (any version), Exim 4.95+, Sendmail with TLS patches, Halon, Microsoft Exchange (with DANE inbound support announced for 2023).

4. The TLSA record format

A TLSA record has four fields per RFC 6698 section 2.1:

4.1 Usage field detail

Usage 0 (PKIX-TA): the Certificate Association Data identifies a CA certificate that MUST be in the certification path. The sender still runs the full PKIX validation against the public root store AND requires that the named CA appears in the chain. Tightens which CA can issue your cert.

Usage 1 (PKIX-EE): the data identifies the end-entity certificate that MUST be served. The cert STILL must validate normally against the public root store. Pins the leaf cert. Vulnerable to PKIX CA compromise (any valid leaf still passes PKIX).

Usage 2 (DANE-TA): the data identifies a trust anchor that REPLACES the public root store. The leaf certificate must chain to this trust anchor; the public CA system is NOT consulted. Useful for private CAs or self-administered hierarchies.

Usage 3 (DANE-EE): the data identifies the end-entity certificate or its key directly. NO PKIX validation is performed - the cert does not need to chain to ANY trust anchor. The TLSA record IS the entire trust assertion. This is the RECOMMENDED shape for SMTP per RFC 7672 section 3.1.3 because (a) it removes the CA dependency entirely, (b) it survives public CA compromise, (c) when combined with Selector 1 (SPKI) it survives certificate renewals as long as the key stays the same.

4.2 Selector field detail

Selector 0 (Cert): the data matches the full DER-encoded X.509 certificate. Every certificate renewal (including a renewal with the same key pair) changes the cert bytes and breaks the TLSA association. Operationally fragile - requires a TLSA rotation per certificate rotation.

Selector 1 (SPKI): the data matches just the SubjectPublicKeyInfo. A new certificate that reuses the same key pair has the same SPKI and stays bound to the same TLSA record. STRONGLY preferred for operational sanity - certificate renewals (which keep the key by default with most ACME clients) require zero DNS changes.

4.3 MatchingType field detail

MatchingType 0 (Full): the Certificate Association Data is the raw cert / SPKI bytes in hex - hundreds of bytes per record. Operationally heavy and rare in practice.

MatchingType 1 (SHA-256): 32-byte (64-hex-character) SHA-256 hash. The RECOMMENDED choice for SMTP - compact, widely implemented, cryptographically strong.

MatchingType 2 (SHA-512): 64-byte (128-hex-character) SHA-512 hash. Used where SHA-256 is considered insufficient (rare for transport-layer SMTP); also accepted by all DANE validators per RFC 6698.

5. The canonical TLSA shape: 3 1 1 (DANE-EE / SPKI / SHA-256)

Across the Internet's DANE-publishing zones the overwhelmingly dominant TLSA shape is 3 1 1 - Usage 3 + Selector 1 + MatchingType 1. RFC 7672 section 3.1.3 explicitly recommends this combination for SMTP. The reasoning:

• Usage 3 (DANE-EE) - cuts out the CA dependency. The TLSA record is the entire trust assertion. A compromised CA cannot mint a cert that subverts your MX. Self-signed certificates work natively.
• Selector 1 (SPKI) - keys rather than certificates are pinned. Certificate renewals that reuse the key pair (the default for Let's Encrypt / certbot, the default for ACME, the default for almost every cert-rotation tool) need zero DNS changes. Operationally cheap.
• MatchingType 1 (SHA-256) - compact (64 hex characters), widely implemented, cryptographically strong, no security concerns for transport-layer SMTP.

Observed in the wild for DANE-publishing receivers: every major German hoster (Posteo, mailbox.org, GMX, web.de, Hetzner) publishes 3 1 1. ProtonMail, Comcast, Microsoft 365, and consumer Gmail all publish 3 1 1. The US .gov sector under BOD 18-01 publishes 3 1 1. The BSI TR-03108 mandate specifies 3 1 1.

Other shapes (Usage 2, MatchingType 2, Selector 0) appear occasionally for specific deployments but are not the recommended starting point. Senders MUST accept any valid shape per RFC 6698 so operationally you can mix shapes during a migration - publish a 3 1 1 alongside a transitional 2 1 1 if rotating from a private CA to DANE-EE, for example.

6. Deployment recipe

The end-to-end deployment for a single MX hostname:

6.1 Confirm DNSSEC is signed

DANE requires DNSSEC end-to-end. Verify with dig:

dig +dnssec +short example.com SOA
dig +dnssec example.com DNSKEY +short
dig DS example.com @<parent-resolver>

The SOA response must include an RRSIG in the answer section, the DNSKEY query must return at least one KSK + ZSK, and the parent zone must publish a DS record pointing at the KSK. If any of these are missing, fix DNSSEC FIRST before publishing TLSA records.

6.2 Extract the SPKI and hash it

For each MX hostname's certificate, extract the SubjectPublicKeyInfo and hash with SHA-256:

# From a PEM certificate file:
openssl x509 -in mx.crt -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  sha256sum | awk '{print $1}'

# From a live STARTTLS endpoint:
openssl s_client -starttls smtp -connect mx.example.com:25 -servername mx.example.com 2>/dev/null | \
  openssl x509 -noout -pubkey | \
  openssl pkey -pubin -outform DER | \
  sha256sum | awk '{print $1}'

The output is a 64-character lowercase hex string - the SHA-256 hash of the SPKI. That string becomes the TLSA RDATA.

6.3 Publish the TLSA record

Add to the zone file:

_25._tcp.mx.example.com. IN TLSA 3 1 1 \
  abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789

One TLSA RR per MX hostname. If example.com has two MX records ( mx1.example.com and mx2.example.com ), publish two TLSA records, one at each MX's _25._tcp name. Re-sign the zone and confirm with dig +dnssec TLSA _25._tcp.mx.example.com - the answer must include both the TLSA record AND its RRSIG.

6.4 Verify with a DANE-validating sender

The fastest path to confirm DANE is working end-to-end is to test from a known-good validator:

# DANE validation via posttls-finger (Postfix 2.11+):
posttls-finger -t10 -T30 -L summary,verbose,untrusted \
  -P /etc/ssl/certs/ -l dane mx.example.com

# Online testers:
# - https://www.huque.com/bin/danecheck (well-maintained)
# - https://www.tlsa-generator.com/ (record builder + validator)
# - https://internet.nl/mail/ (full SMTP transport-security audit)

A successful test shows the TLSA record matched the presented certificate and the DNSSEC chain validated. A failed test shows where in the chain validation broke - missing RRSIG, SHA-256 mismatch, DNSKEY-DS mismatch, etc.

6.5 Add TLS-RPT for observability

Publish a TLS-RPT record at _smtp._tls.example.com per RFC 8460 to receive failure reports from DANE-validating senders. Without TLS-RPT a botched DANE deployment fails silently from the sender's perspective and you only discover the problem via bounce reports days later.

Example TLS-RPT record:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

See help_tls_rpt_explained.php for the full TLS-RPT deployment guide.

7. Provider support reference

DANE for SMTP support varies significantly by provider and by direction (sending vs. receiving). Up-to-date as of 2026:

7.1 Receivers (publishers of TLSA records)

• Google - consumer Gmail published TLSA on gmail-smtp-in.l.google.com in 2024. Google Workspace MX endpoints ( aspmx.l.google.com and siblings) publish TLSA records as part of the consumer rollout.
• Microsoft 365 - inbound DANE support rolled out in 2023 on *.mail.protection.outlook.com MX endpoints. Microsoft's official guide: Microsoft Learn / Exchange Online documentation.
• ProtonMail - publishes TLSA on all proton-managed MX endpoints since 2019.
• Posteo - long-standing DANE publisher (since 2016); the reference German privacy-focused mailbox provider.
• mailbox.org - publishes TLSA for all customer MX endpoints since 2017.
• Comcast - publishes TLSA on consumer comcast.net and business xfinity.com MX endpoints.
• GMX / web.de (German 1and1) - both publish TLSA on their public MX endpoints.
• US .gov sector - the BOD 18-01 binding operational directive mandated DANE for federal email; many agencies meet the requirement on their public MX endpoints.
• German federal email - BSI TR-03108 mandates DANE for federal executive-branch email in Germany.

7.2 Senders (validators of TLSA records)

• Google Workspace - outbound DANE validation since 2022; gradual rollout completed across all customer sending IPs.
• Microsoft 365 - outbound DANE validation since late 2022 / early 2023. Required reading: the M365 DANE outbound rollout post on the Microsoft Tech Community blog.
• Comcast - DANE validation on outbound consumer + business mail since 2018.
• Posteo, mailbox.org, ProtonMail - all three validate DANE on outbound mail natively.
• Hetzner / 1and1 IONOS / united.de - German hosters' outbound MTAs validate DANE natively.

7.3 MTA implementations

• Postfix 3.0+ - canonical DANE receiver and sender implementation. Sending side: smtp_dns_support_level = dnssec + smtp_tls_security_level = dane or dane-only. Receiving side: publish TLSA at _25._tcp.<mx>; Postfix does not need any special config to be DANE-served.
• Exim 4.95+ - DANE support via hosts_request_dane + dnssec_request_domains on the SMTP transport.
• OpenSMTPD - DANE support landed in version 6.7.0+.
• Microsoft Exchange / Exchange Online - inbound DANE rolled out 2023; outbound DANE rolled out 2022.

8. Key rollover without breaking mail

The two-record overlap pattern is the standard DANE rotation procedure:

1. Generate the NEW key pair and obtain the new certificate. Do NOT switch the SMTP server to the new cert yet.
2. Compute the SHA-256 SPKI hash of the new cert.
3. Publish the NEW TLSA record ALONGSIDE the existing TLSA record:

   _25._tcp.mx.example.com. IN TLSA 3 1 1 <old-hash>
   _25._tcp.mx.example.com. IN TLSA 3 1 1 <new-hash>

   Two TLSA records at the same name. RFC 7672 section 7 specifies that senders MUST accept any one of the published records.
4. Wait at least 2x the longest TTL of the TLSA record set for sender caches to refresh. Default TTL of 24h means wait 48h; many operators use a 1h TLSA TTL specifically to keep the rollover window short.
5. Switch the SMTP server to the new certificate. Senders accept either certificate during the overlap.
6. Wait one more TTL after the certificate switch (for senders that fetched the OLD cert + OLD TLSA pair to retry with the new cert during the overlap).
7. Remove the OLD TLSA record. Re-sign the zone.

Key reuse short-circuits this entire procedure: if you renew the certificate with the SAME key pair (the default behavior for Let's Encrypt certbot, the default for ACME clients, the default for most cert rotations), the SPKI is unchanged and the existing TLSA record continues to match. Zero DNS changes for a same-key renewal. This is the operational reason RFC 7672 recommends Selector 1 (SPKI).

9. Common mistakes

• Publishing TLSA without DNSSEC. Every validating sender silently ignores unsigned TLSA records. Symptom: mail continues to flow over opportunistic TLS; DANE is not actually enforced. Detection: dig +dnssec TLSA _25._tcp.<mx> returns the record without an RRSIG. Resolution: enable DNSSEC signing on the zone before claiming DANE.
• Wrong owner name. Publishing the TLSA record at the parent domain ( _25._tcp.example.com) instead of the MX hostname ( _25._tcp.mx.example.com) is the most common shape error. The MX RDATA names which target the TLSA record must accompany.
• Missing TLSA for secondary MX. A zone with two MX records but only one TLSA-protected MX hostname creates a hole - an attacker who can knock the primary MX offline drives senders to the unprotected secondary. Every MX hostname needs its own TLSA record set.
• Hashing the cert instead of the SPKI. When Selector is 1 the hash must be of the SubjectPublicKeyInfo, NOT the entire cert. A common scripting mistake is to sha256sum mx.crt directly, which hashes the PEM file (or the DER cert with Selector 0 semantics). Use the explicit openssl pipeline in section 6.2.
• Hashing in the wrong format. The hash input must be the DER bytes of the SPKI, not the PEM encoding. The openssl pipeline ... | openssl pkey -pubin -outform DER handles this; a manual cat pubkey.pem | sha256sum will produce the wrong hash.
• Not rotating the TLSA before the certificate. Switching the SMTP cert before the new TLSA record has propagated breaks delivery for every DANE-validating sender. Always publish the new TLSA, wait for propagation, THEN switch the cert.
• Selecting Selector 0 (full cert) when Selector 1 was intended. Every certificate renewal then breaks DANE unless the TLSA record is rotated in lockstep. Use Selector 1 for operational sanity.
• Forgetting to publish DS at the parent. A signed child zone with no DS record at the parent means the parent does not advertise the child as signed, so resolvers do not validate. The zone appears signed locally but unsigned to the Internet. Verify with dig DS example.com @parent-resolver.

10. Troubleshooting funnel

When DANE-validating senders report delivery failures (visible in TLS-RPT or in bounce messages mentioning "DANE", "TLSA", or "STARTTLS"), work the funnel from cheapest diagnostic to deepest:

1. Does DNSSEC validate? Run dig +dnssec example.com SOA - the response must include an RRSIG. Run delv example.com SOA - the AD (Authenticated Data) flag must be set ( ; fully validated in delv output). If DNSSEC is broken, fix that first.
2. Does the TLSA record exist and validate? dig +dnssec TLSA _25._tcp.<mx> - the answer must contain a TLSA record AND an RRSIG. If the RRSIG is missing the record is unsigned and DANE will not apply.
3. Does the TLSA hash match the currently-served cert? Run the openssl pipeline in section 6.2 against the live MX ( openssl s_client -starttls smtp ...) and compare to the published RDATA. A mismatch means the cert and the TLSA record have drifted - either the cert was rotated without updating TLSA, or the TLSA was generated against the wrong cert.
4. Does the test from an external validator pass? posttls-finger -l dane <mx> from any Postfix 2.11+ host - or one of the online validators in section 6.4. The validator output names the exact failure mode.
5. Are the TLS-RPT reports arriving? Check the rua= mailbox is receiving reports - DANE-validating senders submit TLS-RPT reports for each failure. If reports are not arriving, TLS-RPT itself may be misconfigured; see help_tls_rpt_explained.php.
6. Did the cert just rotate? If the cert was renewed in the last 24 hours and the renewal used a DIFFERENT key pair (some ACME workflows do this by default), the TLSA record is stale. Publish a new TLSA record for the new SPKI hash following the rollover procedure in section 8.

11. Frequently asked questions

What is DANE for SMTP?

DANE for SMTP (RFC 7672) is a transport- security standard that authenticates the receiving SMTP server certificate using a TLSA record published in DNSSEC-signed DNS. The sender looks up _25._tcp.<mx> for a TLSA record, validates DNSSEC on both the MX and TLSA lookups, and uses the association to verify the STARTTLS certificate. DANE defeats STARTTLS-stripping and SMTP MX downgrade attacks.

What is a TLSA record?

A TLSA record is the DNS resource record defined in RFC 6698 that associates a TLS certificate or public key with a domain. For SMTP the record lives at _25._tcp.<mx-hostname> with four fields: Usage, Selector, MatchingType, and the Certificate Association Data. The canonical SMTP shape is 3 1 1 - DANE-EE / SPKI / SHA-256.

Why does DANE for SMTP require DNSSEC?

DANE relies on DNSSEC for integrity. Without DNSSEC an attacker could simply forge a TLSA response that points at the attacker certificate. RFC 7672 section 2.2 mandates DNSSEC validation on both the MX and TLSA records - if either chain is bogus the sender MUST NOT use the association. If either chain is insecure (unsigned) DANE does not apply.

What does the TLSA notation 3 1 1 mean?

Usage 3 (DANE-EE - end entity, no PKIX), Selector 1 (SubjectPublicKeyInfo - match the public key only), MatchingType 1 (SHA-256 hash). The canonical SMTP shape per RFC 7672 section 3.1.3 - cuts CA out of the trust path, survives certificate renewals that reuse the key.

How do I generate a TLSA record for my SMTP server?

Extract the SubjectPublicKeyInfo, hash with SHA-256, hex-encode. With openssl: openssl x509 -in mx.crt -noout -pubkey | openssl pkey -pubin -outform DER | sha256sum. Publish as _25._tcp.mx.example.com IN TLSA 3 1 1 <hex>. After publishing, sign the zone and verify with dig +dnssec TLSA _25._tcp.mx.example.com.

Which mail providers support DANE for SMTP?

Receiving: Google (consumer Gmail since 2024), Microsoft 365, ProtonMail, Posteo, mailbox.org, Comcast, GMX, web.de, US .gov sector under BOD 18-01, German federal email under BSI TR-03108. Sending: Google Workspace, Microsoft 365 (outbound since 2022), Comcast, Posteo, mailbox.org, ProtonMail, Hetzner. Postfix 3.0+ is the canonical receiver implementation.

How do I rotate a DANE TLSA record without breaking mail?

Two-record overlap: publish the NEW TLSA alongside the OLD, wait at least 2x the TTL for cache propagation, switch the server certificate, wait one more TTL, remove the old TLSA. With Usage 3 + Selector 1 the rotation only matters when the KEY changes - certificate renewals that reuse the same key (the default for ACME clients) need zero DNS changes.

What happens if my DNSSEC validation fails for DANE?

Per RFC 7672 section 2.2, a sender that detects a bogus DNSSEC chain MUST NOT use the TLSA association AND MUST treat the delivery attempt as a transient failure - the sender retries later. Bogus DNSSEC is treated as an active attack signal, not a fallback opportunity. Unsigned (insecure) chains mean DANE does not apply and the sender uses MTA-STS or opportunistic TLS.

Can DANE for SMTP be deployed alongside MTA-STS?

Yes - this is the recommended pattern. The standards explicitly coexist (RFC 7672 section 1.3). A sender that supports both prefers DANE when a TLSA record is present and DNSSEC validates, and falls back to MTA-STS when DANE does not apply. Publishing both means DANE-capable senders use the DNSSEC-based binding and others use the MTA-STS policy. See help_mta_sts_vs_dane.php for the comparison.

12. Related guides

• Email security glossary - the TRANSPORT-SECURITY-DANE-TLSA- DNSSEC-AITM-MITM-STARTTLS-DOWNGRADE-MX- SUBSTITUTION-VOCABULARY-CONSUMER companion to this DANE pillar. Where THIS page documents the DANE protocol at the byte level (the RFC 7672 _25._tcp.<mx-target> TLSA record location, the four certificate-usage parameter values PKIX-TA / PKIX-EE / DANE-TA / DANE-EE, the two selector parameter values cert / spki, the three matching-type parameter values full / SHA-256 / SHA-512, the DNSSEC chain-of-trust requirement on the receiving zone, the SMTP-receiver-side TLSA-record-fetch-and-match algorithm per RFC 7672 §3.1, the deployment cookbook for ED25519 / RSA-2048 key material, the rotation cookbook for the dual-TLSA overlap window during certificate renewal), the email- security-glossary spoke is the VOCABULARY-DEFINITION-REFERENCE companion documenting the canonical definitions for every term-of-art this DANE pillar uses in the body text without inline glossing — readers arriving from a Google search for "what is TLSA" or "what is DNSSEC chain-of-trust" or "what is AiTM" or "what is STARTTLS downgrade" need the glossary spoke to establish the vocabulary baseline before they can productively read THIS page's protocol-level deep dive. The DANE-vs-glossary relationship is pillar-and-vocabulary-reference: THIS page is the canonical RFC 7672 protocol pillar; the glossary spoke is the cross-cluster vocabulary hub the protocol pillar shares with every other transport-security / message-authentication / threat- catalogue / receiver-side pillar in the help cluster, and a reader moving between this DANE pillar and an adjacent transport-security pillar (MTA-STS, TLS-RPT) or threat-catalogue pillar (DMARC attacker-bypass, email-spoofing, business-email-compromise) needs the glossary spoke to bridge the cross-pillar vocabulary translation. Read the glossary spoke when the reader has not yet established the baseline vocabulary for transport- security terms — TLSA, DNSSEC, chain-of-trust, AiTM, MITM, STARTTLS, downgrade attack, opportunistic-TLS vs forced-TLS, certificate-usage / selector / matching-type / TLSA-record-fetch / TLSA-record-match, MX-substitution attack — each defined in the glossary with the canonical RFC anchor, the cross-pillar links to the pillar deep dives, and the operator-side context for when each term-of-art appears in an aggregate- report or RUF-forensic-report row, in an inbound message's Authentication-Results header, or in a receiver-side log artifact.
• MTA-STS vs DANE for SMTP - the side-by-side comparison frame off the MTA-STS pillar. Read this AFTER this page to understand how DANE relates to the DANE-alternative MTA-STS (RFC 8461) and when to deploy each.
• DKIM-Signature header anatomy (byte-level field reference) - the byte-level reference for the message-layer authentication header that rides INSIDE the TLS-encrypted SMTP session DANE protects — the orthogonal-trust-models companion to this page. Where DANE authenticates the TRANSPORT (does the receiving MX present a certificate whose public-key hash SHA-256-matches the TLSA record published at _25._tcp.<mx-target>, with DNSSEC-anchored trust per RFC 7672 §3.1?), DKIM authenticates the MESSAGE (does the cryptographic signature in the DKIM-Signature header validate against the public key at <selector>._domainkey.<d-tag> per RFC 6376 §3.5?). A message that traverses a DANE-validated transport gives the receiver TWO independent trust signals: the DNSSEC-anchored cryptographic authentication of the sending MTA's certificate (DANE) AND the DKIM-public-key-anchored cryptographic authentication of the signing domain claimed in the DKIM-Signature d= tag (DKIM). Read this when understanding what trust signal DANE does NOT provide: DANE verifies the identity of the receiving MX's TLS certificate, not the identity of the sending domain — a message can pass DANE (delivered to the right receiving MX over a TLSA-matched TLS chain) but fail DKIM (the DKIM-Signature header's body hash mismatched after a content-modifying intermediate rewrote the body, or the b= signature value failed to verify after canonicalisation drift). The two protocols protect DIFFERENT attack surfaces: DANE prevents on-path TLS downgrade and MX-substitution attacks via DNSSEC-anchored certificate-hash binding; DKIM prevents in-transit message-content tampering and From-header forge (in combination with DMARC identifier alignment). Note that DANE and DKIM share ONE substrate dependency — both rely on DNS publishing — but DANE additionally requires DNSSEC on the receiving zone for the TLSA RR validation chain, while DKIM requires NO DNSSEC on the signing zone for the <selector>._domainkey.<d-tag> TXT lookup (DKIM treats the public-key-DNS-publish as inherently unauthenticated; signature verification IS the authentication). Deploy both and the receiver gets DNSSEC-anchored transport-layer trust (the MX certificate was the right certificate) plus DKIM-signature-anchored message-layer trust (the message content was not tampered with after the signing MTA).
• MTA-STS explained (pillar) - the MTA-STS-only deep dive. The DANE-alternative covered in this page's section 1; uses the public web PKI plus HTTPS-fetched policy file instead of DNSSEC.
• MTA-STS policy file syntax (byte-level reference) - the byte-level reference for the mta-sts.<domain>/.well-known/mta-sts.txt HTTPS-fetched policy file that the DANE-alternative protocol publishes. Where THIS pillar walks through DANE's DNSSEC-anchored TLSA record (the TLSA 3 1 1 <hash> directive at _25._tcp.<mx-target> binding the receiving MX's certificate to the chain-of-trust anchored in the root zone), the MTA-STS-policy-syntax spoke documents the orthogonal HTTPS-fetched policy file's verbatim grammar: version: STSv1 (must be the first directive), mode: enforce vs mode: testing vs mode: none (the deployment rollout flag), the multi-line mx: directive enumerating receiver MX hostnames (with * wildcards permitted at the leftmost label only), and max_age: (in seconds, 86400 minimum for production deployments). Read this when designing a DANE-vs-MTA-STS deployment matrix and needing the policy-file byte-shape for the MTA-STS side of the orthogonal-trust-models comparison.
• MTA-STS for Google Workspace (provider deployment) - the provider-specific deployment walkthrough for the alternative transport-security protocol on a Google Workspace tenant. Where THIS pillar walks through DANE deployment in the abstract (publish TLSA at _25._tcp.<mx-target>, DNSSEC-sign the chain from root to your zone, rotate via the dual-active overlap window), the Workspace MTA-STS spoke documents the provider-specific MTA-STS deployment on the aspmx.l.google.com / alt1-4.aspmx.l.google.com MX cluster (or the single smtp.google.com entry for tenants migrated to the simplified MX configuration), Workspace-aligned external HTTPS hosting options (Firebase Hosting and Cloud Run for instant custom-domain HTTPS, Cloud Storage + Cloud CDN with Cloud Load Balancing for tenants with existing GCP infrastructure), the absence of any Admin Console / Postmaster Tools MTA-STS panel, and Gmail's role as an MTA-STS-honoring sender since 2018. Read this when running a Workspace tenant where DANE inbound is NOT the strict deployment requirement (Workspace inbound accepts opportunistic TLS by default and the MX targets at aspmx.l.google.com do not publish TLSA records — so DANE applies only to OUTBOUND-from-Workspace flows to DANE-publishing third-party domains, not to senders delivering INBOUND to your Workspace tenant). The two protocols can be deployed in parallel per RFC 7672 §1.3 coexistence — Workspace tenants commonly publish MTA-STS for inbound TLS-enforcement and rely on Gmail's DANE-honoring outbound flow to deliver DANE-protected mail to receivers that publish TLSA records.
• MTA-STS for Microsoft 365 (provider deployment) - the provider-specific deployment walkthrough for the alternative transport-security protocol on a Microsoft 365 / Exchange Online tenant. Where THIS pillar walks through DANE deployment in the abstract (publish TLSA at _25._tcp.<mx-target>, DNSSEC-sign the chain from root to your zone, rotate via the dual-active overlap window), the M365 MTA-STS spoke documents the provider-specific MTA-STS deployment on the <tenant>-com.mail.protection.outlook.com MX target (where <tenant>-com is the dashed transformation of your accepted domain), the M365-aligned external HTTPS hosting options (Azure Static Web Apps and Azure Front Door for tenants standardised on Azure, Cloudflare Pages or Cloudflare Workers with custom-hostname HTTPS, AWS S3 + CloudFront, GitHub Pages with custom-domain Let's Encrypt — Microsoft 365 does NOT host the policy file natively; Exchange Online is a mail platform, not a web platform), the absence of any Defender-portal / Exchange Admin Center MTA-STS panel, and the hybrid-tenant MX-cutover discipline (when on-prem Edge Transport servers route through an on-prem MX alongside the M365 MX, both must be enumerated in the mx: directive). Read this when running an M365 tenant where DANE is architecturally unavailable as an inbound option — the protection.outlook.com MX cluster does NOT publish TLSA records and Microsoft has not committed to a DANE-inbound roadmap, so MTA-STS is the ONLY TLS-enforcement option for senders delivering INBOUND to your M365 tenant. The DANE-vs-MTA-STS coexistence pattern under RFC 7672 §1.3 still applies in the OUTBOUND direction, but Exchange Online outbound currently does NOT honor TLSA records on receiver MX targets — so for M365 tenants the DANE pillar's relevance is primarily about understanding the alternative-trust model their senders may already be using when delivering DANE-protected mail to other DANE-publishing domains.
• TLS-RPT (SMTP TLS Reporting) - the observability standard (RFC 8460) that receives failure reports from DANE-validating AND MTA-STS-validating senders. The operational glue: without TLS-RPT a botched DANE deployment fails silently.
• TLS-RPT report format (RFC 8460 §4 JSON schema) - the operational reference for the JSON payload this pillar's TLSA records cause receivers to deliver to your rua= URI when DANE validation fails. Where the TLS-RPT explained page introduces the reporting channel at a conceptual level, the report-format page documents the byte-level structure operators must parse to diagnose DANE deployment problems: the policies[].policy.policy-type = tlsa path that distinguishes DANE-reported sessions from MTA-STS-reported sessions, the policies[].policy.policy-string carrying the verbatim TLSA RR data that the validating sender fetched and applied, the policies[].policy.mx-host recording the receiving-MX hostname the sender attempted, the policies[].summary with per-MX success / failure session counts that show whether DANE validation is succeeding overall, the policies[].failure-details array with the four canonical DANE-specific result-type values (tlsa-invalid when the TLSA RR exists but the certificate did not match the published association, dnssec-invalid when the DNSSEC chain to the TLSA RR failed validation - the structural prerequisite from this pillar's section on the DNSSEC-bound trust anchor, dane-required when the sender requires DANE but found no DNSSEC-validated TLSA record, and validation-failure when a more general PKIX validation failure occurred during the TLS handshake), plus the shared general result-type values that apply to DANE flows too (starttls-not-supported, certificate-not-trusted, certificate-expired), the Content-Type/filename/MIME conventions receivers use, and the redelivery semantics. Read this page once you have deployed DANE per the section 6 procedure on this pillar and TLS-RPT reports start arriving in your ingestion mailbox - this is the byte-level reference for acting on every tlsa-invalid / dnssec-invalid / dane-required / validation-failure row in the payload.
• TLS-RPT DNS record syntax (RFC 8460 §3) - the byte-by-byte syntax-layer reference for the _smtp._tls.<domain> TXT record a DANE operator publishes to RECEIVE the JSON failure reports the report-format spoke above documents. The TLS-RPT explained pillar entry above introduces the reporting channel as a concept; the report-format spoke above documents the JSON payload structure with the four DANE-specific result-type values; this record-syntax spoke completes the three-page TLS-RPT cluster by documenting the publishing-side DNS record DANE operators publish alongside the _25._tcp.<mx-host> TLSA records this pillar documents. The single TLS-RPT TXT record at _smtp._tls.<domain> covers reporting for BOTH MTA-STS and DANE deployments (receivers send the same JSON to the same rua= destination regardless of which transport-security policy was in force) — so DANE operators get observability of their TLSA-record deployment by publishing ONE additional DNS record documented byte-by-byte on this page. Covers the tag grammar (v=TLSRPTv1 floor case sensitive, rua=mailto: / rua=https: destination URIs, the !-separated multi-URI list semantics, the optional size_limit= extension that caps per-report payload size), the cross-domain authorisation contract for off-domain rua URIs (RFC 8460 §3.2 well-known-token authorisation that prevents amplification attacks via third-party reporting destinations), and the 255-octet TXT-string chunking rule for DNS providers that auto-split or require manual chunking. Read this once you have deployed TLSA records per section 6 of this pillar and need the operational reference for authoring the TLS-RPT TXT record that turns the silent dnssec-invalid / tlsa-invalid failure modes from this pillar's troubleshooting section into JSON failure samples operators can act on.
• MX records explained - the foundational DNS layer DANE binds to. Every TLSA record is published at _25._tcp.<mx-target>; the MX-target layer is the structural prerequisite. Covers the no-CNAME-as-MX- target rule (RFC 2181 §10.3) and the canonical MX hostnames at the major providers.
• Reverse DNS / PTR records for mail servers — the DANE-FOR-SMTP-TLSA-CERTIFICATE-PIN- IS-ANCHORED-AT-MX-HOST-FQDN-WHOSE- CONNECTING-IP-MUST-FCRDNS-VERIFY-AGAINST- THAT-SAME-FQDN companion to this RFC 7672 DANE-for-SMTP pillar. Where THIS page documents the TLSA certificate-pin publication mechanics (the _25._tcp.<mx-target> TLSA-RR publication coordinate; the usage / selector / matching-type parameter triple; the PKIX-TA / PKIX-EE / DANE-TA / DANE-EE certificate-usage discipline; the DNSSEC-signed-zone prerequisite for the TLSA-record authentication chain), the reverse-DNS-PTR spoke documents the IN-ADDR.ARPA / IP6.ARPA PTR-RR publication discipline whose Forward-Confirmed reverse DNS verification is the IP-IDENTITY-LAYER verification protocol that operates AT THE SAME MX-HOST-FQDN boundary the TLSA-record-publication this page documents is anchored at. The relationship between DANE-TLSA-pin verification and FCrDNS verification at the MX-host-FQDN boundary is STRUCTURED across FIVE operationally-load-bearing dimensions: (i) DANE-TLSA-PIN-PUBLICATION-AT-MX-HOST-FQDN- PREREQUISITE — the MX-host FQDN that the TLSA record is published at MUST be the SAME FQDN as the connecting-MTA-IP's forward-confirmed reverse DNS resolves to; an FCrDNS-fail at the connecting IP means the connecting MTA's claimed identity does not match the TLSA-pin's FQDN — the TLSA-pin verification still works cryptographically but the IP- identity claim the TLSA-pin presupposes is unverified; (ii) RECEIVER-SIDE STARTTLS SESSION-NEGOTIATION CONNECTING-IP ATTRIBUTION — at receiver-side inbound MX, the connecting outbound MTA's IP appears as the TCP-connection peer; the receiver's STARTTLS-session opens against a certificate whose subject is the MX- host FQDN — DANE verifies the X.509 certificate's binding to the FQDN, but the IP-identity layer's FCrDNS verification EXISTS IN PARALLEL to verify the connecting IP itself; (iii) DNSSEC-AS- DANE-PREREQUISITE-AND-DNSSEC-PROTECTS-PTR- RR-FROM-OFF-PATH-TAMPERING — for DANE to operate at all, the publisher's DNS zone MUST be DNSSEC-signed; DNSSEC also protects in-addr.arpa / ip6.arpa PTR-RRs when the IP-block-owning organization publishes DNSSEC-signed reverse DNS zones, so the FCrDNS verification protocol becomes ANALOGOUSLY-DNSSEC-PROTECTED at the IP-identity layer when DANE is deployed at the message-authentication layer; (iv) FORENSIC-ATTRIBUTION-OF- DANE-TLSA-VALIDATION-FAILURE-SOURCE-IP — when a TLSA-validation failure is observed via TLS-RPT (RFC 8460), the receiver's forensic investigation begins with the in-addr.arpa PTR-RR lookup on the connecting-MTA-IP to attribute the connection to the IP-block-owning organization (the upstream ISP, the cloud provider, the colocation facility — discovered via PTR delegation chain and whois lookup of the IP block); (v) OPERATOR-DISCIPLINE FOR DANE-DEPLOYING PUBLISHERS — every outbound-mail-sending IP in the operator's DANE-deployed outbound MTA fleet MUST publish a forward-confirmed PTR-RR pointing at the SAME MX-host FQDN whose TLSA record the publisher publishes; the absence of a forward-confirmed PTR at the outbound sending IP produces a receiver-side FCrDNS-fail verdict that REDUCES receiver-side trust in the DANE-validated connection even though the TLSA cryptographic verification passes. Read the reverse-DNS-PTR spoke when constructing the DANE-for-SMTP deployment — the spoke documents the IP-identity- layer companion discipline that operates at the SAME MX-host-FQDN boundary as the TLSA-record-publication discipline this pillar treats.
• Email authentication cluster intro - the cluster-spanning primer covering DMARC, SPF, DKIM, BIMI, MTA-STS, DANE, TLS-RPT, and CAA together.
• DMARC primer (help hub) - the DMARC-specific pillar with the Related Guides index linking back to every topic-cluster spoke.
• CAA records explained - the issuance-time CA authorisation standard (RFC 8659). CAA controls which CAs can issue certs for your domain at the issuance step; DANE controls which certs senders accept at the delivery step. Complementary not competing.
• DNS propagation - the operational-timing reference for the TLSA rollover procedure in section 8. TTL-based propagation determines how long the overlap window must be.
• DMARC record tags explained - DMARC sits at the application layer; this page covers transport. Both are part of the complete email security stack.
• DMARC forensic reports (RUF / AFRF) — the DANE-TRANSPORT-LAYER-VALIDATION- FAILURE-STRUCTURALLY-SUPPRESSES- APPLICATION-LAYER-RUF-AFRF-GENERATION companion to this DANE-for-SMTP pillar. Where THIS page documents the DNSSEC-anchored TLSA-record publication discipline at _25._tcp.<mx-host> and the RFC 7672 §3 four-step receiver- side validation procedure (TLSA RR retrieval, certificate-usage parameter evaluation, selector + matching-type comparison, TLS leaf-certificate hash verification), the DMARC-forensic-reports (RUF) spoke documents the APPLICATION- LAYER per-message AFRF evidence-stream whose generation is STRUCTURALLY GATED by the receiver's successful DANE validation at the SMTP transport-layer BEFORE the receiver's DKIM/SPF/DMARC evaluators ever process the message payload at all. The DANE-TRANSPORT- LAYER-VALIDATION-FAILURE-STRUCTURALLY- SUPPRESSES-APPLICATION-LAYER-RUF-AFRF- GENERATION cross-reference establishes FOUR structurally-distinct DANE-failure- mode-vs-RUF-AFRF-suppression dimensions: (i) DNSSEC-bogus-TLSA-record- validation-failure-suppresses-AFRF- generation-entirely dimension — when the receiver-side resolver returns a DNSSEC-validation-failed (bogus) TLSA record per RFC 6698 §2.1, the receiver per RFC 7672 §2.2 MUST treat the connection as authenticated-failure and reject the SMTP session with a 4xx temporary-failure response BEFORE the DATA command; the message NEVER reaches the application-layer DKIM/SPF/ DMARC evaluators, so NO RUF AFRF evidence is generated for the rejected message — the publisher's incident- response forensic-evidence inventory is STRUCTURALLY DEPRIVED of the per-message AFRF artifact for the rejected-via-DANE-bogus-TLSA event; (ii) TLSA-certificate-usage- mismatch-failure-suppresses-AFRF- generation-at-DANE-EE-cert-pinning- layer dimension — the TLSA certificate-usage parameter (PKIX-TA / PKIX-EE / DANE-TA / DANE-EE per RFC 6698 §2.1.1) determines whether the receiver validates the leaf-certificate against a public CA chain or against the DANE-pinned certificate hash; a DANE-EE-mode pin where the receiver observes a certificate that does NOT match the pinned hash terminates the SMTP session at the TLS handshake BEFORE the DATA command, suppressing AFRF generation for the rejected-via- DANE-EE-mismatch attack-attempt event; (iii) STARTTLS-downgrade-AiTM- attack-bypassing-DANE-suppresses-AFRF- AT-RECEIVER-side-evaluation-AT-DANE- DOWNGRADE-DETECTION-AT-RECEIVER-MTA- layer dimension — when an Adversary-in-the-Middle attempts to strip STARTTLS during the SMTP negotiation but the receiver enforces DANE per RFC 7672 §2.2 (downgrade- resistant), the receiver rejects the connection at the TLS-negotiation layer; the rejection prevents the message from reaching the application- layer authentication evaluators — STRUCTURALLY suppressing AFRF generation for the AiTM-attempted delivery, leaving the publisher's SIRT to rely on TLS-RPT per RFC 8460 for the transport-layer evidence of the attempted attack rather than the DMARC RUF AFRF channel; (iv) DANE-PROTECTED-vs-DANE- UNPROTECTED-receiver-cohort-split- produces-asymmetric-AFRF-evidence- availability-AT-DANE-COVERAGE-GAP- DETECTION-AT-OPERATOR-INVENTORY-layer dimension — DANE deployment is non-uniform across the receiver ecosystem (DANE adoption is high among German .de TLD / Comcast / posteo.de / mailbox.org / Microsoft Exchange Online Protection in 2024-2026; non- DANE receivers fall through to MTA-STS or opportunistic-TLS) — for the publisher's RUF AFRF stream this produces an ASYMMETRIC evidence- availability profile: DANE-protected- receiver cohorts emit AFRF evidence ONLY for attacks that bypass DANE at the application layer (e.g., compromised legitimate sender whose outbound TLS is DANE-validated by the receiver but whose DKIM-Signature fails alignment); non-DANE-protected- receiver cohorts emit AFRF evidence for ALL application-layer failures including the AiTM-attempted classes DANE-protected receivers reject at the transport layer. Read this RUF- forensic-reports spoke alongside THIS DANE-for-SMTP pillar when authoring the cross-layer incident-response playbook that uses both TLS-RPT transport-layer evidence AND DMARC AFRF application-layer evidence to reconstruct the per-message attack- attempt timeline across the DANE- protected and non-DANE-protected receiver cohort split.
• SPF explained - the IP authorisation layer of email authentication.
• Why SPF alone is insufficient — the DANE-TLSA-TRANSPORT-LAYER- DEFENSE-AS-LOAD-BEARING-CROSS-PROTOCOL- LAYER-COMPLEMENT-TO-APPLICATION-LAYER- SPF-WHOSE-ALONE-INSUFFICIENCY-MOTIVATES- CROSS-PROTOCOL-LAYER-DEFENSE-IN-DEPTH companion to this DANE-for-SMTP transport- security reference. Where THIS page documents the per-publisher per-MX-host DANE-TLSA RR-publication discipline (the _25._tcp.<mx-host> TLSA-record DNSSEC-anchored per-MX-host cryptographic-trust-anchor publication as the per-publisher per-receiver per- MX-host inbound-SMTP TLS-handshake cryptographic-validation discipline), the why-SPF-alone-is-insufficient spoke is the per-publisher-per-receiver defense-in-depth motivation reference whose per-attack-class arguments establish per-source-IP application- layer SPF authorization as STRUCTURALLY INCOMPLETE at FOUR per-cross-protocol- layer-defense rebuttal-evidence dimensions: (i) per-source-IP application-layer SPF-alone-publication leaves per-MX-host transport-layer MITM-downgrade-attack-surface ungated gap — per-source-IP application- layer SPF publication discipline cannot defend against per-MX-host transport- layer MITM-downgrade-attacks (StripTLS, certificate-substitution, BGP-hijack- induced MX-server impersonation); the per-publisher per-receiver per-MX-host TLS-handshake cryptographic-validation REQUIRES per-MX-host DANE-TLSA-RR- publication discipline as transport- layer cryptographic-trust-anchor; (ii) per-source-IP application-layer SPF-aligned-pass under TLS-stripped transport-leg is per-attacker-readable per-message payload gap — per- source-IP per-message SPF-aligned-pass delivered over per-MX-host TLS-stripped transport-leg leaves per-publisher per- receiver per-message payload per- attacker-readable in-flight; per-source- IP SPF-alone cannot enforce per-MX-host transport-layer confidentiality without per-publisher per-MX-host DANE-TLSA cryptographic-trust-anchor publication; (iii) per-publisher per-MX-host DANE-TLSA-RR DNSSEC-anchored cryptographic- trust-anchor as load-bearing cross- protocol-layer complement to per-source- IP application-layer SPF-record DNS- unauthenticated publication — per-source-IP SPF-record DNS-publication without DNSSEC-anchored zone-signing is per-attacker per-RR-spoofable; per- publisher per-MX-host DANE-TLSA-RR DNSSEC-anchored publication establishes the per-publisher per-receiver cross- protocol-layer cryptographic-trust-anchor chain (DNSSEC-anchored TLSA-RR + application-layer SPF-record + per- message DKIM-Signature) the per-receiver per-publisher per-receiver per-message delivery REQUIRES for full defense-in- depth; (iv) per-publisher per- receiver per-day per-MX-host TLS-RPT- aggregate-report transport-layer observability as load-bearing per- publisher operational-feedback stream complementing per-source-IP DMARC- aggregate-report application-layer observability — per-publisher per-source-IP DMARC-aggregate-report application-layer observability alone is STRUCTURALLY INCOMPLETE; per-publisher per-receiver per-day per-MX-host TLS- RPT-aggregate-report transport-layer observability is the load-bearing per- publisher operational-feedback complement for per-publisher per-MX-host DANE-TLSA- rollout per-day per-MX-host TLS- handshake-success-rate floor monitoring.
• SPF mechanisms explained (per-directive RFC 7208 §5 reference) - the DANE-TLSA-MX-HOST-CERT-PINNING- AT-SAME-MX-HOST-THE-SPF-mx-MECHANISM- AUTHORIZES cross-protocol companion to this DANE-for-SMTP reference. Where THIS page documents the DANE TLSA record- publication at _25._tcp.<mx-host> whose DNSSEC-anchored binding pins the per-MX-host TLS leaf certificate for inbound-SMTP STARTTLS verification, the SPF-mechanisms-explained spoke is the STRUCTURAL-PARALLEL per-MX-host authorization-set derivation reference at the outbound-SPF-sender-authorization layer — the SAME per-MX-host identity anchor that DANE pins for inbound TLS- cert-binding is also the load-bearing DNS substrate the SPF mx: mechanism resolves for outbound-sender authorization. The DANE-TLSA-MX-HOST- ANCHOR-VS-SPF-mx-MX-HOST-ANCHOR cross- reference establishes FOUR structurally- distinct dimensions where the spoke's per-directive mx: reference shares the MX-host identity anchor with the DANE TLSA pinning discipline THIS page documents: (i) DANE TLSA pins MX-host's TLS leaf cert AT SAME MX host the SPF mx: mechanism authorizes for sender IP — cross-protocol shared identity anchor — the spoke documents that the SPF mx: mechanism resolves the MX-record-host-list at the publisher's domain and uses the resolved MX hosts' A records as the per-host outbound-sender authorization set, paralleling THIS page's DANE TLSA record-publication at _25._tcp.<mx-host> which pins the SAME MX host's inbound- SMTP TLS leaf cert — both DANE TLSA and SPF mx: anchor at the per-MX-host identity, creating a cross-protocol shared-anchor pattern operators must coordinate when publishing both DANE TLSA records (inbound-protect) and SPF mx: records (outbound-authorize) at the same MX-host substrate; (ii) DNSSEC-anchored TLSA chain vs unauthenticated SPF mx: A-record resolution — security-tier gap at the per-MX- host identity anchor — the spoke documents that the SPF mx: mechanism's per-MX-host A-record resolution occurs over UNAUTHENTICATED DNS (no DNSSEC requirement per RFC 7208), paralleling THIS page's RFC 7672 DANE-TLSA requirement for DNSSEC-signed delegation at the TLSA record-publication zone — operators publishing DANE TLSA at DNSSEC-signed zones get a stronger DNS-poisoning-resistance guarantee for the per-MX-host identity anchor than the SPF mx: mechanism's unauthenticated A-record resolution provides — the spoke's per-directive mx: reference clarifies this security-tier asymmetry the publisher must understand when coordinating DANE-protected inbound + SPF-mx-authorized outbound at the same MX-host; (iii) TLSA record-set cardinality (per-MX-host multiple TLSAs) parallels SPF mx: mechanism's per-MX- host A-record cardinality — the spoke documents that the SPF mx: mechanism's per-MX-host A-record resolution may return multiple A records per MX-host (multi-homed MX hosts), each consuming evaluation- budget bandwidth at the receiver- side §4.6.4 ten-DNS-lookup ceiling, paralleling THIS page's per-MX-host TLSA-record-set cardinality where multiple TLSA records per MX host (key-rotation overlap, multi-cert- chain support) each provide independent cert-pinning anchors — in both protocols the per-MX-host record-set cardinality is a per- receiver evaluation cost the publisher's DNS-publication discipline must coordinate; (iv) TLSA-mismatch produces per-receiver send-deferral vs SPF- mx-mismatch produces receiver-side spf=fail — both downstream consequences consume MX- host identity stability — the spoke documents the SPF mx: mechanism's per-message outcome semantics where MX-host A-record instability (rotation, cache staleness, publication errors) produces spf=fail or spf=permerror at the receiver — paralleling THIS page's DANE TLSA-mismatch outcome where an MX-host's TLS leaf cert that doesn't match the published TLSA record produces per-sender deferred-with-temporary-failure at the sender — in both protocols the per-MX-host identity instability cascades to receiver- side / sender-side authentication- and-deliverability outcomes that the publisher's per-MX-host rotation-coordination discipline determines. Read the SPF-mechanisms- explained spoke alongside this DANE-for-SMTP reference when coordinating per-MX-host publication discipline across the DANE inbound-TLS-protection and SPF mx: outbound-sender- authorization layers — the spoke is the canonical per-directive RFC 7208 §5 evaluation-contract reference whose mx: mechanism's per-MX-host identity-anchor consumption structurally parallels THIS page's DANE TLSA per-MX-host identity-anchor pinning discipline.
• SPF qualifiers explained - the DANE-TLSA-MANDATORY-PERMANENT-5XX- VALIDATION-FAILURE-COMMITMENT-VS-SPF- PUBLISHER-QUALIFIER-FAIL-VS-SOFTFAIL-VS- NEUTRAL-COMMITMENT companion to this DANE- TLSA reference. Where THIS page documents the DANE TLSA-record-publication discipline and the receiver-side consumption contract (any TLSA-validation-failure at the publisher-pinned MX-host produces a permanent 5xx rejection - no testing-mode equivalent to MTA-STS testing mode), the dedicated SPF-qualifiers spoke documents the STRUCTURALLY-PARALLEL publisher-side enforcement-strictness-commitment choice at the SPF record's terminating all qualifier-prefix whose four cross-protocol enforcement-strictness commitment dimensions identify the SPF-side parallel to DANE's mandatory-5xx- on-validation-failure commitment: (i) DANE TLSA-record publication is a BINARY-STRICTNESS commitment (publish-or- don't-publish; once published, validation- failure is mandatorily 5xx with no operator-tunable softening dial), and publisher publishing -all (HardFail) at the SPF record's terminating mechanism is the CLOSEST SPF-side parallel - publisher commits to spf=fail for any IP not matched by an earlier mechanism, and receivers honoring SPF-fail as rejection criterion produce SMTP-time rejection at the same operational strictness tier as DANE's TLSA-validation- failure mandatory 5xx rejection; the SPF-qualifiers spoke documents the HardFail-as-DANE-binary-strictness-parallel operator-commitment contract; (ii) SPF has TWO publisher-tunable strictness softening dials that DANE does NOT have: ~all (SoftFail) and ?all (Neutral) qualifier prefixes produce receiver-side non-rejecting verdicts that DANE TLSA-validation has no operational equivalent of - DANE's publisher-side commitment is BINARY (publish-with-validation-required OR don't-publish-at-all), whereas SPF's publisher-side commitment is GRADED across four qualifier-prefix tiers, producing a structurally-distinct publisher-side strictness-choice surface the SPF-qualifiers spoke documents in contrast to DANE's binary-publication commitment; the SPF-qualifiers spoke documents the SoftFail-and-Neutral publisher-tunable softening dials that have no DANE-TLSA equivalent, identifying the operator-decision framework for choosing SPF's graded-strictness vs DANE's binary-strictness publisher- commitment per-mail-stream-profile; (iii) DANE TLSA-record publication requires prerequisite zone-DNSSEC signing and per-MX-host parent-zone DS-record delegation at the registrar - the publisher's enforcement-strictness commitment cascades through three DNS- publication-discipline layers (zone- DNSSEC, DS-delegation, TLSA-RR publication), each of which can fail independently producing DANE-validation- failure with permanent 5xx rejection, whereas SPF publication has NO DNSSEC prerequisite - publisher publishing -all needs only the TXT-RR publication discipline and is structurally immune to the zone-DNSSEC-unsigning failure-mode that produces DANE- validation-failure at receivers; the SPF-qualifiers spoke documents the cross- protocol publication-prerequisite-cascade differential between SPF's single-layer TXT-RR publication and DANE's three-layer DNSSEC-anchored TLSA-RR publication; and (iv) DANE TLSA-validation-failure produces permanent 5xx at the SMTP- connection layer, BEFORE the message body is transmitted - SPF-fail (with publisher's -all commitment and receiver's strict-spf-fail-rejecting policy) produces SMTP-time rejection at the same connection-layer position, but SPF-softfail (~all publisher commitment) is typically NOT SMTP-connection-rejecting and instead produces a spf=softfail result-code consumed downstream at the DMARC alignment layer - the publisher's qualifier-prefix choice therefore determines WHERE in the SMTP-pipeline the publisher-side enforcement-strictness commitment is honored by the receiver, and at WHICH operational impact tier (connection-rejection vs message- quarantine vs message-pass-but-DMARC- observed); the SPF-qualifiers spoke documents the per-qualifier receiver-side SMTP-pipeline-honoring-position taxonomy and the operator-decision framework for choosing the SPF qualifier-prefix appropriate to the per-mail-stream-profile enforcement-strictness target, in structural parallel to the binary DANE- TLSA-publication enforcement-strictness choice this page documents.
• SPF permerror vs temperror - the DANE-TLSA-DNS-RECORD-PUBLICATION- AS-DNSSEC-ANCHORED-PARALLEL-DISCIPLINE companion documenting the structural- parallel DNS-published-authorization- policy error-class taxonomy across the DNSSEC-anchored TLSA-publication discipline THIS page documents (RFC 7672 TLSA-record publication under a DNSSEC-signed delegation whose RRSIG-validated chain provides the trust-anchor binding) and the DNSSEC-unanchored SPF-publication discipline the SPF-permerror-vs-temperror spoke documents (RFC 7208 SPF-TXT-record publication with NO mandatory DNSSEC signing requirement, producing a structurally-different upstream- DNS-authority trust-anchor model). Where THIS page documents the DANE-TLSA-record publication-discipline (the _25._tcp.<mx-host> TLSA- record byte-anatomy, the DNSSEC-signed delegation chain prerequisite, the receiver- side TLS-handshake-time TLSA validation contract, the per-TLSA-rotation overlap- window discipline gated by parent-zone DNSSEC-aware TTL propagation), the SPF- permerror-vs-temperror spoke is the SPF- side-PARALLEL ERROR-CLASS REFERENCE for the analogous DNS-publication-discipline publication-error-class on the SMTP-sender- authorization-policy layer where DNSSEC anchoring is OPTIONAL rather than mandatory. The four-axis DANE-DNSSEC-ANCHORED-VS-SPF- DNSSEC-UNANCHORED-PUBLICATION-DISCIPLINE comparison exposes the structurally-distinct DNS-PUBLISHED-AUTHORIZATION-POLICY error- class-pair parallels: (i) DANE- TLSA-record DNSSEC-validation-failure-class (broken delegation chain, missing DS record at parent zone, NSEC / NSEC3 proof-of-nonexistence regression) → SPF-record permerror verdict from publication-syntax-error class — the canonical DANE DNSSEC-validation-failure cases the receiver encounters during the TLS handshake (DNSSEC-chain-validation failure at any parent-zone delegation boundary treated as TEMPFAIL or PKIX-fail per RFC 7672 §3.1.3 receiver-side behavior contract) STRUCTURALLY PARALLEL the SPF-publication- syntax-error cases the spoke documents (malformed mechanism token, invalid macro expansion, missing terminator qualifier) — both are publication-time- bug-detected-at-evaluation-time error- class verdicts the receiver-side protocol issues; (ii) DANE- TLSA-record DNS-resolution-failure-class from authoritative-NS SERVFAIL during SMTP receive-handshake → SPF-record temperror verdict from analogous resolution-failure — the canonical DANE-resolution-failure cases during the TLS-handshake-time TLSA lookup (transient SERVFAIL during the _25._tcp.<mx> TLSA-record resolution, recursive-resolver-cache eviction window between TLSA-rotation TTL and propagation, DNSSEC-aware resolver validation-time timeout) STRUCTURALLY PARALLEL the SPF-resolution-failure cases the spoke documents (transient SERVFAIL during per-message SPF evaluation, recursive-resolver-cache eviction between publisher's TTL rotation and propagation, DNSSEC-aware validation timeout when the SPF publisher OPTED IN to DNSSEC signing) — both yield the temperror- class verdict + receiver-side retry- deferred behavior; (iii) DANE- DNSSEC-anchored vs SPF-DNSSEC-unanchored publication-discipline operational contrast → per-protocol trust-anchor model difference + per-protocol error- class-detection mechanism difference — DANE MANDATES DNSSEC signing at the publisher's delegation chain (the TLSA-record verifier rejects unsigned- chain TLSA records as UNUSABLE per RFC 7672 §3.2.1), while SPF makes DNSSEC signing OPTIONAL (the SPF-verifier accepts unsigned-chain SPF records with full pass- weight verdict); the spoke documents the structural consequence whereby DNSSEC- zone-misconfiguration produces TLSA- UNUSABLE verdicts on the DANE side but NO equivalent verdict on the SPF side (an SPF publisher who DOES opt into DNSSEC signing gets the opportunistic-DNSSEC-validation benefit but is not subject to the UNUSABLE verdict class DANE structurally produces); (iv) per-domain DANE-vs-SPF cross- protocol DNS-publication-pipeline-health holistic-KPI → per-domain co-regression observability — when the same domain's DANE-TLSA records AND SPF records both regress to error- class verdicts within the same publication window, the operational insight is a common-root-cause DNS- publication-pipeline regression spanning the DNSSEC-anchored AND DNSSEC-unanchored record families (typical causes: DNS- provider DNSSEC-signing key rollover bug that corrupted multiple RR types including TLSA + SPF, mass-publication automation script that mis-published across both DNSSEC-signed and DNSSEC- unsigned record families); the spoke documents the SPF-side observation surface for this cross-protocol regression pattern that THIS page's DANE-monitoring discipline observes from the TLS-receive-authorization side. Read the SPF-permerror-vs-temperror spoke when the operator's DANE-TLSA-record monitoring discipline has just observed a regression in TLS-handshake-time TLSA- validation-pass rates (or a transient spike in receiver-side TEMPFAIL bounces from TLSA- resolution failures) and the operator needs the parallel SPF-side error-class taxonomy to determine whether the regression spans both DNSSEC-anchored AND DNSSEC-unanchored authorization- policy families (suggesting a common- root-cause DNS-publication-pipeline regression) OR is isolated to the DANE- TLSA-DNSSEC-anchored publication side alone.
• SPF forwarding issues - the PER-FORWARDER-PER-SECOND-HOP-MX-HOST- DANE-TLSA-CHANNEL-INTEGRITY-PINNING-VS-PER- FORWARDER-PER-SECOND-HOP-SPF-APPLICATION- LAYER-AUTHORIZATION-BREAK companion documenting the structurally-paired transport-layer-DANE vs application-layer- SPF behavior at every forwarder hop. Where THIS page documents the publisher-side per- MX-host DANE TLSA-record publication discipline that pins the receiver-side STARTTLS leaf certificate to the DNSSEC- signed-anchored per-MX-host trust profile (the _25._tcp.<mx-host> TLSA-record byte anatomy, the receiver-side TLS-handshake-time TLSA-validation contract, and the receiver-side MUST-fail-closed disposition when DNSSEC-validated TLSA validation fails), the SPF-forwarding-issues spoke is the application-layer-PARALLEL SECOND-HOP REFERENCE for the analogous per-second-hop envelope-MAIL-FROM SPF- authorization-break at the forwarder boundary that NO TRANSPORT-LAYER DANE publication can fix at the application layer. The four-axis cross-protocol per- forwarder per-second-hop coordination comparison exposes the structurally-distinct transport-layer-DANE-vs-application-layer- SPF complementary defenses: (i) per- forwarder MX-host DANE-TLSA-publication- discipline transport-integrity floor ↔ per-second-hop envelope-MAIL-FROM SPF- rewrite-vs-un-rewrite application-layer authorization break — DANE pins the forwarder's inbound MX channel-integrity and the receiver's inbound MX channel- integrity at the TLS-handshake layer, but the receiver's SPF-evaluator at the second hop evaluates against the FORWARDER's connecting IP (not the original sender's), producing per-receiver SPF-fail / SPF- softfail verdicts even when both transport legs are DANE-TLSA-validated; (ii) per-forwarder TLSA-record-rotation overlap-window discipline ↔ per- forwarder SRS / DMARC-friendly forwarder envelope-rewriting discipline operator- coordination boundary — both disciplines are out-of-original-publisher's control at the per-forwarder cross- organizational coordination boundary (the publisher cannot dictate the third-party forwarder's TLSA-rotation cadence NOR the forwarder's SRS sender-rewriting-scheme adoption posture), but BOTH determine the composite per-second-hop deliverability outcome at the forwarder → receiver boundary; (iii) per-receiver TLS- RPT JSON-aggregate-report DANE-TLSA- validation-failure observability ↔ per-receiver DMARC RUA XML-aggregate-report SPF-fail-at-forwarder verdict observability — TLS-RPT (RFC 8460 §4) and DMARC RUA (RFC 7489 §7.2.1.1) are the parallel per-receiver per-day per- domain aggregate-evidence streams that surface the transport-layer-DANE-validation regression AND the application-layer-SPF- forwarder-fail-regression patterns at the same per-domain per-receiver observability boundary; (iv) per-publisher per- message DKIM-alignment-survival-at- forwarder as DMARC-composite-pass-floor when SPF breaks + DANE pins channel → once SPF breaks at a forwarder hop, the DMARC composite verdict reduces to DKIM-only survival; the per-forwarder DANE-TLSA-protected channel prevents STARTTLS-downgrade-driven forwarder-content-modification attacks at the transport layer but does NOT prevent the forwarder itself from modifying the body in ways that break the DKIM body- hash, making the forwarder hop the canonical "DKIM-canonicalization-hygiene + DANE-channel-pinning + ARC-chain- construction" three-leg defense moment. Read the SPF-forwarding-issues spoke when the operator's DANE-TLSA-record monitoring discipline has just observed a DANE regression at a per-forwarder MX-host boundary AND the operator needs the application-layer SPF-forwarder-break taxonomy (envelope-MAIL-FROM rewrite vs un-rewrite forwarder classes, SRS-deployed forwarder population, ARC-sealing forwarder population) to determine whether the composite per-second-hop deliverability incident spans both the transport-layer DANE-channel-integrity floor AND the application-layer SPF-authorization survivability floor at the same forwarder cross-organizational boundary.
• DKIM explained - the cryptographic message signing layer.
• BIMI - the visible-brand-logo standard built on top of DMARC enforcement.
• BIMI SVG Tiny-PS asset requirements - the PARALLEL-CRYPTOGRAPHICALLY-BOUND-DISPLAY- LAYER-PUBLISHER-ASSET companion reference. Where THIS page documents the per-publisher per-domain DANE TLSA RR per RFC 7672 binding an X.509 certificate (or its public-key / SubjectPublicKeyInfo hash) to the per-MX-host SMTP transport-layer cryptographic anchor for receiver-side STARTTLS-survival assurance, the per-publisher per-domain BIMI SVG Tiny-PS asset is the structurally-parallel publication- discipline-bound application-layer cryptographic anchor for receiver-side brand-indicator- rendering eligibility — the per-publisher per-domain VMC X.509 certificate (documented in the sibling BIMI VMC and CMC entry below) per RFC 9077-aligned BIMI Group / CA-Browser Forum Mark Certificate Working Group profile cryptographically binds (via per-VMC SHA-256 hash-binding extension at the id-pe-logotype OID per RFC 3709 §5) the per-publisher per-domain SVG Tiny-PS asset byte-stream to the per-publisher per- organizational-domain registered-trademark chain-of-custody, structurally parallel to the per-MX-host DANE TLSA-record-bound X.509- certificate cryptographic anchor THIS page documents at the per-publisher per-domain composite cross-layer cryptographically-bound- publisher-asset-publication coordination boundary — both per-publisher per-domain cryptographically-bound display-layer-and- transport-layer publisher-asset publication- disciplines coordinate per-publisher per- domain composite cross-layer evidence-of- publisher-identity-and-channel-integrity floor.
• BIMI Verified Mark Certificates (VMC and CMC) - the PARALLEL-X509-PKI-CERT-ARCHITECTURE- AT-DISTINCT-EMAIL-PROTOCOL-BOUNDARIES companion reference. Where THIS page documents the DANE TLSA record that binds an X.509 certificate (or its SubjectPublicKeyInfo hash) to an MX hostname at the SMTP-receive transport boundary using the DNSSEC-signed DNS chain as the trust anchor, the BIMI-VMC-certificates spoke documents the structurally-parallel X.509 certificate published at the DIFFERENT MUA-display boundary using the CA/Browser-Forum Mark Certificate WG profile + BIMI Group logotype OID as the trust profile and the DigiCert / Entrust public-CA hierarchy as the trust anchor. The implication: the OPERATOR who deploys DANE TLSA at their MX receive boundary AND procures a VMC for their outbound brand-display is running TWO structurally-parallel X.509 PKI deployments simultaneously — both rely on X.509 certificates as the trust primitive, both bind a cryptographic identifier to a domain-scoped name, both have certificate-rotation operational discipline (DANE's TLSA rollover requires the publish-old-and-new-TLSA-for-2-TTL-cycles choreography this page documents in §3; VMC's annual renewal requires the SVG-hash-binding to be REGENERATED if the underlying SVG changes between renewals), but with FUNDAMENTALLY DIFFERENT trust anchors (DANE's chain is DNSSEC-signed DNS = no public CA; VMC's chain is the BIMI-Group-authorised public-CA hierarchy = NO DNSSEC dependency) and DIFFERENT enforcement boundaries (DANE enforces at the receiving MTA's TLS-handshake step before mail content transits the wire; VMC enforces at the receiving MUA's brand-display step long after the mail has been delivered and stored). Read the BIMI-VMC-certificates spoke alongside this page when scoping a comprehensive X.509-in-email deployment — both DANE TLSA AND VMC impose certificate-procurement + certificate-renewal-discipline + certificate-revocation-on-failure operational obligations on the operator, and the two should be scheduled together in the per-domain certificate-inventory and renewal calendar to avoid the second-year- forgotten-renewal failure-mode that afflicts both layers.
• DMARC for Google Workspace - per-provider deployment guide for one of the major DANE outbound adopters.
• DMARC for Microsoft 365 - per-provider deployment guide for the provider that added DANE outbound in 2022 and inbound in 2023.
• Email spoofing - the TRANSPORT-LAYER-DANE-TLSA-DEFENSE- AGAINST-MX-RECORD-SUBSTITUTION-AND-TLS- DOWNGRADE-SPOOFING-VARIANTS companion to this DANE protocol reference. Where THIS page documents the DANE-TLSA-record-bound DNSSEC-signed certificate-pinning mechanism (RFC 7672 / RFC 6698 TLSA usage 2 / 3 + selector 0 / 1 + matching-type 0 / 1 / 2 + the DNSSEC validation chain from root → TLD → operator zone the TLSA record sits in), the email-spoofing spoke is the ATTACK-CLASS-CATALOGUE companion documenting the SEVEN distinct spoofing-attack mechanisms enumerated at the receiver-side authentication boundary (direct-domain From: header forgery / display-name impersonation / lookalike-domain registration / compromised-mailbox account takeover / freshly-registered domain ephemeral campaign / unauthenticated legacy-protocol bypass / MX-record- substitution-during-DNS-resolution man-in-the-middle), of which TWO variants are STRUCTURALLY ELIMINATED by a correctly-deployed DANE-TLSA-record-bound DNSSEC-signed published certificate-pinning posture: (i) the MX-RECORD- SUBSTITUTION variant where an attacker positioned to manipulate DNS responses (an on-path attacker between sender and recipient, a cache-poisoning attacker against the sender's recursive resolver, a rogue authoritative-server operator at the recipient's DNS provider) injects a forged MX record pointing at an attacker-controlled MTA is structurally eliminated because DANE TLSA validation REQUIRES the forged MX hostname to ALSO publish a TLSA record matching the attacker's certificate AND have the entire DNS chain from root through TLD through operator zone DNSSEC-validate cryptographically — an attacker who can substitute the MX record cannot simultaneously substitute the DNSSEC-signed TLSA record without compromising the DNSSEC ZSK / KSK chain; (ii) the TLS-DOWNGRADE-STARTTLS- STRIPPING variant where an attacker positioned at the network layer strips the 250 STARTTLS capability advertisement from the receiver's EHLO response, causing the sender's MTA to send the message over plaintext SMTP which the attacker can then read / modify / spoof in transit is structurally eliminated because a DANE- TLSA-publishing receiver's TLSA record is itself a STRONG OPERATOR ASSERTION that TLS MUST be enforced on inbound SMTP — sender MTAs implementing DANE REFUSE to fall back to plaintext when a TLSA record exists at the _25._tcp.<mx-hostname> DNS-name regardless of whether STARTTLS advertisement is stripped at the network layer. Read the email-spoofing catalogue when authoring the DANE-deployment operational rationale — DANE is not just a TLS-policy-enforcement mechanism, it is a STRUCTURAL ELIMINATION of two distinct spoofing-attack variants the SPF / DKIM / DMARC authentication stack cannot defend against because those defenses operate at the APPLICATION LAYER AFTER the message has already traversed the (now-attacker-controlled) SMTP transport hop where MX substitution and TLS stripping operate.
• Phishing protection - the DANE-TLSA-TRANSPORT-LAYER-DEFENSE- AS-PHISHING-DELIVERY-INFRASTRUCTURE- SUBSTITUTION-PREVENTION-LAYER companion reference to this RFC 7672 DANE-for-SMTP pillar. Where THIS page documents the DANE-TLSA-record-bound DNSSEC-signed certificate-pinning mechanism (RFC 7672 / RFC 6698 TLSA usage 2 / 3 + selector 0 / 1 + matching-type 0 / 1 / 2 + the DNSSEC validation chain from root → TLD → operator zone the TLSA record sits in), the phishing-protection spoke is the OPERATIONAL DEFENSE-PROGRAM companion documenting how the DNSSEC-anchored TLSA-pin mechanism THIS page documents functions as a CRITICAL PHISHING-DEFENSE-LAYER PRIMITIVE structurally eliminating TWO distinct phishing-delivery-infrastructure- substitution attack vectors at the SMTP transport hop BEFORE the application- layer SPF/DKIM/DMARC defenses can engage. The four-axis DANE-AS-PHISHING- DEFENSE-LAYER framework: (i) MX-record-substitution phishing- infrastructure-injection elimination — a phishing attacker positioned to manipulate DNS responses between the legitimate sender and the legitimate receiver (on-path attacker, cache-poisoning attacker against a target's recursive resolver, rogue authoritative-server operator at a compromised DNS provider) cannot inject a forged MX record pointing at attacker-controlled phishing-relay infrastructure when the receiver publishes TLSA records because the forged MX hostname would ALSO need to publish a DNSSEC-signed TLSA record matching the attacker's certificate AND have the entire DNS chain from root through TLD through operator zone DNSSEC-validate cryptographically; the phishing-protection spoke documents WHY this attack class is operationally significant in real-world phishing campaigns (corporate-network DNS compromise, supply-chain attacks against managed-DNS providers, BGP- hijack attacks against authoritative nameserver IP space); (ii) STARTTLS-stripping phishing-traffic- interception elimination — a phishing attacker positioned at the network layer between sender and receiver who strips the 250 STARTTLS capability advertisement to force plaintext SMTP cannot intercept and modify the message-in-transit when the receiver publishes TLSA records because DANE- implementing senders REFUSE to fall back to plaintext when a TLSA record exists; the phishing-protection spoke documents WHY this transport-layer defense matters for phishing campaigns where the attacker substitutes the message body with phishing-payload content during the unprotected transport hop; (iii) defense- in-depth layering with application- layer authentication — the spoke documents how DANE at the transport layer COMPLEMENTS DMARC / DKIM / SPF at the application layer: the transport-layer DANE-TLSA-pin ensures the message reaches the AUTHENTICATED-IDENTITY-VERIFIED receiver before the application-layer authentication stack evaluates the message contents, closing the GAP that phishing campaigns exploit when attacker-controlled transport infrastructure intercepts mail BEFORE the receiver's authentication engine can apply the publisher's policy; (iv) per-domain DANE-deployment decision in the phishing-defense program — the spoke documents the per-domain cost-benefit analysis for adding DANE to the phishing- defense program: high-value domains (financial-services brand domains, executive-mailbox domains, supply- chain-vendor domains targeted by BEC-vendor-impersonation campaigns) warrant the DNSSEC + TLSA operational- complexity cost the spoke documents because the MX-substitution and STARTTLS-stripping attack vectors are empirically observed in nation-state- sponsored and organised-crime phishing campaigns. Read the phishing- protection spoke alongside this DANE pillar when authoring the publisher's phishing-defense-program roadmap document — the spoke is the authoritative defense-program- effectiveness reference that contextualises WHY a domain operator invests in the DNSSEC + TLSA operational discipline this pillar documents.
• DKIM cryptography basics — the APPLICATION-LAYER-RSA-PUBLIC-KEY- CRYPTOGRAPHIC-ANCHOR companion reference to DANE's transport-layer TLSA-hash- pinning cryptographic-anchor. Where THIS page documents DANE's TRANSPORT-LAYER cryptographic-anchor surface (TLSA record at _25._tcp.<mx> binding the SHA-256 / SHA-512 hash of the receiver's MX server's TLS leaf or intermediate certificate / DNSSEC-signed TLSA-record cryptographic-integrity chain from ICANN root through TLD through operator-zone ZSK / KSK / RFC 6698 PKIX-EE or DANE-EE certificate- usage selectors / SHA-256 or SHA-512 matching types), the DKIM-cryptography- basics spoke documents the PARALLEL APPLICATION-LAYER cryptographic-anchor surface at the per-message signing layer: publisher publishes RSA-2048 (or Ed25519 per RFC 8463) PUBLIC KEY as a TXT record at <selector>. _domainkey.<domain> / publisher's signing-MTA computes the b= signature blob over canonicalised headers + body using SHA-256 hash + RSA-2048 / Ed25519 signing-key / receiver retrieves the public key via DNS at verification time / receiver verifies the b= signature blob against the publisher's public key / verification-result emitted as Authentication-Results dkim=pass / dkim=fail. The TWO cryptographic-anchor surfaces form COMPLEMENTARY DEFENSE LAYERS in the seven-layer receiver-side cryptographic- integrity stack: (i) TRANSPORT-LAYER DANE-TLSA-hash-pinning anchors the HOP- BY-HOP CONFIDENTIALITY + INTEGRITY of the bytes-on-the-wire between sending and receiving MTAs (the bytes never- reach-the-authentication-engine surface DANE protects); (ii) APPLICATION-LAYER DKIM-RSA-key-signing anchors the END- TO-END AUTHENTICITY of the message envelope-from-sender-to-mailbox (the bytes-passed-the-authentication-engine surface DKIM protects). Both layers are required for a defensible end-to-end email-security posture — a publisher with DANE-TLSA-deployment-perfect but DKIM-key-compromised (or DKIM-key- rotation-discipline-failing per the spoke's HSM / per-customer-isolation / no-export-attribute discipline) emits messages where TRANSPORT-LAYER integrity holds but APPLICATION-LAYER authenticity fails — attacker-signed message arrives at receiver with valid DKIM signature from the publisher's compromised key, passing every alignment check by construction; conversely a publisher with DKIM-RSA-key-signing-flawless but no-DANE-TLSA-deployment / DNSSEC-not- deployed-on-operator-zone emits messages where APPLICATION-LAYER authenticity holds but TRANSPORT-LAYER integrity is attacker-substitutable via MX-record- substitution-during-DNS-resolution or TLS-downgrade-STARTTLS-stripping — attacker reads/modifies the message in transit before DKIM signing has any opportunity to detect it (an attacker who modifies the body in transit invalidates the bh= body-hash, but the receiver may still accept the modified message with dkim=fail result and fall back to SPF-only evaluation). Read the spoke alongside this page to understand the WHY behind the joint DANE + DKIM defensible-posture: TLSA- hash-pinning at the DANE layer + RSA-2048-floor signing at the DKIM layer + DNSSEC-signed publisher zone + DNSSEC-signed receiver zone + quarterly DKIM selector rotation cadence + HSM-backed signing-key storage is the SUPERSET cryptographic- anchor posture defending against the MAXIMUM space of in-transit attacker- modifications and end-to-end authenticity- forgery variants.
• SPF DNS-record syntax — the DANE-TLSA-RR-DNSSEC-CHAIN-OF-TRUST- AT-TRANSPORT-LAYER-PUBLISHED-BESIDE-THE- SPF-v=spf1-TXT-RR-AT-APPLICATION-LAYER companion to this DANE pillar. Where THIS page documents the per-MX-host TLSA-RR publication at _25._tcp.<mx-host> with DNSSEC chain-of-trust validation (certificate- usage selectors 0/1/2/3, matching types SHA-256 / SHA-512, the DNSSEC-anchored zone-signing-key + key-signing-key chain through ICANN root), the SPF DNS-record syntax spoke is the APPLICATION-LAYER per- publisher per-domain TXT-record byte- grammar reference whose v=spf1 header-token- followed-by-mechanism-list publication runs ALONGSIDE the per-MX-host TLSA-RR DNSSEC-anchored transport-layer cryptographic-anchor THIS page documents. The four-axis DANE-TLSA-RR-VS-SPF-v=spf1- TXT-RR cross-layer DNS-publication comparison exposes the structurally- distinct per-publisher per-zone publication-discipline roles: (i) per-publisher per-MX-host TLSA-RR publication at _25._tcp.<mx-host> binds the per-MX-host TLS leaf or intermediate certificate hash to the DNSSEC-anchored DNS chain-of-trust at the TRANSPORT layer, whereas per- publisher per-domain SPF TXT-record publication at the per-domain apex (and per-subdomain scope) binds the per-domain SENDING-IP authorization set to the DNS chain at the APPLICATION layer — making the two publication primitives STRUCTURALLY- PARALLEL DNS-publication-discipline primitives that run at distinct OSI layers (transport hop vs application SMTP-envelope), distinct DNS scopes (per-MX-host vs per-domain), and distinct RR types (TLSA vs TXT) — the SPF DNS-record syntax spoke documents the per- domain v=spf1 TXT-RR publication-byte-grammar that every DANE-deploying receiver publisher must coordinate alongside the per-MX-host TLSA-RR DNSSEC- anchored publication this page documents; (ii) DNSSEC- chain-of-trust validation is STRUCTURALLY MANDATORY for DANE TLSA- RR consumption (per RFC 7672 §1.2 — TLSA records lacking DNSSEC validation are silently ignored by the receiver-side TLSA-validator), whereas DNSSEC-chain-of-trust validation is STRUCTURALLY OPTIONAL for SPF TXT-RR consumption (per RFC 7208 §11.6 — SPF receivers consume unsigned TXT records and treat DNSSEC validation as an optional additional gate) — the SPF DNS- syntax spoke documents the SPF v=spf1 TXT-RR publication discipline that survives both DNSSEC-anchored and DNSSEC-unanchored receiver- side consumption, whereas this DANE pillar documents the TLSA-RR publication discipline that CANNOT operate without DNSSEC- anchored receiver-side consumption — the SPF DNS-syntax spoke's DNSSEC- optionality-vs-DANE's-DNSSEC- mandatoriness asymmetry is the load-bearing operational constraint determining which of the two protocols a non-DNSSEC- zone publisher can deploy; (iii) per-publisher SPF v=spf1 TXT-RR encoding is governed by the 255- octet character-string- fragmentation rule of RFC 1035 §3.3.14 (a single TXT-RR encoding a string longer than 255 octets MUST split it into multiple 255- octet character-strings which the SPF resolver concatenates at consumption time), whereas per- publisher DANE TLSA-RR encoding carries a SHA-256 / SHA-512 hash of fixed binary length (32 or 64 octets) that NEVER hits the 255-octet TXT-fragmentation boundary — making the per- publisher TXT-RR-encoding- discipline a SHARED operational concern across SPF publication but ASYMMETRIC against the DANE-TLSA-RR encoding — the SPF DNS-record syntax spoke documents the per- publisher per-domain TXT-record- encoding discipline (the 255- octet character-string- fragmentation rule, the "exactly one SPF record per scope" rule producing permerror on duplicate publication, the whitespace-and-case mechanics) every per-domain SPF publisher must internalise SEPARATELY from the per-MX-host TLSA-RR binary-payload encoding this DANE pillar documents; and (iv) per-publisher v=spf1 TXT-RR publication discipline includes the per-publisher per-domain SPF policy commitment (e.g. -all hard-fail vs ~all soft-fail vs ?all neutral) that the receiver-side SPF evaluator consumes as the publisher's commitment about how to handle unauthorised sending IPs, STRUCTURALLY PARALLELING the per-publisher per-MX-host TLSA- RR publication-mode commitment (PKIX-EE constraint usage 0/1 vs DANE-EE constraint usage 2/3) the receiver-side DANE validator consumes as the publisher's commitment about which CA-issued cert is acceptable at the SMTP transport hop — the SPF DNS-syntax spoke documents the per-publisher per-domain publication-mode discipline at the APPLICATION-layer that every DANE-deploying publisher must coordinate alongside the per-MX-host TLSA-RR per- publisher publication-mode discipline at the TRANSPORT- layer this DANE pillar documents. Read the SPF DNS- record syntax spoke when publishing a per-domain v=spf1 TXT-RR ALONGSIDE a per-MX-host TLSA-RR DNSSEC-anchored DANE deployment (audit the per- publisher per-domain SPF record's 255-octet character-string- fragmentation discipline AND the per-publisher per-MX-host TLSA-RR DNSSEC-anchor deployment in the same change-set), and when deciding the per-publisher DNSSEC-anchor-deployment sequencing across the two protocols (DNSSEC-anchored zone-signing must precede DANE-TLSA-RR publication but is independent of SPF v=spf1 TXT-RR publication ordering).
• DKIM DNS-record syntax - the DKIM-MESSAGE-LAYER-DNS-RECORD-BYTE- GRAMMAR-AS-LOAD-BEARING-SIBLING-DNS- PUBLICATION-DISCIPLINE-TO-DANE-TLSA-RR- TRANSPORT-LAYER-BYTE-GRAMMAR-AT-FOUR-CROSS- LAYER-PER-PUBLISHER-DNS-PUBLICATION- DIMENSIONS companion to this DANE pillar. Where THIS page documents the DANE protocol at the byte level (the RFC 7672 _25._tcp.<mx-target> TLSA-RR location, the four certificate- usage parameter values PKIX-TA / PKIX-EE / DANE-TA / DANE-EE, the two selector parameter values cert / spki, the three matching-type parameter values full / SHA-256 / SHA-512, the DNSSEC chain-of- trust requirement on the receiving zone, the deployment cookbook for ED25519 / RSA- 2048 key material), the DKIM-DNS-record- syntax spoke is the MESSAGE-LAYER per- publisher per-selector TXT-record-byte- grammar reference that runs ALONGSIDE every DANE-deploying publisher's per-MX- host TLSA-RR publication at FOUR per- publisher cross-layer DNS-publication dimensions: (i) per-publisher per- name FQDN publication-location discipline — DKIM at <selector>._domainkey.<d-tag> per RFC 6376 §3.6.1 vs DANE at _25._tcp.<mx-target> per RFC 7672 §3 — the DKIM-DNS- record-syntax spoke documents the per- publisher per-selector FQDN publication- location discipline at the MESSAGE layer STRUCTURALLY PARALLELING the per-publisher per-MX-host FQDN publication-location discipline at the TRANSPORT layer this DANE pillar documents; both are per- publisher per-name FQDN-publication primitives the receiver-side validator consumes by NAME LOOKUP at the canonical location; (ii) per-publisher per- record cryptographic-anchor-byte publication discipline — DKIM p=<base64-encoded-public-key> per RFC 6376 §3.6.1 vs DANE TLSA matching- type SHA-256 / SHA-512 digest bytes per RFC 6698 §2.1.3 — the DKIM-DNS- record-syntax spoke documents the per- publisher per-selector base64-public-key publication discipline at the MESSAGE layer STRUCTURALLY PARALLELING the per- publisher per-MX-host TLSA matching-type SHA-256 / SHA-512 digest-byte publication discipline at the TRANSPORT layer this DANE pillar documents; both are per- publisher per-record DNS-published cryptographic-anchor-byte primitives the receiver-side validator consumes as the publisher's commitment to a specific cryptographic key whose private half the publisher controls; (iii) per- publisher per-record publication-version tag discipline — DKIM v=DKIM1 per RFC 6376 §3.6.1 vs DANE TLSA certificate-usage parameter 2 / 3 (DANE-TA / DANE-EE) per RFC 7672 §3.1.3 — the DKIM-DNS-record- syntax spoke documents the per-publisher per-selector publication-version tag (v=DKIM1 as the canonical- version sentinel the receiver-side validator MUST verify before parsing the rest of the tag list) STRUCTURALLY PARALLELING the per-publisher per-MX- host TLSA certificate-usage parameter (PKIX-EE vs DANE-EE as the canonical constraint-usage sentinel the receiver- side validator MUST consume before applying the matching-type comparison) the receiver-side validator consumes as the publisher's commitment about how to interpret the published bytes; (iv) per-publisher per-record revocation-and-rotation publication- discipline — DKIM empty-p= revocation primitive per RFC 6376 §3.6.1 vs DANE-TLSA dual-RR overlap-window rotation discipline per RFC 7672 §8.4 — the DKIM-DNS-record- syntax spoke documents the per-publisher per-selector kill-switch publication primitive (empty p= as the canonical revocation marker the receiver- side validator interprets as "this selector is retired; reject any signature claiming it") STRUCTURALLY PARALLELING the per-publisher per-MX-host TLSA dual- RR overlap-window rotation discipline this DANE pillar documents (publish OLD and NEW TLSA RRs in parallel during the certificate-renewal window, then retire OLD). Read the DKIM-DNS-record-syntax spoke when publishing a per-publisher per-selector <selector>._domainkey.<d-tag> TXT-RR ALONGSIDE a per-publisher per-MX- host TLSA-RR DNSSEC-anchored DANE deployment (coordinate the per-publisher per-selector DKIM publication-discipline AND the per-publisher per-MX-host TLSA- RR DNSSEC-anchor deployment in the same change-set so the receiver-side validator sees BOTH the message-layer per-domain public-key anchor AND the transport- layer per-MX-host certificate anchor on the FIRST inbound delivery attempt after the change).
• SPF for Microsoft 365 — the PER-M365-TENANT-APPLICATION- LAYER-SPF-INCLUDE-CASCADE-AS-PARALLEL- DNS-PUBLICATION-COMPANION-TO-DANE-TLSA- TRANSPORT-LAYER-MX-HOST-CERTIFICATE- PINNING companion to this DANE-for-SMTP pillar reference. Where THIS page documents the per-publisher per-MX-host _25._tcp.<mx-host> DANE TLSA RR publication discipline (the certificate-usage / selector / matching- type parameter triad, the DNSSEC chain- of-trust requirement, the per-MX-host per-cert-rotation overlap-window coordination), the spf_for_microsoft_365 spoke documents the structurally- parallel per-M365-tenant APPLICATION- LAYER SPF-include-cascade publication at FOUR cross-layer per-M365-tenant publication dimensions: (i) per- M365-tenant include:spf.protection.outlook.com SPF-include-cascade as APPLICATION-LAYER per-envelope-MAIL-FROM-domain authorized- source-IP allow-list publication PARALLEL TO the per-M365-tenant per- MX-host TLSA-RR per-MX-host certificate- pin publication on the inbound transport-layer side — both are per-M365-tenant per-DNS-record publication-discipline primitives the M365-tenant operator must coordinate; the spf_for_microsoft_365 spoke documents the SPF-side APPLICATION- LAYER per-envelope-domain publication the same per-tenant publication- discipline operators master for DANE TLSA RR publication transfers directly to; (ii) per-M365-tenant SPF- include-cascade -all / ~all terminal-qualifier publisher-side enforcement-strictness commitment AS APPLICATION-LAYER STRUCTURAL-PARALLEL TO the per-MX-host DANE TLSA-RR DNSSEC-anchored-vs- opportunistic publisher-side enforcement-strictness commitment THIS page documents on the transport-layer side — the publisher's per-envelope-MAIL-FROM SPF terminal- qualifier publication is the APPLICATION- LAYER per-tenant authorization-policy commitment whose strictness choice is consumed at the receiver as the M365 publisher's commitment about how to handle envelope-source-IP-authorization- policy violations, parallel to how the DNSSEC-anchored DANE TLSA RR is the TRANSPORT-LAYER per-MX-host publisher commitment whose strictness is consumed at the receiver as the M365 publisher's commitment about how to handle MX-host- certificate-pin-validation violations; (iii) per-M365-tenant SPF- include-cascade RFC 7208 §4.6.4 ten- DNS-lookup ceiling publication constraint AS APPLICATION-LAYER PER-TENANT PUBLICATION-BUDGET DISCIPLINE PARALLEL TO the DANE TLSA- RR DNS-zone byte-budget publication constraint per-MX-host on the TRANSPORT-LAYER side — M365's per-tenant include:spf.protection.outlook.com cascade itself consumes 5+ of the ten- lookup budget; the spf_for_microsoft_ 365 spoke documents the per-tenant APPLICATION-LAYER publication-budget discipline whose preservation parallels the per-MX-host DANE TLSA-RR DNS-zone byte-budget publication-budget discipline the per-MX-host TRANSPORT- LAYER side this page documents depends on at the per-M365-tenant publication-discipline boundary; (iv) per-M365-tenant SPF-record per-source-IP authorization-failure- evidence emitted in RUA aggregate- reports AS APPLICATION-LAYER OBSERVABILITY-FEEDBACK-LOOP PARALLEL TO per-M365-tenant DANE TLSA-RR per-MX-host TLS-handshake-failure- evidence emitted in TLS-RPT JSON- aggregate reports on the TRANSPORT- LAYER side — the receiver- side aggregate-report-emitter records per-source-IP-per-disposition SPF- failure rows attributing per-M365- tenant envelope-MAIL-FROM authorization-failures, structurally parallel to the per-M365-tenant per- MX-host TLS-RPT JSON policies[].failure-details[] per-failure-class rows attributing per-MX-host DANE TLSA-validation failures THIS page documents the publisher-side configuration of — both are per-publisher per-DNS- record-publication observability- feedback-loops the M365-tenant operator consumes to validate per- tenant publication discipline. Read the spf_for_microsoft_365 spoke alongside this DANE-for-SMTP pillar reference whenever the M365-tenant operator scopes a per-tenant cross- layer DNS-publication discipline plan — the per-M365-tenant SPF-include- cascade publication the spoke catalogues IS the APPLICATION-LAYER sibling-DNS-publication-discipline primitive that runs ALONGSIDE the per-MX-host DANE TLSA-RR publication discipline THIS page documents at the cross-protocol per-M365-tenant DNS-publication-discipline boundary.
• DMARC multi-domain strategy — the PER-ORGANISATION-DOMAIN-FAMILY- DANE-COORDINATION companion to this per-policy-domain DANE TLSA-RR publication-discipline reference. Where THIS page documents the per- policy-domain DANE TLSA-RR publication discipline (per-MX-host _25._tcp.<mx-host> TLSA-RR publication, per-certificate- usage-and-selector-and-matching-type authoring discipline, per-DNSSEC- signed-zone publication prerequisite, per-MX-host TLS-handshake-anchor attribution), the multi-domain- strategy spoke is the PER-ORGANISATION- DOMAIN-FAMILY-DANE-COORDINATION companion documenting how the per- policy-domain DANE TLSA-RR publication discipline scales across the organisation's complete domain family at FOUR per-organisation-domain- family-DANE-coordination dimensions: (i) per-active-receiving- domain per-MX-host TLSA-RR publication is the per-active-domain transport- layer-execution instantiation of the per-policy-domain DANE publication discipline — the multi- domain-strategy spoke documents how every actively-receiving domain in the organisation's domain family MUST independently publish per-MX-host TLSA records following the per-policy- domain DANE publication discipline THIS page documents; (ii) per- parked-or-defensive-registered domain DANE-TLSA-non-publication is the per- non-active-domain transport-layer- non-publication instantiation — the multi-domain-strategy spoke documents how parked domains and defensive registrations (which typically have null-MX or no MX) skip DANE TLSA-RR publication entirely because there is no inbound MTA to anchor a transport-layer trust decision against — the inverse of the per-policy-domain DANE publication discipline THIS page documents; (iii) per-organisation-wide DNSSEC- signing-coordination is the per- domain-family-wide DANE publication prerequisite instantiation — the multi-domain-strategy spoke documents how the per-policy-domain DNSSEC-signed-zone prerequisite THIS page documents scales when the organisation's domain family includes dozens of inbound-MTA-serving domains each requiring independent per-zone DNSSEC signing as a precondition for per-MX-host DANE publication; and (iv) per-organisation-domain- family DANE-coordination is the transport-layer structural cousin of per-organisation-domain-family DMARC- coordination — the multi- domain-strategy spoke documents how the per-organisation-wide DMARC publication coordination at the application-layer per-publisher per- domain DMARC TXT publication tier structurally pairs with the per- organisation-wide DANE TLSA-RR publication coordination at the transport-layer per-MX-host TLSA-RR publication tier THIS page documents — both are per-organisation-domain- family operational-coordination disciplines on different OSI layers the per-organisation operator MUST scope together.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain.
• DNS Record Generator - interactive wizards for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records.
• Business Email Compromise (BEC) — the per-attacker per-target-domain BEC-ATTACK-THREAT-MODEL companion to this per-publisher per-domain DANE for SMTP reference. Where THIS page documents the per-publisher per- domain DANE-TLSA publication discipline (the _25._tcp.<mx-host> TLSA RR publication with the DANE-EE usage value 3, the per-publisher DNSSEC chain-of-trust requirement, the per-receiver opportunistic-DANE TLS deployment per RFC 7672), the BEC spoke documents the per-attacker per-target-domain BEC attack-vector catalogue whose TRANSPORT-LAYER attack-pathway the per-publisher per-domain DANE publication DETERS — every BEC-attacker man-in- the-middle TLS-downgrade attempt against the per-publisher per-domain inbound SMTP path fails the per- receiver DANE-EE certificate-pinning evaluation, closing the BEC-attacker transport-layer downgrade attack- surface that would otherwise enable per-target-domain inbound message interception. Read the BEC spoke when MOTIVATING the per-publisher per-domain DANE-TLSA publication- discipline investment as a load- bearing TRANSPORT-LAYER-MAN-IN-THE- MIDDLE-DOWNGRADE-DETERRENCE BEC- countermeasure that COMPLEMENTS the APPLICATION-LAYER per-publisher per- domain DMARC + SPF + DKIM BEC- deterrence authentication discipline at the per-publisher per-domain cross-layer BEC-deterrence-defense- in-depth composition boundary.
• DKIM failures explained — the per-recipient per-message DKIM-VERDICT-CATALOGUE companion documenting the seven canonical receiver-side Authentication-Results verdicts (dkim=none / neutral / pass / fail / policy / temperror / permerror) per RFC 6376 §3.9 + RFC 8601 §2.7.1 to this per-publisher per-domain DANE-for-SMTP transport-layer reference. Where THIS page documents the per-publisher per-domain DANE-TLSA publication discipline that authenticates the TRANSPORT layer (the receiving MX certificate hash-matches the DNSSEC-anchored TLSA RR at _25._tcp.<mx-host>, defeating on-path TLS-downgrade and MX-substitution attacks), the DKIM-failures-explained spoke documents the orthogonal MESSAGE layer per-message verdict catalogue produced AFTER the DANE-validated SMTP session delivers the message intact — a message that passes DANE's transport-layer cryptographic validation can still produce a per-message dkim=fail verdict at the receiver-side DKIM evaluator (signature breakage from a content-modifying intermediate that rewrote the body AFTER the DANE-secured hop terminated) or dkim=permerror (missing or malformed <selector>._domainkey.<d-tag> public-key TXT) or dkim=policy (1024-bit RSA or rsa-sha1 receiver-side local-policy rejection). Read the DKIM-failures spoke when CONSTRUCTING the cross-layer per-publisher per-domain email-authentication defence-in-depth — the spoke documents the per-recipient per-message MESSAGE-LAYER verdict catalogue this DANE TRANSPORT-LAYER publication discipline complements but does NOT subsume.
• DKIM for Microsoft 365 — the PER-M365-TENANT-DKIM-SIGNING- DISCIPLINE-AS-MESSAGE-LAYER-CRYPTOGRAPHIC- PRIMITIVE-PARALLEL companion to this DANE-TLSA transport-layer cryptographic- publication reference. Where THIS page documents the per-publisher per-MX-host TRANSPORT-LAYER cryptographic-primitive publication (RFC 7672 DNSSEC-anchored per-MX-host _25._tcp.<mx> TLSA-RR certificate-pinning publication, the per-MX-host TLSA usage selector matching-type byte-grammar, the per- publisher per-domain DNSSEC dependency chain anchoring TLSA validity, the per- MX-host cryptographic-chain-validation verdict at the SMTP-receive-side boundary), the DKIM-for-M365 spoke documents the PARALLEL MESSAGE- AUTHENTICATION-LAYER per-M365-tenant per-custom-domain DKIM-signing deployment workflow (Exchange Admin Center DKIM- Enable toggle; per-tenant per-custom- domain dual-selector1 / selector2 rotation under selector*._domainkey.<d> CNAME publication pointing at per-tenant provider-managed selector*-<tenantId>._domainkey.<onmicrosoft-tenant>; per-tenant Rotate-DKIM-Keys cadence) whose per-M365-tenant message- authentication-layer cryptographic- primitive publication is the STRUCTURAL- PARALLEL cryptographic-publication discipline to the per-M365-inbound-MX- host transport-layer DANE TLSA-RR publication THIS page documents. The DANE-VS-M365-DKIM cross-reference establishes FOUR structurally-distinct cross-layer cryptographic-publication coupling dimensions: (i) BOTH transport-layer DANE TLSA-RR and message-authentication-layer M365 DKIM are per-publisher per-domain DNS-rooted cryptographic-primitive publication disciplines — DANE publishes per- publisher per-MX-host _25._tcp.<mx> TLSA records; M365 DKIM publishes per-tenant per- custom-domain selector*._domainkey.<d> CNAME records pointing at per-tenant provider-managed selector records — the per-publisher per-domain DNS- rooted cryptographic-primitive publication substrate is shared across both protocol layers; (ii) per- M365-tenant per-custom-domain DKIM- signing posture is ORTHOGONAL to but COMPLEMENTARY with the per-M365-inbound- MX-host DANE TLSA-RR publication — the M365 operator needs BOTH the per-tenant outbound-egress message-authentication- layer cryptographic-publication AND the per-tenant inbound-MX-host transport- layer cryptographic-publication deployed in parallel — a per-M365-tenant operator who deploys per-tenant DKIM signing without inbound-MX-host DANE TLSA-RR publication leaves the inbound- transport-layer attack-surface gap; a per-M365-tenant operator who deploys inbound-MX-host DANE TLSA-RR publication without per-tenant DKIM signing leaves the outbound-message-authentication- layer cryptographic-primitive gap; (iii) per-M365-tenant DKIM- selector1 / selector2 rotation cadence and per-publisher per-MX-host DANE TLSA-RR rollover cadence (with the canonical pre-publication overlap window) share an identical operational discipline pattern — both require per- publisher zone-editor commit cadence with DNS-propagation-aware overlap windows during rotation — the operator-side per-publisher per-domain zone-editor discipline transfers directly between M365 DKIM-selector rotation and DANE TLSA-RR rollover; (iv) per-M365-tenant per- custom-domain DKIM-Enable activation in the Exchange Admin Center is the canonical message-authentication-layer primitive every M365-tenant operator must complete BEFORE progressing the per-publisher per-domain DMARC ramp to p=quarantine or p=reject, in parallel with the per-M365-inbound-MX-host DANE TLSA-RR publication the M365-tenant operator simultaneously deploys for the per-publisher per-MX-host transport- security posture — the per- M365-tenant per-custom-domain DKIM- signing deployment + per-M365-inbound- MX-host DANE TLSA-RR publication form the per-M365-tenant per-domain DUAL- LAYER cryptographic-publication posture (message-authentication layer + transport-security layer). Read this DANE-TLSA reference when DEPLOYING the per-publisher per-MX-host transport- layer cryptographic-primitive publication; read the DKIM-for-M365 spoke when DEPLOYING the parallel per- M365-tenant per-custom-domain message- authentication-layer DKIM-signing posture both protocol layers structurally co-require.
• DKIM troubleshooting — the PER-MESSAGE-DKIM-FAILURE-MODE- DIAGNOSTIC-LADDER-AS-APPLICATION-LAYER- CRYPTOGRAPHIC-TRUST-ANCHOR-AUTHENTICATION- LEG-DISCIPLINE-COMPLEMENT-FOR-DANE-TRANSPORT- LAYER-CRYPTOGRAPHIC-TRUST-ANCHOR-PUBLICATION companion to this DANE-explained reference. Where THIS page documents the per-publisher per-domain DANE TLSA-record per-MX DNSSEC- protected certificate-association cryptographic-trust-anchor publication discipline (_25._tcp.<mx>.<domain> IN TLSA <usage> <selector> <matching-type> <cert-association- data>), the DKIM-troubleshooting spoke is the per-message DKIM-failure-mode diagnostic-ladder reference operators consult at the per-publisher per-domain APPLICATION- LAYER cryptographic-trust-anchor authentication-discipline boundary that per-publisher per-domain mail flow must cross-coordinate with transport-layer DANE cryptographic-trust-anchor publication at FOUR per-failure-mode cross-layer cryptographic-coordination dimensions: (i) per-publisher per-domain DANE TLSA-record per-MX certificate-association- publication coordinated with per-publisher per-domain DKIM-failure-mode per-selector cryptographic-trust-anchor-publication discipline-floor — per-publisher operators committing per-publisher per- domain DANE TLSA-record per-MX certificate- association publication concurrently commit per-publisher per-domain DKIM- failure-mode per-selector cryptographic- trust-anchor publication discipline-floor (per-publisher per-domain per-selector public-key publication audit + per-selector key-rotation cadence + per-selector RSA- 2048-or-Ed25519 algorithm-choice + per- canonicalization-mode discipline-floor) because both per-publisher per-domain cryptographic-trust-anchor publication primitives MUST present coherent per- publisher per-domain cryptographic-trust- anchor discipline across the per-receiver- side per-message authentication evaluation chain; (ii) per-publisher per- domain DANE TLSA-record per-MX key-rotation cadence coordinated with per-publisher per- domain DKIM-failure-mode per-selector key- rotation cadence — per-publisher operators rotating per-publisher per-domain DANE TLSA-records (via 3-1-1 selector rotation publication overlap with old + new cert-association-data co-published during the per-publisher per-domain rotation window) concurrently rotate per-publisher per-domain DKIM-failure-mode per-selector public-keys (via dual-selector publication overlap during the per-publisher per- domain rotation window) because per- publisher per-domain cryptographic-trust- anchor key-rotation discipline-floor spanning the per-publisher per-domain application-layer DKIM-side + transport- layer DANE-side requires coordinated per- publisher per-domain rotation calendar cadence the DKIM-troubleshooting spoke is the per-publisher per-domain per- selector per-key-rotation discipline- floor reference for; (iii) per- publisher per-domain DANE TLSA-record DNSSEC-validation per-receiver-side failure-mode-class coordinated with per- publisher per-domain DKIM-failure-mode per-receiver-side diagnostic-discipline — when per-publisher per-domain DANE TLSA-record DNSSEC-validation produces per-receiver-side per-message STARTTLS-rejection verdicts at the per- receiver per-message transport-layer evaluation step, per-publisher per-domain DKIM-failure-mode per-receiver-side diagnostic-discipline becomes the per- publisher per-domain application-layer diagnostic-cross-reference per-publisher operators consult during cross-layer deliverability anomaly triage; (iv) per-publisher per-domain joint DANE-TLSA-and-DKIM cryptographic-trust- anchor incident-response discipline at per-publisher per-domain cryptographic- trust-anchor key-compromise event — when per-publisher per-domain cryptographic-trust-anchor key-compromise events affect either the per-publisher per-domain DANE TLSA-record per-MX certificate-association data OR the per- publisher per-domain DKIM-failure-mode per-selector public-key, per-publisher per-domain joint cryptographic-trust- anchor incident-response discipline-floor applies BOTH to the per-publisher per- domain transport-layer publication (per- publisher per-domain DANE TLSA-record rotation + per-publisher per-domain certificate-association-data publication rotation + per-MX DNSSEC-validation- chain integrity verification) AND to the per-publisher per-domain application- layer publication (per-publisher per- domain DKIM-failure-mode per-selector public-key rotation + per-publisher per- domain DKIM-failure-mode diagnostic- discipline floor recovery) — the DKIM- troubleshooting spoke is the per- publisher per-domain per-failure-mode- class incident-response diagnostic- discipline reference. Read the DKIM- troubleshooting spoke alongside this DANE-explained reference when AUTHORING per-publisher per-domain cross-layer (application-layer DKIM + transport-layer DANE) cryptographic-trust-anchor publication coordination runbooks, when EXECUTING per-publisher per-domain joint DANE-TLSA-and-DKIM cryptographic-trust- anchor key-rotation calendar cadence, when AUDITING per-publisher per-domain per-receiver-side cross-layer cryptographic- trust-anchor verification anomalies, or when ESTABLISHING per-publisher per- domain joint cross-layer cryptographic- trust-anchor incident-response discipline- floor coordinating DANE TLSA-record rotation with per-publisher per-domain DKIM-failure-mode discipline-floor recovery.
• RFC 7672 - SMTP Security via Opportunistic DANE TLS - the canonical SMTP-DANE profile.
• RFC 6698 - The DNS-Based Authentication of Named Entities (DANE) TLSA Resource Record - the base DANE specification establishing the TLSA record format.
• RFC 8460 - TLS-RPT - the SMTP TLS Reporting specification.
• RFC 4033 - DNS Security Introduction and Requirements - the DNSSEC architecture document; DANE's cryptographic-integrity prerequisite.
• DMARC attacker bypass techniques — the TRANSPORT-LAYER PER-RECEIVER-MTA PER-MESSAGE DANE-CERTIFICATE-PINNING-AS- APPLICATION-LAYER-DMARC-BYPASS-RESISTANCE threat-model companion to THIS page's per- publisher per-MX-host DANE TLSA-record publication discipline. Where THIS page documents the per-publisher per-MX-host DANE TLSA-record byte-grammar (the usage, selector, matching-type, and certificate-association-data fields per RFC 6698 §2.1), the DNSSEC- cryptographic-integrity prerequisite (RFC 4033 chain-of-trust validation), the per- receiver-MTA opportunistic-SMTP-DANE validation contract (RFC 7672 §2.1), and the per-publisher per-MX-host key-rollover discipline, the DMARC-attacker-bypass spoke documents the per-attacker per-message certificate-substitution MITM attack surface a per-publisher per-MX-host DANE publication gap exposes the per-publisher per-domain DMARC enforcement posture to. The DANE-VS-ATTACKER-BYPASS cross-reference establishes the per-publisher per-domain TRANSPORT-LAYER-CRYPTOGRAPHIC-PINNING-VS- APPLICATION-LAYER attack-bypass coupling: an active MITM attacker who can substitute a per-receiver-MTA TLS certificate at the per-publisher per-MX-host SMTP handshake boundary (via CA compromise, sub-CA misissuance, or BGP-hijack-driven receiver- side resolver poisoning) can capture per- message DKIM-signed payloads in cleartext, re-emit them with attacker-controlled From- header / Subject-header / body modifications, AND because the per-publisher per-domain SPF record published in DNS STILL authorises the per-attacker-side sending IP (if the attacker controls a per- receiver-side downstream-hop), the per- attacker re-emission can transit downstream receivers as a per-message DMARC-aligned- AND-DKIM-aligned payload despite the per- publisher per-domain DMARC enforcement posture. The per-publisher per-MX-host DANE TLSA-record publication discipline THIS page documents is the load-bearing DNSSEC-anchored cryptographic certificate- pinning floor that CLOSES this transport- layer-MITM-as-application-layer-DMARC- bypass precondition. Read THIS page when DEPLOYING the per-publisher per-MX-host DANE TLSA-record publication discipline; read the DMARC-attacker-bypass spoke when MODELING the per-publisher per-domain application-layer DMARC-authentication bypass attack surface a per-publisher per- MX-host DANE publication gap exposes the per-publisher per-domain DMARC enforcement posture to.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the TRANSPORT-LAYER DANE-TLSA-PUBLICATION- DISCIPLINE-AS-PRECONDITION-FOR-APPLICATION- LAYER-DMARC-POLICY-MODE-RAMP-PHASE-ADVANCEMENT readiness-floor companion to THIS DANE protocol pillar. Where THIS page documents the per- publisher per-MX-host DANE TLSA-record byte- grammar (the usage / selector / matching-type / certificate-association-data fields per RFC 6698 §2.1), the DNSSEC chain- of-trust prerequisite (RFC 4033 validation), the per-receiver-MTA opportunistic-SMTP-DANE validation contract (RFC 7672 §2.1), and the per-publisher per-MX-host TLSA-record dual- publication overlap-window discipline during certificate renewal, the DMARC-policy-modes spoke documents the publisher-side three-state p=-tag enforcement-policy ladder (p=none observe-only, p=quarantine probation, p=reject terminal) whose per- phase advancement gate the per-publisher per-MX-host DANE TLSA-record publication discipline structurally co-authors at FOUR per-publisher per-domain transport-layer-vs- application-layer policy-mode-ramp-coordination dimensions: (i) per-publisher per-MX- host DANE TLSA-record publication readiness as transport-layer precondition for per-publisher per-domain application-layer DMARC p=reject phase-advancement readiness — under per-publisher per- domain p=reject phase the per- attacker per-message direct-From:- spoofing attack surface collapses, so attackers pivot to transport-layer attack classes (per-receiver-MTA MITM TLS-certificate substitution + per-message DKIM-signed payload re-emission + per-receiver-MTA STARTTLS- downgrade), and the per-publisher per-MX-host DANE TLSA-record DNSSEC-anchored cryptographic- certificate-pinning closes the per-message certificate-substitution MITM precondition for application-layer DMARC-bypass before the per-publisher per-domain operator commits to terminal p=reject; (ii) per-publisher per-MX-host DANE TLSA-pin AVAILABILITY discipline as per- publisher per-domain DMARC policy-mode-ramp ROLLBACK PREVENTION — a per-publisher per-MX-host DANE TLSA-validation failure (stale TLSA-record post-certificate-rotation, DNSSEC chain-break, key-mismatch) BREAKS per-sender per-message SMTP delivery to every DANE-aware receiver (Microsoft Exchange Online, Mailcow, Postfix-with-DANE-enabled tenants), and per-receiver inbound mail-delivery breakage during a per-publisher per-domain DMARC p=quarantine/p=reject phase compounds the per-receiver rejection blast-radius — the per-publisher per-MX-host dual-TLSA overlap-window publication discipline THIS page documents prevents per- publisher per-MX-host TLSA-validation gap coinciding with per-publisher per-domain DMARC enforcement-floor commitment; (iii) per-publisher per-domain joint DANE- TLSA + DMARC enforcement-floor maintenance through per-policy-mode-ramp phase advancement — the per-publisher per- domain operator advances per-publisher per- domain DMARC p=none → p=quarantine → p=reject ramp ONLY AFTER the per-publisher per-MX-host DANE TLSA-record publication is stable AT EVERY per-publisher per-MX-host hop the per-publisher per-domain MX-record-published mail-exchanger inventory contains, because the per-receiver per-policy- mode rejection blast-radius compounds if the per-publisher per-MX-host TLSA-validation failure coincides with the per-publisher per- domain application-layer DMARC enforcement- floor commitment at the per-receiver per- message disposition-verdict computation boundary; (iv) per-publisher per- domain DMARC RUA aggregate-XML report + per-publisher per-domain TLS-RPT JSON aggregate-report dual-stream observability surface for joint transport-layer-vs- application-layer enforcement-distribution evidence — the per-publisher per- domain operator reads BOTH per-day per- receiver per-publisher per-domain DMARC RUA aggregate-XML report's per-source-IP per- disposition row distribution AND per-day per- receiver per-publisher per-domain TLS-RPT JSON aggregate-report's per-MX-host per- TLSA-validation-outcome distribution to correlate per-day per-receiver per-publisher per-domain transport-layer DANE TLSA- validation outcome with per-day per-receiver per-publisher per-domain application-layer DMARC policy-mode-ramp phase enforcement- disposition distribution, attributing per- policy-mode disposition-verdict variance to per-publisher per-MX-host TLSA-publication root cause OR per-publisher per-domain application-layer DMARC-record root cause. Read THIS DANE protocol pillar when PUBLISHING the per-publisher per-MX-host TLSA-record discipline AND when GATING the per-publisher per-domain DMARC policy-mode- ramp phase advancement against the per- publisher per-MX-host TLSA-publication readiness floor; read the DMARC-policy-modes spoke when COORDINATING the per-publisher per-domain application-layer DMARC enforcement- ramp phase advancement against the per- publisher per-MX-host transport-layer DANE TLSA-publication readiness floor THIS page documents.
• SPF for Google Workspace — the per-Workspace-tenant per-custom- domain envelope-MAIL-FROM-layer SPF publication-discipline companion to this transport-layer DANE TLSA-record reference. Where THIS page documents the per-publisher per-MX-host RFC 7672 DANE TLSA-record publication discipline (per- MX-host _25._tcp.<mx-host> DNSSEC-signed TLSA RR publication, per- certificate usage / selector / matching- type tag-vocabulary, per-publisher per- MX-host DANE-TLSA-verification floor), the SPF-for-Google-Workspace spoke documents the structurally parallel per- Workspace-tenant per-custom-domain envelope-MAIL-FROM-layer SPF publication (v=spf1 include:_spf.google.com -all canonical baseline, per-tenant per- custom-domain Gmail-egress include:_spf.google.com macro expansion at ~3 nested include: sub-records, per- tenant per-third-party-sender SPF- flattening discipline against the RFC 7208 §4.6.4 ten-DNS-lookup ceiling). Four per-Workspace-tenant per-custom-domain composite envelope-and-transport-layer publication coupling dimensions matter at the per-tenant per-custom-domain publication-portfolio boundary: (i) per- Workspace-tenant per-custom-domain envelope-MAIL-FROM-layer SPF vs transport- layer DANE TLSA dual DNS publication — the per-tenant per-custom-domain envelope- layer SPF v=spf1 per-domain root TXT- RR publication coexists with the per- tenant per-MX-host transport-layer DANE _25._tcp.<mx> TLSA RR publication THIS page documents at the per-tenant per-custom-domain DNSSEC- signed zone-file deployment boundary; (ii) per-Workspace-tenant per-custom-domain DNSSEC zone-signing prerequisite vs SPF DNSSEC-optionality — the per-tenant per- MX-host DANE TLSA publication REQUIRES per-tenant per-custom-domain DNSSEC zone- signing the per-receiver-side resolver validates BEFORE TLSA-record acceptance; per-tenant SPF publication does NOT require DNSSEC (per-tenant per-custom- domain SPF works with or without DNSSEC), but per-tenant DNSSEC-signed zone-file deployment enables per-tenant DANE TLSA publication AS WELL AS providing per- tenant SPF response-integrity protection; (iii) per-Workspace-tenant per-custom- domain composite envelope-layer-vs- transport-layer authentication-pipeline coordination — the per-tenant per-custom- domain Gmail-egress per-message envelope- MAIL-FROM authorization the SPF-for- Google-Workspace spoke documents IS per-message envelope-layer authentication evaluation; the per-tenant per-MX-host DANE TLSA verification THIS page documents IS per-receiver-side transport-layer per-connection certificate-binding evaluation; both compose at the per- tenant per-custom-domain composite envelope-and-transport-layer authentication- pipeline coordination boundary; (iv) per- Workspace-tenant per-custom-domain composite publication-portfolio coordination — the per-tenant per-custom- domain composite SPF + DKIM + DMARC + ARC + MTA-STS + DANE + TLS-RPT publication- portfolio THIS page's DANE transport- layer-publication component IS the per- tenant transport-layer publication- portfolio component, the SPF-for-Google- Workspace spoke's envelope-MAIL-FROM- layer publication-discipline IS the per- tenant envelope-layer publication- portfolio component, both consumed together at the per-tenant per-custom- domain publication-portfolio-coordination floor. Read THIS page when AUTHORING the per-publisher per-MX-host transport-layer DANE TLSA publication-discipline; read the SPF-for-Google-Workspace spoke when AUTHORING the per-Workspace-tenant per- custom-domain envelope-MAIL-FROM-layer SPF publication that per-tenant per- custom-domain transport-layer DANE TLSA publication THIS page documents structurally coordinates with at the per- tenant per-custom-domain composite envelope-and-transport-layer publication- portfolio coordination floor.
• DKIM replay attacks
• DKIM best practices
• Email deliverability
• DMARC reporting pipeline — the PER-PUBLISHER-PER-MX-HOST-DANE-TLSA-RR-DNSSEC-ANCHORED-TRANSPORT-LAYER-AGGREGATE-OBSERVABILITY-COORDINATION-AS-STRUCTURALLY-PARALLEL-AGGREGATE-REPORT-PIPELINE-COMPANION-TO-PER-PUBLISHER-PER-DOMAIN-DMARC-RUA-XML-AGGREGATE-REPORT-APPLICATION-LAYER-EMISSION-PIPELINE companion at four DANE-transport-layer-aggregate-observability-vs-DMARC-RUA-aggregate-report-pipeline coupling dimensions (per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored publication per RFC 6698 + RFC 7672 drives per-receiver per-MX-host STARTTLS-required-or-fail enforcement-verdict whose per-receiver per-day per-policy-domain per-result-type attribution stream surfaces in per-publisher per-policy-domain TLS-RPT JSON-aggregate-report emission per RFC 8460 §4 IS structurally parallel transport-layer aggregate-report-emission-pipeline to per-publisher per-domain DMARC RUA XML-aggregate-report-emission-pipeline per RFC 7489 §7 the reporting-pipeline spoke documents the per-publisher per-domain application-layer aggregate-report-emission cadence of — both per-publisher per-domain per-day per-receiver per-leg aggregate-report-emission-pipelines gate per-publisher per-domain operator-actionable per-day per-leg-verdict drift-closure observability at the per-publisher per-domain composite cross-protocol per-day per-leg aggregate-report-emission-pipeline coordination boundary / per-publisher per-MX-host DANE TLSA-RR transport-layer authentication-floor IS the load-bearing transport-layer per-message envelope-delivery-integrity precondition whose per-receiver per-MX-host STARTTLS-required-or-fail enforcement preserves the per-receiver per-message envelope-integrity baseline against active downgrade-attack MITM — per-publisher per-domain DMARC RUA aggregate-report per-row policy_evaluated/{spf,dkim} attribution stream per RFC 7489 §6.6.1 visibility into per-publisher per-domain composite-aligned-pass-rate floor preservation under threat-actor STARTTLS-stripping MITM topology REQUIRES per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored certificate-pinning commitment the DANE deep-dive THIS page documents the per-publisher per-MX-host transport-layer trust-anchor publication discipline of / per-publisher per-MX-host DANE TLSA-RR publication-discipline at _443._tcp.<mx-host> IS structurally parallel underscore-prefixed-resource-record publication-discipline to per-publisher per-domain DMARC TXT-RR publication-discipline at _dmarc.<domain> carrying the per-publisher per-domain rua=mailto: aggregate-report-URI per RFC 7489 §6.2 the per-publisher per-domain DMARC RUA aggregate-report-pipeline THIS reporting-pipeline reference is the receiver-emission cadence-and-attribution primer of structurally consumes / per-publisher per-MX-host DANE TLSA-RR + per-publisher per-domain MTA-STS + per-publisher per-domain TLS-RPT cross-protocol transport-layer-publication-discipline triple surfaces transport-layer-failure-mode evidence in per-receiver per-day TLS-RPT JSON-aggregate-report stream parallel to per-publisher per-domain SPF + DKIM + DMARC cross-protocol application-layer-publication-discipline triple surfacing application-layer-authentication-leg-fail evidence in per-receiver per-day DMARC RUA XML-aggregate-report stream the reporting-pipeline spoke documents the per-publisher per-domain receiver-emitted observability stream of — both per-publisher per-domain per-day per-receiver per-leg aggregate-evidence-channel-publication-discipline references jointly underpin per-publisher per-domain operator-actionable per-day per-leg drift-closure observability at the per-publisher per-domain composite cross-protocol cross-layer per-day per-receiver aggregate-observability coordination boundary).
• DMARC monitoring
• DMARC for SaaS senders — the PER-PUBLISHER-PER-MX-HOST-DANE-TLSA-RR-DNSSEC-ANCHORED-TRANSPORT-LAYER-CRYPTOGRAPHIC-FLOOR-AS-STRUCTURALLY-PARALLEL-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-SAAS-TENANT-PER-CUSTOM-DOMAIN-DMARC-APPLICATION-LAYER-ENFORCEMENT-PUBLICATION companion at four DANE-transport-layer-vs-SaaS-tenant-DMARC coupling dimensions: (i) per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored cryptographic-certificate-pinning per RFC 6698 + RFC 7672 IS structurally parallel per-tenant transport-layer cryptographic-publication discipline to per-SaaS-tenant per-custom-domain DMARC application-layer enforcement-mode publication per RFC 7489 §6.3 — both per-tenant per-custom-domain publication-discipline references underpin per-tenant per-custom-domain composite cross-layer authentication-and-integrity floor whose per-receiver-side enforcement gates per-SaaS-tenant per-customer-onboarding-deliverability outcome; (ii) per-publisher per-MX-host DANE TLSA-RR underscore-prefixed-resource-record publication at _443._tcp.<mx-host> IS structurally parallel underscore-prefixed-resource-record publication discipline to per-SaaS-tenant per-custom-domain DMARC TXT-RR publication at _dmarc.<custom-domain> per RFC 7489 §6.1 the SaaS-senders spoke documents the per-tenant per-custom-domain DMARC publication-discipline of — both underscore-prefixed publication-discipline references depend on per-tenant per-custom-domain DNS-zone-publication-discipline-and-DNSSEC-prerequisite coordination; (iii) per-publisher per-MX-host DANE-secured STARTTLS-required transport-layer envelope-integrity floor IS the load-bearing per-receiver per-message envelope-delivery integrity precondition preserving per-SaaS-tenant per-custom-domain DMARC-aligned-pass-rate evidence-stream-continuity against threat-actor STARTTLS-stripping MITM downgrade-attack-class — per-SaaS-tenant per-customer-onboarding-deliverability outcome materially depends on per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored certificate-pinning floor preserving per-tenant per-customer DMARC RUA evidence-row attribution-continuity; (iv) per-publisher per-MX-host DANE TLSA-RR + per-SaaS-tenant per-custom-domain SPF + DKIM + DMARC cross-protocol publication-discipline triple JOINTLY underpins per-SaaS-tenant per-customer onboarding-cadence composite cross-layer authentication-and-integrity floor — per-SaaS-tenant per-customer-onboarding publication-discipline coordination cascades DANE TLSA-RR DNSSEC-prerequisite into per-customer-tenant per-custom-domain DNS-publication-discipline floor the SaaS-senders spoke documents the per-tenant per-custom-domain SPF-include + DKIM-CNAME + DMARC TXT-RR publication-discipline of at the per-SaaS-tenant per-customer composite cross-protocol cross-layer publication-discipline coordination boundary.
• SPF 10-DNS-lookup limit
• DKIM canonicalization — the PER-PUBLISHER-PER-MX-HOST-DANE-TLSA-RR-DNSSEC-ANCHORED-TRANSPORT-LAYER-CRYPTOGRAPHIC-CERTIFICATE-PINNING-AS-LOAD-BEARING-ENVELOPE-INTEGRITY-PRECONDITION-FOR-PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-CANONICALIZATION-PRODUCED-BODY-HASH-BYTE-STREAM-INTEGRITY-PRESERVATION companion at four per-publisher per-domain DANE-transport-layer-vs-DKIM-canonicalization-application-layer coupling dimensions: (i) per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored cryptographic-certificate-pinning per RFC 6698 + RFC 7672 IS the load-bearing per-receiver per-MX-host STARTTLS-required-or-fail enforcement-floor preserving per-message envelope-byte-stream-integrity baseline against active MITM downgrade-attack-class — per-publisher per-selector DKIM canonicalization-produced bh= body-hash byte-stream integrity per RFC 6376 §3.4 materially depends on per-receiver-side per-message body-bytes arriving unmodified through transit which the per-publisher per-MX-host DANE TLSA-RR transport-layer cryptographic-trust-anchor publication-discipline THIS page documents structurally underpins; (ii) per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored publication-discipline at _443._tcp.<mx-host> IS structurally parallel transport-layer cryptographic-publication discipline to per-publisher per-selector DKIM canonicalization-mode publication-decision per RFC 6376 §3.4 application-layer cryptographic-byte-stream production-discipline — both per-publisher per-domain cryptographic-byte-stream-publication primitives are per-publisher per-domain operator-side cryptographic-integrity production primitives the per-receiver-side per-message cryptographic-verification consumes; (iii) per-publisher per-MX-host DANE-secured STARTTLS-required transport-layer envelope-integrity floor preserves per-message canonical-body-byte-stream-stability against forwarder-injection / mailing-list-footer-mutation / content-transform-middleware byte-stream-rewriting cascade THAT per-publisher per-selector DKIM c=simple/simple canonicalization-mode publication-decision per RFC 6376 §3.4.3 cannot tolerate AT ALL surfacing as per-receiver per-message dkim=fail body hash did not verify per RFC 6376 §3.9 + RFC 8601 §2.7.1 collapsing DKIM-leg of DMARC composite-aligned-pass disjunction whose preserved-rate floor depends on per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored STARTTLS-required-or-fail enforcement; (iv) per-publisher per-MX-host DANE TLSA-RR publication-discipline drift (mis-published TLSA-RR / DNSSEC-chain-break / per-MX-host cert-rotation-without-TLSA-RR-update) surfaces in per-receiver per-day TLS-RPT JSON-aggregate-report tlsa-invalid attribution per RFC 8460 §4.3 IS structurally parallel cross-layer publication-discipline-drift-attribution to per-publisher per-selector DKIM canonicalization-mode publication-discipline drift (premature c=simple/simple publication-decision under MIME re-encoding / transfer-encoding-change middleware) surfacing in per-receiver per-day DMARC RUA aggregate-report policy_evaluated/dkim=fail attribution per RFC 7489 §6.6.1 — both per-publisher per-domain per-day per-receiver per-leg aggregate-evidence-channel publication-discipline references jointly underpin per-publisher per-domain operator-actionable per-day per-leg drift-closure observability at the per-publisher per-domain composite cross-protocol cross-layer per-day per-receiver aggregate-observability coordination boundary THIS DANE deep-dive page documents the per-publisher per-MX-host transport-layer trust-anchor publication-discipline of.
• ARC (Authenticated Received Chain) explained — the PER-PUBLISHER-PER-MX-HOST-DANE- TLSA-RR-DNSSEC-ANCHORED-TRANSPORT-LAYER- CRYPTOGRAPHIC-TRUST-ANCHOR-AS-LOAD-BEARING- TRANSPORT-LAYER-INTEGRITY-PRECONDITION-OF- PER-FORWARDER-PER-HOP-ARC-CHAIN-OF-CUSTODY- PRESERVATION companion at four per-publisher per-MX-host DANE-transport-layer-vs-ARC- chain-of-custody coupling dimensions: (i) per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored cryptographic-certificate- pinning per RFC 6698 + RFC 7672 IS the load-bearing per-receiver per-MX-host STARTTLS-required-or-fail enforcement-floor preserving per-message envelope-byte-stream- integrity baseline against active MITM downgrade-attack-class — per-forwarder per-hop ARC-Message-Signature cryptographic- attestation per RFC 8617 §5 materially depends on per-message body-bytes arriving unmodified through transit between per- forwarder hops which the per-publisher per- MX-host DANE TLSA-RR transport-layer cryptographic-trust-anchor publication- discipline THIS page documents structurally underpins; (ii) per-publisher per-MX-host DANE-secured STARTTLS-required transport- layer envelope-integrity floor preserves per-forwarder per-hop ARC-chain cryptographic-attestation-byte-stream- integrity against active MITM downgrade- attack-class targeting per-forwarder per- hop ARC-signed message in-transit — without per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored STARTTLS-required- or-fail enforcement, per-forwarder per-hop ARC-chain cryptographic-attestation publication-discipline can be structurally invalidated by active MITM tampering cascading into per-receiver per-mailbox- provider ARC-chain honour decision regression the ARC explained spoke documents the per-forwarder per-hop diagnostic ladder of; (iii) per-publisher per-MX-host DANE TLSA- RR DNSSEC-anchored publication-discipline IS structurally parallel transport-layer cryptographic-publication-discipline to per-forwarder per-hop ARC-signing-key publication at <arc-selector>._domainkey.<forwarder-domain> TXT-RR DNS-publication-discipline — both per-publisher per-domain cryptographic- publication primitives are operator-side cryptographic-integrity production primitives the per-receiver-side per-forwarder per- hop per-message ARC-chain cryptographic- verification consumes; (iv) per-publisher per-MX-host DANE TLSA-RR publication- discipline drift (mis-published TLSA-RR / DNSSEC-chain-break / per-MX-host cert- rotation-without-TLSA-RR-update) IS structurally parallel cryptographic- publication-discipline-drift class to per- forwarder per-hop ARC-Message-Signature cryptographic-attestation publication- discipline drift (missing AAR header / invalid AMS signature / broken AS chain) the ARC explained spoke documents the per- forwarder per-hop diagnostic ladder of. Read the ARC explained spoke when AUTHORING per-publisher per-MX-host DANE TLSA-RR DNSSEC-anchored transport-layer cryptographic- trust-anchor publication discipline coordinated with per-forwarder per-hop ARC chain-of- custody preservation discipline at the per- publisher per-MX-host composite cross-layer transport-layer-cryptographic-trust-and- forwarder-survival publication-discipline coordination boundary.
• DMARC for transactional email
• include vs ip4 vs a vs mx — the SPF-mechanism-selection companion to this DANE explainer. DANE publishes a TLSA record at _25._tcp.<mx-host> for every mail exchanger in the domain's MX set per RFC 7672, and that same MX-host set is exactly what the SPF mx mechanism resolves — so deciding whether to authorize senders via mx / a or to flatten them into explicit ip4: ranges under the ten-DNS-lookup cap operates over the same mail-exchanger inventory the TLSA records pin. Read the mechanism-selection spoke when identifying the MX-host set DANE certificate pinning attaches to.
• DMARC for cPanel — the shared-hosting transport-security context where DANE is usually out of the operator's hands. On a cPanel/Exim hosting node the inbound MX, the TLS certificate, and the DNSSEC-signed zone needed to publish a TLSA record per RFC 7672 are typically controlled by the hosting provider, not the domain owner — so a cPanel operator who wants DANE-anchored inbound transport (rather than the MTA-STS alternative) must escalate to the provider. The cPanel guide documents what the shared-hosting operator can control directly (the DMARC TXT-RR, the auto-generated SPF/DKIM via Email Deliverability) and where transport-layer hardening like DANE or MTA-STS requires provider cooperation. Read the cPanel spoke to see which half of the DANE deployment a shared-hosting customer owns.
• Email authentication glossary — the plain-language reference for the authentication and transport-security vocabulary this DANE page draws on. TLSA, DNSSEC, MTA-STS, STARTTLS and the SPF/DKIM/DMARC terms DANE sits alongside are each defined there in one place — read the glossary when a term in this DANE reference needs grounding before you act on it.
• Microsoft SNDS + JMRP monitoring — transport security decides whether mail travels over verified TLS; Microsoft's IP-reputation gate decides which folder it lands in. SNDS + JMRP monitoring covers that consumer-network reputation layer for Outlook.com/Hotmail recipients.

13. Check your current DANE posture

DMARC Analyzer's free Domain Security Checker performs live DMARC + SPF + DKIM + MTA-STS + BIMI + DNSSEC lookups against any domain. Use it to verify DNSSEC validates correctly on your zone (the DANE prerequisite), confirm your MTA-STS policy publishes the right MX targets, and identify the MX hostnames that need TLSA records. The DNS Record Generator builds syntactically-correct DANE TLSA records with the canonical 3 1 1 (DANE-EE / SPKI / SHA-256) shape directly from your SMTP server certificate. Imported TLS-RPT reports (via includes/TlsRptParser.php) drive the dashboard that surfaces transport-security failures and reveals when DANE-validating senders fall back to plaintext or refuse delivery.

Check my current DANE posture Sign up — Free plan