DMARC Analyzer

TL;DR

An MTA-STS policy is a plain-text key-value file served from https://mta-sts.<domain>/.well-known/mta-sts.txt with four mandatory keys. The policy-file syntax is governed by RFC 8461 §3.2.

• version: STSv1 — mandatory, case-sensitive uppercase STSv1, MUST appear first.
• mode: enforce|testing|none — mandatory deployment-stage tag, case-sensitive lowercase. enforce applies the policy, testing produces TLS-RPT reports without bouncing, none disables.
• mx: <pattern> — one or more lines naming acceptable MX hostnames. Each entry is either an exact hostname (mail.example.com) or a single-label wildcard (*.example.com) matching one DNS label of depth-one expansion.
• max_age: <seconds> — mandatory policy cache lifetime. Maximum 31557600 (one year) per RFC 8461.
• HTTPS-only — the policy URL MUST use HTTPS with a publicly-trusted CA certificate. Self-signed and private-PKI certs are rejected.
• No BOM — UTF-8 byte-order marks at file head cause the policy to be rejected (the version line fails to match).
• No comments — RFC 8461 §3.2 defines only key-value lines; any unrecognised line (including `# comment`) is treated as malformed and the policy is rejected.
• DNS coupling — the policy file is paired with a _mta-sts.<domain> TXT record carrying an id=<token> tag. Every policy change MUST be accompanied by a new id token so senders re-fetch.

The Domain Security Checker validates the live policy file from multiple geographic resolvers and surfaces every syntactic drift class documented on this page. Use TLS-RPT to monitor policy enforcement outcomes after deployment.

1. What "policy file syntax" means for MTA-STS

MTA-STS is a two-layer specification. The DNS LAYER publishes a _mta-sts.<domain> TXT record with v=STSv1; id=<token> that signals senders WHEN to re-fetch the policy. The POLICY LAYER serves the actual policy content from https://mta-sts.<domain>/.well-known/mta-sts.txt — a plain-text key-value file with the four canonical keys governing what TLS posture senders enforce for inbound mail.

This page covers the POLICY-LAYER SYNTAX exhaustively. The protocol-level context lives in the sibling reference pages:

• MTA-STS explained — the protocol pillar — what MTA-STS is, how it works at the protocol level, the relationship to STARTTLS, the trust-anchor model, and the deployment workflow.
• MTA-STS vs DANE for SMTP — the policy-mechanism decision view between MTA-STS (web-PKI trust anchor) and DANE (DNSSEC trust anchor).
• TLS-RPT explained — the operational feedback loop that makes MTA-STS deployable. Without TLS-RPT, an enforce-mode policy failure is invisible.

Why the policy-file syntax matters independently: a syntactically malformed policy file is silently REJECTED by every conformant sender — the sender falls back to opportunistic TLS as if MTA-STS were not deployed at all. There is no error signal to the recipient operator from this layer; the only visible signal is TLS-RPT reports showing policy-type=no-policy-found (or sts-policy-invalid / sts-policy-fetch-error) when the recipient expects policy-type=sts. The syntactic failure modes documented below — UTF-8 BOM at file head, comments in the file, wrong scheme (HTTP instead of HTTPS), wrong Content-Type, malformed wildcard in mx:, capital-letter mode value — are operator-introduced and trivially avoidable once the syntax is understood.

The canonical MTA-STS policy file:

; URL:           https://mta-sts.example.com/.well-known/mta-sts.txt
; Content-Type:  text/plain
; HTTP status:   200
; Body:

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

Every section below documents one syntactic surface of this canonical record.

2. The https://mta-sts.<domain>/.well-known/mta-sts.txt URL

Where: the policy file is served from the well-known location https://mta-sts.<domain>/.well-known/mta-sts.txt per RFC 8461 §3.3, where <domain> is the recipient domain being protected.

Why the mta-sts subdomain: isolating the policy URL under a protocol- specific subdomain lets operators run the MTA-STS HTTPS endpoint on infrastructure independent from the apex web site, with its own CDN, certificate, and routing rules. A common pattern is to point mta-sts.example.com at a CDN edge or a dedicated nginx instance serving static content from /.well-known/mta-sts.txt, while the apex example.com remains on a separate stack.

Operational rule: the sending MTA constructs the URL exactly as https://mta-sts.<recipient-domain>/.well-known/mta-sts.txt and fetches it via a standard HTTPS GET request. The hostname MUST resolve, the TLS certificate MUST validate against the public CA root store for the hostname mta-sts.<domain>, the HTTP status MUST be 200, and the body MUST match the policy-file syntax below.

Common pitfall: serving the policy file from https://example.com/.well-known/mta-sts.txt (apex domain instead of the mta-sts subdomain). RFC 8461 §3.3 specifies the well-known URL on the mta-sts subdomain ONLY; serving from the apex is non-conformant and conformant senders will not discover it. The mta-sts.<domain> name does NOT need to be the same hostname as your MX records — it is purely the policy-serving endpoint.

; DNS — both the apex MX records AND the mta-sts subdomain:
example.com.            IN  MX   10 mail.example.com.
mta-sts.example.com.    IN  A    203.0.113.20
mta-sts.example.com.    IN  AAAA 2001:db8::20

; HTTPS endpoint at mta-sts.example.com serves the policy file:
;   https://mta-sts.example.com/.well-known/mta-sts.txt

3. The HTTPS + public-PKI fetch contract

Scheme: HTTPS only. RFC 8461 §3.3 specifies that senders MUST use HTTPS to fetch the policy file. Plaintext HTTP is rejected — a sender that finds only HTTP available treats the recipient as having no MTA-STS policy.

