DMARC Analyzer

TL;DR

• Same threat, different trust anchor: Both MTA-STS (RFC 8461) and DANE for SMTP (RFC 7672) defend SMTP transport against STARTTLS-stripping and downgrade attacks. They differ on what they TRUST.
• MTA-STS trusts the public web PKI plus HTTPS. Policy lives in an HTTPS-fetched text file at https://mta-sts.example.com/.well-known/mta-sts.txt. Does NOT require DNSSEC.
• DANE trusts DNSSEC. Policy lives in a TLSA record at _25._tcp.mx.example.com signed by DNSSEC. DOES require DNSSEC on the recipient zone.
• Coexistence rule (RFC 7672 section 1.3): a sender that supports both prefers DANE when a TLSA record validates and falls back to MTA-STS otherwise.
• Provider support: MTA-STS is broader (Microsoft 365, Google, Yahoo, ProtonMail, Comcast, mailbox.org). DANE is narrower but growing (Google, ProtonMail, Posteo, mailbox.org, Comcast, Hetzner, .gov sector). Microsoft 365 added DANE outbound in 2022.
• Best practice: publish BOTH. DANE for the DANE-capable senders, MTA-STS for the rest. Add TLS-RPT (RFC 8460) to see failures from either.
• Single most common mistake: deploying DANE without DNSSEC on the zone - DANE is meaningless and SHOULD-NOT-VALIDATE per RFC 7672 section 2.1.1.

1. Overview: why two standards exist for the same problem

Both MTA-STS and DANE for SMTP exist because the SMTP protocol's STARTTLS upgrade is unauthenticated by default. An attacker that can rewrite SMTP responses on the wire can strip the STARTTLS capability and force the sender into a plaintext channel - the sender sees an opportunistic-TLS service that simply chose not to advertise TLS, and delivers the message in cleartext.

Both standards fix the same hole - they tell the sender "this recipient REQUIRES TLS and here is what the certificate should look like" - but they were developed by different working groups with different design philosophies and different assumptions about what infrastructure is universally available.

• DANE (RFC 6698 original spec, RFC 7672 SMTP profile) came first. Released by the IETF DANE working group in 2012-2015 building on the DNSSEC ecosystem. Trust anchor: the recipient's DNSSEC-signed zone. The TLSA record IS the policy.
• MTA-STS (RFC 8461, 2018) came later, designed by Google, Microsoft, LinkedIn, Comcast, Yahoo, and 1and1 as a DANE-alternative that does not require DNSSEC. Trust anchor: the public web PKI plus HTTPS. The policy is fetched out-of-band over HTTPS.

They are NOT competing standards in the "winner-takes-all" sense - the IETF explicitly designed MTA-STS to COEXIST with DANE, and the standards documents (RFC 8461 section 2 + RFC 7672 section 1.3) reference each other. Most large providers ultimately deploy both.

2. The threat model both standards address

Both standards mitigate the same attacks. Defining the attacker capabilities precisely clarifies why different trust anchors lead to different deployment trade-offs.

2.1 STARTTLS stripping

The classic active attack: an attacker on the network path between sender and recipient SMTP server rewrites the EHLO response to remove the STARTTLS capability advertisement. The sender, seeing no STARTTLS offered, falls back to plaintext delivery. The message body, headers, and authentication credentials all transit unencrypted.

2.2 SMTP MX downgrade

A subtler variant: the attacker manipulates DNS responses so the sender routes mail to an attacker-controlled MX with a self-signed cert, a CA-signed cert for a different name, or no TLS at all. The sender connects, optionally accepts the certificate under opportunistic-TLS rules, and delivers the message to the attacker.

2.3 Certificate-mismatch acceptance

Default SMTP TLS is "opportunistic" - the sender will accept ANY valid TLS handshake regardless of whether the certificate matches the MX hostname, is expired, is self-signed, or chains to an unknown CA. Both MTA-STS and DANE upgrade this to strict certificate validation.

2.4 The DNSSEC question

The threat model assumes the attacker can spoof DNS responses (case 2.2) - otherwise no policy advertised IN DNS would be trustworthy. DANE answers this by REQUIRING DNSSEC on the recipient zone: the sender validates the DNSSEC chain end-to-end before trusting the TLSA record. MTA-STS answers this differently: the discovery TXT record is fetched over plain DNS, but the policy file itself comes over HTTPS, so the web PKI plus HTTPS chain provides the integrity guarantee instead of DNSSEC.

2.5 What neither standard addresses

• An attacker who controls a CA in the standard root store (MTA-STS) - same threat as web-PKI-trust HTTPS everywhere.
• An attacker who can compromise the DNSSEC signing key for the recipient zone (DANE).
• An attacker who controls the recipient SMTP server itself - neither standard authenticates the receiver beyond hostname / cert chain.
• Message confidentiality at rest after delivery - both standards stop at the SMTP transport layer.

3. MTA-STS in one screen

Detailed coverage of MTA-STS is in the dedicated MTA-STS deep dive. This section is the short summary needed for the comparison.

3.1 Two-record DNS contract plus HTTPS policy file

The recipient publishes:

_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260521120000"

And serves at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: mail.example.com
mx: mail2.example.com
max_age: 604800

3.2 Sender behaviour

• Sender queries the _mta-sts.example.com TXT - sees the version + policy ID.
• If the ID is new (or the cache expired), fetch the policy over HTTPS from https://mta-sts.example.com/.well-known/mta-sts.txt - the web PKI authenticates the HTTPS connection.
• For each MX delivery attempt, verify the recipient SMTP server presents a CA-signed certificate whose subjectAltName matches one of the mx: patterns from the policy.
• In mode: enforce, refuse delivery if no MX in the policy has a valid TLS cert.

3.3 Failure modes

• HTTPS policy file unreachable: sender uses cached policy until max_age expires.
• Discovery TXT record missing: sender treats the domain as MTA-STS-not-deployed (no enforcement).
• Web PKI CA compromise: sender may accept attacker-controlled policy file.

4. DANE for SMTP in one screen

DANE for SMTP is specified by RFC 7672 (SMTP profile) building on RFC 6698 (the base DANE / TLSA spec).

4.1 TLSA record contract

The recipient publishes a TLSA record at _25._tcp.<mx-hostname> for each MX hostname:

_25._tcp.mail.example.com.  IN  TLSA  3 1 1 8E1F2DE7D81A2BCB3C0F3D9CB2A7A2D2D4A6D5C3B8E2F9A1F7C0D5B6E3A9F8C2

The four fields are: Usage / Selector / MatchingType / Certificate-Association-Data.

4.2 TLSA field reference (the values that matter for SMTP)

