DMARC Analyzer

TL;DR

• MTA-STS (SMTP MTA Strict Transport Security) is the standard that forces inbound SMTP to use authenticated TLS. Defined in RFC 8461 (the protocol) and RFC 8460 (companion TLS-RPT reporting).
• MTA-STS is two artefacts: a DNS TXT record at _mta-sts.<domain> carrying v=STSv1; id=<policy-id>, and an HTTPS-served policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt.
• The policy file declares version, mode (none / testing / enforce), mx hosts, and max_age (cache lifetime in seconds, typically 86400 to 604800).
• STARTTLS alone is downgradable: an active attacker can strip the STARTTLS advertisement. MTA-STS closes that gap by telling sending MTAs that TLS is mandatory, the certificate must validate against the public PKI, and the hostname must match a declared MX.
• The migration path is mode: none → mode: testing → mode: enforce. Pair with TLS-RPT from day one so failures surface before they bite production.
• MTA-STS is the web-PKI alternative to DANE (RFC 7672). DANE requires DNSSEC; MTA-STS requires HTTPS. Senders that support both prefer DANE when a TLSA record exists and fall back to MTA-STS otherwise.

1. What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security) is an email transport-security standard that lets a receiving domain publish a policy requiring sending Mail Transfer Agents (MTAs) to use authenticated TLS for inbound SMTP. MTA-STS is specified in RFC 8461 - SMTP MTA Strict Transport Security (MTA-STS) and is typically deployed alongside its companion standard RFC 8460 - SMTP TLS Reporting (TLS-RPT), which provides the operational feedback channel.

MTA-STS closes a specific gap in STARTTLS (RFC 3207). STARTTLS upgrades a plaintext SMTP session to TLS when both sides advertise it, but the advertisement itself is in the cleartext SMTP handshake - an active network attacker can strip the STARTTLS keyword from the server's EHLO response, and the session silently falls back to plaintext. MTA-STS tells supporting senders that TLS is mandatory: certificate validation against the public PKI, hostname match against one of the declared MX hosts, and refusal to deliver mail if the requirements are not met.

Critically, MTA-STS is NOT an authentication mechanism for the message itself. It does not sign messages, does not authorise senders, does not produce a DMARC verdict. It is purely a transport-security control - it ensures the SMTP envelope crosses the network inside a properly authenticated TLS session. Message authentication is the job of SPF, DKIM, and DMARC; MTA-STS is the parallel transport layer.

2. How MTA-STS works, step by step

1. The recipient domain publishes a DNS TXT record at _mta-sts.<domain> containing v=STSv1; id=<policy-id>. The id is an opaque identifier that senders use as a cache key for the HTTPS policy file - changing the policy MUST also change the id.
2. The recipient hosts an HTTPS policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt. The TLS certificate on this host MUST chain to a public-PKI root - this is the trust anchor that makes MTA-STS a "web-PKI" mechanism. The policy file lists the version, the mode, the allowed MX hosts, and the cache lifetime.
3. When a sending MTA has mail for the recipient domain, it queries the _mta-sts DNS record. If found, the MTA fetches the policy file via HTTPS (re-fetching only when its cached id differs from the DNS id= tag or the cache has expired).
4. For the SMTP connection, the sending MTA enforces: the connecting hostname matches one of the policy's mx entries (with wildcard support for a single leftmost label), the TLS handshake succeeds, and the presented certificate validates against the public-PKI roots with the hostname present in the SAN.
5. If the policy mode is enforce, any failure of those checks causes the sender to REFUSE delivery and report the failure via TLS-RPT if configured. If the policy mode is testing, the sender STILL delivers the mail but reports the failure - the operator gets feedback without breaking mail flow.
6. The sending MTA caches the policy for up to max_age seconds. Cache TTLs of 1 day to 1 week are typical - aggressive caching is part of the design so a transient DNS or HTTPS outage on the recipient side does not immediately drop mail.

3. MTA-STS DNS syntax

The MTA-STS DNS record is a single TXT record at the well-known label _mta-sts under the recipient domain.

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

Tag-by-tag anatomy of the MTA-STS DNS record:

v=STSv1

Version tag. MUST appear first; receivers that find a missing or invalid v= ignore the record. STSv1 is the only defined version at the time of writing.

id=<policy-id>

Opaque policy identifier (1-32 alphanumeric characters per RFC 8461 §3.1). Sending MTAs use this as a cache key for the HTTPS policy file: when the DNS id differs from the cached one, the sender refetches the policy. A common convention is an ISO-8601 timestamp (20260518T120000) - readable, monotonic, and trivially unique per policy change.

The DNS record is required but is NOT the policy itself - it is a pointer that tells senders an MTA-STS policy exists and that the current version of that policy can be identified by id=. The actual rules live in the HTTPS policy file (next section).

4. HTTPS policy file

The MTA-STS policy file is plain text served over HTTPS at the well-known path /.well-known/mta-sts.txt on the mta-sts subdomain of the recipient. The server MUST present a certificate that validates against the public-PKI root store for the mta-sts.<domain> hostname; HTTP fallback is forbidden.

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

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

Key-by-key anatomy of the policy file:

version: STSv1

REQUIRED. Pins the policy to the MTA-STS v1 grammar. Lines use the format key: value (colon-separated, one per line).

mode: none | testing | enforce

REQUIRED. The operational mode of the policy. none retracts a previously published policy (senders SHOULD treat the domain as if it had never published one). testing means senders evaluate the policy and report failures via TLS-RPT but still deliver the mail. enforce means senders refuse to deliver mail when policy checks fail.

mx: <hostname>

REQUIRED in testing and enforce modes. Each mx: line declares one acceptable MX hostname. Wildcards (*.example.com) match exactly one leftmost label; deeper subdomains do NOT match (*.example.com matches mx1.example.com but NOT a.mx1.example.com). MUST be present at least once.

max_age: <seconds>

REQUIRED. Cache lifetime of the policy at the sender, in seconds. RFC 8461 caps the value at 31 557 600 (about 1 year). Typical production values are 86 400 (1 day) for early testing rollouts and 604 800 (1 week) once enforce is stable. High max_age is part of the design: it protects against transient DNS/HTTPS outages on the recipient side that would otherwise drop mail.

The policy file MUST be served with Content-Type: text/plain. Newlines may be CRLF or LF. Unknown keys are ignored per RFC 8461 §3.2, which keeps the format forward-compatible.

5. Policy modes: none, testing, enforce

The typical migration path is mode: testing with max_age: 86400 for 4-8 weeks while TLS-RPT is reviewed weekly, then a switchover to mode: enforce with max_age: 604800. Skipping testing and going straight to enforce is the leading cause of self-inflicted mail outages with MTA-STS - any legitimate sender that the operator missed (a forwarding service, a hosted helpdesk, a CRM integration) starts bouncing on the next send.

6. MTA-STS vs DANE for SMTP

The two mechanisms are complementary, not competing. The recommended deployment posture for high-assurance domains is BOTH: a DNSSEC-signed zone with TLSA records (DANE) and an MTA-STS policy at enforce. A sending MTA that supports both prefers DANE when a TLSA record is present (it is the cryptographically stronger signal when DNSSEC validates) and falls back to MTA-STS for recipients that lack DNSSEC.

7. MTA-STS examples

7.1 Minimal enforce policy

# DNS:
_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260518T120000"

# https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

A single-MX domain in steady-state enforce with a one-week cache. Replacing the certificate on mail.example.com requires no MTA-STS change as long as the new certificate's SAN still covers the hostname.

7.2 Multiple MX hosts

# DNS:
_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260518T120000"

# Policy file:
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
mx: mx3.example.com
max_age: 604800

Multi-MX domain. Each MX is listed explicitly. The order is informational only - selection is driven by DNS MX preference, not by policy order.

7.3 Wildcard MX matching

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

A wildcard *.mail.example.com entry matches a single leftmost label (edge1.mail.example.com, edge2.mail.example.com) but NOT a deeper-nested host (a.edge1.mail.example.com). Useful for Office 365 / Google Workspace tenant MX shapes that use a generated leftmost label.

7.4 Testing-mode rollout

version: STSv1
mode: testing
mx: mail.example.com
max_age: 86400

Initial rollout. max_age: 86400 (1 day) keeps the iteration loop short while operators review TLS-RPT reports. Switch to mode: enforce with max_age: 604800 only after a few weeks of clean reports.

7.5 Retract a policy

# DNS keeps a record so caches expire:
_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260518T180000"

# Policy file:
version: STSv1
mode: none
max_age: 86400

Publishing mode: none tells senders to treat the domain as having no MTA-STS policy. Crucially, keep the DNS record in place for at least max_age of the previous policy so cached enforce policies expire cleanly instead of locking out senders that did not see the retraction.

7.6 Companion TLS-RPT record

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

TLS-RPT (RFC 8460) is the operational feedback loop for MTA-STS. Publish it at the well-known label _smtp._tls with an rua= destination (a mailto: address or a https: endpoint that accepts the JSON report). DMARC Analyzer ingests TLS-RPT reports alongside DMARC aggregate reports - see the TLS-RPT guide for the full report format.

8. MTA-STS best practices

• Always start in mode: testing. Run for at least 4 weeks while watching TLS-RPT. Switching straight to enforce is the leading cause of self-inflicted MTA-STS outages.
• Publish TLS-RPT alongside MTA-STS from day one. Without TLS-RPT, an enforce policy failure is invisible - mail simply does not arrive and there is no report. See help_tls_rpt_explained.php.
• Use a real certificate on mta-sts.<domain>. Public-PKI roots only - self-signed certs do not validate. Let's Encrypt is the typical zero-cost choice. Automate renewal with certbot or acme.sh.
• Change the DNS id= on every policy change. The id is the cache key. If operators update the HTTPS policy file but forget to bump id=, senders with a cached policy continue using the stale rules for up to max_age seconds.
• Pick conservative max_age values during rollouts, long ones for steady state. Start at 86 400 (1 day) so misconfigurations bounce out of caches quickly; move to 604 800 (1 week) or higher once enforce is stable.
• List every legitimate MX in mx: entries. A missing MX in enforce mode causes every send to that MX to be refused. Audit the recipient's MX list from external resolvers (not just the authoritative server) before committing to enforce.
• Match the certificate SAN to the MX hostname. MTA-STS validates the TLS certificate hostname against the mx: entries, not the recipient domain. example.com is irrelevant on the certificate; what matters is that mail.example.com (or whatever the MX is) appears in the SAN.
• Watch DNSSEC-on-MX cases. If any of your MX hosts have published TLSA records, DANE-supporting senders prefer DANE. Keep the TLSA records and the MTA-STS policy consistent (same hostnames, compatible TLS certificate chains) to avoid one mechanism delivering while the other refuses.
• Monitor the mta-sts.<domain> HTTPS endpoint. A 5xx error or expired certificate on that subdomain causes senders to fall back to whatever cached policy they have - if the cache window is short, mail starts bouncing. Add the endpoint to your standard uptime monitoring.
• Plan retractions through mode: none, not by deleting the DNS record. Deleting the DNS record leaves senders with cached enforce policies until their max_age expires. Publishing mode: none explicitly tells supporting senders to discard the cache.

9. Common MTA-STS mistakes

• Going straight to enforce. Without a testing phase, the operator has no visibility into the senders that will start bouncing. Always run testing with TLS-RPT for several weeks first.
• Forgetting to bump the id= tag. Operators update the policy file but leave the DNS id unchanged; senders keep using the cached old policy for up to max_age. Treat the DNS id and the policy file as a single atomic deploy.
• Self-signed certificate on mta-sts.<domain>. The MTA-STS trust anchor is the public web PKI; self-signed certs fail validation and the policy fetch fails. Always use a CA-issued certificate.
• HTTP redirect instead of HTTPS direct. The policy URL MUST be https://. RFC 8461 forbids following any HTTP 3xx redirect when fetching the policy. Serve directly over HTTPS.
• Missing a legitimate MX from mx: entries. The operator's documented MX list is out of date; a hosted-helpdesk MX or a backup-MX still accepts mail and now fails policy. Always enumerate the actual MX records from public resolvers before locking down.
• Using DNS wildcard for the _mta-sts record itself. Only one MTA-STS record is meaningful per domain; _mta-sts.* wildcards cause undefined behaviour. Publish the record for each domain explicitly.
• Setting max_age: 0. Some operators try to "disable" a policy via max_age: 0 - RFC 8461 allows the value (max_age is a non-negative integer), but it does not retract the policy. Retract via mode: none instead.
• Publishing the DNS record without the HTTPS policy file. Senders see the DNS record, fetch the policy URL, get a 404, and treat the policy as broken. Deploy in the opposite order: HTTPS file first, then DNS record.
• Confusing MTA-STS with DMARC. MTA-STS protects transport; DMARC protects message authentication. They are independent controls and both should be deployed.

10. MTA-STS troubleshooting

Mail to my domain is bouncing with TLS errors after I switched to mode: enforce

Switch back to mode: testing immediately (bump the DNS id= at the same time so caches refresh). Review the last 24-48 hours of TLS-RPT reports for the failure reason - the most common causes are a missing mx: entry, a certificate SAN that does not cover the MX hostname, or a recently rotated certificate that has not propagated to all MX hosts.

Senders never fetch the policy file

Verify the DNS record exists with dig +short txt _mta-sts.<domain> and that it starts with v=STSv1;. Then test the HTTPS endpoint with curl -v https://mta-sts.<domain>/.well-known/mta-sts.txt - confirm a 200 response, a valid public-PKI certificate, and the Content-Type: text/plain header.

The DNS record exists but dig +short txt _mta-sts.<domain> returns nothing

Some DNS providers split the _mta-sts label across multiple records or stash it on the apex. Confirm with dig +trace that the authoritative server returns the record. Also check that the TXT value is not split across multiple quoted strings without proper concatenation.

Certificate validation fails on mta-sts.<domain>

Check the certificate chain order with openssl s_client -connect mta-sts.<domain>:443 -servername mta-sts.<domain>. The full intermediate chain must be served, and the leaf certificate's SAN must contain mta-sts.<domain>.

Policy fetch returns 200 but TLS-RPT still reports policy errors

Confirm the file uses LF (or CRLF) line endings with key: value format (colon- space-value), declares a valid version: STSv1 as the FIRST line, and ends each line with a newline. Some editors silently emit BOM (byte-order-mark) bytes at the file head which break the version-line parser.

I rotated the certificate and now senders are refusing delivery

If the new certificate's SAN no longer matches an mx: entry, MTA-STS refuses delivery. Either restore the SAN to cover the listed MX hostname, or update the mx: entries in the policy file AND bump the DNS id= tag so senders refetch.

How do I verify my MTA-STS deployment end-to-end?

Use a free third-party validator (Aykira MTA-STS tester, CheckTLS, DMARC Analyzer's Domain Security Checker), then confirm an end-to-end mail flow by sending from a TLS-RPT-supporting sender (Google Workspace, Microsoft 365, Postmark, SparkPost) and watching the next-day TLS-RPT report.

11. Frequently Asked Questions

What is MTA-STS?

MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) is a DNS- and HTTPS-based mechanism that lets a receiving domain publish a policy requiring that inbound SMTP connections use authenticated TLS. Sending mail servers fetch the policy from a well-known HTTPS URL on the recipient domain and refuse to deliver mail over a plaintext or unauthenticated session when the policy is in enforce mode.

How is MTA-STS different from STARTTLS?

STARTTLS (RFC 3207) opportunistically upgrades an SMTP connection to TLS but provides no protection against a downgrade attack: a network attacker can strip the STARTTLS advertisement and the session falls back to plaintext. MTA-STS layers a policy on top of STARTTLS that tells sending servers TLS is mandatory, the certificate must validate against the public PKI, and the hostname must match one of the declared MX hosts. A sender that supports MTA-STS refuses to deliver mail when the TLS requirements are not met.

What does an MTA-STS DNS record look like?

An MTA-STS DNS record is a TXT record at _mta-sts.<domain> containing two tags: v=STSv1 and id=<policy-id>. A typical record is: _mta-sts.example.com. IN TXT "v=STSv1; id=20260518T120000" - declaring the MTA-STS version and a policy identifier that changes whenever the HTTPS policy file is updated.

Where is the MTA-STS policy file served from?

The MTA-STS policy file is served at https://mta-sts.<domain>/.well-known/mta-sts.txt over HTTPS with a certificate that validates against the public PKI. The file is plain text with one key: value pair per line, declaring version, mode, mx hosts, and max_age (cache lifetime in seconds). Sending servers fetch the policy and cache it for up to max_age seconds.

What are the three MTA-STS policy modes?

MTA-STS defines three modes: none (no policy in effect - used to retract a previous policy), testing (senders evaluate the policy and report failures via TLS-RPT but still deliver the mail), and enforce (senders refuse to deliver mail over a TLS session that fails the policy). The migration path is none → testing → enforce, with TLS-RPT enabled throughout so the domain owner can detect misconfiguration before enforcement bites.

What is the difference between MTA-STS and DANE?

Both MTA-STS (RFC 8461) and DANE for SMTP (RFC 7672) protect SMTP transport from downgrade attacks, but use different trust anchors. MTA-STS trusts the public web PKI - the receiving server's certificate must chain to a CA in the standard root store, and the policy is fetched over HTTPS. DANE trusts DNSSEC - the recipient publishes a TLSA record signed by DNSSEC declaring the expected certificate or public-key hash. DANE requires DNSSEC on the recipient side; MTA-STS does not. The two mechanisms coexist - a sender that supports both prefers DANE when a TLSA record is present and falls back to MTA-STS otherwise.

How do I monitor MTA-STS deployment?

Pair MTA-STS with TLS-RPT (RFC 8460) - the SMTP TLS Reporting standard. Publish a TLS-RPT DNS record at _smtp._tls.<domain> declaring a mailto: or https: report destination, and senders that support TLS-RPT will send daily JSON reports describing successful TLS sessions, certificate failures, STARTTLS failures, and policy lookup errors. DMARC Analyzer ingests these reports alongside DMARC aggregate reports so you can track MTA-STS rollout health in one dashboard.

12. Related guides

