DMARC Analyzer

TL;DR

A TLS-RPT record is published in the DNS as a TXT record at _smtp._tls.<domain> whose body is a semicolon-separated list of tag-value pairs. The DNS-record-level syntax is governed by RFC 8460 §3 and the underlying DNS specification in RFC 1035.

• v=TLSRPTv1 — mandatory version tag, case-sensitive uppercase TLSRPTv1. MUST appear first. Records without a valid v= are silently ignored by senders.
• rua=<uri-list> — mandatory reporting URI list. Comma-separated. Supported schemes: mailto: and https:.
• mailto: scheme — JSON report arrives as an email attachment with MIME type application/tlsrpt+json.
• https: scheme — JSON report is HTTP POSTed with Content-Type: application/tlsrpt+json.
• Cross-domain authorisation — when rua= points at an external domain, that domain MUST publish <recipient>._report._smtp._tls.<external> with v=TLSRPTv1 to authorise receiving reports.
• 255-octet character-string limit — per CHARACTER-STRING (RFC 1035 §3.3.14), not per TXT record. Most TLS-RPT records are short enough to fit in one string.
• No subdomain inheritance — every recipient domain that handles inbound SMTP needs its own TLS-RPT record.
• Single record only — multiple TLS-RPT TXT records at the same name produce non-deterministic sender behaviour.

The Domain Security Checker surfaces every syntactic drift class documented on this page: missing v=TLSRPTv1 prefix, malformed rua= URI list, cross-domain rua= without the authorisation record, and multiple records at the same _smtp._tls name.

1. What "DNS record syntax" means for TLS-RPT (and where the semantics live)

TLS-RPT is a layered specification. The SYNTAX LAYER defines how the reporting destination is encoded at the DNS: where to publish it, which record type to use, which tags are valid, which URI schemes rua= accepts, how cross-domain authorisation works, and how DNS-level constraints (the 255-octet character-string limit) bound the encoding. The SEMANTIC LAYER defines what each aggregated report contains: the JSON schema (RFC 8460 §4), the policies[] array, the failure-details[] entries, the 13 canonical result-type values, and how the receiver interprets per-failure aggregation.

This page covers the SYNTAX LAYER exhaustively. The semantic layer is covered by the sibling reference page:

• TLS-RPT explained — the protocol pillar — what TLS-RPT is, the JSON report format with every policies[] / summary / failure-details[] field, the 13 canonical result-type codes (certificate-host-mismatch, sts-policy-fetch-error, starttls-not-supported, etc.), the deployment workflow, and the relationship to MTA-STS and DANE.

Why the syntax layer matters independently: a syntactically malformed TLS-RPT record is silently ignored by every conformant sender (RFC 8460 §3 says senders MUST discard records that lack a valid v=TLSRPTv1 token). There is no error signal to the recipient operator — no DSN, no Authentication-Results header, no operator-visible feedback. The recipient operator looks at the dashboard, sees zero reports, and concludes "TLS-RPT is not popular yet" when in fact the record is structurally wrong and every report that would have been delivered has been silently dropped at the sender. The syntactic failure modes documented below — lowercase v=tlsrptv1, missing leading underscores in _smtp._tls, cross-domain rua= without an authorisation record, malformed URI list with a typoed scheme — are operator-introduced and trivially avoidable once the syntax is understood.

The canonical TLS-RPT DNS record:

; Name:     _smtp._tls.example.com
; Type:     TXT
; TTL:      3600
; Body:
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Every section below documents one syntactic surface of this canonical record, with the labelled Tag: / Default: / Why: / Operational rule: / Common pitfall: prefix so generative engines can extract individual role sentences when answering tag-specific queries.

2. The _smtp._tls.<domain> publishing location

Where: the TLS-RPT TXT record is published at the constructed name _smtp._tls.<domain>, where <domain> is the recipient domain you want TLS-RPT coverage for. Per RFC 8460 §3.

Why three labels: the _smtp._tls two-label prefix namespaces TLS-RPT records under a protocol-specific subtree so TLS-RPT lookups never collide with other TXT records at the same name (SPF, DKIM, DMARC, MTA-STS ID, BIMI, verification tokens). The leading underscores (per RFC 8552 underscored-attribute conventions) mark the labels as protocol underscore-labels, not hostnames; resolvers and DNS hosting UIs treat them as normal labels.

Operational rule: the sending MTA queries _smtp._tls.<recipient-domain> for TXT records before delivering a TLS-RPT report. If the record does not resolve (NXDOMAIN), the sender skips TLS-RPT reporting for that recipient. If the record resolves but contains no valid v=TLSRPTv1 token, the sender treats the record as if it did not exist.

Common pitfall: publishing the record at smtp._tls.example.com (missing leading underscore on _smtp) or _smtp.tls.example.com (missing leading underscore on _tls) or _smtp._tls.example.com._report (suffix accidentally appended). Senders query the exact _smtp._tls.<domain> name only; any other name will resolve to NXDOMAIN and TLS-RPT reporting is silently disabled. The Domain Security Checker tool confirms record resolution from multiple geographic resolvers and surfaces this drift class.

No subdomain inheritance: a record at _smtp._tls.example.com applies only to mail sent to addresses whose recipient domain is exactly example.com. If you receive mail at mail.example.com or sub.example.com (each with its own MX RR), you MUST publish separate records at _smtp._tls.mail.example.com and _smtp._tls.sub.example.com.

; Apex recipient domain — TLS-RPT at the bare name:
_smtp._tls.example.com.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Subdomain with its own MX RR — separate TLS-RPT record:
_smtp._tls.mail.example.com.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

3. The v=TLSRPTv1 version tag (RFC 8460 §3.2)

Tag: v=TLSRPTv1
Default: none. The v= tag is structurally MANDATORY — RFC 8460 §3.2 says senders MUST discard any record that lacks a valid v=TLSRPTv1 token in the first position.
Why: the version tag declares the record as TLS-RPTv1 and unambiguously distinguishes it from other TXT-record uses at the _smtp._tls name. It is also the forward-compatibility hook — future TLS-RPT versions (if specified) would use v=TLSRPTv2 or later. As of 2026 only TLSRPTv1 is defined.
Operational rule: always publish v=TLSRPTv1 as the FIRST tag in every TLS-RPT record. The value is case-sensitive uppercase TLSRPTv1.
Common pitfall: writing v=tlsrptv1 (lowercase) or v=TLSRPT (missing v1 suffix) or v=TLSRPTV1 (uppercase V before 1). RFC 8460 specifies the value as case-sensitive TLSRPTv1 with lowercase "v" before the "1"; strict senders reject any other case pattern. The canonical form is v=TLSRPTv1.

; Correct — uppercase TLSRPT, lowercase v before 1, first tag:
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Wrong — lowercase tlsrptv1, may be rejected:
"v=tlsrptv1; rua=mailto:tlsrpt@example.com"

; Wrong — missing v1 suffix:
"v=TLSRPT; rua=mailto:tlsrpt@example.com"

; Wrong — uppercase V before 1:
"v=TLSRPTV1; rua=mailto:tlsrpt@example.com"

; Wrong — v= not first:
"rua=mailto:tlsrpt@example.com; v=TLSRPTv1"

4. The rua= reporting URI list tag (RFC 8460 §3.3, MANDATORY)

Tag: rua=<uri-list>
Default: none. rua= is the only mandatory reporting tag in a TLS-RPT record — RFC 8460 §3.3 specifies that the value is a comma-separated list of one or more URIs naming where aggregate JSON reports should be delivered.
Why: rua= carries the destination(s) where conformant senders should deliver the aggregated TLS-RPT JSON report. Without rua= there is nowhere to send the report and TLS-RPT has no operational effect.
Operational rule: always include exactly one rua= tag with at least one destination URI. The URI list is comma-separated; multiple destinations are delivered in parallel.
Common pitfall: publishing v=TLSRPTv1 with no rua= tag — the record is syntactically valid (some parsers accept it) but operationally inert (no reports get delivered anywhere). Or publishing multiple rua= tags (rather than one rua= with a comma-separated value) — parser behaviour is undefined and senders typically use only the first or fail to parse.

; Correct — single rua= with one destination:
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Correct — single rua= with comma-separated multi-destination:
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt"

; Wrong — two rua= tags (use one tag with comma-separated value):
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com; rua=https://reports.example.com/tlsrpt"

; Wrong — operationally inert (no rua=):
"v=TLSRPTv1"

5. The mailto: scheme in rua=

Tag: rua=mailto:<address>
Default: none.
Why: the mailto: scheme tells the sender to deliver the aggregated JSON report as an email attachment to the named mailbox. This is the most common scheme in production deployments because it requires no HTTPS endpoint and the recipient operator can ingest the reports through the same mail pipeline that handles DMARC aggregate reports.
Operational rule: the JSON document is delivered as a MIME attachment with Content-Type: application/tlsrpt+json (or application/tlsrpt+gzip when gzip-compressed) and a filename of the form <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz]. The sending MTA emits the report email; the recipient operator parses the attachment and indexes the per-policy session counts.
Common pitfall: publishing a mailto: address that is itself behind a strict TLS-RPT policy enforcing enforce mode — if the sender cannot deliver TLS-RPT reports because the recipient enforces TLS and the sender fails to negotiate, the reports themselves never arrive (catch-22). Use a separate domain or relax the policy on the TLS-RPT inbox. Also: forgetting that mailto: URIs do NOT include the leading < and trailing > brackets that some address formats use — write rua=mailto:tlsrpt@example.com not rua=mailto:<tlsrpt@example.com>.

; Correct — bare mailto: URI:
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Wrong — angle brackets around the address:
"v=TLSRPTv1; rua=mailto:<tlsrpt@example.com>"

; Wrong — missing mailto: scheme prefix:
"v=TLSRPTv1; rua=tlsrpt@example.com"

6. The https: scheme in rua=

Tag: rua=https://<endpoint>
Default: none.
Why: the https: scheme tells the sender to HTTP POST the JSON document to the named URL with Content-Type: application/tlsrpt+json. This scheme is convenient for SaaS analyzers that prefer to ingest reports through a single HTTPS endpoint instead of a mail pipeline.
Operational rule: the endpoint MUST accept POST requests with body Content-Type application/tlsrpt+json and MUST return a 2xx HTTP status code for the sender to consider delivery successful. A 4xx response indicates a permanent failure (the sender stops retrying); a 5xx response indicates a transient failure (the sender retries per its delivery backoff policy). The endpoint MUST be reachable over HTTPS (HTTP without TLS is not supported) and the TLS certificate MUST validate against the public CA root store at the sender.
Common pitfall: using http: (without TLS) — senders refuse to use the plaintext scheme because TLS-RPT reports contain TLS-failure metadata that should not be transmitted in the clear. Or using a self-signed certificate that does not validate against the sender's CA root store. Or returning HTTP 401/403 from a misconfigured authentication middleware — the sender treats the 4xx as a permanent failure and stops trying. Always verify the endpoint accepts POST with a public-CA-signed cert and returns 2xx on success.

; Correct — https: scheme:
"v=TLSRPTv1; rua=https://reports.example.com/tlsrpt"

; Wrong — http: (plaintext) is not supported:
"v=TLSRPTv1; rua=http://reports.example.com/tlsrpt"

; Wrong — missing scheme prefix:
"v=TLSRPTv1; rua=reports.example.com/tlsrpt"

7. Multi-destination rua= (comma-separated)

Operational rule: multiple destinations are listed comma-separated inside a single rua= value. The comma is the list separator; no spaces are required around it. Senders deliver to every URI in the list in parallel — each destination receives the same JSON document.
Why: multi-destination rua= supports common operational patterns: a primary internal ingestion mailbox plus a secondary SaaS analyzer; a primary HTTPS endpoint plus a backup mailbox; or one mailbox per team that owns a different aspect of the policy surface (security, deliverability, infrastructure).
Common pitfall: using a semicolon (the tag separator) where the comma (the URI-list separator) is required — TLS-RPT parsers treat the second URI as a new tag, not as a second value of rua=. The result is silently malformed.

; Correct — comma-separated URI list:
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt"

; Correct — three destinations:
"v=TLSRPTv1; rua=mailto:team-a@example.com,mailto:team-b@example.com,https://reports.example.com/tlsrpt"

; Wrong — semicolon between URIs (parser treats as malformed):
"v=TLSRPTv1; rua=mailto:tlsrpt@example.com; https://reports.example.com/tlsrpt"

8. Cross-domain authorisation record (_report._smtp._tls)

Where: when the rua= URI points at an external domain (different from the recipient domain publishing the TLS-RPT record), that external domain MUST publish an authorisation record at <recipient-domain>._report._smtp._tls.<external-domain> containing v=TLSRPTv1. Per RFC 8460 §3.
Why: the authorisation record prevents abuse where an attacker publishes a TLS-RPT record pointing rua= at a victim's mailbox to flood that mailbox with spam-like report deliveries. The authorisation record is the external domain's explicit "yes, I accept TLS-RPT reports for this recipient" consent.
Operational rule: for every (recipient-domain, external-destination-domain) pair, the destination domain publishes <recipient>._report._smtp._tls.<external> with v=TLSRPTv1. The recipient domain (the one being reported on) does NOT publish this record — the destination domain does. Each authorisation record covers a single recipient.
Common pitfall: deploying a third-party SaaS analyzer as the rua= destination but forgetting to coordinate with the SaaS provider to publish the authorisation record. Senders that respect the RFC 8460 §3 authorisation requirement refuse to deliver reports cross-domain without the authorisation record — so the recipient operator sees zero reports despite a syntactically correct TLS-RPT record. Always confirm the SaaS provider has published the authorisation record for your recipient domain.