Certificate trust anchor: the TLS certificate at mta-sts.<domain> MUST validate against the publicly-trusted CA root store (Let's Encrypt, DigiCert, Sectigo, etc.). The same root store senders use for general HTTPS validation applies — self-signed certificates, private-CA certificates, expired certificates, and certificates with hostname mismatches all cause the policy fetch to fail and the policy to be discarded.

Content-Type: the response MUST carry Content-Type: text/plain (or text/plain; charset=utf-8). Other Content-Type values (text/html, application/json, application/octet-stream) cause conformant senders to reject the policy.

HTTP status: the response MUST have status 200. Status 301/302/307/308 redirects MAY be followed by senders (RFC 8461 §3.3) but conformant implementations SHOULD limit the redirect chain to prevent loops. Any 4xx or 5xx response causes the policy fetch to fail.

Operational rule: the endpoint is a high-cardinality fetch target — every sending MTA in the world that decides to deliver mail to your domain will fetch this URL once per cache window. Serve it from a CDN or redundant-edge infrastructure to maintain availability.

Common pitfall: using HTTP-to- HTTPS auto-redirects via a 301 on the mta-sts hostname. Some senders skip redirect-following for the well-known fetch and treat the 301 as a fetch error. Serve the policy file directly via HTTPS GET with status 200, not via redirect.

4. The version: STSv1 tag (RFC 8461 §3.2, MANDATORY)

Tag: version: STSv1
Default: none. The version key is structurally MANDATORY and MUST appear FIRST in the file.
Why: declares the policy as MTA-STS v1. The forward-compatibility hook for any future MTA-STS revision; senders that find an unrecognised version reject the policy and fall back to opportunistic TLS, which is the safe default for unknown protocol versions.
Operational rule: the value is the case-sensitive literal STSv1 — uppercase STS, lowercase v, digit 1. As of 2026 no later version has been published.
Common pitfall: writing version: stsv1 (lowercase) or version: STSv2 (next-version speculation) or version: STS (no v1 suffix). All three cause conformant senders to reject the policy.

; Correct — first line, exact case:
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

; Wrong — lowercase:
version: stsv1
...

; Wrong — version not first:
mode: enforce
version: STSv1
mx: mail.example.com
max_age: 604800

5. The mode: enforce|testing|none tag (RFC 8461 §3.2, MANDATORY)

Tag: mode: <value>
Default: none. The mode key is structurally MANDATORY.
Why: the deployment-stage tag — controls what action sending MTAs take when policy evaluation fails.
Operational rule: exactly one of three values:

mode: enforce

Apply the policy. Senders that fail policy validation (certificate mismatch, MX not in the mx: list, STARTTLS not offered) refuse delivery — the connection is aborted and mail bounces back to the sender with a TLS-related error. This is the production state every deployed MTA-STS policy should ultimately reach.

mode: testing

Parse and evaluate the policy but DO NOT bounce on failure. Senders deliver mail as if MTA-STS were not present, but emit TLS-RPT reports describing what they would have done in enforce mode. This is the canonical pre-enforce burn-in stage — run for 7-14 days, review the TLS-RPT reports for any failures, fix issues, then promote to enforce.

mode: none

Suspend the policy. Senders treat the recipient as having no MTA-STS deployed. The operational use case is policy rollback: when an enforce-mode policy is causing unexpected mail bouncing, the operator switches to mode: none (and bumps the id token in DNS) to disable enforcement immediately while the underlying issue is diagnosed and fixed.

Common pitfall: writing mode: Enforce (capital E) or mode: ENFORCE (uppercase) or mode: strict (unrecognised value). The value is case-sensitive lowercase; any other case or any other value causes the policy to be rejected and senders fall back to opportunistic TLS.

; Correct — lowercase mode value:
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

; Wrong — capital E:
version: STSv1
mode: Enforce
mx: mail.example.com
max_age: 604800

; Wrong — unrecognised value:
version: STSv1
mode: strict
mx: mail.example.com
max_age: 604800

6. The mx: tag (RFC 8461 §3.2, MANDATORY, may repeat)

Tag: mx: <pattern>
Default: none. At least one mx: line is structurally MANDATORY; multiple lines are allowed and aggregate as a list.
Why: names the acceptable MX hostnames for the recipient domain. Senders enforce that the actual MX they connect to (and the SAN on the presented TLS certificate) matches one of the patterns in this list. Without an mx: match, the policy is violated and (in enforce mode) the delivery is refused.
Operational rule: each mx: line names exactly one pattern. Two kinds of patterns:

Exact hostname

mx: mail.example.com — matches only the literal hostname mail.example.com. The conservative pattern; explicit additions required for any new MX.

Single-label wildcard

mx: *.example.com — matches one DNS label of depth-one expansion. Matches mail.example.com, mx1.example.com, mx2.example.com. Does NOT match sub.mail.example.com (two labels) or example.com (zero labels, the apex). The wildcard appears ONLY as the leftmost label; *.example.* and mail.*.example.com are malformed.

Common pitfall: using a multi-label wildcard like **.example.com or *.*.example.com (both malformed), or expecting *.example.com to match the apex example.com (it does not), or expecting it to match backup.mail.example.com (it does not — that is two labels of expansion).

; Correct — exact hostnames enumerated:
version: STSv1
mode: enforce
mx: mail.example.com
mx: backup-mail.example.com
max_age: 604800

; Correct — single-label wildcard:
version: STSv1
mode: enforce
mx: *.example.com
max_age: 604800

; Wrong — multi-label wildcard:
mx: *.*.example.com

; Wrong — middle-label wildcard:
mx: mail.*.example.com

7. The max_age: tag (RFC 8461 §3.2, MANDATORY)

Tag: max_age: <seconds>
Default: none. The max_age key is structurally MANDATORY.
Why: the policy cache lifetime in seconds. Senders cache the fetched policy locally for max_age seconds and do not re-fetch the URL until the cache expires (or the id token in DNS changes).
Operational rule: positive integer, maximum 31557600 seconds (one year, calculated as 365.25 × 86400) per RFC 8461. Recommended values:

• Initial deployment / testing mode: max_age: 86400 (24 hours). Short window so policy changes propagate quickly during the iteration cycle.
• Stable enforce mode: max_age: 604800 (one week) or max_age: 2592000 (30 days). Balances re-fetch traffic against policy-change-propagation latency.
• Production with rare changes: max_age: 31536000 (one year minus a leap-second margin). For the most-stable deployments.

Common pitfall: setting max_age: 31557600 exactly (the upper limit) without realising that a policy rollback then takes up to one year to fully propagate to all senders. The id token bump in DNS forces an early re-fetch, but only for senders that actually look at DNS — conformant implementations check DNS on every delivery, but defensive operators assume the worst-case full-cache-window propagation. Use a moderate max_age and rely on the id token for fast change- propagation when needed.

; Recommended for testing mode (24 hours):
max_age: 86400

; Recommended for stable enforce mode (one week):
max_age: 604800

; Recommended for stable enforce mode (30 days):
max_age: 2592000

; Maximum allowed (one year):
max_age: 31536000

; Wrong — over the RFC maximum:
max_age: 100000000

; Wrong — non-integer:
max_age: 7d

8. No BOM, no comments, no extra whitespace

No UTF-8 BOM: RFC 8461 §3.2 specifies the policy file as plain ASCII / UTF-8 without a byte-order mark. The three-byte BOM sequence EF BB BF at file head appears in files saved by Windows Notepad with "UTF-8 with BOM" encoding, some IDE defaults, and a handful of editors. Conformant senders parse the file from byte zero — the BOM is not stripped, so the version line starts with the BOM bytes followed by version: STSv1, which fails the version-key match.

How to verify no BOM:

; Inspect the first three bytes:
$ curl -s https://mta-sts.example.com/.well-known/mta-sts.txt | head -c 3 | xxd

; Correct output (the "v" of "version" plus next two letters):
00000000: 7665 72                                  ver

; Wrong output (BOM bytes EF BB BF then "v"):
00000000: efbb bf                                  ...

How to fix: re-save the file as "UTF-8 without BOM". Notepad++: Encoding menu → Encode in UTF-8 without BOM. vim: :set nobomb then :w. PowerShell: Out-File -Encoding utf8 (not the default utf8BOM).

No comments: RFC 8461 §3.2 defines only key-value lines. Any line not matching the key: value shape — including # comment, // note, blank lines in the middle of the file, or any line with a different separator — is treated as malformed and the entire policy is rejected.

Whitespace handling: the separator between key and value is : (colon plus space). Senders trim surrounding whitespace from values during parsing, but exotic whitespace (tabs, non-breaking spaces, em-spaces) is risky — stick to the canonical : separator and standard ASCII spaces.

Line endings: CRLF (0D 0A) and LF (0A) line endings are both accepted by conformant senders. CR-only line endings (old-style Mac OS 9) are NOT defined by RFC 8461 and may be treated as malformed by strict parsers — use LF or CRLF.

9. The _mta-sts DNS record and the id= token coupling

The pair: MTA-STS uses two coordinated DNS / HTTPS resources:

1. The _mta-sts.<domain> TXT DNS record carrying v=STSv1; id=<token>. This is the change-detection signal that tells senders WHEN to re-fetch.
2. The https://mta-sts.<domain>/.well-known/mta-sts.txt HTTPS endpoint carrying the actual policy file content documented on THIS page.

Operational rule: the id tag in the DNS record is an opaque token (often a date-derived string like 20260522T120000Z) that operators bump every time they change the policy file. Senders cache the policy keyed on the (policy-domain, id) tuple; when a new id appears in DNS, senders treat the cached policy as stale and re-fetch the URL within their next message-delivery attempt.

Why a coupled two-resource design: the DNS lookup is cheap and discoverable on every SMTP delivery; the HTTPS fetch is expensive and should happen only when the policy changes. The token-in-DNS, content-in-HTTPS split lets DNSSEC protect the change-detection token even when the policy file is served from a separate web-PKI trust chain.

Operational rule for changes: whenever you edit the policy file, you MUST ALSO bump the id token in DNS. Editing the policy file alone results in senders continuing to use the cached (now-stale) policy for up to max_age seconds. Bumping the id alone (without editing the policy file) forces senders to re-fetch but they see the unchanged content — wasted fetches.

; The DNS record (change-detection):
_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260522T120000Z"

; The HTTPS endpoint (policy content):
;   https://mta-sts.example.com/.well-known/mta-sts.txt
; serving:
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

; To roll a policy change:
;   1. Edit the .well-known/mta-sts.txt file.
;   2. Update the id= token in DNS to a new value.
;   3. Wait for senders to re-fetch within their max_age window.

10. Canonical examples

Example 1 — minimal enforce policy (single MX, one-week cache):

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

Example 2 — testing-mode burn-in (24h cache for fast iteration):

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

Example 3 — multi-MX enforce policy with explicit enumeration:

version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
mx: mx3.example.com
mx: mx4.example.com
mx: mx5.example.com
max_age: 2592000

Example 4 — single-label wildcard (shorter file, broader coverage):

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

Example 5 — emergency rollback (mode: none suspends enforcement, short cache so senders re-fetch quickly when you restore enforce):

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

Example 6 — combined deployment: the DNS record + policy file for a complete MTA-STS deployment (with TLS-RPT for monitoring):

; DNS records:
_mta-sts.example.com.  IN  TXT  "v=STSv1; id=20260522T120000Z"
_smtp._tls.example.com. IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; HTTPS policy file at https://mta-sts.example.com/.well-known/mta-sts.txt:
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 604800

11. Common operator mistakes

Ten canonical syntactic drift classes, enumerated as a punch list. Every one results in the policy being silently rejected by conformant senders, with TLS-RPT sts-policy-invalid or sts-policy-fetch-error as the only operator-visible signal.

1. UTF-8 BOM at file head — Windows Notepad default. Causes version: line to fail matching. Save as "UTF-8 without BOM".
2. Comments in the file — RFC 8461 §3.2 has no comment syntax. A line starting with # or any other non-key character causes the entire policy to be rejected.
3. HTTP instead of HTTPS — the policy URL MUST use HTTPS. A 301 redirect from HTTP to HTTPS is treated as a fetch error by some senders.
4. Self-signed or private-CA TLS certificate on mta-sts.<domain> — only publicly-trusted CA certificates validate.
5. Wrong Content-Type — serving the file as text/html or application/octet-stream instead of text/plain causes rejection.
6. Capital-letter mode value — mode: Enforce or mode: ENFORCE fails the case-sensitive token match. Use lowercase enforce, testing, or none.
7. Lowercase version value — version: stsv1 fails the case-sensitive match. Use STSv1.
8. Multi-label mx: wildcard — *.*.example.com or **.example.com are malformed. Wildcards match exactly one label and appear only as the leftmost label.
9. Missing id bump after policy edit — the policy file is edited but the _mta-sts DNS record still carries the old id. Senders continue to use the cached old policy for up to max_age seconds. Bump the id in DNS on every policy edit.
10. Excessive max_age — setting max_age: 31557600 (one year) makes policy rollback take up to one year to fully propagate in the worst case. Use a moderate value (604800 to 2592000) and rely on id-bump for fast change-propagation.

The Domain Security Checker surfaces drift classes 1, 2, 3, 4, 5, 6, 7, and 8 via live HTTPS GET against the policy URL. TLS-RPT (per help_tls_rpt_explained.php) surfaces drift class 9 via sts-policy-fetch-error or sts-policy-invalid reports from senders.

12. Frequently asked questions

What URL does the MTA-STS policy file live at?

The policy file is served from https://mta-sts.<domain>/.well-known/mta-sts.txt. The hostname is the well-known mta-sts subdomain prefixed to the recipient domain. The scheme MUST be HTTPS — plaintext HTTP is rejected by conformant senders because the policy controls TLS-enforcement decisions and must itself be transported under TLS. The TLS certificate at mta-sts.<domain> MUST validate against the public CA root store; self-signed and private-PKI certificates are rejected. The Content-Type MUST be text/plain (or text/plain; charset=utf-8). The HTTP status MUST be 200; redirects are followed but conformant senders SHOULD limit redirect chains. RFC 8461 section 3.3 specifies that senders MAY use HEAD before GET to discover the policy size before fetching the full body.

What are the four canonical keys in an MTA-STS policy file?

RFC 8461 section 3.2 defines four canonical keys: (1) version — the policy version identifier, currently the only valid value is STSv1, case-sensitive, MUST appear first. (2) mode — the deployment-stage tag, one of enforce / testing / none, case-sensitive. (3) mx — one or more lines naming acceptable MX hostnames; each entry is either an exact hostname (mail.example.com) or a single-label wildcard (*.example.com). (4) max_age — the policy cache lifetime in seconds; minimum 86400 (24h) recommended, maximum 31557600 (one year) per RFC 8461. All four keys are MANDATORY; a policy file missing any of them is rejected as malformed by conformant senders. The order of keys is loosely defined — version MUST be first but the other three may appear in any order — though the canonical convention is version then mode then mx (one line per MX) then max_age.

How does mx: wildcard matching work?

RFC 8461 section 3.2 specifies mx: wildcards as single-label only. An entry like *.example.com matches one DNS label of depth-one expansion — so it matches mail.example.com and mx1.example.com but does NOT match sub.mail.example.com (two-label) or example.com (zero-label, the bare apex). The wildcard always appears as the leftmost label; you cannot use *.example.* or mail.*.example.com — those are malformed and the policy is rejected. The single-label restriction prevents over-broad policies that would accidentally accept any subdomain. The canonical operational use case: an organisation that names MX hosts in a predictable pattern (mx1.example.com, mx2.example.com, ..., mx5.example.com) can use a single *.example.com entry instead of enumerating each one — saving boilerplate at the cost of accepting any future *.example.com host that gets added to MX records. The more-conservative posture: enumerate each MX hostname explicitly (mx1.example.com on its own line, mx2.example.com on its own line, etc.) so any future MX additions require an explicit policy update.

What is the maximum max_age value and what value should I use?

RFC 8461 section 3.2 specifies max_age as a positive integer of seconds with a hard maximum of 31557600 (one year, calculated as 365.25 × 86400). The minimum is not formally specified by the RFC, but values under 86400 (24 hours) produce excessive policy re-fetch traffic and are generally avoided. Operational recommendations: (1) Initial deployment / testing mode — start with max_age: 86400 (24 hours) so policy changes propagate quickly during the deployment iteration. (2) Stable enforce mode — bump to max_age: 604800 (one week) or max_age: 2592000 (30 days) once the policy is stable. (3) Production with rare changes — max_age: 31536000 (one year minus a leap-second margin) for the most-stable deployments. The trade-off: longer max_age reduces fetch traffic at the cost of slower policy-change propagation. Senders cache the policy locally for max_age seconds keyed on the policy-id-from-DNS, so a policy change requires both editing the file AND bumping the id= tag in the _mta-sts TXT record for senders to re-fetch within the max_age window.

Are comments allowed in the MTA-STS policy file?

No. RFC 8461 section 3.2 defines the policy file grammar as a list of key-value pairs ONLY; any line not matching the `key: value` shape is treated as malformed. There is no comment syntax — no #, no //, no ;, nothing. A line like `# my note` will cause the entire policy to be rejected by conformant senders, which will then fall back to opportunistic TLS (the equivalent of `mode: none`). This is structurally different from many DNS records or configuration files that permit comments. The operational implication: any annotation about the policy file MUST live OUTSIDE the file — in a configuration-management commit message, in a wiki page, in an inline comment in your infrastructure-as-code that generates the file, but never IN the served file itself. If you need a self-documenting policy, expand the mx: enumeration to include obvious-named hostnames (mail-primary.example.com vs mail-backup.example.com) rather than relying on comments.

Why must the policy file not start with a UTF-8 BOM?

RFC 8461 section 3.2 specifies the policy file as plain ASCII / UTF-8 text without any byte-order mark. A UTF-8 BOM (the three-byte sequence EF BB BF at file head) appears in files saved by Windows Notepad, some IDE configurations, and a handful of editors that default to "UTF-8 with BOM". The BOM bytes appear at the start of the file BEFORE the `version: STSv1` line. Conformant senders parse the file from byte zero — the BOM is not stripped before parsing, so the version line starts with the BOM bytes followed by `version: STSv1`, which fails the version-key match (the parser is looking for `version` as the first bytes of the first line, not three BOM bytes followed by `version`). The policy is rejected and senders fall back to opportunistic TLS. Symptom: the file looks correct in a text editor (the editor renders the BOM as invisible), but `dig` / `curl` / `xxd` shows the BOM bytes. Fix: re-save the file as "UTF-8 without BOM" (Notepad++: Encoding menu > Encode in UTF-8 without BOM; vim: `:set nobomb` then `:w`; Windows PowerShell: use `Out-File -Encoding utf8` not the default `utf8BOM`).

What is the relationship between the policy file and the _mta-sts DNS record?

They work in coordinated tandem. The _mta-sts.<domain> TXT record (e.g., `v=STSv1; id=20260522T120000Z`) is the change-detection signal that tells senders WHEN to re-fetch the policy file. The policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt is the actual policy content senders evaluate. The id= tag in the DNS record is an opaque token (often a date-derived string) that operators bump every time they change the policy file. Senders cache the policy keyed on the (policy-domain, id) tuple; when a new id appears in DNS, senders treat the cached policy as stale and re-fetch the URL within their next message-delivery attempt. The two-record architecture exists because: (a) the DNS lookup is cheap and discoverable on every SMTP delivery, while the HTTPS fetch is expensive and should happen only when the policy changes, (b) the DNS-and-HTTPS-coupling lets DNSSEC protect the change-detection token even when the policy file itself is served from a separate web-PKI trust chain, (c) the id token semantically separates "this policy is current" from "this policy file is fetchable" — an unreachable HTTPS endpoint with a valid id token causes senders to use the previously-cached policy rather than failing closed.

Can I serve the policy file from a CDN or load balancer?

Yes, and this is operationally common. The /.well-known/mta-sts.txt URL can be served from any HTTPS endpoint that meets RFC 8461 requirements: publicly-trusted CA certificate validating for the mta-sts.<domain> hostname, Content-Type text/plain, 200 status. Serving from a CDN (Cloudflare, Fastly, CloudFront, Akamai) is recommended for high-availability domains because the policy URL is a high-cardinality fetch target — every sending MTA in the world that decides to deliver mail to your domain will fetch this URL once per cache window. Operational tips: (1) Set CDN cache-control TTL to match or slightly exceed max_age so the origin sees fetch traffic only on cache misses. (2) Ensure the CDN edge serves the file with Content-Type text/plain — some CDNs default to text/html for .txt files served from /.well-known. (3) Monitor the CDN-edge 5xx rate; a single 5xx burst can cause global policy re-fetch failures, which conformant senders treat as a transient error and proceed with the cached policy (no immediate outage). (4) Coordinate cache-bust on the CDN with the id= bump in DNS to ensure senders re-fetching after the id change actually see the new policy and not a stale CDN cache.

What happens if my policy file has a syntactically valid but invalid mode value?

The policy is rejected as malformed. RFC 8461 section 3.2 specifies mode as taking exactly one of three values: enforce, testing, none. Any other value (mode: strict, mode: ENFORCE, mode: deploy, mode: production) fails the mode-token match and causes conformant senders to reject the entire policy. The sender then falls back to opportunistic TLS for the recipient domain — equivalent to no MTA-STS deployment at all. The most common operator error is case-sensitivity: writing `mode: Enforce` (capital E) instead of `mode: enforce` (lowercase). RFC 8461 does not formally specify case-sensitivity, but the canonical convention is lowercase and most sender implementations enforce it strictly. The defensive posture: always use lowercase for mode values, and verify your policy parses correctly by fetching it through a TLS-RPT-aware sender and observing whether `policy-type=sts` appears in the resulting reports (a successfully-parsed policy produces sts-policy-type reports; a rejected policy produces no-policy-found reports because the sender treats the recipient as having no MTA-STS).

How do I test my policy file before going to enforce mode?

Deploy `mode: testing` first — RFC 8461 section 4.2 specifies testing mode as the canonical pre-enforce burn-in stage. In testing mode, senders parse the policy, evaluate it against actual SMTP sessions, and EMIT TLS-RPT REPORTS describing what they would have done in enforce mode — without actually enforcing anything. So a misconfigured policy that would cause silent mail bouncing in enforce mode produces TLS-RPT failures in testing mode that the recipient operator can review before bumping to enforce. The recommended burn-in workflow: (1) Publish the policy file with mode: testing and a short max_age (86400 seconds). (2) Publish the _mta-sts DNS record with the policy id token. (3) Deploy TLS-RPT (RFC 8460) at _smtp._tls.<domain> with rua= pointing at your reporting destination. (4) Wait 7-14 days for sender population to fetch the policy and emit reports. (5) Review TLS-RPT reports for sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-host-mismatch — any non-zero counts indicate a policy issue that would cause bouncing in enforce mode. (6) Fix any issues, bump the policy id in DNS so senders re-fetch, wait another cycle. (7) Once TLS-RPT reports are clean for at least 7 days, swap mode: testing to mode: enforce and bump the policy id one more time. See help_tls_rpt_report_format.php for the TLS-RPT result-type catalogue.

13. Related guides

• MTA-STS explained — the protocol pillar — what MTA-STS is, the protocol-level overview, deployment workflow, relationship to STARTTLS opportunistic TLS.
• SPF mechanisms explained — the MTA-STS-TRANSPORT-LAYER-POLICY- SYNTAX-VS-SPF-ENVELOPE-LAYER-MECHANISM- SYNTAX-PARITY companion to this MTA-STS policy-file byte-syntax pillar. Where THIS page documents the MTA-STS TRANSPORT-LAYER policy-file syntax (RFC 8461 §3.2: version: / mode: / mx: / max_age: directives, the none / testing / enforce mode semantics, the per-MX-host mx: allow-list wildcard grammar, the line-ending normalisation and ASCII-only constraint), the SPF-mechanisms spoke documents the STRUCTURALLY-ANALOGOUS ENVELOPE-LAYER SPF-record mechanism grammar (RFC 7208 §5: the all mechanism's +/-/~/? qualifier prefix, the include:<domain> recursive-include mechanism, the a: / a:<domain> A-record mechanism, the mx: / mx:<domain> MX-record mechanism, the ptr: / ptr:<domain> RFC 7208 §5.5-deprecated PTR mechanism, the exists:<domain> DNS-existence mechanism, the ip4: / ip6: IP-literal mechanisms). The two protocol-syntax catalogues are STRUCTURALLY ANALOGOUS at distinct OSI layers — MTA-STS publishes a HTTPS-served ASCII-text policy file with directive-key/ value pairs governing TRANSPORT-LAYER receiver enforcement, SPF publishes a TXT-record-embedded ASCII-text token sequence with mechanism + qualifier prefixes governing ENVELOPE-MAIL-FROM authorisation — and operators authoring MTA-STS policy files this page documents SHOULD ALSO author the structurally- analogous SPF mechanism vocabulary documented in the spoke to close the envelope-layer authorisation that complements the transport-layer enforcement. The four-axis MTA-STS-POLICY- SYNTAX-VS-SPF-MECHANISM-SYNTAX comparison exposes the structurally-distinct AUTHENTICATION-LAYER roles: (i) MTA-STS policy-file mx: entries enumerate the receiver-MX hostnames whose connecting sessions MUST present TLS certificates chaining to a publicly-trusted root; SPF mechanism tokens enumerate the envelope-MAIL-FROM-authorised IPs the receiver evaluates the connecting client's IP against; (ii) MTA-STS policy-file mode: directive selects between testing / enforce / none receiver-side enforcement strictness; SPF all-mechanism qualifier selects between +all / -all / ~all / ?all receiver-side fall-through strictness; (iii) MTA-STS policy-file max_age: seconds value governs the receiver-side in-memory cache TTL before policy re-fetch; SPF mechanism tokens have no per-token max_age — the SPF record's per-TXT-record DNS TTL serves the analogous role; (iv) MTA-STS policy-file is DNS-signalled (_mta-sts TXT) + HTTPS-served (/.well-known/mta-sts.txt); SPF mechanism sequence is DNS-published inline in the v=spf1 TXT record at the organisation-domain root. Read the SPF-mechanisms spoke alongside this MTA-STS policy-file byte-syntax reference when scoping the ENVELOPE-LAYER + TRANSPORT-LAYER defense-in-depth authentication posture operators must maintain — the envelope-layer SPF mechanism vocabulary and the transport-layer MTA-STS policy- file syntax are STRUCTURAL SIBLINGS at distinct OSI layers, and BOTH must be authored consistently to achieve the full SPF + DKIM + DMARC + MTA-STS authentication posture the Gmail Bulk Sender Requirements and Yahoo 2024 enforcement bar require.
• MTA-STS vs DANE for SMTP — the policy-mechanism decision view between MTA-STS and DANE (RFC 7672).
• DANE for SMTP — the TLSA-record-based TLS enforcement alternative.
• TLS-RPT explained — the operational feedback loop that makes MTA-STS deployable. Without TLS-RPT, enforce-mode failures are invisible.
• DNS propagation explained — the TWO-RECORD-COORDINATION-PROPAGATION- WINDOW-COMPLEXITY companion reference. Where THIS page documents the TWO-RECORD coordination MTA-STS imposes (the _mta-sts.<domain> TXT carrying v=STSv1 + id=<id> AND the HTTPS-hosted policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt carrying version: STSv1 + mode: enforce|testing|none + mx: allow-list + max_age:), the DNS-propagation spoke documents the STRUCTURAL TIMING-MODEL that governs the coordinated update window: the id= tag's role in the TXT record is to act as a cache-invalidation signal at receiver resolvers — receivers re-fetch the HTTPS policy file when they observe an id= value different from their previously-cached one — which means the policy-file update is NOT consumed by receivers until the new id= TXT record has propagated through every recursive resolver's cache that has resolved the _mta-sts name in the prior TTL window. The operator who bumps the policy file's mx: allow-list before bumping the TXT id= creates a window where some receivers see the new policy and some see the old policy depending on whether their resolver cache has aged out the TXT. The operator who bumps the TXT id= before publishing the new policy file creates a window where receivers re-fetch the policy URL and receive the STALE policy bytes (a sts-policy-fetch-error TLS-RPT result-type if the URL is temporarily unreachable during the cutover, or worse, a successful fetch of the OUTDATED policy). The implication: the correct publication-order procedure is (i) publish the new HTTPS policy file FIRST and let it propagate through any CDN cache or HTTP-cache-headers intermediary, then (ii) bump the TXT id= to trigger receiver re-fetch of the new file — and the coordination window between (i) and (ii) must be at LEAST the policy file HTTP cache duration AND the TXT TTL combined, which the DNS-propagation spoke's TTL-tuning recommendations (3600s for stable records, 300s for records being actively rolled, 86400s for static records) directly inform. Read the DNS-propagation spoke alongside this page when scoping an MTA-STS policy-update or mx:-inventory-rollover — the two-record coordination this page documents is OPERATIONALLY REALIZED through the TTL-bounded resolver-cache aging model the DNS-propagation spoke documents, and the per-operator TTL choice on the _mta-sts TXT record IS the gating variable for how fast a policy-file update reaches receivers.
• TLS-RPT DNS record syntax — the _smtp._tls.<domain> TXT record reference for TLS-RPT.
• TLS-RPT JSON report format — the on-the-wire schema TLS-RPT reporters emit; cross-reference for identifying sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid result-types reported about your policy.
• SPF permerror vs temperror — the MTA-STS-PUBLICATION-FAILURE-MODE- VS-SPF-RESULT-CODE-CATALOGUE-PARITY companion to this MTA-STS policy-file byte-syntax reference. Where THIS page documents the MTA-STS policy-file byte-grammar (version: STSv1, mode: enforce/testing/none, max_age: <0..31557600>, mx: <mailbox-host> allow-list) and the corresponding TLS-RPT failure-result-type catalogue (sts-policy-fetch-error / sts-policy- invalid / sts-webpki-invalid) produced under publication failure, the SPF permerror-vs-temperror spoke is the RFC 7208 §2.6 SPF result-code catalogue companion whose publisher-side-permanent- vs-receiver-side-transient-DNS classification discipline structurally mirrors THIS page's failure-mode catalogue. The CROSS-PROTOCOL-PUBLISHER- SIDE-FAILURE-MODE-PARITY cross-reference establishes FOUR structurally-distinct cross-protocol publisher-side failure- mode parity dimensions: (i) sts-policy-invalid byte-syntax-error parallels SPF permerror byte-syntax- error — MTA-STS sts-policy- invalid result-type indicates the receiver-side fetched a valid HTTPS response but the policy-file body bytes violate this page's byte-grammar (missing version: STSv1 sentinel, malformed mode: value, malformed max_age: integer outside 0..31557600, malformed mx: host-pattern); the spoke documents SPF permerror as RFC 7208 §2.6's canonical publisher-side-syntax-error class (malformed v=spf1 sentinel, malformed mechanism syntax, ambiguous +/-/~/? qualifier) — both protocols' byte- syntax-error result-types are publisher-side fixable AND structurally distinct from transient- DNS failures; (ii) sts-policy- fetch-error transient-fetch failure parallels SPF temperror transient-DNS failure — MTA-STS sts-policy- fetch-error result-type indicates receiver-side HTTPS-fetch failure (connection-timeout to mta-sts.<domain> HTTPS endpoint, TCP RST during fetch, DNS-resolver SERVFAIL looking up mta-sts subdomain) — both are retry-friendly transient failure classes; the spoke documents SPF temperror as RFC 7208 §2.6's canonical retry-friendly transient-DNS failure class (authoritative-nameserver outage, recursive-resolver 5-second timeout, anycast-resolver consistency drift); receiver-side both surface as retry-on-next-message rather than permanent verdict; (iii) sts- webpki-invalid cert-chain-validation failure parallels SPF permerror DNS- budget exceedance — distinct publisher-side fix-discipline classes — MTA-STS sts-webpki-invalid result-type indicates HTTPS-cert-chain validation failure at mta-sts.<domain> endpoint (Let's Encrypt cert expired, self-signed cert published, cert-chain not anchored to receiver-trusted CA); the publisher-side fix is cert-renewal- and-cert-chain-publication discipline; the spoke documents SPF permerror budget-exceedance (10-DNS-lookup-budget per RFC 7208 §4.6.4, void-lookup cap of 2) as a STRUCTURALLY DISTINCT publisher-side fix-discipline class from byte-syntax error — flattening operator-tool workflow vs. byte-grammar editing workflow; THIS page's publisher-side fix-discipline catalogue for MTA-STS publication failures has structurally parallel cross-protocol publisher-side fix-discipline classes in the SPF result-code spoke; (iv) both protocols' publisher-side- permanent failures collapse the publisher's INTENDED authentication contract at the protocol layer — MTA-STS publication failure with mode=enforce collapses the publisher's INTENDED STARTTLS-enforcement contract — receiver-side falls back to opportunistic STARTTLS with no cert-validation; SPF permerror collapses the publisher's INTENDED envelope-MAIL-FROM authorisation contract — DMARC RFC 7489 §4.2 treats permerror as "no policy applicable" for the SPF leg; the spoke documents the STRUCTURAL spoofing-bypass window produced by publisher-side permerror parallel to THIS page's STARTTLS- downgrade-window produced by mta-sts publication-failure under mode=enforce. Pair this page (the MTA-STS policy- file byte-syntax + failure-result-type catalogue) with the SPF permerror-vs- temperror spoke (the SPF result-code RFC-7208-§2.6 reference) when designing publisher-side fix-runbooks that span transport-layer (MTA-STS) AND envelope- layer (SPF) publication-failure debugging — both protocols' result- code catalogues share the same publisher-side-permanent-vs-receiver- side-transient-DNS classification discipline that underpins receiver- side authentication-verdict attribution.
• SPF DNS record syntax — sibling byte-syntax reference for SPF.
• DKIM DNS record syntax — sibling byte-syntax reference for DKIM.
• DKIM cryptography basics — the PER-PUBLISHER-DKIM-RSA-KEY- CRYPTOGRAPHIC-TRUST-ANCHOR-DNS-PUBLICATION- DISCIPLINE-AS-STRUCTURAL-PARALLEL-TO-PER- PUBLISHER-MTA-STS-POLICY-FILE-WEB-PKI-TRUST- ANCHOR-HTTPS-PUBLICATION-DISCIPLINE companion to this MTA-STS policy-file byte-syntax pillar. Where THIS page documents the RFC 8461 §3.2 TRANSPORT-LAYER cryptographic- trust-anchor publication discipline (the version: / mode: / mx: / max_age: directives, the policy-file HTTPS-fetch Web-PKI certificate trust-chain validation, the _mta-sts.<domain> TXT publication-coordination), the DKIM- cryptography-basics spoke is the STRUCTURALLY-PARALLEL APPLICATION-LAYER cryptographic-trust-anchor publication discipline documenting the per-publisher per-selector RSA-key cryptographic-trust- anchor publication primitive (RSA-2048-bit key-strength floor per RFC 8301, per- selector v=DKIM1; k=rsa; p=<base64- pubkey> TXT-record publication at <selector>._domainkey.<d-tag>, per-key rotation cadence with overlap-window discipline, per-receiver per-message signature-verification using the published public-key). The two cryptographic-trust- anchor publication disciplines form a per- publisher dual-layer authoring contract: (i) per-publisher dual-layer cryptographic-trust-anchor DNS-OR-HTTPS publication parallel — MTA-STS publishes the per-publisher Web-PKI-anchored TLS-MX-host enforcement policy via HTTPS- fetched policy file + DNS TXT version-stamp; DKIM publishes the per-publisher per- selector RSA-public-key cryptographic-trust- anchor via DNS TXT record at the _domainkey namespace; both carry per-publisher cryptographic-trust- material whose downstream per-receiver cryptographic-verification depends on the per-publisher publication-discipline; (ii) per-publisher cryptographic-trust- anchor rotation-cadence parallel — MTA-STS policy-file max_age: cadence dictates the per-policy refresh window; DKIM per-selector key-rotation cadence (RFC 6376 §3.6.1 overlap-window discipline) dictates the per-key refresh window; both require the publisher to coordinate per-trust-anchor lifecycle so per-receiver cached trust-material remains valid; (iii) per-receiver per- message cryptographic-verification semantics as downstream consumer — MTA-STS per-receiver per-message MTA-side policy- fetch + certificate-trust-chain validation prerequisites the per-publisher policy- file publication; DKIM per-receiver per- message signature-verification prerequisites the per-publisher per-selector public-key publication; both make per-publisher publication-discipline the load-bearing upstream input to per-receiver per-message cryptographic-verification outcomes; (iv) per-publisher cryptographic-key- strength floor as cross-protocol-coordinated operator-discipline — MTA-STS Web- PKI certificate-issuer key-strength floor coordinates with DKIM RSA-2048-bit key- strength floor as the per-publisher dual- protocol cryptographic-trust-anchor operator-discipline invariant; per-publisher downgrade to RSA-1024 DKIM-keys-or-shorter breaks the same per-publisher cryptographic- floor invariant that per-Web-PKI-CA-issuance certificate-strength constraints enforce on the transport-layer trust-anchor side.
• DKIM best practices — the TRANSPORT-LAYER-POLICY-FILE- AUTHORING-DISCIPLINE-AS-SIBLING-OPERATOR- DISCIPLINE-TO-DKIM-KEY-AND-SELECTOR- PUBLICATION-OPERATOR-DISCIPLINE companion reference. Where THIS page documents the TRANSPORT-LAYER policy-file authoring discipline at the /.well-known/mta-sts.txt byte-grammar layer (the version: STSv1 first-line lock, the mode: enforce|testing|none per-line enum, the mx: <hostname-glob> repeated lines, the max_age: <seconds> TTL budget, the _mta-sts.<domain> policy-id TXT-record companion record), the DKIM-best-practices spoke documents the APPLICATION-AUTHENTICATION-LAYER publisher-discipline ruleset that operates at the SAME publisher-side authoring layer but at the application-authentication protocol step instead of the transport- layer step. The cross-protocol sibling composition pattern: BOTH disciplines require the operator to author per- domain DNS-published records (MTA-STS publishes _mta-sts.<domain> TXT + /.well-known/mta-sts.txt policy file; DKIM publishes <selector>._domainkey.<domain> TXT for each active signing selector), BOTH have a publication-syntax surface the operator MUST satisfy at the byte- shape level (MTA-STS policy-file version: STSv1 first-line lock and per-line key/value grammar; DKIM TXT v=DKIM1 first- position version tag and per-tag grammar), BOTH have a rotation-cadence discipline the operator must implement (MTA-STS policy-id rotation via _mta-sts.<domain> TXT id=-tag change; DKIM selector rotation via dual-selector overlap), BOTH have a max-age / TTL-discipline operational dimension (MTA-STS policy max_age: <seconds> field bounds the receiver-side cache TTL; DKIM TXT-record TTL bounds DNS-cache propagation), and BOTH have a testing-mode publication-discipline step that operators use during the first 24-48-hour publication-verify window (MTA-STS mode: testing instructs receivers to log but not enforce; DKIM t=y instructs receivers to treat verification failures as non-authoritative). Read the DKIM-best-practices spoke alongside THIS page when scoping the publisher-side operator-discipline ruleset across the application- authentication and transport-layer protocols — the two rulesets are cross-protocol sibling disciplines operating at structurally-parallel publication-discipline surfaces, and a complete publisher-side audit must verify BOTH rulesets at the same publication-cadence rhythm.
• DMARC record tags explained — sibling byte-syntax reference for DMARC.
• Email security & privacy glossary — the MTA-STS-POLICY-FILE-BYTE-SYNTAX- RESOLVES-BACK-TO-TRANSPORT-LAYER-SECURITY- AND-PRIVACY-VOCABULARY-DEFINITIONS companion to this MTA-STS policy-file byte-syntax reference. Where THIS page documents the MTA-STS policy-file authoring contract at the byte level (RFC 8461 §3.2: the version: STSv1 / mode: testing|enforce|none / mx: <hostname-pattern> / max_age: <seconds> tag-value grammar, the HTTPS-served /.well-known/mta-sts.txt publication contract, the DNS-side _mta-sts.<domain> TXT record version-tracking, and the receiver-side cache-window and policy- ID-vs-DNS-id reconciliation), the email-security-and-privacy-glossary spoke is the THREAT-AND-DEFENSE-VOCABULARY companion (distinct from the email-authentication-glossary's protocol- mechanic-vocabulary role at line 2039 of this page) documenting the canonical single-sentence definitions for FOUR transport-layer threat-and-defense terms- of-art whose OPERATIONAL-MEANING the MTA-STS policy-file authoring discipline THIS page documents directly engages with: (i) STARTTLS-downgrade threat-class — the glossary's canonical definition of STARTTLS-downgrade as the attacker-induced removal of the SMTP STARTTLS capability advertisement during the SMTP banner exchange is what the mode: enforce policy on THIS page defends against: enforce-mode instructs the sender to REFUSE the message delivery rather than fall back to cleartext when STARTTLS negotiation fails; (ii) MX-substitution threat-class — the glossary's canonical definition of MX-substitution as the DNS-spoofing-or-cache-poisoning- induced substitution of attacker- controlled MX hostnames for the receiver's legitimate MX inventory is what the mx: allowlist on THIS page defends against: senders compare the resolved MX hostname against the policy's allowlist and reject the delivery if no entry matches — even if a DNS-cache-poison attack succeeded; (iii) AITM- MITM threat-class — the glossary's canonical definition of AITM (Adversary-In-The-Middle) attack as the per-hop interception of SMTP traffic between sender and receiver MTAs is what TLS-certificate-chain validation gated by the MTA-STS policy on THIS page defends against: senders verify the receiver's TLS certificate against the MX hostname AND the public- CA chain BEFORE delivering, blocking attackers without a valid CA-issued certificate for the receiver's MX hostname; (iv) policy-file- staleness threat-class — the glossary's canonical definition of policy-file-staleness as the receiver- unilateral-revocation-of-policy-mode being unobservable to senders during the cache-window is what the max_age: <seconds> tag on THIS page bounds: shorter max_age values bound the worst-case receiver-side policy-mode-change observability window at the cost of increased HTTPS fetch frequency. Read the email-security-and-privacy- glossary spoke alongside this MTA-STS policy-file byte-syntax reference when designing the transport-layer threat-model documentation that must correlate per-tag-choice on the publisher-side policy authoring with the per-threat-class defense coverage at the sender-side enforce- mode policy application — the glossary is the canonical transport- layer security-and-privacy-vocabulary substrate; THIS page is the canonical MTA-STS policy-file byte-syntax protocol-mechanic reference whose per-tag authoring discipline determines the per-threat-class defense profile the glossary's vocabulary catalogues.
• MTA-STS for Microsoft 365 — the provider-specific deployment companion that answers the practical question this syntax page leaves open: where do I HOST the /.well-known/mta-sts.txt file for an Exchange Online tenant whose MX is <tenant>.mail.protection.outlook.com? Covers the canonical mx: list (*.mail.protection.outlook.com single wildcard), the mode promotion sequence from testing to enforce, the max_age recommendations for M365 tenants, and the BOM / Content-Type / CRLF gotchas this syntax page documents — applied to the Microsoft 365 hosting environment (Azure App Service, Cloudflare Pages, IIS) that operators reach for to serve the policy file.
• MTA-STS for Google Workspace — the sibling provider-deployment companion answering the same practical question for Workspace tenants: where do I HOST the /.well-known/mta-sts.txt file for a Workspace domain whose MX points to aspmx.l.google.com? The Workspace policy-file shape is SIMPLER than the M365 case: a single mx: aspmx.l.google.com line (no FQDN-wildcard pattern needed because the Workspace MX is a fixed single hostname), optionally a mx: alt1.aspmx.l.google.com through mx: alt4.aspmx.l.google.com for the four secondary backup MXes Workspace publishes. Covers the Workspace-specific BOM / Content-Type / CRLF gotchas (Google Sites is the most natural Workspace-tenant hosting target but requires careful Content-Type configuration), the mode-promotion sequence, and the max_age recommendations tuned for Workspace MX-stability patterns.
• Email authentication overview — the SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA cluster intro.
• DMARC help hub — the canonical entry point.
• BIMI SVG-Tiny-PS image authoring requirements — the PUBLISHER-SIDE-STRICT-BYTE-SYNTAX- WIRE-FORMAT-AUTHORING-COMPANION reference. Where THIS page documents the MTA-STS policy-file byte-syntax constraints (RFC 8461 §3.2 strict key:value-with-LF- terminator field grammar, the version: STSv1 / mode: enforce / mx: pattern / max_age: seconds field set, the BOM-prohibition / CRLF-vs-LF / trailing-whitespace silent-fetch-failure modes, the policy-ID byte-identity rule), the BIMI-SVG-Tiny-PS-image-authoring spoke documents the STRUCTURALLY-PARALLEL publisher-side strict-byte-syntax wire- format authoring constraints for the SVG-Tiny-PS image profile (W3C SVG-Tiny- 1.2 subset compliance, the BIMI Working Group's per-element authoring-rules-draft constraints on viewBox / preserveAspectRatio / fillRule / stroke-width / fill-color, the UTF-8 byte- encoding requirement, the 32-KB-after- base64 upper-bound, the gzip-eligibility flag, the baseProfile="tiny-ps" / version="1.2" root-element attribute discipline). Both publisher-side documents share the same structural failure-mode taxonomy: (i) silent fetch-success but post-fetch receiver-side syntax-validation-rejection (MTA-STS receiver discards a malformed policy file silently and falls back to opportunistic STARTTLS; BIMI receiver discards a malformed SVG silently and displays no branded-inbox indicator); (ii) byte-level CDN-caching pinning amplifying authoring-mistake half-life across the receiver population beyond the publisher's correction-deploy cadence; (iii) publisher-side observability gap — the publisher cannot directly observe which receiver populations have which cached version of which file. Read THIS MTA-STS-policy-syntax page WITH the BIMI- SVG-Tiny-PS spoke when designing a publisher-side strict-byte-syntax wire- format authoring discipline across the cluster's parallel publisher-side wire- format channels.
• CAA records explained — the CAA-RECORDS-AS-X509-CERTIFICATE- AUTHORITY-ISSUANCE-AUTHORIZATION- PREREQUISITE-FOR-_mta-sts-DOT-DOMAIN- HTTPS-ENDPOINT companion reference. Where THIS page documents the MTA-STS policy- file byte-syntax (the version: STSv1 / mode: enforce / mx: pattern / max_age: seconds field set, served over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt with a publicly-trusted X.509 server certificate the receiver MUST validate before consuming the policy), the CAA- records-explained spoke documents the DNS-PUBLISHED CA-ISSUANCE-AUTHORIZATION contract (RFC 8659 issue / issuewild / iodef property tags) whose four operator-control dimensions directly gate the cert- issuance pipeline that produces the _mta-sts.<domain> HTTPS endpoint certificate: (i) the CAA <flags> issue "<ca-domain>" property at the policy-publisher domain controls which CA is authorised to issue the X.509 cert every MTA-STS-honouring receiver chain- validates at fetch time, (ii) Certificate-Transparency-log entries (RFC 9162) cross-correlate with CAA authorisation to surface unauthorised issuance attempts the policy-publisher operator can monitor out-of-band, (iii) the CAA <flags> iodef "mailto:…" property establishes the CA-side report-back channel for CAA- violation attempts parallel to the TLS-RPT rua=mailto:… report- back channel for receiver-side transport- layer failures, and (iv) ACME (RFC 8555, Let's Encrypt + ZeroSSL + others) honours CAA records at certificate-renewal time, gating the recurring renewal cycle the long-lived _mta-sts HTTPS endpoint depends on. Read the CAA- records-explained spoke alongside this page when scoping the publisher-side PKI-issuance-authorisation discipline upstream of the MTA-STS policy-file publication this page documents — a misconfigured or absent CAA record at the policy-publisher domain leaves the HTTPS endpoint open to attacker-procured certificate issuance from any of the ~150 publicly-trusted CAs, which would STRUCTURALLY DEFEAT the MTA-STS policy- file integrity guarantee even when the policy-file byte-syntax this page documents is itself perfectly authored.
• Email deliverability — the TRANSPORT-ENCRYPTION-AS- DELIVERABILITY-SCORING-INPUT-AT- RECEIVER-SIDE companion. Where THIS page documents the MTA-STS policy- file byte-syntax (the version: STSv1 / mode: enforce / mx: pattern / max_age: seconds field set, the strict CRLF-vs-LF / BOM / whitespace silent-fetch-failure modes, the policy-ID byte-identity rule), the deliverability spoke documents the UMBRELLA RECEIVER-SIDE INBOX- PLACEMENT OUTCOME the transport-layer encryption posture this page configures ultimately feeds into. Receivers in the post-2024 Gmail / Yahoo / Microsoft bulk-sender-policy-enforcement era explicitly factor transport-layer encryption posture into per-sender- domain reputation scoring: (i) MTA-STS mode: enforce publication is a deliverability-positive signal at Gmail (per Postmaster Tools Encryption column and per 2024 Sender Guidelines publication), (ii) TLS-RPT publication alongside MTA-STS demonstrates publisher-side observability discipline and is treated as a positive reputation signal in the Gmail / Yahoo / Microsoft sender-trust evaluation, (iii) opportunistic-only-STARTTLS publishers whose MTA-STS posture is absent or in mode: testing get a reduced-reputation classification compared to mode: enforce peers when other deliverability signals are equal, (iv) MTA-STS policy file syntax-violation states (silently- fetched-but-discarded malformed policy) produce the worst-of-both-worlds outcome: publisher believes enforcement is active but receiver-side falls back to opportunistic STARTTLS, surfacing as a deliverability-degradation that is invisible to the publisher absent the TLS-RPT feedback loop. The deliverability spoke is therefore the canonical reference for the RECEIVER- SIDE-REPUTATION-SCORING-INPUT layer that the MTA-STS posture this page configures feeds into. Read THIS MTA-STS-policy-syntax page WITH the deliverability spoke when designing a transport-encryption-posture deployment that maximises the Gmail / Yahoo / Microsoft reputation- scoring positive-signal contribution.
• DMARC deployment checklist — the PHASE-4-AND-PHASE-5-TRANSPORT-LAYER- HARDENING-CHECKLIST-STEP-AS-LOAD-BEARING- CONSUMER-OF-MTA-STS-POLICY-FILE-BYTE- SYNTAX-AND-_MTA-STS-TXT-RECORD-PUBLICATION- PRIMITIVE companion to this MTA-STS-policy- syntax reference. Where THIS page documents the per-publisher per-domain MTA-STS-policy file byte-syntax publication discipline (RFC-8461-§3.2 `version: STSv1` + `mode: testing/enforce/none` + per-MX-host `mx:` glob-pattern allow-list + `max_age:` cache- retention discipline at the HTTPS well- known well-known/mta-sts.txt endpoint + RFC-8461-§3.1 `_mta-sts.<d>` TXT record `v=STSv1; id=<policy-version>` publication primitive triggering per- publisher per-policy-version receiver-side cache-invalidation), the DMARC-deployment- checklist spoke is the canonical 5-phase deployment-discipline reference whose Phase 4 quarantine-enforcement-with-transport- layer-hardening + Phase 5 reject- enforcement-with-complete-cross-layer- publication-discipline-stack checklist steps structurally consume THIS page's MTA-STS publication primitives at four MTA-STS-policy-syntax-to-deployment-phase coupling dimensions: (i) per- publisher per-domain MTA-STS-policy file `mode: testing` publication as load- bearing Phase 4 transport-layer- observability-baseline primitive — the deployment-checklist's Phase 4 per-publisher per-domain transport- layer-hardening step structurally requires the per-publisher per-domain MTA-STS- policy `mode: testing` publication discipline THIS page documents as the per-publisher per-domain transport-layer- observability-baseline primitive (analogous to the message-layer Phase 2 `p=none` + `rua=mailto:` observability- baseline) that the per-publisher per- domain operations team consumes BEFORE flipping the per-publisher per-domain MTA-STS-policy mode to enforce; (ii) per-publisher per-domain MTA-STS-policy `mode: enforce` publication as load-bearing Phase 5 transport-layer- STARTTLS-required enforcement primitive — the deployment- checklist's Phase 5 per-publisher per- domain complete-cross-layer-publication- discipline-stack step structurally requires the per-publisher per-domain MTA-STS-policy `mode: enforce` publication discipline THIS page documents as the per-publisher per-domain per-MX-host transport-layer-STARTTLS- required + per-MX-host STARTTLS-cert- trust-evaluation primitive every per- publisher per-domain per-message transport-layer-confidentiality-and- integrity survival the Phase 5 enforcement progression demands; (iii) per- publisher per-domain `max_age:` cache- retention discipline as load-bearing Phase 4-5 ongoing-operational-discipline- primitive — the deployment- checklist's Phase 4-5 per-publisher per- domain ongoing-operational-discipline step structurally requires the per- publisher per-domain `max_age:` cache- retention discipline THIS page documents as the per-publisher per-domain per- receiver MTA-STS-policy-cache-survival- across-incident-recovery primitive that gates per-publisher per-domain MTA-STS- policy-publication-availability-incident- recovery (per-publisher per-domain HTTPS well-known endpoint-down recovery + per-publisher per-domain MTA-STS-policy- cert-rotation discipline) without per- receiver MTA-STS-policy-cache-expiry- induced transport-layer-enforcement- gap incident-window; (iv) per- publisher per-domain `_mta-sts.<d>` TXT record `id=` policy-version-bump discipline as load-bearing Phase 4-5 per-policy-version-cache-invalidation primitive — the deployment- checklist's Phase 4-5 per-publisher per- domain MTA-STS-policy-rotation step structurally requires the per-publisher per-domain `_mta-sts.<d>` TXT record `id=` policy-version-bump discipline THIS page documents as the per-publisher per-domain per-policy- version receiver-side cache-invalidation primitive every per-publisher per- domain MTA-STS-policy update the Phase 4-5 ongoing-operational-discipline step consumes. Read the DMARC- deployment-checklist spoke ALONGSIDE this MTA-STS-policy-syntax reference whenever a per-publisher per-domain DMARC-deployment programme reaches the Phase 4 transport-layer-hardening or Phase 5 complete-cross-layer-publication- discipline-stack step and needs the per- publisher per-domain MTA-STS-policy file byte-syntax + `_mta-sts` TXT record byte-syntax publication discipline THIS page documents as the load-bearing transport-layer-publication primitive every per-phase checklist- step prerequisite gates on.
• DMARC aggregate (RUA) reports — the APPLICATION-LAYER-AGGREGATE- REPORTING-AS-PEER-OBSERVABILITY-CHANNEL companion to this MTA-STS policy-file byte-syntax reference. Where THIS page documents the per-publisher per-domain mta-sts.txt policy-file byte-syntax (the version: STSv1 / mode: testing|enforce|none / mx: <hostname-pattern> / max_age: <seconds> per-line key-value grammar at RFC 8461 §3.2) whose downstream transport-layer enforcement contract produces the daily TLS-RPT JSON aggregate-report stream (per-receiver per-policy per-result- type per-session-count failure distribution), the DMARC-aggregate- reports spoke documents the per-tenant peer application-layer aggregate-report publication discipline at four cross-layer aggregate-report-channel coupling dimensions: (i) per- tenant transport-layer-TLS-RPT-channel vs application-layer-DMARC-RUA-channel observability partition — the per-tenant TLS-RPT-aggregate-report channel THIS page's MTA-STS policy- file byte-syntax publication produces carries per-receiver per-session per- result-type failure distribution at the SMTP transport-layer; the per- tenant DMARC-RUA-aggregate-report channel the DMARC-aggregate-reports spoke documents carries per-receiver per-source-IP per-author-domain per-alignment-outcome row stream at the application-layer — BOTH channels are DNS-published per-tenant reporting endpoints (_smtp._tls + _dmarc at the author- domain DNS zone) that feed the per-tenant operator's per-layer observability programme; (ii) per-publisher per-domain MTA-STS-policy publication discipline as PRECONDITION- TO-TLS-RPT-aggregate-report-stream- VALIDITY vs DMARC-publication-discipline- as-PRECONDITION-TO-RUA-aggregate- report-stream-VALIDITY — the per-tenant MTA-STS policy-file publication THIS page documents the byte-syntax of is the LOAD-BEARING precondition for the per-tenant TLS-RPT aggregate-report stream to carry policy-specific sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid result-types rather than generic no-policy-found rows; symmetrically, the per-tenant DMARC TXT publication is the LOAD-BEARING precondition for the per-tenant DMARC RUA aggregate-report stream to carry per-receiver per-author-domain evaluative rows rather than NO RUA delivery at all — the DMARC- aggregate-reports spoke documents the per-tenant DMARC publication discipline the application-layer-side of this precondition-symmetry depends on; (iii) per-tenant per-receiver per-day per-aggregate-report deduplication-and- redelivery semantics cross-channel parity — the TLS-RPT JSON aggregate-report stream THIS page's downstream protocol documents and the DMARC RUA XML aggregate-report stream the DMARC-aggregate-reports spoke documents share structurally-parallel per-receiver per-day per-report-id deduplication semantics (TLS-RPT: per-report-id keyed; DMARC: per- <report_metadata><report_id> keyed) — the per-tenant operator's cross-channel aggregate-report ingestion pipeline (e.g., this DMARC Analyzer's ImapFetcher → DmarcParser → TlsRptParser ingest path) must apply per-channel deduplication discipline that respects the per-report-id keying both channels emit; (iv) per-tenant Phase-4- quarantine-enforcement-with-transport- layer-hardening + Phase-5-reject- enforcement-with-complete-cross-layer- publication-discipline-stack joint rollout-gate baseline — the canonical 5-phase deployment-discipline the DMARC-deployment-checklist references as the joint MTA-STS-and- DMARC rollout-advancement gate is empirically observed via BOTH the transport-layer TLS-RPT aggregate- report stream THIS page's policy-file publication produces AND the application-layer DMARC RUA aggregate- report stream the DMARC-aggregate- reports spoke documents — Phase 4 and Phase 5 advancement requires empirically-observed ≥99% TLS-RPT successful-session-count + ≥99% DMARC policy_evaluated.disposition=none (legitimate-mail-pass) on per-author- domain per-receiver baselines computed from both aggregate-report channels. Read the DMARC-aggregate-reports spoke alongside this MTA-STS-policy-file byte-syntax reference when the per- tenant operator is designing the joint cross-layer observability programme that correlates the transport-layer mta-sts.txt publication THIS page documents with the application-layer _dmarc publication the DMARC-aggregate- reports spoke documents at every per-receiver per-author-domain failure- attribution event.
• MX records explained — the PER-PUBLISHER-PER-DOMAIN-MX-RR- INVENTORY-AS-LOAD-BEARING-UPSTREAM-INPUT- INTO-mta-sts.txt-mx-DIRECTIVE-LIST- AUTHORING companion to this MTA-STS- policy-file byte-syntax reference. Where THIS page documents the RFC 8461 §3.2 per-publisher per-domain mta-sts.txt policy-file byte-syntax grammar (version: STSv1 / mode: enforce|testing|none / max_age: < seconds> / mx: <mx-hostname> per-line repeated) + the RFC 8461 §3.3 per-publisher per-domain _mta- sts.<domain> IN TXT "v=STSv1; id= <version-string>" TXT-RR publication-discipline byte-syntax reference, the MX-records spoke is the canonical RFC 5321 §5.1 MX-RR primitive reference documenting the per-publisher per-domain MX-RR inventory that ITSELF IS the load-bearing upstream input into the per-publisher per-domain mta-sts.txt policy-file's mx:-directive list authoring at four per-publisher per-domain MX-inventory-to-MTA-STS- policy-file-mx:-directive- authoritative-mirror coupling dimensions: (i) per-publisher per-domain MX- RR-hostname-set publication as load- bearing per-publisher per-domain mta- sts.txt mx:-directive list authoritative-mirror requirement — the per-publisher per-domain MX-RR publication (<publisher- domain> IN MX <priority> < mx-hostname> per-host repeated) IS the receive-side-MX-hostname inventory the per-publisher per-domain mta-sts.txt policy-file's mx:-directive list MUST authoritatively mirror at the per-line per-MX-hostname entry boundary THIS page documents the byte-syntax grammar of; the per-publisher per-domain MX-RR-vs-mta-sts.txt-mx:- directive list publication-discipline- coordination THIS page documents the downstream consumer of IS keyed against the per-publisher per-domain MX-RR inventory the MX-records spoke documents the publication-discipline of; (ii) per-publisher per-domain MX-RR- priority-list-ordering as load-bearing per-publisher per-domain mta-sts.txt mx:-directive list-ordering- coordination discipline — per- publisher per-domain MX-RR-priority-list ordering (primary + fallback per-MX-host repeated per-RFC-5321 §5.1 per-priority- list per-MX-host fallback-order primitive the MX-records spoke documents the publication-discipline of) MUST authoritatively coordinate with the per- publisher per-domain mta-sts.txt mx :-directive list inclusion-set (primary + fallback per-MX-host each individually listed as a per-line mx:-directive entry the per-line-grammar THIS page documents the byte-syntax of); (iii) per- publisher per-domain MX-RR-inventory- rollover as load-bearing per-publisher per-domain mta-sts.txt id=- tag-version-bump-coordination trigger — every per-publisher per-domain MX-RR-inventory rollover (new MX-host added or retired during multi- region active-active publisher deployment cycle the MX-records spoke documents the publication-discipline of) MUST coordinate a per-publisher per- domain mta-sts.txt mx:- directive list update + per-publisher per-domain _mta-sts.<publisher- domain> TXT-RR id=- tag version-bump (per the byte-syntax grammar THIS page documents) to invalidate the per-sender per-recipient- MX-host MTA-STS-policy-cache; (iv) per-publisher per-domain MX-RR- vs-mta-sts.txt-mx:-directive- wildcard-pattern-matching divergence as load-bearing per-recipient-MX-host STARTTLS-cert-trust-evaluation-bypass surface — the per-publisher per- domain mta-sts.txt mx:- directive list-entry MAY use the RFC 8461 §3.2 wildcard-pattern (e.g., mx: *.<publisher-domain>) the byte-syntax grammar THIS page documents; the per-publisher per-domain MX-RR-vs-mta-sts.txt-mx:- directive-wildcard-pattern divergence (per-publisher MX-RR rolls forward to per-MX-host outside the per-domain wildcard-pattern coverage but per- publisher mta-sts.txt mx:- directive list still uses the same wildcard-pattern) produces a load- bearing per-recipient-MX-host STARTTLS- cert-trust-evaluation-bypass surface the per-publisher per-domain TLS-RPT JSON- failure-report-stream registers as a per- sender per-recipient-MX-host MITM-attack defence-bypass event. Read the MX- records spoke ALONGSIDE this MTA-STS- policy-file byte-syntax reference whenever a per-publisher per-domain MTA- STS-policy-file mx:- directive list authoring or inventory- rollover-coordination question emerges — THIS page gives the per-publisher per- domain mta-sts.txt policy-file byte- syntax grammar, the MX-records spoke gives the canonical per-publisher per- domain MX-RR-publication-and-inventory- rollover-discipline EVERY per-line mx:-directive entry the per-line-grammar THIS page documents the byte-syntax of MUST authoritatively mirror.
• Domain Security Checker — validate the live policy file from multiple geographic resolvers.
• DNS record generator — generate the _mta-sts TXT record interactively (Enterprise tier).
• Email Header Analyzer — parse received email headers to cross-check inbound TLS posture.
• SPF qualifiers explained — the CROSS-LAYER-PARALLEL-PER-PUBLISHER- SENDER-SIDE-PUBLISHED-POLICY-TOKEN-BYTE-SHAPE- AUTHORING-DISCIPLINE companion reference. Where THIS page documents the per-publisher MTA-STS policy-file byte-shape at the transport layer (the mode: testing / mode: enforce / mode: none state-machine token-values per RFC 8461 §3.2 plus the version: STSv1, mx:, and max_age: token-values published at the well-known URL https://mta-sts.<domain>/ .well-known/mta-sts.txt), the SPF-qualifiers-explained spoke documents the STRUCTURALLY-PARALLEL per-publisher sender-side published-policy byte-shape at the application layer (the four canonical mechanism-prefix qualifier bytes + Pass / - Fail / ~ SoftFail / ? Neutral per RFC 7208 §4.6.2 that prefix every SPF mechanism token in the v=spf1 TXT-record at the apex <org-domain> owner-name) across four cross-layer published-policy token-byte-authoring dimensions: (i) both publication primitives encode per-publisher enforcement-severity through a small fixed-vocabulary token byte-set — the MTA-STS mode: tag-value is a closed three-state token-set (none / testing / enforce) per RFC 8461 §5, just as the SPF qualifier- prefix byte is a closed four-state token-set (+ / - / ~ / ?) per RFC 7208 §4.6.2; per-publisher operator authoring discipline depends on byte-precision-strict adherence to BOTH closed token-sets at the publication-discipline layer; (ii) both publication primitives encode a progressive-rollout enforcement-state ladder sharing the staged-observability-before- commitment pattern — the MTA-STS mode: testing stage produces per-receiver per-day TLS-RPT aggregate feedback at the transport layer BEFORE the operator commits to mode: enforce, just as the SPF ~all qualifier- prefix SoftFail stage produces per-receiver per-day DMARC aggregate feedback at the application layer BEFORE the operator commits to the production -all Fail-qualifier stance; the cross-layer progressive-rollout discipline is the same; (iii) both publication primitives are paired with DMARC-aligned-pass outcomes — an MTA-STS mode: enforce commitment without a per-publisher SPF -all qualifier-prefix on the publisher's v=spf1 record leaves the cross-layer per-publisher sender-authentication plan incomplete: the transport-layer TLS- stripping-AND-MITM-downgrade attacker-bypass class is gated by the MTA-STS commitment THIS page documents while the application- layer per-publisher spoofing attacker-bypass class is gated by the SPF qualifier-prefix the SPF-qualifiers spoke documents; (iv) both publication primitives share the same per-publisher per-domain DNS publication-cadence coordination discipline — the MTA-STS policy-file is keyed by the per-publisher _mta-sts.<domain> TXT-record's id= tag and the well-known URL host, while the SPF qualifier- prefix bytes publish at the apex <org-domain> owner-name; per-publisher per-domain authoring tooling must keep BOTH publication cadences synchronised across MTA-STS policy-edit operations and SPF qualifier-prefix-edit operations. Read the SPF-qualifiers spoke alongside this MTA-STS-policy-file syntax reference whenever the per-publisher per- domain cross-layer publication plan extends to a complete application-layer-and-transport- layer published-policy byte-shape coordination plan — the SPF qualifier-prefix byte IS the application-layer per-publisher published- policy primitive that runs ALONGSIDE the MTA-STS mode: tag-value byte discipline THIS page documents at every per-publisher cross-layer sender-authentication commitment event.
• DMARC for Microsoft 365 hybrid Exchange — the message-layer dual-egress DMARC deployment companion to this transport- layer MTA-STS policy-file byte-syntax reference. Where THIS page documents the per-publisher per-domain mta-sts.txt HTTPS-served policy file byte-syntax (the version: STSv1 header, the mode: enforce/testing/none ternary, the mx: wildcard- capable hostname enumeration, the max_age: seconds cap), the hybrid-Exchange spoke documents the STRUCTURAL-PEER per-M365-tenant per- custom-domain DMARC publication discipline at the message-authentication layer for the hybrid cloud EXO + on-prem Edge Transport coexistence topology. The MTA-STS-VS-HYBRID-EXCHANGE-DMARC cross-reference establishes FOUR cross-layer coupling dimensions: (i) per-publisher per-domain publication-substrate parallel — MTA-STS HTTPS-served mta-sts.txt on mta-sts.<domain> vs DMARC DNS-published _dmarc.<domain> TXT record; both per-publisher per-domain publications are co-deployed in the canonical hybrid-Exchange green-path roadmap; (ii) per- publisher per-portfolio per-domain co-deployment ordering — DMARC at p=quarantine/p=reject publication precedes per-receiver rejection of unauthenticated mail, and MTA-STS mode: enforce publication precedes per-receiver rejection of transport-layer downgrade attempts; the hybrid spoke documents the per-tenant per-custom- domain co-deployment sequencing operators of hybrid Exchange portfolios rely on; (iii) per-receiver per-publisher per-domain enforcement observability via aggregate reporting — DMARC ${RUA}=rua aggregate XML reports vs TLS-RPT _smtp._tls.<domain> TLSRPTv1 aggregate JSON reports; the hybrid spoke documents the per- tenant per-custom-domain DMARC- aggregate-report consumption discipline that runs alongside this page's MTA-STS-policy-file publication discipline for unified per-publisher cross-layer enforcement observability; (iv) per-publisher per-domain per-tenant publication discipline at the dual-egress hybrid Exchange boundary — both MTA-STS policy-file and DMARC TXT-record publication must align between cloud EXO + on-prem Edge Transport boundaries to avoid cross-boundary policy inconsistency regressions; the hybrid spoke documents the per-boundary publication- consistency invariant whose per- publisher per-domain enforcement contract this page's mta-sts.txt byte-syntax reference anchors at the transport layer. Read the hybrid-Exchange spoke when co-deploying MTA-STS policy-file publication and DMARC TXT-record publication on a hybrid Exchange portfolio with dual-egress boundaries.
• Email spoofing techniques and defenses — the SEVEN-TECHNIQUE-SPOOFING-ATTACK- CATALOGUE companion to this MTA-STS policy-file byte-syntax reference. Where THIS page documents the RFC 8461 §3.2 per-publisher per-policy-domain mta-sts.txt policy-file body byte-grammar (the version: STSv1 prefix line, the mode: enforce|testing|none three-mode axis, the per-MX mx: <hostname-pattern> allow-list lines, the max_age: <N> caching-budget directive), the email-spoofing spoke documents the seven-technique attack catalogue whose transport-layer spoofing-delivery sub-classes the publisher MTA-STS policy-file body publication discipline THIS page documents structurally closes at four MTA-STS-as-anti-spoofing coupling dimensions: (i) mode: enforce commitment closes the STARTTLS-strip cleartext-delivery spoofing technique class — the seventh spoofing technique in the catalogue (STARTTLS-strip-and-cleartext- delivery) requires the attacker to intercept the receiver-MX STARTTLS EHLO advertisement and force a cleartext SMTP fallback; the publisher mode: enforce commitment instructs RFC 8461 sending MTAs to REQUIRE STARTTLS-with-valid-leaf- certificate at the publisher-pinned MX-allow-list and REJECT delivery when the receiver-MX cannot present a valid certificate, structurally failing the STARTTLS-strip technique the email-spoofing catalogue defense section operationalises against; (ii) mx: <hostname- pattern> publisher-pinned allow-list closes the MX-impersonation rogue-receiver spoofing sub-class — the email-spoofing catalogue documents the MX-substitution delivery-redirection variant where an attacker redirects sending-MTA MX resolution to an attacker-controlled MX accepting spoofed-author-domain messages; sending MTAs honoring MTA- STS REJECT delivery to any MX not matching the publisher pinned mx: allow-list pattern, structurally failing the MX- impersonation sub-class the email- spoofing catalogue catalogues; (iii) max_age:-bounded policy-cache-window closes the policy- downgrade-via-stale-cache spoofing sub-class — attackers attempting to extend the cleartext- delivery attack window via DNS-cache poisoning of the _mta-sts.<d> TXT-record id= version pointer are bounded by the publisher max_age: directive ensuring sending MTAs refetch the policy after the cache window, structurally bounding the attack persistence the email-spoofing catalogue downgrade-attack-window analysis section enumerates; (iv) publisher unilateral- publication deployability closes the operator-coordination-window spoofing sub-class — the email- spoofing catalogue documents that application-layer SPF/DKIM/DMARC require per-receiver opt-in enforcement to defeat the per- spoofing-technique class, whereas MTA- STS policy-file publication causes ANY RFC 8461 sending MTA to enforce TLS to the publisher pinned MX-allow- list at delivery time, providing immediate cross-receiver downgrade- attack defense without the per- receiver coordination window the email-spoofing catalogue threat- modelling section flags as an application-layer-defense gap. Read the email-spoofing catalogue alongside this MTA-STS policy-file byte-syntax reference when translating the per-policy-line publisher discipline this page documents into per-attack-technique transport-layer anti-spoofing defense surface mapping.
• Why SPF alone is insufficient — the structural-limitations-of-SPF reference cataloguing the four reasons every per-publisher per-domain email- authentication posture requires additional protocols beyond SPF: (i) forwarding-MAIL- FROM-rewrite-breaks-SPF at the second-hop boundary; (ii) no message-content cryptographic integrity at the envelope- MAIL-FROM authorization layer; (iii) no transport-layer STARTTLS-cipher / certificate-chain enforcement at the per- MX-host receiver-side connection boundary — SPF authorises envelope-MAIL-FROM but offers NO guarantee that the message traverses the inter-MTA hop under an authenticated TLS-encrypted transport channel; (iv) no per-publisher per-domain transport-layer observability evidence for STARTTLS-downgrade / certificate-chain validation failures. THIS page documents the RFC 8461 §3.2 MTA-STS policy-file byte-grammar (version: STSv1, mode: enforce|testing|none, mx: <hostname>, max_age: <seconds>) published at the per-publisher per-domain https://mta-sts.<d>/.well- known/mta-sts.txt HTTPS-fetch endpoint as the canonical TRANSPORT-LAYER- AUTHORIZATION-PERIMETER per-publisher per- domain MTA-STS publishes to close exactly the per-MX-host STARTTLS-downgrade gap the structural-SPF-insufficiency catalogue enumerates as the transport-layer limit — MTA-STS publishes the per-publisher per- domain AUTHORISED-MX-host catalogue + per- domain MINIMUM-TLS-VERSION enforcement gate + per-domain CERTIFICATE-CHAIN-VALIDATION requirement at the per-MX-host receiver- side STARTTLS connection-boundary, which envelope-MAIL-FROM SPF authorisation STRUCTURALLY CANNOT publish at any envelope-layer authoring boundary. Read the why-SPF-alone-is-insufficient spoke alongside this MTA-STS policy-syntax reference when scoping the per-publisher per-domain transport-layer hardening publication discipline that structurally closes the transport-layer gap SPF leaves open, when authoring the per-publisher per- domain SPF + DKIM + DMARC + MTA-STS + TLS- RPT defense-in-depth deployment playbook, or when sequencing the per-publisher per- domain transport-layer-hardening ramp (MTA-STS mode: testing → TLS-RPT receiver-side evidence-collection → MTA-STS mode: enforce) on TLS-RPT receiver-side STARTTLS-success-rate evidence.
• Reverse DNS (PTR records) explained — the MTA-STS-POLICY-MX-DIRECTIVE-PER-MX- HOST-PTR-FORWARD-CONFIRMED-RDNS-CONSUMER companion to this MTA-STS policy syntax reference. Where THIS page documents the per-publisher MTA-STS policy file byte-level syntax (the version: STSv1 / mode: enforce | testing | none / mx: <hostname-pattern> / max_age: <seconds> tags), the reverse-DNS-PTR spoke is the PER-MX-HOST-RDNS-PUBLICATION-DISCIPLINE REFERENCE every MTA-STS publisher consults when verifying the per-MX-host hostname listed in the policy's mx: directive list correctly forward-and-reverse resolves at the connecting sender's per- MX-host rDNS-lookup point. Three structurally- distinct MTA-STS-MX-vs-PTR coordination dimensions: (i) the mx: directive list this page documents enumerates per-MX-host hostname patterns the sender MTA matches against the recipient MX hostname during the per-message STARTTLS handshake — the per-MX-host hostname validation is two-sided: forward DNS (MX RR → A/AAAA RR) for connection establishment AND reverse DNS (PTR RR at the connecting IP's IN-ADDR.ARPA leaf → hostname) for sender-side hostname-cohort fingerprinting, and per-MX-host operators publish BOTH records as a coordinated pair; (ii) MTA-STS enforce-mode publishers whose per-MX-host PTR record drifts (e.g. PTR deleted, PTR hostname re-assigned, PTR TTL expiry triggers stale-cache outcomes) produce per-receiver sender-side TLS- validation outcomes that surface in TLS-RPT evidence streams as policy-conforming-but- infrastructure-inconsistent failure modes the publisher's per-MX-host audit catalogue must coordinate with the policy file's mx: directive listing; (iii) per-MX-host PTR record continuity is the receive-side anti-abuse heuristic foundation that interacts with the publisher's MTA-STS publication discipline — receivers applying rDNS-required heuristics at the connection-establishment boundary will reject per-MX-host connections before the MTA-STS policy file even fetches, producing per-receiver deliverability outcomes the per-publisher MTA-STS rollout playbook coordinates with the per-MX-host PTR publication discipline.
• RFC 8461 §3.2 — MTA-STS policy file format — the normative specification.
• RFC 8461 §3.3 — MTA-STS policy fetch — the HTTPS+well-known fetch contract.
• RFC 8461 — SMTP MTA Strict Transport Security — the full normative reference.
• Phishing protection — the DEFENDER-SIDE-PHISHING-ATTACK- CLASS-ENUMERATION-AT-PER-PROTOCOL-LAYER- MITIGATION-PILLAR companion to this MTA- STS policy-syntax reference. Where THIS page documents the RFC 8461 per-publisher per-domain MTA-STS policy-file byte- grammar (the version: STSv1 prefix, the mode: enforce / testing / none state, the mx: permitted-MX cone, the max_age: per- receiver cache-pinning TTL, and the per-publisher policy-file publication at https://mta-sts.<domain>/ .well-known/mta-sts.txt), the phishing-protection cluster-level enumeration spoke is the cluster-level DEFENDER-SIDE-PHISHING-ATTACK-CLASS- CATALOGUE REFERENCE documenting the six canonical per-protocol-layer phishing attack classes plus the per-protocol- layer mitigation pillar that closes each class. The MTA-STS-POLICY-SYNTAX-VS- PHISHING-PROTECTION cross-reference establishes that the per-publisher per- domain MTA-STS policy-file publication IS the per-transport-layer mitigation pillar for the downgrade-to-plaintext phishing-interception attack class — a per-receiver per-sender per-message STARTTLS downgrade attack (DNS-spoofing the publisher's MX, intercepting the SMTP STARTTLS negotiation, forcing plaintext-fallback transport) is closed at the per-receiver per-policy-file mode: enforce commit boundary because RFC 8461 receivers honour the per-publisher policy-file cached mx: cone + TLS-pinning requirement BEFORE accepting fallback to plaintext. Read THIS page when AUTHORING per-publisher per-domain MTA-STS policy- file content at .well-known/mta- sts.txt; read the phishing- protection cluster-level enumeration spoke when MAPPING per-publisher per- domain MTA-STS publication coverage to the per-receiver per-attack-class defender-side enumeration, or when CO-AUDITING the per-publisher per- protocol-layer mitigation-pillar completeness across SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA / ARC at per-attack-class closure boundaries.
• DKIM for Google Workspace — the LOAD-BEARING per-Workspace-tenant per-custom-domain PER-WORKSPACE-TENANT- DKIM-PUBLICATION-AS-APPLICATION-LAYER- PEER-OF-TRANSPORT-LAYER-MTA-STS- POLICY-FILE-PUBLICATION-DISCIPLINE companion documenting the per- Workspace-tenant per-custom-domain DKIM publication tutorial (the Google Admin console Apps > Google Workspace > Gmail > Authenticate email flow, the per-tenant 2048-bit google._domainkey.<d> DNS-TXT publication, the per-tenant DKIM-signing-domain verification step). Where THIS page documents the per- publisher per-policy-domain MTA-STS TRANSPORT-LAYER policy-file byte-grammar publication (the version, mode, mx, max_age field semantics at .well-known/mta-sts.txt), the DKIM-for-Workspace spoke documents the per-Workspace-tenant per-custom- domain APPLICATION-LAYER DKIM- publication-discipline structural-peer of the TRANSPORT-LAYER MTA-STS policy- file publication-discipline this page documents. Read THIS page when AUTHORING the per-publisher per-policy- domain MTA-STS TRANSPORT-LAYER policy- file publication; read the DKIM-for- Workspace spoke when AUTHORING the per- Workspace-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 — the Workspace-tenant per-custom-domain DKIM application- layer publication and the per-policy- domain MTA-STS transport-layer policy- file publication TOGETHER form the per-tenant per-custom-domain layered authentication-and-transport-security publication-discipline boundary that gates both per-message DKIM-aligned- pass evidence AND per-MX-host STARTTLS- fail-closed enforcement at the per- receiver per-policy-domain ingress gate.
• DKIM key rotation — the PER-SELECTOR-DKIM-KEY-VERSIONING- DISCIPLINE companion to this RFC 8461 §3.2 MTA-STS policy-file byte-grammar reference. Where THIS page documents the per-publisher per-policy-domain MTA-STS policy-file byte-grammar (the version: STSv1 mandatory version-field, the per-policy id: <monotonic-token> version-tag bumped on every per-policy- domain policy-file mutation, the per-receiver per-policy-domain cached policy-file refetch trigger keyed off the id:-tag change), the DKIM key rotation spoke is the STRUCTURALLY-PEER per-selector APPLICATION-LAYER key-versioning- discipline companion documenting the per-publisher per-domain per-selector public-key rotation lifecycle: both publication surfaces use a per-asset version-token-bump-on-every-mutation discipline to drive per-receiver cached-asset refetch. (i) Per- policy-domain MTA-STS policy id:-tag bumping — every per-policy-domain policy-file mutation (adding a new MX host, adjusting the max_age:, promoting mode: testing to mode: enforce) MUST bump the id:-tag to a new monotonic token, AND the _mta-sts.<policy-domain> DNS-TXT-RR id=-tag MUST be bumped in lock-step so per-receiver cached-policy refetch triggers deterministically; (ii) Per- selector DKIM key-version rotation via selector-naming-discipline — every per-publisher per-domain key- rotation publishes the new key at a NEW selector (typically a per-year monotonic selector like 2026q2._domainkey or a per-rotation index like k2._domainkey) and the signing-MTA's outbound DKIM-Signature header's s=<selector> tag drives per-receiver per-selector TXT-RR fetch deterministically — the per-selector naming-discipline IS the DKIM key-version-token equivalent of the MTA-STS id:-tag THIS page documents; (iii) Per- receiver per-asset cached-policy / cached-key refetch discipline — both publication surfaces rely on per-receiver per-asset cache invalidation triggered by the per-asset version-token bump (MTA-STS: TXT-RR id=-tag change; DKIM: per-message s=<selector> tag change). The two discipline surfaces compose: the per-receiver per-domain per-message DKIM-verdict evaluation depends on the per-selector publication-lifecycle the DKIM key rotation spoke documents; the per- receiver per-MX-host STARTTLS enforcement depends on the per-policy- domain MTA-STS policy-file publication-lifecycle THIS page documents. Read THIS page when AUTHORING the per-publisher per-policy- domain MTA-STS policy-file byte- grammar publication; read the DKIM key rotation spoke when AUTHORING the per-publisher per-domain per-selector DKIM key-publication lifecycle whose per-selector version-token-bump- on-every-mutation discipline mirrors the per-policy-domain id:-tag versioning discipline THIS page documents at the per-publisher per-domain layered application-and-transport security publication-discipline boundary.
• RFC 8460 — SMTP TLS Reporting — the TLS-RPT companion specification.
• DKIM troubleshooting — the APPLICATION-LAYER PER-MESSAGE DKIM- RESULT-CLASS DECISION-TREE diagnostic companion to THIS page's per-publisher per- policy-domain transport-layer MTA-STS policy- file byte-grammar reference. Where THIS page documents the per-publisher per-policy-domain MTA-STS policy-file version:, mode:, mx:, max_age: byte-grammar AND the per-publisher per-policy-domain TLS- enforcement-floor discipline that protects per-receiver per-MX-host SMTP delivery from opportunistic STARTTLS-downgrade active-attacker MITM at the transport-layer boundary, the DKIM-troubleshooting spoke is the APPLICATION-LAYER PER-MESSAGE-RESULT- CLASS DIAGNOSTIC discipline that runs ATOP the transport-layer encryption envelope — documenting the per-symptom decision-tree for DKIM-side per-message authentication failures (body-hash mismatch from canonical- isation drift, signature mismatch from key- rotation lag, temperror from DNS-resolution timeout, permerror from missing selector or malformed key, policy-class verdict from receiver-side DKIM-policy enforcement). The two spokes occupy STACKED LAYERS of the per- publisher per-domain email-authentication- and-transport security model: MTA-STS establishes the transport-layer TLS- enforcement floor; DKIM authentication operates ATOP that transport envelope at the per-message application-layer verification boundary. Read THIS page when AUTHORING the per-publisher per-policy- domain MTA-STS policy-file byte-grammar; read the DKIM-troubleshooting spoke when DIAGNOSING per-message application-layer DKIM-side authentication failures the per- receiver per-message verifier surfaces DESPITE the transport-layer MTA-STS enforcement THIS page's policy syntax publication discipline has established.
• DMARC for Microsoft 365 — the M365-TENANT-PER-CUSTOM-DOMAIN-MTA- STS-POLICY-FILE-PUBLICATION companion to this MTA-STS policy-file byte-grammar reference. Where THIS page documents the per-publisher per-policy-domain MTA-STS policy-file byte-grammar (version: STSv1, mode: enforce|testing|none, per-MX-host pattern mx: list, max_age: seconds-bounded policy-cache-lifetime per RFC 8461) and the per-publisher per-policy-domain HTTPS-served policy-file fetching contract at https://mta-sts.<policy-domain>/.well-known/mta-sts.txt, the M365-tenant spoke documents the per- M365-tenant per-custom-domain MTA-STS publication topology where the per-tenant per-custom-domain MTA-STS policy file publishes the per-tenant per-custom-domain Exchange Online Protection inbound MX pattern (canonically mx: *.mail.protection.outlook.com) AS the per-tenant per-custom-domain TLS- enforcement-bound inbound MX roster. The per-M365-tenant per-custom-domain MTA-STS policy-file publication IS the per-tenant per-custom-domain canonical consumer of the MTA-STS policy-file byte-grammar THIS page architectures at four M365-tenant- deployment-vs-MTA-STS-policy-file-byte- grammar coupling dimensions: (i) per-M365- tenant per-custom-domain mx: *.mail.protection.outlook.com pattern as canonical EOP-inbound-MX TLS-enforcement roster — the per-M365- tenant per-custom-domain MTA-STS policy- file's per-MX-host pattern entry IS the per-tenant per-custom-domain canonical TLS-enforcement-bound inbound MX roster the per-M365-tenant per-custom-domain Exchange Online Protection inbound MX cascade resolves through; (ii) per-M365- tenant per-custom-domain mode: enforce commitment as per-tenant per-custom-domain TLS- enforcement-floor publication discipline — the per-M365-tenant per-custom-domain canonical mode: testing → mode: enforce ramp cadence consumes the per-mode-progression discipline THIS page documents at the per-tenant per- custom-domain TLS-enforcement-floor commitment boundary; (iii) per-M365-tenant per-custom-domain https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt HTTPS-served policy-file hosting as per- tenant per-custom-domain DNS + HTTPS coordination discipline — the per-M365- tenant per-custom-domain MTA-STS publication requires per-tenant per- custom-domain DNS publication of the _mta-sts TXT record AND per- tenant per-custom-domain HTTPS hosting of the policy-file the per-tenant per-custom- domain DNS + HTTPS coordination discipline THIS page documents structurally coordinates; and (iv) per-M365-tenant per- custom-domain MTA-STS + TLS-RPT combined publication as per-tenant per-custom- domain transport-layer-policy + transport- layer-observability cross-layer hardening — the per-M365-tenant per-custom-domain MTA-STS policy-file publication AUTHORS the per-tenant per-custom-domain transport- layer-policy-enforcement-floor whose per- MX-host transport-layer-failure-event stream is observed through the per-tenant per-custom-domain TLS-RPT rua=mailto: publication. Read THIS page when AUTHORING the per-publisher per-policy-domain MTA-STS policy-file byte-grammar publication discipline at the canonical record-syntax reference layer; read the M365-tenant DMARC deployment spoke when AUDITING the per-M365-tenant per-custom-domain MTA-STS policy-file publication against the per-tenant per- custom-domain Exchange Online Protection inbound-MX cascade at the per-M365-tenant per-custom-domain transport-layer-policy- enforcement boundary.
• DKIM selectors explained — the PER-PUBLISHER-PER-DOMAIN-MTA-STS- POLICY-FILE-PUBLICATION-AS-TRANSPORT-LAYER- PUBLICATION-DISCIPLINE-PARALLEL-TO-PER- SELECTOR-DKIM-APPLICATION-LAYER-PUBLICATION companion to THIS per-publisher per-domain MTA-STS policy-file byte-syntax reference. Where THIS page documents the per-publisher per-domain MTA-STS policy-file byte-grammar (the version: STSv1 / mode: none|testing|enforce / mx: ... / max_age: field publication discipline per RFC 8461 §3.2, the HTTPS+well-known fetch contract per RFC 8461 §3.3, the per-MX-host pattern- matching syntax, the per-tenant per-custom- domain policy-file rollout cadence coordination), the DKIM-selectors-explained spoke documents the per-publisher per- selector DKIM-selector publication discipline at FOUR per-MTA-STS-policy-syntax-vs-DKIM- selector publication coupling dimensions: (i) per-publisher per-domain MTA- STS policy-file publication AS transport- layer publisher-side authentication- boundary-publication primitive structurally parallel to per-publisher per-selector DKIM- selector TXT-RR application-layer publisher- side cryptographic-identity-publication primitive — the per-publisher per- domain MTA-STS policy-file publication IS the transport-layer publisher-side authentication-boundary-publication primitive scoping per-receiver per-message SMTP-MTA-to- MTA cryptographic-certificate-validation enforcement at the transport-layer boundary; the per-publisher per-selector DKIM-selector TXT-RR publication IS the application-layer publisher-side cryptographic-identity- publication primitive scoping per-receiver per-message DKIM-Signature cryptographic- validation at the application-layer boundary; the two publications are structurally parallel per-publisher per-domain transport-layer-and- application-layer publisher-side authentication-publication-coordination disciplines; (ii) per-publisher per- domain MTA-STS max_age rotation cadence floor AS transport-layer-policy- rotation-cadence-floor publication discipline structurally parallel to per-publisher per- selector DKIM key-rotation cadence floor — the per-publisher per- domain MTA-STS policy-file max_age: field publication discipline establishes the per-publisher per- domain transport-layer-policy-rotation cadence floor at the per-publisher per- domain policy-rotation publication boundary; the per-publisher per-selector DKIM key- rotation cadence floor (per-publisher per- selector at-minimum-quarterly rotation cadence, per-publisher per-selector private- key-custody discipline) IS the per-publisher per-selector application-layer rotation- cadence-floor publication discipline; the two are structurally parallel per-publisher per-domain transport-layer + application- layer rotation-cadence-floor publication- coordination disciplines; (iii) per- publisher per-domain MTA-STS mode=enforce phase-transition commitment AS transport-layer-enforcement- floor publication discipline structurally parallel to per-publisher per-selector DKIM-Signature universal-coverage commitment application-layer-enforcement-floor publication discipline — the per- publisher per-domain MTA-STS mode=enforce commitment IS the per-publisher per-domain transport-layer- enforcement-floor publication discipline at the per-publisher per-domain transport-layer policy-enforcement boundary; the per- publisher per-domain DKIM-Signature- universal-coverage commitment (per-publisher per-stream every-mail-stream selector publication coverage, per-publisher per- third-party-SaaS-sender selector coordination universal-coverage) IS the per- publisher per-domain application-layer- enforcement-floor publication discipline at the per-publisher per-domain application- layer authentication-evaluation boundary; the two are structurally parallel per- publisher per-domain transport-layer + application-layer enforcement-floor publication-coordination disciplines; (iv) per-publisher per-domain MTA-STS policy-file publication AS per-publisher per-domain transport-layer publication- discipline-floor complementing per-publisher per-selector DKIM application-layer publication-discipline-floor at unified composite-publication-coordination boundary — the per-publisher per- domain unified-trust-signal-floor publication posture rests on per-publisher per-domain MTA-STS transport-layer publication + per-publisher per-domain TLS- RPT transport-layer-observability publication + per-publisher per-domain DMARC application-layer enforcement publication + per-publisher per-domain SPF envelope-layer authorisation publication + per-publisher per-selector DKIM application-layer cryptographic-identity publication; the per- publisher per-domain MTA-STS policy-file publication discipline THIS page documents IS the per-publisher per-domain transport- layer publication input AND the per- publisher per-selector DKIM-selector publication discipline IS the per-publisher per-selector application-layer publication input that the per-publisher per-domain unified composite-publication-coordination boundary depends on. Read THIS page when AUTHORING per-publisher per-domain MTA-STS policy-file publication; read the DKIM- selectors-explained spoke when UNDERSTANDING how the per-publisher per-selector DKIM- selector publication discipline IS the per- publisher per-domain application-layer publication-discipline structurally parallel to the per-publisher per-domain MTA-STS policy-file transport-layer publication- discipline at the per-publisher per-domain composite-publication-coordination boundary.
• DKIM-Signature header explained
• DKIM canonicalization explained — the PER-PUBLISHER-PER-MESSAGE-DKIM- CANONICALIZATION-BYTE-NORMALIZATION-MODE- AS-APPLICATION-LAYER-BYTE-GRAMMAR-PUBLICATION PEER-PAIR-TO-MTA-STS-POLICY-FILE-TRANSPORT- LAYER-BYTE-GRAMMAR-PUBLICATION companion to this MTA-STS policy-syntax byte-grammar reference. Where THIS page documents the RFC 8461 §3.2 MTA-STS policy-file byte-grammar publication discipline (per- publisher per-domain version: STSv1 + mode: testing|enforce|none + mx: <hostname-glob> repeated lines + max_age: <seconds> served from https://mta-sts.<domain>/.well-known/mta-sts.txt), the DKIM-canonicalization spoke documents the PARALLEL per-publisher per-message application-layer byte-normalization discipline at FOUR per-publisher per-domain DKIM-canonicalization-vs-MTA-STS-policy- syntax byte-grammar coupling dimensions: (i) per-publisher per-message DKIM canonicalization-mode byte-normalization discipline as APPLICATION-LAYER-BYTE- GRAMMAR PEER-PAIR to per-publisher per- domain MTA-STS policy-file byte-grammar publication discipline at the per-publisher per-domain cross-layer byte-grammar publication-discipline boundary — both are per-publisher per-domain byte-grammar publication primitives the receiver-side evaluator consults at cryptographic-verification or transport- layer-enforcement time, but DKIM canonicalization defines the application- layer per-message byte-normalization the receiver DKIM-verifier applies BEFORE body-hash and header-hash computation while MTA-STS policy syntax defines the transport-layer per-policy-fetch byte- grammar the receiver STARTTLS-enforcement engine parses BEFORE per-MX allow-list evaluation — structurally parallel per-publisher per-domain byte-grammar publication primitives at different protocol layers; (ii) per-publisher per-message DKIM simple vs relaxed canonicalization-mode choice as ROBUSTNESS-VS-STRICTNESS TRADEOFF parallel to per-publisher per- domain MTA-STS mode: testing vs mode: enforce ramp-vs- enforcement TRADEOFF the per-domain transport-layer publication-discipline ramp THIS page documents resolves at deployment — simple/simple canonicalization preserves bytes verbatim (high signature-break risk on any downstream MTA byte-mutation, low forwarder-survivability) while relaxed/relaxed tolerates whitespace and case-folding mutations (low signature-break risk, high forwarder- survivability) — STRUCTURALLY PARALLEL to the per-publisher per-domain MTA-STS mode: testing (low deliverability risk via report-only observability) vs mode: enforce (strict STARTTLS-enforcement, deliverability cost on per-receiver MTA non-compliance) choice the per-publisher per-domain transport-layer publication-discipline ramp resolves at deployment-cadence; (iii) per-publisher per-message DKIM c=-tag publication discipline coupled to per-publisher per-message bh= body-hash + b= signature-bytes emission discipline as STRUCTURAL-PARALLEL to per-publisher per- domain MTA-STS policy-id rotation discipline coupled to per-domain _mta-sts.<d> TXT-RR id= emission discipline THIS page’s policy- publication-discipline anchors — just as the per-publisher per- message DKIM-Signature c= tag MUST be coordinated with the body-hash bh= and signature-bytes b= emission per signed message (canonicalization-mode mismatch between signer and verifier reliably breaks DKIM verification), the per-publisher per- domain MTA-STS policy-file policy-id MUST be coordinated with the per-domain _mta-sts.<d> TXT-RR id=<policy-id> emission so every receiver-side STARTTLS-enforcement engine consistently fetches the active policy version the publisher intends — both per-publisher per-domain publication primitives require disciplined coordination of the byte-grammar-publication mechanism with the metadata-version-emission mechanism; and (iv) per-receiver DKIM canonicalization-mode evaluator-side DETERMINISTIC-RE-COMPUTATION discipline as PARALLEL to per-receiver MTA-STS policy- file byte-grammar evaluator-side DETERMINISTIC-PARSE discipline the per- publisher per-domain MTA-STS publication playbook presupposes — the per-receiver DKIM-verifier MUST apply the c=-tag-declared canonicalization algorithm BIT-EXACTLY identically to the per-publisher per-message DKIM-signer canonicalization (else body-hash and header-hash diverge, signature verification fails), and the per-receiver MTA-STS policy-fetch engine MUST parse the per- publisher per-domain policy-file byte- grammar BIT-EXACTLY identically to the per-publisher policy-file emission (whitespace handling, line-ending discipline, comment handling, repeated-tag handling per RFC 8461 §3.2) — both per- receiver evaluator-side disciplines depend on byte-grammar-determinism the per- publisher per-domain byte-grammar publication discipline must preserve under the per- message DKIM-Signature emission cascade or per-domain MTA-STS policy-republish cadence. Pair THIS MTA-STS policy-syntax byte- grammar reference with the DKIM- canonicalization spoke when designing the per-publisher per-domain cross-layer byte- grammar publication-discipline that coordinates the per-publisher per-message application-layer DKIM canonicalization- mode discipline with the per-publisher per- domain transport-layer MTA-STS policy-file byte-grammar discipline across the per- publisher per-domain composite cross-layer publication-discipline-floor coordination boundary.
• DMARC for SaaS senders — the PER-SAAS-TENANT-PER-CUSTOMER- DOMAIN-MTA-STS-POLICY-FANOUT-AS-STRUCTURALLY- PARALLEL-PER-SAAS-TENANT-MULTI-CUSTOMER- DOMAIN-DMARC-PUBLICATION-FANOUT companion to this MTA-STS policy-syntax reference. Where THIS page documents the per-publisher per-domain RFC 8461 §3.2 MTA-STS policy-file byte-grammar (version: STSv1, mode: enforce|testing|none, mx: hostname-glob list, max_age: TTL), the SaaS-senders spoke is the PER-SAAS-TENANT MULTI-TENANT FANOUT reference the per-SaaS-tenant operator consults when authoring per- customer-domain MTA-STS policy-file publications at scale across N customer- domains. Four per-SaaS-tenant multi- customer-domain transport-layer coordination dimensions: (i) PER-SAAS- TENANT-PER-CUSTOMER-DOMAIN-MTA-STS-MX- ALLOW-LIST-AUTHORISATION (per-customer- domain mx:-directive list publication must authorise the per-SaaS- tenant-managed receive-side MX hostnames without leaking other SaaS customers' infrastructure boundaries); (ii) PER-SAAS- TENANT-PER-CUSTOMER-DOMAIN-MTA-STS-POLICY- ID-ROTATION-UNIFORMITY (per-SaaS-tenant uniform policy-id rotation cadence across N customer-domains avoids per-customer-domain cache-invalidation dispersion that fragments per-publisher observability cohorts); (iii) PER-SAAS- TENANT-PER-CUSTOMER-DOMAIN-MTA-STS-HTTPS- SERVED-POLICY-CERT-CHAIN-UNIFORMITY (per- SaaS-tenant-managed wildcard or per- customer-domain SAN certificate provisioning for mta-sts.<customer-domain> HTTPS endpoints requires uniform per- customer-domain cert-chain validity); (iv) PER-SAAS-TENANT-PER-CUSTOMER-DOMAIN-TLS- RPT-OBSERVABILITY-FANOUT (per-SaaS-tenant per-customer-domain TLS-RPT JSON aggregate- report ingestion across N customer-domains IS the per-SaaS-tenant operational- observability stream surfacing per-customer- domain MTA-STS publication breakage). Read the SaaS-senders spoke alongside this MTA- STS policy-syntax guide when AUTHORING per- SaaS-tenant per-customer-domain MTA-STS policy-file publication discipline at multi- tenant scale, when AUDITING per-SaaS-tenant per-customer-domain MTA-STS publication uniformity, or when PLANNING per-SaaS- tenant per-customer-domain cross-customer- domain MTA-STS rollout sequencing.
• DMARC troubleshooting
• DMARC for transactional-email senders — the per-customer-domain transport- layer-cryptographic-floor-vs-application- layer-identity-floor coordination companion to this MTA-STS policy-file byte-grammar pillar. Where THIS page documents the transport-layer policy-file syntax (the version: STSv1 / mode: testing|enforce|none / mx: *.<customer-domain> allow-list / max_age: <seconds> directive grammar per RFC 8461 §3.2), the transactional-email spoke documents the per- customer-domain DMARC enforcement-mode ramp (p=none → p=quarantine → p=reject progression) the transactional ESP guides the customer-domain through. Four coupling axes connect them: (i) per-customer-domain MTA-STS policy-file mx: allow- list MUST include the transactional-ESP MX- hosts to prevent receiver-side STARTTLS- required-fail surfacing as TLS-RPT failure-details/policy-mx-no-match — parallel to per-customer-domain DMARC SPF/DKIM authorisation discipline including the transactional-ESP's outbound infrastructure; (ii) per-customer-domain MTA-STS HTTPS-served-policy-file availability under high-volume bursts (millions of transactional emails per day) IS structurally parallel to per-customer-domain DKIM- Signature publication availability — both transport-layer and application-layer publication discipline collapse under outbound-infrastructure breakage; (iii) per- customer-domain MTA-STS max_age: cache-window (86400-2592000 seconds typical) parallel to per-customer-domain DMARC TXT-RR TTL-budget drives cross-protocol publication- cadence coordination — transactional- ESP onboarding MUST sequence MTA-STS publication ahead of DMARC enforcement-mode ramp progression; (iv) per-customer-domain MTA-STS mode: enforce + per-customer-domain DMARC p=reject JOINTLY satisfy the 2024 Gmail/Yahoo/Microsoft Bulk-Sender- Requirements composite transport-layer- cryptographic-integrity + application-layer- identity-authentication floor. Read the transactional-email spoke alongside this MTA-STS policy-syntax guide when AUTHORING per-customer-domain MTA-STS policy-file publication discipline at transactional-ESP onboarding, when AUDITING per-customer- domain composite transport-layer + application-layer publication-floor preservation, or when PLANNING per-customer- domain DMARC enforcement-mode ramp sequencing against the MTA-STS mode: testing → enforce cascade progression.
• DMARC multi-domain strategy
• Email authentication glossary
• SPF (Sender Policy Framework) primer
• DKIM for Microsoft 365
• DMARC alignment — the PER-PUBLISHER-PER-DOMAIN-DMARC- APPLICATION-LAYER-ALIGNMENT-EVALUATION companion to this MTA-STS policy-file byte- grammar reference at four cross-layer publication-discipline coupling dimensions: (i) per-publisher per-domain DMARC application-layer alignment-mode publication-decision (adkim=r relaxed vs adkim=s strict + aspf=r relaxed vs aspf=s strict per RFC 7489 §6.3) IS structurally parallel application-layer alignment-evaluation publication-decision to per-publisher per- domain MTA-STS mode: testing vs mode: enforce transport- layer enforcement-mode publication-decision THIS page documents the byte-grammar of; (ii) per-publisher per-domain DMARC composite-verdict aligned-pass disjunction per RFC 7489 §3.1.1 (any-DKIM-aligned- pass OR SPF-aligned-pass = DMARC composite alignment) IS the application-layer composite-verdict-floor structurally parallel to per-publisher per-domain MTA- STS-policy-fetch-and-honour composite transport-layer enforcement-floor THIS page’s policy-file byte-grammar publication-discipline underpins; (iii) per-publisher per-domain DMARC psl-derived organisational-domain extraction discipline per RFC 7489 §3.2 IS structurally parallel cross-layer publication-discipline primitive to per-publisher per-domain MTA- STS policy_domain selection at _mta-sts.<domain> TXT-RR publication boundary THIS page documents; (iv) per-publisher per-domain DMARC alignment-evaluation publication-discipline drift (premature adkim=s/ aspf=s strict-mode cutover surfacing as per-receiver per-day RUA aligned-pass-rate regression) IS structurally parallel application-layer publication-discipline-drift class to per- publisher per-domain MTA-STS premature mode: enforce cutover surfacing as per-receiver per-day TLS-RPT sts-policy-invalid / sts-policy-fetch-error transport-layer publication-discipline- regression THIS page documents the byte- grammar of. Read the DMARC alignment spoke when COORDINATING per-publisher per-domain composite cross-layer application-and- transport-layer publication-discipline across the per-publisher per-domain DMARC alignment-mode + MTA-STS enforcement-mode publication-decision boundaries.
• DMARC for shared-hosting — the PER-PUBLISHER-PER-POLICY-DOMAIN-MTA-STS-POLICY-FILE-BYTE-GRAMMAR-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-SHARED-HOSTING-TENANT-PER-CUSTOM-DOMAIN-DMARC-FIVE-STEP-DEPLOYMENT companion at four per-shared-hosting-tenant per-custom-domain MTA-STS-policy-file-vs-DMARC-shared-hosting-deployment coupling dimensions: (i) per-shared-hosting-tenant per-custom-domain MTA-STS policy-file `mx:` MX-pattern publication-discipline per RFC 8461 §3.2 MUST encompass all per-tenant per-shared-MX-cluster hosts (typically `mx: *.<hosting-provider>.com` single-label-wildcard covering all per-tenant shared-Exim-MTA-server-hostnames) IS the load-bearing per-tenant per-custom-domain transport-layer per-MX-host authorization-discipline whose per-receiver per-MX-host STARTTLS-required-or-fail enforcement-verdict preserves per-tenant per-custom-domain envelope-byte-stream-integrity baseline against MITM downgrade-attack-class at shared-Exim-MTA cluster egress the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of structurally depends on; (ii) per-shared-hosting-tenant per-custom-domain MTA-STS policy-file `mode: testing → mode: enforce` two-stage transport-layer policy-mode publication-discipline ramp per RFC 8461 §5 IS structurally parallel to per-tenant per-custom-domain DMARC `p=none → p=quarantine → p=reject` three-stage application-layer policy-mode publication-discipline ramp per RFC 7489 §6.3 — both per-tenant per-custom-domain progressively-stricter policy-mode-publication ramps gate on per-receiver per-day per-source-IP / per-MX-host evidence-driven readiness metrics the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of; (iii) per-shared-hosting-tenant per-custom-domain MTA-STS policy-file `max_age:` cache-lifetime publication-decision per RFC 8461 §3.2 (max 31557600 seconds = 1 year) drives per-receiver-side per-tenant per-MX-host policy-cache-coherence cadence whose per-tenant per-custom-domain transport-layer policy-cache-stability publication-discipline cascades into per-tenant per-custom-domain composite cross-protocol cross-layer publication-discipline-stability floor the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain Step 5 (Advance from `p=quarantine` to `p=reject`) terminal-stage enforcement-ramp publication-discipline operational-discipline of structurally depends on; (iv) per-shared-hosting-tenant per-custom-domain MTA-STS policy-file byte-grammar publication-discipline drift (BOM-prefix mis-publication / inline-comment mis-publication / wildcard-label crossing single-label-budget / `max_age:` exceeding 31557600-second ceiling / per-tenant per-shared-MX-cluster host omission from `mx:`-line-list) surfacing in per-tenant per-policy-domain TLS-RPT JSON-aggregate-report `failure-type: sts-policy-invalid` attribution per RFC 8460 §4.3 directly opens per-tenant per-custom-domain transport-layer per-MX-host authorization-discipline-floor regression cascading into per-tenant per-custom-domain composite cross-protocol DMARC-aligned-pass-rate floor preservation regression the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of structurally depends on at the per-shared-hosting-tenant per-custom-domain composite cross-protocol cross-layer per-MX-host publication-discipline-and-shared-hosting-deployment coordination boundary.
• include vs ip4 vs a vs mx — the SPF-mechanism-selection companion to this MTA-STS policy-file syntax page. The MTA-STS policy file's mx: pattern lines per RFC 8461 §3.2 enumerate the same mail-exchanger hostnames that the SPF mx mechanism resolves from the domain's MX records, so the publisher's choice between expanding mx / a into explicit ip4: ranges (to stay under the ten-DNS-lookup cap) and pinning those same MX hosts in the transport-layer policy are coordinated decisions over one mail-exchanger inventory. Read the mechanism-selection spoke when reconciling the SPF authorization host set against the MTA-STS mx: host set.
• SPF for Google Workspace
• BIMI explained — the other post-enforcement trust layer a domain adds once DMARC is at p=quarantine or p=reject. Where the MTA-STS policy file this page documents hardens the inbound transport hop, BIMI rewards the same enforcement posture with a verified brand logo at the recipient’s inbox — both are deliverability-and-trust controls operators typically deploy after reaching enforcement, not before. Read the BIMI explained spoke to see how the verified-logo program complements transport hardening in the post-enforcement trust stack.
• DMARC monitoring — the application-layer observability companion to the transport-layer hardening this policy-syntax page documents. Where MTA-STS plus TLS-RPT tell you whether the relay hop stayed encrypted, the DMARC RUA aggregate stream tells you whether messages stayed authenticated and aligned end to end. Read the monitoring spoke to run both observability streams side by side and confirm the domain's authentication posture holds at enforcement.
• SPF for Microsoft 365 — the sender-side authorisation companion to this receiver-side transport-policy reference on the same M365 tenant. An M365 tenant publishes BOTH: the outbound- authorising SPF record (v=spf1 include:spf.protection.outlook.com -all, which authorises Exchange Online as a legitimate envelope- MAIL-FROM sender) AND the MTA-STS policy file whose mx: allow-list THIS page documents the byte- grammar of (mx: *.mail.protection.outlook.com, which authorises which sending MTAs may TLS-handshake with the tenant's inbound MX). The two operate at structurally orthogonal layers — SPF at the application-layer sender-IP-authorisation leg, MTA-STS at the transport-layer inbound-MX-authorisation leg — but both are published per-tenant in the same DNS zone. Read the SPF-for-M365 spoke for the outbound half of the M365 authentication-and- transport publication portfolio this policy-syntax page documents the inbound transport half of.
• DKIM replay attacks — this page's max_age field is a bounded-validity timestamp: it tells receivers how long to trust a cached MTA-STS policy before re-fetching, so a stolen or stale policy cannot be replayed indefinitely. The DKIM layer has the exact analogue — the signature x= expiration tag bounds how long a captured, validly-signed message stays replay-usable before its signature is treated as expired. The two are the transport-layer and message-layer halves of the same bounded-freshness defense discipline. Read the replay-attacks spoke for the message-integrity counterpart to the policy-freshness window this page configures.
• 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.

Validate your MTA-STS policy now

DMARC Analyzer ingests TLS-RPT reports about your MTA-STS policy and surfaces per-result-type breakdowns in the dashboard. Cross-check the DNS + HTTPS state of your policy with the Domain Security Checker before deploying.

Sign up — Free plan Audit my MTA-STS policy