DMARC Analyzer

TL;DR

• Microsoft 365 MTA-STS is operator-driven at the DNS and external HTTPS layers — there is no Defender portal panel, no PowerShell cmdlet, no Exchange admin centre pane. Configuration lives entirely outside the Microsoft administrative surface.
• Four-step deployment: (1) publish the _mta-sts.<your-domain> TXT record with v=STSv1; id=<token>; (2) stand up an HTTPS endpoint at mta-sts.<your-domain> (M365 does NOT host this); (3) serve the policy file at /.well-known/mta-sts.txt with mode: testing initially; (4) publish the TLS-RPT companion record at _smtp._tls.<your-domain> for monitoring.
• The mx: directive enumerates the exact MX hostnames that deliver inbound mail to your tenant. For a standard M365 tenant with no on-prem hybrid this is typically <tenant>-com.mail.protection.outlook.com (where <tenant>-com is the dashed transformation of your domain: example.com → example-com).
• External HTTPS hosting is mandatory for the policy file. Common hosts: Azure Static Web Apps, Azure Front Door, Cloudflare Pages, AWS S3+CloudFront, GitHub Pages with custom domain, Netlify, Vercel, or any commodity LAMP/NGINX host. The certificate at mta-sts.<your-domain> must validate against the public PKI.
• Testing-mode burn-in: publish with mode: testing + max_age: 86400 (24h) for 1-2 weeks while TLS-RPT reports populate. Once sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, and certificate-host-mismatch are all absent for 7+ consecutive days, promote to mode: enforce and increase max_age to 604800 (one week) or higher.
• Exchange Online is BOTH a recipient (with M365 inbound MX) AND a sender (honoring MTA-STS on outbound TLS sessions). As a recipient, M365 provides the MX endpoint you enumerate in the mx: directive. As a sender, M365 fetches recipient MTA-STS policies and refuses to deliver over plaintext when mode: enforce is in effect.
• The id-token bump rule: every edit to the policy file MUST coincide with a fresh id= value in the _mta-sts TXT record. Senders use the id-token to detect when their cached policy is stale and should be re-fetched.
• MTA-STS does not replace DMARC; the two protocols protect different layers (MTA-STS protects transport encryption, DMARC protects sender authentication). Pair with DMARC for Microsoft 365 for end-to-end anti-spoofing protection.

What this guide covers

A focused operator-implementation walkthrough for MTA-STS (SMTP MTA Strict Transport Security, RFC 8461) on Microsoft 365 / Exchange Online tenants. Sibling pages cover the protocol primer (MTA-STS explained), the byte-level policy-file reference (MTA-STS policy file syntax), and the MTA-STS-vs-DANE decision view (MTA-STS vs DANE for SMTP). THIS page is the Microsoft-365-specific operator reference: the protection.outlook.com MX-enumeration in the mx: directive, the mandatory external HTTPS hosting for the mta-sts.<your-domain> subdomain (M365 does NOT serve the policy file natively), the absence of any Defender portal MTA-STS configuration UI, the TLS-RPT pairing for monitoring, and the hybrid-tenant mx-cutover discipline.

The page is anchored against current Microsoft 365 deployment realities: M365 tenants receive mail via <tenant>-com.mail.protection.outlook.com MX targets, Exchange Online honors recipient MTA-STS policies when sending outbound mail (from 2022 onward), and the Defender portal has no MTA-STS configuration panel. Hardening inbound SMTP transport against downgrade attacks via MTA-STS is therefore entirely an operator responsibility executed at the DNS and external HTTPS layers.

How Microsoft 365 MTA-STS deployment works

M365 MTA-STS deployment is structurally different from M365 DKIM and SPF deployment in three ways:

1. Configuration lives entirely outside the M365 admin surface

Unlike DKIM (configured in the Defender portal or via Set-DkimSigningConfig) and SPF (verified in the Defender portal via the domain authentication panel), MTA-STS has NO Microsoft administrative interface. There is no Set-MtaStsConfig cmdlet, no Get-MtaStsSigningConfig, no Defender portal toggle, and no Exchange admin centre panel. Configuration is purely DNS (the _mta-sts TXT record at your authoritative nameserver) plus external HTTPS (the policy file served at a non-Microsoft web host).

2. M365 provides the MX endpoint, not the policy host

Microsoft 365 supplies the inbound MX target that operators enumerate in the policy file mx: directive. For a standard tenant, this is <tenant>-com.mail.protection.outlook.com where the -com suffix is the dashed transformation of your domain (example.com → example-com). Microsoft does NOT host the policy file itself — Exchange Online is a mail platform, not a web platform. Operators must spin up a separate HTTPS host for the mta-sts.<your-domain> subdomain.

3. Microsoft 365 is also an MTA-STS-honoring sender

Exchange Online's outbound mail platform honors recipient MTA-STS policies. When delivering mail to a recipient domain that has published an MTA-STS policy in mode: enforce, Exchange Online fetches the policy, caches it for the policy's max_age, and refuses to deliver over plaintext or with an unauthenticated certificate. Operators do not need to enable this behaviour — it ships on by default in current Exchange Online tenants. The dual role (M365 as both recipient and sender) means every M365 tenant deploys MTA-STS for two independent reasons: to protect inbound mail arriving at the tenant's MX, and to ensure outbound mail to MTA-STS-emitting recipients delivers correctly.

Prerequisites

• An active Microsoft 365 tenant with at least one custom accepted domain (the domain you want to protect with MTA-STS). Verify with Get-AcceptedDomain via Exchange Online PowerShell.
• DNS administration rights at your custom domain's authoritative nameservers (to publish the _mta-sts TXT record, the _smtp._tls TLS-RPT TXT record, and a CNAME or A/AAAA record at the mta-sts subdomain that points at your chosen HTTPS host).
• Access to an external HTTPS hosting platform (Azure Static Web Apps, Azure Front Door, Cloudflare Pages, AWS S3 + CloudFront, GitHub Pages, Netlify, Vercel, or any commodity LAMP/NGINX host). The platform must support custom-hostname HTTPS with a publicly-trusted certificate for the mta-sts.<your-domain> hostname.
• A mailbox or webhook endpoint to receive TLS-RPT reports (typically tls-reports@<your-domain> on the M365 tenant itself, or a third-party TLS-RPT analytics provider like Hardenize, Postmark, or Valimail).
• DMARC and SPF already published for the custom domain — see DMARC for Microsoft 365 and SPF for Microsoft 365. MTA-STS protects the transport layer; DMARC and SPF protect the authentication layer. All three together form the canonical M365 anti-spoofing posture.

Step 1: Publish the _mta-sts DNS TXT record

The _mta-sts TXT record signals to senders that your domain publishes an MTA-STS policy and supplies the id-token they use to detect when their cached policy is stale. Publish a single TXT record at the _mta-sts label of your custom domain:

; Replace example.com with your custom domain and 20260522T120000
; with a fresh unique token (typically a timestamp; any string of 1-32
; alphanumeric characters is valid per RFC 8461 §3.1):

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

Two tags only: v=STSv1 (case-sensitive uppercase, MUST appear first) and id=<token> (1-32 alphanumeric characters, opaque to senders, used as a cache-bust signal). The record MUST live at the three-label name _mta-sts.<your-domain> (with a leading underscore on _mta-sts). Publishing at mta-sts.<your-domain> (without the underscore) is the #1 silent- record-ignoring drift class.

Verify publication with dig or Resolve-DnsName:

$ dig +short TXT _mta-sts.example.com
"v=STSv1; id=20260522T120000"

PS> Resolve-DnsName _mta-sts.example.com -Type TXT
Name                              Type   TTL   Section    Strings
----                              ----   ---   -------    -------
_mta-sts.example.com              TXT    3600  Answer     {v=STSv1; id=20260522T120000}

The id-token discipline matters operationally: every time you edit the policy file at https://mta-sts.<your-domain>/.well-known/mta-sts.txt, you MUST bump the id= value in this TXT record. Senders cache the policy by id-token; without the bump, they continue serving stale policy from cache for up to the max_age of the previous fetch.

Step 2: Stand up HTTPS hosting for mta-sts.<your-domain>

Microsoft 365 does NOT host the MTA-STS policy file. Operators must provision an external HTTPS endpoint at the mta-sts subdomain of their custom domain. The endpoint requirements per RFC 8461 §3.3:

• HTTPS-only. Plaintext HTTP on port 80 is not honored; senders fetch via HTTPS on port 443 only.
• Publicly-trusted TLS certificate. The certificate must validate against the public PKI (Let's Encrypt, DigiCert, GlobalSign, Sectigo, etc.) and its Subject CN or SAN must include mta-sts.<your-domain>. Self-signed certificates, private-CA certificates, and wildcard certificates that don't cover the mta-sts subdomain all cause sts-webpki-invalid in TLS-RPT and silent policy rejection.
• Content-Type text/plain on the policy file response. Other Content-Type values (notably application/octet-stream and text/html) cause sts-policy-invalid.
• HTTP/1.1 or HTTP/2. Both are honored; HTTP/3 is not yet universally supported on the sender side and should not be relied on as the sole transport.

Hosting options for an M365 tenant

The most common operator choices, in approximate order of M365-affinity:

1. Azure Static Web Apps (free tier, autoprovisions HTTPS certificate via Let's Encrypt). Easiest for tenants already running Azure workloads.
2. Azure Front Door (recommended if you already have an Azure Front Door instance fronting other web workloads — adds a routing rule rather than provisioning a new endpoint).
3. Cloudflare Pages or Cloudflare Workers (free tier, supports custom-hostname HTTPS via Cloudflare's certificate authority — typical for tenants already proxying their primary domain through Cloudflare).
4. AWS S3 + CloudFront (low cost, certificate via ACM). Common for organizations with existing AWS infrastructure.
5. GitHub Pages with custom domain (auto-HTTPS via Let's Encrypt, free for public repositories). The simplest zero-cost option for small tenants.
6. Netlify or Vercel (free tier, zero-config HTTPS).
7. Any commodity LAMP/NGINX host you already operate (works fine, requires manual certificate provisioning via Let's Encrypt or your existing CA).

DNS for the mta-sts subdomain

Whichever host you choose, publish a CNAME (or A/AAAA records, depending on the host's DNS pointer requirements) at mta-sts.<your-domain> pointing at the host:

; Example: Azure Static Web App fronted at mywebapp.azurestaticapps.net
mta-sts.example.com.  IN  CNAME  mywebapp.azurestaticapps.net.

; Example: Cloudflare Pages fronted at mypages.pages.dev
mta-sts.example.com.  IN  CNAME  mypages.pages.dev.

; Example: GitHub Pages custom domain — A records to GitHub's IPs
mta-sts.example.com.  IN  A      185.199.108.153
mta-sts.example.com.  IN  A      185.199.109.153
mta-sts.example.com.  IN  A      185.199.110.153
mta-sts.example.com.  IN  A      185.199.111.153

Verify the HTTPS endpoint is reachable and serves a valid certificate:

$ curl -v https://mta-sts.example.com/.well-known/mta-sts.txt
*   Trying 185.199.108.153:443...
* Connected to mta-sts.example.com
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* Server certificate:
*  subject: CN=mta-sts.example.com
*  start date: Mar  1 00:00:00 2026 GMT
*  expire date: May 30 23:59:59 2026 GMT
*  issuer: CN=Let's Encrypt R3, O=Let's Encrypt, C=US
*  SSL certificate verify ok.
> GET /.well-known/mta-sts.txt HTTP/2
< HTTP/2 200
< content-type: text/plain
< content-length: 78
version: STSv1
mode: testing
mx: example-com.mail.protection.outlook.com
max_age: 86400

Step 3: Publish the policy file at /.well-known/mta-sts.txt

Serve the policy file at the path /.well-known/mta-sts.txt on the mta-sts.<your-domain> HTTPS host. The file is plain text with one key: value pair per line per RFC 8461 §3.2. The four canonical keys:

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

Field-by-field:

version: STSv1

Case-sensitive uppercase STSv1. MUST appear first. Senders reject the policy when version is missing, mis-cased (stsv1, STSV1), or unrecognised.

mode:

One of enforce, testing, or none. Case-sensitive lowercase. testing: senders report failures via TLS-RPT but still deliver mail. enforce: senders refuse to deliver over plaintext or with an unauthenticated certificate. none: emergency-rollback signal — equivalent to having no policy. Standard rollout: publish with testing for 1-2 weeks, review TLS-RPT, promote to enforce.

mx:

One per line per MX host that handles inbound mail. For an M365 tenant, this is typically <tenant>-com.mail.protection.outlook.com — see the next section. Single-label wildcards (*.mail.protection.outlook.com) match exactly one label; multi-label wildcards (**.protection.outlook.com) are not supported by RFC 8461.

max_age:

Cache lifetime in seconds. 86400 (24h) is typical for initial testing-mode publication; 604800 (7 days) or 2592000 (30 days) for stable enforce-mode policies. RFC 8461 §3.2 caps max_age at 31557600 (one Julian year); senders MUST honor values up to that cap but MAY cap shorter (Google caps at 604800).

Worked example for a standard M365 tenant at example.com in initial testing-mode burn-in:

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

After 7-14 days with no TLS-RPT failures, promote to enforce mode with a longer max_age:

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

Don't forget to bump the id= value in the _mta-sts TXT record every time the policy file changes. Without the bump, senders continue serving the cached policy until their cached max_age expires.

Enumerating MX hosts in the mx: directive

The mx: directive is an enumeration — only listed hostnames can deliver mail under MTA-STS enforcement. Mis-listing an MX is the #1 reason legitimate inbound mail bounces after promoting to mode: enforce.

Standard M365 tenant (no hybrid, no third-party gateway)

Run dig +short MX <your-domain> to discover your tenant's MX target:

$ dig +short MX example.com
0 example-com.mail.protection.outlook.com.

The format is consistent across all Microsoft 365 tenants: <tenant>-com.mail.protection.outlook.com where <tenant>-com is the dashed transformation of your domain (example.com → example-com, dots replaced with dashes). The policy file mx: line enumerates exactly that hostname:

mx: example-com.mail.protection.outlook.com

Hybrid Exchange tenant (on-prem Edge + M365)

Tenants running Exchange Server on-premises with M365 hybrid mode often have a primary MX pointing at an on-prem Edge Transport server with a secondary or backup MX at the M365 endpoint. Enumerate both:

$ dig +short MX example.com
10 mail-edge.example.com.
20 example-com.mail.protection.outlook.com.

mx: mail-edge.example.com
mx: example-com.mail.protection.outlook.com

During hybrid cutover (migrating from on-prem to M365 cloud-only or vice-versa), update the mx: list BEFORE swapping MX records. Senders with cached policies will continue enforcing the old mx: list for up to max_age seconds — if you swap MX without updating the policy, mail to the new MX target bounces.

Third-party security gateway in front of M365

Tenants behind Mimecast, Proofpoint, Barracuda, FortiMail, or other security gateways have MX pointing at the gateway's public hostnames rather than directly at M365:

$ dig +short MX example.com
10 us-smtp-inbound-1.mimecast.com.
10 us-smtp-inbound-2.mimecast.com.

mx: us-smtp-inbound-1.mimecast.com
mx: us-smtp-inbound-2.mimecast.com

The gateway forwards mail to the M365 endpoint internally — that hop is not visible to external MTA-STS-honoring senders, so the protection.outlook.com hostname should NOT appear in mx: when a gateway is in front. Confirm the gateway itself supports STARTTLS and a valid publicly-trusted certificate before promoting to enforce mode.

Multi-domain tenant

Each accepted domain in a multi-domain M365 tenant needs its own MTA-STS policy with its own mx: list. The policies do NOT inherit across the tenant. A policy published at mta-sts.example.com does NOT protect mail delivered to example.co.uk in the same tenant — operators must publish separate _mta-sts.example.co.uk and mta-sts.example.co.uk/.well-known/mta-sts.txt pairs for each domain.

Step 4: TLS-RPT for monitoring

MTA-STS is operationally blind without TLS-RPT (SMTP TLS Reporting, RFC 8460). Senders report TLS handshake failures and policy-fetch failures back to you via the rua= mailbox declared in _smtp._tls.<your-domain>. Publish the companion record:

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

Senders honor TLS-RPT by submitting JSON reports per RFC 8460 §4 once per day summarising every TLS handshake outcome against your domain. The report enumerates summary.total-successful-session-count, summary.total-failure-session-count, and per-failure failure-details[] entries with result-type values from the 12-value catalogue (the MTA-STS-specific values to watch: sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-host-mismatch, certificate-expired, starttls-not-supported).

Without TLS-RPT, the testing-mode burn-in workflow is impossible — operators have no visibility into whether senders successfully fetched the policy and validated the certificate. Always publish TLS-RPT BEFORE promoting MTA-STS to enforce mode. See TLS-RPT explained, TLS-RPT DNS record syntax, and TLS-RPT JSON report format for the byte-level references.

Receiving TLS-RPT reports on Microsoft 365

The simplest setup uses a dedicated mailbox on the M365 tenant itself (tls-reports@<your-domain>). The mailbox receives JSON attachments with filename <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz] per RFC 8460 §5.1. Configure the mailbox to auto-forward to a TLS-RPT analytics provider (Hardenize, Postmark, Valimail, Skysnag) or build an in-house ingestion pipeline via the DMARC Analyzer API that parses the JSON attachments into the dmarc_tls_reports table.

Testing-mode burn-in workflow

The canonical testing-to-enforce migration discipline for an M365 tenant:

1. Week 0. Publish the _mta-sts TXT record, stand up HTTPS hosting, publish the policy file with mode: testing and max_age: 86400. Publish TLS-RPT pointing at tls-reports@<your-domain>.
2. Day 1-3. Confirm policy is reachable via curl and the certificate validates. Confirm DNS records resolve via dig.
3. Day 7. Begin reading TLS-RPT reports arriving from Google, Microsoft 365 (other tenants), Yahoo, ProtonMail, and other MTA-STS-honoring senders. Watch for sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, and certificate-host-mismatch in the failure-details[] array.
4. Week 2. If TLS-RPT reports show all four MTA-STS-specific failure types absent for 7+ consecutive days AND the total-successful-session-count is substantially greater than zero (so you know senders are actually attempting policy-validated delivery), promote to mode: enforce and increase max_age to 604800 (7 days). Bump the id= value in the _mta-sts TXT record.
5. Week 4. With enforce mode stable, increase max_age to 2592000 (30 days) for longer cache-pinning. Bump id= again.
6. Operational discipline. Every future change to MX records, the mta-sts.<your-domain> certificate, or the mta-sts.<your-domain> HTTPS host provider MUST be preceded by reverting to mode: testing for 24-72 hours while the change burns in. The cached-policy enforcement window is precisely why MTA-STS is brittle to infrastructure changes: cached enforce policies survive on the sender side until max_age expires regardless of what you change on your end.

Emergency rollback (mode: none)

If a misconfiguration causes legitimate inbound mail to bounce in enforce mode, revert to mode: none and bump the id-token. Senders fetch the new policy on their next cache-bust signal (within minutes of the TXT record TTL expiring) and suspend enforcement. mode: none is semantically equivalent to having no policy — emergency-rollback only.

Ten common Microsoft 365 MTA-STS mistakes

1. Assuming Microsoft hosts the policy file. Exchange Online is a mail platform, not a web platform. Microsoft 365 does NOT serve content at mta-sts.<your-domain>; operators must spin up an external HTTPS host. The single most common "where do I start" confusion.
2. Looking for an MTA-STS panel in the Defender portal. There is none. MTA-STS configuration is entirely DNS + external HTTPS, outside the Microsoft administrative surface. No PowerShell cmdlet, no Exchange admin centre pane.
3. Publishing the policy file at the bare apex domain instead of the mta-sts subdomain. RFC 8461 §3.3 locks the hostname to mta-sts.<domain> — publishing the file at https://<your-domain>/.well-known/mta-sts.txt is silently ignored by senders.
4. Forgetting the leading underscore on the TXT record. The DNS record lives at _mta-sts.<domain> (underscore prefix per RFC 8552 underscore-label convention). Publishing at mta-sts.<domain> (no underscore) confuses MTA-STS configuration with the HTTPS host configuration and produces silent record-ignoring.
5. Promoting to enforce before the policy file is reachable. With mode: enforce in effect, a broken HTTPS endpoint causes sts-policy-fetch-error on every sender and inbound mail bounces. Always confirm the endpoint is reachable via curl and the certificate validates BEFORE promoting to enforce.
6. Enumerating the wrong MX hostname in the mx: directive. For a standard M365 tenant the MX is <tenant>-com.mail.protection.outlook.com; for a hybrid Exchange tenant both the on-prem MX and the M365 MX must be enumerated; for a third-party gateway only the gateway MX appears in the list. Mis-enumeration causes legitimate mail to bounce in enforce mode.
7. Forgetting to bump the id-token after a policy edit. Senders cache the policy by id-token; without the bump, the cached policy persists until max_age expires regardless of what you change on your end. Every policy edit MUST be paired with an id= bump in the _mta-sts TXT record.
8. Using a wildcard certificate that doesn't cover the mta-sts subdomain. A *.example.com wildcard covers mta-sts.example.com; a example.com bare-apex certificate does NOT. Operators reusing an existing apex certificate for the mta-sts hostname see sts-webpki-invalid on every TLS-RPT report.
9. Skipping TLS-RPT. Without TLS-RPT, the testing-mode burn-in workflow is impossible — operators have no visibility into whether senders successfully fetched and validated the policy. Always publish TLS-RPT BEFORE the MTA-STS policy.
10. Capital-letter mode value. Mode: Enforce with capital E (or any other capitalisation variant) fails the token match per RFC 8461 §3.2. The value MUST be lowercase enforce, testing, or none.

Troubleshooting decision matrix

Map the observed TLS-RPT failure type or operator symptom to the diagnostic next step:

• Symptom: TLS-RPT reports show sts-policy-fetch-error.
  Diagnosis: Senders cannot fetch the policy file. Either the HTTPS endpoint is unreachable, the certificate is invalid, the Content-Type is wrong, or the mta-sts subdomain DNS does not resolve.
  Fix: Run curl -v https://mta-sts.<your-domain>/.well-known/mta-sts.txt — confirm 200 OK with content-type: text/plain and a Let's Encrypt / DigiCert certificate chain.
• Symptom: TLS-RPT reports show sts-policy-invalid.
  Diagnosis: The policy file is reachable but does not parse. Possible causes: UTF-8 BOM at file head, comments (# lines) in the file, capital-letter Mode: Enforce, missing version: or max_age: key, malformed line endings.
  Fix: Re-save the policy file with a BOM-free editor, confirm only the four canonical keys appear, confirm all values are lowercase. See MTA-STS policy file syntax for the full byte-level reference.
• Symptom: TLS-RPT reports show sts-webpki-invalid or certificate-host-mismatch.
  Diagnosis: The certificate at mta-sts.<your-domain> either does not validate against the public PKI (self-signed, private CA, missing intermediates) or its Subject CN / SAN does not include mta-sts.<your-domain> exactly.
  Fix: Run openssl s_client -connect mta-sts.<your-domain>:443 -servername mta-sts.<your-domain> — confirm the chain bundles intermediates and the end-entity certificate matches the hostname. Provision a fresh Let's Encrypt certificate specifically for the mta-sts subdomain.
• Symptom: Mail bounces with "TLS required but not available" or "MTA-STS enforcement failure" after promoting to enforce.
  Diagnosis: The mx: directive enumerates a hostname that does not match the actual MX target, or the actual MX target does not advertise STARTTLS with a valid certificate.
  Fix: Run dig +short MX <your-domain> — confirm every returned MX hostname appears in the mx: directive verbatim. Revert to mode: testing temporarily if the bounce rate is impacting business.
• Symptom: No TLS-RPT reports arrive even after 7 days.
  Diagnosis: Either the domain has insufficient inbound mail from MTA-STS-honoring senders (low-traffic domain), the _smtp._tls TXT record is mis-published (missing leading underscore, wrong scheme prefix on rua=, missing version tag), or the rua= mailbox is unreachable.
  Fix: Verify dig +short TXT _smtp._tls.<your-domain> returns "v=TLSRPTv1; rua=mailto:<mailbox>". See TLS-RPT DNS record syntax for the full byte-level reference.

Frequently asked questions

How do I enable MTA-STS on Microsoft 365?

Four steps. (1) Publish the MTA-STS DNS TXT record at _mta-sts.<your-domain> with value "v=STSv1; id=<unique-token>" (the id-token changes whenever the policy file is updated). (2) Stand up an HTTPS endpoint at mta-sts.<your-domain> (Microsoft 365 does NOT host the policy file — typical hosts are Azure Static Web Apps, Azure Front Door, Cloudflare Pages, AWS S3+CloudFront, or any commodity HTTPS host with a publicly-trusted certificate). (3) Serve the policy file at https://mta-sts.<your-domain>/.well-known/mta-sts.txt with Content-Type text/plain, containing version: STSv1, mode: testing (initially) or mode: enforce (once burned in), one mx: line per MX host that handles your inbound mail (for M365 tenants this is typically <tenant>-com.mail.protection.outlook.com where <tenant>-com is the dashed transformation of your domain), and max_age: 86400 (24 hours) initially, increasing to 604800 (one week) or higher once stable. (4) Publish a TLS-RPT record at _smtp._tls.<your-domain> with v=TLSRPTv1; rua=mailto:tls-reports@<your-domain> so senders report TLS handshake failures and policy-fetch failures back to you. Microsoft 365 has NO Defender-portal MTA-STS panel — all configuration is DNS + external HTTPS.

What MX hosts should I list in my Microsoft 365 MTA-STS policy?

The exact MX hostname(s) Microsoft published for your tenant's accepted domains. Run dig +short MX <your-domain> to see the canonical values. For a standard M365 tenant with no on-prem hybrid and no third-party security gateway, you will see one MX target with the shape <tenant>-com.mail.protection.outlook.com where <tenant>-com is the dashed transformation of your domain (example.com → example-com.mail.protection.outlook.com). List that exact hostname in the mx: directive of your MTA-STS policy file. For multi-domain tenants, each accepted domain needs its own MTA-STS policy with its own mx: list — the policies do NOT inherit across the tenant. For hybrid Exchange tenants routing some mail through an on-prem Edge Transport server, list both the on-prem MX and the M365 MX. For tenants behind a third-party security gateway (Mimecast, Proofpoint, Barracuda, Fortinet), list the gateway MX (mail.protection.com hostnames are replaced by the gateway's public hostnames). The mx: directive is an enumeration — only listed hostnames can deliver mail under MTA-STS enforcement.

Where do I host the MTA-STS policy file for a Microsoft 365 tenant?

Anywhere that can serve a static text file over HTTPS with a publicly-trusted certificate matching mta-sts.<your-domain>. Microsoft 365 does NOT host the file natively — Exchange Online is a mail platform, not a web platform; there is no SharePoint / OneDrive / Defender route to publish a /.well-known/mta-sts.txt file on the mta-sts subdomain. Operators commonly use: (a) Azure Static Web Apps (free tier, autoprovisions HTTPS), (b) Azure Front Door (if you already use Azure for other workloads), (c) Cloudflare Pages or Cloudflare Workers (free tier, supports custom-hostname HTTPS), (d) AWS S3 with CloudFront for the certificate front-end, (e) GitHub Pages with a custom domain (auto-HTTPS via Let's Encrypt), (f) Netlify or Vercel static hosting, (g) any commodity LAMP / NGINX host where you already run a website. The hostname must be exactly mta-sts.<your-domain> (not www.mta-sts or mta-sts1 — the convention is locked by RFC 8461). The certificate at that hostname must validate against the public PKI; a self-signed cert or a wildcard cert that doesn't cover mta-sts.<your-domain> causes sts-webpki-invalid in TLS-RPT reports and silent policy rejection.

Why does my MTA-STS policy fetch fail with a certificate error for an M365 tenant?

Most likely the certificate at mta-sts.<your-domain> does not match the hostname being fetched, has expired, or was issued by a CA outside the public PKI trust store. Diagnose with three commands. (1) openssl s_client -connect mta-sts.example.com:443 -servername mta-sts.example.com -showcerts </dev/null returns the served certificate chain — verify the Subject CN or SAN includes mta-sts.example.com (NOT just example.com — wildcards must be *.example.com explicitly, not example.com on its own). (2) curl -v https://mta-sts.example.com/.well-known/mta-sts.txt returns the served file — verify the HTTP/2 status is 200 OK and the Content-Type is text/plain. (3) curl -v --cacert /path/to/empty.pem https://mta-sts.example.com/.well-known/mta-sts.txt with an empty CA store fails — verify the certificate chain bundles intermediates (a common oversight: serving only the end-entity certificate without the intermediate chain so commodity clients without the intermediate cached in their TLS stack fail validation). Microsoft 365 itself does NOT supply or proxy the certificate for the mta-sts.<domain> subdomain — operators must obtain and serve it from the chosen HTTPS host.

Does Microsoft 365 honor MTA-STS policies when sending mail outbound (does Exchange Online enforce MTA-STS as a sender)?

Yes. Exchange Online (the M365 outbound platform) acts as an MTA-STS-honoring SENDER: when delivering mail outbound to a recipient domain that has published an MTA-STS policy (either at <domain> directly or at a recipient-side accepted domain), Exchange Online (a) fetches the recipient's policy at https://mta-sts.<recipient-domain>/.well-known/mta-sts.txt, (b) caches it for the policy's max_age, (c) enforces the policy on outbound TLS sessions for that domain (refuses to deliver over plaintext or with an unauthenticated certificate when mode: enforce is in effect), and (d) emits TLS-RPT reports back to the recipient's rua= mailbox detailing every TLS handshake failure or policy-fetch failure observed. This means recipients running Microsoft 365 receive MTA-STS-enforced delivery from any sender whose outbound system honors MTA-STS (Microsoft 365, Google Workspace, Yahoo, ProtonMail, and most modern commercial MTAs). Microsoft published the enforcement-side timeline starting from 2022; current Exchange Online tenants honor MTA-STS by default with no operator configuration.

How do I verify my Microsoft 365 MTA-STS deployment is working?

Five verification gates. (1) DNS: dig +short TXT _mta-sts.<your-domain> must return "v=STSv1; id=<token>". (2) HTTPS endpoint: curl -v https://mta-sts.<your-domain>/.well-known/mta-sts.txt must return HTTP/2 200 OK with Content-Type text/plain and the four canonical keys (version: STSv1, mode:, mx:, max_age:). (3) Certificate: openssl s_client -connect mta-sts.<your-domain>:443 -servername mta-sts.<your-domain> must return a chain whose end-entity certificate Subject CN or SAN includes mta-sts.<your-domain> and validates against the public PKI. (4) Policy file content: the mx: directive must enumerate every hostname that appears in dig +short MX <your-domain> — typically <tenant>-com.mail.protection.outlook.com for an M365 tenant. (5) End-to-end TLS-RPT: 24-72 hours after publication, the rua= mailbox at _smtp._tls.<your-domain> begins receiving JSON reports from major senders (Google, Microsoft 365, Yahoo) detailing policy-fetch success, TLS handshake outcomes, and failure-details for any handshake or policy-fetch errors. Empty or absent TLS-RPT reports means either (a) no senders have attempted delivery yet (low-traffic domain), or (b) the rua= mailbox is mis-published or the receiving endpoint refuses inbound mail.

Can I use the Microsoft 365 Defender portal to configure MTA-STS?

No. The Microsoft 365 Defender portal (security.microsoft.com) has panels for SPF, DKIM, DMARC, ARC, and Connection Filter policy, but it has NO MTA-STS panel. MTA-STS is a recipient-side hardening protocol: the recipient publishes a DNS TXT record at _mta-sts.<domain> and serves a policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt, and senders honor that policy when delivering mail to the recipient. Microsoft 365 (the recipient platform) provides MX hosts (<tenant>-com.mail.protection.outlook.com) that operators enumerate in their policy mx: directive, but Microsoft does NOT publish the DNS record or host the policy file on the operator's behalf. All MTA-STS configuration for an M365 tenant is operator-driven at the DNS and HTTPS layers — there is no PowerShell cmdlet (no Set-MtaStsConfig), no Defender portal toggle, no Exchange admin center pane. The pragmatic workflow: publish the DNS record at your authoritative nameserver, stand up an HTTPS host for the policy file, observe via TLS-RPT — all entirely outside the Microsoft administrative surface.

Related guides

• MTA-STS explained — the protocol pillar deep-dive covering RFC 8461: the DNS record, the HTTPS-served policy file, the policy modes (none/testing/enforce), MTA-STS vs DANE, the testing-to-enforce migration workflow, and integration with TLS-RPT for monitoring.
• DKIM canonicalization — the M365-EXCHANGE-ONLINE-EOP-SAFE-LINKS- AND-LINK-REWRITING-AND-DISCLAIMER-INJECTION- MODIFY-BODY-AFTER-DKIM-SIGNING-AND- CANONICALIZATION-PAIR-CHOICE-DETERMINES- DOWNSTREAM-VERIFICATION-SURVIVAL companion to this M365-tenant MTA-STS deployment guide. Where THIS page documents the M365-tenant RECEIVE-SIDE STARTTLS- enforcement deployment via the _mta-sts.<tenant>.<tld> TXT-record + HTTPS-served policy-file pattern for Exchange Online inbound traffic, the DKIM-canonicalization spoke is the M365-OUTBOUND-MESSAGE-IDENTITY companion documenting the STRUCTURALLY-CONSEQUENTIAL canonicalization- pair choice the M365 tenant signs with at outbound (typically c=relaxed/relaxed as the EOP-DKIM-signer default) and the per-pair survival profile under the FOUR canonical M365-Exchange-Online post-signing body-modification events: (i) EOP's Safe Links URL- rewriting modifies every clickable URL in the body to a nam01.safelinks.protection.outlook .com/?url=... wrapped form — this is a SUBSTANTIVE body-content modification that DEFINITELY breaks c=*/simple bodyhash and FREQUENTLY breaks c=*/relaxed bodyhash (the URL wrapping is more than whitespace- normalisation, even with the relaxed canonicalization's whitespace + empty- trailing-line tolerance); operators whose tenant has Safe Links enabled OUTBOUND must coordinate with the recipient-side ARC-signer at the EOP-egress boundary to seal the post-rewriting bytes for downstream chain-of-custody validation; (ii) EOP's organization-wide disclaimer injection appends an HTML footer to every outbound message — this is a SUBSTANTIVE body-content modification that DEFINITELY breaks any c=*/simple or c=*/relaxed bodyhash IF the disclaimer is injected POST-SIGNING (operators must confirm via the EOP transport rule precedence whether the Add-Disclaimer action precedes or follows the DKIM-signing action, which is configurable per the Microsoft-managed transport-rule pipeline architecture); (iii) EOP's hybrid-Exchange-on- prem-relay path may add additional Received: + X-Originating-IP headers after the tenant's outbound DKIM-signing — adding unsigned headers does NOT break the signature (only headers in the h= tag are part of the hash), but re-ordering or modifying signed headers (e.g. EOP rewrites Sender: to the original-sender proxy address) DOES break the signature under c=*/simple and may break under c=*/relaxed if the modification is more than whitespace-noise; (iv) the cross-tenant Exchange-Online- connector path for B2B mail flow applies the tenant's outbound transport rules + EOP's anti-spoofing rules, producing a canonicalization- survival surface specific to the connector pair — operators must verify the recipient tenant's EOP does NOT apply Add-Authentication-Results in a way that strips the original DKIM-Signature header before the recipient's mailbox-store receives it. Read the DKIM- canonicalization spoke alongside this M365 MTA-STS deployment guide when the operator is investigating "why does my outbound mail to External partner's tenant pass MTA-STS TLS but fail DKIM-bodyhash at their EOP", when planning the M365 tenant's outbound EOP transport-rule precedence ordering (sign-then-modify vs modify-then-sign), or when coordinating the Safe Links rollout with the tenant's existing DKIM-Signature emission posture.
• MTA-STS policy file syntax — the byte-level reference for the policy file served at https://mta-sts.<domain>/.well-known/mta-sts.txt per RFC 8461 §3.2: the four canonical keys (version, mode, mx, max_age), the HTTPS+public-PKI fetch contract, the no-BOM and no-comments rules, the id-token coupling.
• MTA-STS vs DANE for SMTP — the side-by-side comparison spoke covering RFC 8461 (MTA-STS, web PKI trust) vs RFC 7672 (DANE for SMTP, DNSSEC trust), the canonical DANE-EE TLSA deployment shape, provider support reference, the RFC 7672 §1.3 coexistence rule, decision matrix, migration paths.
• MTA-STS for Google Workspace — the sibling provider-deployment spoke covering the same RFC 8461 protocol for Google Workspace tenants. Operators running mixed M365 + Workspace estates (a common large-enterprise pattern) deploy both with subtly different moving parts: Workspace uses a single-MX architecture (aspmx.l.google.com) vs Exchange Online's tenant-specific MX (<tenant>.mail.protection.outlook.com), and the Workspace policy file omits the M365-style FQDN-wildcard *.protection.outlook.com pattern in favour of a single mx: aspmx.l.google.com line plus the four Google secondary backup MXes. Read this when planning cross-tenant SMTP transport encryption rollouts or comparing the two provider-deployment shapes.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460): the DNS record (_smtp._tls, v=TLSRPTv1; rua=), the JSON report format, the result-type catalogue. The companion protocol that makes MTA-STS testable.
• TLS-RPT DNS record syntax — the byte-level reference for the TLS-RPT TXT record at _smtp._tls.<domain> per RFC 8460 §3.
• TLS-RPT JSON report format — the semantic-layer reference for the on-the-wire TLS-RPT report schema per RFC 8460 §4, including the 12 canonical result-type values to watch for in failure-details[].
• DMARC for Microsoft 365 — the broader DMARC rollout for M365 tenants. MTA-STS and DMARC protect different layers (transport vs authentication); deploy both for end-to-end protection.
• DMARC for SaaS senders — the M365-MTA-STS-INBOUND-DEFENSE- AGAINST-SAAS-PLATFORM-SHARED-POOL-IP companion to this M365 MTA-STS deployment guide. Where THIS page documents the per-M365-tenant _mta-sts.<domain> TXT-record + mta-sts.<domain> HTTPS-policy-host publication workflow for Exchange Online tenants, the SaaS- senders spoke is the MULTI-TENANT- PLATFORM-SHARED-POOL-IP-INBOUND- TRANSPORT-LAYER-CROSS-TENANCY- COORDINATION REFERENCE documenting FOUR M365-MTA-STS-vs-SaaS-platform cross-tenancy coordination dimensions any operator running BOTH an M365 tenant AND outbound mail delegated to a SaaS multi-tenant platform must coordinate: (i) M365 inbound MTA-STS policy publication closes the SaaS-platform shared-pool-IP spoofed inbound delivery surface — the M365 tenant's MTA-STS policy enforces STARTTLS-encrypted delivery to the canonical Exchange-Online MX hostname glob list (*.mail.protection.outlook.com), rejecting cleartext-fallback inbound delivery attempts a SaaS-platform shared-pool-IP-spoofing attacker could otherwise use to bypass per- tenant DMARC; (ii) per-M365- tenant testing→enforce mode- progression coordination with the SaaS-platform outbound delivery observability — operators running BOTH an M365 tenant AND outbound mail through a SaaS platform must coordinate the per-tenant testing→enforce MTA-STS mode- progression with the SaaS-platform- side outbound-delivery observability to ensure the SaaS platform's MTA respects the M365 tenant's enforce- mode policy when delivering customer- marketing mail back to the M365 tenant's own employees; (iii) per-tenant TLS-RPT _smtp._tls.<domain> JSON-aggregate ingestion as cross- tenancy transport-layer observability primitive — the M365 tenant's per-tenant TLS-RPT mailbox aggregates per-receiver TLS-negotiation outcome rows from EVERY upstream sender including the SaaS platforms the tenant has delegated outbound marketing mail to, providing the operator-side transport-layer observability for the cross-tenancy delivery boundary; (iv) cross- tenancy transport-layer-failure root- cause attribution — when TLS-RPT JSON rows surface delivery failures the operator must attribute between M365-side policy misconfiguration vs SaaS-platform- side MTA configuration vs in-flight TLS-stripping — the SaaS-senders spoke documents the cross-tenancy attribution discipline. Pair this M365 MTA-STS deployment guide (the per-M365-tenant inbound transport- layer policy publication reference) with the SaaS-senders spoke (the multi-tenant-platform shared-pool-IP cross-tenancy coordination reference) for any operator running BOTH an M365 tenant AND outbound mail delegated to a SaaS multi-tenant platform.
• DMARC for Office 365 hybrid — the dual-transport-path sibling within the M365 deployment cluster — the M365-cluster-sibling deep dive on the Exchange-hybrid-coexistence topology where the MTA-STS transport-security deployment THIS page documents (single- path Exchange-Online-only MTA-STS policy publication for the canonical *.mail.protection.outlook.com MX-host list) is BOTH MORE COMPLEX AND STRUCTURALLY-DIFFERENT than the cloud-only deployment because the hybrid topology has TWO inbound transport paths: the EOP inbound path documented on THIS page AND the on-prem Exchange edge MTA inbound path that the on-prem mailboxes receive mail through. This dual-path inbound topology creates a material MTA-STS deployment constraint the cloud-only deployment documented on this page does not address: the hybrid operator must either (a) publish a single MTA-STS policy that authorises BOTH the EOP MX hosts AND the on-prem Exchange edge MTA hostnames (which expands the mx: directive list beyond the canonical *.mail.protection.outlook.com list this page documents), or (b) publish a single MTA-STS policy that authorises ONLY the EOP MX hosts which means on-prem-mailbox inbound mail flowing through the on-prem edge MTA hostnames is REJECTED by sending MTAs that enforce the MTA-STS policy (a partial-coverage outcome many hybrid operators want to AVOID during coexistence). Read the hybrid-deployment spoke when the hybrid topology's dual-inbound-path structure interacts with the single-path MTA-STS policy this page documents — the hybrid spoke documents the dual-transport-path topology variation of the same M365 deployment cluster the cloud-only MTA-STS spoke lives in. Closes the M365-cluster sibling-orphan parity gap between MTA-STS-for-Microsoft-365 (single- transport-path cloud-only) and DMARC-for-Office-365-hybrid (dual- transport-path coexistence).
• SPF for Microsoft 365 — the SPF operator reference. SPF + DKIM together are the alignment prerequisite for DMARC enforcement; MTA-STS is the orthogonal transport- encryption layer.
• DKIM for Microsoft 365 — the DKIM operator reference for M365: the dual-selector CNAME-delegated architecture, the Defender portal workflow, automatic 2048-bit key rotation.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DKIM-SIGNED- OUTBOUND-TO-M365-MTA-STS-RECEIVE- BOUNDARY cross-provider companion to this M365 MTA-STS deployment pillar. Where THIS page documents the M365- tenant-published MTA-STS policy (the https://mta-sts.<m365- domain>/.well-known/mta-sts.txt policy file with mx: *.mail.protection.outlook.com wildcard, the mode: testing burn-in / mode: enforce terminal posture progression, the max_age: policy-cache TTL contract, the receiver-side STARTTLS- enforcement contract cooperating sending MTAs apply when delivering to Exchange Online inbound MX, the TLS- RPT feedback-loop for per-MX-host failure attribution) — i.e. the M365- RECEIVE-SIDE-TRANSPORT-LAYER-MTA-STS side of cross-provider mail delivery — the Workspace-DKIM spoke is the WORKSPACE-TENANT-DKIM-SIGNED-SENDER- SIDE companion documenting the Workspace-tenant-specific DKIM deployment topology whose cryptographically-valid DKIM-Signature header travels across the cross- provider delivery boundary the M365 MTA-STS policy bounds at the transport layer. Concretely, the spoke documents FOUR Workspace-DKIM-to-M365-MTA-STS- cross-provider-coordination dimensions: (i) Workspace-tenant-outbound DKIM-signed mail to M365-hosted recipient domains traverses the M365- tenant-published MTA-STS enforce-mode policy at the SMTP session boundary — the Workspace- tenant DKIM-Signature header the spoke documents ( d=<workspace-tenant-domain>; s=google; h=From:To:Subject:Date; b=<rsa-signature>) travels within the SMTP DATA phase that STRUCTURALLY follows the cross-provider STARTTLS negotiation THIS page documents — the Workspace-tenant-DKIM- signing-identity is STRUCTURALLY ORTHOGONAL to the M365-receiver-side MTA-STS STARTTLS-enforcement verdict that runs at the transport layer BEFORE the SMTP DATA phase carries the Workspace-DKIM-Signature header body across the cross-provider boundary; (ii) Workspace-tenant-sending- MTA performs MTA-STS policy-cache lookup at the M365-receiving-domain boundary BEFORE opening the SMTP DATA phase carrying the Workspace-DKIM- signed message — the Workspace-tenant sending MTA fetches the M365 operator's https://mta-sts.<m365- domain>/.well-known/mta-sts.txt policy file at policy-cache-miss-or- rollover time, validates the policy signature + cert chain, then enforces the policy's mx: directive + mode: contract on the SMTP session BEFORE the Workspace- DKIM-signed message body crosses the cross-provider boundary — making the Workspace-DKIM-signing-cadence the spoke documents structurally INDEPENDENT of the M365-MTA-STS- policy-cache rollover cadence THIS page documents; (iii) Workspace-tenant-outbound mail to M365 recipients is envelope-encrypted by M365-receiver-side MTA-STS- enforced-STARTTLS at the transport layer but the Workspace-DKIM-signature is APPLICATION-LAYER ORTHOGONAL to the transport-layer encryption envelope — the M365 MTA-STS policy this page documents binds the SMTP session to enforced TLS at the transport layer, and the Workspace- DKIM-Signature header the spoke documents authenticates the message- body integrity at the application layer — both contracts cooperate on cross-provider delivery from Workspace to M365 but operate at structurally- distinct protocol layers; and (iv) cross-provider Workspace- to-M365 TLS-RPT failure correlation requires per-M365-MX-host failure attribution coordinated with per- Workspace-tenant DKIM-failure aggregation across the cross-provider boundary — when an M365- receive-side MTA-STS-enforce-mode STARTTLS failure event surfaces in the M365 TLS-RPT report stream for the Workspace-tenant-outbound cohort, the Workspace-tenant operator's TLS- RPT-report-stream coordination contract with the M365 operator's per-MX-host failure attribution discipline THIS page documents is the load-bearing cross-provider observability primitive — both Workspace-tenant-side and M365- tenant-side reporting streams correlate to attribute the cross- provider delivery failure to the Workspace-DKIM-signed-outbound mail cohort traversing the M365 MTA-STS enforce-mode policy boundary. Read the DKIM-for-Google-Workspace spoke alongside this M365 MTA-STS deployment pillar when planning cross-provider Workspace-to-M365 outbound DKIM-signed mail delivery — the Workspace-tenant-specific single-selector operator-published TXT-record DKIM deployment topology the spoke documents is the load- bearing sender-side application-layer DKIM-signing primitive whose cryptographically-valid DKIM-Signature header crosses the cross-provider delivery boundary the M365 MTA-STS policy THIS page documents bounds at the transport-layer-STARTTLS- enforcement contract.
• Email authentication explained — the cluster intro page tying SPF + DKIM + DMARC + ARC + MTA-STS + DANE + TLS-RPT + BIMI together.
• DANE for SMTP explained — the DANE pillar deep-dive (RFC 7672 + RFC 6698). The DNSSEC-anchored alternative to MTA-STS for SMTP transport authentication.
• CAA records explained - the M365-TENANT-MTA-STS-POLICY-HOST- HTTPS-CERT-ISSUANCE-CA-AUTHORITY-PERMISSION- GATING companion to this M365-MTA-STS deployment reference. Where THIS page documents the M365-tenant-specific MTA-STS publication workflow (the _mta-sts.<tenant-domain> TXT-anchor record with the v=STSv1; id=<timestamp> format, the HTTPS-served https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt policy file with version + mode + mx + max_age fields, the EOP-managed *.protection.outlook.com inbound MX target inclusion in the policy mx: directive list, the testing-mode → enforce-mode ramp coordination), the dedicated CAA-records spoke documents the STRUCTURALLY-DISTINCT cert-issuance-authority publication discipline at FOUR M365-MTA-STS-specific CAA coordination dimensions: (i) M365-tenant's mta-sts.<tenant-domain> HTTPS-policy-host effective owner-name requires a CAA record permitting the HTTPS-cert-issuing CA (typically Let's Encrypt via ACME-DNS-01 challenge or ACME-HTTP-01 challenge) - the M365 tenant operator must publish either an apex CAA record (climbing-up-the-zone CAA- inheritance per RFC 8659 §3) or a per- subdomain CAA record at mta-sts.<tenant-domain> permitting Let's Encrypt cert issuance before automated cert renewal can succeed at the policy host; the CAA- records spoke documents the per-subdomain CAA-publication discipline for the mta-sts. sub-owner-name; (ii) M365 tenants commonly host the MTA-STS policy file on a third-party CDN (Cloudflare Pages, AWS CloudFront, Azure Static Web Apps) rather than on a tenant- managed origin server - the third-party CDN's cert-issuance happens against the tenant's mta-sts.<tenant-domain> owner-name via the CDN's automated cert- provisioning workflow, which structurally requires CAA permission for the CDN's cert-issuing CA at the tenant's zone; the CAA-records spoke documents the per-CDN cert-issuance- authority catalogue and the per-tenant CAA-permission publication discipline the third-party CDN MTA-STS hosting model requires; (iii) M365-tenant cert rotation for the mta-sts.<tenant-domain> host coordinates with the CDN's cert- rotation cadence (typically 60-90 day rotation via Let's Encrypt automation) - the CAA record at the M365 tenant zone must remain published and consistent across the entire cert-rotation lifetime because any CAA-permission gap during the rotation window blocks the next automated cert renewal and produces a cert-expiry incident at the policy host; the CAA-records spoke documents the cert-rotation-vs-CAA- publication consistency discipline across the cert-renewal lifecycle; and (iv) RFC 8659 §4 CAA-record extension accounturi tag enables per-CA account-bound automated cert renewal that the M365-tenant operator can use to limit mta-sts.<tenant-domain> cert issuance to the specific Let's Encrypt account associated with the operator's automation infrastructure - the per-account-binding CAA-extension provides additional anti-attacker-cert- issuance defense beyond the baseline issue= permission tag the M365 tenant publishing the MTA-STS policy host benefits from; the CAA- records spoke documents the accounturi CAA-extension publication discipline as the per-CA account-bound automation contract M365-MTA-STS deployment can consume. Read the dedicated CAA-records spoke alongside this M365-MTA-STS deployment page when scoping the cert- issuance-authority publication discipline for the mta-sts.<tenant-domain> HTTPS-policy-host cert that the M365 tenant's MTA-STS deployment structurally depends on - the spoke is the authoritative RFC 8659 CAA-record reference whose four M365-MTA-STS-specific CAA-coordination boundaries this M365 MTA-STS deployment page is the policy- host-cert-binding companion for.
• SPF for Google Workspace — the PEER-CLOUD-MAILBOX-PROVIDER- WORKSPACE-TENANT-SPF-PUBLICATION-AS- LOAD-BEARING-SENDER-SIDE-AUTHENTICATION- EVIDENCE-EVERY-M365-INBOUND-SPAM- FILTER-CONSUMES companion to THIS M365 MTA-STS deployment reference. Where THIS page documents the per-M365-tenant MTA-STS deployment (the _mta-sts.<tenant> TXT-record publication, the mta-sts.<tenant> policy-host HTTPS publication, the mx: M365-MX-pattern policy-host attestation, the mode:enforce commitment- ramp, the per-tenant TLS-RPT observation discipline), the SPF-for- Google-Workspace spoke is the PEER- CLOUD-PROVIDER SENDER-SIDE AUTHENTICATION-PUBLICATION REFERENCE documenting the per-Workspace-tenant SPF publication discipline every M365 EOP inbound spam-filter consumes for the Workspace→M365 mail-flow leg at FOUR cross-cloud-Workspace-to-M365- mail-flow-leg-authentication- publication-coupling dimensions: (i) per-Workspace-tenant include:_spf.google.com SPF publication is the per-Workspace- tenant authentication-record M365 EOP inbound SPF-evaluator consumes for inbound mail-from-Workspace- senders — the SPF-for- Workspace spoke documents the per- Workspace-tenant SPF cascade publication discipline whose per-source-IP SPF verdict is the message-layer authentication- evidence M365 EOP inbound consumes for the Workspace→M365 mail-flow leg (the same per-leg authentication- record consumption pattern THIS page documents for the M365-tenant inbound-MX side of the TLS handshake, but at the message-layer SPF evaluation step); (ii) per- Workspace-tenant outbound-smarthost / per-tenant mail-flow-connector gateway IP-list is the source-IP topology M365 EOP inbound spam- filter authenticates against the published Workspace SPF — the SPF-for-Workspace spoke documents the per-Workspace-tenant outbound-gateway publication discipline (per-tenant smarthost delegation, per-third-party-sender cascade extension, per-tenant custom outbound-IP-range publication) whose IP-coverage completeness determines whether M365 EOP inbound records SPF-Pass for the Workspace→M365 mail-flow leg — the cross-cloud sender- side counterpart to the per-M365- tenant MX-pattern mx: attestation discipline THIS page documents on the M365-receiver- side; (iii) per-Workspace- tenant SPF-alignment with the Header-From determines whether M365 EOP records dmarc=pass for the Workspace→M365 mail-flow leg — the SPF-for-Workspace spoke documents the per-Workspace-tenant SPF-alignment discipline (per-tenant Header-From organisational-domain choice, per-tenant envelope-MAIL-FROM publication relative to Header-From, per-tenant third-party-sender Header-From rewriting) whose alignment is the load-bearing DMARC-verdict input the M365 EOP inbound dmarc=<result> evaluator records for the Workspace→M365 mail-flow leg — the message-layer authentication- verdict counterpart to the transport-layer TLS-policy attestation discipline THIS page documents; (iv) MTA-STS at the M365-tenant inbound side (this page) and SPF at the Workspace- tenant sender side (target page) are the COMPLEMENTARY transport- layer-vs-message-layer cross- cloud authentication-publication disciplines for the Workspace→ M365 mail-flow leg — THIS page documents the per-M365- tenant inbound TLS-enforcement publication ( _mta-sts + _smtp._tls TXT-record + HTTPS policy-host publication the Workspace sender consumes BEFORE the SMTP delivery handshake), while the SPF-for- Workspace spoke documents the per-Workspace-tenant SPF publication the M365 inbound EOP consumes AFTER the TLS handshake closes and the message-layer authentication-evaluation begins — together they document the FULL cross-cloud Workspace→M365 mail-flow-leg authentication- publication stack from per- Workspace-tenant SPF/DKIM/DMARC publication through per-M365- tenant MTA-STS/TLS-RPT publication. Read the SPF-for- Workspace spoke alongside this M365 MTA-STS deployment reference when auditing the cross-cloud Workspace→M365 mail-flow-leg authentication- evidence stack — the spoke documents the per-Workspace- tenant SPF-publication discipline every M365 EOP inbound spam- filter consumes for mail-from- Workspace-senders.
• include vs ip4 vs a vs mx — the PER-M365-TENANT-SPF-MECHANISM- CHOICE-AS-MESSAGE-LAYER-IP- AUTHENTICATION-PUBLICATION-COMPLEMENT- TO-PER-M365-TENANT-MTA-STS-TRANSPORT- LAYER-TLS-ENFORCEMENT-PUBLICATION companion to this M365-tenant MTA-STS deployment guide. Where THIS page documents the per-M365-tenant TRANSPORT- LAYER STARTTLS-enforcement publication discipline via the _mta-sts.<tenant>.<tld> TXT-record + HTTPS-served policy-file + per-MX TLS-validation pattern (RFC 8461), the include-vs-ip4-vs-a-vs-mx spoke is the PARALLEL MESSAGE-LAYER PUBLICATION DISCIPLINE companion documenting the four IP-providing SPF-mechanism-choice surface (RFC 7208 §5.2 include:, §5.6 ip4:, §5.3 a:, §5.4 mx:) every M365 tenant picks between when authoring the per- tenant SPF record that AUTHORISES outbound sender IPs in parallel with the per-M365-tenant MTA-STS record that ENFORCES inbound TLS at the per-MX cert- validation surface. The four-axis MTA- STS-PER-TENANT-VS-SPF-PER-MECHANISM comparison exposes the structurally- distinct cross-layer per-publisher publication-disciplines: (i) MTA-STS publishes a per-tenant HTTPS-served TLS-enforcement policy binding inbound-MX cert-validation to the publisher's HTTPS-policy-host; SPF publishes a per-publisher per-mechanism per-source-IP authorisation list binding OUTBOUND source-IP topology to the publisher's v=spf1 record — both are per-publisher per-domain publication-disciplines but at structurally-distinct layers (transport-layer TLS handshake enforcement vs message-layer envelope- MAIL-FROM IP authentication) whose combined output completes the per-tenant authentication-and-transport-security publication stack; (ii) MTA-STS protects INBOUND mail-flow at the receiver-side MX cert-validation surface (per-tenant operator publishes a TLS- enforcement contract every sender's MTA must honour); SPF protects OUTBOUND mail-flow authentication at the sender- side IP authorisation surface (per- tenant operator publishes a per-source- IP authorisation contract every receiver's MTA evaluates) — the include-vs-ip4-vs-a-vs-mx decision (M365 tenants typically pick include:spf.protection.outlook.com for the per-tenant EOP egress-IP-pool coverage, then add explicit ip4: for any on-prem-relay or 3rd-party sender topology, then chain via include: per ESP) is the OUTBOUND-AUTHENTICATION-PUBLICATION complement to the INBOUND-TRANSPORT- SECURITY-PUBLICATION this M365 MTA-STS page documents; (iii) the M365- tenant include:spf.protection.outlook.com cascade is THE textbook include:-mechanism use-case the four-way decision matrix documents — every M365 tenant consumes the per-tenant Microsoft- managed egress-IP-pool via include cascade rather than enumerating Microsoft's IP-pool with ip4: (which would require manual updates as Microsoft rotates outbound IPs); operators reading the include-vs-ip4-vs-a-vs-mx spoke find the canonical guidance for why include is the right mechanism choice for managed cloud-mailbox-provider deployments like the M365 tenant this MTA-STS page configures; (iv) the cross- layer per-tenant publication stack — MTA-STS at transport layer + SPF- mechanism-choice at message layer + per- selector DKIM at message layer + per- domain DMARC at policy layer + per- domain TLS-RPT at telemetry layer — produces a coherent per-tenant authentication-and-transport-security publication stack — the include-vs-ip4-vs-a-vs-mx spoke documents the per-tenant SPF-mechanism layer in this stack that the per-tenant MTA-STS layer this page documents structurally complements. Read the include-vs-ip4-vs- a-vs-mx spoke alongside this M365 MTA- STS deployment reference when architecting the full per-M365-tenant cross-layer publication stack — the spoke documents the per-tenant SPF mechanism-choice surface whose per-source-IP authorisation publication is the message-layer authentication complement to the per- tenant transport-layer TLS-enforcement publication this page documents.
• DKIM replay attacks — the PER-M365-TENANT-TRANSPORT-LAYER- TLS-ENFORCEMENT-AS-CROSS-LAYER- ORTHOGONAL-CONTROL-TO-PER-MESSAGE-DKIM- REPLAY-ATTACK-AT-MESSAGE-LAYER companion documenting how the per- M365-tenant MTA-STS transport-layer TLS-enforcement publication discipline THIS page documents the deployment workflow of is STRUCTURALLY ORTHOGONAL to the per-message DKIM-replay attack- class catalogued in the DKIM-replay- attacks spoke — meaning per-M365-tenant MTA-STS enforcement does NOT prevent the per-message DKIM-replay attack class even though both controls contribute to the per-M365-tenant cross-layer defence-in-depth publication stack. Where THIS page documents the per-M365-tenant MTA-STS deployment workflow (per-tenant _mta-sts.<tenant-domain> TXT-RR publication, per-tenant HTTPS- served policy at https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt, per-tenant v=STSv1; id=<policy-id> version-pointer publication, per- tenant mode: enforce vs mode: testing commitment gating, per-tenant mx:-pattern enumeration targeting the canonical <tenant>-com.mail.protection.outlook.com inbound-MX hostname pattern), the DKIM-replay-attacks spoke is the cross-layer-orthogonal per-message message-layer replay-attack-class reference at four per-M365-tenant cross-layer control-orthogonality coupling dimensions: (i) per- M365-tenant MTA-STS enforces TLS- channel-integrity at the per- connection layer-4 boundary but does NOT prevent message-layer-bytes capture-and-replay through legitimate TLS channels — the per-M365- tenant MTA-STS deployment this page documents the workflow of enforces the receiving-MX TLS-handshake- certificate-validation correctness per RFC 8461 §4.3, blocking opportunistic STARTTLS downgrade attacks and per- connection man-in-the-middle interception attempts; however, the per-M365-tenant MTA-STS publication does NOT interfere with the per- message-bytes capture-and-replay threat-class the DKIM-replay-attacks spoke documents — an attacker who captures per-message-bytes through a legitimate (TLS-valid) channel can replay those bytes through ANOTHER legitimate (TLS-valid) channel without violating any per-M365-tenant MTA-STS published policy; (ii) per-M365-tenant DKIM-signing infrastructure (Exchange Online managed selector1 / selector2 CNAME-rotation cadence) operates ORTHOGONALLY to per-M365-tenant MTA-STS publication discipline at distinct cross-layer boundaries — the per-M365- tenant Exchange Online managed DKIM- signing infrastructure operates at the per-message message-layer boundary, producing per-message DKIM- Signature headers signed at the per- M365-tenant per-selector d=<tenant-domain> signing identity; the per-M365-tenant MTA-STS publication this page documents operates at the per- connection transport-layer boundary, enforcing TLS-channel-integrity for the per-recipient receiving MX connection — neither boundary addresses the per-message-bytes replay threat-class the DKIM-replay- attacks spoke documents, making per-M365-tenant t=/ x=-tag DKIM-signature publication discipline the load- bearing per-message replay-mitigation primitive ORTHOGONAL TO the per- M365-tenant MTA-STS publication discipline THIS page documents; (iii) per-M365-tenant cross-layer defence-in-depth stack composes per- connection-TLS-enforcement + per-message-cryptographic-integrity + per-message-replay-resistance as STRUCTURALLY-DISTINCT controls — every per-M365-tenant per-domain cross-layer publication-discipline stack (SPF + DKIM + DMARC at message- layer + MTA-STS + TLS-RPT at transport-layer + per-message t=/x=-tag DKIM-signature replay-mitigation at message-layer + DANE at transport- layer-cryptographic-anchor) composes per-distinct-threat-class controls at per-distinct-cross-layer boundaries — the per-M365-tenant MTA-STS publication discipline this page documents is one cross-layer-distinct defence-control whose per-distinct- threat-class coverage explicitly excludes the per-message-replay threat-class the DKIM-replay-attacks spoke catalogues; (iv) per-M365- tenant per-message replay-attack- evidence via per-tenant rua-aggregate- XML stream as load-bearing per-M365- tenant per-message replay-attack- detection KPI ORTHOGONAL TO per- tenant TLS-RPT-JSON-failure-report transport-layer observability stream — the per-M365-tenant per-message replay-attack-cohort signature surfaces in the per-tenant rua-aggregate-XML stream as a per- source-IP DKIM-aligned-pass-rate distribution anomaly at per-source-IPs outside the per-M365-tenant per-domain authorised egress infrastructure; this per-tenant per-message replay- attack-detection KPI is STRUCTURALLY ORTHOGONAL TO the per-tenant TLS-RPT- JSON-failure-report stream this MTA- STS deployment page implicitly consumes for per-tenant transport- layer observability — the per-M365- tenant operator must scope per-message replay-attack detection in the per- tenant rua-aggregate-XML stream SEPARATELY from per-tenant transport- layer TLS-failure observability in the TLS-RPT stream. Read the DKIM- replay-attacks spoke alongside this M365 MTA-STS deployment reference when scoping the per-M365-tenant cross-layer defence-in-depth publication stack — the spoke documents the per-message message- layer replay-attack-class STRUCTURALLY ORTHOGONAL TO the per-connection transport-layer TLS-enforcement discipline this page documents, making the per-M365-tenant t=/x=-tag DKIM-signature publication discipline the load-bearing per-message replay- mitigation primitive operators must coordinate ALONGSIDE the per-M365- tenant MTA-STS publication discipline this page documents the workflow of.
• MX records explained — the M365-TENANT-PER-DOMAIN-MX-RR- PUBLICATION-AS-LOAD-BEARING-UPSTREAM- INVENTORY-LIST-INPUT-INTO-PER-DOMAIN- MTA-STS-POLICY-FILE-MX-DIRECTIVE-AUTHORING companion to this MTA-STS-for-Microsoft- 365 reference. Where THIS page documents the per-M365-tenant per-domain MTA-STS publication-discipline workflow (per- tenant per-domain mta-sts.<tenant- domain> HTTPS host + per-tenant per- domain mta-sts.txt policy-file with version: STSv1 / mode: enforce / max_age: 604800 / mx: <tenant- domain>.mail.protection.outlook.com + per-tenant per-domain _mta-sts.<tenant-domain> IN TXT "v=STSv1; id=<version-string>" publication discipline), the MX-records spoke is the canonical RFC 5321 §5.1 MX-RR primitive reference documenting the per-tenant per-domain receive-side- MX-inventory-list publication that ITSELF IS the load-bearing upstream input into the per-domain mta-sts.txt policy file's mx:-directive list authoring at four per-M365-tenant MX-to-MTA-STS- policy coupling dimensions: (i) per-tenant per-domain MX-RR- receive-side-hostname publication as load-bearing per-tenant per-domain mta-sts.txt mx:-directive authoritative-mirror requirement — the per-M365-tenant per-domain MX-RR publication (<tenant-domain> IN MX 0 <tenant-domain>.mail.protection.outlook.com) IS the receive-side-MX-hostname inventory every sender-side per-receiver MTA-STS- policy-fetch-and-cache workflow consults as the per-recipient-MX-host STARTTLS- cert-trust evaluation gate-keeping primitive; the per-tenant per-domain mta-sts.txt policy file's mx:- directive list MUST authoritatively mirror the per-tenant per-domain MX-RR inventory the MX-records spoke documents the publication-discipline workflow of; (ii) per-tenant per-domain MX-RR- inventory-rollover as load-bearing per- tenant per-domain mta-sts.txt id=-tag- version-bump-coordination trigger — every per-tenant per- domain MX-RR-inventory rollover (new per-tenant per-domain mail-routing target added to per-tenant MX-RR list during EOP-tier failover / multi-region active- active deployment) MUST coordinate a per-tenant per-domain mta-sts.txt mx:-directive list update + per-tenant per-domain _mta-sts.<tenant- domain> TXT-RR id=-tag version-bump to invalidate the per- sender per-recipient-MX-host MTA-STS- policy-cache; the per-tenant per-domain MX-RR-inventory rollover-discipline IS the load-bearing upstream input the MX-records spoke documents into the per-tenant per-domain mta-sts.txt publication-discipline this page documents; (iii) per-tenant per- domain MX-RR-vs-mta-sts.txt-mx:- directive divergence as load-bearing per- tenant per-domain MITM-and-StripTLS- defence-bypass surface — every per-tenant per-domain MX-RR-vs-mta-sts. txt-mx:-directive list divergence (per-tenant per-domain MX-RR rolls forward to new per-tenant per-domain mail-routing target but per- tenant per-domain mta-sts.txt mx:-directive list still lists the retired mail-routing target) produces a load-bearing per-recipient- MX-host STARTTLS-cert-trust-evaluation- bypass surface every per-sender MTA-STS- policy-enforcing workflow registers as a per-recipient-MX-host MITM-attack defence-bypass event the per-tenant per- domain TLS-RPT JSON failure-report- stream the M365-tenant per-domain observability framework consumes; (iv) per-tenant per-domain MX-RR- priority-list-ordering as load-bearing per-tenant per-domain mta-sts.txt mx:-directive list-ordering-coordination discipline — per-tenant per- domain MX-RR-priority-list ordering (per-tenant per-domain 0 <primary-mx> + per- tenant per-domain 10 <fallback- mx>) the MX-records spoke documents the per-RFC-5321 §5.1 per-priority-list per-MX-host fallback- order primitive of MUST authoritatively coordinate with the per-tenant per- domain mta-sts.txt mx:- directive list inclusion (primary + fallback per-MX-host each individually listed in mx:-directive list) the per-M365-tenant MTA-STS deployment discipline THIS page documents the per-tenant per-domain publication-workflow of. Read the MX-records spoke ALONGSIDE this MTA- STS-for-Microsoft-365 reference whenever a per-M365-tenant per-domain receive-side-MX-inventory-vs-MTA-STS- policy-file mx:-directive list publication-discipline-coordination question emerges — THIS page gives the per-M365-tenant per-domain MTA-STS publication-discipline workflow, the MX-records spoke gives the canonical per-tenant per-domain MX-RR-publication- and-inventory-rollover-discipline IT consumes as the load-bearing upstream receive-side-MX-inventory-list input.
• BIMI SVG Tiny PS logo requirements — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-BIMI-SVG-ASSET-HTTPS-DELIVERY- VS-MTA-STS-TLS-HANDSHAKE-PARALLEL companion to this M365 MTA-STS deployment reference. Where THIS page documents the per-M365-tenant per- custom-domain MTA-STS publication workflow whose per-tenant mta-sts.<custom-domain> policy file body's mx: allow-list specifies *.mail.protection.outlook.com as the per-tenant MX-receive-side endpoint exercising the per-tenant Exchange Online TLS-handshake at the STARTTLS layer, the BIMI SVG requirements spoke documents the STRUCTURALLY-PARALLEL per-M365-tenant per-custom-domain BIMI-SVG-asset HTTPS- delivery-leg consuming the SAME PUBLIC- CA-rooted TLS-handshake surface at FOUR per-M365-tenant per-custom-domain BIMI-SVG-asset-HTTPS-vs-MTA-STS-TLS- handshake coupling dimensions: (i) per-M365-tenant per-custom- domain BIMI SVG-asset HTTPS-serving endpoint cert-chain validity-discipline as structurally-parallel public-CA- rooted-TLS-handshake consumer of the same per-tenant CA-trust-anchor discipline the per-tenant *.mail.protection.outlook.com MTA-STS-MX-receive-side TLS-handshake consumes - the per-M365-tenant per-custom-domain SVG asset's HTTPS- serving endpoint cert-chain must validate against the public-CA root- store at the BIMI evaluator-side, with the per-tenant cert-renewal cadence coordinated alongside the per-tenant Exchange-Online MX-receive-side cert- renewal cadence the per-tenant MTA-STS publication discipline tracks; (ii) per-M365-tenant per- custom-domain BIMI SVG-asset HTTPS- serving endpoint CN/SAN-match discipline as structurally-parallel certificate-hostname-coverage discipline to the per-tenant MTA-STS policy file body mx:-allow-list certificate-hostname-coverage discipline - the per-tenant per-custom-domain default._bimi.<custom-domain> TXT-record l= URL host must match the certificate CN/SAN of the per-tenant per-custom-domain HTTPS- serving endpoint, structurally paralleling the per-tenant per-custom- domain *.mail.protection.outlook.com wildcard SAN matching the per-tenant MTA-STS policy file body mx:-allow-list MX-hostname pattern; (iii) per-M365-tenant per-custom-domain BIMI SVG-asset Tiny PS byte-format compliance as PUBLISHER- SIDE PRE-DELIVERY ACCEPTANCE GATE parallel to per-M365-tenant per- custom-domain MTA-STS policy file body Tiny-grammar publisher-side pre- publication acceptance gate - the per-tenant per-custom-domain operator must validate the SVG bytes conform to the Tiny PS profile (forbidden elements absent + ≤32 KiB + 1:1 aspect-ratio + viewBox 0-512) BEFORE the BIMI evaluator fetches it, structurally paralleling the per- tenant per-custom-domain MTA-STS policy file body grammar acceptance gate the per-tenant MTA-STS publication workflow requires; and (iv) per-M365-tenant per-custom- domain BIMI-SVG-asset HTTPS-endpoint reachability + DNS-resolution discipline as structurally-parallel operational-availability discipline to the per-tenant MTA-STS policy file endpoint https://mta-sts.<custom-domain>/.well-known/mta-sts.txt reachability + DNS-resolution discipline this M365 MTA-STS reference documents - the per-tenant per-custom-domain BIMI-asset HTTPS endpoint reachability discipline must be operationally maintained at per-tenant scale paralleling the per- tenant mta-sts.<custom-domain> policy-file-serving HTTPS endpoint reachability discipline. Pair THIS M365 MTA-STS deployment reference with the BIMI SVG requirements spoke when designing the per-M365-tenant per- custom-domain cross-protocol-pillar transport-layer publishing-discipline that fuses the per-tenant *.mail.protection.outlook.com MTA-STS-MX-receive-side TLS-handshake cert-discipline with the per-tenant per-custom-domain BIMI-SVG-asset HTTPS- serving-endpoint cert-discipline into the unified per-tenant per-custom- domain public-CA-rooted-transport- layer publication-readiness surface.
• DKIM cryptography basics — the per-M365-tenant per-custom-domain DKIM cryptographic primer (RFC 6376 plus RFC 8301 crypto-requirements update plus RFC 8463 Ed25519 alternative) covering the application-layer per-message cryptographic publication-discipline structurally parallel to MTA-STS's transport-layer TLS-cert publication-discipline THIS M365 deployment guide documents. Both per-tenant per-custom-domain layers depend on receiver-side public-key crypto verifying publisher-side cryptographic material — DKIM at the message-signing layer (per-message base64 RSA-2048 or Ed25519 signature over the SHA-256 hash of the canonicalised headers + body), MTA-STS at the TLS transport layer (HTTPS-served policy file plus STARTTLS-X.509-certificate-chain verification against the per-MX-host SAN per RFC 8461 §4.1). The per-M365-tenant per-custom-domain composite application-and-transport-layer cryptographic publication-discipline coordination requires both the per-tenant DKIM selector1._domainkey + selector2._domainkey publication discipline the DKIM-cryptography-basics primer documents AND the per-tenant MTA-STS policy-file + STARTTLS-cert publication discipline THIS M365 deployment guide documents at the cross-layer cryptographic publication coordination boundary.
• RFC 8461 — SMTP MTA Strict Transport Security — the canonical specification.
• RFC 8460 — SMTP TLS Reporting — the canonical TLS-RPT specification.
• Microsoft Learn: Mail flow best practices for Exchange Online — the Microsoft primary-source reference for Exchange Online mail-flow architecture and inbound MX configuration.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, ARC, and TLS results.
• Domain Security Checker — live DNS lookups for every email- authentication record on a domain. Surfaces the published MTA-STS, TLS-RPT, MX, SPF, DKIM, and DMARC records side by side.
• DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• BIMI Verified Mark Certificates (VMCs) explained — the PER-M365-TENANT-MTA-STS-WEB-PKI- FETCH-AS-STRUCTURAL-PARALLEL-TO-PER- PUBLISHER-BIMI-VMC-WEB-PKI-FETCH companion to this M365-tenant MTA-STS deployment reference. Where THIS page documents the per-M365-tenant MTA-STS deployment discipline (the per-tenant mta-sts.<tenant> HTTPS-policy-file publication, the per- tenant _mta-sts TXT publication, the per-tenant max_age: rotation cadence, the per-receiver MTA's HTTPS-fetch + Web-PKI trust-chain validation contract), the BIMI-VMC-explained spoke is the per-publisher Web-PKI certificate trust- chain reference documenting the per- publisher BIMI VMC HTTPS-fetched X.509- certificate trust-chain validation contract whose per-receiver-renderer fetch + trust- chain validation discipline mirrors the per-receiver MTA's per-publisher MTA-STS policy-file fetch + trust-chain validation discipline. The PER-M365-TENANT-MTA-STS- VS-BIMI-VMC-WEB-PKI-FETCH cross-reference establishes FOUR structurally-distinct per-publisher Web-PKI-fetch-discipline dimensions: (i) per-publisher HTTPS-fetched policy-or-certificate file publication infrastructure parallel — the per-publisher MTA-STS-policy-file is HTTPS-fetched at https://mta-sts.<tenant>/.well-known/mta-sts.txt with per-tenant TLS-certificate Web-PKI trust-chain validation; the per-publisher BIMI VMC is HTTPS-fetched at the per- publisher-published a=-tag URL with per-tenant TLS-certificate Web-PKI trust-chain validation — both per-publisher publication-infrastructure disciplines share the per-publisher HTTPS-endpoint availability requirement, the per-publisher Web-PKI trust-chain validity contract, and the per-publisher AutoSSL-equivalent renewal-cadence operational discipline; (ii) per-publisher Web-PKI trust- chain rotation-cadence coordination parallel — the per-publisher MTA-STS mta-sts.<tenant> TLS certificate rotation must be coordinated with per-receiver-MTA policy-cache invalidation; the per-publisher BIMI VMC certificate rotation must be coordinated with per-receiver-renderer cache invalidation — the per-publisher rotation-cadence operational coordination discipline is structurally-identical across both publication-channels and the per-publisher operations team coordinates both rotation cycles through the same per-tenant AutoSSL-equivalent automation pipeline; (iii) per-receiver MTA- STS-policy-fetch-failure-AND-BIMI-VMC- fetch-failure observability parallel — per-receiver MTA-STS-policy-fetch failures surface in per-receiver per-publisher per-day TLS-RPT JSON-aggregate as sts-policy-fetch-error; per-receiver BIMI-VMC-fetch failures surface in per-receiver per-publisher per-day BIMI-render-rate aggregate-feedback as per-publisher mark-suppression evidence — both per-publisher HTTPS-fetch-failure-modes are surfaced in per-receiver per-publisher per-day observability streams the per-tenant operations team uses to detect publication- infrastructure regression; the BIMI-VMC spoke documents the per-receiver-renderer per-publisher mark-suppression observability whose per-publisher-fetch-failure-class is structurally-identical to the per-receiver- MTA per-publisher MTA-STS-policy-fetch- failure-class THIS page documents; (iv) per-M365-tenant Microsoft-managed certificate-issuance-OR-customer-managed- VMC-issuance per-tenant administrative- boundary parallel — the per-M365-tenant MTA-STS HTTPS endpoint is hosted on per- tenant Microsoft-managed infrastructure with Microsoft-managed TLS certificate; the per-M365-tenant BIMI VMC is per-tenant- customer-owned and hosted on per-tenant- customer-managed infrastructure — the per-M365-tenant administrative-boundary discipline differs by publication-channel but both fetch-and-validate Web-PKI trust- chain validation contracts share the per- publisher Web-PKI trust-anchor model; the BIMI-VMC spoke documents the per-tenant customer-owned Web-PKI fetch-target publication boundary that complements the per-tenant Microsoft-managed Web-PKI fetch- target publication boundary THIS page documents. Read the BIMI-VMC-explained spoke alongside this M365-tenant MTA-STS deployment reference whenever the operator scopes a per-M365-tenant Web-PKI publication- infrastructure plan — both per-publisher Web-PKI fetch-and-validate disciplines share the per-tenant publisher-side HTTPS-endpoint publication-and-rotation operational coordination requirement at the per-receiver per-publisher trust-chain validation boundary.
• Email deliverability — the per-publisher per-domain DELIVERABILITY-ENGINEERING-OPERATIONAL companion to this per-M365-tenant MTA-STS deployment reference. Where THIS page documents the per-M365-tenant MTA-STS publication discipline (the per-tenant mta-sts.<tenant>/.well-known/mta-sts.txt HTTPS-fetched policy file with version: STSv1 / mode: enforce / mx: / max_age: directives, the per-tenant _mta-sts.<tenant> TXT-RR v=STSv1; id= policy- version-identifier publication, the per- tenant mode: testing → mode: enforce rollout progression), the email-deliverability spoke documents the per-publisher per- domain deliverability-engineering operational discipline whose per-receiver per-message TLS-enforcement contract the per-M365-tenant MTA-STS publication the per-publisher operates. The composition operates through the per- message TLS-enforcement-deliverability cascade: a per-M365-tenant MTA-STS publication regression (per-tenant HTTPS-endpoint outage, per-tenant TLS- certificate expiry, per-tenant policy- file byte-grammar drift, per-tenant max_age: shorter than the per-receiver-MTA recommended 86400- second baseline) DEGRADES the per- receiver-MTA's per-publisher per- message TLS-enforcement decision — per- receiver MTAs in mode: enforce operation REJECT per-message delivery attempts when the per-publisher per- domain MX certificate fails to match the per-publisher per-domain MTA-STS policy-file MX-list, producing per- message delivery failures the per- publisher per-domain operator observes as a deliverability-engineering regression. Read THIS page when AUTHORING the per-M365-tenant MTA-STS deployment discipline; read the email- deliverability spoke when UNDERSTANDING the per-publisher per-domain deliverability-engineering operational baseline whose per-receiver per-message TLS-enforcement contract the per-M365- tenant MTA-STS publication-discipline THIS page documents materially gates at the per-receiver-MTA per-publisher TLS-enforcement-boundary tier.
• DNS propagation — the per-M365-tenant DNS-PROPAGATION-TIMING companion to this per-M365-tenant MTA-STS deployment tutorial. Where THIS page documents the per-M365-tenant MTA-STS publication discipline — per-tenant per-custom-domain _mta-sts.<domain> TXT policy-version-pointer (RFC 8461 §3.1) publication, per-tenant per-custom-domain mta-sts.<domain> HTTPS policy-file publication path (RFC 8461 §3.2 byte-grammar), per-tenant per-custom- domain _smtp._tls.<domain> TLS-RPT TXT publication, the per-tenant deployment-discipline cookbook coordinating Exchange Online's per-tenant outbound-MTA STARTTLS-enforcement-contract with per-receiver-MTA per-publisher MTA- STS-policy-fetch behaviour — the DNS- propagation spoke documents the per- resolver per-TTL operational-timing layer whose propagation-delay determinism gates every per-tenant per-custom-domain MTA- STS-policy publication-change rollout. The composition operates through three per- M365-tenant per-custom-domain DNS- propagation-timing dependencies the MTA- STS deployment discipline materially relies on: (i) per-tenant per-custom- domain _mta-sts TXT policy-version-pointer TTL determines the per-receiver per-resolver propagation- delay between the operator's per-tenant per-custom-domain policy-version bump (testing → enforce transition, policy-file edit) and the per-receiver-MTA per-tenant per-custom-domain policy-version detection that triggers a fresh policy-file fetch; (ii) per-tenant per-custom-domain mta-sts.<domain> HTTPS endpoint's underlying A / AAAA record TTL determines the per-receiver per-resolver propagation-delay between the operator's per-tenant per-custom-domain policy- endpoint relocation (CDN migration, IP rotation) and the per-receiver-MTA per- tenant per-custom-domain policy-file-fetch target detection; (iii) per-tenant per- custom-domain DNS-publication-precedence ordering — per RFC 2181 §5 the authoritative-nameserver TTL bounds per-receiver per-resolver cache lifetime — determines whether a per-tenant per- custom-domain MTA-STS-policy edit that transitions from mode: testing to mode: enforce is safely observable across the per-receiver-MTA population BEFORE the per-tenant per-custom-domain Exchange Online outbound-MTA contractually depends on per-receiver-MTA enforcement. Read THIS page when DEPLOYING the per-M365-tenant MTA-STS publication discipline against a custom domain; read the DNS-propagation spoke when SEQUENCING the per-tenant per- custom-domain MTA-STS-policy-version rollout cadence against per-receiver-MTA per-resolver cache-lifetime windows whose propagation-delay determinism gates the per-tenant per-custom-domain enforcement- mode promotion safety boundary.
• DMARC attacker bypass techniques — the TRANSPORT-LAYER PER-RECEIVER-MTA PER-MESSAGE STARTTLS-DOWNGRADE-MITM-AS- APPLICATION-LAYER-DMARC-BYPASS-PRECONDITION threat-model companion to THIS page's per- M365-tenant MTA-STS publication discipline. Where THIS page documents the per-M365- tenant per-custom-domain MTA-STS policy- file publication discipline (the _mta-sts TXT record, the HTTPS-served policy file at https://mta-sts.tenant.example.com/.well-known/mta-sts.txt, the mode: enforce / mode: testing / mode: none transition cadence, and the per-MX-host validation envelope the per-receiver-MTA enforces against per- tenant outbound Exchange Online traffic), the DMARC-attacker-bypass spoke documents the per-attacker per-message STARTTLS- downgrade MITM attack surface a per-publisher per-domain MTA-STS publication gap exposes the per-publisher per-domain DMARC enforcement posture to. The MTA-STS-VS- ATTACKER-BYPASS cross-reference establishes the per-publisher per-domain TRANSPORT- LAYER-VS-APPLICATION-LAYER attack-bypass coupling: an active MITM attacker who can downgrade STARTTLS at the per-receiver-MTA SMTP-handshake boundary can capture per- message DKIM-signed payloads in cleartext, re-emit them with attacker-controlled From-header / Subject-header / body modifications, AND because the per-publisher per-domain SPF record published in DNS STILL authorises the per-attacker-side sending IP (if the attacker controls a per- receiver-side downstream-hop), the per- attacker re-emission can transit downstream receivers as a per-message DMARC-aligned- AND-DKIM-aligned payload despite the per- publisher per-domain DMARC enforcement posture. The per-M365-tenant MTA-STS publication discipline THIS page documents is the load-bearing transport-layer per- receiver-MTA STARTTLS-enforcement floor that CLOSES this transport-layer-MITM-as- application-layer-DMARC-bypass precondition. Read THIS page when DEPLOYING the per-M365- tenant MTA-STS publication discipline; read the DMARC-attacker-bypass spoke when MODELING the per-publisher per-domain application-layer DMARC-authentication bypass attack surface a per-publisher per- domain MTA-STS publication gap exposes the per-publisher per-domain DMARC enforcement posture to.
• DMARC policy rollout — the PER-M365-TENANT-MTA-STS-TESTING-TO- ENFORCE-PHASE-TRANSITION-CADENCE-AS- STRUCTURALLY-PARALLEL-TO-PER-PUBLISHER-PER- DOMAIN-DMARC-POLICY-MODE-RAMP-PROGRESSION companion to this M365-tenant MTA-STS deployment reference. Where THIS page documents the per-M365-tenant MTA-STS publication discipline at the protocol byte level (the per-tenant _mta-sts.<tenant-domain> TXT-RR v=STSv1; id=<token> publication, the per-tenant https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt HTTPS-policy-host-file publication, the per-tenant policy-mode transition none → testing → enforce phase cadence, the per-tenant per-policy-mode mx: *.mail.protection.outlook.com MX-cone enumeration, the per-tenant per-receiver-MTA STARTTLS-enforcement floor), the DMARC-policy-rollout spoke is the APPLICATION-LAYER-DMARC-POLICY-MODE- RAMP-AS-STRUCTURAL-PARALLEL companion documenting the per-publisher per-domain canonical DMARC policy-mode-ramp progression (p=none 30+ days monitoring → p=quarantine pct=10 7-14 days → pct=25 7-14 days → pct=50 7-14 days → pct=100 7-14 days → p=reject pct=100) whose multi-phase per-week-cohort ramp-cadence operationally parallels the per-M365- tenant MTA-STS testing-to-enforce phase- transition cadence THIS page documents. Four MTA-STS-vs-DMARC-rollout coupling dimensions matter at the per-M365-tenant per-publisher per-domain cross-protocol multi-phase-progression boundary: (i) per-policy-mode-phase observability — both the per-tenant MTA-STS testing mode AND the per-publisher per-domain DMARC p=none mode emit observability telemetry without altering receiver-side per-message disposition, producing per-publisher per-domain TLS-RPT JSON-aggregate-report rows AND per-publisher per-domain DMARC RUA aggregate-XML-report rows whose per-phase per-receiver per-day per-MX-IP forensic-evidence flow gates per-publisher per-domain progression to the per-policy-mode enforcement phase; (ii) per-policy-mode-phase enforcement- commitment — both the per-tenant MTA-STS enforce mode AND the per- publisher per-domain DMARC p=reject pct=100 mode commit per-receiver- MTA per-message receiver-side disposition-strict semantics, requiring per-publisher per-domain operational- readiness evidence before commitment — TLS-RPT JSON-aggregate-report success-rate floor for the MTA-STS leg, DMARC RUA aggregate-XML-report DKIM-and-SPF-aligned- pass-rate floor for the DMARC leg; (iii) per-policy-mode-phase rollback capability — both protocols maintain per-policy-mode rollback via per-tenant MTA-STS id=<token> version-pointer republication to a previous policy + per-tenant policy-mode downgrade to testing, AND per-publisher per-domain DMARC p=quarantine pct=N downward-pct-adjustment + per-publisher per-domain DMARC p=none downgrade as per-publisher per-domain per-phase rollback options when per- policy-mode enforcement causes per- receiver per-message false-positive deliverability degradation; (iv) per- policy-mode cross-protocol coordination — when a per-publisher per-M365-tenant deploys both protocols simultaneously, the per-tenant MTA-STS enforce-mode commitment SHOULD precede the per-publisher per- domain DMARC p=reject pct=100 commitment so per-receiver-MTA TLS- downgrade attacker-bypass is closed BEFORE per-publisher per-domain application-layer DMARC-enforcement-side spoofing-defence commits to the strict-disposition floor. Read THIS page when DEPLOYING the per- M365-tenant MTA-STS publication discipline; read the DMARC-policy-rollout spoke when AUTHORING the per-publisher per-domain DMARC policy-mode-ramp progression discipline whose per-publisher per-domain multi-phase enforcement-readiness cadence is the structurally-parallel application- layer companion to the per-M365-tenant MTA-STS testing-to-enforce phase-transition cadence THIS page documents.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) and SPF flattening — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-SPF-INCLUDE-CASCADE-AS-LOOKUP-BUDGET- EXHAUSTION-RISK companion to THIS per-M365- tenant per-custom-domain MTA-STS transport- layer publication-discipline reference. Where THIS page documents the per-M365- tenant per-custom-domain MTA-STS RFC 8461 transport-layer enforcement publication (per-M365-tenant per-custom-domain _mta-sts.<tenant>.<d- domain> TXT-RR + per-M365-tenant per-custom-domain https://mta-sts.<tenant>.<d- domain>/.well-known/mta-sts.txt HTTPS-served policy-file + per-M365-tenant per-custom-domain mx: *.mail.protection.outlook.com mode- enforce commitment + per-tenant max_age cache-window discipline + per- tenant testing-vs-enforce phase-transition cadence), the SPF-lookup-limit spoke is the PER-M365-TENANT-PER-CUSTOM-DOMAIN-ENVELOPE- MAIL-FROM-LAYER-PUBLICATION-DISCIPLINE companion at FOUR per-M365-tenant-SPF- publication-vs-MTA-STS-transport-layer coupling dimensions: (i) per-M365- tenant per-custom-domain include: spf.protection.outlook.com root- include cascade-depth budget consumption AS load-bearing per-M365-tenant SPF-permerror- risk-floor — the per-M365- tenant per-custom-domain SPF publication canonical root form v=spf1 include:spf.protection.outlook.com -all consumes per-M365-tenant approximately 3-5 of the RFC 7208 §4.6.4 10-DNS-lookup budget the SPF-lookup-limit spoke documents (one for the root include:spf.protection.outlook.com + recursively further for the per- tenant spfa.protection.outlook.com + spfb.protection.outlook.com + per-region per-shard sub-includes Microsoft adds-and-removes opaquely), leaving per-M365-tenant operators 5-7 of the 10-lookup budget for per-publisher per- third-party-SaaS-sender include: tails (per-publisher per-Salesforce-Pardot include:_spf.pardot.com, per- publisher per-Mailchimp include: spf.mandrillapp.com, per-publisher per-Marketo include:mktomail.com , per-publisher per-HubSpot include:_spf.hubspot.com, per- publisher per-Salesforce include: _spf.salesforce.com, per-publisher per-ZenDesk include:mail.zendesk.com ) BEFORE per-M365-tenant per-custom- domain SPF evaluation crosses the 10-lookup cap and produces per-publisher per-domain SPF permerror catastrophic-disposition; (ii) per-M365-tenant per-custom-domain SPF-permerror cascade AS per-publisher per- domain envelope-MAIL-FROM-layer failure- mode parallel to per-M365-tenant per- custom-domain MTA-STS mode-enforce connection-rejection transport-layer failure-mode — the per-M365- tenant per-custom-domain SPF permerror catastrophic-disposition the SPF-lookup- limit spoke documents (all per-receiver per-message envelope-MAIL-FROM authentication fails with SPF=permerror, cascading to per- publisher per-domain DMARC composite- verdict-fail per-publisher per-domain DMARC p=quarantine / p=reject disposition) IS the per-publisher per-domain envelope-MAIL- FROM-layer publication-failure-mode structurally-parallel to the per-M365- tenant per-custom-domain MTA-STS mode- enforce per-MX-host SMTP-connection- rejection transport-layer-publication- failure-mode THIS page documents; per-M365- tenant operators must reconcile BOTH publication-discipline pipelines at the per- publisher per-custom-domain composite- publication-failure-mode investigation boundary; (iii) per-M365-tenant per-custom-domain SPF-flattening pipeline AS per-publisher per-domain envelope-MAIL- FROM-layer remediation pipeline parallel to per-M365-tenant per-custom-domain MTA-STS policy-file refresh pipeline — the per-M365-tenant per-custom- domain SPF-flattening remediation pipeline the SPF-lookup-limit spoke documents (per- M365-tenant per-custom-domain include- cascade resolution to per-M365-tenant per- custom-domain ip4: / ip6: literal mechanisms via per-M365-tenant per-custom- domain daily cron-driven refresh, per-M365- tenant per-custom-domain subdomain- delegation to split per-M365-tenant per- mail-stream 10-lookup budget across per- M365-tenant per-subdomain SPF records) IS the per-publisher per-domain envelope-MAIL- FROM-layer publisher-side remediation pipeline structurally-parallel to the per- M365-tenant per-custom-domain MTA-STS /.well-known/mta-sts.txt policy-file refresh pipeline THIS page documents (per-M365-tenant per-custom- domain max_age cache-refresh-cycle discipline, per-M365-tenant per-custom- domain policy-version-bump cache-invalidation protocol); BOTH per-M365-tenant per-custom- domain remediation pipelines preempt catastrophic per-M365-tenant per-custom- domain authentication-and-transport- publication failures at the per-M365-tenant per-custom-domain operational-hygiene- discipline boundary; (iv) per-M365- tenant per-custom-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication- floor coordination AS load-bearing per-M365- tenant per-custom-domain operator-side unified-trust-signal-publication-discipline- floor — the per-M365-tenant per-custom-domain SPF-lookup-budget-audit discipline the SPF-lookup-limit spoke documents (per-M365-tenant per-custom- domain SPF-lookup-count monitoring, per- M365-tenant per-custom-domain include- cascade-depth-audit cadence, per-M365- tenant per-custom-domain ESP-include-list consolidation discipline) IS one load- bearing leg of the per-M365-tenant per- custom-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination posture the per-M365-tenant per-custom-domain MTA-STS publication discipline THIS page documents the transport-layer leg of; per-M365-tenant operators must publish BOTH per-M365-tenant per-custom-domain envelope-MAIL-FROM-layer SPF + per-M365-tenant per-custom-domain transport-layer MTA-STS publication coordinated at the per-M365-tenant per- custom-domain unified-trust-signal-floor publication-readiness boundary. Read THIS page when DEPLOYING the per-M365-tenant per-custom-domain MTA-STS transport-layer publication discipline; read the SPF- lookup-limit spoke when AUDITING the per- M365-tenant per-custom-domain SPF-include- cascade-depth budget against the RFC 7208 §4.6.4 10-DNS-lookup cap whose per-publisher per-domain envelope-MAIL-FROM-layer publication-discipline is the load-bearing sibling per-M365-tenant per-custom-domain authentication-publication discipline coordinated with the per-M365-tenant per- custom-domain MTA-STS transport-layer publication discipline THIS page documents.
• Email security & privacy glossary — the cross-protocol security-and- privacy threat-and-defense vocabulary registry consumed at four per-M365-tenant MTA-STS transport-layer vs cross-protocol threat-catalogue coupling dimensions.
• DKIM best practices
• DKIM key rotation
• DMARC records explained
• DKIM alignment with DMARC
• DKIM-Signature header explained
• DKIM failures explained
• DKIM troubleshooting — the per-publisher per-selector DKIM-verdict-class triage reference companion at four per-M365-tenant per-custom-domain MTA-STS-vs-DKIM-verdict-troubleshooting coupling dimensions: (i) per-M365-tenant per-custom-domain DKIM dual-selector selector1._domainkey.<tenant-domain> + selector2._domainkey.<tenant-domain> CNAME-delegation publication-discipline drift (stale CNAME-target pointing to retired EOP signing-infrastructure host, missing-CNAME publication during dual-selector overlap-rollover window) surfaces in per-receiver per-message dkim=permerror verdict-class per RFC 8601 §2.7.1 whose per-tenant per-custom-domain root-cause triage the DKIM-troubleshooting permerror symptom-flow documents at the per-receiver-side per-message DKIM-verdict-class triage-flow — structurally parallel to per-M365-tenant per-custom-domain MTA-STS sts-policy-fetch-error transport-layer publication-floor failure-class the page documents above; (ii) per-M365-tenant per-custom-domain EOP Safe-Links rewriting + disclaimer injection breaking per-message body-hash post-signing surfaces as per-receiver per-message dkim=fail-body-hash-mismatch verdict-class whose per-tenant per-custom-domain message-modification root-cause triage the DKIM-troubleshooting body-hash-mismatch symptom-flow documents the per-symptom-class triage-procedure of — structurally parallel transport-layer per-tenant per-custom-domain MTA-STS sts-webpki-invalid post-publication cryptographic-integrity-regression failure-class the page documents above; (iii) per-M365-tenant per-custom-domain DKIM-Signature d=<tenant-onmicrosoft-com> default-fallback signing-identity (without per-tenant per-custom-domain CNAME-delegated DKIM publication) surfaces as per-receiver per-message dkim=pass-but-DMARC-fail verdict-class per RFC 7489 §3.1.1 alignment-evaluator whose per-tenant per-custom-domain CNAME-delegation publication-discipline gap the DKIM-troubleshooting pass-DMARC-fail symptom-flow documents the per-tenant per-custom-domain alignment-evaluator triage-procedure of — structurally parallel application-layer per-tenant per-custom-domain DKIM-alignment-evaluator triage to per-tenant per-custom-domain MTA-STS-mode:enforce-with-mx-host-allowlist alignment-publication-discipline this page documents at the transport layer; (iv) per-M365-tenant per-custom-domain Rotate-DkimSigningConfig dual-selector overlap-rollover publication-window discipline (parallel to per-tenant per-custom-domain MTA-STS policy-file id: rotation-cadence publication-discipline this page documents at the transport layer) requires per-receiver per-message DKIM-verdict-class evidence-driven readiness validation across the rotation window — surfaces in per-receiver per-day per-source-IP / per-message dkim=pass-rate floor preservation evidence the DKIM-troubleshooting decision-matrix documents the per-verdict-class per-rotation-window readiness-validation triage-procedure of — structurally parallel transport-layer rotation-window readiness-validation discipline to per-tenant per-custom-domain MTA-STS policy-publication rotation discipline THIS page documents at the cross-layer per-M365-tenant per-custom-domain composite application-and-transport-layer per-rotation-window readiness-validation coordination boundary — together the per-M365-tenant per-custom-domain MTA-STS transport-layer publication-discipline THIS page documents AND the per-publisher per-selector DKIM-verdict-class troubleshooting decision-tree the DKIM-troubleshooting spoke documents compose the per-M365-tenant per-custom-domain composite cross-layer publication-discipline-and-verdict-class-triage coordination floor.
• SPF DNS record syntax
• DMARC reporting pipeline — the end-to-end ingestion architecture that parses, aggregates, and stores the report streams this M365 MTA-STS deployment generates. The same operator-owned pipeline that ingests DMARC aggregate (RUA) and forensic (RUF) reports also ingests the TLS-RPT JSON reports a per-tenant MTA-STS enforce-mode policy produces: policy-type: sts records with result-type: starttls-not-supported / certificate-expired / sts-policy-fetch-error failure rows per RFC 8460 §4. Reading the reporting-pipeline spoke shows how the TLS-RPT telemetry surfaced by THIS page's rua=-equivalent rua: mailto:tlsrpt@<tenant-domain> TLS-RPT mailbox is normalized into the same per-source-IP per-day aggregation the DMARC aggregate pipeline applies, so transport-layer enforcement failures and application-layer auth failures are investigated through one unified ingestion path.
• DMARC policy modes — the application-layer enforcement ladder that runs in parallel with the transport-layer enforcement MTA-STS provides for a Microsoft 365 tenant. MTA-STS moves SMTP delivery from opportunistic to enforced TLS; DMARC policy modes move message authentication from p=none observation through p=quarantine to p=reject. Both are staged, evidence-driven ramps a tenant operator runs for the same domain — read this spoke for the DMARC-side progression.
• SPF qualifiers explained — MTA-STS secures the transport channel to your M365 tenant, but the envelope-layer SPF verdict still hinges on the ~all vs -all qualifier you publish; read the qualifier reference so the tenant's published SPF record hard-fails forged senders rather than softfailing them, the message-layer complement to the transport-layer policy this page deploys.
• DKIM DNS record syntax — an M365 tenant publishes DKIM as selector1/selector2 CNAMEs that ultimately resolve to the <selector>._domainkey TXT-RR key record; read the DKIM DNS syntax reference for the v=DKIM1; k=rsa; p=<base64-pubkey> format those CNAMEs point at, the message-signing companion to the transport-layer MTA-STS policy this page deploys.
• Business email compromise (the message-layer fraud the transport layer alone cannot stop) — the MTA-STS policy THIS page deploys hardens the transport channel so mail to your M365 tenant cannot be silently downgraded or MITM'd; BEC is a different threat layer entirely — CEO-impersonation wire-transfer requests and vendor-invoice redirection that ride a forged or look-alike sender identity, which a perfectly enforced STARTTLS does nothing to authenticate. Read it to see why MTA-STS is one leg of defence-in-depth that only closes the spoofing route when paired with an enforced SPF/DKIM/DMARC p=reject posture on the message layer.
• Microsoft SNDS + JMRP monitoring — the consumer-network half of the Microsoft story: authentication can be perfect and Outlook.com/Hotmail will still junk-folder mail from an IP with a degraded SNDS filter verdict; SNDS grades every sending IP GREEN/YELLOW/RED and JMRP streams each Junk click back as an ARF complaint report.

Verify MTA-STS on your Microsoft 365 tenant now

DMARC Analyzer ingests TLS-RPT JSON reports sent to your rua= mailbox at _smtp._tls.<your-domain> via includes/TlsRptParser.php and surfaces per-sender policy-fetch success, certificate-validation outcomes, and STARTTLS handshake breakdown — catching sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, and certificate-host-mismatch within hours of the first failure. Live DNS verification for the _mta-sts and _smtp._tls records runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual TLS handshake failures by parsing the Received: ... (using TLSv1.3 ...) stack via includes/EmailHeaderParser.php.

Sign up — Free plan Check my Microsoft 365 MTA-STS setup