• DMARC explained - the policy + reporting standard for message authentication. MTA-STS protects transport; DMARC protects authentication. Deploy both.
• DKIM-Signature header anatomy (byte-level field reference) - the byte-level reference for the DKIM-Signature: header that rides INSIDE the TLS-encrypted SMTP session this pillar's policy enforces — the orthogonal-trust-models companion to this page. Where MTA-STS authenticates the TRANSPORT (does the receiving MX present a publicly-trusted certificate matching the connected hostname, per the /.well-known/mta-sts.txt policy file's mx: directive?), DKIM authenticates the MESSAGE (does the cryptographic signature in the DKIM-Signature header validate against the public key at <selector>._domainkey.<d-tag> per RFC 6376 §3.5?). A message that traverses an MTA-STS-enforced transport gives the receiver TWO independent trust signals: the TLS-handshake authentication of the sending MTA's hostname (MTA-STS) AND the cryptographic authentication of the signing domain claimed in the DKIM-Signature d= tag (DKIM). Read this when understanding what trust signal MTA-STS does NOT provide: MTA-STS verifies the identity of the receiving MX, not the identity of the sending domain — a message can pass MTA-STS (delivered to the right receiving MX over enforced TLS) but fail DKIM (the DKIM-Signature header's body hash mismatched after a content-modifying gateway rewrote the body, or the b= signature value failed to verify after a header-rewriting gateway broke canonicalisation). The two protocols protect DIFFERENT attack surfaces: MTA-STS prevents on-path TLS downgrade and MX-substitution attacks; DKIM prevents in-transit message-content tampering and From-header forge (in combination with DMARC identifier alignment). Deploy both and the receiver gets transport-layer trust (the MX was the right MX) plus message-layer trust (the message content was not tampered with after the signing MTA).
• TLS-RPT explained - SMTP TLS Reporting (RFC 8460), the operational feedback channel that surfaces MTA-STS policy failures. Deploy alongside MTA-STS.
• DMARC troubleshooting — the SYMPTOM-DRIVEN-DMARC-FAIL-DIAGNOSTIC- LADDER companion to this MTA-STS transport- security pillar. Where THIS page documents the MTA-STS policy-publication discipline (the RFC 8461 _mta-sts.<domain> DNS TXT record + the mta-sts.<domain> HTTPS policy-host + the per-domain mta-sts.txt hostname-glob list + the testing-vs-enforce mode progression), the DMARC-troubleshooting spoke is the STRUCTURAL DOWNSTREAM CONSUMER of the MTA-STS publication outcome on a structurally- distinct diagnostic axis — DMARC's application-layer authentication evaluation and MTA-STS's transport-layer encryption- enforcement evaluation produce different evidence streams (RUA aggregate XML + forensic RUF AFRF vs TLS-RPT JSON-aggregate) that operators must correlate when the DMARC-troubleshooting ladder reaches a Pattern-6 mailbox-provider-specific delivery- failure symptom. Four per-MTA-STS-DMARC- troubleshooting-coupling dimensions: (i) TRANSPORT-LAYER-TLS-NEGOTIATION-FAILURE-AS- ORTHOGONAL-TO-APPLICATION-LAYER-DMARC-FAIL attribution (a Pattern-6 delivery-failure symptom can be EITHER DMARC=fail at the application layer OR TLS-handshake-fail at the transport layer OR both; the DMARC- troubleshooting spoke's diagnostic ladder explicitly cross-references the TLS-RPT JSON-aggregate evidence stream this page introduces to distinguish the two failure axes), (ii) PREMATURE-ENFORCE-MODE-PROMOTION- ROOT-CAUSE attribution (operators who promote MTA-STS from testing-mode to enforce-mode before catching all MX-glob misses observe silent inbound delivery failures correlated with DMARC=fail RUA rows — the spoke's diagnostic ladder walks the operator through the MTA-STS policy audit + TLS-RPT pass-through review as the canonical pre-promotion checklist), (iii) PER-RECEIVER-MTA-STS-ENFORCEMENT- VARIANCE attribution (Gmail and Microsoft 365 enforce MTA-STS policies more aggressively than smaller receivers — when the DMARC-troubleshooting ladder reaches a Pattern-6 receiver-specific symptom, the operator must factor per-receiver MTA-STS- enforcement variance into the root-cause attribution), (iv) HTTPS-POLICY-HOST- CERTIFICATE-EXPIRATION-CASCADE attribution (operators whose MTA-STS policy-host TLS certificate expires observe a structurally- distinct silent inbound delivery failure cascade — the DMARC-troubleshooting spoke's diagnostic ladder catalogues the per-receiver cert-expiration-response variance and the TLS-RPT JSON-aggregate evidence row signature that surfaces this root cause). Critical when this MTA-STS guide's reader observes inbound delivery failures whose DMARC RUA evidence stream contains DMARC=fail rows correlated with TLS-RPT transport-layer-failure rows — the DMARC-troubleshooting spoke's symptom- driven diagnostic ladder is the canonical next step in the orthogonal-failure-axis root-cause attribution workflow.
• Reverse DNS PTR records and FCrDNS — the MTA-STS-POLICY-AT-SENDER-MX-VS-PTR- CERT-CN-ALIGNMENT companion to this MTA-STS transport-security pillar. Where THIS page documents the MTA-STS protocol mechanics (the mta-sts.txt policy file at https://mta-sts.<domain>/.well- known/mta-sts.txt + the _mta-sts.<domain> TXT record + the mode: enforce gate at sender-side connection-time TLS enforcement), the reverse-DNS-PTR spoke is the MX-IP-TO-MX-ORGANIZATIONAL-IDENTITY resolution reference that MTA-STS-enforcing senders consult when validating the receiver-MX cert's CN/SAN against the connection-time peer-identity. The MTA-STS-POLICY-AT-SENDER-MX-NEEDS-PTR- VALIDATION cross-reference establishes FOUR structurally-distinct MX-identity- verification dimensions where PTR resolution is the load-bearing pivot: (i) MX-host PTR-vs-cert-CN match at MTA-STS-enforce-mode connection boundary — RFC 8461 §4.1 requires the sender to validate the receiver-MX cert's CN/SAN matches the MX-host name from the policy file's mx: directives; some sender-side MTA-STS implementations augment cert validation with a defensive PTR check (resolve the connection IP via PTR → confirm the PTR-derived hostname matches the cert's CN/SAN) to detect cert-issuance-against- wrong-hostname attacks where an attacker with a valid cert for an unrelated host attempts to intercept the connection; (ii) per-MX FCrDNS posture as deliverability-prerequisite — FCrDNS (Forward-Confirmed-Reverse-DNS) requires the receiver's MX-host to publish A-record + matching PTR-record that bidirectionally resolve; receivers publishing MTA-STS policy must ALSO maintain FCrDNS on their MX-host IPs because sender-side TLS validation often falls back to PTR-derived hostname when the cert's CN/SAN format is ambiguous; the reverse-DNS-PTR spoke is the canonical FCrDNS-posture-deployment reference receivers consult when deploying MTA-STS; (iii) policy-host vs MX-host PTR-divergence detection during MTA-STS deployment — MTA-STS deployment introduces a NEW publication host (mta-sts.<domain> for the policy file via HTTPS) DISTINCT from the MX-host (e.g., mx1.<domain> for SMTP connections); operators auditing the deployment must verify the policy-host's PTR (HTTPS-serving infrastructure) does NOT collide with the MX-host's PTR (SMTP- serving infrastructure); PTR-divergence between the two publication boundaries is a deployment-correctness signal the reverse-DNS-PTR spoke documents at the topology-level; (iv) connection-time defensive PTR check at MTA-STS-enforce-mode boundary — at mode: enforce gate, sender-side MTA-STS implementations refuse the connection on cert-validation failure; some implementations augment the cert-only check with a defensive PTR-lookup on the connection IP to detect specific MITM attack patterns (the cert validates because the attacker has a valid cert for an attacker-controlled hostname, but the PTR resolves to an unexpected organization — the PTR mismatch surfaces the MITM pre-connection-completion); the reverse- DNS-PTR spoke documents the FCrDNS posture whose verification is the prerequisite for this defensive PTR-check pattern to work bidirectionally. Read the reverse-DNS-PTR spoke alongside the MTA-STS deployment guide when authoring the mta-sts.txt policy file's mx: directives — the spoke documents the per-MX FCrDNS posture prerequisite that the four MX-identity- verification dimensions above all structurally depend on.
• DMARC reporting pipeline — the MTA-STS-TRANSPORT-LAYER-AS-SIBLING- OF-DMARC-APPLICATION-LAYER-REPORTING- PIPELINE companion documenting the receiver-side aggregate-report ingestion pipeline whose transport-layer sibling the TLS-RPT JSON-report-format spoke below makes observable for the MTA-STS policy-enforcement layer THIS page documents. Where THIS page documents the TRANSPORT-LAYER policy-enforcement mechanics (the RFC 8461 publish-discover- enforce three-step protocol — DNS _mta-sts.<domain> TXT signal-record at the publisher, HTTPS /.well-known/mta-sts.txt policy file at the mta-sts.<domain> host, receiver-side policy fetch with in-memory caching governed by the max_age seconds value, and the per-MX-host TLS-handshake enforcement the receiver performs against the published mx:-list at SMTP- connection time), the reporting-pipeline spoke documents the structurally- analogous APPLICATION-LAYER reporting pipeline that surfaces DMARC enforcement outcomes the same way TLS-RPT surfaces MTA-STS-policy-violation outcomes — receiver-side report-generator → DNS resolution of the publisher's rua= URI → MIME-attached SMTP / HTTPS delivery → operator-side inbound mailbox / webhook → MIME-part extraction → gzip-or-zip decompression → XML schema-validation → row-by-row ingestion. The two reporting pipelines — the TLS-RPT JSON pipeline that surfaces the TRANSPORT-LAYER MTA-STS-policy- violation telemetry this page's MTA-STS enforcement produces, and the DMARC RUA XML pipeline that surfaces the APPLICATION-LAYER DMARC-authentication- verdict telemetry the message-content enforcement layer produces — are STRUCTURALLY ANALOGOUS sibling pipelines that the operator runs side-by-side to get full-stack telemetry: TLS-RPT JSON reports tell the operator which TRANSPORT-LAYER MTA-STS policy violations the receiver observed (cleartext-fallback, certificate-mismatch, expired-certificate, STARTTLS-strip), and DMARC RUA XML reports tell the operator which APPLICATION-LAYER DMARC-authentication- verdicts the receiver issued (alignment- pass, alignment-fail-but-DKIM-passes, SPF-fail, full-fail). Read the reporting-pipeline spoke alongside this MTA-STS pillar when scoping the full-stack telemetry posture for a production-deployed mail-authentication stack — the two pipelines together close the end-to-end transport-and-application- layer authentication-observability loop that THIS MTA-STS pillar's transport- layer enforcement and the DMARC pillar's application-layer enforcement respectively populate. Closes the MTA-STS-cluster ↔ DMARC-reporting-pipeline bridge whereby the operator-side ingestion of the DMARC RUA XML report- stream is the APPLICATION-LAYER STRUCTURAL TWIN of the TLS-RPT JSON report-stream THIS MTA-STS pillar's transport-layer enforcement is itself the subject of.
• TLS-RPT report format (RFC 8460 §4 JSON schema) - the operational reference for diagnosing the very MTA-STS failure-types this pillar's policy file produces at the receiver side. Where the TLS-RPT explained page above introduces the reporting channel as a concept, the report-format page documents the byte-level structure of the JSON report payloads operators must parse to act on MTA-STS deployment issues: the RFC 8460 §4 top-level object (organization-name, date-range, contact-info, report-id, policies), the policies[].policy object with policy-type = sts (vs tlsa / no-policy-found), policy-string carrying the verbatim fetched policy text, policy-domain + mx-host, the summary with success and failure session counts, the failure-details array with per-failure result-type, sending-MTA IP, receiving-MX hostname, failure-reason-code, timestamp, and session-count fields, and the 13 canonical result-type values - of which FOUR are MTA-STS-specific (sts-policy-fetch-error when the policy URL is unreachable, sts-policy-invalid when the fetched file failed RFC 8461 §3.2 grammar validation, sts-webpki-invalid when the policy host's TLS chain failed public-PKI validation, and certificate-host-mismatch when the MX target's certificate did not match the connecting hostname). Read this once you have deployed MTA-STS in testing mode per this pillar's burn-in workflow and TLS-RPT reports start arriving in your ingestion mailbox - this page is the byte-level reference for parsing and acting on each report-payload field.
• TLS-RPT DNS record syntax (RFC 8460 §3) - the byte-by-byte syntax-layer reference for the _smtp._tls.<domain> TXT record an MTA-STS operator publishes to RECEIVE the JSON failure reports the report-format spoke above documents. The TLS-RPT explained pillar entry above introduces the reporting channel as a concept; the report-format spoke above documents the JSON payload structure; this record-syntax spoke completes the three-page TLS-RPT cluster by documenting the publishing-side DNS record itself — the tag grammar (v=TLSRPTv1 floor case sensitive, rua=mailto: / rua=https: destination URIs, the !-separated multi-URI list semantics, the optional size_limit= extension that caps per-report payload size), the cross-domain authorisation contract for off-domain rua URIs (RFC 8460 §3.2 well-known-token authorisation that prevents amplification attacks via third-party reporting destinations), and the 255-octet TXT-string chunking rule for DNS providers that auto-split or require manual chunking. Read this once you have decided to instrument MTA-STS with TLS-RPT per this pillar's burn-in workflow — this is the byte-level reference for the DNS record an operator publishes ALONGSIDE the _mta-sts discovery record documented in section 4 of this pillar. Without TLS-RPT published, MTA-STS deployment is flying blind: there is no operational feedback channel for diagnosing the sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid / certificate-host-mismatch failure types this pillar's policy can produce at the receiver side.
• MTA-STS vs DANE for SMTP - the comparison deep-dive sibling spoke: RFC 8461 vs RFC 7672 trust-anchor difference, the canonical DANE-EE TLSA deployment shape, provider support reference, the RFC 7672 §1.3 coexistence rule, decision matrix for which to deploy first, migration paths.
• DANE for SMTP (RFC 7672) explained - the sibling-protocol pillar this MTA-STS pillar's RFC 7672 §1.3 coexistence rule names as the alternative trust-anchor model. Where this pillar walks through the public-PKI + HTTPS-fetched-policy-file model (mailbox providers validate the policy host's TLS chain against the Mozilla / Microsoft / Apple root stores, then honour the mx + mode + max_age directives), the DANE pillar documents the DNSSEC-bound TLSA-record trust-anchor model that pins the MX target's certificate or public-key fingerprint directly in DNS — no separate HTTPS fetch, no public-PKI dependency, but a hard requirement for end-to-end DNSSEC across the registry + parent zone + your authoritative nameserver. Read this when you are choosing between MTA-STS and DANE for your inbound TLS-enforcement strategy (the comparison page above is the side-by-side decision matrix; the DANE pillar is the same depth of operational walkthrough this MTA-STS pillar provides but for the TLSA-record path). The DANE pillar covers 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, the 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 zone makes the TLSA RRset bogus and senders fall back to opportunistic TLS), the RFC 7672 §2.2.1 receiver-side algorithm for TLSA-record retrieval and validation, the certificate / key rotation procedure (publish new TLSA record alongside old, wait for max(zone-TTL, signature-validity) overlap, deploy new certificate, retire old TLSA after a second overlap window), and the per-provider deployment reference covering the major mailbox providers that honour DANE inbound as of writing. The two protocols are deliberately deployable in parallel per RFC 7672 §1.3 — operators publishing both get the union of sender coverage (MTA-STS honoured by Gmail, Yahoo, Microsoft; DANE honoured by major German / Dutch / Scandinavian ISP mailboxes that have made DNSSEC mandatory at the registry level) at the cost of maintaining two trust-anchor publication paths.
• MTA-STS policy file syntax (RFC 8461 §3.2) - the byte-by-byte syntax-layer sibling spoke off this pillar covering the /.well-known/mta-sts.txt policy file format. Where this pillar tells you the protocol HAS a policy file and that mailbox providers fetch it over HTTPS, the policy-syntax page documents the exact byte-level grammar that mailbox providers will validate before applying the policy: the four canonical keys (version: STSv1, mode: enforce|testing|none as a case-sensitive token enum, mx: entries with single-label wildcard semantics that match mail.example.com but NOT sub.mail.example.com and NOT the apex, max_age: in seconds with RFC 8461 floor and recommended ceiling), the no-BOM constraint (Windows Notepad default produces UTF-8 BOM that silently breaks the version line match — the #1 silent-rejection cause), the no-comments rule (any line starting with # causes the entire policy to be rejected — structurally different from DNS records that permit them), 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 for zero-downtime policy updates, six canonical example policy files, and ten common operator mistakes that produce TLS-RPT sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid failure reports. Read this once you have the pillar's protocol model and need the operational reference for authoring or auditing the actual /.well-known/mta-sts.txt file the protocol relies on.
• DMARC for hybrid Exchange (on-premises + Exchange Online) — the HYBRID-EXCHANGE-DUAL-OUTBOUND-PATH- MTA-STS-RECEIVER-POLICY-HONOR-CONSUMER companion to this MTA-STS protocol pillar. Where THIS page documents the RFC 8461 receiver-publishes-policy-at-mta-sts-host + sender-fetches-via-HTTPS-and-caches + sender-enforces-STARTTLS-on-MX-matching- mx-directive contract — i.e. the TRANSPORT- LAYER-MTA-STS-RECEIVER-POLICY-HONOR side of the SMTP transport-security protocol — the DMARC-for-hybrid-Exchange spoke is the HYBRID-EXCHANGE-DUAL-OUTBOUND-PATH-MTA-STS- CONSUMER companion documenting how the receiver-policy-honor discipline gets applied at the TWO independent sending- MTA boundaries a hybrid Exchange topology induces. Concretely, the spoke documents FOUR hybrid-Exchange-MTA-STS-dual-egress- coordination dimensions: (i) the on-premises Exchange Send Connector and Exchange Online outbound queue are TWO STRUCTURALLY-INDEPENDENT sending MTAs that must each honor receiver MTA-STS policies independently — the on- prem Exchange transport stack performs its own MTA-STS policy fetch via https://mta-sts.<receiver-domain>/.well-known/mta-sts.txt when the on-prem Send Connector delivers directly to external receivers (bypassing Centralized Mail Transport), while Exchange Online's outbound queue maintains its OWN policy cache against the same receiver domains — the dual sending-MTA boundaries produce TWO independent MTA-STS policy-cache lifecycles whose TTL expirations, refresh failures, and cleartext-fallback dispositions the operator must monitor at both locations; (ii) Centralized Mail Transport (CMT) collapses dual-MTA-STS-policy-honor to a single cloud-side policy cache — when the operator enables CMT, all outbound mail relays through Exchange Online which becomes the SOLE sending MTA evaluating receiver MTA-STS policies, and the on-prem Send Connector becomes operationally INVISIBLE to receiver-side MTA-STS enforce-mode policies (the trip from on-prem to Exchange Online is an internal-trust hop that does not consult receiver MTA-STS) — the operator inherits the single-policy-cache model THIS page documents for cloud-only senders; (iii) classic-hybrid dual-outbound topology requires per-egress-path TLS-RPT failure-attribution coordination — when on-prem remains a parallel outbound boundary, MTA-STS failure reports (the sts-policy-fetch-error, sts-webpki-invalid, starttls-not-supported result-types in the RFC 8460 JSON schema) arrive AT THE RECEIVER from BOTH on-prem-direct delivery attempts AND cloud-relayed delivery attempts under the same Friendly-From-header domain, and the operator must correlate per- sending-IP-source-attribution (Exchange Online egress IP range vs operator's on-prem perimeter NAT pool) to disambiguate which sending MTA produced the failure; and (iv) HCW (Hybrid Configuration Wizard) does NOT configure MTA-STS policy fetching on either side — HCW configures the bidirectional Send / Receive connector pair with TLS mutual authentication for the INTRA-HYBRID hop between on-prem and cloud, but does NOT configure either side's outbound MTA-STS policy-fetch client, does NOT publish the operator's OWN MTA-STS policy at https://mta-sts.<your-domain>/.well-known/mta-sts.txt (for inbound mail from external senders), and does NOT configure TLS-RPT reporting at _smtp._tls.<your-domain> — every aspect of the operator's MTA-STS deployment THIS page documents must be assembled AFTER HCW completes, applied to whichever side(s) the operator chooses as outbound boundary AND to the operator's own published-policy surface for inbound. Read the DMARC-for-hybrid- Exchange spoke alongside this MTA-STS pillar when planning MTA-STS deployment for a hybrid Exchange portfolio: the receiver-policy-honor contract THIS page documents applies at BOTH sending- MTA boundaries (in classic-hybrid) or ONLY at the cloud boundary (with CMT enabled) — a deployment-shape decision the spoke makes explicit.
• MTA-STS for Microsoft 365 - the provider-specific deployment walkthrough for Exchange Online tenants: where to host the /.well-known/mta-sts.txt policy file when MX is <tenant>.mail.protection.outlook.com, the canonical mx: list (a single wildcard *.mail.protection.outlook.com entry covers all M365 MX targets), the Azure App Service / Cloudflare Pages / IIS hosting options for the policy file with the HTTPS public-PKI fetch contract from RFC 8461 §3.3, the testing-mode burn-in workflow paired with TLS-RPT, and the M365-specific gotchas (the onmicrosoft.com vanity MX, the EOP opportunistic-TLS-by-default outbound posture, and the absence of DANE for inbound that makes MTA-STS the only TLS-enforcement option a sender to M365 can rely on). Read this when you have decided MTA-STS is the right choice for your tenant and need the operational sequence end-to-end.
• DMARC for Microsoft 365 - documenting the canonical M365-tenant application-layer DMARC publication discipline whose four operational dimensions couple back to the transport-layer MTA-STS publication discipline THIS pillar documents at the same per-tenant deployment boundary: (i) shared per-tenant DNS-zone publication-cadence coordination — the _dmarc.<tenant> TXT record (DMARC policy) and the _mta-sts.<tenant> TXT record (MTA-STS policy ID) are both published in the same M365 vanity-domain DNS zone via the same Azure portal / DNS provider surface, with the same propagation TTL semantics and the same rollback drill; (ii) application-layer message- identity (DMARC) vs transport-layer channel- integrity (MTA-STS) defence-in-depth pairing — DMARC enforces SPF + DKIM alignment on the message contents (RFC 7489 §3) while MTA-STS enforces TLS on the channel that carries the message (RFC 8461 §3), and a complete M365-tenant security posture publishes BOTH (DMARC at p=quarantine or p=reject + MTA-STS at mode: enforce) so attackers cannot bypass either layer; (iii) parallel per-tenant aggregate- evidence reporting-pipeline parity — the DMARC RUA mailbox declared at _dmarc.<tenant> rua=mailto: structurally parallels the TLS-RPT mailbox declared at _smtp._tls.<tenant> rua=mailto: THIS page's burn-in workflow references; both feed per-day per-receiver per-tenant evidence streams the M365 admin co-locates in the same RUA-aggregation pipeline; and (iv) shared M365 MX-target infrastructure coordination — the *.mail.protection.outlook.com wildcard MTA-STS mx: entry THIS page documents at line 1716 covers the same EOP infrastructure whose include:spf.protection.outlook.com SPF macro + selector1._domainkey.<tenant> DKIM selector this DMARC-for-M365 spoke documents at the application layer, making the two spokes the canonical M365-tenant deployment-pair off this pillar.
• MTA-STS for Google Workspace - the Workspace counterpart to the M365 deployment spoke above; completes the MTA-STS provider-deployment pair off this pillar. Walks through the four-step deployment on a Workspace tenant: the aspmx.l.google.com / alt1-4.aspmx.l.google.com MX enumeration in the mx: directive for legacy tenants (or the single smtp.google.com entry for tenants migrated to the simplified MX configuration), the Workspace-aligned external HTTPS hosting options (Firebase Hosting and Cloud Run for instant custom-domain HTTPS, Cloud Storage + Cloud CDN with Cloud Load Balancing for tenants with existing GCP infrastructure), the absence of any Admin Console / Postmaster Tools MTA-STS panel, the testing-mode burn-in workflow paired with TLS-RPT, Gmail's role as an MTA-STS-honoring sender since 2018, and the Workspace-specific 604800 max_age honoring cap (Gmail-as-sender silently caps cache lifetime at one week regardless of higher values published). Read this when you have decided MTA-STS is the right choice for your Workspace tenant and need the operational sequence end-to-end.
• MX records explained - the foundational DNS-record reference for the addressing layer MTA-STS protects. The mx field in the MTA-STS policy file (the list of hostnames a sender will connect to over TLS) is a literal mirror of the domain's MX record set: the MTA-STS policy is meaningless without understanding what the published MX records actually are. Read this when authoring or reviewing your first MTA-STS policy file - the policy must list every active MX target hostname (RFC 8461 §3.2) or senders enforcing the policy will reject delivery to mismatched connections. Covers MX priority semantics, the no-CNAME-as-MX-target rule (RFC 2181 §10.3) that breaks MTA-STS validation when violated, MX target IPv4 / IPv6 resolution for the TLS connection, TTL recommendations that should be at least as long as the MTA-STS max_age, and the per-provider deployment reference covering the canonical MX hostnames you must list for Google Workspace, Microsoft 365, and the major transactional ESPs.
• DNS propagation explained — the DNS-INFRASTRUCTURE-CACHE-AGING companion to this MTA-STS pillar's DUAL DNS + HTTPS publication mechanism. Where THIS page documents the MTA-STS protocol's transport-security primitive (RFC 8461: the _mta-sts.<domain> TXT record's v=STSv1; id=<N> policy-version pointer, the https://mta-sts.<domain>/.well-known/mta-sts.txt policy file's mode + mx + max_age directives, the policy-rotation cadence and the testing → enforce mode advance), the DNS-propagation spoke documents the DNS-INFRASTRUCTURE-LAYER behaviour that determines WHEN a newly-published or rotated _mta-sts TXT-record id= value becomes OBSERVABLE across the global senders that cache the prior policy via per-record TTL: per- record TTL semantics (RFC 1035 §3.2.1 + RFC 2181 §8), the resolver-cache minimum + maximum cap quirks (Cloudflare 1.1.1.1 300-second negative-cache floor, Google 8.8.8.8 21 600-second TTL cap, corporate- resolver 1800-second minimums), and the diagnostic workflow operators run when a policy-rotation (id= bump from old to new) appears to not take effect at remote senders despite the operator confirming the new TXT record is present in the authoritative zone: dig / kdig directly against the authoritative nameservers ("dig _mta-sts.example.com TXT @ns1.your-dns-provider.com") to confirm publication, then dig with +norecurse against multiple recursive resolvers to confirm what each cache believes, then the web-based propagation checker for the global cache snapshot. Read the propagation spoke when an MTA-STS policy-mode-change rotation (testing → enforce, or a fresh id= bump) appears to be ignored by remote senders for the first 24-72 hours after the rotation event — DNS propagation of the TXT-record id= bump is almost always the explanation, not a malfunctioning receiver-side enforcement engine.
• DMARC for transactional email — the TRANSPORT-LAYER-MTA-STS-AS- CLEARTEXT-STRIPPING-DEFENCE-FOR- TRANSACTIONAL-RECEIPT-PII-IN-FLIGHT companion to this MTA-STS pillar's receiver-side transport-security primitive. Where THIS page documents the RFC 8461 protocol mechanics (_mta-sts.<domain> TXT-record id= pointer + https://mta-sts.<domain>/.well-known/mta-sts.txt policy-file mode: enforce cleartext-fallback-rejection discipline), the transactional-email spoke is the per-message-type deployment companion documenting FOUR transactional-delivery- lifecycle protection dimensions: (i) order-confirmation and receipt delivery → MTA-STS enforce mode prevents cleartext-fallback exfiltration of the per-message recipient PII payload (delivery address, item list, purchase total, payment-instrument-last-four-digits, order ID, fulfilment timeline) by an on-path downgrade attacker intercepting the SMTP DATA phase — the transactional spoke documents WHY the transactional stream is the highest-PII-density operationally- distinct mail stream every operator owns and the receiver-side MTA-STS enforce-mode posture is the dominant TRANSPORT-LAYER protection layer for the per-message recipient's PII payload in flight; (ii) password-reset and account-verification link delivery → MTA-STS enforce mode protects the password-reset-link single-use credential from on-path capture during the seconds-to-minutes delivery window the recipient is actively waiting for — the transactional spoke documents the canonical operator failure pattern (password-reset codes intercepted in transit via SMTP STARTTLS downgrade attack, attacker uses the captured link before the legitimate user, gains account access) and the MTA-STS enforce-mode mitigation that closes the per-message single-use credential in-transit capture window; (iii) two-factor authentication code delivery → MTA-STS enforce mode protects the per-message 6-digit / 8-digit time-bounded TOTP-or-bank-issued OTP from on-path capture during the ~30-second-to-5-minute validity window the recipient must use the code within — the transactional spoke documents the highest-financial-impact MTA-STS enforce-mode use case (bank-issued wire-confirmation OTP, payment- authorisation OTP, ACH-transfer confirmation OTP) where on-path cleartext interception during the narrow validity window enables immediate financial fraud and where sender-side ESPs that DON'T honour MTA-STS enforce-mode on the receiver- side become the structural attack surface; (iv) transactional- stream SLA-vs-deliverability coordination at the transport-layer boundary — MTA-STS enforce mode adds a delivery-failure failure mode at the per-message transport-security boundary that the operator MUST coordinate with the customer-support SLA-tracking discipline — the transactional spoke documents the canonical operator-side blast- radius framework whereby MTA-STS enforce-mode deployment INTRODUCES a new transactional-stream deliverability failure surface (sender MTA refuses cleartext-fallback delivery when receiver MTA presents an invalid / expired / hostname-mismatched certificate; transactional message deferred or bounced; recipient escalates to customer support; support team cannot deliver the message via any cleartext-fallback alternative) and the coordination point between operations engineering, customer support, deliverability monitoring, and the per-tenant MTA-STS-monitoring TLS-RPT JSON ingestion pipeline. Read the transactional-email spoke when deploying MTA-STS enforce mode for an operator whose dominant mail stream is transactional (e-commerce checkout confirmations, SaaS account-lifecycle notifications, bank-transaction alerts, healthcare appointment reminders, fintech KYC-progress updates) — the spoke is the authoritative per-message-type operational reference for the transport-layer-protection-meets- transactional-deliverability-discipline cross-cluster boundary.
• SPF explained - Sender Policy Framework (RFC 7208): the envelope-sender authorisation mechanism. Authenticates the message envelope, not transport.
• SPF include: vs ip4: vs a: vs mx: decision tree — the TRANSPORT-LAYER-MX-ALLOW-LIST- VS-ENVELOPE-LAYER-MX-AUTHORIZATION CROSS-LAYER-MX-PARITY companion to this RFC 8461 MTA-STS pillar. Where THIS page documents the RECEIVE-SIDE SMTP-transport STARTTLS enforcement via the MTA-STS policy-file mx: <hostname-glob> directive that declares which inbound MX servers are authorised to receive TLS-protected mail for the domain, the include-vs-ip4-vs-a-vs-mx decision-tree spoke is the SEND-SIDE ENVELOPE-MAIL-FROM-LAYER companion documenting the FOUR structurally- distinct SPF IP-providing mechanism choices whose mx:<name> and bare mx variants AUTHORISE the SAME MX servers AT THE OPPOSITE END of the message life-cycle: (i) MTA-STS mx: allow-list and SPF mx: mechanism share the DNS MX record as the LOAD-BEARING IDENTITY GROUND-TRUTH — both mechanisms resolve the domain's MX records to a set of hostnames, but MTA-STS uses them as the TLS-CERTIFICATE-MUST-VALIDATE-AGAINST- THIS-NAME allow-list while SPF uses them as the ENVELOPE-MAIL-FROM-MUST- ORIGINATE-FROM-AN-A/AAAA-OF-THIS-NAME allow-list, so any MX-topology change (vendor migration, on-prem-to- cloud cutover, MX hostname rename) flows through BOTH the MTA-STS policy file AND the SPF record and requires synchronised updates at both layers; (ii) the SPF mx: mechanism counts as ONE include-budget hit + N A/AAAA lookups per resolved MX target against the RFC 7208 §4.6.4 ten-DNS-lookup budget, which makes the SPF mx: choice a budget- consequential decision in a way the MTA-STS mx: allow-list is NOT (MTA-STS does not have a DNS-lookup budget — its policy file is fetched once and cached for max_age seconds); (iii) the SPF decision-tree spoke's ip4: / ip6: direct- CIDR-enumeration choice has NO MTA-STS equivalent — MTA- STS only addresses names (the policy-file mx: directive accepts a hostname or wildcard, not a CIDR block), so operators who prefer IP-based envelope-layer authorisation (ip4:198.51.100.0/24) face a STRUCTURAL ASYMMETRY between envelope-IP precision and transport- layer-name authorisation that the decision-tree spoke makes explicit; (iv) the SPF decision-tree spoke's include: delegated-authorization choice has a CROSS-LAYER ANALOGUE in the MTA- STS pattern of OUTSOURCING receive-side MX to a managed provider — a domain whose SPF authors include:spf. protection.outlook.com at the SEND-SIDE typically pairs with an MTA-STS policy file authorising mx: *.mail.protection.outlook .com at the RECEIVE-SIDE, so the OPERATOR'S delegation-to-managed- provider posture is expressed symmetrically at both protocol layers (and conversely a domain that resists include: delegation in SPF often also resists wildcard mx: in MTA-STS). Read the four-IP- providing-mechanism decision-tree spoke alongside this MTA-STS transport-layer-policy pillar when the operator faces an MX-topology migration (vendor cutover, hostname rename, cloud-to-on-prem repatriation) and must coordinate the SEND-SIDE SPF mx: / include: / ip4: / a: mechanism choice with the RECEIVE-SIDE MTA-STS mx: allow-list update so the two protocol-layer commitments remain consistent through the migration window.
• SPF for Microsoft 365 — the TRANSPORT-LAYER-MTA-STS-COMPLEMENT-TO- MESSAGE-IDENTITY-SPF-AUTHORING-FOR-M365-TENANT- RECEIVE-SIDE-EXCHANGE-ONLINE-MX-INFRASTRUCTURE companion documenting the M365-tenant SEND-SIDE SPF-authoring discipline that completes the TRANSPORT-LAYER (MTA-STS) + MESSAGE-IDENTITY (SPF) defense-in-depth posture for Exchange Online tenants. Where THIS page documents the SMTP-RECEIVE-SIDE transport-security enforcement (RFC 8461 STS-policy-file syntax, the _mta-sts TXT-record publication, the .well-known/mta-sts.txt HTTPS-served policy file, the testing / enforce / none policy modes, the max_age cache TTL, the mx-allowlist fingerprinting, the TLS-RPT complement), the SPF-for-Microsoft-365 spoke is the SEND-SIDE MESSAGE-IDENTITY SPF-AUTHORING companion documenting the OUTBOUND-MESSAGE-IDENTITY-AUTHORISATION discipline that runs at the orthogonal protocol layer to MTA-STS. The four-axis MTA-STS-VS-SPF-FOR-M365 comparison exposes the structurally-distinct LAYER-OF-PROTECTION roles: (i) MTA-STS protects the SMTP-CONNECTION INBOUND to the Exchange Online MX (<tenant>-com.mail.protection.outlook.com) against active downgrade attacks (STARTTLS-stripping, MX-record spoofing without DNSSEC) but does NOT validate the envelope-MAIL-FROM authorisation — the SPF-for-M365 spoke documents the complementary envelope-MAIL-FROM authorisation discipline at the message- identity layer, including the include:spf.protection.outlook.com baseline token that authorises Microsoft- managed outbound MTAs and the secondary SaaS-sender include layering; (ii) MTA-STS operates RECEIVE-SIDE at the SMTP transport boundary, SPF-for-M365 operates SEND-SIDE at the message-identity envelope boundary — both are DNS-published policies but live at structurally-distinct OSI layers (transport vs message-identity), and operators deploying MTA-STS at the M365 RECEIVE-SIDE and SPF at the M365 SEND-SIDE achieve defense-in-depth that NEITHER protocol achieves alone; (iii) MTA-STS policy-file misconfiguration produces DELIVERY FAILURE for inbound mail to the M365 tenant; SPF-for-M365 misconfiguration produces DMARC-FAIL for outbound mail from the M365 tenant — the two failure modes are operationally disjoint but BOTH gate the M365-tenant trust-posture and the Gmail Bulk Sender Requirements / Yahoo 2024 enforcement compliance the M365 operator must satisfy; (iv) MTA-STS is policy-published via _mta-sts.<tenant>.<tld> TXT-record + HTTPS-served policy file; SPF-for-M365 is policy-published via the organisation-domain v=spf1 TXT record — operators deploying both MUST maintain consistency: the SPF record's include:spf.protection.outlook.com baseline declares the M365 outbound IP envelope as authorised for envelope-MAIL- FROM use, AND the MTA-STS policy file's mx: *.mail.protection.outlook.com line declares the M365 inbound MX as the only TLS-protected delivery target — both statements are the M365-tenant operator's commitment to the two-layer trust posture and BOTH must be maintained as the M365 infrastructure evolves.
• DKIM explained - DomainKeys Identified Mail (RFC 6376): the cryptographic message signature. Authenticates message content, not transport.
• DKIM cryptography basics (RFC 8301) — the CROSS-PROTOCOL-TRANSPORT-LAYER- PKI-CERTIFICATE-CRYPTOGRAPHY-VS-MESSAGE- LAYER-RSA-OR-ED25519-MESSAGE-SIGNING- CRYPTOGRAPHY-COMPLEMENT companion to this MTA-STS pillar. Where THIS page documents the MTA-STS RFC 8461 transport-layer TLS-handshake cryptography (the mta-sts.<domain> vhost MUST present a public-PKI X.509 certificate chain rooted in a CA/Browser-Forum-baseline-trusted root, signed via RSA-or-ECDSA-with-SHA-256-or- SHA-384, validated against the chain-of- trust at TLS-handshake time per RFC 8461 §3.2 normative semantics; the mode=enforce mode requires SUCCESSFUL public-PKI validation for message delivery), the DKIM cryptography basics spoke is the RFC 8301 message- layer cryptographic-primitive companion whose RSA-with-SHA-256 / Ed25519-with- SHA-256 keypair generation, public-key publication via the p=<base64-pubkey> tag of the <selector>._domainkey. <d-domain> TXT RR, and receiver-side signature verification at message-receive time mirror the public- PKI transport-layer cryptographic primitives THIS page's MTA-STS deployment requires. The CROSS-PROTOCOL-TRANSPORT- LAYER-PKI-CERTIFICATE-CRYPTOGRAPHY-VS- MESSAGE-LAYER-RSA-OR-ED25519-MESSAGE- SIGNING-CRYPTOGRAPHY-COMPLEMENT cross- reference establishes FOUR structurally- distinct cross-layer cryptographic- primitive-and-lifecycle dimensions: (i) asymmetric-keypair-foundation cross-layer parallel — MTA-STS public-PKI uses asymmetric RSA-or-ECDSA keypair (private key on mta-sts.<domain> web server; public key in published X.509 cert) per CA/Browser-Forum-baseline- requirements §6.1.1.3; DKIM message- signing uses asymmetric RSA-or-Ed25519 keypair (private key on outbound MTA; public key in DNS-published TXT RR) per RFC 8301 §3 + RFC 8463; both protocols share the asymmetric-keypair-foundation cryptographic primitive where the private key signs and the public key verifies; (ii) public-key-distribution-via- external-system parallel — MTA- STS public-key distribution is via the public-PKI X.509 chain (root CAs embedded in OS/browser trust stores, intermediate CAs included in the cert chain, leaf cert presented at TLS handshake); DKIM public-key distribution is via DNS TXT RR ( <selector>._domainkey. <d-domain>); both protocols share the public-key-distribution-via- external-discoverable-system pattern, with MTA-STS via WebPKI chain and DKIM via DNS — but the structural primitive is the same (publisher publishes the public key; receiver discovers it via the protocol's prescribed mechanism); (iii) cryptographic-algorithm- deprecation-lifecycle parallel — MTA-STS WebPKI cryptography deprecates SHA-1 (CA/Browser-Forum-baseline- requirements §6.1.6, sunset effective 2017-01-01), deprecates RSA-1024 (CABF §6.1.5.1, minimum 2048-bit since 2013-12-31), and tracks NIST FIPS 186-4 / FIPS 186-5 elliptic-curve recommendations; DKIM cryptography deprecates SHA-1 (RFC 8301 §3.2 sunset effective 2018-11-01), deprecates RSA- 1024 (RFC 8301 §3.1 minimum 2048-bit normative requirement), and tracks RFC 8463 Ed25519 as the post-RSA-2048 algorithm-agility path; both protocols share the cryptographic-algorithm- deprecation-lifecycle discipline where algorithm-strength tracks NIST/IETF normative deprecation timelines and operators must rotate before deprecation sunsets; (iv) key-rotation-and- revocation-operator-runbook parallel — MTA-STS WebPKI key rotation is via ACME-certificate-renewal cycles (typically 90 days for Let's Encrypt, 13 months for commercial CAs); revocation is via CRL / OCSP for compromised keys; DKIM key rotation per RFC 6376 §3.6.2 is via publish-new- selector / retire-old-selector overlap cycles (typically every 6 months for compliance frameworks, more often for high-value sender domains); both protocols share the cryptographic-key- rotation-and-revocation operator- runbook discipline where rotation cadence balances cryptographic key- compromise risk against publication churn, and operator-tooling must coordinate the publication-handoff across rotation windows. Pair this page (the MTA-STS transport-layer cryptography deployment reference) with the DKIM cryptography basics spoke (the RFC 8301 message-layer cryptographic- primitive reference) when an operator audits the end-to-end cross-layer cryptographic-primitive lifecycle for the enterprise's authentication-and- transport-security deployment and needs to apply the same asymmetric-keypair- foundation / public-key-distribution / algorithm-deprecation-lifecycle / key- rotation-revocation operator-runbook discipline across BOTH the transport- layer MTA-STS public-PKI WebPKI chain and the message-layer DKIM RSA-or- Ed25519 DNS-TXT-RR publication contexts.
• DKIM DNS-TXT-record byte syntax — the CROSS-PROTOCOL-APPLICATION-LAYER- DKIM-TXT-RECORD-VS-TRANSPORT-LAYER-MTA- STS-TXT-RECORD-BYTE-GRAMMAR-AND- LIFECYCLE-COMPARISON companion to this MTA-STS pillar. Where THIS page documents the MTA-STS RFC 8461 §3.1 transport-layer DNS-TXT-record at _mta-sts.<domain> carrying the v=STSv1; id=<version- token> byte-payload that triggers the HTTPS policy-file fetch at https://mta-sts.<domain>/.well- known/mta-sts.txt, the DKIM-DNS- syntax spoke is the STRUCTURALLY- ORTHOGONAL APPLICATION-LAYER COMPANION documenting the RFC 6376 §3.6.1 per-tag DKIM-TXT-record at <selector>._domainkey.< signing-domain> carrying the v=DKIM1; k=rsa; p=<base64- pubkey> byte-payload that the receiver-side DKIM-verification cascade consumes. The CROSS-PROTOCOL-DNS-TXT- RECORD-BYTE-GRAMMAR-AND-LIFECYCLE- COMPARISON establishes FIVE structurally- comparable axes both protocols share at the DNS-TXT-record layer: (i) per-protocol version-sentinel tag — MTA-STS uses v=STSv1; DKIM uses v=DKIM1 at the front of the TXT-record payload; both protocols require the version-sentinel as the FIRST tag for receiver-side parsing to recognise the record as belonging to its protocol; missing or wrong version- sentinel causes the receiver to reject the record AS NOT BELONGING TO THIS PROTOCOL — the DKIM-DNS-syntax spoke documents the DKIM version-sentinel failure modes; (ii) per-protocol version-or-policy-id token — MTA-STS uses id=<version- token> as the policy-file version tracker; DKIM uses s=<selector> implicit via the TXT-record-hostname selector subdomain to track per-key versioning; both protocols publish version-or- rotation discipline at the DNS-TXT- record layer; (iii) per-protocol key-rotation-or-policy-revision lifecycle — MTA-STS RFC 8461 §3.1 documents the id= bump-on-every-policy-edit lifecycle; DKIM RFC 6376 §3.6.1 documents the selector- rotation publish-new → wait-TTL → sign- new → wait-TTL → retire-old lifecycle the DKIM-DNS-syntax spoke catalogues per- tag (the p= tag carries the rotating public-key material); both protocols require operator-discipline at the byte-edit-and-DNS-propagation boundary; (iv) per-protocol revocation-sentinel byte-pattern — MTA-STS revocation publishes the empty v=STSv1; id=<new-version> TXT record paired with a mode: none policy file; DKIM revocation per RFC 6376 §3.6.1 publishes the p= tag with an empty value as the revoked-key sentinel; both protocols establish revocation-as-byte- pattern at the DNS-TXT-record layer; the DKIM-DNS-syntax spoke documents the per-tag revocation byte-format; (v) per-protocol receiver-side DNS-TXT-record-byte-payload-overflow at UDP 512-byte boundary — MTA-STS TXT-record payloads are small and rarely overflow; DKIM TXT-record payloads with 2048-bit or 4096-bit RSA p= tag values can overflow requiring TCP fallback or EDNS0 UDP-size extension support at the receiver-side resolver; the DKIM-DNS-syntax spoke documents the DKIM-specific overflow-and-fallback considerations. Pair this page (the MTA-STS transport-layer reference) with the DKIM-DNS-syntax spoke (the application-layer DKIM-TXT-record byte- grammar reference) when authoring a comprehensive per-domain DNS-TXT- record publication topology audit — both protocols converge on the DNS-TXT-record as the cryptographically-policy-anchoring primitive whose byte-grammar discipline the operator must maintain at parallel publication paths.
• DKIM best practices — the MTA-STS-TRANSPORT-LAYER-OPERATOR- DISCIPLINE-PARITY-WITH-DKIM-APPLICATION- LAYER-13-RULE-OPERATOR-DISCIPLINE companion documenting the platform-agnostic 13-rule DKIM operator-discipline synthesis that is the structurally-analogous APPLICATION-LAYER operator-discipline companion to this MTA-STS TRANSPORT-LAYER pillar. Where THIS page documents the MTA-STS TRANSPORT-LAYER operator-discipline (the RFC 8461 _mta-sts TXT-record publication, the HTTPS-served /.well-known/mta-sts.txt policy file, the testing → enforce mode advance cadence, the max_age-governed cache TTL, the per-MX-host TLS-handshake enforcement, the policy-rotation id=-bump discipline), the DKIM-best-practices spoke is the STRUCTURALLY-ANALOGOUS APPLICATION-LAYER operator-discipline companion documenting the 13 rules EVERY DKIM-publishing operator must internalise as the message-content authentication-layer counterpart to MTA-STS's transport-layer authentication-discipline: the 2048-bit RSA / Ed25519 algorithm floor, the per-selector key-isolation rule, the 6-to-12-month rotation cadence, the relaxed-relaxed canonicalisation default, the x= expiration discipline for replay mitigation, the post-DMARC alignment-with-DMARC discipline, the DKIM-failure-monitoring discipline via RUA aggregate reports, and the seven-additional- rules covering selector hygiene, public-key retirement, signing-algorithm migration, and the platform-portability discipline. The two operator-discipline checklists are STRUCTURALLY ANALOGOUS at distinct OSI layers — MTA-STS publishes a TXT signal + HTTPS policy file + receiver-side TLS- handshake enforcement at the SMTP-transport boundary, DKIM publishes a TXT signature- verification key + signs message-content + receiver-side body-hash + header-hash verification at the message-content boundary — and operators running an MTA-STS-enforced TRANSPORT posture SHOULD also run the 13-rule DKIM APPLICATION-LAYER operator-discipline to close the defense-in-depth posture that NEITHER protocol achieves alone. Read the DKIM-best-practices spoke when scoping the application-layer operator-discipline that runs at the orthogonal-protocol-layer sibling to this page's MTA-STS transport- layer operator-discipline — the 13-rule checklist is the rubric against which the operator's DKIM-publishing posture is evaluated for parity with the MTA-STS transport-layer operator-discipline documented here.
• DKIM replay attacks — the TRANSPORT-LAYER-MX-ALLOW-LIST-AS- REPLAY-DELIVERY-CHANNEL-CONSTRAINT companion reference. Where THIS page documents the MTA-STS TRANSPORT-LAYER publish-discover-enforce mechanism (the _mta-sts.<domain> TXT record, the HTTPS-served /.well-known/mta-sts.txt policy file's mx: allow-list + mode: enforce + max_age: TTL, the per-MX- host TLS-handshake enforcement at the SMTP-transport boundary), the DKIM- replay-attacks spoke documents the RFC 6376 §6.2.2 signature-replay attack class in which an attacker captures a legitimately-signed message from its original delivery path and re-injects the byte-identical signed corpus to many additional receivers under the ORIGINAL DKIM-Signature header. The TRANSPORT-LAYER CONNECTION between the two protocols is that MTA-STS-enforced delivery binds the receiver-side message ingress to the published mx: allow-list — when a domain publishes MTA-STS at mode: enforce, the receive- side TLS handshake → SMTP-RCPT path terminates exclusively at the operator- published MTAs whose receive-side DKIM-Signature replay-detection logic (h=-tag tracking, message-id uniqueness cache, x=-tag expiry enforcement, body- hash deduplication) is auditable by the operator. Without MTA-STS, the replay attacker can deliver the captured signed corpus to ANY MX (including operator-unknown receive- side MTAs with no replay-detection logic) — the replay-detection surface becomes the union of every globally- deployed MTA's individual policy. MTA-STS structurally bounds the replay- delivery channel: only operator- approved MTAs accept the replayed traffic at the transport layer, and only those MTAs' application-layer DKIM-Signature replay-detection logic is in scope. Read this when planning the receiver-side replay-detection deployment surface for a sending domain that publishes MTA-STS at enforce — the DKIM-replay-attacks page documents the RFC 6376 §3.5 x= expiration timestamp tag, the l=-tag-as-replay- extension-vector, the per-selector retire-and-rotate cadence, and the receive-side DKIM-Signature header tracking that compose with this page's MTA-STS transport-layer constraint to produce a layered replay-defense posture.
• BIMI explained - Brand Indicators for Message Identification: the inbox brand-logo standard. Requires DMARC at enforce, independent of MTA-STS.
• BIMI Verified Mark Certificates (VMC and CMC) — the CROSS-CERTIFICATE-CLASS-PARALLEL- PKI-TRUST-CHAIN companion reference. Where THIS page documents the MTA-STS protocol's HTTPS-published policy file served at https://mta-sts.<domain>/.well-known/mta-sts.txt with a publicly-trusted X.509 server certificate the receiver-side fetcher chain-validates before consuming the policy, the BIMI-certificates spoke documents the STRUCTURALLY-PARALLEL BIMI VMC/CMC X.509 trademark-bound certificate whose CAA-gated issuance pipeline + MVA trademark-evidence- validation gate + SVG-hash-binding mechanism run in parallel to THIS page's HTTPS-policy-endpoint cert issuance pipeline, across four cross-cert-class publisher-operator- discipline dimensions: (i) both certificate classes are issued by publicly-trusted CAs under CAA record control at the publisher domain — the operator's CAA issue tag set MUST encompass the CA issuing the mta-sts sub-domain cert AND the CA issuing the VMC (typically distinct providers — Let's Encrypt / DigiCert for the MTA-STS server cert vs DigiCert / Entrust for the VMC), composing the per-publisher PKI authorisation scope, (ii) certificate renewal- lifecycle discipline applies to both — the MTA-STS HTTPS cert renews on a 60-90-day ACME cadence (Let's Encrypt) or annual MPKI cadence (commercial CA), while the VMC renews on a 1-3-year MPKI cadence — both require continuous publisher-side operational monitoring to prevent the receiver- side downstream failure modes (MTA-STS policy fetch fails AND BIMI display fails respectively), (iii) the receiver-side trust-model evaluation is structurally parallel — MTA-STS-honouring receivers chain-validate the mta-sts.<domain> cert against the system PKI trust store before consuming the policy; BIMI-honouring MUAs chain-validate the VMC against the (more restricted) BIMI WG-approved CA list before rendering the logo, composing the two cert-chain- validation surfaces at the publisher's PKI-trust posture, and (iv) both cert classes participate in the §7.4-class brand- impersonation defense surface catalogued in the dmarc_attacker_ bypass threat catalogue — CA- compromise affects MTA-STS cert issuance just as it affects VMC issuance, and the operator's CAA- based defense posture mitigates the attacker-bypass class symmetrically across both certificate classes. Read the BIMI-certificates spoke alongside this MTA-STS pillar when scoping the publisher-side cross-cert- class PKI-discipline — the CAA- authorisation, ACME-renewal- cadence, receiver-side chain- validation, and CA-compromise- defense surfaces enumerated for the MTA-STS HTTPS server cert ON THIS page apply structurally to the parallel VMC procurement and renewal lifecycle the BIMI- certificates spoke documents.
• Email spoofing explained — the MTA-STS-PROTECTS-AGAINST-TRANSPORT- LAYER-SPOOFING parent-threat-class reference documenting the seven canonical email-spoofing techniques as MESSAGE-IDENTITY-LAYER spoofing classes structurally-distinct from the TRANSPORT-LAYER SMTP-receiver-impersonation spoofing class MTA-STS is specifically engineered to defeat. Where THIS pillar documents the MTA-STS protocol at the byte level (the _mta-sts.<domain> TXT record, the mta-sts.<domain> HTTPS policy-fetch endpoint, the version: / mode: / max_age: / mx: keys, the none / testing / enforce mode semantics, the STARTTLS-with-policy-enforcement receiver- side behaviour) and MTA-STS's NARROW anti-spoofing scope (preventing transport- layer MITM downgrade where a network- position attacker impersonates the legitimate destination MTA by stripping STARTTLS or presenting a forged certificate), the email-spoofing pillar is the PARENT-CLASS DEEP DIVE on the seven MESSAGE-IDENTITY-LAYER spoofing techniques MTA-STS has ZERO defensive contribution against — critical because the two spoofing layers (transport vs message- identity) are routinely conflated in operator discussions. The four-axis comparison exposes the structurally-distinct TRANSPORT-LAYER-VS-MESSAGE-IDENTITY-LAYER spoofing-class boundary: (i) MTA-STS DEFEATS — Transport-layer MTA-receiver impersonation — a network-position attacker (BGP-hijacker, on-path ISP, hostile Wi-Fi) attempts to intercept SMTP delivery by impersonating the destination MX with a rogue server presenting either no TLS, a self-signed certificate, or a certificate for the wrong hostname; MTA-STS enforce mode REJECTS the delivery and emits TLS-RPT failure events; this is the SPOOFING-OF- TRANSPORT-CHANNEL class the spoofing pillar explicitly EXCLUDES from its seven-technique taxonomy because the pillar scopes itself to MESSAGE-IDENTITY-LAYER spoofing only; (ii) MTA-STS DOES NOT defeat — Direct domain spoofing (RFC 5322 From: forgery) — the attacker forges the From: header at message origin and delivers the message to the legitimate recipient MX OVER A LEGITIMATE STARTTLS-PROTECTED CONNECTION; MTA-STS verifies the TRANSPORT channel but has no visibility into the message-identity headers; the spoofed message arrives in the inbox with MTA-STS positively confirming the transport was secure — i.e. MTA-STS is THE WRONG LAYER for direct-From-spoofing defense; (iii) MTA-STS DOES NOT defeat — Display-name spoofing — same layer-mismatch reasoning; the attacker's "Acme Bank" <billing@unrelated.example> From-header arrives over a STARTTLS-secured connection that MTA-STS positively validates; (iv) MTA-STS DOES NOT defeat — Lookalike-domain registration + IDN homograph + cousin-domain + envelope MAIL FROM forgery — same layer- mismatch reasoning across all four message-identity-layer variants; the attacker establishes a legitimate STARTTLS session and ships their spoofed message, MTA-STS positively confirms transport security. Read THIS MTA-STS pillar WITH the email-spoofing pillar when scoping the operator's anti-spoofing stack: this page documents the NARROW transport-layer- spoofing defense MTA-STS provides, the spoofing pillar documents the SEVEN message-identity-layer spoofing classes that require the SEPARATE DMARC + DKIM + SPF + BIMI + secure-email-gateway anti- impersonation + user-awareness training stack at the message-identity layer.
• Phishing protection — the MTA-STS-AS-TRANSPORT-LAYER-PHISHING- DEFENSE-COMPLEMENT companion to this MTA-STS protocol pillar. Where THIS page documents the MTA-STS protocol at the byte level (the _mta-sts.<domain> TXT record version indicator, the mta-sts.<domain> HTTPS policy-fetch endpoint, the version: / mode: / max_age: / mx: keys, the none / testing / enforce mode semantics, the STARTTLS-with-policy-enforcement receiver-side behaviour), the phishing-protection spoke documents the cross-cluster DEFENSE-IN-DEPTH stack (DMARC + DKIM + SPF + BIMI + MTA-STS + secure-email-gateway anti-impersonation + user-awareness training) MTA-STS slots into as the TRANSPORT-LAYER defense-layer — a defense-stack composition where MTA-STS is the ONLY layer that defends against the ACTIVE-MITM transport-layer downgrade phishing attack class (the application- layer DMARC/DKIM/SPF stack defends against forged-identity phishing at the message layer but offers ZERO protection against an on-path attacker who strips STARTTLS to deliver the phishing message in cleartext for harvesting + replay, whereas MTA-STS at mode: enforce raises the cleartext- stripping attack to a detectable delivery-failure-with-TLS-RPT-receipt signature). Read the phishing- protection spoke when scoping the full defense-in-depth posture this MTA-STS pillar contributes the transport-layer defense-layer to — particularly when the operator's threat model includes nation-state or ISP-class active-MITM attackers (where the application-layer-only defense stack is structurally insufficient) or when building the cleartext-delivery-failure forensic runbook the phishing-protection spoke documents.
• Business email compromise (BEC) defence — the MTA-STS-AS-TRANSPORT-LAYER- BEC-DEFENCE companion to this MTA- STS protocol pillar. Where the email-spoofing taxonomy spoke catalogues the seven message- identity spoofing techniques at the protocol level, the business- email-compromise spoke is the financial-loss-quantified, human- engineering-amplified, multi-stage- attack-pattern companion documenting the FBI IC3-tracked BEC attack class whose 2024 reported loss was $2.9B globally — and whose transport-layer-touching variants the MTA-STS mode: enforce + MX-allow-list publication THIS pillar documents is the LOAD-BEARING TRANSPORT- LAYER COMPLEMENT to the application-layer DKIM-and-DMARC defence against at FOUR transport- layer-vs-BEC-attack-stage defence dimensions: (i) BEC stage-1 pre-delivery interception via downstream SMTP STARTTLS downgrade → MTA-STS mode:enforce prevents the cleartext-fallback path the attacker needs to intercept-and-modify the legitimate finance-team message — the BEC spoke's stage-1 catalogue documents the attacker-in-the-middle variant where the attacker positions between the legitimate sender and receiver (compromised upstream MTA, BGP-hijack of receiver's MX IP-block, ISP- level NAT-cone hijack) and STRIPS the STARTTLS announcement from the EHLO response, forcing the sender's MTA to fall back to cleartext SMTP — in this variant the attacker reads the legitimate finance- team's wire-transfer instructions message in cleartext and SUBSTITUTES the attacker's bank-account number before forwarding to the receiver; THIS MTA-STS pillar's mode: enforce + MX-allow-list publication REFUSES delivery when the attacker strips STARTTLS (cleartext fallback becomes a BLOCKED operation at the sender side rather than a SILENT downgrade), neutralising the BEC stage-1 transport- interception variant; (ii) BEC stage-2 cousin- domain variant routes outbound through the cousin's own MTA infrastructure → MTA-STS does NOT protect against this variant (different publisher, different MX, different policy), motivating the scope-boundary acknowledgement the cousin-domain variant requires complementary out-of- band controls — the BEC spoke's stage-2 catalogue documents the lookalike-domain variant where the attacker registers company-llc.com and routes outbound through the cousin's OWN MTA infrastructure with the cousin's OWN MTA-STS policy (or no MTA-STS policy at all); in this variant THIS pillar's protection scope ends at the publisher's own MX endpoint (MTA-STS is bound to a specific publisher's MX, not to "any plausible domain"), making the scope-boundary acknowledgement explicit and motivating the COMPLEMENTARY out-of-band controls (passive- DNS lookalike-monitoring feeds, homoglyph-permutation enumeration, recipient-side warning banners for first- contact cousin domains) the BEC spoke's stage-2 catalogue documents the attack-pattern reference for; (iii) BEC stage-3 reply- chain-hijack from in-thread-compromised-account bypasses transport-layer controls (legitimate sender is the attacker, legitimate MX is the egress) → MTA-STS passes correctly, motivating the layered application-layer-plus- identity-layer-plus-content- layer defence the BEC spoke documents — the BEC spoke's stage-3 catalogue documents the most sophisticated variant where the attacker compromises an in-thread participant's mailbox via separate credential-theft and pivots at message N+1 to a social- engineering payload; in this variant THIS pillar's transport-layer protection passes correctly (the compromised user IS the legitimate egress through the legitimate MX under the legitimate MTA-STS policy), making explicit that MTA-STS is NECESSARY but NOT SUFFICIENT for full BEC defence — the stage-3 variant motivates the LAYERED-CONTROLS posture (identity-layer MFA- plus-impossible-travel- detection, application-layer DLP-content-scanning, content- layer finance-process two- channel verification) the BEC spoke documents at the attack-pattern reference level; (iv) BEC stage-4 post-compromise outbound-spoof from the victim's OWN egress with STARTTLS-encrypted delivery → MTA-STS passes correctly, and the BEC spoke documents the COMPLEMENTARY identity- layer controls that detect the compromise upstream of the egress — the BEC spoke's stage-4 catalogue documents the variant where the attacker has fully compromised a user account at the victim organisation and sends outbound BEC from the victim's OWN MTA infrastructure with the victim's OWN MTA-STS policy; in this case the transport-layer evaluation THIS pillar documents passes correctly (the attacker IS the legitimate egress from the legitimate MTA under the legitimate STARTTLS- encrypted channel), making explicit that MTA-STS is the OUTBOUND-CONFIDENTIALITY- AND-INTEGRITY gate but not the COMPROMISED-USER detector, and the BEC spoke's stage-4 catalogue documents the COMPLEMENTARY identity-layer controls (impossible-travel sign-in alerts, anomalous-send- volume detection, MFA-bypass forensics) that detect the compromise upstream of the egress. Read the BEC spoke WITH this MTA-STS pillar when authoring the layered- defence posture for an organisation in the FBI IC3 BEC-target categories (manufacturing, legal, finance, real-estate, construction) — the BEC spoke is the financial- loss-quantified, attack- stage-catalogued business- outcome threat-modelling reference; THIS MTA-STS pillar is the transport- layer cryptographic-channel protection reference for the stage-1 transport- interception variant (and stages 2–4 scope-boundary acknowledgement).
• DMARC myths and misconceptions - the cluster-spanning catalogue this MTA-STS pillar refutes the transport-security myths from - the CLUSTER-SPANNING MYTHS CATALOGUE the transport-security-specific myths this MTA-STS pillar refutes IN PASSING are catalogued in. Where THIS pillar documents the MTA-STS protocol at the byte level (the _mta-sts.example.com TXT record, the mta-sts.example.com HTTPS policy-fetch endpoint, the policy file with version: / mode: / max_age: / mx: keys, the none / testing / enforce mode semantics, the STARTTLS-with-policy-enforcement receiver-side behaviour, the TLS-RPT observability companion under RFC 8460, the parallel DANE-via-TLSA RFC 7672 deployment), the myths-catalogue spoke is the OPERATIONAL CROSS-PROTOCOL TAXONOMY of the full myth family the transport-security myths this page refutes belong to: the transport- security myths (TLS encryption stops phishing - false, transport encryption protects the SMTP envelope in flight but does NOT authenticate the From: header attackers spoof; opportunistic STARTTLS is enough - false, STARTTLS without MTA-STS or DANE is downgrade- attackable; MTA-STS replaces DANE - false, they layer for distinct threat models; MTA-STS prevents AiTM - false, only the enforce mode + receiver STARTTLS support + valid certificate chain do; TLS-RPT is purely diagnostic - false, it surfaces the downgrade-attack evidence the SOC depends on; mta-sts policy publication implies enforcement - false, the mode value at the policy endpoint is the actual switch), catalogued ALONGSIDE the adjacent myth families: the DMARC-protocol myths (DMARC blocks all phishing, p=none is safe forever), the SPF myths (SPF stops spoofing, ~all is safer than -all), the DKIM myths (DKIM proves end-to-end integrity, single-selector deployment is sufficient), the BIMI myths (BIMI requires VMC at every receiver, BIMI improves deliverability directly), and the threat-model myths (display-name spoofing is cosmetic, BEC is solved by authentication alone). Read the myths-catalogue spoke when stakeholders arrive with transport-security misconceptions ("we have TLS so we're secure", "STARTTLS is enough without MTA-STS", "DANE is obsolete now that MTA-STS exists", "TLS-RPT is just for compliance dashboards", "policy file publication is the deployment - mode choice doesn't matter") - the catalogue is the cluster-spanning navigation reference for the broader misconception taxonomy this MTA-STS pillar intentionally only refutes pillar- adjacent fragments of.
• DMARC multi-domain strategy - the per-domain MTA-STS deployment fanout across the organizational-domain portfolio - the portfolio-level deployment reference for the per-domain MTA-STS policy publication mandated by THIS page. Where THIS page documents the MTA-STS protocol at the SINGLE-DOMAIN level (one _mta-sts.example.com TXT record + one mta-sts.example.com HTTPS policy-fetch endpoint + one policy file with one mode: / max_age: / mx: set), the multi-domain-strategy spoke documents the PORTFOLIO-LEVEL deployment fanout: each domain in the portfolio (organizational domain, public-facing subdomains, parked domains, M&A acquisitions, shared transactional senders) needs an INDEPENDENT MTA-STS policy because RFC 8461 §2 prohibits policy inheritance through PSL boundaries (unlike DMARC's sp= rollup). The portfolio operator's checklist: per-domain _mta-sts.<domain> TXT record publication with unique id= per-domain rotation cadence, per-domain TLS-certified mta-sts.<domain> HTTPS endpoint (X.509 SAN matching each domain individually — wildcard certificates simplify but are risky), parked-domain MTA-STS publication that explicitly signals the brand expects NO inbound mail traffic to its non-sending domains, and the per-domain TLS-RPT rua= stream that independently reports STARTTLS downgrade attempts per-domain (essential for detecting AiTM targeting one brand in the portfolio but not others).
• Email deliverability - the operational deep dive on the deliverability outcome the transport-encryption layer documented on this page directly contributes to. Where this page documents the MTA-STS protocol itself (the policy file syntax, the three mode values none / testing / enforce, the _mta-sts.example.com TXT record + mta-sts.example.com HTTPS policy-fetch transport, the STARTTLS enforcement semantics at the receiver, the max_age TTL discipline, the TLS-RPT reporting companion), the deliverability spoke documents the OUTCOME MTA-STS contributes to: the 100%-encryption-rate floor measured by Google Postmaster Tools / Microsoft SNDS / Yahoo Sender Hub as a per-sending-domain deliverability sub-score. The Gmail Bulk Sender Requirements (effective February 2024) explicitly count MTA-STS enforce mode toward the per-sender encryption-rate compliance gate that bulk senders (≥5,000 messages per day to gmail.com) must meet to retain inbox placement — MTA-STS is no longer a nice-to-have transport-security improvement, it is now a deliverability compliance prerequisite for any sender at scale. Where the protocol primer on this page documents the HOW of MTA-STS deployment (policy file structure, receiver behaviour, mode advancement from testing to enforce), the deliverability spoke documents the WHY of the transport-encryption layer in the broader deliverability framework (where transport encryption sits in the 14-section delivery funnel, how the encryption-rate sub-score interacts with the IP / domain / tenant / engagement reputation axes, how postmaster tools surface encryption-rate compliance per-receiver). Read the deliverability spoke when budgeting the MTA-STS rollout ("which Bulk Sender Requirements are deliverability gates and which are deliverability accelerants", "how does the encryption-rate sub-score interact with sender reputation at Gmail", "is MTA-STS testing mode sufficient for the Gmail Bulk Sender Requirements or does the gate require enforce") - the spoke is the authoritative cluster-spanning operational reference for the deliverability business outcome the MTA-STS protocol contributes to.
• Email security glossary - the broader threat-actor and attack-taxonomy context that justifies MTA-STS enforce mode - the security-context glossary that documents the threat model MTA-STS was engineered to close. Where this page is the TRANSPORT-ENCRYPTION-PROTOCOL deep dive (RFC 8461 policy syntax, STARTTLS downgrade-resistance, the three mode values, the policy-fetch transport, the max_age TTL discipline, the TLS-RPT companion), the security_glossary spoke is the THREAT-MODEL context that justifies MTA-STS's existence. Concretely: MTA-STS defends against the STARTTLS-stripping man-in-the-middle attack variant the glossary catalogues under adversary-in-the-middle (AiTM) tactics and maps to MITRE ATT&CK T1557 (Adversary-in-the-Middle) as a transport- layer-confidentiality control; STARTTLS-stripping attacks map to the cyber kill-chain Command-and-Control + Exfiltration stages as the encrypted- channel-stripping bypass that exposes attachment content and intercepted credentials in plaintext on the wire; MTA-STS sits in the defence-in-depth stack alongside the AUTHENTICATION layer (SPF / DKIM / DMARC defend against sender-identity attacks) and the ENCRYPTION-AT-REST layer (mailbox-side encryption defends against post-delivery access) as the WIRE-ENCRYPTION control. The glossary also catalogues the threat-actor classes that historically weaponised STARTTLS-stripping (nation- state SIGINT programmes documented by the EFF STARTTLS Everywhere project, the 2014 Cisco TLS-stripping incident, ISP-level downgrade attacks observed in the Internet Society's MANRS programme), situating MTA-STS as the documented defence against documented threat actors rather than a "nice-to-have" deliverability tweak. Read the security_glossary spoke when an operator asks "what specific threat does MTA-STS close in our threat model" - the glossary is the canonical cross-walk from this protocol pillar to the threat-actor, kill-chain, MITRE ATT&CK technique, and incident-response vocabulary the broader security organisation works in.
• DMARC deployment checklist — the MTA-STS-PARALLEL-TRACK-CHECKLIST-ITEM-FOR-TRANSPORT-LAYER-DEFENSE-IN-DEPTH companion to this MTA-STS reference — the MTA-STS-PARALLEL-TRACK-CHECKLIST- ITEM-FOR-TRANSPORT-LAYER-DEFENSE-IN-DEPTH companion documenting WHERE the MTA-STS publication step sits in the linear DMARC deployment checklist as a parallel-track item that complements the message-layer identity-authentication pillar of DMARC. Where THIS page documents MTA-STS in protocol-precise terms (RFC 8461 the _mta-sts.<domain> TXT- record syntax with v=STSv1 + id=, the mta-sts.<domain> HTTPS- policy-file delivery via .well-known/mta-sts.txt path, the mode: enforce vs mode: testing rollout choice, the mx: allow-list whose sending-MTA TLS-policy enforcement closes the opportunistic-TLS-downgrade attack surface), the deployment-checklist spoke documents the PARALLEL-TRACK ORDERING of MTA-STS within the broader DMARC deployment sequence: MTA-STS publication can proceed IN PARALLEL with the Phase-1 RUA observation period (independent DNS publication, no coupling to SPF/DKIM/DMARC content), and the checklist documents the per-domain MTA- STS rollout calendar (Phase A mode: testing with TLS-RPT observation, Phase B mode: enforce after two consecutive observation windows confirm zero sender-side reachability failures). The checklist's defense-in-depth framing positions MTA-STS as the TRANSPORT-LAYER complement to DMARC's message-layer identity-authentication — both publication tracks must complete to close the full attack surface. Read THIS MTA-STS- explained page WITH the deployment-checklist reference when planning a DMARC + MTA-STS joint deployment — the checklist names the parallel-track ordering that lets both publications proceed without serial-blocking dependencies between the message-layer and transport-layer phases.
• Why SPF alone is insufficient - the TRANSPORT-LAYER-MTA-STS-AS- COMPLEMENTARY-DEFENSE-COVERING-THE- APPLICATION-LAYER-SPF-PROTOCOL-LIMITATION- AT-THE-SMTP-TRANSPORT-HOP companion to this MTA-STS protocol reference. Where THIS page documents the MTA-STS policy- enforcement mechanism (RFC 8461 _mta-sts.<domain> TXT record + the https://mta-sts.<domain>/.well-known/mta-sts.txt policy file with version: STSv1 + mode: enforce|testing|none + repeated mx: directives + max_age: <seconds> tag- value grammar, the receiver-MTA's policy- discovery / policy-fetch / cache-lookup / TLS-policy-enforcement state machine, the testing-vs-enforce mode-progression operator-discipline), the why-SPF-alone- is-insufficient pillar is the BROADER STRUCTURAL ARGUMENT companion documenting the SEVEN-PLUS-TWO structural defense- layer gaps SPF cannot defend against: the SEVEN application-layer gaps closed by DKIM-alignment-with-DMARC (forwarding- rewrites-MAIL-FROM, shared-hosting-IP- cohort-identity-confusion, MAIL-FROM-vs- From-header-asymmetry, cloud-provider- IP-rotation, 10-DNS-lookup-budget cap, absence-of-content-integrity, absence-of- publisher-private-key), PLUS TWO transport-layer gaps that DKIM cannot close either: (i) TLS-DOWNGRADE- STARTTLS-STRIPPING — an attacker positioned at the network layer between sender and receiver strips the 250 STARTTLS capability advertisement from the receiver's EHLO response, causing the sender's MTA to send the message over plaintext SMTP which the attacker can then read, modify, replay, or replace in transit — SPF, DKIM, and DMARC operate at the APPLICATION LAYER and provide ZERO defense at the transport layer, allowing an attacker to substitute the entire message body and headers (overwriting the DKIM-Signature header with a fresh attacker-signed signature against attacker-controlled DNS) before relay to the receiving MTA — this MTA-STS page documents the policy mechanism REQUIRED to close this gap by signalling to sender MTAs that TLS MUST be enforced on inbound SMTP regardless of EHLO advertisement; (ii) MX- RECORD-SUBSTITUTION-DURING-DNS- RESOLUTION-MAN-IN-THE-MIDDLE — an attacker positioned to manipulate DNS responses (an on-path attacker between sender and recipient, a cache-poisoning attacker against the sender's recursive resolver, a rogue authoritative-server operator at the recipient's DNS provider) injects a forged MX record pointing at an attacker-controlled MTA, redirecting the entire mail flow to attacker- controlled infrastructure — SPF, DKIM, and DMARC cannot defend against this because the application-layer authentication checks fire AFTER the message has already been delivered to the (now-attacker-controlled) MTA where the attacker can drop, replay, or substitute it freely — this MTA-STS page documents the policy mechanism that binds expected MX hostnames in the mx: directives of the policy file the sender's MTA fetches over HTTPS with WebPKI-validated certificate chains, structurally eliminating the MX-substitution attack at the policy- enforcement layer. Read the why-SPF-alone-is-insufficient pillar when authoring the operational argument for MTA-STS deployment urgency — MTA-STS is not a defense layer DUPLICATING what DKIM provides, it is a defense at the TRANSPORT-LAYER attack surface neither SPF nor DKIM can reach, and the joint MTA-STS + DKIM-alignment- with-DMARC + DMARC posture is the SUPERSET of structural defense layers the SPF protocol cannot provide by itself.
• CAA records explained - the UPSTREAM-PKI-ISSUANCE-POLICY- GATEKEEPER-FOR-MTA-STS-POLICY-HOST- HTTPS-CERTIFICATE companion reference. Where THIS page documents the MTA-STS transport-layer policy-enforcement protocol surface (publisher publishes a _mta-sts.<domain> TXT record advertising policy version / publisher publishes a policy file at https://mta-sts.<domain>/ .well-known/mta-sts.txt served over HTTPS with WebPKI-validated TLS certificate chains / sending MTAs fetch the policy file over HTTPS and cache it / sending MTAs enforce the policy's mx: directives and mode: enforce when delivering messages), the CAA-records spoke documents the UPSTREAM PUBLISHER- SIDE PKI-issuance-policy enforcement contract that gates WHICH CA CAN ACTUALLY ISSUE THE TLS CERTIFICATE the MTA-STS policy-host HTTPS server presents. CAA (RFC 8659) is a DNS- published RR-type-257 record at the publisher's apex domain that ENUMERATES THE FINITE LIST OF CAs the publisher AUTHORISES TO ISSUE certificates against the domain name including the mta-sts.<domain> policy-host subdomain. A publisher deploying MTA-STS without a CAA record accepts certificate issuance against the policy-host subdomain from any publicly-trusted CA — an attacker who compromises ANY of the ~80 CAs in the Mozilla / Apple / Microsoft root stores can issue an attacker-controlled certificate against the publisher's mta-sts.<domain> policy-host, then combine the attacker- controlled certificate with a BGP hijack or DNS-cache-poisoning attack to serve a forged MTA-STS policy file that DOWNGRADES MX enforcement or REDIRECTS traffic to an attacker- controlled MTA, defeating the MTA-STS defense layer at the policy-host compromise rather than at the policy- content level. A publisher with CAA records example.com. CAA 0 issue "letsencrypt.org" AUTHORISES only Let's Encrypt for ALL subdomain certificates including mta-sts.example.com, structurally bounding the attacker- compromised-CA surface from ~80 to 1 — the single CA the publisher selected. CAA records are ESSENTIAL DEFENSE-IN- DEPTH for every MTA-STS-deploying publisher because the entire transport- layer security guarantee MTA-STS provides rests on the publisher's policy-host HTTPS server presenting a TLS certificate that ONLY THE PUBLISHER'S AUTHORISED CA can issue — without CAA, the MTA-STS defense is only as strong as the WEAKEST CA in the global trust store. Read the CAA-records spoke alongside this page when authoring an MTA-STS deployment plan — the publisher's CAA record at the apex domain (and optionally a more-restrictive record at mta-sts.<domain>) is a SOFTWARE-PUBLISHER-OBSERVABLE operational artefact every MTA-STS deployment SHOULD include alongside the policy file and DNS TXT record. CAA records also support an iodef property pointing at a contact endpoint where CAs MUST report attempted-issuance-against-CAA-violating records, surfacing attacker-attempts at adversarial CA-issuance BEFORE the attacker succeeds and the MTA-STS defense layer is silently compromised.
• DKIM canonicalization — the APPLICATION-LAYER-DKIM-BODY- CANONICALIZATION-AS-TRANSPORT-LAYER-MTA-STS- COMPLEMENTARY-DEFENSE-PAIR companion to this MTA-STS transport-layer policy enforcement reference. Where THIS page documents the RFC 8461 MTA-STS policy file + DNS TXT publication + receiver-side TLS-enforcement + the STARTTLS-downgrade + MX-substitution + AITM-MITM transport-layer attack-class defense, the DKIM-canonicalization spoke is the APPLICATION-LAYER per-message body-and- header cryptographic-integrity-anchor whose `c=` tag value (the four RFC 6376 §3.4 combinations: `simple/simple`, `simple/relaxed`, `relaxed/simple`, `relaxed/relaxed`) is the STRUCTURALLY- COMPLEMENTARY application-layer defense paired with this transport-layer MTA-STS defense at FOUR cross-OSI-layer protection dimensions: (i) TRANSPORT-LAYER MTA-STS DEFENDS AGAINST PRE-TLS-NEGOTIATION STRIPTLS-DOWNGRADE; APPLICATION-LAYER DKIM BODY CANONICALIZATION DEFENDS AGAINST POST- TLS-NEGOTIATION INTERMEDIARY BODY MODIFICATION — the MTA-STS policy enforcement ensures the SMTP transport hop is encrypted, but DOES NOT prevent a downstream legitimate-receiver intermediary (mailing-list-server, anti-spam appliance, SaaS-tenant content-filter) from modifying the message body after the TLS-protected transport hop completes — the canonicalization choice on the body half (`c=*/simple` vs `c=*/relaxed`, §3.4.3 vs §3.4.4) determines whether post-transport intermediary body modifications survive DKIM verification at the next-hop receiver; (ii) MTA- STS POLICY-FILE INTEGRITY IS PROTECTED BY THE HTTPS X.509 CERTIFICATE CHAIN; DKIM-SIGNATURE INTEGRITY IS PROTECTED BY THE PUBLISHER-PUBLISHED PER-SELECTOR TXT-RECORD PUBLIC KEY — the two defense layers depend on DIFFERENT trust-anchor models: MTA-STS leverages the X.509 PKI (with CAA records as upstream issuance gate) for the policy-file authenticity; DKIM canonicalization leverages the publisher's `<selector>._domainkey.<d>` TXT- record-published public key for per-message signature authenticity — operators deploying BOTH defense layers must maintain BOTH trust-anchor publication disciplines (HTTPS certificate renewal cadence at the policy-host AND DKIM key rotation cadence at the signer); (iii) MTA-STS PROTECTS THE INBOUND-MX RECEIVE-SIDE TRANSPORT HOP; DKIM CANONICALIZATION PROTECTS THE OUTBOUND- SIGNED-MESSAGE INTEGRITY ACROSS EVERY DOWNSTREAM RECEIVER — MTA-STS is a RECEIVER-PUBLISHED policy (the operator publishes `_mta-sts.<org-domain>` and the policy-host file) that defends INBOUND mail to the org's protected domain; DKIM canonicalization is a PUBLISHER-DECIDED choice (the publisher publishes the per-selector public key and per-message DKIM-Signature header with `c=` tag) that defends OUTBOUND mail egressing from the org to every downstream receiver — the two defense layers cover ORTHOGONAL message-flow directions and BOTH are required for complete cross-direction defense; (iv) RUF-CHANNEL FORENSIC EVIDENCE FROM DMARC PAIRS WITH TLS-RPT FROM MTA-STS TO ENABLE CROSS-LAYER FAILURE- ATTRIBUTION — when a receiver emits a DMARC RUF sample for a `dkim=fail bodyhash-mismatch` verdict, the operator can cross-reference the TLS-RPT report for the same per-day window: if TLS-RPT reports STARTTLS-downgrade failures on the same source-IP, the body-hash failure is attributable to a pre-MTA-STS- enforcement transport-layer interception; if TLS-RPT reports clean TLS enforcement, the body-hash failure is attributable to a post-transport-hop intermediary body modification the canonicalization choice failed to survive — the parallel report-stream analysis is the cross-OSI- layer forensic-attribution capability the two defense layers together enable. Read the DKIM-canonicalization spoke alongside this MTA-STS transport-layer policy enforcement reference when authoring the operator's complete cross-OSI-layer mail- integrity defense posture — the spoke is the canonical RFC 6376 §3.4 reference whose four canonicalization combinations are the application-layer body-and-header cryptographic-integrity-anchor complementary to this MTA-STS transport-layer policy enforcement at the four orthogonal cross- OSI-layer protection dimensions.
• DMARC for cPanel-hosted domains — the PER-CPANEL-MANAGED- HOSTING-TENANT-WEBROOT-AND- ZONE-EDITOR companion to this MTA-STS protocol pillar. Where THIS page documents the MTA-STS protocol byte-level publication discipline (the per-publisher _mta-sts.<d-domain> TXT-record + HTTPS-served mta-sts.<d-domain>/.well-known/mta-sts.txt policy-file publication, the version: STSv1 version-prefix, the mode: testing → enforce progression, the mx: mail-flow- authorization invariants, the max_age: policy- rotation-cadence discipline), the dmarc_for_cpanel spoke documents the per-cPanel-tenant hosting-deployment infrastructure whose webroot + Zone Editor + AutoSSL stack IS the canonical load-bearing per-tenant MTA-STS- policy-file-publication infrastructure the per-publisher MTA-STS publication-discipline THIS page documents resolves to at the per-shared-hosting- tenant deployment boundary. FOUR structurally-distinct PER-CPANEL- INTERFACE-VS-MTA-STS-PUBLICATION- STAGE-COUPLING-DIMENSIONS the dmarc_for_cpanel spoke operationally documents: (i) per-cPanel-tenant webroot /.well-known/mta-sts.txt file-publication via cPanel File Manager OR shell-level public_html/.well-known/ directory creation AS LOAD- BEARING-MTA-STS-POLICY-FILE- HTTPS-SERVING-PRIMITIVE — the MTA-STS protocol REQUIRES the policy file to be served via HTTPS at a precise URL path; cPanel's per-tenant webroot infrastructure (DocumentRoot rooted in /home/<tenant>/public_html/) + AutoSSL-provisioned HTTPS certificate IS the canonical load-bearing per-tenant HTTPS- publication primitive THIS page's policy-file HTTPS-fetch publication discipline materially depends on at the per-shared- hosting-tenant deployment boundary; (ii) per- cPanel-tenant _mta-sts.<d-domain> TXT-record publication via cPanel Zone Editor "Add Record" → TXT type → host _mta-sts → value v=STSv1; id=< timestamp> AS LOAD- BEARING-PER-TENANT-DNS- PUBLICATION-PRIMITIVE — the MTA-STS protocol REQUIRES the per-publisher _mta-sts.<d-domain> TXT-record at the apex subdomain as the discovery primitive announcing policy-file presence and the per-rotation policy-id value; cPanel's per-tenant Zone Editor interface (the per-tenant view of the underlying BIND / PowerDNS authoritative-server zone-file) IS the canonical load-bearing per-tenant DNS- publication primitive every per-tenant _mta-sts-TXT publication operation THIS page's discovery-TXT-publication discipline depends on at the per- shared-hosting-tenant deployment boundary; (iii) per- cPanel-tenant AutoSSL-provisioned HTTPS certificate covering the mta-sts.<d-domain> Web-PKI-anchored Subject-Alt- Name AS LOAD-BEARING-PER-TENANT- WEB-PKI-TRUST-ANCHOR-PRIMITIVE — the MTA-STS protocol REQUIRES the mta-sts.<d-domain> policy-fetch endpoint to be served under a Web-PKI-valid TLS certificate; cPanel's AutoSSL feature auto-issues + auto- renews per-tenant Let's Encrypt / Sectigo / cPanel-bundled-CA certificates covering the per- tenant mta-sts.-prefixed Subject-Alt-Name IS the canonical load-bearing per-tenant Web-PKI trust-anchor primitive every receiver-side MTA-STS-policy- fetch-validation operation THIS page's policy-file-HTTPS-trust- chain-validation discipline depends on at the per-shared- hosting-tenant deployment boundary; (iv) per- cPanel-tenant max_age:-cadence policy-rotation-discipline coordinated with the per-tenant zone-template TTL + AutoSSL- renewal-cadence AS LOAD-BEARING- PER-TENANT-OPERATIONAL-DISCIPLINE — the MTA-STS protocol REQUIRES per-publisher policy- rotation be coordinated with the max_age: TTL-cache window receivers honor; cPanel's per-tenant policy-file-rotation cadence (push new policy-file via File Manager + bump _mta-sts-TXT id= field via Zone Editor) coordinated with the per-tenant Zone Editor TTL + AutoSSL renewal cadence IS the canonical load-bearing per-tenant operational discipline THIS page's policy-rotation publication discipline depends on at the per- shared-hosting-tenant deployment boundary. Read the dmarc_for_ cpanel spoke ALONGSIDE this MTA- STS protocol pillar whenever a per-cPanel-managed-hosting-tenant publisher scopes a per-tenant MTA-STS deployment plan — the per-cPanel-tenant webroot + Zone Editor + AutoSSL stack THIS deployment spoke documents IS the canonical load-bearing per- shared-hosting-tenant deployment infrastructure the per-publisher MTA-STS publication discipline THIS page documents materially depends on at the per-tenant deployment boundary.
• DMARC monitoring discipline — where THIS page documents the per-publisher per-domain TRANSPORT- LAYER policy-file + DNS-TXT publication discipline that ENFORCES the SMTP-TLS transport-encryption contract at the per-MX-host boundary, the DMARC-monitoring spoke documents the per-publisher per-domain APPLICATION-LAYER observability discipline whose structural-parallel to the TLS-RPT JSON-report observability THIS page references at the transport layer produces the symmetric cross-OSI- layer publisher-operator observability framework. FOUR structurally-distinct CROSS-LAYER MONITORING coupling dimensions the DMARC-monitoring spoke operationally documents: (i) per-publisher per-domain DMARC-pass-rate KPI floor across all receivers as load-bearing application-layer observability parallel to TLS-RPT per-MX-host TLS-pass-rate KPI floor — the application-layer DMARC aggregate-XML dmarc/result=pass rate is the structural parallel to the transport-layer TLS-RPT successful-session rate; both KPIs must be monitored against per- domain alert thresholds during the mode: testing → enforce progression THIS page documents to catch unforeseen mail-flow breakage BEFORE enforce-mode rejects legitimate mail; (ii) per- publisher per-source-IP alert threshold as load-bearing post- publication regression-detection primitive coordinated with MTA-STS id=<version-token> rotation cadence — the DMARC-monitoring spoke's per- source-IP alignment-failure alert threshold surfacing a previously- aligned legitimate sender now producing DMARC-fail at a single receiver is the structurally- analogous post-change regression- detection primitive to the TLS-RPT per-receiver policy-string-failure rate spiking immediately after an MTA-STS policy-id bump; both regression-detection primitives must run synchronized to the publication cadence; (iii) per-publisher sender- inventory drift detection as load- bearing standing observability for BOTH per-domain DMARC alignment AND per-MX-host MTA-STS allow- list correctness — when a new operationally-distinct sending infrastructure (per-tenant marketing platform, per-tenant SaaS partner, per-tenant transactional ESP) appears in the per-publisher per- domain rua aggregate-XML evidence stream, BOTH the DMARC alignment envelope-MAIL-FROM + DKIM d= alignment posture AND the MTA-STS per-MX-host mx: allow-list THIS page's policy-file discipline constrains must be re-evaluated in the same operational pass; (iv) per-publisher cross-OSI- layer observability synthesis as load-bearing publisher-operator review cadence — the DMARC-monitoring spoke's per-week / per-month / per-quarter operational review cadence provides the standing publisher- operator discipline framework whose per-cadence-tier review agenda materially includes both the application-layer DMARC-aggregate-XML evidence review and the transport-layer TLS-RPT-JSON-report evidence review THIS page documents the publication discipline of. Read the DMARC-monitoring spoke ALONGSIDE this MTA-STS pillar whenever the publisher scopes a per-publisher per-domain CROSS- OSI-LAYER mail-security observability framework — the MTA-STS publication discipline THIS page documents IS the transport-layer enforce-mode primitive, and the DMARC- monitoring discipline IS the application-layer observability primitive whose structural parallel to TLS-RPT monitoring produces the symmetric cross-layer operational observability framework.
• DMARC for shared hosting — the PER-TENANT-PER-POLICY-DOMAIN- MTA-STS-PUBLICATION-DISCIPLINE-AT- THE-PROVIDER-MANAGED-MX-RRSET-AND- HTTPS-POLICY-HOST-BOUNDARY companion to this MTA-STS operator reference. Where THIS page documents the canonical MTA-STS publication discipline (the _mta-sts.<domain> TXT-RR v=STSv1;id=<policy-id> version-pin, the https://mta-sts.<domain>/.well-known/mta-sts.txt HTTPS policy host serving the per-policy-domain MX RRset version-bound enforce-mode policy, the testing-to-enforce ramp progression per RFC 8461 §5, the per-receiver enforcement variance Gmail+M365 honor enforce vs Yahoo+iCloud receiver-side variance), the shared-hosting spoke is the per-tenant-deployment- execution companion documenting FOUR shared-hosting-MTA-STS coordination dimensions whose per- tenant satisfaction gates per- tenant MTA-STS publication on Plesk / DirectAdmin / ISPConfig / Webmin-Virtualmin / CWP: (i) per- tenant per-policy-domain MX RRset publication is gated by the provider-managed shared MX topology — the five non- cPanel control panels each provision a shared MX RRset whose per-tenant publication is bounded by the per-panel zone- editor UI affordance (Plesk's DNS template, DirectAdmin's DNS records, ISPConfig's DNS Zone record-add UI, Webmin / Virtualmin's DNS feature flag, CWP's DNS Functions manual edit); the shared-hosting spoke documents the per-panel per-tenant MX RRset publication discipline that determines whether the per-tenant MTA-STS policy's mx: directive (THIS page's per-policy- domain MX RRset version-bound contract) can ever be satisfied by the per-tenant inbound mail flow; (ii) per-tenant mta-sts.<tenant-domain> HTTPS policy host publication friction across the five non- cPanel control panels gates per-tenant MTA-STS policy deployment — Plesk requires per-tenant subdomain creation + HTTPS certificate + custom .well-known/mta-sts.txt path provisioning, DirectAdmin requires per-tenant Subdomain Management + SSL Certificates + File Manager edits, ISPConfig requires per-tenant Web Domain creation + Let's Encrypt + manual policy file edit, Webmin / Virtualmin requires per-tenant Server Configuration + SSL feature + manual upload, CWP requires per-tenant Domain Management + AutoSSL + manual .well-known directory creation; the shared-hosting spoke documents the per-panel per-tenant HTTPS policy host publication friction; (iii) per-tenant TLS certificate procurement for the mta-sts.<tenant-domain> subdomain is gated by the per- panel ACME automation discipline — the §3 mta-sts HTTPS policy host MUST present a valid TLS certificate matching the policy- host name (RFC 8461 §3.3), and the per-panel per-tenant ACME automation cadence (Plesk's SSL It! automation, DirectAdmin's Let's Encrypt integration, ISPConfig's Let's Encrypt feature flag, Webmin / Virtualmin's Let's Encrypt renewal cron, CWP's AutoSSL cron) determines whether the per-tenant policy host's TLS certificate stays continuously valid (preventing the HTTPS policy host certificate expiration cascade); (iv) per- tenant per-account escalation path from provider-default no- MTA-STS to operator-published per-tenant enforce-mode policy is the structural per-provider per-tenant remediation — the shared-hosting spoke documents the per-panel per- tenant testing-to- enforce ramp discipline and the per-panel per-tenant operator- escalation path from shared- hosting default (no MTA-STS publication for any tenant) to per-tenant publisher-controlled enforce-mode publication. Read the shared- hosting spoke ALONGSIDE this MTA-STS-explained reference whenever the operator scopes a per-tenant transport-layer- TLS-enforcement deployment on Plesk / DirectAdmin / ISPConfig / Webmin-Virtualmin / CWP — the MTA-STS publication discipline THIS page documents IS the per-policy-domain transport- layer enforcement contract the shared-hosting deployment guide encodes the per-provider per-tenant execution discipline for.
• ARC (Authenticated Received Chain) — the PER-FORWARDER-HOP-APPLICATION- LAYER-CRYPTOGRAPHIC-CHAIN-OF-CUSTODY- MECHANISM companion to this MTA-STS operator reference. Where THIS page documents the per-policy-domain transport-layer TLS-enforcement discipline (the _mta-sts TXT version-pin, the HTTPS policy host version-bound enforce-mode policy, the per-receiver enforcement variance), the ARC-explained spoke is the application-layer per- forwarder-hop cryptographic chain- of-custody companion documenting FOUR cross-OSI-layer ARC-vs-MTA-STS coordination dimensions whose per- publisher per-domain joint satisfaction provides the per- publisher per-policy-domain cross- OSI-layer (application+transport) integrity defence baseline: (i) application- layer per-hop integrity preservation vs transport-layer per-connection- leg integrity preservation — the ARC-Set authoring discipline at each forwarder hop preserves the per-message application-layer authentication verdict (DKIM-pass / SPF-pass) across forwarder rewrites, while MTA-STS enforces transport- layer TLS integrity for the per- connection-leg between sending MTA and receiving MTA; the ARC spoke documents the application-layer per-message provenance preservation mechanism whose per-message-bytes integrity grain runs STRUCTURALLY PARALLEL to the per-connection-leg TLS-encrypted-channel integrity grain THIS page documents at the transport layer; (ii) per- receiver ARC-validator trust posture vs per-sending-MTA MTA-STS-enforce- mode posture at the per-publisher per-domain cross-OSI-layer integrity boundary — the per-receiver per-ARC-signer trust-posture (Gmail, M365, Yahoo, iCloud, Apple Mail per- receiver variance) determines the application-layer ARC-rescue rate, while the per-sending-MTA MTA-STS- enforce-mode posture determines the transport-layer TLS-enforcement rate; the ARC spoke documents the per-receiver ARC-validator trust- posture catalogue whose application- layer per-receiver variance runs structurally parallel to the per- sending-MTA MTA-STS-enforce-mode- adoption variance THIS page documents at the transport layer; (iii) per-publisher per- domain ARC-signer trust-anchor publication discipline vs per- policy-domain MTA-STS-policy publication discipline — the per-publisher per-domain ARC- signer trust-anchor catalogue publication discipline at the per- publisher per-domain DNS-publication- boundary runs structurally parallel to the per-policy-domain MTA-STS- policy publication discipline at the per-policy-domain mta-sts.<domain> HTTPS-policy-host publication boundary; the ARC spoke documents the per-publisher per-domain ARC- signer trust-anchor publication discipline operationally consumed at the per-receiver per-message ARC-chain-validation boundary; (iv) per-publisher per- domain ARC-rescue baseline observability vs per-policy-domain TLS-RPT-evidence-stream observability at the per-publisher per-domain cross-OSI-layer integrity-coverage boundary — the per-day per-receiver per-forwarder-path per-policy-mode ARC-rescued-row rate baseline surfaces in the application-layer aggregate-XML RUA evidence stream, while the per-day per-receiver per-policy- domain TLS-RPT JSON-report aggregate-evidence stream surfaces the transport-layer per-connection- leg integrity coverage baseline; the ARC spoke documents the per- publisher per-domain ARC-rescue- rate diagnostic visibility whose application-layer observability grain runs structurally parallel to the per-policy-domain TLS-RPT- evidence-stream observability grain the per-publisher per-domain cross- OSI-layer integrity-coverage framework consumes for per- publisher per-domain integrity- defence confidence-floor measurement. Read the ARC spoke ALONGSIDE this MTA-STS-explained reference whenever the per- publisher per-domain operator scopes a per-publisher per-policy- domain cross-OSI-layer integrity defence baseline — the MTA-STS publication discipline THIS page documents IS the load-bearing per-connection-leg transport-layer enforcement contract whose structural-parallel per-message application-layer per-forwarder- hop cryptographic chain-of-custody mechanism the ARC spoke documents encodes the per-message provenance preservation defence for.
• DNS Record Generator - interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with syntax validation and best-practice defaults.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC, MTA-STS, CAA, BIMI, and DNSSEC against any domain.
• DMARC attacker bypass techniques - the 22-TECHNIQUE PER-POLICY-DOMAIN TRANSPORT-LAYER ATTACKER-BYPASS CLASSIFICATION-FRAMEWORK companion to this MTA-STS pillar reference. Where THIS page documents the MTA-STS protocol primer (RFC 8461 per-policy-domain enforcement-mode ladder of none / testing / enforce, the per- policy-domain _mta-sts TXT record + mta-sts.txt HTTPS-fetched policy file, per- policy-domain MX-pattern + max_age + version field publication discipline), the attacker-bypass spoke is the per- policy-domain attacker-side MTA-STS- evaluation-bypass technique- classification documenting the FIVE MTA-STS-targeted transport-layer attacker-bypass technique-classes the per-policy-domain operator MUST defend against at the per-policy- domain SMTP STARTTLS handshake boundary: (i) STARTTLS- stripping attack via in-flight SMTP-banner-rewrite at compromised intermediate-MTA - attacker intercepts the per-publisher per- domain outbound SMTP session at a compromised intermediate-MTA and removes the STARTTLS capability from the SMTP banner, forcing the per-publisher per-domain sender into cleartext SMTP transmission which the attacker captures or modifies in transit; (ii) MTA-STS-policy-pre-publication downgrade-attack exploitation - attacker targets per-policy- domain operators who have not yet published the per-policy-domain _mta-sts TXT record or whose published per-policy-domain policy-mode is still none / testing, exploiting the absence of per-receiver enforcement-mode requirement to downgrade the per-publisher per- domain SMTP session to cleartext; (iii) MTA-STS-policy-cache- poisoning via per-policy-domain long-max_age-value attacker-side upstream policy-server compromise - attacker compromises an upstream per-policy-domain mta-sts.<domain> HTTPS endpoint or its DNS resolution path and publishes a malicious mta-sts.txt policy file with attacker-controlled MX patterns + a long max_age: value that causes per-receiver MTA-STS validators to cache the malicious policy for an extended window during which all per-policy-domain outbound SMTP sessions are routed to attacker-controlled MX targets; (iv) MTA-STS-policy-DoS via per-policy-domain HTTPS endpoint availability-targeted attack - attacker DoS- targets the per-policy-domain mta-sts.<domain> HTTPS endpoint to prevent per- receiver mta-sts.txt policy refresh, causing per-receiver validators to fall back to per- receiver default-TLS-policy-mode which on some per-receivers means no enforcement, opening the per- policy-domain to per-receiver downgrade attack; (v) MTA-STS-policy-host-name- confusion attack via attacker- controlled mta-sts.cousin-domain registration - attacker registers a homoglyph cousin- domain of the per-policy-domain and publishes a malicious mta- sts.txt policy at the cousin domain, exploiting per-receiver UI display of the per-policy- domain identifier in user-visible STARTTLS-policy-status reporting. Read THIS page when AUTHORING the per-policy-domain MTA-STS pillar publication discipline; read the DMARC-attacker-bypass spoke when DESIGNING the per-policy-domain transport-layer STARTTLS-stripping + downgrade + mta-sts-policy-bypass defence posture against the 22- technique attacker-bypass classification framework - the spoke is the canonical attacker- bypass technique catalogue the per- policy-domain MTA-STS posture THIS page documents must structurally defend against.
• DMARC for Google Workspace — the WORKSPACE-TENANT-APPLICATION- LAYER-DMARC-PUBLICATION-COMPANION to this per-policy-domain transport-layer MTA-STS publication-discipline reference. Where THIS page documents the per-policy-domain transport-layer STARTTLS-policy enforcement publication discipline (per-policy-domain _mta-sts.<domain> TXT publication, per-policy-domain mta-sts.<domain> HTTPS policy-host hosting, per-policy- domain max_age caching policy, per-policy-domain enforcement- mode progression none → testing → enforce), the Workspace-deployment spoke is the STRUCTURAL APPLICATION- LAYER COUSIN documenting how the per- Workspace-tenant application-layer per- publisher per-domain DMARC publication discipline at the per-tenant authoritative DNS zone instantiates concretely on Google Workspace at FOUR per-Workspace- tenant-application-layer-DMARC-vs-per- policy-domain-transport-layer-MTA-STS- structural-pairing dimensions: (i) per-Workspace-tenant _dmarc.<domain> TXT publication is the application-layer structural twin of per-policy-domain _mta-sts.<domain> TXT publication — both are per- domain TXT records at a reserved subdomain label that the per-receiver evaluates as a policy publication; the Workspace-deployment spoke documents the per-tenant Google Admin Console DMARC-authoring workflow that produces the application-layer publication, the structural twin of the per-policy- domain MTA-STS publication this page documents; (ii) per-Workspace- tenant per-domain DMARC enforcement- mode progression (p=none → p=quarantine → p=reject) is the application-layer structural twin of per-policy-domain MTA-STS enforcement- mode progression (none → testing → enforce) — the Workspace-deployment spoke documents the per-tenant ramp discipline at the application-layer DMARC tier whose structural pattern (per-publisher per- domain three-stage ramp at incremental per-percentage rollout) mirrors the per-policy-domain MTA-STS three-mode ramp THIS page documents; (iii) per-Workspace-tenant per-domain DMARC rua/ruf feedback-loop authoring is the application-layer twin of per- policy-domain TLS-RPT rua=mailto: companion publication — both publish per-publisher per-domain operator aggregate-feedback mailboxes the per- receiver delivers daily evidence to; the Workspace-deployment spoke documents the per-tenant DMARC rua/ruf authoring whose structural pairing with the per-policy-domain TLS-RPT rua feedback-loop publication discipline THIS page co-references in §11 structures the per-publisher per- domain operator's two-stream aggregate- evidence consumption discipline; and (iv) per-Workspace-tenant per- domain authoritative DNS-zone publication boundary is the same publication boundary as per-policy- domain MTA-STS publication — both are published at the per-publisher per-domain authoritative DNS-zone tier the Workspace-tenant operator controls through their registrar / DNS provider; the Workspace-deployment spoke documents the per-tenant authoritative DNS-zone publication discipline whose publication boundary structurally coincides with the per-policy-domain MTA-STS publication boundary THIS page documents.
• DKIM for Microsoft 365 — the LOAD-BEARING per-M365-tenant per- custom-domain PER-M365-TENANT-DKIM- PUBLICATION-AS-APPLICATION-LAYER-PEER- OF-TRANSPORT-LAYER-MTA-STS-PUBLICATION- DISCIPLINE companion documenting the per-M365-tenant per-custom-domain DKIM publication tutorial (Exchange Online / Microsoft 365 Defender admin-center DKIM enablement, the 2048-bit selector1._domainkey / selector2._domainkey per-tenant CNAME publication, the Microsoft Graph PowerShell DKIM management cmdlets, the per-tenant DKIM signing-domain verification) — the per-M365-tenant per-custom-domain APPLICATION-LAYER message-authentication- publication-discipline STRUCTURAL PEER of the per-publisher per-policy-domain TRANSPORT-LAYER MTA-STS policy- publication-discipline THIS page documents. M365 tenants typically deploy per-custom-domain DKIM and per-custom- domain MTA-STS in the same deployment cycle — the per-tenant DKIM CNAME publication and per-tenant MTA-STS _mta-sts.<custom-domain> TXT-RR + mta-sts.<custom-domain> HTTPS-policy-host publication together establish the per-tenant per-custom- domain APPLICATION-LAYER + TRANSPORT- LAYER LAYERED-PROTECTION discipline. Where THIS page documents the per- publisher per-policy-domain RFC 8461 MTA-STS TRANSPORT-LAYER POLICY- PUBLICATION DISCIPLINE (the _mta-sts.<d> TXT-RR version + policy-ID tag publication, the https://mta-sts.<d>/.well- known/mta-sts.txt HTTPS-policy- host file publication, the per-publisher per-policy-domain mode: enforce / mode: testing / mode: none publication-mode choice, the per-receiver-MX STARTTLS- fail-closed enforcement gate), the DKIM-for-M365 spoke documents the per-M365-tenant per-custom-domain APPLICATION-LAYER DKIM-publication- discipline structural-peer of the TRANSPORT-LAYER MTA-STS publication- discipline this page documents. Read THIS page when AUTHORING the per- publisher per-policy-domain MTA-STS TRANSPORT-LAYER publication; read the DKIM-for-M365 spoke when AUTHORING the per-M365-tenant per-custom-domain APPLICATION-LAYER DKIM publication that PARTNERS with the per-tenant per- custom-domain MTA-STS publication discipline this page documents at the per-tenant per-custom-domain LAYERED- PROTECTION publication-discipline boundary.
• DMARC forensic (failure / RUF) reports — the DMARC forensic-reports spoke documents the RFC 6591 ARF + RFC 7489 §7.3 + RFC 8460 per-message application-layer-authentication-failure- redacted-envelope grammar that is the STRUCTURAL PARALLEL to the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate transport-layer-TLS-handshake-failure evidence stream THIS page's MTA-STS publication discipline produces. Four CROSS-LAYER-FAILURE-EVIDENCE-STREAM coupling axes the forensic-reports spoke documents: (i) per-publisher per- domain APPLICATION-layer DMARC RUF ARF envelope dkim=fail / spf=fail / dmarc=fail evidence rows are the application-layer COUNTERPART to the per-publisher per-domain TRANSPORT-layer RFC 8460 TLS-RPT JSON-aggregate certificate-host-mismatch / certificate-expired / certificate-not-trusted / validation-failure / sts-policy-fetch-error result-type rows the MTA-STS publication discipline THIS page produces — the operator who consumes BOTH streams in lockstep operates a full-stack per-publisher per-domain message- authentication-AND-transport-security observability surface; (ii) per- publisher per-domain RFC 8460 TLS-RPT JSON-aggregate report `summary.total- failure-session-count` SPIKE under sts-policy-fetch-error / certificate-host-mismatch result-types is the transport-layer UPSTREAM evidence-signal that ALSO retrospectively explains the application- layer ARF envelope's dkim=temperror / dkim=fail evidence-row spike when transport-layer SMTP delivery latency cascades into per-receiver verifier-side DNS-resolver timeout cascades — the forensic-reports spoke catalogues this cross-layer evidence- propagation pattern as the canonical operator-discipline diagnostic for per- publisher per-domain MTA-STS publication regression cascading into application- layer authentication observability; (iii) per-publisher per-domain BIMI-asset HTTPS-delivery TLS-handshake- failure-class evidence is captured in the SAME RFC 8460 TLS-RPT JSON-aggregate stream THIS page's MTA-STS publication discipline produces AND parallel to the per-failure ARF envelope's per-message application-layer-authentication-failure evidence — the operator who consumes the cross-protocol RFC 8460 TLS-RPT result-type enumeration alongside the per-failure ARF envelope evidence stream maintains a UNIFIED per-publisher per-domain transport-layer-AND-application- layer authentication-AND-encryption-posture observability surface; (iv) per- publisher per-domain DMARC p=reject terminal-state enforcement readiness is empirically validated by the COMBINED application-layer-DMARC-aligned-pass-rate- floor from the per-failure ARF envelope stream AND transport-layer-MTA-STS-policy- fetch-success-rate-floor from the TLS-RPT JSON-aggregate stream — the forensic-reports spoke catalogues the per-failure ARF envelope as the application-layer evidence-floor whose coupling with the MTA-STS-published transport-layer evidence-floor is the LOAD-BEARING per-publisher per-domain ramp-readiness gating discipline for the per-publisher per-domain DMARC terminal- state policy commitment. Read THIS page when AUTHORING the per-publisher per- domain MTA-STS-WITH-TLS-RPT transport- layer publication discipline; read the forensic-reports spoke when CONSUMING the application-layer DMARC RUF ARF envelope evidence stream that is the STRUCTURAL PARALLEL to the transport-layer TLS-RPT JSON-aggregate stream THIS page produces at the per-publisher per-domain layered- observability boundary.
• DKIM troubleshooting — the PER-MESSAGE-DKIM-FAILURE-MODE- DIAGNOSTIC-LADDER-AS-APPLICATION-LAYER- AUTHENTICATION-LEG-DISCIPLINE-COMPLEMENT-FOR- MTA-STS-TRANSPORT-LAYER-HARDENING companion to this MTA-STS-explained transport-layer reference. Where THIS page documents the per- publisher per-domain MTA-STS HTTPS-served policy publication discipline (mta-sts. <domain> well-known endpoint serving mode: testing/enforce + mx: hostname-pattern allowlist + max_age: seconds at the per- publisher per-domain transport-layer boundary), the DKIM-troubleshooting spoke is the per-message DKIM-failure-mode diagnostic- ladder reference operators consult at the per-publisher per-domain APPLICATION-LAYER authentication-discipline boundary that per-publisher per-domain mail flow must cross-coordinate with transport-layer MTA- STS publication at FOUR per-failure-mode cross-layer coordination dimensions: (i) per-publisher per-domain MTA-STS testing-mode publication coordinated with per-publisher per-domain DKIM-failure-mode baseline-survey discipline — per- publisher operators deploying per-publisher per-domain MTA-STS testing-mode publication as the first per-publisher per-domain transport-layer hardening rollout step concurrently survey per-publisher per- domain DKIM-failure-mode baseline state (per-selector publication audit + per- canonicalization-mode survey + per-key- size + per-rotation-cadence baseline) because the per-publisher per-domain transport-layer hardening rollout commits the per-publisher per-domain to per- message DKIM-signed-mail-flow with cryptographic-trust-anchor consistency the per-publisher per-domain DKIM-failure-mode baseline-survey discipline IS the diagnostic-discipline reference for; (ii) per-publisher per-domain MTA-STS enforce-mode publication coordinated with per-publisher per-domain DKIM-failure-mode terminal-discipline-floor — per- publisher operators committing per-publisher per-domain MTA-STS enforce-mode publication (the per-publisher per-domain transport- layer terminal-hardening commitment) MUST have per-publisher per-domain DKIM-failure- mode terminal-discipline-floor in place because per-publisher per-domain transport- layer enforce-mode rejection of per-message STARTTLS-downgrade attempts presupposes per-message DKIM-signed-mail-flow whose per-publisher per-domain DKIM-failure-mode terminal-discipline-floor matches the per- publisher per-domain MTA-STS enforce-mode terminal-discipline-floor at the cross- layer boundary; (iii) per- publisher per-domain MTA-STS policy-fetch per-receiver TLS-RPT evidence stream coordinated with per-publisher per-domain DKIM-failure-mode per-receiver per-message Authentication-Results-header evidence stream — per-publisher per-domain operators reading per-receiver-side TLS- RPT JSON evidence streams (the per- publisher per-domain transport-layer observability primitive THIS page documents the publication discipline of) cross- reference per-receiver-side per-message Authentication-Results-header evidence streams (the per-publisher per-domain application-layer observability primitive the DKIM-troubleshooting spoke documents the per-failure-mode diagnostic discipline for) when triaging per-publisher per- domain per-receiver per-message deliverability anomalies that correlate across both layers; (iv) per- publisher per-domain MTA-STS policy-mode rollback discipline coordinated with per- publisher per-domain DKIM-failure-mode rollback discipline — when per- publisher per-domain operators detect per- publisher per-domain deliverability KPI degradation post per-publisher per-domain MTA-STS enforce-mode rollout, the per- publisher per-domain rollback discipline applies BOTH to the transport-layer publication (downshift MTA-STS mode from enforce back to testing while investigating sts-policy-fetch-error patterns) AND verifies per-publisher per-domain DKIM- failure-mode discipline-floor stability across the rollback window — per-publisher per-domain DKIM-troubleshooting per-failure- mode diagnostic-discipline reference is the per-publisher per-domain operational cross-reference per-publisher per-domain operators consult during cross-layer rollback coordination. Read the DKIM- troubleshooting spoke alongside this MTA- STS-explained reference when AUTHORING per-publisher per-domain cross-layer (application-layer DKIM + transport-layer MTA-STS) rollout coordination runbooks, when AUDITING per-publisher per-domain DKIM-signing posture BEFORE committing to per-publisher per-domain MTA-STS enforce- mode rollout, when EXECUTING per-publisher per-domain per-receiver-side TLS-RPT-and- Authentication-Results cross-evidence- stream triage, or when ESTABLISHING per- publisher per-domain joint cross-layer rollback discipline coordinating MTA-STS mode downshift with per-publisher per- domain DKIM-failure-mode discipline-floor stability verification.
• RFC 8461 - SMTP MTA Strict Transport Security - the MTA-STS specification itself.
• RFC 8460 - SMTP TLS Reporting - the companion reporting standard.
• RFC 7672 - DANE for SMTP - the DNSSEC-based alternative trust anchor.
• BIMI SVG Tiny PS requirements — the per-publisher per-domain BIMI SVG Tiny PS asset-HTTPS-fetch trust-chain publication-discipline companion to this MTA-STS-protocol-pillar reference. Where THIS page documents the per-publisher per- policy-domain RFC 8461 MTA-STS HTTPS- policy-host publication discipline (the _mta-sts.<d> TXT-RR version + policy ID publication, the https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication, the per- publisher per-policy-domain enforce-mode policy choice that gates the receiver-side STARTTLS-fail-closed behavior), the BIMI SVG Tiny PS requirements spoke is the PER- PUBLISHER-PER-DOMAIN-BIMI-SVG-TINY-PS- ASSET-FORMAT-PUBLICATION reference documenting the BIMI Group Tiny PS SVG profile (baseProfile="tiny-ps", square viewBox, forbidden script / animation / external-reference / raster element list), the per-publisher per-domain BIMI-record l=https://.../svg SVG-asset URL publication, the per-publisher per-domain a=https://.../vmc VMC-cert URL publication, and the per-receiver BIMI logo- display gate SVG-fetch trust chain. Four CROSS-LAYER-HTTPS-TRUST-CHAIN-PUBLICATION- COUPLING dimensions the BIMI SVG Tiny PS requirements spoke documents: (i) per-publisher per-domain HTTPS- published-asset trust-chain publication- discipline parallel at distinct protocol layers — both the per-publisher per-policy-domain MTA-STS HTTPS-policy-host file publication this page documents and the per-publisher per-domain BIMI SVG Tiny PS asset + VMC HTTPS-published-asset publication the BIMI SVG Tiny PS requirements spoke documents are per- publisher per-domain HTTPS-asset-publication primitives at distinct protocol layers (transport-layer MTA-STS policy vs display- layer BIMI logo + VMC); (ii) per- publisher per-domain Web-PKI-CA-issued- HTTPS-cert-chain trust-anchor parallel — both the per-publisher per-policy-domain https://mta-sts.<d> HTTPS-policy-host endpoint and the per- publisher per-domain BIMI-asset HTTPS endpoints (https://.../svg + https://.../vmc) depend on Web- PKI CA-issued TLS cert-chains whose per- publisher per-domain trust-anchor publication discipline must be coordinated; (iii) per-publisher per-policy- domain MTA-STS HTTPS-policy-host availability as cross-protocol-pillar HTTPS-asset- publication discipline-correctness baseline — the per-publisher per- policy-domain MTA-STS HTTPS-policy-host availability discipline THIS page documents (the publication-host SLA, the policy-host cert renewal cadence, the policy-host server configuration) is the per-publisher per- domain HTTPS-asset-publication discipline- correctness baseline that the per-publisher per-domain BIMI SVG + VMC HTTPS-asset- publication discipline the BIMI SVG Tiny PS requirements spoke documents inherits; (iv) per-publisher per-domain transport-layer-encryption-discipline as upstream cross-protocol-pillar prerequisite for BIMI display-gate trust-chain integrity — the per-publisher per- policy-domain MTA-STS-enforce transport- layer encryption-discipline THIS page documents is the load-bearing upstream cross-protocol-pillar prerequisite for the per-publisher per-domain BIMI display-gate trust-chain integrity the BIMI SVG Tiny PS requirements spoke documents — both per- publisher per-domain HTTPS-published-asset trust-chain integrity primitives compose at the per-publisher per-domain cross-protocol- pillar HTTPS-publication-discipline boundary. Read the BIMI SVG Tiny PS requirements spoke alongside this MTA-STS-protocol-pillar reference when DESIGNING the per-publisher per-domain cross-protocol-pillar HTTPS- published-asset trust-chain publication discipline that pairs per-publisher per- policy-domain MTA-STS HTTPS-policy-host publication with per-publisher per-domain BIMI SVG Tiny PS HTTPS-asset publication at the per-publisher per-domain transport- layer-encryption-and-display-layer-asset- delivery composition boundary.
• DMARC for SaaS senders — the APPLICATION-LAYER per-SaaS- sender per-customer-domain authentication-publication peer to this TRANSPORT-LAYER per-publisher per-policy-domain MTA-STS policy- publication-discipline reference. Where THIS page documents the per- publisher per-policy-domain TRANSPORT- LAYER MTA-STS publication (the _mta-sts.<d> TXT-RR + the https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file + the mode: enforce policy-mode choice), the SaaS-sender DMARC spoke documents the per-SaaS-sender per- customer-domain APPLICATION-LAYER authentication publication (the per- customer-domain DMARC TXT publication, the per-customer-domain SPF-include cascade include:<saas>.com authorising the SaaS-sender outbound IP cone, and the per-customer-domain DKIM-CNAME delegation <selector>._domainkey.<customer> → <selector>.<saas>.com publishing the SaaS-sender-managed DKIM key under the customer's domain). Read the SaaS-sender DMARC spoke when composing the per-publisher per- domain CROSS-LAYER authentication-and- transport publication discipline across BOTH the APPLICATION-LAYER SaaS-sender per-customer-domain SPF + DKIM + DMARC publication this spoke catalogues AND the TRANSPORT-LAYER per-policy-domain MTA-STS publication this page documents — the two layers together close the per-publisher per- customer-domain authentication-and- transport publication-discipline surface a multi-tenant SaaS sender coordinates across its customer portfolio.
• SPF DNS record syntax — the APPLICATION-LAYER PER-PUBLISHER-PER- DOMAIN SPF-RECORD-BYTE-GRAMMAR-AS-PEER- PUBLICATION-DISCIPLINE-STACKED-BENEATH-THE- TRANSPORT-LAYER-MTA-STS-PUBLICATION-DISCIPLINE companion to THIS page's per-publisher per- policy-domain MTA-STS publication discipline. Where THIS page documents the per-publisher per-policy-domain MTA-STS publication discipline — the _mta-sts TXT record, the HTTPS-served policy file at https://mta-sts.example.com/.well-known/mta-sts.txt, the mode: enforce / mode: testing / mode: none transition cadence, and the per-MX-host validation envelope the per-receiver-MTA enforces against per- publisher per-policy-domain outbound SMTP traffic — at the TRANSPORT-LAYER publication-discipline boundary, the SPF- DNS-syntax spoke is the APPLICATION-LAYER PEER-PUBLICATION-DISCIPLINE reference documenting the per-publisher per-domain SPF-record TXT-RR syntactic publication discipline whose byte-level compliance is the load-bearing PRECONDITION for the application-layer per-message spf=pass-AND-aligned cascade into the DMARC verdict that runs ATOP the transport-layer encryption envelope THIS page's MTA-STS publication discipline establishes. The two spokes occupy COMPLEMENTARY LAYERS of the per-publisher per-domain email-authentication-and- transport security model: MTA-STS establishes the TRANSPORT-LAYER per- receiver-MTA STARTTLS-enforcement floor protecting per-message SMTP delivery from opportunistic STARTTLS-downgrade MITM at the transport-layer boundary; SPF-DNS- syntax establishes the APPLICATION-LAYER per-publisher per-domain sender-IP- authorization publication-discipline floor whose syntactic correctness sustains the per-message spf=pass- AND-aligned cascade at the per-message application-layer alignment-evaluation boundary. Read THIS page when AUTHORING the per-publisher per-policy-domain TRANSPORT-LAYER MTA-STS publication discipline; read the SPF-DNS-syntax spoke when AUTHORING the per-publisher per-domain APPLICATION-LAYER SPF-record byte-grammar publication discipline whose syntactic- correctness floor sustains the application- layer per-message DMARC-aligned-pass cascade that runs ATOP the transport-layer MTA-STS enforcement envelope THIS page's publication discipline establishes.
• DMARC policy rollout — the APPLICATION-LAYER-PER-PUBLISHER-PER- DOMAIN-DMARC-POLICY-RAMP-AS-PEER-PHASED- DEPLOYMENT-DISCIPLINE-TO-TRANSPORT-LAYER- MTA-STS-MODE-RAMP-DISCIPLINE companion to this per-publisher per-domain transport- layer MTA-STS publication-and-mode-progression reference. Where THIS page documents the per-publisher per-domain transport-layer MTA-STS phased-deployment discipline (the mode: none publication-only phase, the mode: testing TLS- RPT-observed phase where transport-layer failures emit but do NOT bounce, the mode: enforce hard-fail phase where transport-layer non-compliance bounces), the policy-rollout spoke documents the FOUR PER-APPLICATION-LAYER-DMARC-RAMP- PHASE-AS-PEER-TO-TRANSPORT-LAYER-MTA-STS- MODE-PHASE coordination DIMENSIONS the per- publisher per-domain operator MUST jointly execute to sustain coherent cross-layer phased-deployment posture: (i) per- publisher per-domain joint cross-layer rollout-cadence SEQUENCING — the canonical per-publisher per-domain joint cross-layer rollout sequence is MTA-STS mode: none + DMARC p=none → MTA-STS mode: testing + DMARC p=quarantine(pct=10..100) → MTA-STS mode: enforce + DMARC p=reject; advancing one layer's phase without the corresponding peer-layer advancement defeats the joint cross-layer observability discipline; (ii) per- publisher per-domain joint cross-layer ROLLBACK CASCADE under per-phase advancement- gate-failure — the per-publisher per-domain operator MUST treat a per-phase- advancement-gate failure on EITHER layer as a JOINT rollback trigger that reverts BOTH layers to the prior phase simultaneously, because per-receiver per-day deliverability regression observed under per-phase advancement cannot be ROOT-CAUSE-attributed to a single layer when the joint cross-layer phase progression is mid-step; (iii) per- publisher per-domain joint cross-layer per- receiver per-day OBSERVABILITY-STREAM CO-INGESTION — the per-publisher per-domain operator MUST co-ingest the application-layer per-day per-receiver DMARC rua= aggregate report AND the transport-layer per-day per-sender TLS-RPT aggregate report into the SAME per-publisher operator dashboard so a per-receiver per-day deliverability regression observed during a per-phase joint advancement can be ROOT- CAUSE-attributed to the SPECIFIC application- layer-vs-transport-layer per-phase advancement whose configuration caused the regression; (iv) per-publisher per-domain joint cross-layer per-phase WAIT-DURATION DISCIPLINE — the per-publisher per-domain operator MUST hold each per-phase joint cross-layer configuration for a per-phase minimum observation window (4-week per-receiver per- day aggregate-report observation per phase is the load-bearing wait-duration discipline) BEFORE advancing to the next joint cross- layer phase, because per-receiver per-day deliverability evidence below the per-phase- minimum observation window is per-receiver- aggregate-sampling-noise-dominated. Read the policy-rollout spoke ALONGSIDE this MTA-STS phased-deployment reference whenever the per- publisher per-domain operator COORDINATES the application-layer DMARC ramp with the transport-layer MTA-STS mode ramp — the per- application-layer-DMARC-ramp-phase-as-peer- to-transport-layer-MTA-STS-mode-phase coordination catalogue is the canonical operator-facing companion every per-publisher per-domain joint cross-layer-deployment operator MUST master to sustain coherent cross-layer phased-deployment posture.
• SPF mechanisms explained — the APPLICATION-LAYER-SPF-MECHANISM- VOCABULARY-AS-CROSS-LAYER-PEER-OF-MTA-STS- TRANSPORT-LAYER-MX-ALLOW-LIST-MECHANISM companion to this RFC 8461 MTA-STS protocol pillar. Where THIS page documents the per- publisher per-domain TRANSPORT-LAYER MTA-STS policy publication discipline (the _mta-sts.<domain> TXT-ID- record publication, the mta-sts.<domain> HTTPS policy-host hosting topology, the per-publisher mode=enforce / mode=testing / mode=none ramp discipline, the per-publisher MX-allow-list pinning to the canonical per-domain MX-RR-host targets, the per-publisher max_age cache-policy publication, and the parallel per-publisher TLS-RPT _smtp._tls.<domain> RUA publication for failure-report ingestion), the SPF-mechanisms spoke is the APPLICATION- LAYER-PARALLEL-PUBLISHER-AUTHORIZATION- VOCABULARY companion documenting the per- publisher per-domain SPF authorization-vocabulary publication discipline whose application-layer publisher-discipline mechanics parallel the transport-layer MTA-STS publisher-discipline mechanics THIS page architectures. The MTA-STS- vs-SPF-mechanisms relationship is cross-layer- publisher-discipline-parallel-with-distinct- scope: MTA-STS publishes per-publisher per- domain transport-layer authorization at the MX-RR-host boundary; SPF publishes per-publisher per-domain application-layer authorization at the envelope-MAIL-FROM source-IP boundary; both are per-publisher per-domain publisher- side authorization-vocabulary publication disciplines. Four cross-layer per-publisher- publication-discipline-parallel dimensions matter at the per-publisher per-domain coherent-publisher-posture boundary: (i) per- publisher per-domain MTA-STS mx: allow-list mechanism PARALLELS per-publisher per-domain SPF mx: mechanism — both anchor publisher-side authorization to the per-publisher per-domain MX-RR-host topology, providing dual-layer (transport + application) authorization-binding to the same per-publisher per-domain MX-RR-host; (ii) per-publisher per-domain MTA-STS mode=enforce / mode=testing ramp discipline PARALLELS per-publisher per-domain SPF -all hardfail / ~all softfail default-disposition ramp — both gradate from observation to enforcement at the per-publisher per-domain operator- controlled tightening boundary; (iii) per- publisher per-domain MTA-STS max_age cache-policy publication PARALLELS per-publisher per-domain SPF TXT-record TTL publication — both gate the per-receiver per-resolver per-publisher per- domain authorization-policy propagation cache- lifetime window at the publisher-side TTL- publication discipline boundary; (iv) per- publisher per-domain MTA-STS HTTPS policy- host publication PARALLELS per-publisher per- domain SPF cumulative DNS-lookup budget discipline — both impose per-publisher per- domain publication-discipline operational complexity overhead at the per-publisher per- domain authoritative-zone publication-cadence boundary, requiring per-publisher per-domain operator competence at the HTTPS-policy-host certificate-renewal and per-publisher per- domain SPF include-cascade flattening respective disciplines. Read THIS page when AUTHORING the per-publisher per-domain transport-layer MTA-STS publication discipline; read the SPF-mechanisms spoke when AUTHORING the per-publisher per-domain application-layer SPF authorization-vocabulary publication discipline whose cross-layer publisher- discipline parallels the MTA-STS transport- layer publication discipline THIS page architectures at the per-publisher per-domain coherent-publisher-posture boundary.
• Email authentication ecosystem — the per-publisher per-domain four-protocol application-layer integration framework (SPF envelope-MAIL-FROM authorization + DKIM per- message cryptographic-signature + DMARC alignment-and-policy + ARC forwarder-rescue) whose transport-layer-TLS-enforcement- complement THIS MTA-STS protocol pillar structurally provides at the per-publisher per-domain inbound-MX-receive-side TLS- handshake-protection boundary, at four cross-layer ecosystem-vs-transport-layer coupling dimensions: (i) per- publisher per-domain MTA-STS policy-file publication as the transport-layer ENFORCE-MODE TLS-handshake-protection primitive STRUCTURALLY PARALLEL to the application-layer per-publisher per-domain DMARC p=reject pct=100 terminal-state enforcement primitive the email-authentication-ecosystem framework documents — both transport-layer MTA-STS mode: enforce and application-layer DMARC p=reject publication-decisions represent per-publisher per-domain terminal-state enforcement-tier publication-discipline the ecosystem framework's progressive- publication-ramp methodology converges towards; (ii) per-publisher per- domain MTA-STS policy-file ramp-progression through mode: none → mode: testing → mode: enforce tiers STRUCTURALLY PARALLEL to per-publisher per-domain DMARC p=none → p=quarantine → p=reject policy-tier ramp- progression the email-authentication- ecosystem framework documents — the per-publisher per-domain operator's per-protocol per-tier ramp-advancement- readiness gate methodology applies consistently across both transport-layer MTA-STS publication-discipline and application-layer DMARC publication- discipline within the unified ecosystem framework; (iii) per-publisher per-domain MTA-STS receive-side TLS- handshake-protection complements the application-layer SPF + DKIM + DMARC evidence the ecosystem framework's per- receiver per-day per-source-IP per-row RUA-XML evidence stream surfaces with a per-receiver per-session-pair RFC 8460 TLS-RPT JSON-aggregate transport-layer evidence stream the ecosystem framework's defense-in-depth full-stack observability operator-discipline materially consumes — the per-publisher per-domain application-layer per-row RUA aggregate + transport-layer per-session-pair TLS- RPT aggregate dual-stream is the canonical full-stack observability primitive the ecosystem framework's operator-discipline runbook documents; (iv) per- publisher per-domain MTA-STS DNS-anchored publication discipline (`_mta-sts.<d>` TXT-record + `mta-sts.<d>` HTTPS-served policy-file) sits at the per-publisher per-domain authoritative-DNS-zone publication boundary the same boundary the application-layer SPF / DKIM / DMARC TXT-records publish at within the ecosystem framework's per-publisher per- domain publication-coherence operator- discipline — the per-publisher per-domain operator's per-protocol publication-coordination MUST author ALL four application-layer DNS-records + the transport-layer MTA-STS + TLS- RPT DNS-records at the same per-publisher per-domain authoritative-zone publication boundary the ecosystem framework's per- publisher per-domain publication- coherence discipline requires. Read the email-authentication-ecosystem pillar alongside this MTA-STS transport-layer protocol pillar when the per-publisher per-domain operator is coordinating per- publisher per-domain transport-layer MTA-STS publication-discipline with the per-publisher per-domain application- layer SPF + DKIM + DMARC + ARC publication-discipline within the unified per-publisher per-domain four-plus-one- protocol publication-coherence operator- discipline, when planning the per- publisher per-domain MTA-STS mode-tier ramp progression concurrent with the per- publisher per-domain DMARC policy-mode- tier ramp progression, or when authoring the per-publisher per-domain per-protocol full-stack defense-in-depth observability runbook that consumes the application- layer RUA-aggregate-evidence + transport- layer TLS-RPT-aggregate-evidence dual- stream the per-publisher per-domain operator-discipline floor materially consumes.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the PER-PUBLISHER-PER-DOMAIN-MTA-STS-MODE- TIER-RAMP-AS-TRANSPORT-LAYER-PARALLEL-OF-PER- PUBLISHER-PER-DOMAIN-DMARC-APPLICATION-LAYER- POLICY-MODE-TIER-RAMP companion to THIS MTA- STS transport-layer protocol pillar. Where THIS page documents the per-publisher per- domain MTA-STS publication discipline (the _mta-sts.<d> TXT-RR version-and-ID token publication per RFC 8461 §3.1, the mta-sts.<d> HTTPS-served policy-file YAML grammar per RFC 8461 §3.2, the per-publisher per-domain mode: three-state tier ladder (none, testing, enforce), the per-publisher per-domain mx: wildcard-aware receiver-MX allow-list authoring discipline, and the per-publisher per-domain max_age: cache-TTL discipline coordinating receiver- side policy-cache invalidation), the DMARC- policy-modes spoke documents the publisher- side three-state p=-tag application-layer enforcement-policy ladder (p=none observe-only, p=quarantine probation, p=reject terminal) whose per- phase progression cadence the per-publisher per-domain MTA-STS mode-tier ramp progression structurally MIRRORS at FOUR per-publisher per-domain transport-layer-vs-application- layer policy-mode-tier-ramp-coordination dimensions: (i) per-publisher per- domain MTA-STS mode=testing → mode=enforce transport-layer phase transition as structurally-parallel of per-publisher per-domain DMARC p=none → p=quarantine → p=reject application-layer phase transition — both per- publisher per-domain mode-tier ramps progress through OBSERVE-ONLY (mode=none on the transport-layer rail / p=none on the application-layer rail) → PROBATION (mode=testing / p=quarantine) → TERMINAL- ENFORCEMENT (mode=enforce / p=reject) phases at the same per-publisher per-domain operator-discipline cadence, and the per-publisher per-domain operator-discipline floor materially benefits from per-publisher per-domain joint mode- tier-ramp-cadence coordination at the per- publisher per-domain authoritative-zone publication-coherence boundary; (ii) per-publisher per-domain MTA-STS mode-tier ramp + per-publisher per-domain DMARC policy-mode-tier ramp JOINT phase- advancement gating — the per- publisher per-domain operator advances per- publisher per-domain MTA-STS mode=testing → mode=enforce ONLY AFTER the per-publisher per-domain DMARC policy-mode ramp is stable at per-publisher per-domain p=quarantine / p=reject phase, because the per-publisher per-domain joint MTA-STS- mode=enforce-bounce-on-TLS- violation + DMARC-p=reject- bounce-on-identifier-misalignment per-message rejection blast-radius requires per- publisher per-domain operator-side incident- response capability matured during the per- publisher per-domain lower-mode-tier monitoring period BEFORE per-publisher per- domain joint terminal-enforcement commitment; (iii) per-publisher per-domain MTA- STS policy-file id: sequence- number bump on every policy change as per- publisher per-domain DMARC policy-mode-ramp PHASE-FREEZE coordination boundary — a per-publisher per-domain MTA-STS policy-file change during per-publisher per- domain DMARC mode-ramp risks per-receiver- side caching of stale per-publisher per- domain MTA-STS policy + per-publisher per- domain RUA aggregate-XML report's per- source-IP per-record attribution gap (the per-receiver per-day per-publisher per- domain RUA aggregate-XML attributes per- message disposition outcomes to a per- publisher per-domain SPF + DKIM evidence state the per-publisher per-domain MTA- STS-update has invalidated at the per- publisher per-domain transport-layer delivery boundary), so per-publisher per- domain operator-discipline FREEZES per- publisher per-domain MTA-STS policy-file changes during per-publisher per-domain DMARC mode-ramp phase advancement; (iv) per-publisher per-domain per- receiver per-day TLS-RPT JSON aggregate report + per-receiver per-day DMARC RUA XML aggregate report dual-stream observability surface for joint transport- layer-vs-application-layer mode-tier-ramp phase enforcement-distribution evidence — the per-publisher per- domain operator reads BOTH per-day per- receiver per-publisher per-domain TLS-RPT JSON aggregate-report's per-MX-host per- TLS-handshake-outcome distribution AND per- day per-receiver per-publisher per-domain DMARC RUA aggregate-XML report's per- source-IP per-disposition row distribution to correlate per-day per-receiver per- publisher per-domain transport-layer MTA- STS mode-tier-ramp phase enforcement- outcome with per-day per-receiver per- publisher per-domain application-layer DMARC policy-mode-ramp phase enforcement- disposition distribution at the per- publisher per-domain joint cross-layer operator-discipline boundary. Read THIS MTA-STS transport-layer protocol pillar when PUBLISHING the per-publisher per- domain MTA-STS mode-tier ramp discipline AND when COORDINATING the per-publisher per-domain joint transport-layer-mode- tier-ramp + application-layer-policy-mode- tier-ramp cadence; read the DMARC-policy- modes spoke when COORDINATING the per- publisher per-domain application-layer DMARC enforcement-ramp phase advancement against the per-publisher per-domain transport-layer MTA-STS mode-tier-ramp progression THIS page documents.
• SPF forwarding issues
• Email authentication glossary
• SPF qualifiers explained
• DKIM failures explained
• DMARC aggregate (RUA) reports
• DKIM selectors explained — the PER-PUBLISHER-PER-SELECTOR-DKIM-TXT-RR-APPLICATION-LAYER-DNS-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-APPLICATION-LAYER-DNS-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-PUBLISHER-PER-POLICY-DOMAIN-MTA-STS-TRANSPORT-LAYER-DNS-AND-HTTPS-PUBLICATION-DISCIPLINE companion at four MTA-STS-transport-layer-vs-DKIM-selector-application-layer DNS-publication-discipline coupling dimensions (per-publisher per-selector DKIM TXT-RR publication at <selector>._domainkey.<domain> per RFC 6376 §3.6.2.2 IS structurally parallel to per-publisher per-policy-domain MTA-STS _mta-sts.<domain> TXT-RR publication per RFC 8461 §3.1 — both per-publisher per-domain DNS-TXT-RR publication-discipline references are per-publisher per-domain operator-side composite-DNS-publication-discipline-integrity primitives at the per-publisher per-domain composite cross-protocol DNS-TXT-RR publication-discipline coordination boundary THIS MTA-STS deep-dive documents the per-publisher per-policy-domain transport-layer publication-discipline of / per-publisher per-selector DKIM dkim=permerror verdict-fail traceable to mis-published <selector>._domainkey.<d> TXT-RR byte-grammar crossing RFC 1035 255-octet character-string boundary at 2048-bit RSA p= public-key encoding IS structurally parallel to per-publisher per-policy-domain MTA-STS sts-policy-invalid verdict-fail traceable to mis-published https://mta-sts.<domain>/.well-known/mta-sts.txt policy-file byte-grammar violating RFC 8461 §3.2 policy-file syntax — both per-publisher per-domain publication-discipline-byte-grammar verdict-fail root-cause traceability ladders are per-publisher per-domain operator-actionable per-day per-receiver evidence-driven publication-discipline drift-closure primitives / per-publisher per-selector DKIM dkim=temperror verdict-fail traceable to per-publisher per-selector transient DNS-resolver-timeout at <selector>._domainkey.<d> resolution IS structurally parallel to per-publisher per-policy-domain MTA-STS sts-policy-fetch-error verdict-fail traceable to per-publisher per-policy-domain transient DNS-resolver-timeout at _mta-sts.<domain> resolution OR transient HTTPS-policy-host TLS-handshake-failure at https://mta-sts.<domain> — both per-publisher per-domain transient DNS-resolution-and-policy-fetch verdict-fail traceability ladders are per-publisher per-domain operator-side transient-failure-mode publication-discipline drift-closure primitives / per-publisher per-selector DKIM key-rotation operational discipline (selector-namespace-segregation by traffic stream + zero-downtime rotation via parallel selector publication + selector-namespace-decommission cadence) IS structurally parallel to per-publisher per-policy-domain MTA-STS mode: testing → mode: enforce two-stage transport-layer ramp publication-readiness baseline per RFC 8461 §5.2 — both per-publisher per-domain operator-side publication-discipline-ramp-progression primitives gate per-publisher per-domain composite cross-protocol publication-discipline-integrity at the per-publisher per-domain composite cross-protocol publication-discipline-ramp-progression coordination boundary THIS MTA-STS deep-dive documents the per-publisher per-policy-domain transport-layer publication-discipline of).
• SPF 10-DNS-lookup limit
• DKIM key rotation
• SPF PermError vs TempError
• DKIM alignment with DMARC — the application-layer companion to the transport-layer enforcement this MTA-STS page documents. MTA-STS hardens how mail reaches the MX; DMARC decides whether the message authenticates, and a DKIM signature only counts toward a DMARC pass when its d= domain aligns (relaxed or strict) with the From-header domain. Read the alignment spoke for the message-layer verdict that runs alongside the transport posture here.
• DMARC alignment explained — MTA-STS hardens the transport hop, but whether a message is authenticated turns on DMARC alignment: the SPF- or DKIM-validated identifier must match the visible RFC5322.From domain (relaxed or strict). This spoke documents that alignment rule — the message-layer identity check that runs orthogonally to the transport-layer encryption posture this page configures. Read it to see how the two layers compose into a complete defence.
• Microsoft SNDS + JMRP monitoring — transport security decides whether mail travels over verified TLS; Microsoft's IP-reputation gate decides which folder it lands in. SNDS + JMRP monitoring covers that consumer-network reputation layer for Outlook.com/Hotmail recipients.

13. Audit your MTA-STS setup now

DMARC Analyzer's free Domain Security Checker performs live MTA-STS lookups: it queries the _mta-sts DNS record, fetches the /.well-known/mta-sts.txt policy file over HTTPS, validates the version, mode, MX list, and max_age, and confirms that the certificate on mta-sts.<domain> chains to a public-PKI root. It also flags missing TLS-RPT records so you can spot the most common monitoring gap before it bites production.

Check my MTA-STS record Sign up — Free plan