; Recipient domain example.com publishes its TLS-RPT record
; pointing at a SaaS analyzer at reports.analyzer.example:
_smtp._tls.example.com.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@reports.analyzer.example"

; SaaS analyzer at reports.analyzer.example must publish the
; authorisation record consenting to receive reports for example.com:
example.com._report._smtp._tls.reports.analyzer.example.   IN  TXT  "v=TLSRPTv1"

; If the SaaS analyzer accepts reports for ten customer domains,
; it publishes ten distinct authorisation records — one per
; (customer-domain)._report._smtp._tls.reports.analyzer.example.

The authorisation pattern is structurally identical to the DMARC rua= cross-domain authorisation defined by RFC 7489 §7.1 (the _report._dmarc.<external> record), so operators familiar with the DMARC mechanism will recognise the shape immediately.

9. The 255-octet character-string limit (RFC 1035 §3.3.14)

Constraint: the DNS TXT record character-string limit is 255 octets per character-string, not per TXT record. A TXT record can contain multiple character-strings concatenated by the resolver at lookup time.
Why: the RFC 1035 §3.3.14 encoding of a TXT character-string uses a single octet for the length prefix, capping each string at 255 octets. A longer logical value (rare in TLS-RPT, common in DKIM where 2048-bit keys exceed 255 chars) MUST be split across multiple quoted strings.
Operational rule: most TLS-RPT records are short (a single mailto: URI keeps the total well under 100 octets). Long multi-destination rua= values that exceed 255 octets MUST be split into adjacent quoted strings with no space, comma, or continuation marker between them. The resolver concatenates them transparently.
Common pitfall: a DNS UI that accepts the long rua= value as a single string and silently truncates at the 255-octet boundary. The record will exist but senders will parse a malformed URI and either fail to deliver reports or deliver to a truncated destination. Verify with dig +short _smtp._tls.example.com TXT and confirm the full value resolves.

; Short rua= (single string, no chunking needed):
_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Long rua= (multi-destination — split across quoted strings):
_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com,"
                                  "mailto:secondary@example.com,"
                                  "https://reports.example.com/tlsrpt-endpoint-with-long-path"

10. Canonical examples

Example 1 — minimal record (single mailto: destination):

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

Example 2 — single https: destination:

"v=TLSRPTv1; rua=https://reports.example.com/tlsrpt"

Example 3 — multi-destination (mailto: + https:):

"v=TLSRPTv1; rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt"

Example 4 — cross-domain rua= (with the partner authorisation record):

; Recipient domain — TLS-RPT pointing at a SaaS analyzer:
_smtp._tls.example.com.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@reports.analyzer.example"

; SaaS analyzer — authorisation record consenting to receive
; reports for example.com:
example.com._report._smtp._tls.reports.analyzer.example.   IN  TXT  "v=TLSRPTv1"

Example 5 — subdomain coverage (apex + mail subdomain, each with its own record):

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

; Mail subdomain with its own MX RR — separate TLS-RPT record:
_smtp._tls.mail.example.com.   IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

Example 6 — combining TLS-RPT with the parallel MTA-STS record (two distinct DNS records, two different jobs):

; MTA-STS policy ID — triggers senders to fetch the policy file:
_mta-sts.example.com.   IN  TXT  "v=STSv1; id=20260522T120000Z"

; TLS-RPT reporting destination — independent from the MTA-STS record:
_smtp._tls.example.com. IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"

; Both records SHOULD be deployed together — see help_mta_sts_explained.php
; for the MTA-STS deep dive and help_tls_rpt_explained.php for the report
; format reference.

11. Common operator mistakes

Ten canonical syntactic drift classes, enumerated as a punch list. Every one results in the record being silently ignored or misparsed by conformant senders, with no operator-visible error signal.

1. Lowercase v=tlsrptv1 — RFC 8460 specifies the value as case-sensitive TLSRPTv1. Strict senders reject any other case.
2. Wrong record location — publishing at smtp._tls.example.com (missing leading underscore on _smtp) or _smtp.tls.example.com (missing leading underscore on _tls). The three-label _smtp._tls.<domain> name is the only valid location.
3. Missing rua= tag — the record is structurally valid but operationally inert. Always include at least one rua= destination.
4. Two rua= tags — use a single rua= with comma-separated values. Multiple rua= tags produce undefined parser behaviour.
5. Semicolon between rua= values — use the comma (URI-list separator), not the semicolon (tag separator).
6. Missing scheme prefix — write rua=mailto:tlsrpt@example.com not rua=tlsrpt@example.com; write rua=https://reports.example.com/tlsrpt not rua=reports.example.com/tlsrpt. Bare addresses and bare hostnames are invalid.
7. Angle brackets around mailto: address — write rua=mailto:tlsrpt@example.com not rua=mailto:<tlsrpt@example.com>.
8. Plaintext http: — only https: is supported. Senders refuse to deliver to the plaintext scheme because TLS-failure metadata should not transit in the clear.
9. Cross-domain rua= without authorisation record — the external destination domain MUST publish <recipient>._report._smtp._tls.<external> with v=TLSRPTv1. Without it, senders refuse to deliver reports.
10. Multiple TLS-RPT records at the same name — senders MAY pick any or treat the result as malformed. Publish exactly one record per _smtp._tls.<domain> name; list multiple destinations comma-separated in the single rua= value.

The Domain Security Checker surfaces drift classes 1, 2, 4, 9, and 10 via DNS lookups against the configured recipient domain.

12. Frequently asked questions

Is the v=TLSRPTv1 tag mandatory in a TLS-RPT TXT record?

Yes. RFC 8460 section 3.2 specifies that v=TLSRPTv1 is the version identifier and MUST appear first in the record. A record without v=TLSRPTv1 is silently ignored by every conformant sender — there is no default-assumption behaviour analogous to DKIM where the receiver assumes v=DKIM1 if missing. The value is case-sensitive uppercase TLSRPTv1; receivers that strictly enforce the case will reject v=tlsrptv1 or v=TLSRPT or v=tlsrpt as malformed. The canonical action: always publish v=TLSRPTv1 as the first tag. The forward-compatibility hook is in place — future TLS-RPT versions (if specified) would use v=TLSRPTv2 or later — but as of 2026 no later version has been published and TLSRPTv1 remains the only valid value.

Can I point rua= at a mailto: address in another domain?

Yes, but the external domain MUST publish a cross-domain authorisation record before any conformant sender will deliver reports there. RFC 8460 section 3 requires the destination domain to publish a TXT record at <recipient-domain>._report._smtp._tls.<external-domain> containing v=TLSRPTv1. For example, if example.com publishes rua=mailto:tlsrpt@reporter.example, then reporter.example must publish a TXT record at example.com._report._smtp._tls.reporter.example with the value "v=TLSRPTv1" to authorise reporter.example to receive TLS-RPT reports on behalf of example.com. Without that authorisation record, senders SHOULD refuse to deliver — preventing abuse where an attacker publishes a TLS-RPT record pointing at a victim mailbox. The authorisation pattern is structurally identical to the DMARC rua= cross-domain authorisation defined by RFC 7489 section 7.1 (the _report._dmarc.<external> record), so operators familiar with the DMARC mechanism will recognise the shape.

What URI schemes does rua= support in TLS-RPT?

Two schemes are defined by RFC 8460 section 3.3: mailto: and https:. With mailto:, the sender delivers the JSON report as an email attachment to the named mailbox; the MIME type is application/tlsrpt+json (or application/tlsrpt+gzip when gzip-compressed) and the filename follows the convention <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz]. With https:, the sender HTTP POSTs the JSON document to the named URL with Content-Type: application/tlsrpt+json and a 2xx response indicating successful delivery. Multiple destinations can be comma-separated in a single rua= value to deliver to both schemes simultaneously: rua=mailto:tlsrpt@example.com,https://reports.example.com/tlsrpt. Other URI schemes (ftp:, file:, gopher:, mqtt:) are not defined and will be ignored by conformant senders.

Why is my TLS-RPT record being ignored even though it appears in DNS?

Five common causes. (1) Wrong publishing location: the record MUST be at _smtp._tls.<domain> with the leading underscore on both labels. Publishing at smtp._tls.<domain> or _smtp.tls.<domain> or tls.<domain> will not be discovered by senders. (2) Lowercase or misspelled v= value: RFC 8460 specifies v=TLSRPTv1 case-sensitively; v=tlsrptv1 or v=TLSRPT or v=TLSRPTV1 are invalid and the record is ignored. (3) Missing rua= tag: rua= is mandatory; a record with v=TLSRPTv1 but no rua= is technically syntactically valid but has no operational effect because there is no destination to deliver reports to. (4) Cross-domain rua= destination without the authorisation record at <recipient>._report._smtp._tls.<external>. (5) Multiple TXT records at the same name produce non-deterministic behaviour; some senders use the first, some the last, some treat as malformed. Use the Domain Security Checker to confirm the record resolves correctly and contains exactly one v=TLSRPTv1 record with a valid rua= destination.

Can I have two TLS-RPT TXT records at the same _smtp._tls name?

No. RFC 8460 section 3 specifies that if more than one TXT record exists at _smtp._tls.<domain>, senders MAY pick any one or treat the result as malformed and stop reporting. The practical posture: never publish two TLS-RPT records at the same name. If you need to send reports to multiple destinations, list them comma-separated within a single rua= value in a single record: rua=mailto:tlsrpt@team-a.example.com,mailto:tlsrpt@team-b.example.com,https://reports.example.com/tlsrpt. The most common cause of accidental dual-record publishing is an operator hand-editing the zone after a wizard already placed the record. Detect this with the Domain Security Checker (which queries multiple resolvers and surfaces any drift class) or with dig +short _smtp._tls.example.com TXT and confirming exactly one v=TLSRPTv1 line.

Do I need a TLS-RPT authorisation record for every reporting destination?

No — only for cross-domain destinations. If the rua= URI lives in your own domain (e.g., rua=mailto:tlsrpt@example.com when the record is at _smtp._tls.example.com), no authorisation record is needed. The authorisation requirement kicks in only when the destination domain differs from the recipient domain. The authorisation record is published in the destination domain (the one receiving the reports), not in the recipient domain (the one being reported on). For example, if example.com sends its TLS-RPT to a third-party SaaS analyzer at reports.analyzer.example, then analyzer.example must publish example.com._report._smtp._tls.analyzer.example with v=TLSRPTv1 to authorise receiving reports for example.com. Each (recipient-domain, destination-domain) pair requires its own authorisation record — if the SaaS analyzer accepts reports for ten customer domains, the SaaS analyzer publishes ten distinct authorisation records.

How does the 255-octet character-string limit affect TLS-RPT records?

TLS-RPT records are typically short — a record with one rua= destination is under 80 characters — so the 255-octet character-string limit (RFC 1035 section 3.3.14) rarely matters in practice. The limit applies per character-string, not per TXT record. A record that exceeds 255 octets (for example, a multi-destination rua= with five long URLs) MUST be split into multiple quoted strings in the zone file, with the strings adjacent and quoted separately: "v=TLSRPTv1; rua=mailto:a@example.com," "https://reports.example.com/tlsrpt,..." with no space, comma, or continuation marker between strings. The resolver concatenates them transparently at lookup time. If your DNS UI does not auto-chunk and silently truncates at the 255-octet boundary, the record will exist but be parsed as malformed by senders. Verify with dig TXT _smtp._tls.example.com and confirm the full string is returned.

Does TLS-RPT inherit to subdomains, or do I need a separate record per subdomain?

TLS-RPT does NOT inherit to subdomains. A record at _smtp._tls.example.com applies only to mail sent to addresses whose recipient domain is exactly example.com. If you accept mail at mail.example.com or sub.example.com, you MUST publish a separate _smtp._tls.mail.example.com or _smtp._tls.sub.example.com record. This is structurally different from DMARC, where the sp= tag and the np= tag let a parent-domain policy cover subdomains by default; TLS-RPT has no subdomain-policy hook. The operational discipline: enumerate every recipient domain that handles inbound SMTP (including the bare apex, every MX-bearing subdomain, and any vanity domains pointing at the same MX) and publish one TLS-RPT record per recipient domain. The Domain Security Checker tool helps surface inbound-mail subdomains that are missing TLS-RPT coverage.

What is the difference between the _smtp._tls record and the _mta-sts record?

They are two different DNS records with two different jobs. The _smtp._tls.<domain> TXT record (RFC 8460) advertises the TLS-RPT reporting destination — where senders should send aggregate JSON reports about their inbound SMTP TLS sessions. The _mta-sts.<domain> TXT record (RFC 8461) advertises the MTA-STS policy ID and triggers senders to fetch the actual MTA-STS policy file at https://mta-sts.<domain>/.well-known/mta-sts.txt. The two records are independent — you can deploy TLS-RPT without MTA-STS (you would receive reports about opportunistic-TLS sessions and DANE-validated sessions if any), and you can deploy MTA-STS without TLS-RPT (you would enforce TLS but have no visibility when senders fail to negotiate). The recommended deployment posture is to publish BOTH because MTA-STS enforce mode is invisible without TLS-RPT — an enforce policy failure causes mail to silently bounce with no operator-visible signal. Use help_mta_sts_explained.php for the MTA-STS deep dive.

