DMARC Analyzer

TL;DR

• Google Workspace MTA-STS is operator-driven at the DNS and external HTTPS layers — there is no Admin Console panel, no gcloud cmdlet, no Postmaster Tools pane. Configuration lives entirely outside the Google 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> (Workspace 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 Workspace tenant on the legacy five-target MX config this is aspmx.l.google.com plus alt1.aspmx.l.google.com through alt4.aspmx.l.google.com (five lines in the policy file). For tenants migrated to the simplified MX configuration this is a single smtp.google.com entry.
• External HTTPS hosting is mandatory for the policy file. Workspace-aligned hosts: Google Cloud Storage + Cloud CDN (with Cloud Load Balancing for HTTPS), Cloud Run (free tier, autoprovisions HTTPS), Firebase Hosting (free tier, instant custom-domain HTTPS via Let's Encrypt), 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 — Google caps the honored cache lifetime at 604800 regardless of higher values you publish).
• Gmail is BOTH a recipient (with Workspace inbound MX) AND a sender (honoring MTA-STS on outbound TLS sessions since 2018). As a recipient, Workspace provides the MX endpoint you enumerate in the mx: directive. As a sender, Gmail 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 Google Workspace 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 Google Workspace / Gmail-for-business tenants. Sibling pages cover the protocol primer (MTA-STS explained), the byte-level policy-file reference (MTA-STS policy file syntax), the MTA-STS-vs-DANE decision view (MTA-STS vs DANE for SMTP), and the M365 counterpart (MTA-STS for Microsoft 365). THIS page is the Workspace-specific operator reference: the aspmx.l.google.com / alt1-4 MX-enumeration in the mx: directive, the mandatory external HTTPS hosting for the mta-sts.<your-domain> subdomain (Workspace does NOT serve the policy file natively), the absence of any Admin Console MTA-STS configuration UI, the TLS-RPT pairing for monitoring, and Gmail's role as an MTA-STS-honoring sender since 2018.

The page is anchored against current Google Workspace deployment realities: Workspace tenants receive mail via the five aspmx.l.google.com / alt1-4.aspmx.l.google.com MX targets (or the simplified smtp.google.com single-target config for newer tenants), Gmail honors recipient MTA-STS policies when sending outbound mail (from 2018 onward — Google was one of the earliest sender-side implementers), and the Admin Console 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 Google Workspace MTA-STS deployment works

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

1. Configuration lives entirely outside the Workspace admin surface

Unlike DKIM (configured in the Admin Console at Apps > Google Workspace > Gmail > Authenticate email) and SPF (verified via DMARC alignment monitoring in Postmaster Tools), MTA-STS has NO Google administrative interface. There is no gcloud workspace mta-sts command, no Admin Console toggle, no Postmaster Tools panel. Configuration is purely DNS (the _mta-sts TXT record at your authoritative nameserver) plus external HTTPS (the policy file served at a non-Google web host, or a Google Cloud host outside the Workspace tenant boundary).

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

Google Workspace supplies the inbound MX targets that operators enumerate in the policy file mx: directive. For a standard tenant on the legacy MX configuration, these are five targets: aspmx.l.google.com (priority 1), alt1.aspmx.l.google.com and alt2.aspmx.l.google.com (priority 5), and alt3.aspmx.l.google.com and alt4.aspmx.l.google.com (priority 10). Tenants migrated to the simplified MX configuration see a single smtp.google.com target (priority 1). Google does NOT host the policy file itself — Gmail is a mail platform, not a web platform. Operators must spin up a separate HTTPS host for the mta-sts.<your-domain> subdomain.

3. Gmail is also an MTA-STS-honoring sender

Gmail's outbound mail platform has honored recipient MTA-STS policies since 2018. When delivering mail to a recipient domain that has published an MTA-STS policy in mode: enforce, Gmail fetches the policy, caches it for up to 604800 seconds (one week — Google's published cap, regardless of higher max_age values the policy advertises), 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 Workspace tenants. The dual role (Workspace as both recipient and sender) means every Workspace 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 Google Workspace tenant with at least one custom accepted domain (the domain you want to protect with MTA-STS). Verify with the Admin Console at admin.google.com > Domains > Manage domains.
• 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 (Google Cloud Storage + Cloud CDN, Cloud Run, Firebase Hosting, 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 Workspace 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 Google Workspace and SPF for Google Workspace. MTA-STS protects the transport layer; DMARC and SPF protect the authentication layer. All three together form the canonical Workspace 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:

$ dig +short TXT _mta-sts.example.com
"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 (Gmail caps that at 604800 seconds — one week).

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

Google Workspace 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, Google Trust Services, 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 a Workspace tenant

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

1. Firebase Hosting (free tier, instant custom-domain HTTPS via Let's Encrypt — managed by Firebase automatically). The lowest-friction Workspace-aligned option: deploy a single static file with firebase deploy and the endpoint comes up in minutes.
2. Cloud Run (free tier, autoprovisions HTTPS via Google Trust Services). Suitable for tenants already using Cloud Run for other workloads; deploy a minimal container serving the static policy file.
3. Google Cloud Storage + Cloud CDN (Workspace-tier hosting, requires Cloud Load Balancing for custom-hostname HTTPS). Common for tenants with existing GCP infrastructure; certificate provisioning via Google-managed certificates on the load balancer.
4. 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).
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. AWS S3 + CloudFront (low cost, certificate via ACM). Common for organizations with existing AWS infrastructure.
7. Netlify or Vercel (free tier, zero-config HTTPS).
8. 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: Firebase Hosting (firebaseapp.com / web.app target)
mta-sts.example.com.  IN  CNAME  example-mta-sts.web.app.

; Example: Cloud Run service
mta-sts.example.com.  IN  CNAME  ghs.googlehosted.com.

; 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: 148
version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.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: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.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 a Workspace tenant on the legacy MX configuration, this is five lines: aspmx.l.google.com plus alt1.aspmx.l.google.com through alt4.aspmx.l.google.com. For the simplified MX configuration, this is a single smtp.google.com line — see the next section. Single-label wildcards (*.l.google.com) match exactly one label and are valid per RFC 8461 §3.2; multi-label wildcards are not supported.

max_age:

Cache lifetime in seconds. 86400 (24h) is typical for initial testing-mode publication; 604800 (7 days) for stable enforce-mode policies. Google caps the cache lifetime it honors at 604800 regardless of higher values published, so anything beyond one week is effectively no-op for Gmail-as-sender. 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 Workspace tenant at example.com in initial testing-mode burn-in (legacy five-target MX config):

version: STSv1
mode: testing
mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com
max_age: 86400

Worked example for a Workspace tenant on the simplified MX configuration:

version: STSv1
mode: testing
mx: smtp.google.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: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.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 Workspace tenant (legacy five-target MX)

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

$ dig +short MX example.com
1 aspmx.l.google.com.
5 alt1.aspmx.l.google.com.
5 alt2.aspmx.l.google.com.
10 alt3.aspmx.l.google.com.
10 alt4.aspmx.l.google.com.

The legacy MX configuration uses five targets at three priority levels (1 / 5 / 10). Enumerate all five in the policy file mx: directive:

mx: aspmx.l.google.com
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: alt3.aspmx.l.google.com
mx: alt4.aspmx.l.google.com

Single-label wildcards are also accepted by RFC 8461 §3.2 — a single *.l.google.com entry matches all five canonical MX targets and is a valid (though less explicit) alternative:

mx: *.l.google.com

Operators choosing the wildcard form should document that choice prominently — explicit enumeration of the five canonical hostnames is easier to audit when reviewing the policy against future MX configuration changes.

Workspace tenant on the simplified MX configuration

Newer Workspace tenants migrated to the simplified MX configuration see a single target:

$ dig +short MX example.com
1 smtp.google.com.

mx: smtp.google.com

The simplified configuration is functionally equivalent — Google's infrastructure routes the single smtp.google.com hostname to the same backend inbound infrastructure as the legacy five-target shape. The MTA-STS policy must match whatever shape the DNS MX records actually publish; if your tenant migrates from legacy to simplified, update the policy file BEFORE swapping MX records or cached policies will reject the new MX target.

Third-party security gateway in front of Workspace

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

$ 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 Workspace endpoint internally — that hop is not visible to external MTA-STS-honoring senders, so the aspmx.l.google.com hostnames 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 Workspace 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 Google Workspace

The simplest setup uses a dedicated mailbox on the Workspace 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. Postmaster Tools (postmaster.google.com) surfaces aggregate DMARC posture but does NOT ingest or display TLS-RPT reports — the reports flow directly to the rua= mailbox or webhook the operator publishes.

Testing-mode burn-in workflow

The canonical testing-to-enforce migration discipline for a Workspace tenant:

1. Week 0. Publish the _mta-sts TXT record, stand up HTTPS hosting (Firebase Hosting or Cloud Run is the lowest-friction path for Workspace tenants), 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 Workspace (other tenants), Microsoft 365, 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 — Google's enforced cap). Bump the id= value in the _mta-sts TXT record.
5. Week 4+. With enforce mode stable, Workspace tenants typically leave max_age at 604800 — higher values are silently capped at 604800 by Gmail-as-sender, so anything beyond one week is no-op for the dominant sender. Bump id= on every future policy edit.
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 Google Workspace MTA-STS mistakes

1. Assuming Google hosts the policy file. Gmail is a mail platform, not a web platform. Google Workspace does NOT serve content at mta-sts.<your-domain>; operators must spin up an external HTTPS host (Firebase Hosting and Cloud Run are the lowest-friction Workspace-aligned options). The single most common "where do I start" confusion.
2. Looking for an MTA-STS panel in the Admin Console. There is none. MTA-STS configuration is entirely DNS + external HTTPS, outside the Google administrative surface. No gcloud command, no Postmaster Tools pane, no Admin Console toggle.
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. Listing only aspmx.l.google.com without the alt1-4 siblings. On the legacy MX configuration, Workspace inbound mail can land at any of the five MX targets (aspmx + alt1-4) depending on routing health. Listing only the priority-1 host in mx: causes mail to bounce when senders attempt delivery to alt1-4 under enforcement. Enumerate all five, or use the *.l.google.com wildcard.
6. 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.
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. Setting max_age higher than 604800 expecting Gmail to honor it. Gmail-as-sender caps the cache lifetime it honors at 604800 (one week) regardless of higher values the policy advertises. Operators who publish max_age: 2592000 (30 days) expecting longer cache pinning from Gmail see the same one-week cache in practice. Other senders may honor longer windows; Gmail will not.

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 / Google Trust Services 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 (Firebase Hosting and Cloud Run autoprovision; Cloud Storage + Cloud CDN requires explicit Google-managed certificate setup on the load balancer).
• 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. For the legacy Workspace MX configuration that means five lines (aspmx.l.google.com plus alt1.aspmx.l.google.com through alt4.aspmx.l.google.com); for simplified that means a single smtp.google.com. 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 Google Workspace?

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> (Google Workspace does NOT host the policy file — typical hosts are Google Cloud Storage + Cloud CDN, Cloud Run, Firebase Hosting, Cloudflare Pages, GitHub 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 Workspace tenants this is typically aspmx.l.google.com plus alt1-4.aspmx.l.google.com — five MX entries in total for the standard inbound MX set), 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. Google Workspace has NO Admin Console MTA-STS panel — all configuration is DNS + external HTTPS.

What MX hosts should I list in my Google Workspace MTA-STS policy?

The exact MX hostname(s) Google published for your tenant's accepted domains. Run dig +short MX <your-domain> to see the canonical values. For a standard Workspace tenant with no third-party security gateway, you will see five MX targets: 1 aspmx.l.google.com., 5 alt1.aspmx.l.google.com., 5 alt2.aspmx.l.google.com., 10 alt3.aspmx.l.google.com., 10 alt4.aspmx.l.google.com. — all five must appear in the mx: directive of your MTA-STS policy file (each on its own line). Workspace tenants migrated to the newer simplified MX configuration see a single target: 1 smtp.google.com. — in that case enumerate only smtp.google.com. For multi-domain Workspace tenants, each accepted domain needs its own MTA-STS policy with its own mx: list — the policies do NOT inherit across the tenant. For tenants behind a third-party security gateway (Mimecast, Proofpoint, Barracuda, FortiMail), list the gateway MX hostnames instead. 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 Google Workspace tenant?

Anywhere that can serve a static text file over HTTPS with a publicly-trusted certificate matching mta-sts.<your-domain>. Google Workspace does NOT host the file natively — Gmail is a mail platform, not a web platform; there is no Drive / Sites / Admin Console route to publish a /.well-known/mta-sts.txt file on the mta-sts subdomain. Operators commonly use: (a) Google Cloud Storage with Cloud CDN (Workspace-aligned, supports custom-hostname HTTPS via Cloud Load Balancing), (b) Cloud Run (free tier, autoprovisions HTTPS), (c) Firebase Hosting (free tier, instant custom-domain HTTPS via Let's Encrypt), (d) Cloudflare Pages or Cloudflare Workers (free tier, supports custom-hostname HTTPS), (e) GitHub Pages with a custom domain (auto-HTTPS via Let's Encrypt, free for public repositories), (f) AWS S3 with CloudFront for the certificate front-end, (g) Netlify or Vercel static hosting, (h) 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 a Workspace 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). Google Workspace 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. Firebase Hosting and Cloud Run autoprovision certificates via Let's Encrypt; Google Cloud Storage + Cloud CDN requires explicit certificate provisioning via Cloud Load Balancing.

Does Google Workspace honor MTA-STS policies when sending mail outbound (does Gmail enforce MTA-STS as a sender)?

Yes. Gmail (the Workspace outbound platform) has acted as an MTA-STS-honoring SENDER since 2018: 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), Gmail (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 Google Workspace receive MTA-STS-enforced delivery from any sender whose outbound system honors MTA-STS (Google Workspace, Microsoft 365, Yahoo, ProtonMail, and most modern commercial MTAs). Google was an early implementer of the sender side; current Workspace tenants honor recipient MTA-STS by default with no operator configuration. Gmail caps max_age it honors at 604800 (one week) per public documentation — policies advertising a longer max_age are honored only for the first 604800 seconds.

How do I verify my Google Workspace 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 aspmx.l.google.com plus alt1-4.aspmx.l.google.com for a standard Workspace tenant (or smtp.google.com for the simplified config). (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 Google Workspace Admin Console to configure MTA-STS?

No. The Google Workspace Admin Console (admin.google.com) has panels for DKIM (Apps > Google Workspace > Gmail > Authenticate email), DMARC (the Postmaster Tools dashboard at postmaster.google.com surfaces DMARC posture, but DMARC records are published at the operator's DNS), and SPF (no panel — published purely at DNS), 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. Google Workspace (the recipient platform) provides MX hosts (aspmx.l.google.com plus alt1-4) that operators enumerate in their policy mx: directive, but Google does NOT publish the DNS record or host the policy file on the operator's behalf. All MTA-STS configuration for a Workspace tenant is operator-driven at the DNS and HTTPS layers — there is no gcloud command (no gcloud workspace mta-sts), no Admin Console toggle, no Postmaster Tools panel. The pragmatic workflow: publish the DNS record at your authoritative nameserver, stand up an HTTPS host for the policy file (Cloud Run / Firebase Hosting are the Workspace-aligned choices), observe via TLS-RPT — all entirely outside the Google 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.
• 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 Microsoft 365 — the M365 counterpart to this guide. Side-by-side comparison spoke covering the protection.outlook.com MX enumeration, the Azure / Cloudflare Pages / GitHub Pages hosting options, the absence of any Defender-portal MTA-STS panel, and the testing-to-enforce burn-in workflow for Exchange Online tenants.
• 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 Google Workspace — the broader DMARC rollout for Workspace tenants. MTA-STS and DMARC protect different layers (transport vs authentication); deploy both for end-to-end protection.
• DMARC for SaaS senders — the WORKSPACE-MTA-STS-INBOUND-DEFENSE- AGAINST-SAAS-PLATFORM-SHARED-POOL-IP companion to this Workspace MTA-STS deployment guide. Where THIS page documents the per-Workspace-tenant _mta-sts.<domain> TXT-record + mta-sts.<domain> HTTPS-policy-host publication workflow for Gmail tenants, the SaaS-senders spoke is the MULTI-TENANT-PLATFORM- SHARED-POOL-IP-INBOUND-TRANSPORT-LAYER- CROSS-TENANCY-COORDINATION REFERENCE documenting FOUR Workspace-MTA-STS-vs- SaaS-platform cross-tenancy coordination dimensions any operator running BOTH a Workspace tenant AND outbound mail delegated to a SaaS multi-tenant platform must coordinate: (i) Workspace inbound MTA-STS policy publication closes the SaaS-platform shared-pool-IP spoofed inbound delivery surface — the Workspace tenant's MTA-STS policy enforces STARTTLS-encrypted delivery to the canonical Gmail MX hostname glob list (ASPMX.L.GOOGLE.COM + ALT1.ASPMX.L.GOOGLE.COM + ALT2.ASPMX.L.GOOGLE.COM + ALT3.ASPMX.L.GOOGLE.COM + ALT4.ASPMX.L.GOOGLE.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- Workspace-tenant testing→enforce mode- progression coordination with the SaaS-platform outbound delivery observability — operators running BOTH a Workspace 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 Workspace tenant's enforce-mode policy when delivering customer-marketing mail back to the Workspace tenant's own employees; (iii) per-tenant TLS-RPT _smtp._tls.<domain> JSON-aggregate ingestion as cross- tenancy transport-layer observability primitive — the Workspace 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 Workspace-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 Workspace MTA-STS deployment guide (the per-Workspace-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 a Workspace tenant AND outbound mail delegated to a SaaS multi-tenant platform.
• SPF for Google Workspace — the SPF operator reference. SPF + DKIM together are the alignment prerequisite for DMARC enforcement; MTA-STS is the orthogonal transport- encryption layer.
• DKIM for Google Workspace — the DKIM operator reference for Workspace: the single-selector TXT-publication model, the Admin Console workflow, operator-controlled 2048-bit key generation, and manual rotation cadence.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-SIGNED-OUTBOUND- TO-WORKSPACE-MTA-STS-RECEIVE-BOUNDARY cross-provider companion to this Workspace MTA-STS deployment pillar. Where THIS page documents the Workspace- tenant-published MTA-STS policy (the https://mta-sts.<workspace- domain>/.well-known/mta-sts.txt policy file with mx: aspmx.l.google.com + 4-alt-tier entries, 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 Workspace inbound MX, the TLS-RPT feedback-loop for per-MX-host failure attribution) — i.e. the WORKSPACE- RECEIVE-SIDE-TRANSPORT-LAYER-MTA-STS side of cross-provider mail delivery — the M365-DKIM spoke is the M365- TENANT-DKIM-SIGNED-SENDER-SIDE companion documenting the M365-tenant- specific DKIM deployment topology whose cryptographically-valid DKIM-Signature header travels across the cross-provider delivery boundary the Workspace MTA- STS policy bounds at the transport layer. Concretely, the spoke documents FOUR M365-DKIM-to-Workspace-MTA-STS- cross-provider-coordination dimensions: (i) M365-tenant-Exchange-Online- outbound-connector-delivered DKIM-signed mail to Workspace-hosted recipient domains traverses the Workspace-tenant- published MTA-STS enforce-mode policy at the SMTP session boundary — the M365-tenant DKIM-Signature header the spoke documents ( d=<m365-tenant-domain>; s=selector1|selector2; h=From:To:Subject:Date; b=<rsa-signature>) travels within the SMTP DATA phase that STRUCTURALLY follows the cross-provider STARTTLS negotiation the Workspace MTA- STS spoke documents — the M365-tenant- DKIM-signing-identity is STRUCTURALLY ORTHOGONAL to the Workspace-receiver- side MTA-STS STARTTLS-enforcement verdict that runs at the transport layer BEFORE the SMTP DATA phase carries the M365-DKIM-Signature header body across the cross-provider boundary; (ii) M365-tenant- Exchange-Online-sending-MTA performs MTA-STS policy-cache lookup at the Workspace-receiving-domain boundary BEFORE opening the SMTP DATA phase carrying the M365-DKIM-signed message — the M365-tenant Exchange Online sending MTA fetches the Workspace operator's https://mta-sts.<workspace- 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 M365-DKIM- signed message body crosses the cross-provider boundary — making the M365-DKIM-signing-cadence the spoke documents structurally INDEPENDENT of the Workspace-MTA-STS-policy-cache rollover cadence THIS page documents; (iii) M365-tenant-Exchange- Online-outbound mail to Workspace recipients is envelope-encrypted by Workspace-receiver-side MTA-STS- enforced-STARTTLS at the transport layer but the M365-DKIM-signature is APPLICATION-LAYER ORTHOGONAL to the transport-layer encryption envelope — the Workspace MTA-STS policy this page documents binds the SMTP session to enforced TLS at the transport layer, and the M365-DKIM-Signature header the spoke documents authenticates the message- body integrity at the application layer — both contracts cooperate on cross-provider delivery from M365 to Workspace but operate at structurally- distinct protocol layers; and (iv) cross-provider M365-to- Workspace TLS-RPT failure correlation requires per-Workspace-MX-host failure attribution coordinated with per-M365-tenant DKIM-failure aggregation across the cross-provider boundary — when a Workspace- receive-side MTA-STS-enforce-mode STARTTLS failure event surfaces in the Workspace TLS-RPT report stream for the M365-tenant-outbound cohort, the M365-tenant operator's TLS-RPT- report-stream coordination contract with the Workspace operator's per-MX- host failure attribution discipline the spoke documents is the load- bearing cross-provider observability primitive — both M365-tenant-side and Workspace-tenant-side reporting streams correlate to attribute the cross-provider delivery failure to the M365-DKIM-signed-outbound mail cohort traversing the Workspace MTA- STS enforce-mode policy boundary. Read the DKIM-for-Microsoft-365 spoke alongside this Workspace MTA-STS deployment pillar when planning cross- provider M365-to-Workspace outbound DKIM-signed mail delivery — the M365- tenant-specific dual-selector CNAME- delegated 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 Workspace 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 — Certification Authority Authorization (RFC 8659). The MTA-STS policy file is fetched by sending MTAs over HTTPS at https://mta-sts.<domain>/.well-known/mta-sts.txt using the WebPKI trust store (RFC 8461 §3.3 explicitly requires publicly-trusted CAs and rejects self-signed certificates). The TLS certificate for mta-sts.<domain> must therefore be issued by a CA that the domain's CAA record authorises via an issue directive. For Workspace tenants who delegate the mta-sts hostname via CNAME to a Google-hosted endpoint, the CAA record at the apex must explicitly permit Google Trust Services (issue "pki.goog") — or omit CAA entirely — for the cert provisioning and ongoing renewal to succeed. Tenants using Cloudflare Pages, GitHub Pages, or Azure Static Web Apps to host the policy file must similarly authorise those providers' CAs (Let's Encrypt / ISRG, Google Trust Services, DigiCert) depending on platform. A CAA misconfiguration here silently breaks MTA-STS enforcement weeks or months after the initial deployment when the auto-renewal cron fails — the policy file becomes unreachable, sending MTAs fall back to opportunistic TLS per RFC 8461 §5, and the transport-encryption guarantee evaporates without any operator-visible signal until a TLS-RPT report eventually surfaces the failure.
• DNS propagation — the MTA-STS-WORKSPACE-DEPLOYMENT- AS-MULTI-RECORD-DNS-AND-HTTPS- POLICY-FILE-COORDINATED-PUBLICATION- CYCLE companion to this Workspace MTA-STS deployment page. The DNS propagation spoke is the publisher- side publish-and-verify-cycle reference that mediates how long a Workspace-tenant MTA-STS deployment change takes to materialise at the sender-MTA's MTA-STS resolver-side enforcement decision at FOUR MTA- STS-publication-coordination dimensions: (i) publisher emits new _mta-sts.<d> TXT record with rotated id= value → sender-MTA's MTA-STS resolver cache invalidates at TTL expiry → sender-MTA re-fetches the https://mta-sts.<d>/.well-known/mta-sts.txt policy body and refreshes its in-memory MTA-STS policy cache — the DNS propagation spoke documents the cycle for the publisher emitting a new MTA-STS id= rotation: the DNS TXT record TTL-bounded propagation governs the sender- MTA's resolver-cache invalidation window; the spoke documents how the publisher should LOWER the TTL on the MTA-STS TXT record BEFORE the planned id= rotation to compress the sender-side time-to-cache-refresh window; (ii) publisher emits new HTTPS-served policy-file body (mode: testing → mode: enforce transition, MX allow-list update for new Workspace MX, max_age extension) → sender-MTA re-fetches the new policy on next id= rotation — the DNS propagation spoke documents the OPERATOR-DISCIPLINE-RULE that the publisher MUST rotate the DNS TXT id= value when emitting a new policy-file body (because the sender-MTA's policy cache keyed by id= will NOT invalidate until id= changes); the spoke's policy-rotation coordination rule is the load- bearing operator-discipline for safely transitioning from mode: testing to mode: enforce without leaving senders on a stale cached mode: testing policy; (iii) publisher coordinates the mta-sts.<d> HTTPS endpoint cutover (CDN edge-server refresh, origin certificate rotation, backend-IP rebalancing) with the DNS TXT id= rotation → coordinated DNS + HTTPS publish-and-verify cycle — the DNS propagation spoke documents the cycle for the Workspace tenant's MTA-STS HTTPS endpoint cutover: the publisher must coordinate the DNS TXT id= rotation with the HTTPS-endpoint availability of the new policy body (no DNS propagation-cycle race condition where sender-MTAs fetch the new id= but find the OLD policy body still served at the HTTPS endpoint); the spoke's coordinated-publish-cycle operator-discipline-rule is the load-bearing reference for this race-condition- avoidance pattern; (iv) publisher retires Workspace MTA-STS deployment → DNS TXT record DELETE → TTL- bounded sender-MTA resolver-cache invalidation → sender-MTA FALLS BACK to opportunistic STARTTLS or cleartext per RFC 8461 §3.4 precedence — the DNS propagation spoke documents the cycle for the publisher retiring an MTA-STS deployment: the TTL-bounded cache invalidation governs how long after the TXT record DELETE sender-MTAs observe the absence of the MTA-STS policy and fall back to opportunistic STARTTLS (RFC 3207 / RFC 8461 §3.4 precedence chain — MTA-STS > DANE > opportunistic STARTTLS > cleartext); the spoke is the operator-discipline reference for computing the worst-case time-to- sender-MTA-fallback in a Workspace MTA-STS retirement scenario. Read the DNS propagation spoke WITH this Workspace MTA-STS deployment page when scheduling a Workspace tenant's MTA-STS deployment, rotation, or retirement — THIS page is the Workspace-tenant- specific MTA-STS deployment runbook; the propagation spoke is the TTL-bounded-publish-and- verify-cycle operator- discipline reference for safely coordinating the DNS-TXT id= rotation + HTTPS-served-policy-body update lifecycle the Workspace MTA-STS deployment depends on.
• SPF for Microsoft 365 — the PEER-CLOUD-MAILBOX-PROVIDER-M365- SPF-PUBLICATION-AS-CROSS-LAYER-COMPLEMENT- TO-WORKSPACE-MTA-STS-PUBLICATION companion to this MTA-STS-for-Workspace reference. Where THIS page documents the per- Workspace-tenant MTA-STS publication discipline (DNS _mta-sts TXT-record with per-tenant id=, HTTPS-served policy file with per-tenant mx: pattern-list + mode:enforce|testing|none + max_age, TTL-bounded id= rotation lifecycle), the SPF-for-Microsoft-365 spoke is the PEER- CLOUD-MAILBOX-PROVIDER MESSAGE-LAYER- AUTHENTICATION-PUBLICATION reference whose per-M365-tenant publication-discipline complements the per-Workspace-tenant MTA-STS transport-layer-publication this page documents at FOUR cross-layer cross- cloud publication-discipline coupling dimensions: (i) per-M365-tenant SPF publication (DNS TXT v=spf1 include:spf.protection.outlook.com cascade) as MESSAGE-LAYER publication primitive PARALLEL to per-Workspace-tenant MTA-STS publication (DNS TXT + HTTPS policy-host) as TRANSPORT-LAYER publication primitive — both are per-tenant per-domain DNS-anchored publication-discipline primitives, but the per-M365-tenant SPF primitive operates at the message-layer authentication-evidence plane (per-source-IP per-mechanism SPF evaluation against the MAIL-FROM-domain) while the per-Workspace-tenant MTA-STS primitive operates at the transport-layer TLS-enforcement plane (per-MX-host TLS validation against the policy-host's mx: pattern-list); (ii) per-M365- tenant SPF publication's per-source-IP evaluation outcome (pass / fail / softfail / neutral / permerror / temperror) at the receiver-side Workspace inbound vs per-Workspace-tenant MTA-STS publication's per-MX-host evaluation outcome (enforce / testing / none / policy-fetch-fail / id-mismatch) at the sender-side M365 outbound — both produce per-tenant receiver-side evaluation outcomes against the per- tenant published-record content, but on opposite cross-cloud mail-flow legs (per- M365-tenant SPF evaluated at Workspace- inbound for mail-from-M365-senders vs per-Workspace-tenant MTA-STS evaluated at M365-outbound for mail-to-Workspace- recipients); (iii) per-M365- tenant per-mail-flow-connector outbound- smarthost IP-list as per-tenant SPF- evaluation source-IP topology vs per- Workspace-tenant per-MX-host TLS- validation topology — each per- tenant publishes the per-tenant per- layer topology its peer-cloud mailbox- provider authenticates against, producing the cross-cloud per-tenant per-layer receiver-side evaluation context the cross-cloud mail-flow leg depends on for per-tenant deliverability + per-tenant TLS-enforcement; (iv) per-M365- tenant SPF publication's -all qualifier publication-commitment vs per- Workspace-tenant MTA-STS publication's mode:enforce publication- commitment — both are per- tenant publication-commitment tail- terminators that signal the per-tenant publisher's authorisation discipline to the receiver-side per-layer evaluator (- all = SPF hard-fail on per-source-IP mismatch; mode:enforce = MTA-STS TLS-enforcement on per-MX-host validation failure), and both per-tenant publication- commitments must be coordinated for the per-tenant cross-layer publication discipline stack to provide per-tenant message-layer-and-transport-layer cross- cloud defense coverage. Read the SPF- for-Microsoft-365 spoke alongside this MTA-STS-for-Workspace reference when scoping the per-tenant cross-layer publication-discipline stack the cross- cloud M365-to-Workspace and Workspace- to-M365 mail-flow legs structurally consume.
• MX records explained — the WORKSPACE-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-Google- Workspace reference. Where THIS page documents the per-Workspace-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: aspmx.l.google.com / mx: alt1.aspmx.l. google.com / mx: alt2.aspmx.l.google.com / mx: alt3.aspmx.l.google.com / mx: alt4.aspmx.l.google.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-Workspace-tenant MX-to-MTA- STS-policy coupling dimensions: (i) per-tenant per-domain MX-RR- receive-side-hostname-set publication as load-bearing per-tenant per-domain mta-sts.txt mx:-directive authoritative-mirror requirement — the per-Workspace-tenant per-domain MX-RR publication (<tenant- domain> IN MX 1 aspmx.l.google.com / 5 alt1.aspmx.l.google.com / 5 alt2.aspmx. l.google.com / 10 alt3.aspmx.l.google.com / 10 alt4.aspmx.l.google.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 ALL FIVE aspmx-tier MX-host entries 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- aspmx-tier-rollover as load-bearing per- tenant per-domain mta-sts.txt id=-tag- version-bump-coordination trigger — every per-tenant per- domain MX-RR-aspmx-tier-rollover (per- Google-side aspmx-tier MX-host inventory rotation — new aspmx-tier host added or deprecated to per-tenant per-domain MX-RR list during Google-managed multi- region active-active deployment cycle) 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-aspmx-tier- 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 aspmx-tier host but per-tenant per-domain mta-sts.txt mx:-directive list still lists the retired aspmx-tier host) 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 Workspace-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 1 aspmx.l.google.com + per-tenant per-domain 5 alt1./ alt2.aspmx.l.google.com + per-tenant per-domain 10 alt3./ alt4.aspmx.l.google.com) 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 (ALL FIVE per-Workspace-tenant aspmx-tier MX-host entries individually listed in mx:- directive list) the per-Workspace- 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-Google-Workspace reference whenever a per-Workspace-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-Workspace-tenant per-domain MTA-STS publication-discipline workflow, the MX-records spoke gives the canonical per-tenant per-domain MX-RR- publication-and-aspmx-tier-rollover- discipline IT consumes as the load- bearing upstream receive-side-MX- inventory-list input.
• DMARC for shared hosting — the per-shared-hosting-tenant per-custom- domain APPLICATION-LAYER-DMARC-DEPLOYMENT peer-operator-empowerment-ceiling companion to this per-Workspace-tenant transport- layer MTA-STS publication tutorial. Where THIS page documents the per-Workspace- tenant per-custom-domain MTA-STS publication tutorial — per-tenant per- custom-domain _mta-sts.<domain> TXT policy-version-pointer publication, per- tenant per-custom-domain mta-sts.<domain> HTTPS policy-file publication path, per-tenant per-custom-domain _smtp._tls.<domain> TLS-RPT publication, the per-Workspace- tenant per-custom-domain Google-tenant- as-receive-side-MTA STARTTLS-enforcement- contract — the DMARC-for-shared-hosting spoke documents the structurally-paired per-shared-hosting-tenant per-custom- domain DMARC application-layer deployment tutorial (Plesk / DirectAdmin / ISPConfig / Webmin / CWP / no-control-panel operator-empowerment-ceiling tiers). The composition operates as a per- publisher per-custom-domain OPERATOR- EMPOWERMENT-CEILING TRANSPORT-VS- APPLICATION-LAYER-PEER relationship: per- Workspace-tenant per-custom-domain MTA- STS publication on the Workspace-tier operator-empowerment ceiling (full UI access, per-tenant self-service DKIM / DMARC / MTA-STS toggle) gates per- Workspace-tenant per-custom-domain transport-layer per-receiver-MTA TLS- enforcement contract publication; per- shared-hosting-tenant per-custom-domain DMARC publication on the shared-hosting operator-empowerment ceiling (panel-tier-restricted DKIM-toggle access, SaaS-relay CNAME-delegated DKIM escape hatch when no panel exists) gates per-shared-hosting-tenant per-custom-domain application-layer per-publisher per-domain DMARC alignment-enforcement contract publication — both are LOAD-BEARING per- publisher per-custom-domain OPERATOR- EMPOWERMENT-CEILING tutorials whose per-tenant per-custom-domain operator UI-access surface materially gates the per-tenant per-custom-domain authentication-discipline publication- completeness at the transport-layer (MTA-STS) vs application-layer (DMARC) tier. Read THIS page when DEPLOYING the per-Workspace-tenant per-custom-domain MTA-STS transport-layer publication discipline; read the DMARC-for-shared- hosting spoke when DEPLOYING the per- shared-hosting-tenant per-custom-domain DMARC application-layer publication discipline as the per-publisher per- custom-domain peer-operator-empowerment- ceiling tutorial whose per-tenant per- custom-domain operator UI-access ceiling materially gates the per-publisher per- custom-domain authentication-discipline publication completeness on the application-layer DMARC tier.
• SPF forwarding issues (the second-hop break) — the APPLICATION-LAYER-SPF-FORWARDING-BREAK- AS-PARALLEL-AUTHENTICATION-LAYER-EXPOSURE- DESPITE-PER-WORKSPACE-TENANT-MTA-STS-ENFORCED- TRANSPORT-ENCRYPTION companion to this Google Workspace tenant MTA-STS deployment reference. Where THIS page documents the per-Workspace- tenant MTA-STS publication discipline (the _mta-sts.<domain> TXT-ID- record publication, the mta-sts.<domain> HTTPS policy-host hosting topology, the per- tenant mode=enforce / mode=testing ramp discipline, the per-Workspace-tenant MX-allow-list pinning to the canonical aspmx.l.google.com family, the per-tenant max_age cache-policy publication, and the parallel per-Workspace-tenant TLS-RPT _smtp._tls.<domain> RUA publication for failure-report ingestion), the SPF-forwarding-issues spoke is the CROSS-LAYER- APPLICATION-LAYER-AUTHENTICATION-PARALLEL- EXPOSURE companion documenting how the per- Workspace-tenant message-authentication publication discipline (the parallel application-layer SPF / DKIM / DMARC posture) is structurally vulnerable to forwarder- induced second-hop SPF-fail outcomes that the per-tenant transport-layer MTA-STS posture does NOT defend against. The MTA-STS-vs-SPF- forwarding-issues relationship is cross-layer- publisher-discipline-with-independent-vulnerability- profiles: MTA-STS encrypts the SMTP transport between sending MTA and receiving MTA but cannot rescue forwarder-induced message- authentication-fail outcomes; SPF-forwarding- break is forwarder-induced message- authentication-fail that survives perfectly encrypted MTA-STS transport. Four per-Workspace- tenant MTA-STS-vs-SPF-forwarding-break cross- layer coupling dimensions matter at the per- Workspace-tenant publication discipline boundary: (i) per-Workspace-tenant transport- layer MTA-STS-enforced TLS encrypts the SMTP delivery to aspmx.l.google.com but does NOT preserve the per-publisher first-hop SPF verdict across a forwarder hop where envelope-rewriting reauthenticates the message against the forwarder's source- IP; (ii) per-Workspace-tenant DKIM-aligned- pass as application-layer survival primitive — when the per-tenant message traverses a forwarder hop that breaks SPF-aligned-pass via envelope rewriting, the per-Workspace- tenant DKIM-aligned-pass (signed at the Workspace outbound boundary with google.com-managed signing identity) becomes the SOLE DMARC-aligned-pass leg surviving the forwarder hop; (iii) per- Workspace-tenant TLS-RPT failure-report ingestion at _smtp._tls.<domain> captures transport-layer MTA-STS enforcement outcomes but does NOT capture per-message forwarder-induced application-layer SPF-fail outcomes — the per-tenant DMARC RUA aggregate- report ingestion is the parallel application- layer evidence stream documenting per- forwarder-hop SPF-fail attribution; (iv) per-Workspace-tenant cross-layer authentication- and-encryption posture completeness — the per-tenant MTA-STS publication discipline delivers TRANSPORT-LAYER encryption guarantees; the per-tenant SPF publication discipline delivers FIRST-HOP application-layer authentication; the per-tenant DKIM publication discipline delivers FORWARDER-SURVIVING application-layer authentication; only the joint posture across MTA-STS + SPF + DKIM + DMARC delivers complete per-Workspace-tenant publication posture. Read THIS page when AUTHORING the per-Workspace-tenant MTA-STS transport-layer publication discipline; read the SPF-forwarding-issues spoke when DIAGNOSING the canonical application-layer forwarder- induced second-hop SPF-fail outcome that the per-Workspace-tenant MTA-STS transport-layer posture cannot itself defend against.
• DMARC aggregate (RUA) reports — the PER-WORKSPACE-TENANT-PER- CUSTOM-DOMAIN-DMARC-RUA-XML-SCHEMA-AS- APPLICATION-LAYER-AUTHENTICATION-VERDICT- EVIDENCE-STREAM-COMPLEMENT-FOR-PER- WORKSPACE-TENANT-MTA-STS-TRANSPORT-LAYER- TLS-RPT-JSON-EVIDENCE-STREAM companion to this per-Workspace-tenant MTA-STS deployment reference. Where THIS page documents the per-Workspace-tenant per- custom-domain MTA-STS HTTPS-served policy publication (mta-sts.<custom-domain> well-known endpoint with mx: ASPMX.L. GOOGLE.COM + ALT*.ASPMX.L.GOOGLE.COM per-Workspace-tenant inbound MX-pattern allowlist + per-Workspace-tenant testing/ enforce mode + max_age: + per-Workspace- tenant TLS-RPT JSON evidence-stream observability), the DMARC-aggregate-RUA- reports spoke is the per-Workspace-tenant per-custom-domain APPLICATION-LAYER authentication-verdict evidence stream complement at FOUR per-Workspace-tenant cross-layer observability coordination dimensions: (i) per-Workspace- tenant per-custom-domain DMARC RUA aggregate-report per-receiver per-source- IP per-alignment-outcome row stream coordinated with per-Workspace-tenant per-custom-domain MTA-STS TLS-RPT JSON evidence stream — per-Workspace- tenant operators reading per-receiver-side per-custom-domain TLS-RPT JSON evidence streams (the per-Workspace-tenant transport- layer per-receiver per-MX STARTTLS-handshake- success-or-failure attribution primitive) cross-reference per-receiver-side per- custom-domain DMARC RUA XML rows (the per-Workspace-tenant application-layer per- receiver per-source-IP per-message authentication-verdict attribution primitive) when triaging per-Workspace-tenant per- custom-domain per-receiver per-message deliverability anomalies that correlate across both layers; (ii) per- Workspace-tenant per-custom-domain MTA-STS enforce-mode rollout prerequisite per- Workspace-tenant per-custom-domain DMARC RUA aggregate-report per-source-IP per- alignment-outcome survey-discipline readiness — per-Workspace-tenant operators committing per-Workspace-tenant per-custom-domain MTA-STS enforce-mode publication MUST first verify per-Workspace- tenant per-custom-domain DMARC RUA aggregate-report per-source-IP per-alignment- outcome stream is at deliverability- discipline-floor readiness (per-Workspace- tenant per-custom-domain per-tenant-SaaS- platform per-source-IP authentication attribution stable across per-receiver per-author-domain rows) because per- Workspace-tenant per-custom-domain transport-layer enforce-mode commits the per-Workspace-tenant per-custom-domain to per-receiver per-MX STARTTLS-handshake rejection of per-message STARTTLS-downgrade attempts whose per-source-IP attribution the per-Workspace-tenant per-custom-domain DMARC RUA aggregate-report stream IS the per-publisher per-domain canonical observability primitive for; (iii) per-Workspace-tenant per-custom- domain joint MTA-STS testing-and-DMARC- RUA observability rollout discipline at per-Workspace-tenant rollout Phase 1 evidence-survey window — per- Workspace-tenant operators typically deploy per-Workspace-tenant per-custom- domain MTA-STS testing-mode publication AND per-Workspace-tenant per-custom- domain DMARC p=none monitor-only publication CONCURRENTLY at per- Workspace-tenant rollout Phase 1 because both per-Workspace-tenant per-custom- domain publications produce per-receiver- side evidence streams (per-Workspace- tenant per-custom-domain TLS-RPT JSON for transport-layer STARTTLS-handshake failures, per-Workspace-tenant per- custom-domain DMARC RUA XML for application-layer per-source-IP authentication-attribution verdicts) the per-Workspace-tenant operator analyses before committing to per-Workspace- tenant per-custom-domain MTA-STS enforce-mode + per-Workspace-tenant per- custom-domain DMARC p=quarantine-or-p= reject terminal-discipline commitments; (iv) per-Workspace-tenant per- custom-domain joint cross-layer rollback discipline coordinating MTA-STS mode downshift with per-Workspace-tenant per- custom-domain DMARC RUA per-source-IP per-alignment-outcome row stream stability verification — when per-Workspace-tenant operators detect per-Workspace-tenant per-custom-domain deliverability KPI degradation post per- Workspace-tenant per-custom-domain MTA- STS enforce-mode rollout, the per- Workspace-tenant per-custom-domain rollback discipline applies BOTH to the per-Workspace-tenant per-custom-domain MTA-STS publication (downshift per- Workspace-tenant per-custom-domain MTA- STS mode from enforce back to testing) AND verifies per-Workspace-tenant per- custom-domain DMARC RUA aggregate-report per-source-IP per-alignment-outcome row stream stability across the per- Workspace-tenant per-custom-domain rollback window. Read the DMARC- aggregate-RUA-reports spoke alongside this per-Workspace-tenant MTA-STS deployment reference when AUTHORING per- Workspace-tenant per-custom-domain cross- layer (application-layer DMARC + transport- layer MTA-STS) rollout coordination runbooks, when AUDITING per-Workspace- tenant per-custom-domain DMARC alignment- posture BEFORE committing to per- Workspace-tenant per-custom-domain MTA- STS enforce-mode publication, when EXECUTING per-Workspace-tenant per- custom-domain per-receiver-side TLS-RPT- and-DMARC-RUA cross-evidence-stream triage, or when ESTABLISHING per- Workspace-tenant per-custom-domain joint per-receiver-side TLS-RPT-and- DMARC-RUA observability coordination discipline-floor.
• RFC 8461 — SMTP MTA Strict Transport Security — the canonical specification.
• RFC 8460 — SMTP TLS Reporting — the canonical TLS-RPT specification.
• Google Workspace Help: Set up SMTP TLS reports for your domain — the Google primary-source reference for TLS-RPT and MTA-STS guidance on Workspace tenants.
• 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 explained — the PER-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-MTA-STS-PUBLICATION-AS-TRANSPORT- LAYER-COMPANION-TO-BIMI-APPLICATION-LAYER- BRAND-PROTECTION companion to THIS per- Workspace-tenant per-custom-domain MTA-STS publication reference. Where THIS page documents the per-Workspace-tenant per- custom-domain MTA-STS publication workflow (the per-tenant per-custom-domain _mta-sts.<custom-domain> TXT-RR + mta-sts.<custom-domain> HTTPS policy-file publication, the per-tenant per-custom-domain mode=none → mode=testing → mode=enforce phase-transition cadence, the per-Workspace-tenant per- custom-domain TLS-RPT cross-layer observability coordination, the per-tenant per-custom-domain SMTP MTA-to-MTA cryptographic-certificate-validation transport-layer enforcement), the BIMI explained spoke documents the per-publisher per-domain application-layer BIMI brand- indicator-rendering eligibility cascade at FOUR per-MTA-STS-publication-vs-BIMI- indicator-rendering coupling dimensions: (i) per-Workspace-tenant per-custom- domain MTA-STS transport-layer enforcement AS structurally-parallel transport-layer publisher-side identity-protection publication discipline to per-publisher per- domain BIMI application-layer brand- protection publication discipline — the per-Workspace-tenant per-custom-domain MTA-STS publication discipline IS the transport-layer publisher-side identity- protection publication discipline that compresses per-attacker MITM-vector attack surface against per-publisher per-domain legitimate mail-stream; the per-publisher per-domain BIMI publication discipline IS the application-layer publisher-side brand- protection publication discipline that compresses per-attacker brand-impersonation vector attack surface at the per-recipient per-message inbox-list-display layer; the two publications are structurally parallel publisher-side identity-and-brand-protection publication-coordination disciplines; (ii) per-Workspace-tenant per-custom- domain MTA-STS + TLS-RPT cross-layer observability AS transport-layer observability complement to per-publisher per-domain BIMI brand-indicator-rendering observability — the per-Workspace- tenant per-custom-domain TLS-RPT JSON- aggregate-report cadence provides per- publisher per-domain transport-layer- encryption-floor observability that structurally complements the per-publisher per-domain BIMI brand-indicator-rendering- decision observability the per-publisher per-domain operator surveys via per-receiver per-message inbox-list-display-layer rendering surveys; (iii) per- Workspace-tenant per-custom-domain MTA-STS mode=enforce phase-transition commitment AS transport-layer-enforcement- floor analog of per-publisher per-domain DMARC p=reject phase-transition commitment that is per-publisher per-domain BIMI brand-indicator-rendering eligibility precondition — the per-Workspace- tenant per-custom-domain MTA-STS mode=enforce commitment is the transport-layer-enforcement-floor analog of the per-publisher per-domain application- layer DMARC p=reject enforcement-floor commitment; the per- publisher per-domain BIMI indicator- rendering eligibility cascade depends on the per-publisher per-domain DMARC enforcement- floor commitment; the per-publisher per- domain MTA-STS enforcement-floor commitment and the per-publisher per-domain DMARC enforcement-floor commitment together constitute the per-publisher per-domain unified transport-layer-and-application- layer trust-signal floor publication posture; (iv) per-Workspace-tenant per-custom-domain MTA-STS publication AS per-publisher per-domain brand-protection- authority publication coordination complement — per-publisher per- domain BIMI publication discipline coordinates per-publisher per-VMC trademark- authority issuance + per-publisher per- domain BIMI selector publication + per- publisher per-domain DMARC enforcement-floor + per-publisher per-domain SPF + DKIM composite-publication; the per-Workspace- tenant per-custom-domain MTA-STS publication discipline THIS page documents IS the per- Workspace-tenant per-custom-domain transport- layer publication input that the per- publisher per-domain unified trust-signal coordination posture rests on at the per- publisher per-domain transport-layer-and- application-layer publication-coordination boundary. Read THIS page when PUBLISHING per-Workspace-tenant per-custom-domain MTA- STS; read the BIMI explained spoke when UNDERSTANDING how the per-Workspace-tenant per-custom-domain MTA-STS transport-layer publication discipline THIS page documents IS the per-publisher per-domain transport- layer publication primitive structurally parallel to the per-publisher per-domain BIMI application-layer brand-protection- authority publication discipline at the per- publisher per-domain unified-transport-and- application-layer trust-signal-floor coordination boundary.
• BIMI Verified Mark Certificates (VMC and CMC)
• DKIM replay attacks
• BIMI SVG asset requirements
• SPF DNS record syntax explained
• DMARC for cPanel hosting — the PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN-MTA-STS-HTTPS-SERVED-POLICY-TRANSPORT-LAYER-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-PER-TENANT-PER-CUSTOM-DOMAIN-MULTI-TENANT-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-CPANEL-TENANT-PER-CUSTOM-DOMAIN-APPLICATION-LAYER-DMARC-PUBLICATION-DISCIPLINE companion at four per-tenant-multi-tenant-deployment-vs-MTA-STS-transport-layer-publication-discipline coupling dimensions: (1) per-Workspace-tenant per-custom-domain MTA-STS HTTPS-served-policy publication-discipline at https://mta-sts.<workspace-tenant>/.well-known/mta-sts.txt per RFC 8461 §3.2 IS structurally parallel per-tenant per-custom-domain multi-tenant-deployment publication-discipline to per-cPanel-tenant per-custom-domain DMARC TXT-RR publication-discipline at _dmarc.<cpanel-tenant-custom-domain> per RFC 7489 §6.1 — both are per-tenant per-custom-domain N-tenant cloud-or-shared-hosting-deployment per-message-authentication primitives whose per-tenant per-custom-domain operator-side N-tenant publication-discipline coordination underpins the per-tenant per-custom-domain composite multi-tenant deployment authentication-floor; (2) per-Workspace-tenant per-custom-domain transport-layer MTA-STS enforcement-mode publication-discipline (mode=none → mode=testing → mode=enforce per RFC 8461 §5) IS structurally parallel per-tenant per-custom-domain enforcement-ramp publication-discipline to per-cPanel-tenant per-custom-domain DMARC application-layer enforcement-mode-ramp publication-discipline (p=none → p=quarantine → p=reject per RFC 7489 §6.3) — both per-tenant per-custom-domain publication-discipline references are per-tenant per-custom-domain N-tenant operator-side per-tenant ramp-readiness-coordination publication-discipline primitives at the per-tenant per-custom-domain composite N-tenant cross-layer ramp-publication-discipline coordination boundary; (3) per-Workspace-tenant per-custom-domain MTA-STS mx: allow-list publication-discipline enumerating Workspace inbound MX hosts (aspmx.l.google.com) IS structurally parallel per-tenant per-custom-domain enumeration-publication-discipline to per-cPanel-tenant per-custom-domain SPF include: macro-publication discipline (per-cPanel-shared-MX-cluster outbound IP-pool enumeration) the per-cPanel hosting page documents the per-tenant per-custom-domain SPF publication-discipline of — both per-tenant per-custom-domain enumeration-publication-discipline references are per-tenant per-custom-domain N-tenant operator-side per-tenant per-MX-host-or-IP-pool inbound-or-outbound DNS-publication-discipline primitives at the per-tenant per-custom-domain composite N-tenant inbound-and-outbound MX-cluster-and-IP-pool publication-discipline coordination boundary; (4) per-Workspace-tenant per-custom-domain MTA-STS-HTTPS-served-policy publication-discipline TLS-RPT JSON aggregate-report-pipeline per RFC 8460 IS structurally parallel per-tenant per-custom-domain aggregate-report-pipeline to per-cPanel-tenant per-custom-domain DMARC RUA XML aggregate-report-pipeline per RFC 7489 §7 — both per-tenant per-custom-domain N-tenant aggregate-report-pipeline references gate per-tenant per-custom-domain operator-actionable per-day per-receiver per-tenant evidence-stream-driven publication-discipline drift-closure visibility at the per-tenant per-custom-domain composite N-tenant multi-tenant-deployment per-day per-receiver aggregate-observability coordination boundary the per-cPanel hosting page documents the per-tenant per-custom-domain application-layer publication-discipline of.
• Phishing protection
• SPF mechanisms explained — the PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN-MTA-STS-HTTPS-SERVED-POLICY-TRANSPORT-LAYER-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-COMPANION-TO-PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN-SPF-MECHANISM-CLASS-ENVELOPE-MAIL-FROM-LAYER-PUBLICATION-DISCIPLINE companion at four per-Workspace-tenant per-custom-domain MTA-STS-vs-SPF-mechanism-class coupling dimensions: (i) per-Workspace-tenant per-custom-domain MTA-STS mx: allow-list publication-discipline enumerating Workspace inbound MX hosts (aspmx.l.google.com + *.googlemail.com) IS structurally parallel per-Workspace-tenant per-custom-domain enumeration-publication-discipline to per-Workspace-tenant per-custom-domain SPF include:_spf.google.com mechanism-class macro-publication discipline enumerating Workspace outbound IP-pool authorization vocabulary the SPF mechanism-class catalogue THIS page documents the per-publisher per-domain SPF mechanism-vocabulary publication-discipline of; (ii) per-Workspace-tenant per-custom-domain MTA-STS HTTPS-served-policy publication-discipline + per-Workspace-tenant per-custom-domain SPF TXT-RR include:_spf.google.com mechanism-class macro-expansion publication-discipline JOINTLY underpin per-Workspace-tenant per-custom-domain composite transport-and-envelope-MAIL-FROM-layer cryptographic-trust-floor — per-tenant MTA-STS mode: enforce transport-layer enforcement is structurally parallel envelope-MAIL-FROM-layer authorization-discipline to per-tenant SPF -all terminal-mechanism qualifier-publication enforcement; (iii) per-Workspace-tenant per-custom-domain MTA-STS policy-id rotation cadence per RFC 8461 §4.1 IS structurally parallel per-tenant transport-layer DNS-publication-budget-rotation discipline to per-Workspace-tenant per-custom-domain SPF include:_spf.google.com recursive-expansion DNS-lookup-cap budget per RFC 7208 §4.6.4 — both are per-Workspace-tenant per-custom-domain operator-side publication-budget primitives at the per-Workspace-tenant composite transport-and-envelope-MAIL-FROM-layer DNS-publication-budget coordination boundary; (iv) per-Workspace-tenant per-custom-domain MTA-STS policy-discovery-failure (mode-stuck-testing surfacing in TLS-RPT JSON aggregate-report) IS structurally parallel per-tenant transport-layer publication-discipline-drift class to per-Workspace-tenant per-custom-domain SPF mechanism-class publication-discipline drift (premature -all hardfail cutover surfacing as DMARC RUA spf=fail attribution-distortion + permerror on 10-DNS-lookup-cap exhaustion surfacing as SPF-aligned-pass-rate floor regression) the SPF mechanism-class catalogue THIS page documents the diagnostic discipline of.
• DKIM failures explained — the PER-WORKSPACE-TENANT-PER-CUSTOM-DOMAIN-MTA-STS-TRANSPORT-LAYER-HTTPS-SERVED-POLICY-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-TRANSPORT-LAYER-CRYPTOGRAPHIC-PUBLICATION-COMPANION-TO-PER-WORKSPACE-TENANT-PER-ACCEPTED-DOMAIN-DKIM-APPLICATION-LAYER-CRYPTOGRAPHIC-AUTHENTICATION-LEG-VERDICT-FAILURE-CATALOGUE companion at four per-Workspace-tenant per-custom-domain MTA-STS-vs-DKIM-failures-verdict-catalogue coupling dimensions: (i) per-Workspace-tenant per-custom-domain MTA-STS mode: testing → mode: enforce transport-layer enforcement-mode ramp publication-decision IS structurally parallel per-tenant cryptographic-trust-publication-decision to per-Workspace-tenant per-accepted-domain DKIM application-layer cryptographic-signing-discipline whose per-message DKIM-Signature verdict-fail-class taxonomy the DKIM-failures explained spoke documents the diagnostic ladder of; (ii) per-Workspace-tenant per-custom-domain MTA-STS-policy-fetch transport-layer cryptographic-failure (per RFC 8460 TLS-RPT sts-policy-fetch-error / sts-policy-invalid per-day per-MX-host attribution stream) IS structurally parallel transport-layer cryptographic-verdict-fail to per-Workspace-tenant per-accepted-domain DKIM application-layer cryptographic-verdict-fail (per RFC 8601 §2.7.1 dkim=fail body-hash mismatch / dkim=permerror public-key fetch failure / dkim=temperror transient DNS-resolver-side public-key fetch failure) the DKIM-failures explained spoke documents the per-receiver per-message per-publisher per-selector verdict-attribution diagnostic ladder of; (iii) per-Workspace-tenant per-custom-domain MTA-STS-policy-id rotation cadence per RFC 8461 §4.1 IS structurally parallel per-tenant cryptographic-trust-publication-rotation cadence to per-Workspace-tenant per-accepted-domain DKIM Rotate-DkimSigningConfig 2048-bit cryptographic-key rotation cadence whose per-publisher per-selector publication-discipline drift surfaces as per-receiver per-day per-source-IP DMARC RUA auth_results/dkim=fail attribution the DKIM-failures explained spoke documents the per-publisher per-selector publication-discipline-drift diagnostic ladder of; (iv) per-Workspace-tenant per-custom-domain MTA-STS-policy-fetch transport-layer cryptographic-failure observability stream (per RFC 8460 TLS-RPT JSON aggregate-report) IS structurally parallel per-tenant cross-layer cryptographic-failure-evidence-observability companion to per-Workspace-tenant per-accepted-domain DKIM application-layer cryptographic-verdict-fail observability stream (per RFC 7489 §7.2 DMARC RUA aggregate-XML auth_results/dkim per-row per-day per-source-IP attribution) the DKIM-failures explained spoke documents the per-publisher per-selector per-receiver per-day per-source-IP verdict-attribution-and-diagnostic-evidence stream of. Read the DKIM-failures explained spoke when DIAGNOSING per-Workspace-tenant per-accepted-domain composite cross-layer cryptographic-publication-discipline floor regression at the per-tenant per-custom-domain MTA-STS transport-layer-policy-fetch verdict OR per-accepted-domain DKIM application-layer per-message-verdict-fail root-cause-attribution coordination boundary every per-Workspace-tenant per-custom-domain DMARC operator-side cross-layer cryptographic-aligned-pass-rate floor preservation discipline depends on.
• DMARC for transactional email
• Reverse DNS / PTR records for mail servers
• DKIM explained (cryptographic message signing, the public key in DNS, and receiver-side verification of the DKIM-Signature) — MTA-STS secures the transport channel to your Workspace MX, while DKIM secures the message itself; both are controls a Workspace operator publishes for the same domain at distinct layers. Read the DKIM primer alongside this MTA-STS guide so the per-tenant signing you set up in the Admin Console produces the aligned dkim=pass that DMARC enforcement needs.
• Email spoofing explained — the threat-class reference whose seven-technique taxonomy includes the transport-layer STARTTLS-stripping MITM variant that the Workspace MTA-STS policy this page deploys structurally closes; read it to place this transport-layer defense in the wider anti-spoofing picture alongside the SPF, DKIM, and DMARC message-layer legs.
• SPF explained — MTA-STS secures the transport channel to your Workspace MX, while SPF authorizes the envelope sender at the message layer; both are controls a Workspace operator publishes for the same custom domain at distinct layers. Read the SPF primer so the include:_spf.google.com leg this page's tenant relies on produces the aligned spf=pass that DMARC enforcement needs alongside the transport-layer policy.
• DKIM signatures explained — MTA-STS secures the transport channel to your Workspace MX, but the message itself is signed by the DKIM-Signature header this page's tenant publishes under the Workspace google selector. Read the signature byte-layout reference to see the b=/bh=/d=/s= tags a receiver verifies for the aligned dkim=pass that DMARC enforcement needs alongside this transport-layer policy.
• Microsoft SNDS + JMRP monitoring — the Microsoft-side counterpart of Google Postmaster Tools: when the same streams also reach Outlook.com/Hotmail recipients, SNDS is where Microsoft exposes per-IP GREEN/YELLOW/RED filter verdicts and JMRP is its complaint feedback loop.

Verify MTA-STS on your Google Workspace 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 Google Workspace MTA-STS setup