• Usage: 0 PKIX-TA, 1 PKIX-EE, 2 DANE-TA, 3 DANE-EE. DANE-EE (3) is the recommended SMTP deployment per RFC 7672 section 3.1.3 - the TLSA record is bound to the end-entity certificate or key directly, bypassing the CA chain entirely.
• Selector: 0 full certificate, 1 SubjectPublicKeyInfo. Selector 1 is the recommended SMTP deployment because it survives certificate renewal when the public key is unchanged (the cert's NotBefore / NotAfter dates rotate but the key does not).
• MatchingType: 0 full data exact match, 1 SHA-256 hash, 2 SHA-512 hash. MatchingType 1 (SHA-256) is the recommended SMTP deployment for record-size efficiency.

The canonical SMTP TLSA deployment is therefore 3 1 1 - DANE-EE / SubjectPublicKeyInfo / SHA-256.

4.3 DNSSEC requirement (the load-bearing prerequisite)

A DANE-validating sender MUST validate the DNSSEC chain on both:

• The MX record for the recipient domain.
• The TLSA record at _25._tcp.<mx-hostname>.

If either DNSSEC chain is bogus, the sender MUST NOT use the TLSA association. If neither is signed (insecure delegations), DANE does not apply - the sender falls back to opportunistic TLS or MTA-STS.

4.4 Sender behaviour

• Resolve the recipient MX record with DNSSEC validation.
• For each MX hostname, query _25._tcp.<mx> with DNSSEC validation.
• If a validated TLSA exists, connect via STARTTLS and validate the server certificate against each TLSA association.
• If validation succeeds, deliver; if fails, refuse delivery (the SMTP RFC requirement bites here - DANE upgrades a soft TLS error to a hard delivery failure).

4.5 Failure modes

• Recipient zone not DNSSEC-signed: DANE does not apply. The sender falls back. This is often-discovered the hard way: the operator publishes TLSA records, runs their checker, and the validation silently fails because the zone delegation is unsigned.
• DNSSEC validation failure (bogus): the sender MUST refuse delivery per RFC 7672 section 2.2.1 - protecting against attacker-injected records.
• Certificate rotation without TLSA rotation: cert fingerprint no longer matches; deliveries bounce. Use Selector 1 (SubjectPublicKeyInfo) and rotate the public key on the deliberate cadence rather than every cert renewal to avoid this.

5. Keystone comparison table: MTA-STS vs DANE for SMTP

The side-by-side reference operators read when they need to choose, deploy, or troubleshoot. Each row is a single comparison dimension.

6. Provider support reference (sending + receiving, as of 2026)

Which providers send via DANE, MTA-STS, or both? Which providers PUBLISH TLSA records or MTA-STS policies for inbound mail to their domains? The reference below reflects the state as of 2026 - deployment momentum is positive on both standards, so verify with the operator's published transport security page before architectural decisions.

6.1 Sending side - validates and enforces what the recipient publishes

6.2 Receiving side - publishes a policy / TLSA so others validate against it

Verify provider capability against the operator's own transport security documentation before architectural decisions. The matrix above is a snapshot of 2026 deployment - operators have been adding support steadily.

7. Coexistence rules - when both are deployed

The IETF designed both standards to coexist. RFC 7672 section 1.3 specifies the precedence order when a sender supports both AND the recipient publishes both:

1. DANE first. Sender queries the _25._tcp.<mx> TLSA record with DNSSEC validation.
2. If a validated TLSA exists, the sender uses DANE. The TLSA association determines the certificate validation outcome. MTA-STS policy lookup is skipped because DANE is already authoritative.
3. If DNSSEC is insecure (unsigned delegation), the sender moves on - DANE does not apply.
4. If DNSSEC is bogus (validation failure), the sender MUST NOT proceed with the original certificate regardless of MTA-STS - bogus DNSSEC indicates an attack and the connection should be aborted rather than falling back to MTA-STS.
5. MTA-STS fallback. If DANE did not apply (case 3), the sender performs the MTA-STS discovery TXT lookup + HTTPS policy fetch and validates the cert against the MTA-STS policy.
6. Opportunistic TLS fallback. If neither standard applies, the sender uses STARTTLS opportunistically with whatever certificate the receiver presents.

The TLS-RPT (RFC 8460) reporting endpoint at _smtp._tls.example.com receives failure reports from EITHER standard - the policy-type field in the report body identifies whether the failure was MTA-STS, TLSA, or generic STARTTLS. One reporting endpoint covers both standards.

Implication for the recipient operator: there is no downside to publishing both. A correctly deployed MTA-STS policy is invisible to DANE-only senders (they never look at it), and a correctly deployed TLSA record is invisible to MTA-STS-only senders. Coverage is strictly additive.

8. Decision matrix - which to deploy when

Operators face three common decision points. Use the matrix to short-circuit the "which should I deploy" question.

8.1 "I am starting from zero - which should I deploy first?"

• If your zone is already DNSSEC-signed: deploy DANE first. You have the prerequisite already; adding TLSA records is cheap and protects against the strongest attacker model.
• If your zone is NOT DNSSEC-signed: deploy MTA-STS first. DNSSEC deployment is a separate multi-week project; do not block SMTP transport security on it.
• Plan to deploy BOTH eventually. Coverage is strictly additive - MTA-STS protects you from senders without DANE (most), DANE protects you from MTA-STS bypasses (a CA root compromise) for senders that support DANE.

8.2 "I run an internal corporate SMTP gateway - do I need either?"

• If the gateway only sends to internal recipients: opportunistic TLS plus internal PKI is usually sufficient.
• If the gateway sends to external recipients (the common case): publishing MTA-STS or DANE on the SENDING domain does not affect outbound TLS - it advertises INBOUND policy. You should still configure the gateway to VALIDATE recipient MTA-STS and DANE policies on outbound mail.

8.3 "I am being audited / need a compliance check-box - which is recognised?"

• US federal sector: BOD 18-01 mandates BOTH MTA-STS and DANE for .gov domains.
• EU NIS2 + DORA: do not name MTA-STS or DANE specifically but require "encrypted email transport with appropriate cryptographic controls" - either standard satisfies. DANE is technically stronger.
• UK NCSC Mail Check / Cyber Assessment Framework: encourages both; specifically names MTA-STS as a deployment target.
• BIMI: BIMI itself does not require MTA-STS or DANE, but BIMI implementations are increasingly co-deployed with transport security.

8.4 "My TLSA records validate today - can I drop MTA-STS?"

• No - MTA-STS covers senders that do not support DANE. Microsoft 365 historically used MTA-STS before adding DANE outbound in 2022; Yahoo / AOL still rely primarily on MTA-STS as of 2026.
• Keep both published - coverage is additive.

8.5 "DNSSEC adds operational complexity I cannot afford - is MTA-STS only acceptable?"

• Yes. MTA-STS-only is a complete deployment and addresses the same threat model from most senders. The trade-off is web-PKI trust rather than DNSSEC trust - a compromised CA in the standard root store can issue a cert that defeats MTA-STS; DNSSEC is not susceptible to that particular attack.
• Many medium-and-large providers (Yahoo, Office 365 historically) deploy MTA-STS only.

9. Migration paths - from one to both (or one to the other)

9.1 MTA-STS-only -> MTA-STS + DANE

1. Verify the recipient zone is DNSSEC-signed. Use dig +dnssec example.com SOA and confirm the ad flag is set on the response.
2. For each MX hostname, generate a TLSA record from the current SMTP server certificate. The recommended deployment is 3 1 1 (DANE-EE / SPKI / SHA-256). Tools: openssl x509 -in mail.crt -pubkey -noout | openssl asn1parse -strparse 19 -out spki.bin; openssl dgst -sha256 spki.bin (or posh-dnssec / swede / danetool).
3. Publish the TLSA records at _25._tcp.<mx> with TTL 300-3600 during rollout (lower TTL for fast rollback).
4. Wait for the DNS to converge + propagate through DNSSEC validators (typ. 1-2 cycles of the TTL).
5. Validate from a DANE-capable test sender (e.g. a Posteo or mailbox.org account, or the danetool / posh-dnssec CLI verifiers).
6. Confirm TLS-RPT reports for the next 1-2 weeks show TLSA success (or failures to diagnose).
7. Raise the TTL on the TLSA records to 3600-86400 once stable.

9.2 DANE-only -> DANE + MTA-STS

1. Confirm an HTTPS host is available at mta-sts.example.com with a CA-signed certificate that chains to the public web PKI.
2. Author the policy file at /.well-known/mta-sts.txt with version: STSv1; mode: testing; mx: entries for each production MX; max_age: 86400 for the testing phase.
3. Publish the discovery TXT at _mta-sts.example.com with v=STSv1; id= as a fresh identifier.
4. Monitor TLS-RPT for 7-14 days at mode: testing to discover any unexpected MX hostnames.
5. Promote to mode: enforce once test mode is clean.
6. Raise max_age to 604800-2592000 for steady-state caching.

9.3 Certificate rotation under DANE-EE / Selector 1 (SPKI)

1. Generate the NEW certificate with the SAME public key as the current TLSA record. If the renewal generates a new key, the TLSA record fingerprint will change and you must rotate it.
2. If the public key is unchanged: no TLSA rotation needed. The cert NotBefore / NotAfter dates rotate but the TLSA stays valid.
3. If the public key changes (key rotation): publish the NEW TLSA record alongside the OLD one ahead of cert deployment - then deploy the new cert + remove the old TLSA once the renewed cert is live and the new TLSA TTL has propagated. The 2-record overlap window covers any cached lookups with the old TLSA fingerprint.

9.4 Adding TLS-RPT - the operational glue for both standards

Both MTA-STS and DANE benefit from TLS-RPT (RFC 8460) observability. Publish a single _smtp._tls.example.com TXT and receive structured failure reports covering BOTH standards - the policy-type in each report identifies which one failed.

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

The TLS-RPT pillar (help_tls_rpt_explained.php) documents the format end-to-end.

10. Common mistakes

• Deploying DANE without DNSSEC. TLSA records on an unsigned zone are ignored by validating senders - DANE REQUIRES DNSSEC end-to-end per RFC 7672 section 2.1.1. The records cost nothing to publish but they protect nothing. Confirm DNSSEC on the zone before publishing TLSA.
• TLSA record at the wrong location. The record goes at _25._tcp.<mx-hostname> NOT at the apex of the recipient domain and NOT at example.com. Each MX hostname gets its own TLSA record. The 25 is the SMTP port; the tcp is the protocol.
• Using Usage 0 or 1 (PKIX-TA / PKIX-EE) on the recipient side. These usages require the cert to chain to a public CA AND match the TLSA. Recommended SMTP deployment is Usage 3 (DANE-EE) which decouples from the CA chain entirely. Public CAs sometimes refuse to issue certs for SMTP hostnames or have outage windows; DANE-EE is robust against both.
• Forgetting to rotate TLSA when rotating cert keys. If you use Selector 0 (full cert) or rotate the SubjectPublicKeyInfo, the TLSA fingerprint changes and senders will reject the new cert. Always pre-publish the new TLSA alongside the old before the cert rotation, and only remove the old TLSA after the new cert is live + TTL has propagated.
• MTA-STS policy file served over HTTP instead of HTTPS. RFC 8461 section 3.3 requires HTTPS - HTTP-served policy files are rejected by validating senders. The whole point of MTA-STS is the HTTPS chain providing integrity.
• MTA-STS policy file with stale mx: entries. The mx: pattern must match each production MX hostname (or use wildcards like mx: *.example.com). Stale entries from a previous MX configuration cause delivery failures.
• Missing TLS-RPT. Without TLS-RPT you do not know if your MTA-STS or DANE policy is failing for ANY sender. Always publish TLS-RPT alongside either standard.
• Treating MTA-STS and DANE as either/or. They are explicitly designed to coexist. Publish both whenever the prerequisite (DNSSEC for DANE, HTTPS for MTA-STS) is satisfied - coverage is additive.

11. Troubleshooting common failures

11.1 "I published TLSA records but DANE-capable senders are not validating"

• Verify DNSSEC is enabled on the recipient zone - dig +dnssec example.com SOA should show the ad flag in the response header.
• Verify the TLSA record is at _25._tcp.<mx> not the apex - dig TLSA _25._tcp.mail.example.com should return the record.
• Verify the TLSA fingerprint matches the served SMTP cert - use danetool --check or posh-dnssec to test.
• Verify the DNSSEC chain validates - delv +short example.com SOA should resolve without bogus.

11.2 "MTA-STS policy fetch returns 404"

• Verify the file is at the EXACT path /.well-known/mta-sts.txt - the leading dot in .well-known trips some web servers that hide dotfiles.
• Verify the HTTPS cert on mta-sts.example.com chains to a public CA - self-signed certs are rejected.
• Verify the response Content-Type is text/plain.

11.3 "Mail to a DANE-publishing recipient is bouncing after a cert renewal"

• The renewed cert generated a new public key. If you use Selector 1 (SPKI), the TLSA fingerprint changed - publish the new TLSA alongside the old, deploy the cert, then remove the old TLSA after TTL has propagated.
• If you use Selector 0 (full cert), every cert renewal requires TLSA rotation. Switch to Selector 1 if you want to decouple cert renewal from TLSA rotation.

11.4 "TLS-RPT reports show MTA-STS failures from a single sender"

• Check the policy-type in the report: if it is sts, the failure is in the MTA-STS path. If tlsa, it is DANE.
• Match the failing policy-strings against the published policy file - common cause is a stale mx: pattern that did not get updated after an MX change.
• Verify the policy ID in the discovery TXT record matches the policy file content - if the ID is stale the sender may be cacheing an old policy.

11.5 "DANE validation reports bogus DNSSEC"

• Bogus is the dangerous state - it means DNSSEC validation FAILED. Confirm the zone's DS record at the parent zone matches the published DNSKEY.
• Confirm the DNSKEY rollover has propagated - a stale DS at the registrar after a key rollover is the canonical cause.
• Confirm the zone signing is fresh (RRSIG not expired).

12. Frequently asked questions

What is the difference between MTA-STS and DANE for SMTP?

Both protect SMTP transport against STARTTLS-stripping and downgrade attacks but use different trust anchors. MTA-STS (RFC 8461) trusts the public web PKI - the policy lives in an HTTPS-fetched file. DANE (RFC 7672) trusts DNSSEC - the policy lives in a TLSA record signed by DNSSEC. DANE requires DNSSEC; MTA-STS does not. The two coexist - a sender that supports both prefers DANE when a TLSA validates.

Which is better, MTA-STS or DANE for SMTP?

Neither replaces the other. DANE is technically stronger when DNSSEC is correctly deployed but requires DNSSEC on the recipient zone (roughly half of internet zones lack it). MTA-STS has lower deployment friction but introduces an HTTPS-fetched policy file. For maximum coverage publish both - DANE for the senders that support it, MTA-STS for the rest. RFC 7672 section 1.3 specifies the coexistence rules explicitly.

Does MTA-STS require DNSSEC?

No. MTA-STS uses DNS only for the discovery TXT record at _mta-sts.example.com plus the standard MX records. The policy itself comes over HTTPS from https://mta-sts.example.com/.well-known/mta-sts.txt - the web PKI plus HTTPS chain provides the cryptographic guarantee, not DNSSEC.

Does DANE for SMTP require DNSSEC?

Yes. DANE for SMTP requires DNSSEC end-to-end on the recipient zone. The sender MUST validate the DNSSEC chain on both the MX record AND the TLSA record. If either chain is bogus, the sender MUST NOT use the TLSA association. DANE without DNSSEC is meaningless - the records are silently ignored by validating senders.

How do MTA-STS and DANE interact if both are deployed?

RFC 7672 section 1.3: DANE takes precedence when a TLSA record is present and DNSSEC validates. If DNSSEC is bogus, the sender MUST NOT fall back to MTA-STS - bogus DNSSEC indicates an attack. If DNSSEC is insecure (unsigned), the sender falls back to MTA-STS policy lookup. If MTA-STS also fails, the sender falls back to opportunistic TLS.

Which large email providers support DANE for SMTP?

Sending side: Google Workspace, Microsoft 365 (since 2022), Comcast, Posteo, mailbox.org, ProtonMail, Hetzner. Receiving side - those publishing TLSA: Google (since 2024), Microsoft 365, ProtonMail, Posteo, mailbox.org, Comcast, GMX, web.de, and the US .gov sector under BOD 18-01. MTA-STS coverage is broader - Microsoft 365, Google, Yahoo, ProtonMail, Comcast, mailbox.org all publish MTA-STS.

What is the DANE TLSA record format for SMTP?

Published at _25._tcp.<mx-hostname>. Four fields: Usage (0 PKIX-TA, 1 PKIX-EE, 2 DANE-TA, 3 DANE-EE), Selector (0 full cert, 1 SubjectPublicKeyInfo), MatchingType (0 full match, 1 SHA-256, 2 SHA-512), Certificate Association Data hex. Canonical SMTP deployment is 3 1 1 (DANE-EE / SPKI / SHA-256) per RFC 7672 section 3.1.3.

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

Yes - this is the recommended pattern for maximum coverage. Publish DANE TLSA records at _25._tcp.<mx> signed by DNSSEC, AND publish an MTA-STS policy at https://mta-sts.example.com/.well-known/mta-sts.txt with matching mx: lines. Add TLS-RPT observability at _smtp._tls.example.com to see failures from either. Most providers that take SMTP transport security seriously publish both.

13. Related guides

• MTA-STS pillar deep-dive - the full MTA-STS reference: discovery TXT, HTTPS policy file format, policy modes (none / testing / enforce), worked examples, common mistakes, and the official RFC 8461 section walkthrough.
• DANE for SMTP (RFC 7672) pillar deep-dive - the symmetric counterpart to the MTA-STS pillar above. This comparison page sits BETWEEN the two pillars, documenting which protocol to deploy when; the DANE pillar is the same depth of operational reference the MTA-STS pillar provides but for the TLSA-record path that THIS page's trust-anchor row contrasts against the public-PKI / HTTPS-fetched-policy-file model. Where THIS page documents the choice (RFC 8461 vs RFC 7672 trust-anchor split, the per-provider support matrix, the RFC 7672 §1.3 coexistence rule, the decision matrix for which to deploy first, migration paths between the two), the DANE pillar walks through the deployment end-to-end: the _25._tcp.<mx-hostname> TLSA owner-name convention per RFC 7672 §3.1, the four TLSA-record fields (usage / selector / matching-type / certificate-association-data) with the canonical DANE-EE (usage=3) + SPKI-selector (selector=1) + SHA-256-matching (matching-type=1) deployment shape this comparison page's deployment-shape row recommends, the end-to-end DNSSEC chain-of-trust requirement (every ancestor zone from the root down to your TLSA-publishing zone MUST be DNSSEC-signed — a single unsigned ancestor makes the TLSA RRset bogus and senders fall back to opportunistic TLS, the failure mode this page's trust-anchor row flags as the operational cost of the DANE column), the RFC 7672 §2.2.1 receiver-side TLSA-retrieval-and-validation algorithm, the certificate / key rotation procedure (publish new TLSA alongside old, wait for max(zone-TTL, signature-validity) overlap, deploy new cert, retire old TLSA after a second overlap window), and the per-provider DANE deployment reference covering the German / Dutch / Scandinavian ISP-mailbox operators whose DANE adoption is matrixed on this comparison page. Read this once you have used the decision matrix on this page to settle on DANE (or to deploy BOTH per the coexistence row).
• TLS-RPT (SMTP TLS Reporting) - the observability standard (RFC 8460) that receives failure reports from MTA-STS-aware AND DANE-aware senders. Operational glue for BOTH standards.
• TLS-RPT report format (RFC 8460 §4 JSON schema) - the operational reference for diagnosing failures from either protocol once this decision matrix resolves to one of them. Where THIS comparison page documents which protocol to choose (the RFC 8461 vs RFC 7672 trust-anchor split, the per-provider support matrix, the coexistence rule), the report-format page documents the byte-level structure of the JSON reports that arrive at the rua= URI for BOTH protocols: the policies[].policy.policy-type enum that distinguishes sts-typed policy reports (from MTA-STS deployments) from tlsa-typed policy reports (from DANE deployments) from no-policy-found-typed reports (when neither protocol was discovered at the receiver), the policy-specific result-type values for each side (MTA-STS: sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-host-mismatch; DANE: tlsa-invalid, dnssec-invalid, dane-required, validation-failure), and the shared result-type values relevant to both (starttls-not-supported, certificate-not-trusted, certificate-expired). Read this once the decision matrix on this page has resolved and you have TLS-RPT deployed alongside the chosen enforcement protocol — this is the byte-level reference for parsing every ingested report-payload row regardless of which protocol produced it.
• TLS-RPT DNS record syntax (RFC 8460 §3) - the publishing-side byte-by-byte reference for the single _smtp._tls.<domain> TXT record an operator publishes to RECEIVE TLS-RPT failure reports for EITHER protocol this comparison page resolves to (or both, under the RFC 7672 §1.3 coexistence rule). Where the TLS-RPT explained entry above introduces the reporting channel and the report-format entry above documents the JSON payload structure, this record-syntax spoke completes the three-page TLS-RPT cluster by documenting the DNS record operators publish ONCE to cover BOTH MTA-STS and DANE deployments — the same TXT record advertises the rua= destination for receivers reporting on sts-typed, tlsa-typed, and no-policy-found-typed policy sessions. Covers the tag grammar (v=TLSRPTv1 floor case sensitive, rua=mailto: / rua=https: destination URIs, the !-separated multi-URI list, the optional size_limit= extension), the cross-domain authorisation contract for off-domain rua URIs (RFC 8460 §3.2 well-known-token authorisation), and the 255-octet TXT-string chunking rule for DNS providers. Read this once the decision matrix on THIS page has resolved (MTA-STS, DANE, or coexistence per RFC 7672 §1.3) — the TLS-RPT TXT record is the SAME single DNS publish regardless of which row of the decision matrix you land on; without it published, neither protocol deployment has an operational feedback channel and you are flying blind on sts-* / tlsa-* / dnssec-invalid / certificate-* failure types documented in the report-format spoke above.
• DNS propagation — the publisher-side TTL-bounded publish-and-verify cycle that gates every MTA-STS and DANE deployment change - the DNS-INFRASTRUCTURE-PUBLISHER-SIDE-PROPAGATION- LAYER companion to this comparison page's deployment-and-rotation procedures. Where THIS page documents the decision between RFC 8461 MTA-STS and RFC 7672 DANE (the public-PKI / HTTPS-fetched-policy- file trust-anchor model vs the DNSSEC-anchored TLSA trust-anchor model, the per-provider support matrix, the RFC 7672 §1.3 coexistence rule), the dns_propagation spoke documents the PUBLISHER-SIDE TTL-BOUNDED PUBLISH-AND-VERIFY CYCLE that gates EVERY DNS-published transport-security change between authoring intent and global sender-side enforcement realisation. Four structurally-distinct transport-security-propagation operational classes the spoke covers that THIS comparison page intentionally elides: (i) MTA-STS discovery TXT propagation window — when an operator publishes the _mta-sts.<domain> discovery TXT record per RFC 8461 §3.1, the record does NOT instantly become visible to every sender-side MTA worldwide; instead, the record propagates through the caching-resolver hierarchy at a rate gated by the TTL value (recommended 600s-3600s for the discovery TXT per RFC 8461 §10.2). The propagation-window race condition matters because sender-side MTAs cache the discovery TXT's id= token to detect policy changes — until the new id= token reaches the sender's resolver, the sender continues to honour the OLD HTTPS-fetched policy; (ii) DANE TLSA record propagation cascade — when an operator publishes (or rotates) a _25._tcp.<mx-target> TLSA record per RFC 7672 §3.1, the record's propagation is gated by BOTH the standard TTL-cached-resolver layer AND the DNSSEC signature-validity window (RFC 4034 §3.1.5 Inception / Expiration timestamps). The certificate-rotation procedure documented on the DANE pillar (publish-new-TLSA-alongside- old → wait max(zone-TTL, signature-validity) → deploy-new-cert → retire-old-TLSA after a second overlap window) is FUNDAMENTALLY gated by DNS-propagation timing; (iii) MTA-STS policy-mode-transition propagation tail — when an operator transitions a deployment from mode: testing to mode: enforce by republishing the policy file AND incrementing the discovery TXT's id= token, the propagation cycle determines when sender-side MTAs FETCH the new HTTPS policy file (some senders cache the policy file for hours after the discovery TXT's TTL expires); (iv) DNSSEC chain-of-trust propagation for DANE — DANE TLSA validity REQUIRES every ancestor zone from the root down to the TLSA-publishing zone be DNSSEC-signed; a single DNSSEC key-rollover anywhere in the chain produces a propagation-window during which sender-side validators may see dnssec-invalid TLS-RPT report rows for the affected TLSA-publishing domain. Required reading once an operator publishes a new MTA-STS discovery TXT or DANE TLSA record and reports "the change isn't taking effect across all senders" or "different senders see different policy verdicts for the same MX target".
• MX records explained - the foundational DNS-record reference for the addressing layer that BOTH MTA-STS and DANE operate at. MTA-STS lists the MX target hostnames in its policy file (RFC 8461 §3.2); DANE publishes TLSA records at _25._tcp.<mx-target> (RFC 7672 §3.1) - so both standards bind directly to the MX-target hostnames. The no-CNAME-as-MX-target rule (RFC 2181 §10.3) is the structural reason MX targets must resolve to A / AAAA records directly: DANE TLSA discovery follows the CNAME chain unless DNSSEC is broken, and MTA-STS validation expects the hostname listed in the policy to match the SNI on the TLS connection. Read this when modelling a new MTA-STS policy OR a new DANE TLSA record set: BOTH standards depend on the MX-publishing layer being correct first. Covers MX priority semantics, the multi-record + priority deployment pattern, per-provider canonical MX hostnames (Google Workspace, Microsoft 365, Yahoo, ProtonMail, Posteo, Comcast - the same providers whose MTA-STS / DANE support is matrixed on this comparison page), and TTL alignment with MTA-STS max_age / DANE TLSA TTL.
• 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.
• CAA records - the issuance-time CA authorisation standard. CAA controls which CAs can ISSUE certs for your domain; MTA-STS controls whether senders REQUIRE TLS to your MX. Complementary not competing.
• DMARC record tags explained - DMARC sits at the application layer; this page covers transport. Both are part of the complete email security stack.
• SPF explained - the IP authorisation layer.
• DKIM explained - the cryptographic message signing layer.
• BIMI - the visible-brand-logo standard.
• BIMI SVG Tiny PS logo requirements — the TRANSPORT-LAYER-HTTPS-POLICY-FILE- BYTE-GRAMMAR-AND-CONTENT-TYPE-SERVING- CONTRACT-AS-PARALLEL-PUBLISHER-SIDE- PUBLICATION-DISCIPLINE companion to this MTA-STS-vs-DANE decision-matrix reference. Where THIS page documents the transport- layer authentication-protocol choice between MTA-STS (HTTPS-PKI-anchored trust at publisher's mta-sts.<d> policy host serving a UTF-8 text policy file under a publisher-defined byte-grammar and a TLS-validated text/plain Content-Type contract) and DANE (DNSSEC-anchored trust at TLSA RRset for receiving MX host), the BIMI-SVG- requirements spoke documents the STRUCTURALLY-PARALLEL publisher-side publication discipline at the message- rendering layer: a UTF-8 SVG asset under the BIMI Working Group Tiny PS profile (RFC 9078 §5.1) served at the per-publisher l=-URL endpoint under a TLS-validated image/svg+xml Content-Type contract. Four publisher-side byte-grammar-and-HTTPS-serving parallel dimensions the cross-reference makes explicit: (i) MTA-STS policy-file UTF-8 line-grammar IS STRUCTURALLY- PARALLEL to BIMI SVG Tiny PS XML byte- grammar — MTA-STS publishers author a version: STSv1 + mode: testing|enforce|none + one-or-more mx: <hostname> + max_age: <seconds> text format at .well-known/mta-sts.txt; BIMI publishers author an SVG with baseProfile="tiny-ps" + <title>-first-child + square viewBox + forbidden-element exclusion (no <script>, no external references, no animation) + 32KB cap at the l=-URL endpoint. Both are publisher-defined UTF-8 text-format publication contracts receivers byte-parse before consuming; (ii) MTA-STS HTTPS-policy-host TLS-cert-validity discipline IS STRUCTURALLY-PARALLEL to BIMI SVG-URL HTTPS-asset-host TLS-cert-validity discipline — MTA-STS receivers retrieve the policy file ONLY over TLS, the cert MUST chain to a public-CA-trusted root, the connection MUST validate at every policy refresh; BIMI receivers retrieve the SVG asset ONLY over TLS, the cert MUST chain to a public-CA-trusted root, the connection MUST validate at every receiver-side asset fetch. Both are per-publisher HTTPS-served-content availability disciplines coupled to the publisher's TLS-cert-renewal cadence (Let's Encrypt 60-day, commercial-CA 12-month, AutoSSL automation as the common substrate); (iii) MTA-STS text/plain Content-Type serving contract IS STRUCTURALLY-PARALLEL to BIMI image/svg+xml Content-Type serving contract — the publisher's webserver MUST emit the correct MIME type at the policy-file endpoint (MTA-STS) and at the SVG asset endpoint (BIMI); a server-side MIME misconfiguration emitting application/octet-stream or text/html instead of the per-protocol expected Content-Type causes receiver-side parser rejection at the BIMI asset-fetch boundary in the exact SAME structural fashion as it causes receiver-side MTA-STS-policy parser rejection at the policy-fetch boundary — both protocols share the SAME publisher-side webserver-MIME-type coordination constraint; (iv) MTA- STS _mta-sts.<d> TXT-record-encoded version + policy-id publication IS STRUCTURALLY-PARALLEL to BIMI default._bimi.<d> TXT-record-encoded l= + a= tag pair — both protocols publish the receiver-side retrieval URL (MTA-STS policy host / BIMI SVG asset URL + VMC PEM URL) via a per-publisher per-domain DNS TXT record at a protocol-specific selector prefix (_mta-sts / _bimi); receivers consume the TXT-record-encoded retrieval URL, fetch the HTTPS-served-content asset, byte-parse the asset under the protocol's byte-grammar, and gate downstream protocol behaviour (transport-encryption for MTA-STS / brand-logo-rendering for BIMI) on successful byte-parse + TLS- validation + Content-Type-match. The receiver-side retrieval-and-validation pipeline is structurally identical at the architectural level. Read bimi_svg_requirements as the message- rendering-layer publisher-side publication- discipline reference that operates in STRUCTURAL PARALLEL to the transport- layer publisher-side publication-discipline choice (MTA-STS HTTPS-policy-host vs DANE TLSA-record) THIS page presents.
• BIMI Verified Mark Certificates (VMC and CMC) — the TRANSPORT-LAYER-CERTIFICATE-PKI- VS-DNSSEC-ANCHOR-DECISION-MATRIX-AS- PARALLEL-DECISION-PRIMITIVE-WITH- BIMI-VMC-PKI-VS-CMC-PKI-CHAIN-CHOICE companion to this MTA-STS-vs-DANE decision-matrix reference. Where THIS page documents the transport-layer authentication-protocol choice between MTA-STS (HTTPS-PKI-anchored trust at publisher's mta-sts.<domain> policy host) and DANE (DNSSEC-anchored trust at TLSA RRset for receiving MX host), the BIMI-VMC/CMC spoke documents the STRUCTURALLY-PARALLEL cryptographic-attestation decision- matrix at the message-rendering layer between VMC (Verified Mark Certificate — CA/Browser-Forum-attested trademark- binding for registered trademarks) and CMC (Common Mark Certificate — government- registered-common-law-mark attestation for unregistered marks). Concretely, the spoke documents FOUR parallel-PKI-vs-DNSSEC-decision-axis dimensions: (i) per-attestation- protocol cryptographic-trust-anchor choice parallel — MTA-STS uses CA-anchored HTTPS-PKI rooted in the receiver-side browser-trust-store certificate set (the same trust-anchor topology web-PKI uses), and DANE uses DNSSEC-anchored trust at the publisher's authoritative zone (a STRUCTURALLY DISTINCT trust topology the decision-matrix THIS page compares side-by-side); the BIMI VMC chain uses BIMI-Working-Group-approved-CA- anchored PKI rooted in the BIMI-WG- published CA allow-list (DigiCert / Entrust) — a STRUCTURALLY PARALLEL decision the publisher makes ALONGSIDE the transport-layer protocol choice THIS page covers, with both decision- matrices producing structurally- similar CA-vs-DNSSEC-anchor tradeoffs; (ii) per-attestation-protocol certificate-issuance vetting-stringency parallel — MTA-STS HTTPS certificate issuance follows CA/Browser-Forum Server BR §3.2.2 domain-validation procedures (DV baseline plus optional OV / EV extension), while DANE certificate material can be self-signed PRECISELY because DNSSEC anchoring removes the CA-trust-vetting requirement (the trust-anchor-removal tradeoff THIS page documents at the operator- complexity vs trust-anchor-strength decision boundary); the BIMI VMC certificate issuance follows BIMI-WG-BR §3.2.2.8 trademark- verification-discipline-PLUS-domain- validation procedures (a STRUCTURALLY STRONGER vetting requirement than either DV or EV web-PKI) while the BIMI CMC alternative uses a government-registered-common-law- mark attestation primitive — a STRUCTURALLY PARALLEL per-attestation- protocol-vetting-stringency decision the publisher coordinates ALONGSIDE the transport-layer protocol choice; (iii) per-attestation-protocol revocation-and-rotation cadence parallel — MTA-STS HTTPS certificate revocation uses CRL / OCSP / OCSP-stapling primitives (the receiver-side certificate- revocation-validation discipline THIS page documents at the HTTPS-PKI operational-overhead axis), while DANE certificate rotation uses publisher-controlled TLSA RRset rotation with double-publish overlap windows (the publisher-side operational-overhead axis THIS page covers); the BIMI VMC certificate lifecycle uses CA-issuance-cadence- bound 13-month BIMI BR validity period with annual trademark-re- verification + certificate-re- issuance — a STRUCTURALLY DIFFERENT revocation-and-rotation cadence the publisher coordinates ALONGSIDE the transport-layer protocol's certificate lifecycle the THIS page documents; and (iv) per- attestation-protocol publisher-and- receiver-side operational-overhead parallel — the MTA-STS-vs- DANE decision-matrix THIS page documents at the publisher-side operational-complexity vs trust- anchor-strength decision boundary DIRECTLY INFORMS the BIMI-VMC-vs-CMC decision the publisher makes ALONGSIDE the transport-layer protocol choice — both decisions follow the same cryptographic-attestation-protocol- choice template (CA-anchored vs DNSSEC- anchored at the transport-layer; CA-anchored trademark-vetting vs government-registered-common-law-mark attestation at the message-rendering layer) with shared operational- complexity-vs-trust-anchor-strength tradeoff axes. Read the BIMI-VMC/CMC spoke alongside THIS MTA-STS-vs-DANE decision matrix when the publisher is COORDINATING the cryptographic- attestation-protocol-choice template across both the transport-layer (MTA-STS-HTTPS-PKI-vs-DANE-DNSSEC- anchor choice THIS page covers) AND the message-rendering layer (BIMI-VMC- CA-PKI-vs-BIMI-CMC-common-law-mark- attestation choice the spoke covers) — the two decisions follow the same template at structurally-distinct layers of the email-deliverability stack the publisher operates.
• Phishing protection (defense-in-depth catalogue) — the TRANSPORT-LAYER-AUTHENTICATION- PROTOCOL-CHOICE-VS-PHISHING-VIA- DOWNGRADE-MITM-AND-CLEARTEXT- INTERCEPTION-DEFENSE companion to this MTA-STS-vs-DANE decision-matrix reference. Where THIS page documents the structural axes along which the two transport-layer authentication protocols differ (DNSSEC dependency, certificate trust model, deployment complexity, key-rotation cadence, receiver-vs-sender enforcement-tier progression, RFC 8461 policy-file vs RFC 7672 TLSA-record-pinning), the phishing-protection spoke documents the LAYERED DEFENSE-IN- DEPTH CONTROL CATALOGUE in which the MTA-STS-or-DANE transport-layer STARTTLS-authentication enforcement is a LOAD-BEARING control whose absence creates structural phishing- attack vectors. FIVE structurally- distinct TRANSPORT-LAYER-PROTOCOL- VS-PHISHING-CONTROL operational classes the spoke catalogues that THIS decision-matrix reference intentionally elides: (i) active-attacker STARTTLS- downgrade-MITM as phishing-payload- injection vector — an on- path attacker can strip the STARTTLS upgrade response from the receiving MX's SMTP banner, forcing the sending MTA to fall back to cleartext SMTP; the attacker can then modify the in-flight message body to substitute attacker-controlled URLs / attach malicious payloads / inject phishing content; both MTA-STS mode:enforce AND DANE TLSA-pinning structurally prevent this attack class because the sending MTA refuses to deliver via a non- TLS-authenticated channel; (ii) cleartext-interception phishing-credential-harvest at intermediate hops — an attacker with passive observation of in-flight email traffic can harvest every message's payload for offline analysis if any hop falls back to cleartext, then craft targeted phishing campaigns against the captured recipient list using the captured legitimate-sender writing style and corporate-branding evidence; the MTA-STS/DANE transport-layer authentication enforcement structurally eliminates this attacker-research substrate; (iii) cousin-MX hostname-substitution phishing — an attacker who controls a malicious MTA matching the receiver's hostname glob (e.g. an attacker-registered cousin-MX that looks like a legitimate receiver MX) can attract phishing- payload-laden mail if the sending MTA does not verify MX hostnames against an MTA-STS policy-file mx:-allow-list or a DANE TLSA-pinning record; (iv) certificate-mis-issuance- based phishing-receiver impersonation — the MTA-STS-vs-DANE trust-model choice this page contrasts (Web-PKI- CA-issued certificates for MTA-STS vs DNSSEC-anchored TLSA pins for DANE) determines whether a mis-issuance attack against the receiving organisation's CA enables phishing- receiver impersonation; DANE-deploying organisations gain structural defense against CA-mis-issuance via DNSSEC- anchored TLSA pin verification at every connection attempt; (v) per-incident TLS-RPT-aggregate- report-based phishing-defense observability feedback loop — the TLS-RPT receiver-side feedback channel both protocols publish-into produces the per-receiver-per-day STARTTLS-failure / DANE-verification- failure / MTA-STS-policy-fetch-failure anomaly time-series the security team consults when a phishing-via- downgrade-MITM campaign produces a sudden spike in cleartext-fallback reports. Read the phishing-protection spoke alongside this decision-matrix reference when constructing the security-team's transport-layer phishing-defense threat-model — the spoke maps each MTA-STS/DANE protocol choice onto the concrete phishing- TTP class (T1557 adversary-in-the- middle, T1040 network-sniffing- cleartext-traffic, T1583.001 acquire- infrastructure cousin-MX-registration) the transport-layer authentication control defends against.
• How attackers bypass weak DMARC — the TRANSPORT-LAYER-DOWNGRADE- RESISTANCE-COMPARISON-AT-MTA-STS- VS-DANE-IS-PER-PROTOCOL-ATTACKER- BYPASS-VECTOR-ANALYSIS companion to this MTA-STS-vs-DANE decision-matrix reference. Where THIS page documents the STRUCTURAL AXES along which the two transport-layer authentication protocols differ (DNSSEC dependency, certificate trust model, deployment complexity, key-rotation cadence, receiver-vs-sender enforcement-tier progression, RFC 8461 policy-file vs RFC 7672 TLSA-record-pinning), the attacker-bypass spoke documents the PER-PROTOCOL ATTACKER-BYPASS- VECTOR taxonomy whose exploitation feasibility the publisher's protocol- choice decision DIRECTLY determines. FOUR structurally-distinct PER- PROTOCOL ATTACKER-BYPASS-VECTOR dimensions emerge from the side-by- side comparison: (1) MTA-STS-DNS-record-MITM-attacker- bypass via DNS-cache-poisoning against the _mta-sts.<domain> TXT record — the bypass- spoke documents how an attacker with the ability to poison the sender-MTA's resolver cache (Kaminsky- class off-path injection, on-path attacker between sender-MTA and upstream resolver, BGP-route hijack targeting the publisher's NS) can REMOVE the publisher's MTA-STS DNS-policy-indicator from the sender-MTA's view during the attacker's chosen interception window. Where MTA-STS depends on the sender-MTA observing the publisher's _mta-sts.<domain> TXT record, the absence of DNSSEC anchoring per RFC 8461 design leaves this attacker-bypass-vector viable. DANE-anchored-via-DNSSEC forces the attacker to compromise the DNSSEC trust-chain (substantially higher effort), shifting the bypass- vector ceiling. THIS page's DNSSEC-dependency comparison axis is the publisher-side choice the bypass-spoke proves determines this attacker-bypass class's feasibility. (2) MTA-STS-HTTPS-policy- host-substitution-attacker-bypass via cert-CA-misissuance or HTTPS- path-substitution against the mta-sts.<domain>/.well-known/mta-sts.txt endpoint — the bypass- spoke documents how an attacker who can obtain a fraudulently-issued WebPKI certificate for mta-sts.<domain> (CA-misissuance class, validation- bypass attacks against CAs without CAA-record-enforcement discipline, attacker-controlled-DNS during cert-issuance window) can serve a FORGED MTA-STS policy file with mode: none to the sender-MTA, downgrading the publisher's published mode: enforce to opportunistic STARTTLS at the attacker's choosing. DANE-TLSA- pinning does NOT depend on a WebPKI CA — the publisher's TLSA record directly pins the SubjectPublicKeyInfo or full-cert hash — closing this attacker-bypass class. THIS page's certificate-trust-model comparison axis is the publisher-side choice the bypass-spoke proves determines this attacker-bypass class's feasibility. (3) DANE- TLSA-record-DNSSEC-chain-compromise- attacker-bypass via NSEC-walking- plus-zone-substitution against the publisher's authoritative DNSSEC delegation — the bypass- spoke documents how an attacker who can compromise the publisher's authoritative-DNS DNSSEC zone- signing-key (e.g. by registrar- level account compromise allowing DS-record replacement at the parent zone, by KSK/ZSK key-material exfiltration from the publisher's DNS provider, by NSEC-walking + zone-substitution at compromised secondary nameservers) can replace the publisher's TLSA-record with an attacker-chosen hash pinning a MITM proxy's cert/key. MTA-STS does NOT depend on DNSSEC — its trust comes from the WebPKI cert on the policy-file endpoint — making this DNSSEC-chain-compromise attacker-bypass-vector inapplicable to MTA-STS deployments. THIS page's DNSSEC-anchored-trust-vs- WebPKI-trust comparison axis is the publisher-side choice the bypass-spoke proves determines this attacker-bypass class's applicability. (4) Per- protocol enforcement-tier-vs- attacker-during-deployment-window bypass at the MTA-STS-mode-testing- and-DANE-bootstrap-period boundary — the bypass-spoke documents how the MTA-STS mode: testing deployment phase (publisher-side observation period where TLS-RPT reports surface failures but sender-MTAs continue opportunistic STARTTLS) is a STRUCTURAL attacker-bypass window — an attacker who intercepts a message during mode: testing downgrades the connection without triggering any sender-MTA enforcement reaction. DANE has no equivalent observation-only mode — TLSA records are enforcement-immediate at publication. THIS page's receiver-vs-sender enforcement- tier-progression comparison axis is the publisher-side choice the bypass-spoke proves determines this deployment-window attacker- bypass class's duration. Read the attacker-bypass spoke alongside THIS page when sizing the MTA-STS-vs-DANE protocol choice against THREAT EXPECTATIONS: this page tells you HOW the two protocols compare at the operational and structural axes, the bypass-spoke tells you WHAT THE ATTACKER DOES at each protocol's failure boundary AND WHY the publisher's protocol- choice directly determines the per-protocol attacker-bypass- vector floor.
• DMARC for Google Workspace - per-provider deployment guide for one of the major DANE + MTA-STS adopters.
• DMARC for Microsoft 365 - per-provider deployment guide for the provider that added DANE outbound in 2022.
• DMARC for Office 365 hybrid (Exchange Server + Exchange Online coexistence) - the HYBRID-EXCHANGE-ON-PREM-VS-EXO-DUAL-INBOUND-MX-SURFACE-MTA-STS-VS-DANE-DECISION-AT-PER-RECEIVER-CONTROL-PLANE-AT-FOUR-CROSS-SURFACE-TRANSPORT-LAYER-CONFIGURATION-COORDINATION-DIMENSIONS companion to this MTA-STS-vs-DANE comparison page. A hybrid Exchange tenant is the canonical case where the MTA-STS-vs-DANE decision matrix BIFURCATES across two simultaneous inbound-MX surfaces under a single author-domain: documents FOUR cross- surface transport-layer-coordination dimensions (on-prem Exchange Server MX record vs EXO *.mail.protection.outlook.com MX record dual-inbound-surface DANE-vs- MTA-STS decision asymmetry — on-prem operator publishes BOTH a DNSSEC-signed zone AND a TLSA record at the _25._tcp.on-prem-mx.example.com owner-name making DANE feasible on the on-prem surface, while EXO carries no TLSA on *.mail.protection.outlook.com forcing MTA-STS on the EXO surface; per-surface operator-control-plane bifurcation — on-prem Exchange operator controls the inbound MX DNS zone and the TLSA publication, while EXO is provider- controlled and the operator can publish an MTA-STS policy at the SAME author- domain's _mta-sts.example.com owner-name pointing to the EXO MX wildcard but CANNOT inject TLSA at the provider-controlled MX target; cross-surface TLS-RPT feedback signal at the _smtp._tls.example.com TXT record collects per-inbound-MX success/failure counts that the operator MUST disambiguate by target MX to attribute TLS handshake errors to the on-prem-DANE surface vs the EXO-MTA-STS surface; hybrid migration TLS-policy coordination at the on-prem-mailbox-to- EXO-mailbox move boundary — when a mailbox migrates the MX record may remain dual-targeted but the TLS-policy authority shifts from on-prem-DANE to EXO-MTA-STS, and the cutover window REQUIRES both policies to be published simultaneously to avoid a TLS-enforcement gap during the migration. This page's decision matrix RESOLVES per-surface for a hybrid tenant: on-prem surface → DANE (operator-controlled, DNSSEC-anchored TLSA publication is feasible), EXO surface → MTA-STS (provider-controlled, no TLSA option). Spoke documents the hybrid coexistence-mode mailflow, connector configuration, per-surface DKIM-signing path, and the per-surface DMARC alignment audit prerequisite to Phase-3 p=reject ramp.
• MTA-STS for Microsoft 365 - the provider-specific MTA-STS deployment guide. Read this once the decision matrix on this page resolves to MTA-STS for an M365 tenant: Microsoft 365 added DANE OUTBOUND in 2022 but does NOT publish TLSA records for INBOUND (the *.mail.protection.outlook.com MX targets carry no TLSA), so senders that need TLS enforcement to an M365 inbox MUST rely on MTA-STS — DANE is not an alternative on the inbound side for this provider. Covers the canonical mx: wildcard, where to host the policy file when the tenant doesn't have a public web property, and the testing-mode burn-in workflow paired with TLS-RPT.
• MTA-STS for Google Workspace - the provider-specific MTA-STS deployment guide for Workspace tenants. Read this once the decision matrix on this page resolves to MTA-STS for a Workspace domain: Google does NOT publish TLSA records for inbound on aspmx.l.google.com nor on the four secondary backup MXes (alt1..alt4.aspmx.l.google.com), so senders that need TLS enforcement to a Workspace inbox MUST rely on MTA-STS — DANE is not an inbound alternative for this provider either. Covers the single-MX mx: aspmx.l.google.com policy-file shape (contrast with M365's FQDN-wildcard pattern), the four secondary backup MXes Workspace permits, where to host the policy file for a Workspace tenant without a public web property, and the testing-to-enforce burn-in workflow paired with TLS-RPT.
• MTA-STS policy file syntax (RFC 8461 §3.2) - the byte-by-byte syntax reference for the /.well-known/mta-sts.txt policy file operators reach for once the decision matrix on this page resolves to MTA-STS. Where this page tells you WHICH standard to deploy and WHY MTA-STS is the right call for a given provider posture, the policy-syntax page documents what the policy file itself must contain to be accepted: the four canonical keys (version: STSv1, mode as case-sensitive enforce/testing/none enum, mx: entries with single-label wildcard semantics that match mail.example.com but NOT sub.mail.example.com, max_age: in seconds with RFC 8461 ceiling), the no-BOM constraint (UTF-8 BOM silently breaks the version line match — the #1 silent-rejection cause), the no-comments rule (any #-prefixed line causes rejection — structurally different from DNS records and most configuration formats), the text/plain Content-Type and CRLF/LF line-ending tolerance, the _mta-sts DNS id-token coupling with the policy-file id: rotation contract, six canonical example policies, and the ten common mistakes that produce TLS-RPT sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid failure reports. The DANE alternative has no comparable byte-syntax reference because TLSA records are binary DNS payloads with zone-file rendering handled by the nameserver — for any MTA-STS deployment this page is the operational follow-up to the decision view above.
• Reverse DNS and PTR records explained - the DANE-TLSA-AS-DNSSEC-ANCHORED-MX- CERTIFICATE-VS-PTR-AS-FCRDNS-FORWARD- CONFIRMED-REVERSE-DNS-RECEIVER-SIDE- CONNECTION-FILTERING-GATE companion to this MTA-STS-vs-DANE decision-matrix reference. Where THIS page documents the TRANSPORT-LAYER AUTHENTICATION CHOICE between MTA-STS (HTTPS-PKI-anchored policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt + _mta-sts.<domain> TXT-record id-token coupling) and DANE (DNSSEC-anchored TLSA-RR pinned at _25._tcp.<mx-host>), the reverse-DNS / PTR spoke is the DNS-FOUNDATION-LAYER reverse-resolution primitive every MTA-STS-deploying or DANE-deploying operator inherits at the SMTP-connection-establishment phase BEFORE either protocol's policy-fetch / TLSA-validation runs. The four-axis TRANSPORT-LAYER-CHOICE-VS-PTR-FCRDNS- RECEIVER-SIDE-CONNECTION-FILTERING comparison exposes the structurally- distinct DNS-foundation coordination roles: (i) per-receiver MTA-STS policy-host HTTPS fetch (the mta-sts.<domain> HTTPS-anchored well-known fetch) and per-receiver DANE TLSA-RR DNSSEC- validated lookup both occur at the SENDER-SIDE of the SMTP connection — but the RECEIVER-SIDE iprev=pass / FCrDNS gate every major MTA enforces against the connecting sender's IP runs at the CONNECTION-ESTABLISHMENT phase BEFORE either MTA-STS or DANE policy evaluation matters — the reverse-DNS / PTR spoke documents the receiver-side iprev=-verdict-as-FCrDNS- diagnostic that every deploying operator must verify is publishing iprev=pass for its sending IP pool BEFORE either transport-layer authentication protocol THIS page compares can operationally rescue a deliverability outcome; (ii) DANE TLSA-RR DNSSEC chain-of-trust requires the _25._tcp.<mx-host> TLSA-RR resolution to succeed via the DNSSEC-anchored validating resolver path — but the mailbox-provider / mailbox-receiver also runs a forward-confirmed-reverse-DNS (FCrDNS) check that requires the MX host's IP-side PTR record to publish a hostname that forward-resolves back to the MX-host IP — making the per-MX-host PTR publication a PARALLEL DNS-foundation prerequisite to the DANE TLSA-RR DNSSEC chain-of- trust this page documents as the DANE-side trust-anchor mechanism — the reverse-DNS / PTR spoke documents the per-MX-host PTR-RR publication-and-FCrDNS-verification operational discipline every DANE- deploying receiver MUST coordinate alongside the DNSSEC-anchored TLSA-RR publication this page's decision view documents; (iii) MTA-STS policy-file mx: entries (single-label wildcard mx: *.example.com or explicit mx: mail.example.com) bind to receiver-side MX-hostnames whose underlying IP addresses MUST publish forward-confirmed PTR records — without per-MX-host PTR publication, the receiver-side connection-filtering layer can reject the connecting SMTP client BEFORE the per-message MTA-STS-enforced TLS-required handshake completes, producing a TLS-RPT tls-error / certificate-host-mismatch failure-report class whose root cause is PTR misconfiguration UPSTREAM of MTA-STS enforcement — the reverse-DNS / PTR spoke documents the MTA-STS-policy-host- and-MX-hostname-vs-per-MX-host-PTR coordination chain every MTA-STS- deploying operator must audit BEFORE flipping the policy file's mode: enforce transition this page's decision view recommends; and (iv) RFC 7208 §5.5 deprecation of the SPF ptr-mechanism removed per-message reverse-DNS-based envelope-sender authentication from the SMTP transmission path — but the receiver-side connection-filtering layer's FCrDNS verification (independent of the deprecated SPF ptr mechanism) REMAINS load-bearing for the receiver-side connection-acceptance decision the operator's MTA-STS / DANE choice CANNOT rescue once FCrDNS fails — making PTR publication a SEPARATE DNS-foundation-layer prerequisite whose deployment must precede either MTA-STS / DANE protocol rollout this page recommends — the reverse-DNS / PTR spoke documents the SPF-ptr- deprecation-rationale-vs-FCrDNS- persistence distinction every deploying operator must internalise BEFORE concluding that transport- layer authentication (MTA-STS / DANE) is sufficient to protect a sending or receiving SMTP path without a baseline FCrDNS-pass floor. Read the reverse-DNS / PTR spoke BEFORE selecting MTA-STS or DANE on the decision view this page presents (audit the per-MX-host PTR / FCrDNS publication BEFORE either MTA-STS policy-file publication or DANE TLSA-RR DNSSEC-anchoring), and WHENEVER diagnosing a TLS-RPT failure-report whose root cause may be FCrDNS-misconfiguration UPSTREAM of the transport-layer authentication protocol THIS page's decision view compares.
• Email deliverability — the TRANSPORT-LAYER-TECHNOLOGY-CHOICE- AS-PER-RECEIVER-ENCRYPTION-RATE-FLOOR- INPUT-INTO-PER-PUBLISHER-PER-DOMAIN- DELIVERABILITY-VERDICT companion to this MTA-STS-vs-DANE decision reference. Where THIS page documents the head-to-head DNSSEC-anchored DANE (RFC 7672 + RFC 6698 TLSA-RR + per-MX-host TLSA-RR publication) vs HTTPS-PKI-anchored MTA-STS (RFC 8461 + per-domain mta-sts.txt policy-file publication + _mta-sts TXT-RR publication) transport-layer technology- choice decision tree, the email- deliverability spoke is the per-publisher per-domain BUSINESS-OUTCOME reference documenting the 14-section OUTCOME-LAYER deliverability framework whose transport-layer-encryption-rate floor IS the downstream-consumer of the MTA- STS-vs-DANE choice THIS page's decision view resolves at four MTA-STS-vs-DANE- choice-to-deliverability coupling dimensions: (i) per-receiver per-MX-host STARTTLS-handshake-success- rate floor as per-publisher per-domain TLS-encryption-rate input feeding receiver-side reputation-model verdicts — per-receiver STARTTLS opportunistic-vs-required-handshake success-rate at every recipient-MX-host IS the load-bearing per-publisher per- domain TLS-encryption-rate input the email-deliverability framework's Section 9 (transport-layer-encryption-rate floor) and major-receiver reputation-model verdict (Gmail / Outlook / Yahoo / Apple) consume; whether the per-publisher per- domain operator picks MTA-STS, DANE, or both determines the per-receiver per- MX-host encryption-rate-coverage matrix that drives the per-publisher per-domain deliverability verdict; (ii) per- receiver-counterparty-coverage-matrix differential as load-bearing per- publisher per-domain deliverability- ceiling determinant — per- receiver-side MTA-STS-policy-fetch- support-rate (Gmail / Outlook / Yahoo) vs per-receiver-side DANE-TLSA-RR-fetch- support-rate (T-Online / GMX / Comcast) produces DIFFERENT per-publisher per- domain encryption-rate-coverage matrices; the per-publisher per-domain deliverability-ceiling THIS page's decision view advises picking the better-coverage technology for IS the load-bearing input into the email- deliverability framework's Section 9 (encryption-rate floor) per-receiver- counterparty-coverage-matrix composition; (iii) Bulk Sender Requirements 2024 100-percent- encryption-rate floor as load-bearing per-publisher per-domain deliverability- compliance gate — the Gmail/ Yahoo Feb 2024 Bulk Sender Requirements threshold mandates 100-percent encryption- rate on per-publisher outbound mail; the per-publisher per-domain MTA-STS-vs-DANE publication-discipline-choice THIS page resolves IS the load-bearing input into the email-deliverability framework's Section 13 (Bulk Sender Requirements deliverability floor) — whichever technology (or both) maximises the per- recipient-MX-host encryption-rate-coverage matrix toward the 100-percent floor is the per-publisher per-domain Bulk-Sender- Requirements-compliant deliverability- ceiling; (iv) per-publisher per-domain MTA-STS-and-DANE-both composition as load-bearing per-receiver- counterparty-coverage-matrix-completeness deliverability-uplift trajectory — per-publisher per-domain operators deploying BOTH MTA-STS (covering Gmail / Outlook / Yahoo encryption-rate floor) AND DANE (covering T-Online / GMX / Comcast encryption-rate floor) achieve the load-bearing per-receiver- counterparty-coverage-matrix completeness that maximises the per-publisher per- domain encryption-rate-coverage delta across the full recipient-MX-host per-receiver counterparty matrix — the cross-receiver complete-encryption- rate-coverage composition the email- deliverability framework's Section 9 and Section 13 cross-reference IS the load-bearing per-publisher per-domain deliverability-uplift trajectory THIS page's both-technologies-combined decision- view advises in the right counterparty coverage scenarios. Read the email- deliverability spoke ALONGSIDE this MTA-STS-vs-DANE decision reference whenever the per-publisher per-domain per-recipient-MX-host transport-layer- technology-choice question emerges with a deliverability-outcome attribution dimension — THIS page gives the per- recipient-MX-host technology-choice decision tree, the email-deliverability spoke gives the per-publisher per-domain inbox-placement BUSINESS-OUTCOME framework that transport-layer-encryption- rate composition ultimately feeds at the receiver-side reputation-model verdict boundary.
• Email spoofing (the seven canonical techniques) — where THIS page documents the transport-layer-encryption-policy technology-choice decision-tree (MTA-STS RFC 8461 web-PKI-anchored policy file + per-publisher TXT- version pointer + per-MX-host allow-list VERSUS DANE RFC 7672 DNSSEC-anchored TLSA-RR publication per-MX-host), the email-spoofing spoke documents the seven canonical spoofing techniques whose TRANSPORT-LAYER attack-variant subset the publisher's MTA-STS-or-DANE publication-discipline THIS page documents is the LOAD-BEARING defense against. FOUR structurally- distinct CROSS-OSI-LAYER SPOOFING- DEFENSE coupling dimensions the email-spoofing spoke operationally documents: (i) MX-record substitution during DNS resolution as load-bearing transport-layer attack variant THIS page's MTA-STS per-publisher per-MX-host allow-list defends against — attacker poisons recursive- resolver MX-RR resolution to redirect mail-flow to attacker- controlled MX-host; MTA-STS per-publisher policy file's explicit mx: per-MX-host allow-list materially defeats this attack class even when the recursive resolver returns a poisoned MX-RR set; (ii) TLS-stripping STARTTLS downgrade as load-bearing transport-layer attack variant THIS page's MTA-STS mode: enforce policy + DANE TLSA-RR per-MX-host publication BOTH defend against — attacker MITMs the SMTP STARTTLS negotiation to downgrade to plaintext-SMTP; both MTA-STS enforce-mode + DANE TLSA publication enforce that senders REQUIRE TLS at the per-publisher per-MX-host scope and REFUSE plaintext fallback; (iii) lookalike-MX-host substitution as load-bearing transport-layer attack variant the per-publisher per-MX-host allow-list + DANE TLSA per-MX- host certificate-binding defend against — attacker publishes a confusable-MX-host (e.g., mail1.example.com vs mai1.example.com ) in a compromised zone; the per-publisher per-MX-host publication-discipline at the MTA-STS policy file or DANE TLSA-RR scope materially binds the sender's TLS-handshake to the EXACT per-publisher per-MX- host the publisher controls; (iv) application-layer- spoofing-techniques (RFC 5322 From: forgery + display-name + IDN-homograph + cousin-domain + subdomain-takeover) as load- bearing exemplars of the ORTHOGONAL OSI-LAYER attack surfaces THIS page's transport- layer technology-choice DOES NOT defend against — these FIVE techniques require application-layer SPF / DKIM / DMARC + registrar-layer defensive registration of confusables AS THE STRUCTURALLY-DISTINCT defense layer complementing this page's transport-layer choice — the email-spoofing spoke's seven-technique catalogue provides the cross-OSI-layer attack-surface taxonomy that SCOPES which spoofing variants THIS page's transport-layer publication-discipline defends against and which require the complementary application-layer SPF / DKIM / DMARC defense stack. Read the email-spoofing spoke ALONGSIDE this MTA-STS-vs- DANE technology-choice decision-tree whenever the publisher scopes a per-publisher per-domain cross-OSI-layer anti-spoofing defense framework — the seven canonical spoofing techniques the email-spoofing spoke catalogues materially define the cross-OSI-layer attack-surface taxonomy this transport-layer technology- choice decision-tree defends the per-publisher in-transit subset of.
• SPF for Microsoft 365 — the PER-PUBLISHER-PER-MICROSOFT- 365-TENANT-SPF-PUBLICATION-DISCIPLINE-AS- LOAD-BEARING-PEER-PROTOCOL-LAYER-PER- TENANT-PER-OPERATOR-APPLICATION-LAYER- AUTHENTICATION-PUBLICATION-DISCIPLINE companion to this MTA-STS-vs-DANE publication-discipline choice reference. Where THIS page documents the per- publisher per-domain transport-layer MTA-STS-vs-DANE publication-discipline choice (Web-PKI-anchored MTA-STS two-leaf publication via _mta-sts.<domain> TXT- RR pointer + HTTPS-served .well-known/mta-sts.txt policy-file vs DNSSEC-anchored DANE TLSA- RR single-leaf publication via _25._tcp.<mx-host>), the SPF-for-Microsoft-365 spoke is the peer per-publisher per-tenant per- Microsoft-365-operator application-layer SPF publication discipline whose per- M365-tenant SPF publication discipline (canonical v=spf1 include:spf.protection.outlook.com -all SPF-record template, per-tenant supplemental third-party-ESP include- statement composition, per-tenant cumulative 10-lookup-limit budget arithmetic, per-tenant M365 admin-portal zone-editor commit cadence) pairs operationally with the per-publisher per- domain transport-layer MTA-STS-vs-DANE publication-discipline choice THIS page documents at FOUR per-protocol-pillar publication-discipline coupling dimensions: (i) peer per-publisher per-domain application-layer-vs-transport- layer publication-discipline parallelism — the per- publisher per-domain transport-layer MTA-STS-vs-DANE publication-discipline choice THIS page documents at the per- receiver per-session per-MX-hop transport- encryption peer-authentication layer pairs operationally with the per-publisher per- M365-tenant application-layer SPF publication discipline the SPF-for- Microsoft-365 spoke documents at the per- message envelope-MAIL-FROM authentication- evaluation layer — together the per- publisher per-domain application-layer-vs- transport-layer publication-discipline composition is the load-bearing per- publisher per-domain complete cross- layer authentication-and-encryption publication-posture every per-publisher per-domain DMARC-deployment programme requires; (ii) per-publisher per- M365-tenant per-operator transport-layer- and-application-layer publication- discipline composition parallelism — the per-publisher per-domain transport-layer MTA-STS-vs-DANE publication-discipline choice THIS page documents at the per-receiver per-session per-MX hop transport-encryption peer- authentication layer pairs operationally with the per-publisher per-M365-tenant application-layer SPF publication discipline the SPF-for-Microsoft-365 spoke documents the per-tenant per- operator publication-rationale of (per- M365-tenant canonical include:spf.protection.outlook.com application-layer SPF-publication primitive + per-publisher per-M365-tenant per-domain MX-RR-set *.mail.protection.outlook.com receiver-side transport-layer MX-hop primitive) — together the per-publisher per-M365-tenant per-operator transport- layer-and-application-layer publication- discipline composition is the load- bearing per-publisher per-tenant per- operator complete cross-protocol-pillar publication-discipline-composition rhythm; (iii) per-publisher per-M365- tenant per-operator cross-protocol-pillar cumulative-publication-discipline- complexity coordination — the per-publisher per-domain transport- layer MTA-STS-vs-DANE publication- discipline choice THIS page documents at the per-publisher per-domain transport- layer-publication-discipline-complexity boundary (Web-PKI-anchored MTA-STS two- leaf publication operational-complexity vs DNSSEC-anchored DANE single-leaf publication DNSSEC-operational-complexity) pairs operationally with the per- publisher per-M365-tenant per-operator SPF-publication-discipline-complexity the SPF-for-Microsoft-365 spoke documents (per-tenant cumulative include:spf.protection.outlook.com+supplemental-ESP-include 10-lookup-limit budget arithmetic, per- tenant supplemental-include-statement composition discipline) — the per- publisher per-tenant per-operator cross- protocol-pillar cumulative-publication- discipline-complexity coordination is the load-bearing per-publisher per-tenant per- operator publication-discipline-complexity management rhythm every per-publisher per- tenant per-operator DMARC-deployment programme requires; (iv) per- publisher per-M365-tenant per-operator cross-protocol-pillar publication- discipline-coordination as load-bearing per-tenant per-operator complete authentication-and-encryption posture rhythm — the per-publisher per-domain transport-layer MTA-STS-vs- DANE publication-discipline choice THIS page documents at the per-receiver per- session per-MX hop transport-encryption peer-authentication layer pairs operationally with the per-publisher per- M365-tenant application-layer SPF publication discipline the SPF-for- Microsoft-365 spoke documents the per- tenant per-operator publication-rationale of, and the per-publisher per-M365-tenant per-operator cross-protocol-pillar publication-discipline-coordination (application-layer SPF publication coordinated with transport-layer MTA-STS- or-DANE publication discipline) is the load-bearing per-publisher per-tenant per-operator complete authentication-and- encryption publication-posture rhythm every per-publisher per-tenant per- operator DMARC-deployment programme requires for complete cross-layer authentication-and-encryption coverage. Read THIS page when CHOOSING the per- publisher per-domain transport-layer MTA-STS-or-DANE publication-discipline approach; read the SPF-for-Microsoft-365 spoke when PUBLISHING per-publisher per- M365-tenant per-domain application-layer SPF infrastructure via the Microsoft 365 admin portal whose per-tenant per- operator SPF publication discipline pairs operationally with the per-publisher per- domain transport-layer MTA-STS-vs-DANE publication-discipline choice THIS page documents at the per-publisher per-tenant per-operator cross-protocol-pillar publication-discipline-composition boundary.
• DKIM cryptography basics — the per-publisher per-selector application-layer per-message DKIM cryptographic-primitive as load-bearing cross-layer peer of transport-layer MTA-STS / DANE cryptographic-primitive choice companion to this per-publisher per-domain transport-layer MTA-STS-vs-DANE publication- discipline reference. Where THIS page documents the per-publisher per-domain transport-layer cryptographic-primitive selection between RFC 8461 MTA-STS (TLS- certificate Web-PKI trust-anchor model, _mta-sts.<domain> TXT-RR publication, https://mta-sts.<domain>/.well-known/mta-sts.txt policy fetch) and RFC 7672 DANE for SMTP (TLSA-RR DNSSEC-anchored trust-anchor model, per-MX-host _25._tcp.<mx-host> TLSA-RR publication, DANE-EE vs DANE-TA usage), the DKIM cryptography-basics spoke documents the per-publisher per-selector application-layer per-message cryptographic-primitive whose publication-discipline pairs operationally with the transport-layer cryptographic- primitive choice as the per-publisher per- domain complete cross-layer cryptographic- authentication-and-encryption posture rhythm. Four DKIM-APPLICATION-LAYER-VS-MTA- STS-OR-DANE-TRANSPORT-LAYER cross- correlation axes the cryptography-basics spoke documents: (i) per-publisher per-domain application-layer per-message DKIM-signature cryptographic primitive PARALLELS the per-publisher per-MX-host transport-layer MTA-STS / DANE TLS- certificate-validation cryptographic primitive at the cross-layer cryptographic- authentication-and-encryption coordination boundary — the per-publisher per- selector DKIM RSA-2048 signature primitive authenticates the per-message identifier at the application layer, AND the per-publisher per-MX-host MTA-STS-enforced or DANE-TLSA- bound TLS-certificate validates the per- receiver per-MX transport-layer encryption; cross-layer cryptographic-publication coordination is the per-publisher per-domain complete authentication-and-encryption publication-posture rhythm; (ii) per- publisher per-selector DKIM RSA-2048-vs- Ed25519-sha256 algorithm-choice PARALLELS per-publisher per-domain DANE TLSA-2-vs-3 certificate-usage choice as cross-layer cryptographic-primitive-selection coordination — the per-publisher per-selector DKIM algorithm choice per RFC 8463 parallels the per-publisher per-MX-host DANE TLSA usage-field choice between DANE-EE (certificate-usage 3, end-entity bound) and DANE-TA (certificate-usage 2, trust-anchor bound) per RFC 7672; both are cross-layer per-publisher per-domain cryptographic- primitive-selection decisions whose per- receiver verifier-coverage divergence impacts per-publisher per-domain complete authentication-and-encryption posture baseline; (iii) per-publisher per- selector DKIM-key-publication TXT-RR publication cadence PARALLELS per-publisher per-MX-host DANE TLSA-RR + MTA-STS policy- host TXT-RR publication cadence as cross- layer cryptographic-publication-discipline coordination — the per-publisher per-selector DKIM TXT-RR publication discipline at <selector>._domainkey.<domain> runs in cross-layer publication-cadence parallel to the per-publisher per-MX-host DANE TLSA-RR publication discipline at _25._tcp.<mx-host> and the per-publisher per-domain MTA-STS policy- host TXT-RR publication discipline at _mta-sts.<domain> + policy-document publication at https://mta-sts.<domain>/.well-known/mta-sts.txt; cross-layer per-publisher per-domain publication-discipline coordination is the per-publisher per-domain complete cryptographic-publication posture rhythm; (iv) per-publisher per-selector DKIM-key-rotation overlap-window discipline PARALLELS per-publisher per-MX-host TLS- certificate-renewal overlap-window discipline as cross-layer cryptographic- lifecycle coordination — the per- publisher per-selector DKIM key-rotation overlap-window (typical 14-90 day window covering per-receiver per-selector cache TTL) parallels the per-publisher per-MX- host TLS-certificate-renewal overlap-window (typical 14-30 day window covering Let's Encrypt or commercial-CA renewal cadence) AND the per-publisher per-domain MTA-STS policy-version mode-rollback overlap-window (testing → enforce mode transition per-receiver MAX-LIFE TTL cache); per- publisher per-domain cross-layer cryptographic-lifecycle coordination is the per-publisher per-domain complete cryptographic-rotation posture rhythm every per-publisher per-domain operator must maintain at the per- application-layer + per-transport-layer cryptographic-primitive lifecycle boundary. Read THIS page when CHOOSING the per- publisher per-domain transport-layer MTA- STS-or-DANE publication-discipline approach; read the DKIM cryptography- basics spoke when AUDITING the per- publisher per-selector application-layer per-message DKIM cryptographic-primitive publication discipline whose per-selector RSA-2048 key-strength baseline, per- algorithm choice, per-publication cadence, and per-rotation overlap-window discipline pair operationally with the per-publisher per-domain transport-layer MTA-STS-vs-DANE publication-discipline choice THIS page documents at the per-publisher per-domain complete cross-layer cryptographic- authentication-and-encryption posture boundary.
• 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.
• DMARC deployment checklist — the 4-PHASE-ROLLOUT-DISCIPLINE companion to this MTA-STS-vs-DANE transport-layer-policy comparison reference. Where THIS page documents the per-publisher per-domain transport-layer policy choice (RFC 8461 MTA-STS HTTPS-fetched policy publication vs RFC 7672 DANE DNSSEC-anchored TLSA RR publication, the per-deployment trust-anchor choice between web-PKI and DNSSEC, the per-receiver enforcement semantics, the per-publisher operational-cost trade-offs), the DMARC-deployment-checklist spoke is the APPLICATION-LAYER-DMARC-ROLLOUT companion documenting the cross- layer composition pattern: the 4-phase Discovery → Triage → Quarantine → Enforcement progression operates at the APPLICATION-LAYER per-message authentication-and- alignment surface (RFC 7489 p=none → p=quarantine → p=reject), while THIS page's per-publisher per-domain MTA-STS or DANE publication operates at the TRANSPORT-LAYER per-SMTP- session encryption-and-integrity surface (TLS-mandatory enforcement on the SMTP path from sender to receiver). The two layers compose: Phase 4 (Enforcement) at p=reject refuses spoofed mail at the receiver-side SMTP RCPT TO stage based on the application-layer DMARC verdict — but ONLY for mail that REACHED the receiver intact; the per-publisher per-domain MTA-STS or DANE publication THIS page compares is the TRANSPORT-LAYER complement that defends the per-session SMTP path from man-in-the-middle TLS-downgrade attacks that would otherwise intercept the message before the application-layer DMARC verdict can execute. The cross-layer rollout sequencing is: complete Phase 1 (Discovery) and Phase 2 (Triage) of the application-layer DMARC progression in parallel with the per-publisher per-domain MTA-STS or DANE choice THIS page documents; confirm Phase 3 (Quarantine) at p=quarantine with the transport-layer policy enforce mode active; advance to Phase 4 (p=reject) only after TLS-RPT confirms no per-receiver transport-layer policy mismatch regressions. Read THIS page when AUTHORING the per-publisher per- domain transport-layer-policy publication-discipline choice that runs in parallel with the application-layer DMARC rollout; read the DMARC-deployment-checklist spoke when AUTHORING the application- layer 4-phase progression that composes with the transport-layer policy THIS page documents at the per-publisher per-domain complete cross-layer authentication-and- encryption posture boundary.
• DKIM alignment with DMARC — the application-layer per-publisher per-domain DKIM identifier-alignment deep-dive (the RFC 6376 d=- tag organisational-domain match against the RFC 5322 From: header per RFC 7489 §3.1.1; the per-tenant relaxed vs strict adkim= mode toggle; the per-message composition rule when multiple DKIM signatures from distinct signers race for the aligned-pass verdict; the third-party-ESP escape hatches via per-domain CNAME-delegated DKIM publication) whose per-publisher per-domain application-layer DKIM- alignment publication-discipline runs IN PARALLEL with the per-publisher per- domain transport-layer MTA-STS-vs-DANE publication-discipline choice THIS page compares side-by-side. The cross-layer composition operates through FOUR operationally-distinct per-publisher per-domain cross-layer-authentication- posture-coupling dimensions: (i) per- publisher per-domain joint application- layer DKIM-aligned-pass-rate floor + transport-layer TLS-encryption-rate floor as the per-publisher per-domain DUAL-LEG complete-authentication-and- encryption posture — the application- layer DKIM-aligned-pass-rate floor gates the per-message DMARC-aligned- pass verdict regardless of which transport-layer protocol THIS page's decision-tree resolves, while the transport-layer TLS-encryption-rate floor gates the per-message MAC- integrity-and-confidentiality posture regardless of the application-layer DKIM-alignment outcome; (ii) per- publisher per-domain joint application- layer DKIM-key-rotation-cadence + transport-layer MTA-STS-policy-host- certificate-renewal-cadence (or DANE TLSA-RR-rollover-cadence) as the per- publisher per-domain cryptographic- material-lifecycle-management discipline — both layers expose CRYPTOGRAPHIC- MATERIAL-EXPIRY-AT-PUBLICATION-BOUNDARY risk that the per-publisher per-domain operations playbook must coordinate across the application-layer per- selector DKIM rotation overlap-window AND the transport-layer cert-or-TLSA rotation overlap-window; (iii) per- publisher per-domain joint application- layer RUA-aggregate-report-ingestion + transport-layer TLS-RPT-failure-report- ingestion as the per-publisher per- domain DUAL-OBSERVABILITY-STREAM evidence-pipeline — the application- layer per-receiver per-day RUA stream surfaces DKIM-alignment-pass-rate regressions per-receiver per-source-IP, while the transport-layer per-receiver per-day TLS-RPT stream surfaces transport-layer policy-mismatch regressions per-receiver per-MX-host; the per-publisher per-domain observability-dashboard MUST ingest BOTH streams jointly to detect cross- layer-correlated regressions; (iv) per- publisher per-domain joint application- layer DMARC-ramp p=none → p=quarantine → p=reject progression-discipline + transport-layer MTA-STS testing → enforce mode-ramp progression-discipline — both ramps are GATED on the per-leg observability-stream's per-receiver per-source-IP regression-incidence falling below the per-publisher per- domain ramp-advancement-floor for that layer; the per-publisher per-domain operations runbook MUST sequence the joint cross-layer ramp progressions so that one layer's regression does not block the OTHER layer's advancement. Read THIS page when AUTHORING the per- publisher per-domain transport-layer MTA-STS-vs-DANE decision; read the DKIM-alignment-with-DMARC spoke when AUTHORING the per-publisher per-domain application-layer DKIM identifier- alignment publication-discipline that runs as the cross-layer peer to THIS page's transport-layer publication- discipline choice at the per-publisher per-domain complete cross-layer authentication-and-encryption posture boundary.
• DKIM replay attacks explained (RFC 6376 §8.6 + RFC 8617 ARC) — the DKIM-replay-attacks spoke documents the RFC 6376 §8.6 DKIM- replay threat-class as the per-publisher per-domain APPLICATION-layer anti-replay defense-discipline whose per-key-lifetime + per-message x= expiration- tag + Trusted ARC Sealer operator- discipline runs STRUCTURALLY ORTHOGONAL to but COMPLEMENTARY with the per-publisher per-domain TRANSPORT-layer MTA-STS-vs-DANE protocol-choice decision THIS page documents. Four CROSS-LAYER-TRUST-MODEL-VS- APPLICATION-LAYER-ANTI-REPLAY coupling axes the replay-attacks spoke documents: (i) per-publisher per-domain TRANSPORT-layer MTA-STS web-PKI-rooted trust-anchor OR DANE DNSSEC-anchored TLSA- record trust-anchor protocol choice is STRUCTURALLY ORTHOGONAL to the per-publisher per-domain APPLICATION-layer per-message DKIM-signature anti-replay defense-discipline but the operator who deploys the per- publisher per-domain full-stack anti- spoofing-and-anti-replay posture must coordinate BOTH layers — receiver-side trust evaluation operates independently at the per-message TLS- handshake boundary (transport-layer) and the per-message DKIM-verification boundary (application-layer), and per-publisher per-domain anti-replay operator-discipline must cover BOTH boundaries to defeat both per-connection MITM downgrade and per- message DKIM-replay attacker mechanics; (ii) per-publisher per-domain TRANSPORT-layer MTA-STS-vs-DANE protocol- choice does NOT close the application- layer DKIM-replay attack-surface STRUCTURALLY — an attacker who captures a per-publisher per-domain cryptographically-legitimate DKIM-signed message over a perfectly-MTA-STS-protected OR perfectly-DANE-protected TLS handshake can still re-send the captured message to arbitrary recipients carrying the per- publisher per-domain DKIM-signature — the per-publisher per-domain transport-layer protocol-choice provides zero anti-replay benefit at the per-message application-layer; the replay-attacks spoke catalogues this as the FUNDAMENTAL layered-defense-decomposition primitive the per-publisher per-domain operator must understand; (iii) per-publisher per-domain APPLICATION-layer per-message x= expiration-tag publication (per RFC 6376 §3.5) and per-selector key-lifetime rotation discipline is the LOAD-BEARING anti-replay control-surface whose per-publisher per-domain operator- discipline TRANSCENDS the transport-layer MTA-STS-vs-DANE protocol-choice decision — per-publisher per-domain operators who run DANE for transport-layer trust- anchoring still need to publish per- message expiration-tags and rotate per- selector keys to defeat per-message DKIM- replay, and per-publisher per-domain operators who run MTA-STS for transport- layer trust-anchoring have the same per- message-granularity anti-replay operator-discipline obligation; (iv) per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate transport-layer failure-evidence stream + RFC 6376 §8.6 application-layer DKIM-replay diagnostic evidence stream are STRUCTURALLY PARALLEL per-publisher per-domain observability surfaces whose joint consumption is the per-publisher per-domain FULL-STACK-OBSERVABILITY operator-discipline primitive — the per-publisher per-domain operator who consumes BOTH the TLS-RPT transport-layer evidence stream (gating MTA-STS-vs-DANE protocol-choice operational health) AND the per-message DKIM-replay application-layer evidence stream (per-message expiration-tag-violation + per-selector key-replay diagnostic) maintains the per-publisher per-domain UNIFIED cross- layer anti-spoofing-and-anti-replay observability surface. Read THIS page when AUTHORING the per-publisher per-domain transport-layer MTA-STS-vs-DANE protocol- choice decision; read the replay-attacks spoke when AUDITING the per-publisher per- domain APPLICATION-layer per-message DKIM- signature anti-replay operator-discipline whose per-key-lifetime + per-message x= expiration-tag + Trusted ARC Sealer operator-discipline runs STRUCTURALLY ORTHOGONAL to but COMPLEMENTARY with the transport-layer protocol-choice decision THIS page documents.
• DKIM for Google Workspace — the PER-WORKSPACE-TENANT-DKIM- SIGNING-DISCIPLINE-AS-MESSAGE-LAYER- CRYPTOGRAPHIC-PRIMITIVE-PARALLEL companion to this MTA-STS-vs-DANE transport-protocol-choice reference. Where THIS page documents the per- publisher per-MX-host TRANSPORT-LAYER cryptographic-protocol-choice decision between MTA-STS (RFC 8461 HTTPS-fetched per-publisher per-policy-domain PKIX-chain-validated transport policy) and DANE TLSA (RFC 7672 DNSSEC- chain-anchored per-MX-host TLSA-RR certificate-pinning) — the per-MX-host cryptographic-primitive-publication trade-offs, the per-publisher per- domain DNSSEC dependency choice, the per-MX-host operational discipline, the per-publisher DANE-MTA-STS dual- deployment composability — the DKIM- for-Workspace spoke documents the PARALLEL MESSAGE-AUTHENTICATION-LAYER per-Workspace-tenant per-custom-domain DKIM-signing deployment workflow (Workspace Admin Console > Apps > Google Workspace > Gmail > Authenticate email; per-tenant per- custom-domain DKIM key generation at 2048-bit RSA modulus; per-selector TXT-record publication under google._domainkey.<domain> in the per-tenant authoritative DNS zone) whose per-Workspace-tenant message-authentication-layer cryptographic-primitive publication is the STRUCTURAL-PARALLEL cryptographic- publication discipline to the per- MX-host transport-layer cryptographic- primitive choice THIS page documents. The MTA-STS-VS-DANE-VS-WORKSPACE-DKIM cross-reference establishes FOUR structurally-distinct cross-layer cryptographic-publication coupling dimensions: (i) BOTH transport-layer MTA-STS / DANE and message-authentication-layer Workspace DKIM are per-publisher per-domain cryptographic-primitive publication disciplines — MTA-STS publishes per- publisher per-policy-domain mta-sts.<d> HTTPS policy + _mta-sts.<d> TXT version-pointer; DANE publishes per- MX-host _25._tcp.<mx> TLSA records; Workspace DKIM publishes per- tenant per-custom-domain google._domainkey.<d> public- key TXT records — the per-publisher per-domain DNS-rooted cryptographic-primitive publication substrate is shared across both protocol-layers; (ii) per- Workspace-tenant per-custom-domain DKIM-signing posture is ORTHOGONAL to but COMPLEMENTARY with the per- publisher per-MX-host MTA-STS / DANE transport-protocol-choice — the operator needs BOTH the per-Workspace- tenant message-authentication-layer cryptographic-publication AND the per-publisher per-MX-host transport- layer cryptographic-publication deployed in parallel — a Workspace-tenant operator who deploys per-Workspace-tenant DKIM signing without per-MX-host MTA-STS or DANE leaves the transport-layer attack- surface gap; a Workspace-tenant operator who deploys per-MX-host MTA- STS without per-Workspace-tenant DKIM signing leaves the message- authentication-layer cryptographic- primitive gap; (iii) per- Workspace-tenant DKIM-key rotation cadence (per RFC 6376 §3.6.1 scheduled per-selector rotation with DNS-propagation overlap) and per- publisher MTA-STS policy version- pointer rotation (the _mta-sts.<d> TXT version-token rotation cadence) 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 Workspace DKIM-selector rotation and MTA-STS policy version-pointer rotation; (iv) per-Workspace- tenant DKIM-signing deployment is the canonical message-authentication- layer primitive every Workspace-tenant operator must complete BEFORE progressing the per-publisher per- domain DMARC ramp to p=quarantine or p=reject, in parallel with the per-MX-host MTA-STS / DANE transport-protocol-choice the operator simultaneously makes for the per-publisher per-MX-host transport-security posture — the per-Workspace- tenant per-custom-domain DKIM-signing deployment + per-MX-host MTA-STS-or- DANE transport-protocol-choice form the per-Workspace-tenant per-domain DUAL-LAYER cryptographic-publication posture (message-authentication layer + transport-security layer). Read this MTA-STS-vs-DANE reference when CHOOSING the per-publisher per-MX- host transport-protocol cryptographic- primitive; read the DKIM-for- Workspace spoke when DEPLOYING the parallel per-Workspace-tenant per- custom-domain message-authentication- layer DKIM-signing posture both protocol-layers structurally co- require.
• Business email compromise (BEC) defender catalogue — the BEC variant + defender-side enforcement-primitive reference covering CEO-fraud / vendor-impersonation / payroll-redirection / cousin-domain- lookalike / compromised-account-replay / thread-hijack-after-account-takeover attack-pattern catalogue and the per- publisher per-domain SPF + DKIM + DMARC + ARC + MTA-STS + BIMI defender-side enforcement-primitive stack against per- attack-variant impersonation. THIS page documents the per-publisher per-domain TRANSPORT-LAYER MTA-STS-PKIX-vs-DANE- DNSSEC-TLSA protocol-choice decision-tree at the per-MX-host receiver-side STARTTLS- chain-validation boundary as the canonical TRANSPORT-LAYER-AUTHORISATION-PERIMETER per-publisher per-domain dual-protocol choice substrate; the BEC-defender-catalogue spoke is the per-attack-variant defender- side enforcement peer documenting how the per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice this page documents structurally closes per-attack- variant BEC transport-layer attack-surfaces — (i) per-attacker per-MX-host STARTTLS- downgrade attack-variant (the opportunistic-MTA-MITM class targeting per- publisher per-domain inbound BEC vendor- impersonation messages) is structurally closed by per-publisher per-domain MTA-STS mode: enforce at the receiver- side STARTTLS connection boundary, denying per-attacker per-MX MITM the per-message downgrade-to-plaintext-then-rewrite attack- primitive; (ii) per-attacker per-MX-host certificate-substitution attack-variant is closed by per-publisher per-domain DANE TLSA RR DNSSEC-anchored per-MX-host certificate-pinning at the per-publisher per-domain DNSSEC trust-anchor boundary, denying per-attacker compromised-CA-issued impersonation certificates at the per-MX connection-validation gate; (iii) per- attacker per-MX-host DNS-hijack attack- variant (the BGP-hijack / DNS-cache- poisoning class targeting per-publisher per-domain inbound BEC payload delivery) is closed by per-publisher per-domain DANE DNSSEC-anchored TLSA-RR-publication substrate at the per-MX-host receiver-side DNS-resolution boundary; (iv) per-publisher per-domain combined MTA-STS-enforce + DANE- TLSA-publish DUAL-PROTOCOL-LEG transport- layer hardening posture is the canonical BEC-defender-side per-attack-variant transport-layer-attack-surface CLOSURE DISCIPLINE every per-publisher per-domain BEC-defender-side per-attack-variant defender-catalogue MUST publish as load- bearing inbound-transport-layer-hardening prerequisite. Read the BEC-defender- catalogue spoke alongside this MTA-STS-vs- DANE protocol-choice reference when authoring the per-publisher per-domain BEC-defender-side per-attack-variant inbound-transport-layer-hardening publication discipline that structurally closes the per-attack-variant transport- layer attack-surface the per-publisher per-domain TLS-RPT receiver-side STARTTLS- chain-validation evidence stream surfaces as load-bearing BEC-defender-side per- attack-variant indicator-of-compromise.
• DKIM key rotation — the APPLICATION-LAYER-DKIM-PRIVATE-KEY- ROTATION-VS-TRANSPORT-LAYER-MTA-STS-AND- DANE-KEY-PIN-ROTATION companion to this MTA-STS-vs-DANE transport-layer protocol- choice reference. Where THIS page documents the per-publisher per-domain transport- layer key-custody disciplines (MTA-STS public-CA-rooted TLS-chain trust-anchor publication via `mta-sts.txt` policy file + DANE DNSSEC-rooted TLSA-record per-MX key- pin trust-anchor publication), the DKIM- key-rotation spoke is the STRUCTURAL APPLICATION-LAYER PARALLEL per-publisher per-selector key-custody discipline whose joint operation with the transport-layer key-custody disciplines forms the per- publisher per-domain FULL-STACK-CRYPTOGRAPHIC- KEY-CUSTODY DEFENSE-IN-DEPTH operator- discipline. FOUR cross-layer-key-rotation coupling dimensions: (i) per-publisher per-domain application-layer DKIM private-key rotation cadence STRUCTURALLY PARALLEL to transport- layer MTA-STS policy rotation cadence as per-publisher per-domain joint key-rotation runbook coordination discipline — the per-publisher per-domain DKIM-key- rotation 90-180-day cadence parallels the per-publisher per-domain MTA-STS policy- file `id=`-tag-versioned rotation cadence (operator-discretionary, typically aligned with the TLS-certificate rotation cadence at the receive-side MX hostname); the DKIM- key-rotation spoke documents the application- layer per-selector key-custody discipline whose joint operation with the transport- layer MTA-STS policy-file rotation forms the per-publisher per-domain joint key- rotation runbook; (ii) per-publisher per-domain application-layer DKIM private-key compromise incident-response discipline (revocation via empty-`p=` publication + emergency rotation) STRUCTURALLY PARALLEL to transport- layer DANE TLSA-record key-pin compromise incident-response discipline (TLSA-record re-publication after key-pin compromise) as joint per-publisher per-domain key- compromise incident-response coordination discipline — per-publisher per- domain incident response to per-selector DKIM private-key compromise REQUIRES per- selector revocation-via-empty-`p=` publication PLUS emergency rotation; per- publisher per-domain incident response to per-MX DANE TLSA key-pin compromise REQUIRES DNSSEC-signed TLSA-record re- publication to remove the compromised key-pin; the DKIM-key-rotation spoke documents the application-layer per- selector key-compromise incident-response discipline whose joint operation with the transport-layer DANE TLSA key-pin compromise incident-response forms the per-publisher per-domain full-stack key-compromise incident-response runbook; (iii) per-publisher per-domain application-layer DKIM dual-selector overlap-window rotation discipline STRUCTURALLY PARALLEL to transport-layer DANE TLSA dual-record overlap-window rotation discipline as per-receiver per- resolver-cache TTL-bounded propagation- window-floor cross-layer coordination discipline — per-publisher per- domain DKIM-rotation requires concurrent publication of `selector1._domainkey` + `selector2._domainkey` across the per- receiver per-resolver-cache eviction window; per-publisher per-domain DANE TLSA-rotation requires concurrent publication of TLSA records matching BOTH the outgoing-MX-cert keypin AND the incoming-MX- cert keypin across the per-receiver per- resolver-cache eviction window; the DKIM- key-rotation spoke documents the application- layer per-selector overlap-window discipline whose parallel transport-layer DANE TLSA overlap-window discipline THIS page catalogues at the cross-layer rotation- cadence coordination boundary; (iv) per-publisher per-domain application-layer DKIM RSA-2048-bit key- strength minimum (RFC 8301) STRUCTURALLY PARALLEL to transport-layer TLS-certificate RSA-2048-bit-minimum / ECDSA-P256-minimum key-strength discipline as full-stack cryptographic key-strength-floor operator- discipline — per-publisher per- domain DKIM keys MUST meet the RFC 8301 RSA-2048-bit key-strength minimum; per- publisher per-domain receive-side TLS- certificates MUST meet the public-CA- baseline key-strength floor (RSA-2048-bit / ECDSA-P256-bit); the DKIM-key-rotation spoke documents the application-layer per- selector key-strength-floor discipline whose parallel transport-layer TLS- certificate key-strength-floor discipline the MTA-STS-vs-DANE protocol-choice consumes via the receive-side trust-anchor validation evidence the per-receiver TLS- RPT JSON-aggregate report stream surfaces. Read the DKIM-key-rotation spoke alongside this MTA-STS-vs-DANE transport-layer protocol-choice reference when AUTHORING the per-publisher per-domain full-stack cryptographic-key-custody DEFENSE-IN-DEPTH operator-discipline runbook that coordinates application-layer DKIM-key- rotation cadence with transport-layer MTA-STS policy-rotation + DANE TLSA-record key-pin-rotation cadence, when PLANNING the per-publisher per-domain joint key-rotation calendar across the application-layer DKIM-selector boundary AND the transport-layer MTA-STS policy-file + DANE TLSA-record boundaries, or when AUTHORING the per-publisher per-domain joint key-compromise incident-response runbook the per-publisher operator- discipline-floor across the cross-layer cryptographic-key-custody surface.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- RECORD-BYTE-LEVEL-PUBLICATION-DISCIPLINE-AS- CANONICAL-DNS-PUBLISHED-POLICY-DIRECTIVE- REFERENCE companion to this MTA-STS-vs-DANE transport-layer comparison. Where THIS page documents the per-publisher MTA-STS HTTPS- served policy publication (mta-sts.<domain> well-known endpoint serving mode: testing/ enforce + mx: hostname-pattern allowlist + max_age: seconds) vs DANE DNS-published TLSA-record publication (_25._tcp.<mx>. IN TLSA 3 1 1 <cert-association-data>) trade-offs at the per-publisher per-domain transport-layer hardening boundary, the SPF-DNS-record-syntax spoke is the per-publisher-per-domain APPLICATION-LAYER DNS-PUBLISHED policy-directive reference that complements the transport-layer comparison at FOUR per-publication- primitive cross-cluster coordination dimensions: (i) per-publisher per-domain SPF TXT-record DNS-publication as APPLICATION-LAYER per-source-IP envelope-MAIL-FROM authorisation primitive complementing transport-layer per-message STARTTLS authorisation — both per-publisher publication primitives produce per-receiver per-message policy directives (SPF: per-source-IP envelope- MAIL-FROM authorisation at the per-message application layer; MTA-STS: per-MX hostname-pattern + STARTTLS-enforce at the per-message transport layer; DANE: per-MX TLSA-certificate-association at the per- message transport layer), so per-publisher per-domain operators rolling out MTA-STS or DANE typically already have SPF DNS records published — the SPF DNS record syntax reference documents the per- publisher per-source-IP authorisation primitive that the per-publisher MTA-STS / DANE rollout transport-hardens at the per-message STARTTLS boundary; (ii) per-publisher per-domain SPF include: chain depth-limit (RFC 7208 §4.6.4) as DNS-publication-discipline evidence-source for MTA-STS testing mode coordination — the per- publisher SPF DNS record's 10-DNS-lookup chain-depth limit produces per-receiver per-message spf=permerror when exceeded, which the per-publisher per-domain operator audits BEFORE committing to per- publisher MTA-STS testing mode rollout (which generates per-publisher TLS-RPT per-receiver evidence streams the per- publisher MTA-STS discipline depends on being readable per-message — per-message SPF-permerror cascades complicate per- receiver per-message TLS-RPT attribution); (iii) per-publisher per-domain SPF ~all softfail qualifier as deliverability-monitoring-mode-published complement to per-publisher MTA-STS testing mode publication — the per-publisher SPF DNS record's ~all softfail qualifier (deliberate per- publisher monitoring-mode publication analogous to MTA-STS testing mode) is the per-publisher application-layer deliverability-discipline-publication complement to the per-publisher MTA- STS testing mode transport-layer publication — per-publisher operators running both publications in parallel gather per-source-IP application-layer + per-MX transport-layer per-message evidence streams for coordinated rollout to per-publisher SPF -all hardfail + per-publisher MTA-STS enforce mode terminal-discipline- publication; (iv) per-publisher per-domain SPF DNS-record vs MTA-STS HTTPS-policy-file vs DANE DNS-TLSA per-receiver-resolution-path comparison as policy-publication-mechanism trade- off reference — the per- publisher SPF DNS record syntax reference documents the per-publisher TXT-record publication mechanism (DNS- served per-receiver-cached per-source- IP application-layer policy) that operators directly compare against the per-publisher MTA-STS HTTPS-served policy-file mechanism (per-receiver well-known fetch + per-publisher max_age cache-discipline) and the per-publisher DANE DNSSEC-protected TLSA-record mechanism (per-receiver DNSSEC-validated per-MX certificate-pin) when designing per-publisher per-domain cross-layer policy-publication strategy. Read the SPF DNS record syntax spoke alongside this MTA-STS-vs-DANE comparison when designing per-publisher per-domain cross-layer (application-layer + transport-layer) policy-publication rollout strategy, when AUDITING per- publisher per-domain SPF record state BEFORE committing to per-publisher MTA-STS or DANE transport-layer rollout, or when AUTHORING per- publisher per-domain DNS-published- policy-directive cross-reference documentation comparing per-mechanism per-qualifier per-modifier byte-level semantics across SPF + MTA-STS + DANE + DMARC publication primitives.
• DMARC myths and misconceptions — the PER-PUBLISHER-PER-DOMAIN-MTA-STS- VS-DANE-TRANSPORT-LAYER-DECISION-MATRIX- OPERATOR-SIDE-MISTAKE-PATTERN-AS-PER- PUBLISHER-PER-DOMAIN-MYTH-CATALOGUE- LOOKUP-REFERENCE companion to THIS MTA- STS-vs-DANE protocol-comparison reference. Where THIS page documents the per-publisher per-domain MTA-STS-vs-DANE decision-matrix (the per-publisher per- domain MTA-STS HTTPS-served policy-file publication discipline vs the per- publisher per-MX-host DANE TLSA-record DNSSEC-anchored cryptographic-certificate- pinning discipline, the per-publisher per- domain transport-layer-rollout deployment- complexity trade-offs, the per-receiver- MTA per-publisher per-domain transport- layer-protocol-support matrix, and the per-publisher per-domain operator- discipline-floor coordinating per-protocol rollout cadence), the DMARC-myths-and- misconceptions spoke documents the per- publisher per-domain operator-side transport-layer-vs-application-layer misconception bucket the per-publisher per-domain transport-layer-protocol-choice operator MUST consult at FOUR per-MTA- STS-vs-DANE-vs-DMARC-myth-catalogue coupling dimensions: (i) per- publisher per-domain "DMARC alone is enough" misconception lookup as per- publisher per-domain transport-layer- complement mythbusting catalogue consultation — per-publisher per- domain operators commonly adopt the "DMARC application-layer enforcement alone is enough — no transport-layer MTA-STS or DANE hardening needed" / "DMARC p=reject covers all attack surfaces" / "transport-layer hardening is unnecessary because DMARC blocks spoofing" misconceptions during per- publisher per-domain transport-layer- rollout planning, and the DMARC-myths-and- misconceptions spoke's transport-layer- complement mythbusting entries (DMARC application-layer authenticates the per- message identifier-alignment evidence but does NOT defend against per-receiver-MTA MITM TLS-certificate-substitution attack- class that the per-publisher per-MX-host DANE TLSA-record or per-publisher per- domain MTA-STS policy-file defends against) IS the per-publisher per-domain canonical pre-flight per-publisher per- domain transport-layer-vs-application- layer rollout audit reference; (ii) per-publisher per-domain "MTA-STS replaces DMARC" misconception lookup as per-publisher per-domain transport-layer- application-layer-orthogonality mythbusting catalogue consultation — per-publisher per-domain operators commonly adopt the "MTA-STS replaces DMARC at the transport layer" / "DANE TLSA-record alone provides per-message authenticity at the application layer" / "transport-layer authenticated TLS means per-message DMARC verdict is no longer needed" transport-layer-vs- application-layer-orthogonality misconceptions during per-publisher per- domain protocol-stack rollout planning, and the DMARC-myths-and-misconceptions spoke's transport-layer-application- layer-orthogonality mythbusting entries provide the per-publisher per-domain canonical pre-flight per-publisher per- domain protocol-stack-orthogonality audit reference; (iii) per- publisher per-domain "MTA-STS and DANE are interchangeable" misconception lookup as per-publisher per-domain transport-layer-protocol-distinctness mythbusting catalogue consultation — per-publisher per-domain operators commonly adopt the "MTA-STS and DANE are interchangeable" / "deploying both MTA- STS and DANE is redundant" / "one protocol covers the other's gaps" transport-layer- protocol-distinctness misconceptions during per-publisher per-domain transport-layer-protocol-selection planning, and the DMARC-myths-and- misconceptions spoke's transport-layer- protocol-distinctness mythbusting entries (MTA-STS depends on HTTPS-served policy- file integrity + receiver-side policy- cache freshness; DANE depends on DNSSEC chain-of-trust integrity at the per-MX- host TLSA-record publication boundary; deploying BOTH provides defense-in-depth against per-protocol-specific gap exploitation) provide the per-publisher per-domain canonical pre-flight transport-layer-protocol-selection audit reference; (iv) per-publisher per- domain "transport-layer hardening blocks legitimate forwarders" misconception lookup as per-publisher per-domain transport-layer-rollout-cadence mythbusting catalogue consultation — per-publisher per-domain operators commonly adopt the "MTA-STS mode=enforce breaks forwarders" / "DANE TLSA-validation breaks legitimate mail-flow" / "transport- layer hardening is incompatible with ARC-rescued forwarder chain" forwarder- compatibility misconceptions during per- publisher per-domain transport-layer- rollout-cadence planning, and the DMARC- myths-and-misconceptions spoke's forwarder-compatibility mythbusting entries (MTA-STS mode=testing observation-only phase + DANE TLSA-pin per-MX-host dual-publication overlap- window discipline + ARC-aware downstream- receiver evaluation discipline jointly preserve legitimate forwarder mail-flow) provide the per-publisher per-domain canonical pre-flight transport-layer- rollout-cadence audit reference. Read THIS MTA-STS-vs-DANE protocol-comparison reference when SELECTING the per- publisher per-domain transport-layer- protocol-rollout strategy AND when COORDINATING the per-publisher per- domain protocol-stack rollout cadence against the per-publisher per-domain operator-side mistake-pattern catalogue; read the DMARC-myths-and-misconceptions spoke when AUDITING the per-publisher per-domain transport-layer-vs-application- layer-rollout operator-side mistake- pattern catalogue lookup BEFORE per- publisher per-domain transport-layer- policy-publication commit THIS page documents.
• SPF mechanism-choice decision matrix
• DMARC monitoring
• DKIM for Microsoft 365
• SPF permerror vs temperror
• DMARC for shared-hosting providers — the per-hosting-provider per-customer- domain transport-layer-protocol-choice-at- scale-vs-DMARC-ramp coordination companion to this MTA-STS-vs-DANE decision-matrix pillar. Where THIS page documents the per-publisher per-domain transport-layer-protocol-choice decision-matrix (MTA-STS HTTPS-served policy- file at _mta-sts.<domain> per RFC 8461 §3.2 vs DANE TLSA-RR DNSSEC- anchored cryptographic-certificate-pinning per RFC 6698 + RFC 7672), the shared-hosting spoke documents the per-hosting-provider per- customer-domain DMARC ramp the per-customer- domain transport-layer protocol-choice underpins. Four coupling axes connect them: (i) per-hosting-provider DANE adoption is gated by per-customer-domain DNSSEC signing- infrastructure availability — many shared-hosting customers' parent zones lack DNSSEC signing, forcing per-hosting-provider MTA-STS-default policy-choice over DANE at thousands-of-customer-domains scale; (ii) per-hosting-provider MTA-STS HTTPS-served- policy infrastructure (the https://mta-sts.<customer-domain>/.well-known/mta-sts.txt per-customer-domain endpoint serving the version: STSv1 / mode: enforce / mx: allow-list / max_age: policy file) MUST scale across thousands of per-customer-domain HTTPS endpoints with valid TLS certificates and uniform per- customer-domain MX-allow-list discipline; (iii) per-hosting-provider per-customer-domain MTA-STS mx: allow-list MUST enumerate the hosting-provider's inbound-MX- host pattern (e.g. mx: *.mail.<hosting-provider>.net) plus any customer-overridden inbound MX-hosts — parallel to per-customer-domain DMARC composite-verdict computation depending on per-customer-domain SPF + DKIM publication discipline; (iv) per-hosting-provider per- customer-domain MTA-STS mode: enforce + per-customer-domain DMARC p=reject JOINTLY satisfy the 2024 Gmail/Yahoo/Microsoft Bulk-Sender- Requirements composite transport-layer- cryptographic-integrity + application-layer- identity-authentication floor at hosting- provider scale. Read the shared-hosting spoke alongside this MTA-STS-vs-DANE decision- matrix pillar when AUTHORING per-hosting- provider transport-layer-protocol-choice publication discipline across the per- customer-domain tenant portfolio, when AUDITING per-customer-domain composite transport-layer + application-layer publication-floor preservation under hosting- provider infrastructure constraints, or when PLANNING per-hosting-provider DNSSEC signing-infrastructure adoption sequencing gating per-customer-domain DANE-eligibility progression.
• DMARC policy modes
• DMARC policy rollout
• DMARC forensic (RUF) failure reports
• SPF qualifiers explained — the per-publisher per-domain SPF qualifier-prefix envelope-MAIL-FROM-layer enforcement-decision companion at four per-publisher per-domain SPF-qualifier-prefix-vs-MTA-STS-vs-DANE coupling dimensions: (i) per-publisher per-domain SPF terminal-qualifier -all strict-fail vs ~all softfail publication-decision per RFC 7208 §4.6.2 IS structurally parallel envelope-MAIL-FROM-layer enforcement-mode publication-decision to per-publisher per-domain MTA-STS mode: testing vs mode: enforce transport-layer enforcement-mode publication-decision per RFC 8461 §5.2 vs per-publisher per-domain DANE cert-usage = DANE-EE(3) transport-layer enforcement-mode publication-decision per RFC 7672 §3 — all three per-publisher per-domain cross-layer enforcement-mode publication-decisions coordinate at the per-publisher per-domain composite envelope-MAIL-FROM-and-transport-layer enforcement-mode publication-decision coordination boundary the per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice decision-matrix THIS page documents structurally underpins; (ii) per-publisher per-domain SPF qualifier-prefix result-class taxonomy (+/-/~/? per RFC 7208 §4.6.2 mapping to spf=pass/spf=fail/spf=softfail/spf=neutral per RFC 7208 §2.6) IS structurally parallel envelope-MAIL-FROM-layer per-leg result-class catalogue to per-publisher per-domain MTA-STS-vs-DANE transport-layer per-leg result-class catalogue (MTA-STS-enforce surfacing sts-policy-fetch-error/sts-policy-invalid/certificate-host-mismatch vs DANE-enforce surfacing dnssec-invalid/dane-mismatch/tlsa-invalid) the per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice decision-matrix THIS page documents the per-publisher per-domain transport-layer publication-discipline of materially surfaces against; (iii) per-publisher per-domain SPF terminal-qualifier publication-decision discipline ramp (~all softfail → -all hardfail) IS structurally parallel envelope-MAIL-FROM-layer enforcement-ramp publication-discipline to per-publisher per-domain MTA-STS mode: testing → mode: enforce transport-layer enforcement-ramp publication-discipline + per-publisher per-domain DANE TLSA-RR DNSSEC-chain-anchored enforcement-ramp publication-discipline whose composite per-publisher per-domain envelope-MAIL-FROM-and-transport-layer enforcement-floor preservation discipline the per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice decision-matrix THIS page documents the per-publisher per-domain transport-layer enforcement-decision-discipline of structurally coordinates; (iv) per-publisher per-domain SPF qualifier-prefix mechanism-class publication-discipline drift (premature -all hardfail cutover / ~all-stuck publication-discipline drift / include:-cascade-target publication-discipline drift) IS structurally parallel envelope-MAIL-FROM-layer publication-discipline-drift class to per-publisher per-domain MTA-STS publication-discipline drift (mis-published _mta-sts.<domain> TXT-RR / HTTPS-served-policy fetch failure) vs per-publisher per-domain DANE publication-discipline drift (TLSA-RR-mis-publication / DNSSEC-chain-break) the per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice decision-matrix THIS page documents the per-publisher per-domain transport-layer publication-discipline-drift closure of materially diagnoses.
• DKIM DNS TXT-record byte syntax
• DKIM canonicalization — the PER-PUBLISHER-PER-DOMAIN-MTA-STS-VS-DANE-TRANSPORT-LAYER-PROTOCOL-CHOICE-DECISION-MATRIX-AS-STRUCTURALLY-PARALLEL-CRYPTOGRAPHIC-ALGORITHM-CHOICE-PUBLICATION-DECISION-COMPANION-TO-PER-PUBLISHER-PER-SELECTOR-DKIM-APPLICATION-LAYER-CANONICALIZATION-ALGORITHM-CHOICE-PUBLICATION-DECISION companion at four per-publisher per-domain MTA-STS-vs-DANE-transport-layer-vs-DKIM-canonicalization-application-layer coupling dimensions: (i) per-publisher per-domain MTA-STS-vs-DANE transport-layer cryptographic-trust-anchor protocol-choice decision-matrix THIS page documents (X.509-PKI-trust per RFC 8461 §3.2 vs DNSSEC-chain-trust per RFC 7672 prerequisites) IS structurally parallel per-publisher per-domain cryptographic algorithm-choice publication-decision to per-publisher per-selector DKIM c=relaxed/relaxed vs c=simple/simple canonicalization-algorithm publication-decision per RFC 6376 §3.4 — both per-publisher per-domain cryptographic algorithm-choice publication-decisions are per-publisher per-domain operator-side cryptographic-publication-discipline algorithm-choice primitives at the per-publisher per-domain composite cross-layer cryptographic-publication-discipline-and-algorithm-choice coordination boundary; (ii) per-publisher per-MX-host DANE-secured STARTTLS-required transport-layer envelope-integrity floor THIS page documents the per-publisher per-domain transport-layer protocol-choice decision-matrix of 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; (iii) per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice publication-discipline drift (mis-published _mta-sts.<domain> TXT-RR / policy-file fetch failure / TLSA-RR-mis-publication / DNSSEC-chain-break) surfacing in per-receiver per-day TLS-RPT JSON-aggregate-report failure-details 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; (iv) per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice decision-matrix THIS page documents AS the per-publisher per-domain operator-side transport-layer cryptographic-trust-anchor algorithm-choice reference IS structurally parallel to per-publisher per-selector DKIM canonicalization algorithm-choice as the per-publisher per-domain operator-side application-layer cryptographic-byte-stream-production-discipline algorithm-choice reference — both per-publisher per-domain cross-layer algorithm-choice publication-discipline references jointly compose the per-publisher per-domain composite cross-protocol cross-layer cryptographic-publication-discipline floor at the per-publisher per-domain composite cross-layer cryptographic-trust-anchor-and-signature-integrity coordination boundary the per-publisher per-domain MTA-STS-vs-DANE transport-layer protocol-choice decision-matrix THIS page documents the per-publisher per-domain transport-layer cryptographic-publication-discipline algorithm-choice of.
• DMARC multi-domain strategy
• Forwarding issues with SPF — the SRS / ARC / mailing-list / .forward catalogue of forwarder-induced SPF failures. Where this page weighs the two transport-layer protocols that secure the relay hop, the forwarding-issues spoke covers what that relay hop does to the application-layer SPF identity — envelope rewrites at the forwarder break the original SPF authorization, and SRS / ARC are the compensating mechanisms.
• DKIM selectors — where this page weighs the two transport-layer protocols that secure the relay hop, DKIM selectors govern the application-layer signing identity that travels inside that hop. A selector names the <selector>._domainkey.<domain> TXT-RR carrying a signing public key, and the selector namespace is what lets an operator stage and roll keys without breaking in-flight mail — the message-layer analogue of the TLSA-record and certificate rotation MTA-STS and DANE each demand at the transport layer. Read the DKIM selectors spoke to see how the signing-key lifecycle is managed once a message is safely delivered over the secured hop this page compares.
• Email security glossary — the plain-language reference for the transport-security vocabulary this MTA-STS-vs-DANE comparison relies on: STARTTLS, TLSA, DNSSEC, MX, policy mode, and the certificate-validation terms that distinguish the two protocols. Read the glossary when a term in the transport-layer comparison is unfamiliar before acting on it.
• SPF mechanisms explained — MTA-STS and DANE secure the transport channel to your MX, while SPF authorizes the envelope sender at the message layer; both are controls the same domain publishes at distinct layers. Read the SPF mechanism catalogue (a/mx/ip4/include/all + the RFC 7208 §4.6.4 10-DNS-lookup cap) to see the envelope-layer analogue to the transport-policy comparison here — the -all terminal mechanism is the message-layer counterpart to MTA-STS enforce.
• SPF 10-DNS-lookup limit — the ENVELOPE-LAYER-DNS-RESOLUTION-BUDGET-DISCIPLINE companion to this transport-policy comparison: MTA-STS and DANE both impose their own DNS-resolution dependency (the _mta-sts.<domain> TXT-RR plus HTTPS policy fetch for MTA-STS, the _25._tcp.<mx> TLSA-RR lookup for DANE), and SPF imposes its own include:-cascade DNS-lookup budget at the envelope layer — all three are per-domain DNS-publication-and-resolution disciplines an operator must keep within budget for the control to evaluate cleanly. Read the SPF-10-DNS-lookup-limit spoke to see the envelope-layer DNS-budget analogue to the transport-layer resolution dependencies this MTA-STS-vs-DANE comparison weighs.
• RFC 8461 - MTA-STS - the SMTP MTA Strict Transport Security specification.
• RFC 7672 - DANE for SMTP - the DANE profile for SMTP transport security.
• RFC 6698 - The DANE TLSA Resource Record - the base DANE specification establishing the TLSA record format.
• RFC 8460 - TLS-RPT - the SMTP TLS Reporting specification.
• 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.

14. Check your current transport security posture

DMARC Analyzer's free Domain Security Checker performs live DMARC + SPF + DKIM + MTA-STS + BIMI + DNSSEC lookups against any domain. Use it to check your current MTA-STS policy and DANE TLSA records, confirm DNSSEC validates correctly on the recipient zone, and validate each deployment step before pushing to production. The DNS Record Generator (linked above) builds syntactically-correct MTA-STS discovery TXT records and TLSA records with the canonical DANE-EE / SPKI / SHA-256 deployment shape. Imported DMARC aggregate reports (via includes/DmarcParser.php) plus parsed TLS-RPT reports (via includes/TlsRptParser.php) drive the dashboard that surfaces transport-security failures and migration progress.

Check my current transport security Sign up — Free plan