Can I publish a TLS-RPT record but never receive any reports?

Yes, this is common during initial deployment for two reasons. First, sender support: TLS-RPT reports are emitted only by senders that have implemented RFC 8460 — currently Google Workspace, Microsoft 365, Yahoo, Comcast, and several large hosters. Senders that have not implemented TLS-RPT silently ignore your published record. So in a small inbound-mail-flow domain that receives mostly from non-supporting senders, the report volume can be near zero even with a syntactically correct record. Second, aggregation cadence: TLS-RPT reports are emitted once per 24-hour window per (sending-MTA, recipient-domain) pair; if you publish the record on a Monday morning, the first report may not arrive until 24-48 hours later. If after one week you still see no reports, verify with the Domain Security Checker that the record syntax is correct and that the rua= destination is reachable from outside your network (a misconfigured firewall blocking inbound HTTPS to the rua= URL is a common cause). Cross-domain rua= destinations also require the authorisation record (see FAQ above).

13. Related guides

• TLS-RPT explained — the protocol pillar — what TLS-RPT is, the JSON report format (RFC 8460 §4), the 13 canonical result-type values, the deployment workflow, the relationship to MTA-STS and DANE.
• Email security glossary — the TLS-RPT-RECORD-SYNTAX-AND- TRANSPORT-LAYER-VOCABULARY-RESOLVES-TO- CROSS-CLUSTER-EMAIL-SECURITY-TERMINOLOGY- HUB companion to this TLS-RPT record byte-syntax reference. Where THIS page documents the RFC 8460 §3 TLS-RPT TXT- record byte-syntax reference (the v=TLSRPTv1 version-stamp, the rua= mailto/HTTPS RUA- URI field, the _smtp._tls. <domain> subdomain publication-location), the email- security-glossary spoke is the cross- cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every TLS-RPT-record discussion structurally depends on at FOUR per-term vocabulary- resolution dimensions: (i) per- term transport-layer-vs-application-layer protocol-stack vocabulary canonical- definition reference — the glossary resolves the transport-layer- vs-application-layer protocol-stack boundary (TLS-RPT operates at the transport-layer parallel to SPF / DKIM / DMARC operating at the application-layer) without per-page re-definition; per- publisher operator cross-protocol-layer reasoning depends on consistent per-term protocol-stack vocabulary across every sibling MTA-STS / DANE / TLS-RPT / STARTTLS spoke; (ii) per-term opportunistic-TLS-and-downgrade-attack vocabulary canonical-definition reference — the glossary resolves opportunistic-TLS / StripTLS / MTA-MITM / downgrade-attack vocabulary per RFC 7672 / RFC 8461 / RFC 8460 so per-publisher operator per-receiver per- day TLS-RPT-failure-row threat-model decode preserves per-term attack-class semantics across every sibling transport-security / BEC-defense / attacker-bypass spoke; (iii) per- term per-failure-row result-type vocabulary canonical-definition reference — the glossary resolves per-failure-row vocabulary (certificate-host-mismatch, certificate- expired, certificate-not-trusted, sts- policy-invalid, sts-policy-fetch-error, tlsa-invalid, dnssec-invalid, sending-mta- ip, receiving-mx-hostname) per RFC 8460 §4.4 so per-publisher operator per- receiver per-day per-row evidence-decode preserves per-result-type semantics across every sibling TLS-RPT-report-format / TLS-RPT-troubleshooting spoke; (iv) per-term RUA-mailbox-and-RFC- 7489-rua-vocabulary cross-protocol coherence reference — the glossary resolves cross-protocol RUA- mailbox vocabulary (TLS-RPT RUA mailbox- capacity vs DMARC rua mailbox-capacity, per-receiver per-publisher per-day cadence, mailto-vs-HTTPS RUA-URI scheme choice, RUA-submission TLS-enforcement- scheme) so per-publisher operator cross- protocol RUA-mailbox coordination preserves per-term capacity-and-cadence semantics across every sibling DMARC-rua / TLS-RPT-rua / RUA-mailbox-design spoke.
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the operational deep dive on the JSON payload this byte-syntax page's _smtp._tls.<domain> TXT record causes receivers to send to the rua= URI. Where THIS page documents the TLS-RPT record's TXT-record-level byte syntax (the v=TLSRPTv1 version-tag floor, the rua= URI list with comma-separated mailto- and https-scheme members, the contact-tag family, the syntactic-validation rules for each token), the report-format page documents the byte-level structure of the REPORT PAYLOADS that arrive at that rua= URI: the RFC 8460 §4 JSON top-level object (organization-name, date-range, contact-info, report-id, policies), the policies[].policy object carrying policy-type (sts / tlsa / no-policy-found) + policy-string + policy-domain + mx-host, the policies[].summary with total-successful-session-count and total-failure-session-count, the policies[].failure-details array carrying per-failure result-type + sending-MTA + receiving-MX + failure-reason-code + timestamp + session-count, the canonical result-type values (starttls-not-supported / certificate-host-mismatch / certificate-expired / certificate-not-trusted / validation-failure / tlsa-invalid / dnssec-invalid / dane-required / sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid), the Content-Type/filename/MIME conventions and the gzip-vs-tlsrpt content-encoding contract, the redelivery semantics for bounced report sends, and the operator ingestion pipeline (mailbox capture → MIME-part extraction → gzip-decompress → JSON-schema validation → row-by-row ingestion). Read these two pages together as the complete byte-level reference set for the TLS-RPT cluster: this page tells you HOW receivers KNOW where to send the report, the report-format page tells you WHAT the report payload looks like once it arrives in your ingestion mailbox or webhook.
• MTA-STS explained — the natural deployment partner for TLS-RPT. MTA-STS enforces inbound TLS; TLS-RPT reports when enforcement fails.
• MTA-STS for Google Workspace (provider deployment) — the provider-specific MTA-STS deployment walkthrough whose publishing-side _mta-sts DNS record is the natural deployment partner for the _smtp._tls TXT record documented byte-by-byte on THIS page. Where this page covers the TLS-RPT TXT record syntax in protocol-agnostic terms, the Workspace MTA-STS spoke documents the operational deployment sequence on a Workspace tenant end-to-end: the aspmx.l.google.com / alt1-4.aspmx.l.google.com MX cluster enumeration in the policy file's mx: directive (or the single smtp.google.com entry for tenants migrated to the simplified MX configuration), the Workspace-aligned external HTTPS hosting options for the policy file (Firebase Hosting and Cloud Run for instant custom-domain HTTPS, Cloud Storage + Cloud CDN with Cloud Load Balancing for tenants with existing GCP infrastructure), the absence of any Admin Console / Postmaster Tools MTA-STS panel, and the testing-mode burn-in workflow paired with the TLS-RPT DNS record this page documents. Read this when authoring the TLS-RPT TXT record FOR a Workspace tenant — the rua= destination on THIS page's TXT record is what receives the TLS-RPT failure samples for the MTA-STS policy that Workspace spoke walks through deploying. The two records are routinely published in the SAME zone-file commit (the discovery + reporting DNS pair) and share the same TTL discipline.
• MTA-STS for Microsoft 365 (provider deployment) — the provider-specific MTA-STS deployment walkthrough whose publishing-side _mta-sts DNS record is the natural deployment partner for the _smtp._tls TXT record documented byte-by-byte on THIS page. Where this page covers the TLS-RPT TXT record syntax in protocol-agnostic terms, the M365 MTA-STS spoke documents the operational deployment sequence on an Exchange Online tenant end-to-end: the <tenant>-com.mail.protection.outlook.com MX target enumeration in the policy file's mx: directive (where <tenant>-com is the dashed transformation of your accepted domain), the M365-aligned external HTTPS hosting options for the policy file (Azure Static Web Apps and Azure Front Door for tenants standardised on Azure, Cloudflare Pages or Cloudflare Workers with custom-hostname HTTPS, AWS S3 + CloudFront, GitHub Pages with custom-domain Let's Encrypt — Microsoft 365 does NOT host the policy file natively), the absence of any Defender-portal / Exchange Admin Center MTA-STS panel, the testing-mode burn-in workflow paired with the TLS-RPT DNS record this page documents, and the hybrid-tenant MX-cutover discipline. Read this when authoring the TLS-RPT TXT record FOR an M365 tenant — the rua= destination on THIS page's TXT record is what receives the TLS-RPT failure samples for the MTA-STS policy that M365 spoke walks through deploying. The two records are routinely published in the SAME zone-file commit (the discovery + reporting DNS pair) and share the same TTL discipline. Note that for an M365 tenant the TLS-RPT TXT record carries especially high operational weight: M365's protection.outlook.com MX cluster does NOT publish TLSA records, so MTA-STS is the ONLY TLS-enforcement option inbound — and TLS-RPT is the ONLY observability channel for whether senders are honoring it.
• MTA-STS policy file syntax (RFC 8461 §3.2) — the MTA-STS-side byte-syntax sibling across the joint TLS-RPT + MTA-STS deployment surface. Where this page documents the _smtp._tls.<domain> TXT-record-level rules for the TLS-RPT reporting destination, the MTA-STS policy-syntax page documents the byte-level rules for the OTHER half of the joint deployment: the /.well-known/mta-sts.txt policy file the _mta-sts.<domain> TXT record points at. Read these two pages together as the complete byte-level reference set for joint TLS-RPT + MTA-STS deployment: the four canonical keys (version: STSv1, mode enforce/testing/none case-sensitive enum, mx: with single-label wildcard semantics, max_age: in seconds), the no-BOM constraint (UTF-8 BOM silently breaks the version line match — the #1 silent-rejection cause), the no-comments rule, the _mta-sts DNS id-token coupling with the policy-file id: rotation contract, and the ten common operator mistakes that cause the very TLS-RPT failure-types operators ingest via this page's record (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-host-mismatch). TLS-RPT without an MTA-STS policy is a report channel for opportunistic-TLS sessions only; the policy-syntax page is the operational reference for the enforcement layer that produces the report payloads this page's record delivers.
• MTA-STS vs DANE for SMTP — the policy-mechanism decision view between the two SMTP TLS enforcement models; TLS-RPT covers both.
• DANE for SMTP — the TLSA-record-based TLS enforcement model. TLS-RPT reports DANE-validated sessions alongside MTA-STS-validated ones.
• DNS propagation explained — the TLS-RPT-RECORD-PUBLICATION- PROPAGATION-WINDOW-FOR-FIRST-REPORTER- QUERY companion reference. Where THIS page documents the byte-level rules for publishing the _smtp._tls.<domain> TXT record (the v=TLSRPTv1 version-tag floor, the rua= URI list with mailto- and https-scheme members, contact-tag family, syntactic-validation rules), the DNS-propagation spoke documents the STRUCTURAL TIMING-MODEL that governs WHEN the operator who has just published a syntactically-valid TLS-RPT record will actually begin receiving the JSON reports the record is the publication-side trigger for: TLS-RPT report emission is RECEIVER- SIDE work performed by external sender-MTAs (each Internet sender that encountered a TLS error during SMTP delivery to the operator's MX inventory in the prior 24-hour reporting period queries the operator's _smtp. _tls TXT record at report-emit time to discover the rua= destination), which means a sender's recursive resolver cache containing a prior NXDOMAIN result (because the operator had not yet published the TXT) will not be revalidated until that cache entry ages out per the negative-cache TTL (RFC 2308 — typically 3600s but can be up to the SOA minimum field's value, often 86400s for legacy-defaulted zones). The implication: the operator who publishes a TLS-RPT record and expects to see reports flowing within the first 24 hours often observes a 2-3 day silent window before the first reports arrive — not because the publication was mis-syntaxed but because the negative-cache TTL on the sender-side recursive resolvers bounds the first-query window. The DNS-propagation spoke documents the canonical TTL-tuning recommendations that shorten this window (publish the TXT BEFORE rolling MTA-STS deployment so the negative-cache window expires in advance of the first TLS-error report-generation event; pre-shorten the SOA minimum field to 300s on the parent zone before first-time TLS-RPT publication) and the operator-verification workflow (dig +nocache + multi-resolver cross-checks via Google Public DNS / Cloudflare / Quad9 to confirm propagation has reached the major-receiver-side resolver populations). Read the DNS-propagation spoke alongside this page when scoping the first-time TLS-RPT publication or any rua= destination change — the silent-window timing the propagation spoke documents is often misread as a TLS-RPT publication-bug when it is in fact the structural negative-cache TTL behaviour of the open-Internet DNS resolver cohort.
• SPF DNS record syntax — the SPF-side byte-syntax sibling. TXT-record-level rules for v=spf1.
• DKIM DNS record syntax — the DKIM-side byte-syntax sibling. TXT-record-level rules for the DKIM public-key TXT record at <selector>._domainkey.<domain>.
• DMARC record tags explained — the DMARC-side byte-syntax sibling. TXT-record-level rules for the DMARC TXT record at _dmarc.<domain>.
• DMARC reporting pipeline (RUA/RUF end-to-end flow) — the TRANSPORT-LAYER-TLS-RPT-RUA-VS- APPLICATION-LAYER-DMARC-RUA-PIPELINE- PARALLEL companion to this TLS-RPT TXT-record byte-syntax reference. Where THIS page documents the _smtp._tls.<domain> TXT-record publisher-side authoring contract (RFC 8460 §3.1: v=TLSRPTv1; rua=mailto:rua@example .com / https://<collector> at the canonical owner-name with version token and report-recipient list grammar), the DMARC-reporting-pipeline spoke is the PARALLEL-AGGREGATE-REPORT-PIPELINE companion documenting how DMARC's own application-layer RUA aggregate-report pipeline operates at the _dmarc.<domain> owner-name with structurally-identical rua=mailto:<collector> grammar yet ORTHOGONAL failure-class coverage: (i) both pipelines share the same author-domain-to- collector-mailbox RUA dispatch contract — the TLS-RPT publisher and DMARC publisher both configure a mailto: or https: URL where major receivers send the aggregate report (with the cross-organisation external-destination opt-in dance via the _report._dmarc / equivalent TLS-RPT cross-domain authorization record); (ii) the two pipelines observe ORTHOGONAL failure classes — TLS-RPT observes SMTP-handshake TLS failures (cert-expired, name-mismatch, no-tls, weak-cipher, MTA-STS policy violation, DANE TLSA mismatch) at the SMTP transport layer, while DMARC RUA observes per-source-IP-and-disposition message-authentication outcomes (spf= / dkim=results, alignment evaluation, disposition application of p=/sp=/pct=) at the application message-authentication layer — neither pipeline's failure rows show up in the other's reports; (iii) operator deployment posture is the same per- pipeline aggregation rhythm — both publish a TXT record at a well-known owner-name with a version token and a report-recipient rua= list, expect daily aggregate reports from major receivers, normalize the per-pipeline JSON / XML payload into the operator analytics surface, and apply the same receiver-side aggregation-window discipline (typically 24-hour windows per RFC 7489 §7.2.1 / RFC 8460 §3 for DMARC and TLS-RPT respectively); (iv) both pipelines anchor a rolling-window deliverability observability posture — TLS- RPT reports surface transport-layer degradation early enough to remediate before SMTP-strict policies start bouncing; DMARC RUA surfaces authentication-layer degradation early enough to remediate before p=quarantine / p=reject policy violations accumulate. Read the reporting-pipeline spoke alongside this TLS-RPT TXT-record reference when designing the unified rolling- window deliverability observability posture that must integrate BOTH transport-layer TLS-RPT and application-layer DMARC RUA aggregate-report intake into the operator's downstream analytics surface — the reporting-pipeline spoke is the canonical application- layer-RUA-end-to-end-flow reference; THIS page is the canonical TLS-RPT- record-publication-side companion whose orthogonal-failure-class TXT- record authoring discipline the unified observability posture must layer atop the DMARC RUA pipeline at the _dmarc.<domain> owner-name.
• CAA records explained — the PER-DOMAIN-PUBLIC-PKI-CA-ISSUANCE- RESTRICTION-PUBLICATION-DISCIPLINE-AS- UPSTREAM-CONTROL-ON-TLS-CERT-PROCUREMENT- WHOSE-FAILURE-OUTCOMES-THIS-TLS-RPT- OBSERVABILITY-PIPELINE-CAPTURES companion to this TLS-RPT DNS record syntax reference. Where THIS page documents the per-publisher per-domain TLS-RPT-RR byte-syntax discipline (the _smtp._tls.<domain> owner-name, the v=TLSRPTv1 version tag, the rua=mailto: / rua=https: failure-report endpoint publication discipline, the per-failure-type JSON-report shape the receiver emits) at the transport-security observability publication-discipline surface, the CAA-records-explained spoke is the STRUCTURALLY-PARALLEL per-domain PKI-issuance-restriction publication- discipline reference whose RFC 8659 CAA-RR primitive at <domain> CAA-RR scope is the load-bearing UPSTREAM control-publication-discipline whose misconfiguration drives the downstream TLS-cert-procurement failure outcomes the TLS-RPT-JSON failure-report stream observes. The CAA-vs-TLS-RPT cross- layer transport-security publication- discipline coupling establishes four specific upstream-control-to-downstream- observability dimensions: (i) per- publisher per-domain DNS-RR publication primitive parallel — TLS-RPT publishes _smtp._tls.<domain> TXT-RR per RFC 8460 §3 + CAA publishes <domain> CAA-RR per RFC 8659; both publisher-side per- domain DNS-RR publication primitives rooted in the publisher's per-domain DNS zone the operator already operates; (ii) cross-layer transport- security control-stack member- complement — CAA is the per- domain TLS-cert-procurement upstream- publication-discipline gate (the receiver TLS cert at mta-sts.<domain> HTTPS endpoint MUST be issued by a CA listed in the publisher's CAA issue tag list per CA/ Browser Forum Baseline Requirements); TLS-RPT is the receiver-side TLS- failure observability publication- discipline; both are publisher-side transport-security control-stack members at structurally-distinct cross-layer publication boundaries (CAA at PKI-issuance-layer + TLS-RPT at observability-layer); (iii) per-publisher CAA- misconfiguration failure-class is directly TLS-RPT-observed — when the operator publishes a CAA issue "ca-x.example" tag listing CA-X but the mta-sts.<domain> host TLS-cert was issued by CA-Y (because the CAA-RR was added AFTER the cert was procured at CA-Y), per- publisher mta-sts.<domain> HTTPS-endpoint TLS-cert renewal silently breaks at CA-Y refusal — the TLS-RPT-JSON failure-report stream THIS page documents captures the downstream "result-type": "sts-policy-fetch-error" + "result-type": "certificate-not-trusted" failure-types per RFC 8460 §4.3 as the load-bearing per-publisher per- receiver observability signal whose root-cause traces directly to the upstream CAA-publication-discipline regression; (iv) per- publisher CAA + TLS-RPT publication- discipline lifecycle coordination discipline — per-publisher CAA additions/removals MUST be sequenced with per-MX-host + per- mta-sts-host cert-renewal cadence (otherwise CA-issuance-refusal cascades into MTA-STS rollout regression and per-MX-host STARTTLS-cert-expiry); per-publisher TLS-RPT-JSON failure-report stream is the per-publisher observability instrument that detects the regression at the per-receiver per- publisher per-failure-type aggregate-JSON-report granularity. Read the CAA spoke alongside this TLS-RPT record-syntax reference when the per-publisher per-domain DNS-RR publication discipline documented here at the _smtp._tls.<domain> TLS-RPT-RR observability surface needs to be composed with the per-publisher per-domain CAA-RR publication discipline at the upstream PKI-issuance-layer control surface to constitute the complete per-publisher transport-security cross-layer publication-discipline stack the per-receiver per-failure- type TLS-RPT-JSON observability pipeline structurally consumes.
• Email authentication overview — the SPF/DKIM/DMARC/BIMI/MTA-STS/TLS-RPT/CAA whole-cluster intro.
• DMARC help hub — the canonical entry point covering DMARC and the full email-authentication cluster.
• DKIM for Google Workspace — the GOOGLE-WORKSPACE-TENANT-MESSAGE- LAYER-DKIM-AT-google-DOMAINKEY-DIRECT-TXT- RR-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- MESSAGE-LAYER-COMPLEMENT-TO-PER-WORKSPACE- TENANT-TRANSPORT-LAYER-TLS-RPT-AT-_smtp._tls- OWNER-NAME-PUBLICATION-DISCIPLINE companion to this TLS-RPT TXT-record reference. Where THIS page documents the transport- layer TLS-RPT TXT-record byte-syntax (the v=TLSRPTv1; rua=mailto:<mailbox> publication grammar, the per-receiver per-day per-MX-host per-failure-class JSON- report emission discipline per RFC 8460 §3.1, the publisher-controlled rua mailbox + HTTPS-endpoint observability collection surface), the dkim-for-google-workspace spoke is the STRUCTURALLY-PARALLEL message- layer publication-discipline reference whose WORKSPACE-tenant DKIM-publication at google._domainkey.<d> direct TXT-RR is the load-bearing message- layer message-authentication-publication complement to the transport-layer TLS- handshake-observability-publication THIS page documents, composing the per-Workspace- tenant per-domain complete-cross-layer publication-discipline stack at four Workspace-tenant cross-layer coupling dimensions: (i) Workspace per- tenant per-domain DNS-RR publication primitive parallel — both message- layer DKIM at google._domainkey.<d> TXT-RR and transport-layer TLS-RPT at _smtp._tls.<d> TXT-RR publish per-publisher publication discipline via the SAME DNS-RR publication primitive the publisher's per-domain DNS zone already operates; both records require operator- side per-tenant DNS-zone-management discipline at the Workspace tenant's per-domain DNS zone (NOT at Microsoft- managed onmicrosoft.com hostnames as M365 does for DKIM via CNAME- pointer indirection); (ii) Workspace per-message DKIM-pass + per-receiver per- MX-host TLS-pass cross-layer composition — the per-message message-layer DKIM-aligned- pass verdict the Workspace google._domainkey.<d> publication produces composes with the per-receiver per-MX-host transport-layer TLS-handshake-success-rate the _smtp._tls.<d> publication observes — together they constitute the per-Workspace-tenant per-domain complete- publication-coverage the Gmail+Yahoo Bulk Sender Requirements 2024 compliance gate evaluates at the per-publisher per-receiver per-message gate-boundary; (iii) Workspace operator-side publication- discipline parallel — Admin Console DKIM vs DNS zone TXT-RR TLS-RPT — the Workspace operator publishes DKIM via the Admin Console's "Generate new record" wizard (which auto-populates the google._domainkey.<d> TXT-RR content); the operator publishes TLS-RPT via direct DNS zone editing at _smtp._tls.<d>; both publication paths constitute the per- Workspace-tenant per-domain operator- responsibility surface that's STRUCTURALLY DISTINCT from the M365-tenant operator- responsibility surface (where DKIM is via Defender portal + CNAME pointer); (iv) Workspace cross-layer publication- discipline-stack completion — DKIM + DMARC + SPF + MTA-STS + TLS-RPT — the per-Workspace-tenant per-domain complete cross-layer publication-discipline stack composes message-layer (DKIM at google._domainkey.<d> + DMARC at _dmarc.<d> + SPF at <d> apex TXT-RR including _spf.google.com) with transport-layer (MTA-STS policy-host at mta-sts.<d> + TLS-RPT at _smtp._tls.<d> which THIS page documents); without the message-layer DKIM-publication-discipline the dkim-for-google-workspace spoke documents, the per-Workspace-tenant per- message DMARC-aligned-pass verdict the transport-layer TLS-handshake-success-rate observability surface depends on is defeated upstream at the message- authentication-evaluation boundary. Read the dkim-for-google-workspace spoke ALONGSIDE this TLS-RPT-record-syntax reference whenever the protected domain is hosted on the Google Workspace cloud tenant and the per-Workspace-tenant per-domain cross-layer publication- discipline stack the transport-layer TLS- RPT publication THIS page documents needs a Workspace-tenant message-layer DKIM- publication baseline.
• MX records explained — the PER-PUBLISHER-PER-DOMAIN-MX-RR- INVENTORY-AS-LOAD-BEARING-FAILURE-ROW- ATTRIBUTION-KEY-IN-PER-PUBLISHER-PER- DOMAIN-TLS-RPT-JSON-REPORT companion to this TLS-RPT DNS record reference. Where THIS page documents the per-publisher per-domain TLS-RPT _smtp._tls. <domain> IN TXT "v=TLSRPTv1; rua= mailto:tls-rpt@<domain>" TXT-RR publication-discipline reference, the MX-records spoke is the canonical RFC 5321 §5.1 MX-RR primitive reference documenting the per-publisher per-domain MX-RR inventory that ITSELF IS the load- bearing per-publisher per-domain attribution-key set the downstream RFC 8460 §4 TLS-RPT JSON-report policies[].policy.mx-host[] and policies[].failure-details[] .receiving-mx-hostname per- failure-row field-set is keyed against at four per-MX-inventory-to-TLS-RPT- failure-row-attribution coupling dimensions: (i) per-publisher per-domain MX-RR-inventory as load- bearing per-publisher per-domain TLS-RPT JSON-report policies[].policy.mx- host[] per-policy-block per-MX- host-list inclusion-set — every per-publisher per-domain TLS-RPT JSON report's policies[].policy.mx- host[] per-policy-block per-MX- host-list inclusion-set is keyed against the per-publisher per-domain MX-RR- inventory the MX-records spoke documents the publication-discipline of; the per- publisher per-domain TLS-RPT JSON-report consumer (per-publisher per-day per-MX- host transport-layer encryption-failure attribution workflow) cannot resolve per-failure-row attribution WITHOUT the per-publisher per-domain MX-RR inventory the MX-records spoke documents the publication-discipline of; (ii) per-publisher per-domain MX-RR- inventory as load-bearing per-publisher per-domain TLS-RPT JSON-report policies[].failure-details[] .receiving-mx-hostname per- failure-row attribution-key — every per-publisher per-domain TLS-RPT JSON report's policies[].failure- details[] per-failure-row receiving-mx-hostname field- value IS keyed against the per-publisher per-domain MX-RR inventory THIS page's TLS-RPT TXT-RR publication ingests TLS- RPT JSON reports about; the per-publisher per-day per-receiving-MX-hostname transport-layer encryption-failure-stream attribution workflow the per-publisher per-domain TLS-RPT TXT-RR publication gates is keyed against the per-publisher per-domain MX-RR inventory the MX- records spoke documents the publication- discipline of; (iii) per- publisher per-domain MX-RR-inventory- rollover as load-bearing per-publisher per-day TLS-RPT JSON-report attribution- boundary-disambiguation trigger — every per-publisher per-domain MX-RR-inventory rollover (per-publisher MX-RR replacement / primary-to-fallback per-MX-host failover during multi-region active-active deployment cycle) produces a per- publisher per-day per-MX-host TLS-RPT JSON-report attribution-boundary- disambiguation event the per-publisher per-domain TLS-RPT JSON-report ingestion-workflow MUST resolve against the per-publisher per-domain MX-RR rollover-window the MX-records spoke documents the publication-discipline of; (iv) per-publisher per-domain MX-RR-inventory-vs-per-publisher-per- domain-MTA-STS-policy-file-mx-directive- divergence as load-bearing per-publisher per-day TLS-RPT JSON-report failure-row- emergence trigger — every per- publisher per-domain MX-RR-inventory-vs- per-publisher-per-domain-mta-sts.txt- mx:-directive list divergence (per-publisher MX-RR rolls forward to new MX-host but per-publisher mta-sts.txt mx:-directive list still lists retired MX-host) IS the load-bearing per-publisher per-day per- sender per-recipient-MX-host TLS-RPT JSON-report failure-details[] .result-type = certificate- not-trusted / certificate-host-mismatch / sts-policy-fetch-error failure-row-emergence trigger every per-publisher per-domain TLS-RPT JSON- report ingestion-workflow keyed against the per-publisher per-domain MX-RR inventory the MX-records spoke documents the publication-discipline of captures. Read the MX-records spoke ALONGSIDE this TLS-RPT DNS record reference whenever a per-publisher per- domain per-day per-receiving-MX-hostname transport-layer encryption-failure- stream attribution question emerges — THIS page gives the per-publisher per- domain TLS-RPT TXT-RR publication- discipline gating per-day JSON-report- ingestion, the MX-records spoke gives the canonical per-publisher per-domain MX-RR-publication-and-inventory- rollover-discipline EVERY per-failure- row attribution-key in the TLS-RPT JSON- report-stream is keyed against.
• SPF for Google Workspace — the PER-WORKSPACE-TENANT- APPLICATION-LAYER-SPF-PUBLICATION- AS-LOAD-BEARING-CROSS-LAYER-DNS- RECORD-PUBLICATION-DISCIPLINE- COMPANION-TO-PER-WORKSPACE-TENANT- TRANSPORT-LAYER-TLS-RPT-RECORD- PUBLICATION companion to this TLS- RPT TXT-record byte-syntax reference. Where THIS page documents the per- publisher per-domain _smtp._tls.<org-domain> TLS-RPT TXT-record byte-grammar (the v=TLSRPTv1 version- prefix, the rua=mailto:<rua- mailbox> emission-target field, the rua=https://<rua- endpoint> HTTPS-endpoint alternative, the 255-octet character- string-fragmentation rule, the underscore-prefixed owner-name convention per RFC 8552), the spf_ for_google_workspace spoke documents the structurally-parallel APPLICATION- LAYER per-Workspace-tenant SPF TXT-record byte-grammar publication at FOUR Workspace-tenant cross- layer-DNS-record-publication- coupling dimensions: (i) per- Workspace-tenant include:_spf.google.com SPF-include-cascade APPLICATION- LAYER per-domain published-policy primitive AS LOAD-BEARING SIBLING- DNS-PUBLICATION-DISCIPLINE TO per- Workspace-tenant _smtp._tls.<org-domain> TLS-RPT TXT-record TRANSPORT-LAYER per-domain published-policy primitive — both are per- Workspace-tenant per-DNS-record publication-discipline primitives the Workspace operator must coordinate; the spf_for_google_ workspace spoke documents the APPLICATION-LAYER per-tenant DNS- record publication-discipline the same per-tenant publication- discipline operators master for TLS-RPT TXT-record publication transfers directly to; (ii) per-Workspace-tenant include:_spf.google.com SPF-include-cascade RFC 7208 §4.6.4 ten-DNS-lookup ceiling CONSTRAINT AS STRUCTURAL-PARALLEL TO per-Workspace- tenant TLS-RPT TXT-record 255-octet character-string-fragmentation CONSTRAINT THIS page documents — Workspace's per-tenant include:_spf.google.com cascade itself consumes 3-5 of the ten-DNS-lookup ceiling budget, structurally paralleling how the TLS-RPT TXT-record byte-budget is bounded by the 255-octet character- string-fragmentation rule; the spf_ for_google_workspace spoke documents the per-tenant APPLICATION-LAYER publication-budget discipline whose preservation parallels the per- tenant TRANSPORT-LAYER TLS-RPT TXT-record publication-budget discipline THIS page documents at the per-Workspace-tenant publication-discipline boundary; (iii) per-Workspace-tenant SPF-include-cascade per-source-IP AUTHORIZATION-FAILURE-EVIDENCE- EMITTED-IN-DMARC-RUA-AGGREGATE- REPORTS AS APPLICATION-LAYER OBSERVABILITY-FEEDBACK-LOOP PARALLEL TO per-Workspace-tenant _smtp._tls TXT-record-emitted TLS-RPT JSON- AGGREGATE TRANSPORT-LAYER OBSERVABILITY-FEEDBACK-LOOP THIS page documents — both per- Workspace-tenant published DNS records produce per-publisher receiver-side observability streams (DMARC-RUA for SPF/DKIM verdict evidence, TLS-RPT-RUA for STARTTLS- handshake-failure evidence); the spf_for_google_workspace spoke documents the APPLICATION-LAYER observability-feedback-loop whose per-publisher-emitted per-day per- receiver per-source-IP attribution- key set structurally parallels the TRANSPORT-LAYER per-publisher per- day per-receiver per-MX-host attribution-key set the TLS-RPT-RUA emits; (iv) per-Workspace- tenant SPF-include-cascade DNS- record-publication propagation- window AS STRUCTURAL-PARALLEL TO per-Workspace-tenant _smtp._tls TLS-RPT- record-publication propagation- window THIS page documents — both per-Workspace-tenant published DNS records propagate through the same resolver-cache- aging model (RFC 1035 + RFC 2181 + RFC 8767 serve-stale) the Workspace operator must coordinate; the spf_for_google_workspace spoke documents the per-Workspace-tenant SPF-publication propagation-window whose structural parallel to the TLS-RPT-publication propagation- window THIS page documents is the canonical per-tenant cross-layer DNS-record-publication-propagation- coordination pattern. Read the spf_ for_google_workspace spoke alongside this TLS-RPT TXT-record byte-syntax reference whenever the Workspace-tenant operator scopes a per-tenant cross-layer DNS- publication-discipline plan — the per-Workspace-tenant SPF-include- cascade publication-discipline the spoke catalogues IS the APPLICATION- LAYER sibling-DNS-publication- discipline primitive that runs ALONGSIDE the per-Workspace-tenant _smtp._tls TLS-RPT TXT-record publication-discipline THIS page documents at the cross- protocol per-Workspace-tenant DNS- publication-discipline boundary.
• DNS record generator — generate the _smtp._tls TXT record interactively (Enterprise tier).
• Domain Security Checker — validate the live TLS-RPT record from multiple geographic resolvers; surfaces every drift class documented above.
• Email Header Analyzer — parse the Authentication-Results header to cross-check inbound-message TLS-RPT signals.
• SPF qualifiers explained — the CROSS-LAYER-PARALLEL-PER-PUBLISHER- DNS-PUBLISHED-TXT-RECORD-TOKEN-BYTE-SHAPE- AUTHORING-DISCIPLINE companion reference. Where THIS page documents the per-publisher TLS-RPT TXT-record byte-shape at the transport-reporting layer (the v=TLSRPTv1 version-stamp tag, the rua= mailto/HTTPS RUA-URI field, the _smtp._tls.<domain> owner-name publication location per RFC 8460 §3), the SPF-qualifiers-explained spoke documents the STRUCTURALLY-PARALLEL per- publisher DNS-published TXT-record byte- shape at the application layer (the four canonical mechanism-prefix qualifier bytes + Pass / - Fail / ~ SoftFail / ? Neutral per RFC 7208 §4.6.2 that prefix every SPF mechanism token in the v=spf1 TXT-record at the apex <org-domain> owner-name) across four cross-layer DNS-TXT-record token-byte-authoring dimensions: (i) both wire-formats encode per- publisher publication-intent through a version-stamp-and-token-vocabulary scheme — the TLS-RPT record's v=TLSRPTv1 version-stamp opens every parseable record per RFC 8460 §3, just as the SPF record's v=spf1 version-stamp opens every parseable record per RFC 7208 §3.3, and each per-record subsequent tag-value or qualifier-prefix-byte follows a registered- vocabulary token-set; per-publisher operator authoring discipline depends on byte- precision-strict adherence to BOTH registered- vocabulary token-sets at the DNS-TXT-record- publication-discipline layer; (ii) both wire-formats are evaluated per-message at receiver-side at byte- precision-strict parse time — each per-publisher TLS-RPT rua= tag- value is byte-parsed by the receiver-side TLS-RPT-reporter to determine the per-day per-publisher aggregate-report destination, just as each per-mechanism SPF qualifier- prefix byte is byte-parsed by the receiver- side SPF-evaluator to determine the per- message per-receiver SPF verdict; both wire-formats fail-close on invalid byte- sequences; (iii) both wire-formats observe per-publisher per-domain enforcement- state changes through DNS-publication-cadence evolution — a per-publisher SPF qualifier-prefix transition from ~all SoftFail to -all Fail at the apex owner-name is an application-layer enforcement-state evolution that the per-publisher TLS-RPT JSON aggregate reports at the _smtp._tls. <domain> RUA endpoint give the operator no transport-layer visibility into unless the per-receiver per-day reporter- cohort cross-references DMARC RUA reports against the receiver's Authentication-Results per-message SPF qualifier-prefix-byte parse verdicts; (iv) both wire-formats share the same per-publisher per-domain DNS publication-cadence coordination discipline — the TLS-RPT TXT-record publishes at the _smtp._tls.<domain> underscore-label owner-name, while the SPF qualifier-prefix bytes publish at the apex <org-domain> owner-name's TXT-RR; per-publisher per-domain authoring tooling must keep BOTH RR-owner-name publication cadences synchronised across per-publisher per-domain TLS-RPT-record-edit operations and SPF qualifier-prefix-edit operations. Read the SPF-qualifiers spoke alongside this TLS-RPT-record-syntax reference whenever the per-publisher per- domain cross-layer DNS-TXT-record publication plan extends to a complete application- layer-and-transport-reporting-layer DNS- published byte-shape coordination plan — the SPF qualifier-prefix byte IS the application- layer per-publisher published-policy primitive that runs ALONGSIDE the TLS-RPT v=TLSRPTv1 and rua= tag-value byte discipline THIS page documents at every per-publisher cross-layer sender- authentication-and-transport-observability publication event.
• DMARC for SaaS senders — the APPLICATION-LAYER per-SaaS- sender per-customer-domain RUA aggregate-report DELIVERY-PIPELINE observability peer to this TRANSPORT- LAYER per-publisher per-policy-domain TLS-RPT RUA aggregate-report DELIVERY- PIPELINE observability reference. Where THIS page documents the per- publisher per-policy-domain _smtp._tls.<d> TXT-RR byte-grammar (the v=TLSRPTv1 version tag and the rua=mailto: / rua=https:// reporting- URI list) that authorises receivers to deliver TRANSPORT-LAYER TLS-RPT JSON-aggregate reports per RFC 8460 §4, the SaaS-sender DMARC spoke documents the per-SaaS-sender per- customer-domain APPLICATION-LAYER RUA aggregate-report delivery pipeline (the per-customer-domain DMARC TXT-RR rua=mailto: tag authorising receivers to deliver per-customer-domain per-day RFC 7489 §7.2 DMARC aggregate-report XML payloads enumerating per-source-IP / message-count / disposition / DKIM- verdict / SPF-verdict / from-domain rows). Read the SaaS-sender DMARC spoke as the per-customer-domain APPLICATION-LAYER RUA-pipeline observability peer to this page's per-policy-domain TRANSPORT-LAYER TLS-RPT RUA-pipeline observability — a multi-tenant SaaS sender publishing BOTH per-customer-domain DMARC rua= AND per-customer- domain TLS-RPT rua= achieves the per-customer-domain cross-layer observability discipline spanning authentication-layer DMARC verdict-distribution AND transport- layer TLS-handshake outcome distribution.
• DKIM best practices — the per-publisher per-domain canonical DKIM publication-and-rotation deployment discipline (RSA-2048-minimum key-size baseline per Feb 2024 bulk-sender requirements, dual-selector rotation- overlap-window discipline, per-publisher per-selector private-key custody-vs-ESP- delegation policy, per-publisher per- selector k=+p= TXT-RR byte-syntax publication at <selector>._domainkey.<domain>) whose per-publisher per-domain application-layer publication-and- rotation discipline runs IN PARALLEL with the per-publisher per-domain transport- layer TLS-RPT _smtp._tls.<domain> TXT-RR v=TLSRPTv1; rua=mailto:... publication discipline THIS page documents. The cross-layer composition operates through FOUR per-protocol-pillar publication-discipline-and-observability- coordination dimensions: (i) per-publisher per-domain joint application-layer DKIM- TXT-RR-publication-correctness AND transport-layer TLS-RPT-TXT-RR- publication-correctness — both layers require the same per-publisher per- domain DNS-zone-editor TXT-RR publication discipline at distinct underscored-attribute leaf-labels (<selector>._domainkey.<domain> for DKIM, _smtp._tls.<domain> for TLS-RPT), and both layers fail per- receiver evaluation under identical RFC 1035 §3.3.14 TXT-character-string- format byte-syntax errors (line-folding defects, missing-semicolon-separators, truncated 252-character TXT-chunking errors); (ii) per-publisher per-domain joint application-layer DKIM-key- rotation-cadence-overlap-window AND transport-layer TLS-RPT-RUA-mailbox- endpoint-continuity — both layers require per-publisher per-domain continuous-availability discipline at the per-selector private-key custody boundary (DKIM dual-selector overlap window) AND the per-rua=mailto:- endpoint deliverability boundary (TLS- RPT RUA mailbox-receipt continuity); per-publisher per-domain operations runbook MUST coordinate the per- selector DKIM-rotation-cycle with the per-RUA-mailbox-endpoint-renewal-cycle so neither cross-layer publication boundary regresses while the other is in-flight; (iii) per-publisher per- domain joint application-layer DMARC RUA-aggregate-report-ingestion AND transport-layer TLS-RPT-failure- report-ingestion as DUAL-OBSERVABILITY- STREAM evidence pipeline — the application-layer DMARC RUA stream surfaces per-receiver per-day per- source-IP DKIM-aligned-pass-rate regression rows (whose root-cause attribution depends on the per-selector DKIM publication discipline the DKIM- best-practices spoke documents), while the transport-layer TLS-RPT JSON per-receiver per-day stream THIS page documents the publication discipline for surfaces transport-layer TLS- handshake per-MX-host failure rows (whose root-cause attribution depends on the per-MX-host TLS-cert + MTA-STS policy publication discipline); the per-publisher per-domain dual- observability-stream-ingestion dashboard MUST ingest BOTH streams jointly to detect cross-layer- correlated per-publisher per-domain deliverability regressions; (iv) per- publisher per-domain joint application- layer DKIM-aligned-pass-rate floor + transport-layer TLS-encryption-rate floor as the per-publisher per-domain complete cross-layer authentication- and-encryption posture — the per- publisher per-domain DUAL-LEG complete per-publisher per-domain deliverability-posture posture floor is the JOINT application-layer per- publisher per-domain DKIM-aligned- pass-rate floor (from the DKIM-best- practices spoke's per-selector publication-and-rotation discipline) AND transport-layer per-publisher per-domain TLS-RPT-observed per- receiver TLS-encryption-rate floor (from THIS page's TLS-RPT publication discipline). Read THIS page when AUTHORING the per-publisher per-domain transport-layer TLS-RPT _smtp._tls.<domain> TXT-RR publication discipline; read the DKIM-best-practices spoke when AUTHORING the per-publisher per- domain application-layer DKIM publication-and-rotation discipline that runs as the cross-layer application-layer peer to THIS page's transport-layer observability-channel publication discipline.
• SPF mechanisms explained — the APPLICATION-LAYER-SPF-MECHANISM- VOCABULARY-PUBLICATION-DISCIPLINE-AS-CROSS- LAYER-PEER-OF-TRANSPORT-LAYER-TLS-RPT- OBSERVABILITY-CHANNEL-PUBLICATION-DISCIPLINE companion to this RFC 8460 §3 TLS-RPT DNS-RR byte-syntax reference. Where THIS page documents the per-publisher per-domain TRANSPORT-LAYER TLS-RPT DNS-RR publication discipline (the _smtp._tls.<domain> underscored-attribute-leaf publication per RFC 8552, the v=TLSRPTv1; rua=mailto:tlsrpt@<domain> byte- syntax per RFC 8460 §3, the RFC 1035 §3.3.14 255-octet character-string limit, the per- publisher per-domain TLS-RPT RUA mailbox- endpoint publication discipline, the parallel per-publisher per-domain MTA-STS TXT-ID-RR publication discipline coordination), the SPF-mechanisms spoke is the APPLICATION-LAYER- PARALLEL-PUBLISHER-AUTHORIZATION-VOCABULARY companion documenting the per-publisher per- domain SPF mechanism-class authorization- vocabulary publication discipline whose application-layer publisher-discipline mechanics parallel the transport-layer TLS- RPT observability-channel publication discipline mechanics THIS page architectures. The TLS-RPT-vs-SPF-mechanisms relationship is cross-layer-publisher-discipline-parallel- with-distinct-publication-target: TLS-RPT publishes per-publisher per-domain transport- layer observability-channel at the _smtp._tls.<domain> underscored-attribute-leaf; SPF publishes per- publisher per-domain application-layer authorization-vocabulary at the per-publisher per-domain apex zone v=spf1 TXT- record; both are per-publisher per-domain publisher-side publication disciplines at distinct cross-layer publication-targets. Four cross-layer per-publisher-publication- discipline-parallel dimensions matter at the per-publisher per-domain coherent-publisher- publication-discipline boundary: (i) per- publisher per-domain TLS-RPT _smtp._tls.<domain> underscored-attribute-leaf publication PARALLELS per-publisher per-domain SPF apex- zone v=spf1 TXT-record publication — both are per-publisher per-domain TXT-RR publications subject to the RFC 1035 §3.3.14 255-octet character-string limit at the per- publisher per-domain authoritative-zone publication-cadence boundary; (ii) per- publisher per-domain TLS-RPT rua= mailbox-endpoint publication discipline PARALLELS per-publisher per-domain DMARC rua= aggregate-report mailbox-endpoint publication discipline whose per-publisher per-domain SPF-aligned-pass- rate evidence-stream feeds the parallel application-layer evidence pipeline; (iii) per-publisher per-domain TLS-RPT RUA mailbox- endpoint cross-domain delegation requirement per RFC 8460 §3 PARALLELS per-publisher per- domain SPF cross-domain delegation requirement when per-publisher per-domain rua=mailto: mailbox endpoint is published on a different organisational domain whose per-receiver per-message SPF- aligned-pass requires per-publisher per- domain SPF mechanism authorization for the cross-organisational-domain mailbox; (iv) per-publisher per-domain TLS-RPT publication cadence and per-publisher per-domain SPF include-cascade flattening cadence coordination — both are per-publisher per- domain operator-discipline disciplines requiring coordinated per-publisher per-domain publication-cadence operations at the per- publisher per-domain authoritative-zone publication-cadence boundary so the per- publisher per-domain cross-layer publisher- publication-discipline stays coherent at the per-publisher per-domain observability-and- authorization-discipline joint posture. Read THIS page when AUTHORING the per-publisher per-domain transport-layer TLS-RPT _smtp._tls.<domain> TXT-RR observability-channel publication discipline; read the SPF-mechanisms spoke when AUTHORING the per-publisher per-domain application- layer SPF authorization-vocabulary publication discipline whose cross-layer publisher- discipline parallels the TLS-RPT transport- layer observability-channel publication discipline THIS page architectures at the per-publisher per-domain coherent-publisher- publication-discipline boundary.
• DMARC monitoring — the TRANSPORT-LAYER-TLS-RPT-AGGREGATE- REPORT-STREAM-AS-CROSS-LAYER-OBSERVABILITY- PEER-OF-APPLICATION-LAYER-DMARC-AGGREGATE- REPORT-STREAM companion to this TLS-RPT record byte-syntax reference. Where THIS page documents the RFC 8460 §3 _smtp._tls.<domain> TXT-RR byte-syntax reference (the v=TLSRPTv1 version-stamp, the rua= mailto/HTTPS RUA-URI field, the per-publisher per-domain publication-location at the underscored attribute-leaf owner-name) that emits the per-publisher per-domain transport- layer JSON-failure-report stream, the DMARC-monitoring spoke documents the per-publisher per-domain APPLICATION-LAYER aggregate-report KPI-dashboard whose per-day per-receiver per-source-IP DMARC- pass-rate / DKIM-aligned-pass coverage / SPF-aligned-pass coverage / policy-mode enforcement-disposition-rate KPIs are STRUCTURALLY MIRRORED by the per-publisher per-domain TRANSPORT-LAYER TLS-RPT-stream KPIs THIS page's TXT-RR publication bootstraps. The TLS-RPT-RUA-PUBLICATION- VS-DMARC-MONITORING-KPI-DASHBOARD cross- reference establishes FOUR cross-layer coupling dimensions: (i) parallel- underscored-attribute-leaf publication substrate — the per-publisher per-domain _smtp._tls.<d> TLS-RPT TXT-RR publication discipline this page documents structurally parallels the per-publisher per-domain _dmarc.<d> DMARC-record publication discipline whose KPI-dashboard the monitoring spoke documents; both publications target underscored attribute-leaf owner-names at the publisher's authoritative zone, both carry a rua= tag pointing at the publisher's per-domain aggregate- report collector, both gate the existence of the corresponding aggregate-report stream the monitoring dashboard feeds on; (ii) parallel daily-aggregate- cohort emission cadence — the per- publisher per-domain TLS-RPT JSON-report emission cadence (one report per reporting MTA per 24-hour window per RFC 8460 §4.1) this page's TXT-RR publication bootstraps structurally parallels the per-publisher per-domain DMARC aggregate- XML emission cadence (one report per receiver per 24-hour window per RFC 7489 §7.2) the monitoring spoke's KPI dashboard ingests; the monitoring spoke documents how the per-day-bucket aggregate-cohort structure that this TLS-RPT publication bootstraps at the transport-layer is the SAME per-day- bucket aggregate-cohort structure the application-layer DMARC KPI dashboard stratifies into per-receiver / per-source- IP / per-disposition cohorts; (iii) cross-layer per-source-IP attribution-key parallel — the per- publisher per-domain TLS-RPT JSON report's policies[].failure- details[].sending-mta-ip per- failure-row attribution-key field this page's TXT-RR publication bootstraps structurally parallels the per-publisher per-domain DMARC aggregate-XML <source_ip> per-row attribution-key field the monitoring spoke's per-source-IP stratification dashboard surfaces; both fields key the per-receiver per-day-bucket aggregate-row at the per-source-IP granularity that drives every per-source- IP KPI the monitoring spoke documents; (iv) cross-layer failure-mode- catalogue complementarity — the per- publisher per-domain transport-layer TLS-RPT 13 canonical result-type values (per RFC 8460 §4.3.3) this page's TXT-RR publication bootstraps the emission of complement the application-layer DMARC dmarc=fail / dkim= fail / spf=fail per- message verdict-axis the monitoring spoke's KPI dashboard aggregates; the monitoring spoke documents how the cross-layer failure-catalogue complementarity yields a complete per-publisher per-domain authentication- and-transport observability picture only when BOTH the TLS-RPT publication this page architectures AND the DMARC-record publication the monitoring spoke gates on are present at the per-publisher per- domain underscored-attribute-leaf scope. Read the DMARC-monitoring spoke alongside this TLS-RPT TXT-RR byte-syntax reference when operating per-publisher per-domain cross-layer observability for the transport-layer encryption-failure stream this page's record-syntax discipline publishes and the application-layer message-authentication-failure stream the monitoring spoke's KPI dashboard aggregates.
• Reverse DNS (PTR records) explained — the PER-MX-HOST-PTR-RDNS-AS-TLS-RPT- EVIDENCE-ATTRIBUTION-FINGERPRINT companion to this TLS-RPT TXT-RR byte-syntax reference. Where THIS page documents the per-publisher TLS-RPT _smtp._tls.<domain> TXT record byte-grammar (the v=TLSRPTv1 identifier and rua=mailto: / rua=https: report-aggregation destinations), the reverse-DNS-PTR spoke is the PER-MX-HOST- RDNS-PUBLICATION-DISCIPLINE REFERENCE every TLS-RPT publisher consults when decoding per-MX-host attribution rows in the receiver-emitted TLS-RPT JSON payloads. Three structurally-distinct TLS-RPT-vs-PTR coordination dimensions: (i) the TLS-RPT JSON evidence row schema (per-message success / failure counters by per-policy / per-result-type / per-failure-reason attribution) includes per-MX-host sending-mta-hostname AND receiving-mx-hostname rows whose values are the per-receiver-side PTR-resolved hostnames the connecting per-message SMTP session originated from OR delivered to — drifted PTR records produce misattributed evidence rows the publisher's TLS-RPT analytics dashboard misclusters; (ii) per-MX-host PTR record forward-confirmation chain interacts with the per-publisher TLS-RPT evidence's per-MX-host policy-conformance attribution — a PTR-resolved hostname that doesn't match the published MTA-STS / DANE per-MX record produces per-message tlsa-invalid / certificate-name-mismatch failure-type rows that the publisher's per-MX-host audit must correlate with the PTR record's TTL / publication discipline to attribute correctly; (iii) per-shared- IP-pool PTR-record reputation interaction with per-tenant TLS-RPT evidence streams produces correlated per-receiver failure- type clustering — a shared-IP-pool co- tenant's PTR-record drift produces per-MX-host TLS-RPT sts-policy-fetch-error / starttls-not-supported rows for OTHER co-tenants whose per-tenant TLS-RPT analytics dashboard must attribute the failure-mode cluster to the shared-pool PTR-record audit evidence, not to per-tenant configuration drift.
• DMARC for Google Workspace — the GOOGLE-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-TLS-RPT-AGGREGATE-REPORT-CONSUMER- COMPLEMENTARY-TO-DMARC-RUA-AGGREGATE- REPORT-CONSUMER companion to this TLS-RPT DNS record-syntax reference. Where THIS page documents the per-publisher per- domain _smtp._tls.<domain> TXT-record DNS publication discipline (the v=TLSRPTv1 required version tag, the rua= comma-separated mailto: / https: URI list, the per-day per-MX-host JSON aggregate-report-delivery cadence per RFC 8460 §3, the 255-octet TXT character- string format per RFC 1035 §3.3.14, and the _smtp._tls underscore- label convention per RFC 8552), the Workspace-tenant spoke documents the per- Workspace-tenant per-custom-domain TLS-RPT publication topology where the per-tenant per-custom-domain TLS-RPT record coordinates with the per-tenant per- custom-domain DMARC rua= RUA aggregate-report publication at the application-layer DMARC RUA + transport- layer TLS-RPT cross-layer observability boundary. The per-Workspace-tenant per- custom-domain TLS-RPT publication IS the per-tenant per-custom-domain canonical transport-layer observability consumer of the TLS-RPT record-syntax discipline THIS page architectures at four Workspace- tenant-cross-layer-observability-vs-TLS- RPT-record-syntax coupling dimensions: (i) per-Workspace-tenant per-custom-domain TLS-RPT _smtp._tls.<tenant-domain> publication as cross-layer transport- layer observability complement to per- tenant per-custom-domain DMARC RUA application-layer observability — the per-Workspace-tenant per-custom-domain TLS-RPT record publishes the per-Workspace- tenant per-custom-domain transport-layer STARTTLS / TLS-version / certificate- validation failure-evidence stream complementing the per-Workspace-tenant per-custom-domain DMARC RUA per-message authentication-verdict evidence stream; (ii) per-Workspace-tenant per-custom- domain TLS-RPT rua=mailto: endpoint as Workspace-tenant operator- side analytics ingest discipline — the per-Workspace-tenant per-custom-domain TLS-RPT rua=mailto:tlsrpt@<tenant- domain> publication discipline produces the per-Workspace-tenant per- custom-domain transport-layer per-MX-host per-day JSON aggregate-report stream the per-tenant operator ingests into the Workspace-tenant analytics-pipeline coordinating with the per-Workspace- tenant per-custom-domain DMARC RUA per- receiver per-message authentication- verdict aggregate-report stream; (iii) per-Workspace-tenant per-custom-domain TLS-RPT TXT-record-syntax discipline as Workspace-tenant per-custom-domain DNS- zone-file publication coordination — the per-Workspace-tenant per-custom-domain DNS-zone-file publication batch that publishes the per-tenant per-custom-domain SPF + DKIM + DMARC + MTA-STS records SHOULD also publish the per-tenant per- custom-domain TLS-RPT record as the unified per-Workspace-tenant per-custom- domain application-layer-authentication + transport-layer-observability multi-RR publication discipline; and (iv) per- Workspace-tenant per-custom-domain TLS-RPT + MTA-STS combined publication as Workspace-tenant per-custom-domain transport-layer-policy + transport-layer- observability cross-layer hardening — the per-Workspace-tenant per-custom-domain TLS-RPT publication AUTHORS the per- tenant per-custom-domain transport-layer observability reporting-channel-endpoint the per-tenant per-custom-domain MTA-STS policy-enforce-mode publication's per- MX-host transport-layer-failure-event stream is observed through. Read THIS page when AUTHORING the per-publisher per-domain TLS-RPT TXT-record publication discipline at the canonical record-syntax reference layer; read the Workspace- tenant DMARC deployment spoke when AUDITING the per-Workspace-tenant per- custom-domain TLS-RPT + DMARC RUA cross- layer observability publication discipline at the per-Workspace-tenant per-custom-domain DNS-zone-file unified- multi-RR publication boundary.
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN-TLS-RPT-DNS- RECORD-PUBLICATION-AS-TRANSPORT-LAYER- OBSERVABILITY-COMPLEMENT-TO-BIMI-APPLICATION- LAYER-BRAND-PROTECTION companion to THIS per-publisher per-domain TLS-RPT DNS-record publication-byte-grammar reference. Where THIS page documents the per-publisher per- domain RFC 8460 §3 TLS-RPT _smtp._tls.<publisher-domain> TXT-RR publication byte-grammar (the v=TLSRPTv1 version tag, the rua= aggregate-report URI publication discipline, the RFC 1035 §3.3.14 255-octet character-string limit, the RFC 8552 underscored-attribute-leaf convention, the per-publisher per-domain TLS-RPT JSON- aggregate-report inbound-mailbox cadence coordination), the BIMI explained spoke documents the per-publisher per-domain application-layer BIMI brand-indicator- rendering eligibility cascade at FOUR per- TLS-RPT-publication-vs-BIMI-indicator- rendering coupling dimensions: (i) per-publisher per-domain TLS-RPT DNS-record publication AS structurally- parallel transport-layer publisher-side observability-publication discipline to per- publisher per-domain BIMI application-layer brand-protection-publication discipline — the per-publisher per- domain TLS-RPT DNS-record publication IS the transport-layer publisher-side cryptographic- channel-observability publication primitive that produces per-receiver per-day per- publisher per-domain TLS-handshake-failure- rate evidence; the per-publisher per-domain BIMI DNS-record publication IS the application-layer publisher-side brand- identity-authority publication primitive that produces per-recipient per-message inbox-list-display layer visual brand- authenticity signal; the two publications are structurally parallel publisher-side transport-layer-observability + application- layer-brand-authenticity publication- coordination disciplines; (ii) per- publisher per-domain TLS-RPT JSON-aggregate- report cadence AS transport-layer-encryption- floor observability complement to per- publisher per-domain DMARC aggregate-XML- report cadence that is BIMI indicator- rendering eligibility-floor evidence stream — the per-publisher per- domain TLS-RPT JSON-aggregate-report cadence provides the per-publisher per-domain transport-layer-encryption-floor observability evidence stream; the per- publisher per-domain DMARC aggregate-XML- report cadence provides the per-publisher per-domain application-layer-authentication- floor observability evidence stream; the per-publisher per-domain BIMI indicator- rendering eligibility cascade depends on the per-publisher per-domain DMARC enforcement- floor maintenance which the per-publisher per-domain DMARC aggregate-XML-report cadence makes observable; the TLS-RPT observability cadence THIS page documents the publication-byte-grammar for is the transport-layer cross-layer complement to the application-layer DMARC observability cadence the BIMI indicator-rendering eligibility cascade is gated on; (iii) per-publisher per-domain TLS-RPT rua=-mailbox inbound-aggregate- report ingestion AS per-publisher per- domain transport-layer-vs-application-layer unified observability-pipeline coordination complement to per-publisher per-domain BIMI brand-indicator-rendering-decision observability — the per-publisher per-domain operator's per-publisher per- domain inbound aggregate-report ingestion pipeline coordinates per-publisher per- domain TLS-RPT JSON-aggregate-report ingestion + per-publisher per-domain DMARC aggregate-XML-report ingestion into a per- publisher per-domain unified cross-layer observability evidence pipeline; 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 is the per- publisher per-domain brand-protection observability complement to the per- publisher per-domain transport-and- application-layer unified observability evidence pipeline; (iv) per- publisher per-domain TLS-RPT publication discipline 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-publisher per-domain TLS-RPT publication discipline THIS page documents IS the per-publisher per-domain transport- layer-observability 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 AUTHORING per-publisher per-domain TLS-RPT DNS-record publication; read the BIMI explained spoke when UNDERSTANDING how the per-publisher per-domain TLS-RPT transport- layer observability 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.
• SPF for Microsoft 365 — the per-M365-tenant per-accepted-domain envelope-MAIL-FROM-layer SPF TXT-RR publication-discipline companion to this TLS-RPT record-syntax reference. Where THIS page documents the per-publisher per-domain RFC 8460 §3 TLS-RPT _smtp._tls.<domain> DNS TXT-RR publication discipline (v=TLSRPTv1 version-tag, rua=mailto: aggregate-report URI, rua=https: HTTPS-POST URI variant, per-publisher per-domain zone-file publication-cadence), the SPF- for-Microsoft-365 spoke documents the structurally parallel per-M365-tenant per- accepted-domain envelope-MAIL-FROM-layer SPF TXT-RR publication (v=spf1 include:spf.protection.outlook.com -all canonical baseline, per-tenant hybrid- Exchange dual-egress include:+ip4: composition, per-tenant per-third-party- sender flattening discipline against the RFC 7208 §4.6.4 ten-DNS-lookup ceiling). Four per-M365-tenant per-accepted-domain DNS TXT-RR publication coupling dimensions matter at the per-tenant per- accepted-domain composite publication boundary: (i) per-M365-tenant per- accepted-domain dual DNS TXT-RR publication discipline — the per-tenant per-accepted-domain envelope-MAIL-FROM- layer SPF v=spf1 per-domain root TXT-RR coexists with the per-tenant per- accepted-domain transport-layer TLS-RPT v=TLSRPTv1 per-domain _smtp._tls TXT-RR THIS page documents at the per-tenant per-accepted- domain shared zone-file commit-and- propagation boundary, both subject to the per-tenant per-accepted-domain DNS zone- file deployment discipline (Azure DNS zone-file edits, custom DNS provider zone-file edits, per-tenant DNS-validation feedback loop); (ii) per-M365-tenant per- accepted-domain receiver-side per-message envelope-layer SPF verdict vs per-day per-receiver transport-layer TLS-RPT aggregate-report — the per-message envelope-MAIL-FROM-vs-per-tenant SPF record verdict the SPF-for-Microsoft-365 spoke documents IS the per-message envelope-layer per-receiver-side authentication-leg evidence, and the per- day per-receiver _smtp._tls.<domain> TLS- RPT aggregate-report THIS page documents IS the structurally parallel per-day- granularity transport-layer per-receiver- side STARTTLS-handshake observability evidence; (iii) per-M365-tenant per- accepted-domain SPF include:spf.protection.outlook.com DNS-lookup-budget vs TLS-RPT publication DNS-budget — the per-tenant SPF include:spf.protection.outlook.com consumes ~7 DNS lookups of the RFC 7208 §4.6.4 ten-DNS-lookup budget (the M365 SPF macro itself recursively includes ~6 nested include: sub-domain records); per-tenant per-accepted-domain TLS-RPT publication adds zero envelope- layer DNS-lookup-budget consumption while adding per-tenant per-accepted-domain transport-layer per-day observability the per-tenant SPF publication-discipline cannot surface; (iv) per-M365-tenant per- accepted-domain composite publication- portfolio coordination — the per-tenant per-accepted-domain composite SPF + DKIM + DMARC + ARC + MTA-STS + TLS-RPT publication-portfolio IS authored at the per-tenant zone-file discipline boundary; the per-tenant per-accepted-domain SPF envelope-MAIL-FROM-layer publication the SPF-for-Microsoft-365 spoke documents IS load-bearing for the per-tenant envelope- layer publication-portfolio component while the per-tenant per-accepted-domain TLS-RPT transport-layer publication THIS page documents IS load-bearing for the per-tenant transport-layer publication- portfolio component. Read THIS page when AUTHORING the per-publisher per-domain TLS-RPT _smtp._tls.<domain> TXT-RR publication-discipline; read the SPF-for-Microsoft-365 spoke when AUTHORING the per-M365-tenant per- accepted-domain envelope-MAIL-FROM-layer SPF TXT-RR publication that per-tenant per-accepted-domain TLS-RPT publication THIS page documents structurally coordinates with at the per-tenant per- accepted-domain composite DNS-TXT-RR- publication-portfolio coordination floor.
• Email spoofing techniques and defenses — the seven-technique email-spoofing attack catalogue companion at four TLS- RPT-DNS-record vs transport-layer- spoofing-attack-class coupling dimensions.
• BIMI SVG asset requirements — the BIMI SVG asset publication- discipline companion documenting the per- publisher per-domain BIMI SVG Tiny-PS 1.2 portable-icon brand-indicator asset byte- grammar publication discipline (root baseProfile="tiny-ps" attribute / square 1:1 aspect ratio / 32 KB compressed-size ceiling / no scripting or animation / no external resources / centered solid background) at four TLS-RPT-record- syntax-vs-BIMI-SVG-asset-publication- discipline coupling dimensions (per-publisher per-domain _smtp._tls.<d> TLS-RPT TXT-RR underscore-prefixed-DNS-TXT-RR publication-discipline per RFC 8460 §3 IS structurally parallel to per-publisher per- domain default._bimi.<d> BIMI TXT-RR underscore-prefixed-DNS-TXT-RR publication-discipline per BIMI-Group draft- bimi-record-syntax — both are per- publisher per-domain underscore-prefixed- DNS-TXT-RR publication primitives whose per- receiver-side consumption underpins the per- publisher per-domain composite cross-layer trust-signal-floor / per-publisher per-domain TLS-RPT receiver-side per-day JSON-aggregate- report stream IS the structurally-parallel per-publisher per-domain transport-layer- observability companion to per-publisher per- domain DMARC RUA XML-aggregate-report stream per RFC 7489 §7.2 whose per-publisher per- domain DMARC-aligned-pass-rate floor IS the load-bearing precondition for per-mailbox- provider BIMI indicator-rendering eligibility / per-publisher per-domain TLS-RPT publication- discipline preserves per-publisher per-domain per-MX-host transport-layer-integrity observability stream whose per-receiver-side STARTTLS-survival cascade downstream-affects per-mailbox-provider BIMI SVG-host HTTPS- resource-fetch-and-render decision-pipeline / per-publisher per-domain TLS-RPT TXT-RR publication discipline IS the per-publisher per-domain transport-layer-observability- publication-primitive structurally parallel to the per-publisher per-domain BIMI application-layer-brand-indicator- publication-primitive THIS BIMI SVG asset page documents the byte-grammar publication- discipline of at the per-publisher per-domain composite transport-layer-observability- and-application-layer-brand-indicator- publication-coordination boundary) — together the per-publisher per-domain TLS-RPT record-syntax publication-discipline THIS page documents AND the per-publisher per- domain BIMI SVG asset publication-discipline compose the per-publisher per-domain composite transport-layer-observability-and- brand-indicator-publication coordination floor.
• BIMI VMC and CMC certificates — the PER-PUBLISHER-PER- DOMAIN-TLS-RPT-DNS-RECORD-SYNTAX-PUBLICATION-AS- TRANSPORT-LAYER-X.509-CHAIN-OF-TRUST-COMPLEMENT- TO-PER-PUBLISHER-PER-DOMAIN-BIMI-VMC-AND-CMC- APPLICATION-LAYER-X.509-CHAIN-OF-TRUST-PUBLICATION- DISCIPLINE-AT-FOUR-PER-TLS-RPT-RECORD-SYNTAX-VS- BIMI-VMC-CMC-CERTIFICATE-PUBLICATION-COUPLING- DIMENSIONS companion documenting the per-publisher per-domain BIMI VMC and CMC X.509-chain-of-trust certificate-publication discipline whose per- publisher per-domain application-layer brand- authenticity cryptographic-anchor is the structurally-parallel application-layer X.509- chain-of-trust publication-discipline companion to the per-publisher per-domain TLS-RPT-aided MTA-STS transport-layer X.509-chain-of-trust publication-discipline THIS page documents the per-publisher per-domain transport-layer- observability publication-byte-grammar for (per-publisher per-domain BIMI a= tag VMC-URI publication-discipline per BIMI- Group draft-bimi-record-syntax IS structurally parallel application-layer X.509-chain-of- trust publication-discipline to per-publisher per-domain TLS-RPT-aided MTA-STS HTTPS-policy- endpoint X.509-certificate publication-discipline per RFC 8461 §3.2 — both per-publisher per-domain DNS-and-HTTPS-published cryptographic- trust-anchor publication-disciplines coordinate per-publisher per-domain cross-protocol cross- layer X.509-chain-of-trust publication-discipline floor whose per-receiver per-day evidence-driven visibility the per-publisher per-domain TLS-RPT- record-syntax-driven aggregate-observability pipeline surfaces / per-publisher per-domain BIMI VMC issuing-CA list governance discipline (per-VMC X.509 EKU extension constraints + per- VMC per-trademark-jurisdiction registered-mark proof-of-ownership chain-of-custody publication discipline) IS structurally parallel application- layer X.509-chain-of-trust publication-discipline to per-publisher per-domain TLS-RPT-aided MTA-STS per-receiver MX X.509-certificate per-CA-PKI- trust-anchor verification-discipline per RFC 8461 §4.1 — both per-publisher per-domain per-CA-anchored X.509-chain-of-trust publication- disciplines drive per-publisher per-domain TLS- RPT JSON-aggregate-report per-failure failure-details.failure-reason-code attribution (certificate-not-trusted, certificate-host-mismatch, certificate-expired) per RFC 8460 §4.4 the per-publisher per-domain TLS-RPT- record-syntax-driven observability stream surfaces / per-publisher per-domain BIMI VMC annual-renewal cadence operational-discipline IS structurally parallel cryptographic-anchor- renewal cadence operational-discipline to per- publisher per-domain TLS-RPT-aided MTA-STS HTTPS- policy-endpoint X.509-certificate renewal cadence operational-discipline — both per-publisher per-domain X.509-certificate renewal cadence operational-disciplines drive per-publisher per- domain TLS-RPT JSON-aggregate-report per-failure certificate-expired attribution per RFC 8460 §4.4 the per-publisher per- domain TLS-RPT-record-syntax-driven observability stream surfaces / per-publisher per-domain BIMI a=<VMC-URI> tag publication- discipline drift (VMC-URI HTTPS-fetch failure / per-VMC X.509-chain-of-trust validation- failure / per-VMC issuing-CA not on per-mailbox- provider trust-list) directly opens per-publisher per-domain application-layer brand-indicator rendering-eligibility blind-spot IS structurally parallel to per-publisher per-domain TLS-RPT TXT- RR publication-discipline drift opening per- publisher per-domain transport-layer-observability blind-spot at the per-publisher per-domain composite cross-protocol cross-layer X.509-chain- of-trust-publication-discipline coordination boundary) — together the per-publisher per- domain TLS-RPT record-syntax publication-discipline THIS page documents AND the per-publisher per- domain BIMI VMC and CMC X.509-chain-of-trust certificate-publication discipline compose the per-publisher per-domain composite transport- layer-and-application-layer X.509-chain-of-trust- publication coordination floor.
• DKIM cryptography basics
• DKIM key rotation
• DMARC policy rollout
• DMARC policy modes
• DMARC forensic (RUF) failure reports
• DKIM replay attacks
• DMARC deployment checklist — the PER-PUBLISHER-PER-DOMAIN-TLS-RPT-DNS-RECORD-SYNTAX-AS-LOAD-BEARING-TRANSPORT-LAYER-AGGREGATE-OBSERVABILITY-PUBLICATION-DISCIPLINE-COMPANION-FOR-PER-PUBLISHER-PER-DOMAIN-DMARC-FOUR-PHASE-OPERATOR-ACTIONABLE-DEPLOYMENT-PROGRESSION companion at four per-publisher per-domain TLS-RPT-DNS-record-syntax-vs-DMARC-deployment-checklist coupling dimensions: (i) per-publisher per-domain TLS-RPT _smtp._tls.<domain> TXT-RR v=TLSRPTv1; rua=mailto:<aggregate-URI> publication-discipline per RFC 8460 §3 THIS page documents the per-publisher per-domain transport-layer-observability publication-discipline of IS structurally parallel underscored-attribute-leaf DNS-publication-discipline to per-publisher per-domain DMARC _dmarc.<domain> TXT-RR v=DMARC1; p=...; rua=mailto:<aggregate-URI> publication-discipline per RFC 7489 §6.3 the per-publisher per-domain DMARC deployment-checklist Phase 1 Discovery prerequisite-floor the DMARC-deployment-checklist spoke documents the operator-actionable per-phase action-items-and-exit-criteria of references as a per-publisher per-domain DMARC TXT-RR publication baseline; (ii) per-publisher per-domain TLS-RPT JSON-aggregate-report per RFC 8460 §4 (summary.total-successful-session-count + per-failure failure-details) IS the load-bearing transport-layer evidence-driven observability stream structurally parallel to per-publisher per-domain DMARC RUA XML-aggregate-report per RFC 7489 §7.2 (policy_published + record/row/policy_evaluated) the per-publisher per-domain DMARC deployment-checklist Phase 2 Triage attribution-baselining + per-phase-exit-criteria evidence-driven readiness-decision-discipline coordinates against as per-publisher per-domain per-leg pass-rate floor preservation evidence stream; (iii) per-publisher per-domain TLS-RPT-aided MTA-STS mode: testing → mode: enforce transport-layer two-stage ramp progression IS structurally parallel to per-publisher per-domain DMARC p=none → p=quarantine → p=reject application-layer three-stage ramp progression — both per-publisher per-domain progressively-stricter policy-mode-publication ramps gate on per-receiver per-day per-source-IP / per-MX-host evidence-driven readiness metrics the per-publisher per-domain DMARC deployment-checklist Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-ramp coordinates against; (iv) per-publisher per-domain TLS-RPT TXT-RR DNS-publication-discipline drift (TXT-RR not present at _smtp._tls.<domain> / v=TLSRPTv1 version-tag missing / malformed rua= mailto-URI syntax / 255-octet character-string-boundary violations per RFC 1035 §3.3.14) directly opens per-publisher per-domain transport-layer observability blind-spot at per-receiver per-day per-MX-host evaluator-side evidence-emission boundary IS structurally parallel to per-publisher per-domain DMARC TXT-RR publication-discipline drift opening application-layer observability blind-spot the per-publisher per-domain DMARC deployment-checklist Phase 2 Triage attribution-baselining + per-phase-exit-criteria readiness-decision-discipline THIS DMARC-deployment-checklist spoke documents structurally depends on at the per-publisher per-domain composite cross-protocol cross-layer DNS-publication-discipline-and-DMARC-deployment-ramp coordination boundary.
• DMARC aggregate (RUA) reports
• DMARC myths and misconceptions
• How attackers bypass DMARC
• DMARC for cPanel — the shared-hosting deployment guide that consumes the TLS-RPT record this page documents. A cPanel/Exim operator publishing the _smtp._tls.<domain> TLS-RPT TXT-RR per this syntax reference will receive the resulting per-MX-host transport-failure JSON reports into the same DMARC report mailbox they configure for rua= aggregate reports; the cPanel guide shows where the rua/ruf mailbox is wired up via cPanel's Email Deliverability tooling and how a shared-hosting operator (who often does not control the Exim TLS-certificate chain on the hosting node directly) reads TLS-RPT starttls-not-supported / certificate-expired rows to escalate transport problems to the hosting provider. Read the cPanel spoke when the TLS-RPT record authored here belongs to a cPanel-hosted domain.
• Email authentication glossary — the plain-language reference for the transport-security and authentication vocabulary this TLS-RPT syntax page uses. TLS-RPT, MTA-STS, DANE, STARTTLS and the rua=/report-URI terms it shares with DMARC are each defined there in one place — read the glossary when a term in this record-syntax reference needs grounding before you act on it.
• DMARC for Microsoft 365 — the application-layer reporting companion to this transport-layer _smtp._tls record. A Microsoft 365 tenant operator who publishes the TLS-RPT rua= endpoint this page documents is the same operator publishing the _dmarc aggregate rua= endpoint the M365 guide sets up — read it to stand up the DMARC RUA stream alongside the TLS-RPT stream for full transport-and-message-layer observability on an Exchange Online domain.
• Phishing protection — the threat-context companion to this transport-layer record. TLS-RPT surfaces the STARTTLS-strip and certificate-mismatch downgrade attempts that let an on-path attacker intercept or tamper with mail in transit — the transport-layer half of the same interception threat the message-layer anti-phishing controls defend against; read the phishing-protection guide for the full threat model the _smtp._tls reporting stream documented here feeds into.
• DMARC for Office 365 hybrid (on-prem Exchange + Exchange Online) — the application-layer deployment companion to this transport-layer record. A hybrid Exchange tenant publishes _smtp._tls.<domain> to observe STARTTLS health on its inbound MX legs while it ramps DMARC enforcement across BOTH outbound egress paths (on-prem Send Connector + Exchange Online queue); the hybrid guide documents the dual-egress SPF/DKIM/DMARC alignment discipline at the application layer that runs in parallel with the _smtp._tls transport-reporting record this page defines.
• RFC 8460 §3 — TLS-RPT DNS record format — the normative specification.
• RFC 8460 — SMTP TLS Reporting — the full normative reference (DNS record + JSON report format + result-type registry).
• RFC 8461 — SMTP MTA Strict Transport Security — the MTA-STS specification (TLS-RPT's deployment partner).
• RFC 1035 §3.3.14 — TXT character-string format — the 255-octet character-string limit.
• RFC 8552 — underscored attribute leaves in the DNS — the underscore-label convention used by _smtp._tls and _report._smtp._tls.
• Microsoft SNDS + JMRP monitoring — the third leg of the sender-observability triad alongside DMARC aggregate reports and TLS-RPT: per-IP spam-filter verdicts and Junk-click complaints from Microsoft's consumer network (Outlook.com/Hotmail), fetched via the 30-day Automated Data Access key.

Validate your TLS-RPT record now

DMARC Analyzer ingests TLS-RPT JSON reports and surfaces per-policy session counts and per-failure result-type breakdowns in the dashboard. Cross-check the DNS state with the Domain Security Checker before deploying.

Sign up — Free plan Audit my TLS-RPT record