DMARC Analyzer

TL;DR

• TLS-RPT (SMTP TLS Reporting) is the standard for receiving daily JSON reports about inbound SMTP TLS sessions. Defined in RFC 8460. Companion to RFC 8461 (MTA-STS) and RFC 7672 (DANE for SMTP).
• TLS-RPT is a single DNS TXT record at _smtp._tls.<domain> carrying v=TLSRPTv1; rua=<destination>. Destinations can be mailto: or https:, comma-separated.
• Senders that support TLS-RPT aggregate one day of inbound TLS sessions per recipient policy and deliver a JSON report describing successful and failed session counts, the policy that was evaluated (MTA-STS / DANE / no-policy-found), and per-failure detail records (result-type, sending MTA, receiving MX, failure reason).
• The report is aggregate per policy per day, NOT per message. There is no TLS-RPT equivalent of a DMARC forensic / RUF report.
• TLS-RPT is the operational feedback loop that makes MTA-STS and DANE deployable. Without TLS-RPT, an enforce policy failure is invisible — mail simply does not arrive.
• Result-type values like certificate-host-mismatch, sts-policy-fetch-error, and starttls-not-supported point directly at the underlying defect; the report format is designed for actionable remediation.

1. What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting) is an email transport-security observability standard that lets a receiving domain request daily JSON reports from sending mail servers describing the TLS health of inbound SMTP delivery. TLS-RPT is specified in RFC 8460 - SMTP TLS Reporting and is typically deployed as the companion to MTA-STS (RFC 8461) or DANE for SMTP (RFC 7672).

TLS-RPT closes the visibility gap in opportunistic and enforced SMTP TLS. Before TLS-RPT, a sending MTA that failed to negotiate TLS with a recipient (bad certificate, missing STARTTLS, MTA-STS policy fetch failure, DANE TLSA mismatch) would silently fall back to plaintext or refuse delivery, with no feedback channel to the recipient operator. TLS-RPT formalises a daily aggregate report so the recipient operator can see exactly which senders are seeing which failures and act on the underlying defect.

Critically, TLS-RPT is NOT a message- authentication mechanism — it does not describe SPF / DKIM / DMARC results, does not identify individual messages, and does not produce a pass / fail verdict for any specific delivery. It is purely a transport-layer observability standard: how was the TCP-level SMTP session, did the TLS handshake complete, did the recipient policy validate? Message authentication is the job of SPF, DKIM, and DMARC; TLS-RPT and MTA-STS are the parallel transport layer.

2. How TLS-RPT works, step by step

1. The recipient domain publishes a DNS TXT record at _smtp._tls.<domain> containing v=TLSRPTv1; rua=<destination>. The destination is either a mailto: URI (where the JSON report arrives as an email attachment) or an https: URI (where the JSON is POSTed). Multiple destinations are comma-separated.
2. Sending MTAs that support TLS-RPT track every outbound SMTP delivery attempt to the recipient domain over a 24-hour window. For each session they record the result (success or failure), the policy that was evaluated (MTA-STS, DANE, or no-policy-found), the failure result-type (if applicable), and connection metadata (sending MTA, receiving MX, receiving IP).
3. At the end of the 24-hour window, the sending MTA aggregates per recipient policy and generates a JSON report — one policies[] entry per policy seen, with summary counts of successful and failed sessions and a failure-details[] array describing each distinct failure shape (deduplicated by result-type + receiving-mx-hostname + sending-mta-ip with a per-shape failed-session-count).
4. The reporting MTA delivers the JSON document to the recipient's rua= destination. mailto: deliveries arrive as email attachments with MIME type application/tlsrpt+json (or application/tlsrpt+gzip when compressed) and a filename of the form <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz]. https: deliveries are HTTP POST with Content-Type: application/tlsrpt+json.
5. The recipient operator (or an analyzer like DMARC Analyzer) ingests the report, indexes the per-policy session counts and per-failure result-type values into a database, and surfaces the trends in dashboards: total session counts per MX, per-failure breakdowns, per-sender deliverability, certificate-error regression alerts, and MTA-STS rollout health.
6. Sending MTA support is the bottleneck for TLS-RPT coverage. Google Workspace, Microsoft 365, Yahoo, Comcast, and several large hosters emit TLS-RPT; many smaller senders do not. The reports cover the senders that do, which is enough signal to operate large-scale MTA-STS / DANE rollouts.

3. TLS-RPT DNS syntax

The TLS-RPT DNS record is a single TXT record at the well-known label _smtp._tls under the recipient domain.

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

Tag-by-tag anatomy of the TLS-RPT DNS record:

v=TLSRPTv1

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

rua=<uri-list>

Reporting URI for aggregate reports. REQUIRED. Comma-separated list of one or more URIs. Supported schemes are mailto: (the report arrives as an email attachment) and https: (the report is POSTed as the request body). If both schemes are needed, list them comma-separated: rua=mailto:a@example.com,https://reports.example.com/tlsrpt.

Cross-domain reporting destinations (rua=mailto:reports@otherdomain.com) require the destination domain to publish a DNS TXT record at example.com._report._smtp._tls.otherdomain.com containing v=TLSRPTv1 to authorise receiving reports for example.com. Without that authorisation record, RFC 8460 §3 says senders MAY refuse to deliver reports cross-domain — preventing abuse where an attacker publishes a TLS-RPT record pointing at a victim's mailbox.

4. TLS-RPT JSON report format

Reports are JSON documents (MIME type application/tlsrpt+json) with the structure defined in RFC 8460 §4. A minimal example:

{
  "organization-name": "Example Reporter Inc.",
  "date-range": {
    "start-datetime": "2026-05-17T00:00:00Z",
    "end-datetime":   "2026-05-17T23:59:59Z"
  },
  "contact-info": "tlsrpt-support@reporter.example",
  "report-id":    "2026-05-17T00:00:00Z_example.com",
  "policies": [
    {
      "policy": {
        "policy-type":   "sts",
        "policy-string": [
          "version: STSv1",
          "mode: enforce",
          "mx: mail.example.com",
          "max_age: 604800"
        ],
        "policy-domain": "example.com",
        "mx-host":       "mail.example.com"
      },
      "summary": {
        "total-successful-session-count": 12450,
        "total-failure-session-count":    37
      },
      "failure-details": [
        {
          "result-type":            "certificate-host-mismatch",
          "sending-mta-ip":         "203.0.113.5",
          "receiving-mx-hostname":  "mail.example.com",
          "receiving-mx-helo":      "mail.example.com",
          "receiving-ip":           "203.0.113.10",
          "failed-session-count":   37,
          "additional-information": "https://reporter.example/tlsrpt/incidents/12345",
          "failure-reason-code":    "X509: cert SAN does not include MX hostname"
        }
      ]
    }
  ]
}

Top-level field reference (RFC 8460 §4.1):

organization-name

Human-readable name of the reporting organisation. Free-form string.

date-range.start-datetime / date-range.end-datetime

ISO 8601 UTC timestamps for the 24-hour aggregation window the report covers.

contact-info

Free-form contact string (often an mailto: or operator-portal URL) for follow-up questions.

report-id

Reporter-assigned unique identifier for the document. Used to deduplicate redelivered reports.

policies[]

Array of per-policy aggregation entries — one for each distinct recipient policy seen during the window. The vast majority of reports contain exactly one entry.

Per-policy field reference (RFC 8460 §4.2):

policy.policy-type

One of sts (MTA-STS policy evaluated), tlsa (DANE TLSA record evaluated), or no-policy-found (neither MTA-STS nor DANE — the session used opportunistic TLS or plaintext).

policy.policy-string

Array of strings reproducing the policy that was evaluated. For sts, the per-line content of the MTA-STS policy file. For tlsa, the TLSA resource-record values. For no-policy-found, an empty array.

policy.policy-domain

The recipient domain whose policy was evaluated.

policy.mx-host

The MX hostname (or wildcard pattern from the MTA-STS policy) involved.

summary.total-successful-session-count

Count of inbound SMTP sessions that succeeded under the policy during the window.

summary.total-failure-session-count

Count of inbound SMTP sessions that failed the policy. Sum of all failure-details[].failed-session-count entries in this policy.

failure-details[]

Array of per-failure-shape records describing each distinct way a session failed. Deduplicated by result-type + receiving-mx-hostname + sending-mta-ip.

5. TLS-RPT failure result-types

RFC 8460 §4.3 defines a small catalogue of result-type values that classify TLS failures. Each value maps to a specific deployment defect the recipient operator can act on.

6. TLS-RPT examples

6.1 Minimal TLS-RPT record (mailto destination)

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

The production-typical TLS-RPT record. Reports arrive at tlsrpt@example.com as email attachments with MIME type application/tlsrpt+json (or application/tlsrpt+gzip when compressed).

6.2 HTTPS endpoint destination

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=https://reports.example.com/tlsrpt"

Reports are POSTed to the URL as the HTTP request body. The endpoint MUST accept Content-Type: application/tlsrpt+json and respond with 2xx. Useful when a JSON-ingesting pipeline already exists and the operator would rather not parse email.

6.3 Multiple destinations

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

Both destinations receive the report. Useful for redundancy (a transient outage on one channel does not lose the report) and for parallel ingestion by two systems (e.g. DMARC Analyzer and an internal SIEM).

6.4 Cross-domain reporting

# Recipient domain publishes:
_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:reports@other.example"

# Cross-domain authorisation at other.example:
example.com._report._smtp._tls.other.example.  IN  TXT  "v=TLSRPTv1"

Required when rua= points at a mailbox outside the recipient domain (e.g. a third-party analytics service like DMARC Analyzer hosted under a separate domain). Without the authorisation record, RFC 8460 §3 says senders MAY refuse to deliver reports cross-domain.

6.5 Companion MTA-STS deployment

_smtp._tls.example.com.  IN  TXT  "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
_mta-sts.example.com.    IN  TXT  "v=STSv1; id=20260518T120000"

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

The recommended initial deployment: publish TLS-RPT and MTA-STS at the same time, set MTA-STS to mode: testing for the first 4-8 weeks while reviewing TLS-RPT reports, then flip to mode: enforce once the reports show zero unexpected failures.

6.6 Sample failure-details (host mismatch)

"failure-details": [
  {
    "result-type":            "certificate-host-mismatch",
    "sending-mta-ip":         "203.0.113.5",
    "receiving-mx-hostname":  "mx1.example.com",
    "receiving-ip":           "203.0.113.42",
    "failed-session-count":   18,
    "additional-information": "Certificate CN=example.com, SAN does not include mx1.example.com",
    "failure-reason-code":    "X509: SAN mismatch"
  }
]

A canonical actionable failure: the certificate on mx1.example.com covers the bare domain but not the MX hostname itself. Reissue the certificate with the MX in the SAN list and the failure clears on the next reporting window.

7. TLS-RPT best practices

• Publish TLS-RPT at the SAME TIME you publish MTA-STS or DANE. Without TLS-RPT, an enforce-mode policy failure is invisible — mail simply does not arrive and there is no report to correlate the drop against.
• Use a dedicated mailbox for rua=mailto:. A separate tlsrpt@example.com address keeps reports out of operator inboxes and makes it easy to point an IMAP-fetcher (DMARC Analyzer supports IMAP + Microsoft Graph) at exactly the right mailbox.
• Pipe reports into an analyzer. TLS-RPT reports are aggregate JSON — trying to read them by eye scales to roughly one or two reports per day. Past that point, an automated ingestion + dashboard pipeline (DMARC Analyzer, Postmark TLS-RPT, internal SIEM) is the only viable option.
• Compress or HTTPS-stream large reports. Reports from large senders (Google, Microsoft) for high-volume domains can exceed 1MB uncompressed. Most reporters gzip-compress the attachment by default (application/tlsrpt+gzip); HTTPS ingestion sidesteps mail-attachment-size limits entirely.
• Authorise cross-domain destinations explicitly. When rua=mailto: points at a third- party mailbox, publish the <policy-domain>._report._smtp._tls.<reporter-domain> authorisation record at the destination's domain. Without it, senders may silently refuse to deliver.
• Treat no-policy-found as a baseline, not a failure. If you have not yet published MTA-STS or DANE, policy-type: no-policy-found entries are expected — they document opportunistic-TLS session counts and are useful as a coverage baseline. Failure result-types (starttls-not-supported, certificate-*) inside a no-policy-found policy still warrant attention.
• Watch session-count trends, not absolute numbers. A sudden drop in total-successful-session-count from one reporter is a more reliable regression signal than absolute counts — absolute counts depend on the sender's message volume, which fluctuates.
• Alert on new failure result-types, not on raw counts. A certificate-host-mismatch appearing for the first time is a deploy-time regression worth a page; a long-running 1-2 failure/day baseline from misconfigured outlier senders is noise.
• Keep TLS-RPT records short. TXT records over 255 characters get split across multiple strings, which most parsers handle but some legacy resolvers do not. A well-formed TLS-RPT record is under 100 characters even with two destinations.
• Retain reports for at least 1 year. Annual audits, MTA-STS rollout retros, and certificate-incident postmortems all benefit from historical context. DMARC Analyzer stores TLS-RPT alongside DMARC reports indefinitely.

8. Common TLS-RPT mistakes

• Publishing MTA-STS without TLS-RPT. The most common mistake. MTA-STS at enforce with no feedback channel means the operator only learns about failures from end-user "missing email" complaints. Always pair MTA-STS with TLS-RPT.
• Pointing rua= at an unmonitored mailbox. Daily JSON reports queue up unread and the operator never sees the failures. Use a mailbox with an automated ingester or alerting.
• Forgetting the cross-domain authorisation record. When rua=mailto:tlsrpt@analyzer.example points at a separate domain and that domain does not publish the <policy-domain>._report._smtp._tls authorisation, senders silently refuse to deliver and TLS-RPT looks broken.
• Trying to read failure result-types without RFC 8460 §4.3 open. The result-type catalogue is closed — terms like sts-webpki-invalid are precise and decode to a specific defect. Guessing the meaning from the name leads operators down the wrong remediation path.
• Confusing TLS-RPT with DMARC RUA. Both are aggregate-XML/JSON reports about email, but they describe different things: DMARC RUA = message authentication results; TLS-RPT = transport TLS results. Operators sometimes confuse the two when reading dashboards.
• Using http: (not https:) for the rua= URI. RFC 8460 requires the destination scheme be either mailto: or https:. Plain HTTP destinations are rejected by compliant senders.
• Expecting per-message detail. TLS-RPT is aggregate per policy per day per failure-shape. It does NOT identify individual messages and does not include message-ID or recipient-address fields. Operators looking for per-message detail should look at SMTP server logs, not TLS-RPT.
• Treating TLS-RPT as a security control. TLS-RPT is observability, not enforcement. The control is MTA-STS or DANE; TLS-RPT just reports on its outcomes.

9. TLS-RPT troubleshooting

I published a TLS-RPT record but no reports are arriving

Confirm the DNS record exists with dig +short txt _smtp._tls.<domain> and starts with v=TLSRPTv1;. Reports usually take 24-72 hours to start arriving from a given sender (the first daily window has to complete). If the rua= destination is cross-domain, verify the <policy-domain>._report._smtp._tls.<reporter-domain> authorisation record is also published.

Reports arrive from Google but not from Microsoft 365 (or vice versa)

Sender coverage varies. Google Workspace, Microsoft 365, Yahoo, Comcast, and major hosters emit TLS-RPT; many smaller senders do not yet. This is expected and not a deployment defect — the reports you DO get are still actionable.

The JSON in the report won't parse

Some reporters send the report gzip-compressed with MIME type application/tlsrpt+gzip. The attachment is the gzip stream, not the JSON directly. Decompress first (gunzip or a library's gzip decoder), then parse JSON. DMARC Analyzer's TlsRptParser handles both forms transparently.

Filenames look like <reporter>!<policy-domain>!<unix-start>!<unix-end>.json.gz — is that right?

Yes. RFC 8460 §5.1 defines the filename convention. The four exclamation-separated fields are reporter-domain, policy-domain, Unix timestamp of the start-of-window, and Unix timestamp of the end-of-window. The trailing .json or .json.gz reflects the file format.

Reports show only policy-type: no-policy-found entries

You have not yet published MTA-STS or DANE, so reporters log opportunistic-TLS sessions under no-policy-found. To get sts / tlsa entries, deploy MTA-STS or DANE. TLS-RPT remains useful in the no-policy-found baseline form — it documents what session counts your domain is actually receiving.

A specific failure-details entry has failed-session-count of 1 and keeps reappearing

A single-session-count entry that recurs across days indicates a low-volume sender with a persistent defect (often an obscure forwarding service or a sandbox MTA). The sending-mta-ip field is the IP address (IPv4 or IPv6) of the sending MTA that attempted the TLS session; identify the provider via reverse-DNS / WHOIS on that IP (it is not a HELO/EHLO hostname and not the From: domain), then reach out via the WHOIS contact or an abuse@ address if the defect is theirs to fix.

The report claims a sts-policy-fetch-error but my policy file is accessible

Re-test from a sender's vantage point with curl -v --resolve "mta-sts.<domain>:443:<ip>" https://mta-sts.<domain>/.well-known/mta-sts.txt against each of your authoritative IPs. Geo-routing or CDN cache misses can make the file reachable from your test client and unreachable from the sender. Also check the TLS certificate chain on mta-sts.<domain> matches what reporters report.

10. Frequently Asked Questions

What is TLS-RPT?

TLS-RPT (SMTP TLS Reporting, RFC 8460) is a DNS-based mechanism that lets a domain owner request and receive daily reports about TLS connection successes and failures for inbound mail. Reporting senders aggregate one day of TLS sessions per recipient policy and deliver a JSON document describing successful session counts, failed session counts, the policy that was evaluated (MTA-STS or DANE), and per-failure detail records (result type, sending MTA, receiving MX, failure reason).

What does a TLS-RPT DNS record look like?

A TLS-RPT DNS record is a TXT record at _smtp._tls.<domain> containing two tags: v=TLSRPTv1 and rua=<destination>. A typical record is: _smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com" — declaring the TLS-RPT version and the destination address that should receive daily aggregate reports. Multiple rua= destinations can be combined comma-separated, and HTTPS endpoints (rua=https://...) are also supported.

How is TLS-RPT different from DMARC RUA reports?

DMARC RUA reports (RFC 7489) describe message-authentication results — which messages passed or failed SPF, DKIM, and DMARC alignment. TLS-RPT reports (RFC 8460) describe transport-layer results — which inbound SMTP sessions succeeded or failed TLS negotiation against an MTA-STS or DANE policy. The two are independent: TLS-RPT tells you about the network connection, DMARC tells you about message authentication. Both are operational feedback loops that need to be enabled before you can audit your deployment.

Which result-type values appear in TLS-RPT failure-details?

RFC 8460 defines a small set of result-type values that classify why a TLS session failed: 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, and a generic certificate-error. Each value points at a specific deployment defect — for example, certificate-host-mismatch means the leaf certificate SAN does not cover the MX hostname; sts-policy-fetch-error means the sender could not retrieve the MTA-STS policy file at the /.well-known URL.

Where is a TLS-RPT report delivered?

Reporting senders look up the recipient domain's _smtp._tls TXT record, parse the rua= destination, and deliver the daily JSON report there. For mailto: destinations, the report arrives as an email attachment (application/tlsrpt+json or application/tlsrpt+gzip) with a filename of the form <reporter-domain>!<policy-domain>!<unix-start>!<unix-end>.json[.gz]. For https: destinations, the report is POSTed as the request body with Content-Type: application/tlsrpt+json.

Do I need MTA-STS or DANE before deploying TLS-RPT?

No — TLS-RPT is useful on its own as a transport-security observability tool. Without an MTA-STS or DANE policy, reports use policy-type=no-policy-found and document opportunistic-TLS session counts plus any handshake failures. That data is still valuable for spotting senders that are dropping back to plaintext, certificate problems on your MX hosts, or sudden drops in TLS coverage. TLS-RPT becomes more actionable when paired with MTA-STS / DANE because the failure-details then describe policy-validation outcomes the operator can correct.

Can DMARC Analyzer ingest TLS-RPT reports?

Yes. DMARC Analyzer includes a TLS-RPT parser (includes/TlsRptParser.php) that ingests JSON and GZIP-compressed TLS-RPT reports via the upload page or via IMAP / Microsoft Graph mailbox fetch. Reports are stored alongside DMARC aggregate reports in the dmarc_tls_reports table and surface in the dashboard as policy success rates, failure breakdowns by result-type, and per-MX session histograms — so you can audit MTA-STS rollout in the same UI as DMARC alignment.

11. Related guides

• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461): the transport-security policy TLS-RPT reports against. Deploy together.
• DMARC reporting pipeline (RFC 7489 §7) — the APPLICATION-LAYER-PARALLEL-REPORTING- PIPELINE companion to this TLS-RPT transport-layer reporting protocol reference. Where THIS page documents the RFC 8460 TLS-RPT TRANSPORT-LAYER reporting protocol (per-receiver-organisation SMTP-receive-TLS-handshake failure- reporting via the _smtp._tls.<domain> TXT record + the JSON-payload failure- report schema published to rua=mailto:…), the DMARC- reporting-pipeline spoke is the APPLICATION-LAYER PARALLEL REFERENCE documenting the RFC 7489 §7 application- layer reporting protocol whose seven-stage end-to-end pipeline structure is the DESIGN-LEVEL ANALOG of the TLS-RPT pipeline this page documents. The TLS-RPT- VS-DMARC-REPORTING-PIPELINE cross- reference establishes FOUR structurally- distinct ORTHOGONAL FAILURE-MODE-COVERAGE dimensions across the two parallel pipelines: (i) TLS-RPT reports TRANSPORT-LAYER failures (SMTP STARTTLS handshake errors, certificate validation failures, MTA-STS policy enforcement failures, STS policy-discovery failures); DMARC RUA reports APPLICATION-LAYER failures (SPF auth-result, DKIM auth- result, alignment-mode evaluation against the From: organisational domain) — the two protocols cover ORTHOGONAL failure-mode classes; a complete operator- side observability posture requires BOTH pipelines deployed alongside each other; the DMARC-reporting-pipeline spoke documents the application-layer pipeline Stage 1 verdict-emission contract (per- message spf= / dkim= auth-result enum) the TLS-RPT pipeline this page documents DOES NOT cover; (ii) both pipelines use the SAME RFC 8552 underscore-prefixed DNS-label publication convention (TLS-RPT at _smtp._tls.<domain>, DMARC at _dmarc.<domain>) AND the SAME rua=mailto:… endpoint-subscription mechanism for receiver-to-operator failure-reporting delivery — the operator familiar with one pipeline's per-rua- endpoint discipline can transfer that operational knowledge directly to the other; the DMARC-reporting-pipeline spoke documents the per-rua-endpoint Stage 4 outbound dispatch contract (per-receiver- organisation per-day batched delivery, per-mailbox rua=mailto:… subscription, per-endpoint MIME attachment encoding) operators who manage TLS-RPT failure-reporting subscriptions recognise; (iii) TLS-RPT publishes a JSON-payload failure-report schema (RFC 8460 §4); DMARC publishes an XML aggregate-report schema (RFC 7489 §7.2) — the payload format differs but both pipelines apply the SAME Stage 2 per-source-MX / per-source-IP aggregation algorithm and the SAME Stage 3 per-receiver-organisation serialisation pattern; the DMARC-reporting-pipeline spoke documents the XML schema operators familiar with the TLS-RPT JSON schema can map onto via per-stage payload- structure parallels; (iv) both pipelines feed into Stage 7 per-operator reputation feedback channels that close the per-organisation failure-detection loop — TLS-RPT failure-pattern evidence becomes Sender Score / Spamhaus ZEN / Talos receiver-side trust input AND DMARC failure-pattern evidence also becomes Sender Score / Spamhaus ZEN / Talos receiver-side trust input; the DMARC-reporting-pipeline spoke documents the Stage 7 per-operator feedback channels AND the per- organisation reputation-feedback cycle operators using BOTH pipelines coordinate to ensure transport-layer and application- layer failure-detection evidence are cross-correlated in the operator-side analysis discipline. Pair this page (the TLS-RPT transport-layer reporting protocol reference) with the DMARC-reporting- pipeline spoke (the application-layer parallel reporting pipeline reference) when designing the complete operator- side failure-reporting observability posture — the spoke documents the application-layer pipeline whose seven- stage structure is the DESIGN-LEVEL ANALOG of the TLS-RPT pipeline this page documents, and the two pipelines deployed alongside each other deliver complete per-layer failure-mode coverage at the per-organisation observability boundary.
• MTA-STS policy file syntax — the TRANSPORT-SECURITY-COMPANION-POLICY-FILE-PAIR byte-level reference for the mta-sts.txt policy file TLS-RPT reports against — the TRANSPORT-SECURITY-COMPANION-POLICY-FILE-PAIR byte-level companion to this TLS-RPT protocol pillar. Where THIS pillar documents the TLS-RPT REPORTING protocol at the byte level (the _smtp._tls.<domain> TXT record + the JSON-payload failure-report schema published to rua=mailto:…), the mta-sts-policy-syntax spoke documents the BYTE-LEVEL POLICY-FILE format TLS-RPT reports against — the plain-text mta-sts.txt policy file published at https://mta-sts.<domain>/.well-known/mta-sts.txt with the version: STSv1 + mode: enforce|testing|none + repeated mx: directives + max_age: <seconds> tag-value grammar (RFC 8461 §3.2). The two protocols are DESIGNED AS A POLICY-AUTHORING / FAILURE-REPORTING PAIR — RFC 8461 publishes the POLICY (what the operator WANTS enforced); RFC 8460 publishes the REPORTING channel (what the receiver DID enforce and what failures occurred). Where the TLS-RPT-reported failure-mode is policy-validation-failure or policy-discovery-failure, the root cause is almost always a byte-level error in the mta-sts.txt policy file's grammar — a missing version: tag, a missing terminal CRLF, an incorrect max_age: value outside the 604800-second (7-day) operational window, a typo'd mx: pattern that fails to match the receiver-resolved MX hostnames. Read the mta-sts-policy-syntax spoke alongside this page when AUTHORING the policy file the receiver-side enforcement engine will consume, AND when triaging a TLS-RPT-reported policy-validation-failure / policy-discovery-failure whose root cause is a byte-level syntax error in the published policy file rather than an MX-misconfiguration or certificate-chain failure.
• CAA records explained — the CAA-AUTHORIZATION-MISCONFIGURATION- AS-DIRECT-PRODUCER-OF-TLS-RPT-CERTIFICATE- FAILURE-RESULT-TYPES companion reference. Where THIS pillar documents the RFC 8460 TLS-RPT reporting protocol (the _smtp._tls.<domain> TXT record + the JSON-payload failure-report schema with its failure-details[].result-type enumeration), the CAA-records-explained spoke documents the DNS-published CA- issuance-authorisation contract (RFC 8659 issue / issuewild / iodef property tags) whose four operator-control dimensions directly produce specific TLS-RPT JSON result-type failure-mode entries the receiver-side observability stack aggregates: (i) CAA- violation-driven cert-issuance failures (the authoritative CA refuses to issue because the requesting account is not listed in the publisher's CAA issue tags) surface in TLS-RPT JSON as certificate-not- trusted result-type when the publisher falls back to a self-signed or expired cert and receivers' chain- validation fails, (ii) wrong-CAA-host- binding (the publisher's CAA at the apex authorises CA-X but the mta-sts.<domain> sub- domain has a delegated CAA authorising only CA-Y, producing a mismatched cert chain) produces certificate-host- mismatch failures in the receiver- side TLS-RPT aggregate-report stream, (iii) the CAA iodef report-back URI parallels the TLS-RPT rua=mailto:… mailbox as cross-protocol PKI-vs-transport-layer feedback channels — operators publishing both records receive PKI-layer issuance- attempt notifications via iodef AND transport-layer chain-validation-failure notifications via TLS-RPT, structurally composing the two evidence-streams across the PKI and transport stack, and (iv) DNSSEC-signed CAA records (recommended per RFC 8659 §3 to prevent attacker DNS- spoofing of issuance authorisation) parallel DNSSEC-signed TLS-RPT TXT records for cross-protocol PKI-trust- chain anchoring at the DNS layer. Read the CAA-records-explained spoke alongside this pillar when triaging TLS-RPT-reported certificate-not-trusted or certificate-host-mismatch failure-clusters whose root cause is publisher-side CAA misconfiguration rather than receiver-side cert-store- staleness or transport-layer attack — the CAA record's issue tag set MUST encompass every CA the publisher intends to use for the mta-sts sub-domain cert before the cert-issuance pipeline this page's TLS-RPT failure-modes are downstream of can produce a chain- validatable cert at all.
• MTA-STS for Google Workspace (provider deployment) — the provider-specific MTA-STS deployment walkthrough for the Workspace tenant topology TLS-RPT pairs with at the observability layer. Where THIS pillar introduces the TLS-RPT reporting channel in the abstract, the Workspace MTA-STS spoke walks through the four-step deployment on a Workspace tenant: the aspmx.l.google.com / alt1-4.aspmx.l.google.com MX cluster enumeration in the mx: directive (or the single smtp.google.com entry for tenants migrated to the simplified MX configuration), the Workspace-aligned external HTTPS hosting options (Firebase Hosting and Cloud Run for instant custom-domain HTTPS, Cloud Storage + Cloud CDN with Cloud Load Balancing for tenants with existing GCP infrastructure), the absence of any Admin Console / Postmaster Tools MTA-STS panel, the testing-mode burn-in workflow that pairs with the _smtp._tls.<domain> TLS-RPT DNS record this pillar documents, Gmail's role as an MTA-STS-honoring sender since 2018, and the Workspace-specific 604800 max_age honoring cap (Gmail-as-sender silently caps cache lifetime at one week regardless of higher values published). Read this when deploying TLS-RPT on a Workspace tenant — the _smtp._tls TXT record documented on this pillar advertises the rua= destination, and the Workspace spoke documents the complementary _mta-sts publishing-side DNS+HTTPS workflow that produces the very sts-* result-types TLS-RPT reports back. Without the Workspace MTA-STS deployment, the TLS-RPT reports for a Workspace tenant will only carry shared / generic result-type values, not the policy-specific sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid / certificate-host-mismatch diagnostics this pillar's section on reading reports references.
• MTA-STS for Microsoft 365 (provider deployment) — the provider-specific MTA-STS deployment walkthrough for the Microsoft 365 / Exchange Online tenant topology TLS-RPT pairs with at the observability layer. Where THIS pillar introduces the TLS-RPT reporting channel in the abstract, the M365 MTA-STS spoke walks through the four-step deployment on an M365 tenant: the <tenant>-com.mail.protection.outlook.com MX target enumeration in the mx: directive (where <tenant>-com is the dashed transformation of your accepted domain — multi-domain tenants need separate MTA-STS policies per accepted domain, no tenant-level inheritance), the M365-aligned external HTTPS hosting options (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 /.well-known/mta-sts.txt file natively; there is no SharePoint / OneDrive / Defender route), the absence of any Defender-portal / Exchange Admin Center MTA-STS panel (all configuration is DNS + external HTTPS), the testing-mode burn-in workflow that pairs with the _smtp._tls.<domain> TLS-RPT DNS record this pillar documents, and the hybrid-tenant MX-cutover discipline (when on-prem Edge Transport servers route through an on-prem MX alongside the M365 MX, both must be enumerated in the mx: directive). Read this when deploying TLS-RPT on an M365 tenant — the _smtp._tls TXT record documented on this pillar advertises the rua= destination, and the M365 spoke documents the complementary _mta-sts publishing-side DNS+HTTPS workflow that produces the very sts-* result-types TLS-RPT reports back. Without the M365 MTA-STS deployment, the TLS-RPT reports for an M365 tenant will only carry shared / generic result-type values, not the policy-specific sts-policy-fetch-error / sts-policy-invalid / sts-webpki-invalid / certificate-host-mismatch diagnostics this pillar's section on reading reports references. Note also that for M365 tenants MTA-STS is the ONLY TLS-enforcement option inbound — the protection.outlook.com MX cluster does NOT publish TLSA records, so the TLS-RPT reports for M365 inbound carry exclusively sts-* / certificate-* / starttls-not-supported result-types (never the tlsa-invalid / dnssec-invalid values DANE deployments produce).
• DMARC for Microsoft 365 — the PER-TENANT-TLS-RPT-AS-PEER- OBSERVABILITY-CHANNEL-TO-PER-TENANT- DMARC companion to this TLS-RPT protocol pillar reference. Where THIS pillar documents the transport-layer per-tenant TLS-RPT reporting discipline (the _smtp._tls.<tenant-domain> TXT publication, the per-policy per-result-type per-session aggregation in the daily JSON report, the per-receiver delivery to the rua= mailbox / HTTPS endpoint, the sts-policy-fetch- error / sts-policy- invalid / certificate-host- mismatch / starttls-not- supported result-type taxonomy), the DMARC-for-M365 spoke documents the peer application-layer per-tenant DMARC reporting discipline (the _dmarc.<tenant-domain> TXT publication, the per-receiver aggregate-report XML stream the rua= mailbox consumes, the per-message policy_evaluated.dkim/spf verdict each report row carries) at four per-tenant TLS-RPT-vs-DMARC- reporting coupling dimensions: (i) per-tenant transport-layer-vs- application-layer observability partition — TLS-RPT reports on the per-receiver per-session STARTTLS handshake success/failure distribution at the SMTP transport layer (whether the connecting receiver could negotiate TLS at all and whether the certificate offered satisfied the per-policy MTA-STS verification rules); DMARC reports on the per-message per-author-domain identifier-alignment verdict at the message-content application layer (whether the message DKIM-signature or SPF-authenticated- envelope produces an aligned-pass with the From: author-domain) — both layers produce DNS-published reporting endpoints the M365 tenant operator must consume in parallel for full outbound-mail observability; (ii) per-tenant rollout-phase coupling — TLS-RPT testing mode burn- in PARALLEL to DMARC p=none monitoring mode — the M365-tenant rollout discipline pairs the MTA-STS mode=testing publication with the DMARC p=none publication during a 30-90 day observation window; both _smtp._tls and _dmarc reporting endpoints feed the per-receiver per-session and per-receiver per-message failure evidence the operator needs BEFORE advancing MTA-STS to mode=enforce and DMARC to p=reject; (iii) per-tenant M365 EOP-outbound-MX-IP-set as common evidence subject across both reporting channels — the per-tenant TLS-RPT report's session-count per failure and the per-tenant DMARC RUA report's per-row source_ip evidence both reference the same M365 EOP- outbound IP space (spf.protection.outlook.com IP set) when M365 is the SENDER; when M365 is the RECEIVER, both channels reference the <tenant>-com.mail.protection.outlook.com MX cluster — the M365-tenant operator must correlate across both reports to attribute per-IP per-receiver per- per-author-domain failure clusters to either transport-layer (TLS) or application-layer (DMARC) root causes; (iv) per-tenant Feb 2024 bulk- sender requirements as joint TLS-and-DMARC compliance gate — the Google/Yahoo Feb 2024 bulk- sender requirements that the DMARC- for-M365 spoke documents enforce BOTH a per-tenant DMARC publication (p=none minimum) AND a per-tenant TLS publication (STARTTLS OR MTA-STS) at the same compliance checkpoint — M365 tenants sending ≥5000 messages/day to Gmail or Yahoo recipients must satisfy BOTH the TLS-RPT-observable transport-layer encryption baseline THIS pillar documents AND the DMARC-RUA-observable application-layer authentication baseline the M365 spoke documents. Read the DMARC-for-M365 spoke alongside this TLS-RPT protocol pillar when the M365-tenant operator is designing the per-tenant observability programme that correlates the transport-layer _smtp._tls reporting endpoint THIS pillar documents with the application-layer _dmarc reporting endpoint the M365 spoke documents at every per-receiver per-author-domain failure-attribution event.
• TLS-RPT DNS record syntax (RFC 8460 §3) — the byte-by-byte syntax-layer sibling spoke off this pillar covering the _smtp._tls.<domain> TXT record format. Where this pillar tells you the protocol HAS a DNS record that advertises a reporting destination, the record-syntax page documents the exact tag grammar (v=TLSRPTv1, rua=mailto:|https:, the !-separated multi-URI list, the optional size_limit= extension), the cross-domain authorisation contract for off-domain rua URIs, and the 255-octet TXT-string chunking rule. Read this once you understand TLS-RPT's protocol model on this pillar and need the operational reference for authoring the DNS record the protocol relies on.
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the semantic-layer sibling spoke off this pillar covering the on-the-wire JSON report format senders deliver to the rua: destination. Where this pillar tells you the protocol HAS a reporting channel and that reports describe sessions that failed TLS, the report-format page documents the exact JSON schema: top-level fields (organization-name, date-range, contact-info, report-id, policies[]), the per-policy object with policy-type enum (sts / tlsa / no-policy-found), the summary per-session counts, the failure-details[] array with the canonical 13 result-type values, the application/tlsrpt+json vs application/tlsrpt+gzip MIME types, the !-separated mailto: filename convention, and the report-id-keyed redelivery and deduplication semantics. Together with the record-syntax spoke above, forms the complete byte-level TLS-RPT reference: the DNS record advertises the destination; the JSON report is what arrives.
• Reverse DNS PTR records and FCrDNS — the TLS-RPT-PER-FAILING-MX-IP-IDENTITY- VIA-PTR-LOOKUP aggregate-failure-report- consumer companion to this TLS-RPT protocol pillar. Where THIS page documents the TLS-RPT protocol mechanics (the _smtp._tls.<domain> TXT record + the JSON failure-report schema delivered to rua=mailto:… via the receiver-generator → sender-collector → report-consumer pipeline), the reverse- DNS-PTR spoke is the FAILING-IP-TO-MX- ORGANIZATIONAL-IDENTITY resolution reference that the TLS-RPT report consumer uses to pivot from numeric IPs in the JSON failure records (the sending-mta-ip per-session field, the receiving-mx-host per-session field) into the underlying MX-organization identity. The TLS-RPT-AGGREGATE-FAILURE- REPORT-CONSUMER-NEEDS-IP-IDENTITY cross- reference establishes FOUR structurally- distinct report-consumer dimensions where PTR resolution is the load-bearing pivot: (i) TLS-RPT JSON sending-mta-ip resolution to sender-MX organization — RFC 8460 §4.3.2 includes per-session sending-mta-ip as a numeric IP field in failure-record entries; report consumers analyzing aggregate failure streams MUST translate these numeric IPs into sender-MX organizational identity to identify which third-party platform or self-operated egress MX produced the failure (sender-MTA-IPs PTR-resolving to protection.outlook.com → Microsoft 365 EOP; PTR-resolving to google.com → Google Workspace; PTR-resolving to sendgrid.net → SendGrid; PTR-resolving to numeric or no-PTR → potential malicious-relay candidate); (ii) per-MX-host failure attribution in split-MX topologies via PTR — receivers operating split-MX deployments (primary + secondary + tertiary MX hosts on different IP ranges) need per-MX failure attribution to identify which MX-host is producing the TLS failures; the JSON receiving-mx- host field carries the hostname but the per-IP failure-rate breakdown requires PTR resolution of the receiving IPs to confirm which MX-host's underlying IPs are failing vs healthy — the PTR pivot is the prerequisite for the per-MX-host failure-attribution dashboard; (iii) failure-pattern clustering via PTR-derived /24-block-owner identity — TLS failures from IPs in the same /24 with consistent PTR- derived organization typically cluster as ONE underlying issue (a single misconfigured sender-MX serving from a /24); failures from IPs with divergent PTR-derived organizations classify as INDEPENDENT issues that need per-IP root-cause analysis — the report consumer uses PTR-derived organization as the clustering key for failure-record aggregation that the bare-IP grouping cannot achieve; (iv) TLS-RPT report-submitter identity attribution via PTR of the report-source IP — TLS-RPT reports arrive to the receiver's rua= destination from sender-collector infrastructure; PTR resolution of the IP that submitted the report itself confirms the report-source organization matches the report-payload's organization-name field (legitimate report submitters PTR-resolve to the corresponding sender- organization's infrastructure; spoofed- report attack candidates PTR-resolve to unrelated organizations or no-PTR) — the PTR pivot is the canonical anti-spoof gate for TLS-RPT report ingestion. Read the reverse-DNS-PTR spoke alongside the TLS-RPT report-consumer workflow when building the receiver-side failure-stream analysis dashboard — the spoke is the canonical IP-identity-resolution reference whose PTR-derived organizational mapping is the load-bearing input the four report-consumer dimensions above all structurally depend on.
• MTA-STS vs DANE for SMTP — the head-to-head COMPARISON of the two SMTP transport-security standards (RFC 8461 MTA-STS vs RFC 7672 DANE for SMTP). TLS-RPT is the operational observability layer for BOTH standards: failure samples for an MTA-STS policy mismatch AND a DANE TLSA validation failure both arrive through the TLS-RPT reporting stream documented on this page. Read the comparison when deciding which standard to deploy or when reading TLS-RPT failure samples that mention dane-required or sts-policy-fetch-error (the policy-source-specific failure types defined in RFC 8460 §4.3).
• DANE for SMTP (RFC 7672) explained — the deployment-pillar deep dive on the OTHER transport-security standard whose failure samples this TLS-RPT pillar receives and aggregates. Where the comparison page above documents which protocol to choose between, the DANE pillar walks through the full DANE deployment end-to-end: the _25._tcp.<mx-hostname> TLSA owner-name convention per RFC 7672 §3.1, the four TLSA-record fields (usage / selector / matching-type / certificate-association-data) with the canonical DANE-EE (usage=3) + SPKI-selector (selector=1) + SHA-256-matching (matching-type=1) deployment shape, the end-to-end DNSSEC chain-of-trust requirement (a single unsigned ancestor zone makes the TLSA RRset bogus and produces the dnssec-invalid result-type in TLS-RPT reports per RFC 8460 §4.3), the RFC 7672 §2.2.1 receiver-side TLSA-retrieval-and-validation algorithm, the certificate / key rotation procedure (publish new TLSA alongside old, wait for max(zone-TTL, signature-validity) overlap, deploy new cert, retire old TLSA), and the per-provider DANE adoption reference. Read this when TLS-RPT reports flowing into the rua=-named mailbox start carrying tlsa-typed policy records or one of the four DANE-specific result-type values (tlsa-invalid, dnssec-invalid, dane-required, validation-failure) — this pillar tells you what the receiver did with the TLSA records and why each value appeared. Read this also when designing your TLS-RPT deployment alongside DANE (publish the same _smtp._tls.<domain> TXT record covers both protocols — receivers send the same JSON reports regardless of whether MTA-STS or DANE was the active policy).
• MX records explained — the foundational DNS-record reference for the addressing layer TLS-RPT reports against. TLS-RPT failure samples are indexed per-MX-hostname: the receiving-mx-hostname field of each failure-sample record (RFC 8460 §4.4) names the specific MX target the failing TLS handshake was attempting to reach. Without understanding the MX layer, reading TLS-RPT reports becomes guesswork — an operator seeing repeated failures against mx2.example.com needs to know whether that's a primary or backup MX, what priority it sits at, and whether removing it from rotation would cascade load to higher-priority MXs. Read this when triaging TLS-RPT failure reports OR designing a new TLS-RPT-aware mail infrastructure: the MX-records reference covers the priority semantics, the multi-record + backup MX pattern, per-provider canonical MX hostnames you'll see in TLS-RPT report fields (Google Workspace aspmx.l.google.com, Microsoft 365 <tenant>-com.mail.protection.outlook.com), and the TTL alignment between MX records and the _smtp._tls.<domain> TLS-RPT record.
• DNS propagation explained — the TLS-RPT-RECORD-PUBLICATION-TO- SENDER-RESOLVER-CACHE-OBSERVATION-WINDOW companion to this TLS-RPT protocol-pillar reference. Where THIS page documents the TLS-RPT discovery contract (the _smtp._tls.<domain> TXT record sender-side MTAs retrieve to identify where to deliver aggregate transport-security failure reports), the dns-propagation spoke documents the TTL-WINDOW between publication and sender-side observation: (i) sender-side recursive-resolver cache- ageing — operators publishing the _smtp._tls TXT record at the apex DNS provider see the record live at the authoritative nameserver within seconds, but sender-side recursive resolvers (Gmail's outbound relay, Microsoft 365 EOP's outbound relay, Yahoo's outbound relay, every downstream MTA) cache the previous NXDOMAIN response for the RFC 2308 negative-cache SOA-min-TTL window (default 3600s), producing per-sender silent DROP of TLS-RPT reports until each sender's recursive resolver re-queries; (ii) per-sender TTL diversity — TLS-RPT publication requires senders to observe the record before they generate any aggregate JSON report, producing the per-sender "first report appears days after publication" empirical pattern operators experience when first deploying TLS-RPT; (iii) RFC 8767 serve-stale re-emergence — even after the authoritative TTL expires, a sender configured per RFC 8767 may continue serving stale (pre-publication) NXDOMAIN responses for hours under upstream-failure conditions, producing rare delayed TLS-RPT-report-absence windows after the operator believes propagation has completed; (iv) TLS-RPT-record- change propagation — operators rotating the rua=mailto: destination (changing the reporting mailbox from an old vendor to a new vendor) encounter the TTL-bounded window during which senders continue delivering aggregate reports to the OLD destination per their cached TXT record, producing the "report-stream gap" the operator must plan around with overlapping mailbox provisioning. TLS-RPT operators deploying or rotating the _smtp._tls record need the propagation spoke's per-sender cache-ageing model to set realistic first-report SLOs and plan rua-destination rotations.
• DMARC explained — the policy + reporting standard for message authentication. TLS-RPT protects transport; DMARC protects authentication. Deploy both.
• SPF explained — Sender Policy Framework (RFC 7208): the envelope-sender authorisation mechanism. Authenticates the message envelope, not transport.
• DKIM explained — DomainKeys Identified Mail (RFC 6376): the cryptographic message signature. Authenticates message content, not transport.
• DKIM key rotation — the TLS-RPT-AGGREGATE-FEEDBACK-LOOP-AS- PER-RECEIVER-OBSERVABILITY-CHANNEL-FOR- DKIM-KEY-ROTATION-PROPAGATION companion to this RFC 8460 TLS-RPT pillar. Where THIS page documents the canonical TLS-RPT feedback-loop infrastructure (_smtp._tls.<domain> TXT-record publication, the daily/hourly JSON-report dispatch to the rua=mailto: or rua=https: aggregation endpoint, the per-receiver-aggregated transport-layer TLS-negotiation outcome catalogue), the DKIM-key-rotation spoke documents FOUR TLS-RPT-vs-DKIM-rotation observability dimensions: (i) TLS-RPT JSON-report receiving-mx-hostname triplet as the cross-reference key operators use to correlate transport- layer per-receiver evidence with the DMARC RUA aggregate-report per-receiver DKIM-verification-outcome stream during a rotation event — the rotation spoke documents the canonical operator-side observability discipline where the per-receiver TLS- RPT transport-layer evidence stream and the per-receiver DMARC RUA application-layer evidence stream are cross-correlated on the receiving-mx- hostname key during the rotation cutover window — together producing the complete cross-layer per-receiver rotation-readiness observability matrix; (ii) TLS-RPT aggregate-report per-receiver dispatch rhythm vs DMARC RUA aggregate-report per-receiver dispatch rhythm — coordinated observability cadence during the rotation cutover window — the rotation spoke documents the per-receiver-pair-rhythm operators coordinate (TLS-RPT typically daily per RFC 8460 §3.3 default, DMARC RUA typically daily per RFC 7489 §7.2.1 default) to ensure rotation-event observability lands at the operator's aggregation endpoint with comparable cadence; (iii) TLS-RPT failure-type catalogue (RFC 8460 §4.3: starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure) as the transport-layer-side companion to the DMARC RUA application-layer DKIM-verification-failure catalogue operators consult during the rotation cutover window — the rotation spoke documents the operator-side cross-layer diagnostic framework where a per-receiver-pair DMARC dkim=fail surge during the rotation cutover correlates with a TLS-RPT failure surge to surface the canonical transport-layer-vs- application-layer interaction patterns operators must distinguish; (iv) per-publisher TLS-RPT publication discipline maintained through the rotation event — the operator's TLS-RPT publication infrastructure must remain operational throughout the rotation cutover so rotation-induced per-receiver transport-layer evidence captures the rotation-window observability data the operator needs for post-rotation analysis — the rotation spoke documents the operator-side discipline of confirming the TLS-RPT publication is healthy BEFORE the rotation event begins so the rotation-window aggregate-report evidence stream remains intact and the operator's post-rotation analysis has the cross-layer observability data intact. Read the rotation spoke when planning a DKIM-key-rotation event on a domain whose TLS-RPT publication infrastructure is operational — the spoke is the authoritative per-rotation operational reference for the DKIM- rotation-meets-TLS-RPT-aggregate- feedback-loop cross-layer observability boundary.
• DKIM for Google Workspace — the WORKSPACE-TENANT-OUTBOUND-MAIL-STREAM- TLS-NEGOTIATION-OUTCOME-FEEDBACK-AGGREGATION- AT-GMAIL-MANAGED-SENDER-SIDE-MX-RELAY- BOUNDARY companion to this RFC 8460 SMTP TLS-Reporting pillar. Where THIS page documents the generic TLS-RPT feedback-loop infrastructure (the _smtp._tls.<domain> TXT- record publication, the rua=mailto: reporter-endpoint contract, the receiver-emitted JSON failure- summary format, the daily aggregation window) — i.e. the TRANSPORT-LAYER-FEEDBACK- STREAM side of the email-authentication- plus-transport-security stack — the DKIM- for-Google-Workspace spoke is the APPLICATION-LAYER-WORKSPACE-TENANT-DKIM- SIGNING-COMPANION documenting the structurally-orthogonal application-layer DKIM-signing surface a Workspace-hosted outbound mail-stream operates against. The two spokes are operationally complementary evidence streams that together let a Workspace-tenant operator reconcile transport-layer TLS-negotiation outcomes with application-layer DKIM-authentication outcomes for the same mail-stream: (i) the Workspace tenant publishes google._domainkey.<workspace- domain> as the per-tenant DKIM public-key TXT record AND publishes _smtp._tls.<workspace-domain> as the per-tenant TLS-RPT subscriber endpoint — these two DNS publications are structurally independent but operationally complementary; the google._domainkey TXT record anchors the application-layer DKIM signing-identity the receiver verifies via auth_results/dkim in the DMARC aggregate-report stream, while the _smtp._tls TXT record anchors the transport-layer TLS-negotiation feedback the receiver-side STARTTLS handler emits via the TLS-RPT JSON aggregate this page documents; (ii) a Workspace- tenant outbound mail-stream that triggers a TLS-RPT failure event (e.g., certificate-host-mismatch, certificate-expired, starttls-not-supported, validation-failure) at the receiver-side STARTTLS handler MAY STILL produce a successful DKIM pass verdict at the application layer — TLS-negotiation outcomes and DKIM- verification outcomes are orthogonal: Gmail's outbound signer applies the DKIM-Signature header at message-author- time independent of which TLS posture the receiving MX subsequently negotiates; the Workspace spoke documents the application- layer signing surface, this TLS-RPT page documents the orthogonal transport-layer feedback surface, and an operator reconciling both evidence streams gets a more complete operational picture than either stream alone provides; (iii) the Workspace-tenant operator's SPF/DKIM/DMARC publication discipline is the prerequisite for application-layer authentication identifier-alignment, while the Workspace-tenant operator's MTA-STS and TLS-RPT publication discipline is the prerequisite for transport-layer encryption identifier-alignment — both DNS- publication-discipline layers must be operated in parallel for a fully-defensible Workspace-tenant outbound mail-stream posture; THIS page documents the transport-layer feedback-loop infrastructure side, the DKIM-for-Workspace spoke documents the application-layer signing-infrastructure side that completes the operator-side complete authentication-plus-encryption stack picture. Read the DKIM-for-Google- Workspace spoke alongside this TLS-RPT pillar when reconciling per-receiver TLS- negotiation outcomes against per-message DKIM-authentication outcomes for a Workspace-hosted mail-stream — the two evidence streams are operationally complementary windows onto the same receiver-side processing pipeline (transport accept-vs-reject and application authenticate-vs-fail), and the Workspace- spoke-documented google._domainkey TXT-record publication topology is the load-bearing application-layer-anchor counterpart to the transport-layer _smtp._tls publication topology this page documents.
• DMARC for cPanel — the SHARED-HOSTING-PROVIDER-MANAGED- EXIM-DOVECOT-RECEIVE-SIDE-TLS-NEGOTIATION- OUTCOME-EVIDENCE-AGGREGATION-AT-CUSTOMER- DOMAIN-TLS-RPT-PUBLICATION-BOUNDARY companion to this RFC 8460 SMTP TLS- Reporting pillar. Where THIS page documents the generic TLS-RPT feedback-loop infrastructure (the _smtp._tls.<domain> TXT- record publication, the rua=mailto: reporter-endpoint contract, the receiver-emitted JSON failure-summary format, the daily aggregation window), the DMARC-for-cPanel spoke is the SHARED-HOSTING-CONTROL-PANEL companion documenting the STRUCTURALLY- DISTINCT TLS-negotiation-outcome surface a cPanel-shared-hosting deployment induces: (i) the cPanel provider's centralised cpsrvd / Exim / Dovecot stack handles TLS-negotiation for ALL customer domains hosted on a single cPanel server — a TLS-RPT report emitted by an external sender about a customer- domain's MX (which resolves to the shared cPanel server) carries evidence about the SHARED TLS-stack's negotiation outcomes, not just the customer's individual domain — the customer who reads the TLS-RPT report observes events that may originate in OTHER customers' message flows sharing the same MX hostname; (ii) the cPanel _smtp._tls TXT record is typically published at the customer-domain layer (per-customer granularity) but the receiver-side TLS-policy enforcement runs at the cPanel-server-managed /etc/exim.conf + Dovecot TLS-config layer (provider-managed granularity) — this granularity mismatch means a customer who publishes rua=mailto:tls-reports@ <customer-domain> receives reports about a TLS-stack the customer does NOT control, requiring provider-side coordination to remediate any TLS-failures the customer observes; (iii) the cPanel WHM does NOT typically surface a TLS-RPT-publication UI in the "Email Deliverability" wizard as of the current cPanel release stream — customers wanting TLS-RPT evidence aggregation typically must add the _smtp._tls TXT record via cPanel's DNS Zone Editor manually, an operator-side step the customer-portal-only customer rarely takes without external guidance; (iv) provider- wide TLS-stack rolls (Let's Encrypt cert renewal, OpenSSL version bumps, cipher-suite policy changes) propagate to ALL customer-domain MX hostnames served by the cPanel infrastructure, so a TLS-RPT report spike from multiple unrelated external senders within a narrow time window is a strong signal of a provider-wide event the customer- level operator must escalate to the cPanel-hosting provider for root-cause remediation. Read the DMARC-for-cPanel spoke alongside this TLS-RPT reporting pillar when the operator faces a TLS- RPT spike on a cPanel-hosted customer domain, when the customer reports "I published TLS-RPT but I'm getting no reports", or when the cPanel provider's TLS-stack rolls and the customer must coordinate the TLS-RPT-evidence-window with the provider's change-window.
• BIMI explained — Brand Indicators for Message Identification: inbox brand-logo standard. Requires DMARC at enforce; independent of transport-security stack.
• DMARC myths and misconceptions — the TLS-RPT-AS-TRANSPORT-LAYER- COMPLEMENT-MYTH-REFUTATION companion documenting the operator-facing 18-myth catalogue whose refutation arguments cite the transport-layer-vs-application- layer distinction THIS TLS-RPT protocol pillar structurally enforces. Where THIS page documents the TLS-RPT protocol (RFC 8460 SMTP TLS Reporting — the publisher-side _smtp._tls.<domain> TXT record signalling the operator's opt-in to receive transport-layer-failure JSON reports, the receiver-side per-day aggregation of every per-MX-host STARTTLS-handshake outcome — success / certificate-mismatch / certificate- expired / STARTTLS-stripped / dane-fail / sts-policy-fetch-failure — into a JSON-format report-payload, and the operator-side ingestion of that JSON via the rua=mailto: or rua=https: destination URI), the myths-and-misconceptions spoke documents the 18-myth catalogue whose most-cited refutation arguments cite the transport-layer-vs-application-layer distinction THIS protocol enforces: Myth #2 "DMARC encrypts email" is refuted by pointing out that DMARC operates at the APPLICATION layer (message-content authentication via SPF / DKIM alignment with the From: header) and provides NO confidentiality guarantees — the confidentiality guarantee belongs to the orthogonal STARTTLS transport-layer mechanism whose per-MX-host failure modes (cleartext- fallback, certificate-mismatch, certificate-expired, STARTTLS-stripped by an active-MITM attacker, downgrade- attack) THIS TLS-RPT protocol reports. Myth #4 "DMARC alone is enough — no need for MTA-STS" is refuted by pointing out that MTA-STS (the publisher-side TLS-enforcement-policy the receiver-side SMTP-connecting MTA respects) and TLS-RPT (the observer- side feedback channel reporting MTA-STS policy-violation observations) together form the transport-layer security stack ORTHOGONAL to the DMARC application- layer authentication stack — an operator who has only DMARC at p=reject still has zero visibility into whether a per-MX-host STARTTLS-strip downgrade-attack is depriving them of transport-layer confidentiality on every message-leg between Workspace's outbound MTA and the receiver-side inbound MX. Read the myths-and-misconceptions catalogue alongside this TLS-RPT pillar when an operator argues that DMARC alone is sufficient — the catalogue's Myth #2 and Myth #4 refutation arguments map directly onto the transport-layer- observation infrastructure THIS protocol pillar provisions. Closes the TLS-RPT-cluster ↔ DMARC-pillar myth-refutation bridge whereby the transport-layer / application-layer STRUCTURAL DISTINCTION THIS TLS-RPT protocol enforces is the OPERATIONAL-PRECONDITION for the operator-facing transport-vs- application-layer myth-refutation catalogue the myths spoke maintains.
• Email deliverability fundamentals — the TRANSPORT-LAYER-DELIVERABILITY-COMPANION business-outcome consumer of every TLS-RPT failure-mode this page documents — the TRANSPORT-LAYER-DELIVERABILITY-COMPANION business-outcome companion to this TLS-RPT protocol pillar. Where THIS pillar documents the TLS-RPT protocol at the byte level (the _smtp._tls.<domain> TXT record, the v=TLSRPTv1; rua=mailto:… tag grammar, the per-receiver TLSA / MTA-STS / STARTTLS failure-report schema with JSON payload delivery, the tls-negotiation-failure / policy-validation-failure / policy-discovery-failure / certificate-chain-validation-failure failure-category taxonomy, the per-aggregate-window reporting cadence), the email-deliverability page documents the INBOUND-DELIVERABILITY business- outcome consequence of every TLS-RPT- reported failure: when an enforcing receiver (Gmail, Yahoo, the major enterprise mailbox providers) cannot negotiate STARTTLS to your inbound MX, the message either drops on the floor (silent transport failure, never delivered) or downgrades to cleartext+delayed retry — both routes register in the deliverability funnel as INBOUND-DELIVERABILITY DAMAGE that does NOT surface in DMARC aggregate reports (which only report on outbound authentication outcomes, not inbound transport-security failures). The deliverability page documents the FULL FOUR-STAGE DELIVERY FUNNEL (sender → MX accept → bounce vs accept → spam-folder vs inbox-folder placement) and where in the funnel each TLS-RPT- reported failure-category causes the message to FAIL TO ACCEPT (the MX-accept stage gate), plus the per-receiver transport-security ENFORCEMENT MATRIX documenting which mailbox providers enforce MTA-STS in testing vs enforce mode and what the per-receiver consequences of TLS negotiation failure are. Read the deliverability page when triaging a TLS-RPT report's INBOUND-DELIVERABILITY consequence rather than the report's protocol-level failure-mode — the deliverability page is the canonical operator-reference for how transport-security failures propagate into inbox-placement loss across the receiver-side acceptance → placement → engagement outcomes chain.
• DMARC for Microsoft 365 hybrid Exchange — the HYBRID-EXCHANGE-TRANSPORT-LAYER-EVIDENCE-STREAM-COMPANION spoke to this TLS-RPT-explained canonical RFC 8460 aggregate-report-format reference. Where THIS page documents the TLS-RPT aggregate-report JSON envelope structure (organization-name, contact-info, report-id, date-range, policies[] with policy-domain, policy-type, policy-string, mx-host, and summary with total-successful-session-count / total-failure-session-count plus the per-failure-details array enumerating result-type values like starttls-not-supported, certificate-host-mismatch, certificate-expired, validation-failure, tlsa-invalid, dane-required), the hybrid-Exchange deployment spoke documents the canonical Microsoft enterprise topology where TLS-RPT aggregate-report streams provide STRUCTURALLY-DISTINCT transport-layer evidence at multiple hybrid-topology boundaries. The hybrid-Exchange spoke documents the on-prem-Exchange-to-Exchange- Online RELAY boundary where the on-prem Send Connector negotiates STARTTLS outbound to the Exchange Online inbound connector — a structurally-distinct transport-security boundary where the TLS-RPT-reported certificate-host-mismatch / certificate-expired / validation-failure failure categories surface hybrid-specific cert- rotation failures on the on-prem Edge Transport server or hybrid relay host that cause cloud-side delivery to silently FAIL in the absence of TLS-RPT visibility. The hybrid-Exchange spoke documents the Centralized-Mail-Transport cloud-outbound-boundary topology where Exchange Online relays on-prem-originated mail to external receivers via the *.protection.outlook.com managed cert chain — a topology where external-receiver TLS-RPT reports surface the Microsoft-managed transport-layer posture (the policy-domain in the TLS-RPT report will be the receiver-side domain, the mx-host will be the Microsoft-managed *.protection.outlook.com host) and the operator interpretation of the failure categories must distinguish receiver-side policy from Microsoft-managed Exchange Online cert chain failures. The hybrid-Exchange spoke documents the Direct-Send anonymous-relay topology where on-prem servers send DIRECTLY to external receivers via Exchange Online connectors — a topology where TLS-RPT streams provide the ONLY visibility into per-hop STARTTLS negotiation outcomes that otherwise leave no trace in the M365 message-trace logs. Read the hybrid-Exchange spoke alongside this page when triaging a TLS-RPT-reported transport-security failure whose policy-domain / mx-host attribution maps to a Microsoft Exchange Online IP cohort (40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14) or to an on-prem-Exchange Edge Transport server, and you need the per-topology hybrid- deployment reference to identify WHICH of the five hybrid-Exchange mail-flow paths the failed-STARTTLS message traversed and WHICH operator-side configuration remediation (on-prem Send Connector TLS cert renewal vs Exchange Online inbound connector posture review vs Edge Transport cert chain repair) closes the transport-security gap the TLS-RPT report surfaced.
• DKIM replay attacks explained — the TLS-RPT-TRANSPORT-LAYER- REPORTING-DOES-NOT-COVER-APPLICATION- LAYER-DKIM-REPLAY companion to this TLS-RPT pillar. Where THIS page documents the RFC 8460 STARTTLS- negotiation-outcome aggregate-reporting protocol whose JSON-payload result- types catalogue (certificate-not-trusted / certificate-host-mismatch / certificate- expired / TLSA-validation-failure / STS-policy-invalid / STS-policy-failure / STS-webPKI-invalid / STARTTLS-not- supported / validation-failure) the operator's transport-layer observability stack consumes, the DKIM-replay-attacks spoke documents the structurally- distinct application-layer attack class operating ENTIRELY ABOVE the transport layer after a successful TLS handshake — the attacker captures a legitimately- signed message at the receiver-side mailbox per RFC 6376 §8.6 and re-sends it to arbitrary additional recipients via a separate SMTP session whose STARTTLS handshake completes successfully and produces NO TLS-RPT evidence at all. The TLS-RPT-TRANSPORT-LAYER-REPORTING- DOES-NOT-COVER-APPLICATION-LAYER-DKIM- REPLAY cross-reference establishes FOUR structurally-distinct protocol-layer- coverage-boundary dimensions: (i) RFC-8460-§4-JSON-result-type- catalogue-is-transport-layer-exhaustive- and-application-layer-empty dimension — the TLS-RPT JSON result-type catalogue THIS page documents enumerates the COMPLETE set of transport-layer STARTTLS / certificate / DANE-TLSA / MTA-STS observability events; none of the catalogued result-types match the DKIM-replay-attack signature (which produces a SUCCESSFUL transport-layer TLS handshake followed by a re-sent message that DKIM-passes at the receiver), so the TLS-RPT evidence- stream produces no replay-attack signal; (ii) TLS-RPT-receiving-MX-host- cohort-is-orthogonal-to-DKIM-replay- recipient-cohort dimension — the TLS-RPT JSON aggregate reports THIS page documents are organized per receiving-mx-helo / receiving-ip identity at the receiving-SIDE; the DKIM-replay attack's per-recipient-cohort distribution operates ORTHOGONALLY to the per-MX-host observability axis the TLS-RPT aggregate stream's report structure organizes evidence by; (iii) TLS-RPT-aggregation-window-is- UTC-day-bucket-not-per-message-and- cannot-capture-per-message-replay- forensic-evidence dimension — the TLS-RPT JSON aggregate format THIS page documents aggregates per UTC-day windows per RFC 8460 §4.1; the DKIM- replay-attack class requires per-message forensic evidence (Message-ID: uniqueness audit, per-recipient targeting pattern, x-tag expiration verification) at a per-message granularity STRUCTURALLY INCOMPATIBLE with the day-bucket aggregation TLS-RPT provides; (iv) TLS-RPT-emission- gates-on-STARTTLS-failure-not-on- application-layer-replay-and-cannot- compensate-via-tag-configuration dimension — the TLS-RPT emission-gate THIS page documents fires only on STARTTLS-negotiation failure or successful-with-warnings result-types; unlike DMARC's fo= tag which enables operator-side configuration of failure-emission granularity, TLS-RPT has no operator- configurable emission gate that could be tuned to capture application-layer replay attempts — the coverage gap is STRUCTURAL to the protocol design. Read this DKIM-replay-attacks spoke alongside THIS TLS-RPT pillar when authoring the cross-layer incident- response playbook that must SIMULTANEOUSLY consume the transport-layer TLS-RPT JSON-aggregate evidence stream THIS page documents AND the application-layer replay-attack detection patterns the DKIM-replay-attacks spoke documents the operator-discipline of — neither evidence stream covers the other's attack-class.
• DMARC forensic reports (RUF) — the APPLICATION-LAYER per-message forensic-envelope-evidence-stream counterpart to the TRANSPORT-LAYER aggregate-failure evidence stream this pillar documents. Where TLS-RPT publishes the _smtp._tls.<domain> TXT record advertising a rua=mailto:tls-rpt@… destination receivers POST a once-daily JSON aggregate report to (a TRANSPORT-LAYER per-receiver cohort of failed STARTTLS sessions anonymized by aggregation across a UTC-day window), the DMARC RUF channel publishes the ruf=mailto:dmarc-forensic@… tag in the _dmarc.<domain> TXT record advertising a SECOND, STRUCTURALLY DIFFERENT destination receivers POST a per-message AFRF envelope (RFC 5965 + RFC 6591 message/feedback-report MIME with a Feedback-Type: auth-failure header) for EACH individual message that failed DMARC evaluation at the receiver. The two streams pair across the seven-layer receiver-side observability stack: TLS-RPT surfaces transport-security failures BEFORE DATA (STARTTLS negotiation, certificate chain validation, MTA-STS policy enforcement, DANE TLSA matching) where the bytes never reach the receiver's authentication evaluation engine; DMARC RUF surfaces authentication failures AFTER DATA (SPF evaluation, DKIM signature verification, RFC 7489 alignment computation, p= policy application) where the bytes DID reach the authentication engine but failed the organisational-domain alignment test. Operate the two report streams as a PAIRED OBSERVABILITY INVESTMENT — a TLS-RPT certificate-host-mismatch / policy-validation-failure / validation-failure failure-type explains why a sender's traffic NEVER REACHES the receiver (and therefore never appears in the DMARC aggregate or forensic stream); a DMARC RUF auth-failure envelope explains why a sender's traffic DID reach the receiver but failed DMARC alignment at the application layer. Read the DMARC forensic-reports pillar for the AFRF message/feedback-report MIME envelope structure (Feedback-Type / Auth-Failure / Reported-Domain / Source-IP / Authentication-Results / DKIM-Domain / Original-Mail-From headers plus the embedded message/rfc822 part containing the offending message's complete headers + body), the fo= failure-reporting-options tag (fo=0 only when ALL underlying mechanisms fail vs fo=1 on ANY mechanism failure vs fo=d on DKIM-specific failure vs fo=s on SPF-specific failure — the operator-facing knob controlling RUF emission volume), the still-active forensic receivers (Yahoo / AOL / Mail.ru / a handful of European receivers — Gmail and Microsoft DEPRECATED RUF emission years ago citing GDPR concerns), and the GDPR / CCPA privacy analysis governing operator-side ingestion of RUF envelopes (each envelope embeds third-party PII in the message/rfc822 part — the recipient's email address in the To: header, any names / addresses / phone numbers in the body, any IP addresses / user-agent strings in Received: headers). Where TLS-RPT publishes a per-cohort aggregate JSON daily, RUF publishes a per-message MIME envelope minute-by-minute — the operational data-protection / retention / minimization posture is substantially STRICTER for RUF than for TLS-RPT precisely because the granularity is per-message rather than per-cohort. Treat the pair as complementary observability layers: TLS-RPT tells you WHICH STARTTLS sessions failed and why; RUF tells you WHICH per-message AUTHENTICATION decisions failed and which embedded headers explain the alignment computation outcome.
• DMARC monitoring discipline — the APPLICATION-LAYER PARALLEL- OBSERVABILITY-CADENCE companion to the TRANSPORT-LAYER TLS-RPT monitoring cadence THIS pillar documents. Where THIS pillar documents the TRANSPORT-LAYER TLS-RPT observability cadence (the _smtp._tls.<domain> publishing surface, the rua=mailto:tls-rpt@… JSON aggregate destination, the once-daily UTC- aligned report batch cadence, the certificate-host-mismatch / policy-validation-failure / validation-failure failure- type catalogue, and the STARTTLS- negotiation evidence stream the per-domain per-day TLS-RPT report aggregates), the DMARC-monitoring spoke documents the STRUCTURALLY-PARALLEL APPLICATION-LAYER observability cadence across FOUR pairing dimensions: (i) publishing-surface parallel — TLS-RPT publishes at _smtp._tls.<domain> with v=TLSRPTv1 + rua= mailto:tls-rpt@…, the DMARC- monitoring discipline depends on the parallel publication at _dmarc.<domain> with v=DMARC1 + rua= mailto:dmarc-rua@…; identical From=<author-domain>- to-collector-mailbox addressing contract but ORTHOGONAL failure-class coverage (transport-layer STARTTLS failures vs application-layer alignment failures); (ii) cadence-rhythm parallel — both protocols emit per-domain per-day UTC-aligned aggregate batches at major receivers (Gmail, Microsoft 365, Yahoo, Mail.ru), letting the operator align their TLS-RPT monitoring dashboard review-cadence with their DMARC-monitoring dashboard review-cadence at a single morning UTC-aligned operational rhythm; (iii) failure-class-coverage complementarity — TLS-RPT monitoring surfaces failures BEFORE DATA (STARTTLS, certificate chain, MTA-STS, DANE) where bytes never reach the authentication layer; DMARC monitoring surfaces failures AFTER DATA (SPF, DKIM, alignment) where bytes DID reach the authentication layer but failed organisational-domain alignment — operate the two monitoring streams as a PAIRED OBSERVABILITY INVESTMENT, since a TLS-RPT failure-spike explains gaps in the DMARC-monitoring stream (mail never arrived at the receiver and therefore never appears in the DMARC aggregate report) and conversely a DMARC-monitoring failure-spike often coincides with no TLS-RPT evidence (because the mail DID reach the receiver but failed application-layer alignment); (iv) rolling-window deliverability- observability complementarity — both observability disciplines anchor the operator's per-week and per-quarter deliverability-trend retrospectives at the same UTC-day cohort granularity, letting the operator overlay a transport-layer TLS-RPT failure-trend curve against an application-layer DMARC- failure-trend curve and explicitly identify which deliverability incidents had a transport-layer root cause vs an application-layer root cause. Read the DMARC-monitoring spoke WITH this TLS-RPT pillar as a paired observability- cadence reference: the two protocols publish at sibling owner-name positions (_smtp._tls.<domain> and _dmarc.<domain>), emit per-domain per-day aggregate batches over the same SMTP transport path, and together provide the operator with the COMPLETE receiver- side observability picture across both the transport-security layer and the application-authentication layer of the SMTP stack.
• DMARC policy rollout — the TRANSPORT-LAYER-TLS-RPT- AGGREGATE-FAILURE-EVIDENCE-AS- PARALLEL-PER-RAMP-STAGE-DIAGNOSTIC- CHANNEL companion to this TLS-RPT protocol pillar. Where THIS page documents the RFC 8460 TLS-RPT protocol (per-publisher per-domain _smtp._tls.<domain> TXT-RR v=TLSRPTv1 + rua=mailto: publication, the per-receiver per- day TLS-RPT JSON aggregate-failure- evidence stream, the per-failure result-type / sending-mta-ip / receiving-mx-hostname / failed-session-count per-record diagnostic fields, the TRANSPORT-LAYER STARTTLS-handshake + DANE TLSA-RR validation + MTA-STS policy-enforcement evidence boundaries), the DMARC policy rollout spoke is the APPLICATION- LAYER per-ramp-stage publisher- side commitment-curve that runs PARALLEL to the TLS-RPT transport- layer aggregate-evidence stream THIS pillar documents across the same receiver-side observability stack. The four-axis TLS-RPT- TRANSPORT-LAYER-VS-DMARC-ROLLOUT- APPLICATION-LAYER per-ramp-stage cross-layer observability comparison exposes the structurally-distinct cross-layer per-ramp-stage diagnostic coordination dimensions: (i) per-publisher per-ramp- stage p=none monitoring-stage application- layer evidence (per-source-IP aggregate-rua-row spf= / dkim= / dmarc= verdicts) runs PARALLEL to the per- publisher per-day TLS-RPT aggregate-failure-evidence stream (per-receiver per-MX-host starttls-not-supported / certificate-host-mismatch / tlsa-invalid verdicts) — making the per- ramp-stage operator's diagnostic surface a CROSS- LAYER paired-observability channel where the application- layer DMARC verdict and the transport-layer TLS-RPT failure-mode evidence are both consumed at the per-source-IP and per-receiving-MX-host attribution boundaries — the DMARC policy rollout spoke documents the per-ramp- stage application-layer commitment-curve that consumes the per-stage rua-stream evidence ALONGSIDE the transport-layer TLS-RPT aggregate-failure-evidence stream THIS pillar documents as the parallel cross-layer observability channel every per-ramp-stage operator decision depends on; (ii) per-publisher p=quarantine pct=<n> partial- enforcement ramp-gate advancement decisions STRUCTURALLY DEPEND on transport-layer message- delivery integrity — a publisher's per-domain p=quarantine commitment OPERATIONALLY FAILS if the per-publisher's TLS-RPT evidence shows recurring certificate-host-mismatch / starttls-not-supported at the per-publisher's outbound MX-host boundary because messages get queued / dropped / re-tried at the TRANSPORT-LAYER BEFORE the application-layer DMARC evaluation produces a dmarc=pass verdict at the receiver- side — the DMARC policy rollout spoke documents the per-ramp-stage operator decision-discipline that every transport-layer TLS- RPT failure-evidence stream THIS pillar documents materialises as a structural ramp-gate-disqualifier for the per-publisher per-domain DMARC p=quarantine / p=reject commitment; (iii) per-publisher per- ramp-stage sp=- tag subdomain-coordination commitment coordinates against the per-subdomain TLS-RPT evidence stream (per- publisher per-subdomain _smtp._tls.<subdomain> TXT-RR publication may be ABSENT producing TLS-RPT- free per-subdomain observability gap, OR PRESENT producing per- subdomain TLS-RPT aggregate- failure-evidence the per- subdomain sp=- tag rollout-coordination depends on) — making the per-subdomain TLS-RPT publication discipline THIS pillar documents the STRUCTURAL TRANSPORT-LAYER PREREQUISITE for every per- subdomain sp=-tag rollout-coordination commitment — the DMARC policy rollout spoke documents the per-subdomain sp=-tag rollout-coordination discipline that every per- subdomain TLS-RPT publication THIS pillar documents enables at the per-subdomain ramp-stage commitment boundary; and (iv) per-publisher p=reject terminal-stage commitment consumes the per-publisher per-day TLS-RPT aggregate-failure-evidence stream as the TRANSPORT- LAYER LAST-MILE LEGITIMATE- MAIL-DELIVERY-RISK DIAGNOSTIC SURFACE — the publisher's decision to flip from p=quarantine pct=100 to p=reject depends on the per- publisher per-day TLS-RPT evidence showing the per- receiver per-MX-host transport-layer STARTTLS-handshake + certificate-validation + DANE / MTA-STS policy-enforcement SUCCESS RATE at the per-publisher's outbound MX-host boundary the p=reject commitment will not destructively impact at the transport-layer delivery attempt — the DMARC policy rollout spoke documents the terminal-stage p=reject commitment-decision discipline that every per-publisher TLS-RPT deployment documented on this page produces the transport-layer observability evidence for, at the cross-layer application-layer- commitment-vs-transport- layer-delivery-success coordination boundary. Read the DMARC policy rollout spoke WITH this TLS-RPT pillar when DESIGNING the per- publisher per-domain cross-layer observability deployment (publish the per-domain _smtp._tls.<domain> TXT-RR documented on this page AS A CROSS-LAYER COMPANION to the per-domain _dmarc TXT-RR's per-ramp-stage commitment), and WHEN diagnosing a per-ramp- stage advancement- blocking pattern that correlates with per- publisher TLS-RPT aggregate-failure- evidence emerging at the per-receiver per-MX-host transport-layer boundary.
• DKIM troubleshooting (symptom-driven diagnostic ladder) — the APPLICATION-LAYER-DKIM-VERDICT- DIAGNOSTIC-LADDER-AS-CROSS-LAYER-COMPANION to this RFC 8460 TLS-RPT pillar. Where THIS page documents the transport-layer reporting protocol (the _smtp._tls.<domain> TXT-record publication + the JSON failure- report schema enumerating STARTTLS / certificate / MTA-STS policy-discovery failure modes), the DKIM-troubleshooting spoke is the canonical APPLICATION-LAYER per-symptom diagnostic ladder operators traverse at FOUR cross-layer failure- correlation dimensions: (i) per-receiver TLS-handshake failure dropping the receiver-side connection BEFORE the DKIM-signed payload reaches the verification stack — TLS-RPT surfaces the transport-layer evidence (starttls-not-supported); the troubleshooting spoke documents the receiver-side fallthrough pattern (NO dkim= evidence row emitted in the DMARC RUA aggregate) operators must distinguish from genuine DKIM-publication misconfiguration; (ii) per-receiver certificate-validation failure (certificate-host-mismatch, certificate-expired, certificate-not-trusted) producing the same receiver-side dkim=- evidence absence — the troubleshooting spoke's per-symptom decision tree is the operator-side reference for attributing the missing dkim= row to the transport-layer rather than the application-layer publication discipline; (iii) per-receiver MTA-STS policy-discovery / policy-validation rejection surfacing in TLS-RPT JSON as policy-discovery-failure / policy-validation-failure with zero application-layer DKIM verdict ever emitted — the troubleshooting spoke documents how operators read the absence- of-dkim= row in the DMARC RUA aggregate as the downstream consequence of the TLS-RPT transport-layer rejection THIS page surfaces; (iv) per-receiver clean TLS negotiation followed by application-layer dkim=temperror / dkim=permerror — TLS-RPT surfaces ZERO transport-layer evidence (clean handshake); the DKIM- troubleshooting spoke is the ONLY operator- side reference catalogue surfacing the application-layer root causes (selector-TXT NXDOMAIN, missing v=DKIM1 tag, body-hash mismatch, canonicalisation-mode mismatch). Read the DKIM-troubleshooting spoke ALONGSIDE this TLS-RPT pillar when a per-receiver per-MX-host pair shows a DMARC RUA dkim=fail surge correlating with (or appearing in the absence of) TLS-RPT aggregate-failure evidence for the same pair — the spoke is the canonical application-layer per-symptom diagnostic ladder the TLS-RPT transport-layer infrastructure documented on this page does not cover.
• DNS Record Generator — interactive wizard for building SPF, DKIM, DMARC, BIMI, MTA-STS, CAA, and TLS-RPT records with syntax validation and best-practice defaults.
• Domain Security Checker — live DNS lookups for SPF, DKIM, DMARC, MTA-STS, TLS-RPT, CAA, BIMI, and DNSSEC against any domain.
• DMARC aggregate (RUA) reports — the RFC-7489-§7.2 APPLICATION- LAYER XML-AGGREGATE-EVIDENCE-STREAM companion to this TLS-RPT transport-layer aggregate-evidence- stream reference. Where THIS page documents the RFC-8460 §5 JSON TLS-RPT aggregate-report schema (per-day per-receiver per-policy- domain per-result-type STARTTLS- handshake-failure aggregate stream whose policies[].policy + policies[].summary + policies[].failure_details[] sub-objects enumerate per-MX-target STARTTLS / mta-sts.txt / DANE-TLSA / certificate-validation failure counts), the aggregate- reports spoke is the structurally- paired application-layer per-publisher per-domain RFC-7489- §7.2 XML evidence-stream documenting the THREE per-publisher per-domain operator correlation-points between the two co-published aggregate feedback loops: (i) the per-publisher per-domain application-layer DMARC-alignment- verdict vs transport-layer TLS- handshake-verdict disambiguation layer — when a per-publisher per-domain operator sees aggregate per-receiver per-day delivery anomalies, the per-publisher per- domain operator MUST consult BOTH evidence-streams in parallel: the RUA-aggregate-XML answers the question "did the message reach the per-receiver application-layer DMARC evaluator at all and with what alignment verdict" while the TLS- RPT-aggregate-JSON answers the prior-in-the-stack question "did the SMTP transport-layer STARTTLS handshake to the per-receiver per- MX-target succeed at all"; (ii) the per-publisher per-domain per-source-IP per-destination-MX- target stack-position attribution layer — every per-publisher per-day delivery-volume drop the per-publisher per-domain operator observes in the RUA-aggregate-XML <row><source_ip> + <count> elements has a candidate root-cause partition that lives in the TLS-RPT-aggregate- JSON policies[].summary .total_failure_session_count elements (the per-source-IP per-day volume drop in RUA could be EITHER application-layer DMARC-rejection OR transport-layer STARTTLS-handshake- failure suppressing the per-source- IP per-day delivery entirely); (iii) the per-publisher per-domain operator daily-correlation discipline between the two co-published per- publisher per-domain feedback-loop mailboxes — the per- publisher per-domain rua=mailto: tag publication discipline that feeds the application-layer XML aggregate- stream into the per-publisher per- domain operator's RUA mailbox and the per-publisher per-domain rua=mailto: tag publication discipline at the _smtp._tls.<domain> TLS-RPT TXT record that feeds the transport-layer JSON aggregate- stream into the per-publisher per- domain operator's TLSRPT mailbox are the canonical structurally- paired per-publisher per-domain operator-side aggregate-feedback- loop discipline pair. Read THIS page when DEPLOYING the per- publisher per-domain transport- layer TLS-RPT aggregate-evidence- stream consumption discipline; read the aggregate-reports spoke when DEPLOYING the per-publisher per-domain application-layer DMARC aggregate-evidence-stream consumption discipline the per-publisher per-domain operator MUST correlate with the TLS-RPT- side aggregate-stream daily.
• DMARC for Google Workspace — the WORKSPACE-TENANT-APPLICATION- LAYER-DMARC-RUA-CONSUMPTION-COMPANION to this per-policy-domain transport- layer TLS-RPT JSON-aggregate-stream consumption-discipline reference. Where THIS page documents the per- policy-domain transport-layer _smtp._tls.<domain> TXT publication discipline, the per- policy-domain rua=mailto: publication the per-receiver delivers the per-day per-source-IP STARTTLS-handshake JSON aggregate-evidence to, and the per- publisher per-domain operator's daily TLS-RPT aggregate-stream consumption discipline at the per- policy-domain operator's TLSRPT mailbox, the Workspace-deployment spoke is the STRUCTURAL APPLICATION-LAYER TWIN documenting how the per-Workspace- tenant application-layer per-publisher per-domain DMARC rua-aggregate-XML consumption discipline at the per- tenant operator's RUA mailbox instantiates concretely on Google Workspace at FOUR per-Workspace-tenant- application-layer-DMARC-rua-vs-per- policy-domain-transport-layer-TLS-RPT- rua-structural-pairing dimensions: (i) per-Workspace-tenant _dmarc.<domain> rua=mailto: publication is the application-layer structural twin of per-policy-domain _smtp._tls.<domain> rua=mailto: publication — both are per- domain TXT records at a reserved subdomain label publishing a per- operator aggregate-feedback mailbox the per-receiver delivers per-day aggregate evidence to; the Workspace- deployment spoke documents the per- tenant Google Admin Console DMARC- authoring workflow that produces the application-layer rua=mailto: publication, the structural twin of the per-policy-domain TLS-RPT rua=mailto: publication THIS page documents; (ii) per- Workspace-tenant application-layer DMARC rua-aggregate-XML consumption is the structural twin of per-policy- domain transport-layer TLS-RPT JSON- aggregate-stream consumption — both feed the per-publisher per- domain operator daily aggregate- evidence consumption discipline at the per-operator mailbox; the Workspace-deployment spoke documents the per-tenant operator's RFC 7489 §7.2 rua-aggregate-XML ingestion discipline whose structural twin is the per-policy-domain operator's RFC 8460 §5 TLS-RPT JSON-aggregate ingestion discipline THIS page documents; (iii) per-Workspace- tenant per-publisher per-domain operator's daily correlation between application-layer DMARC rua-aggregate- XML and transport-layer TLS-RPT JSON- aggregate is the canonical two-stream aggregate-evidence consumption discipline — the per-publisher per-domain operator's daily volume attribution (e.g. whether a per-day RUA volume drop is application-layer DMARC-rejection or transport-layer STARTTLS-handshake failure) requires the structurally-paired two-stream correlation discipline; the Workspace- deployment spoke documents the per- tenant application-layer DMARC-side of the structurally-paired pair THIS page documents the transport-layer TLS-RPT- side of; and (iv) per- Workspace-tenant per-domain authoritative DNS-zone publication boundary is the same publication boundary as per-policy-domain TLS-RPT publication — both are published at the per-publisher per- domain authoritative DNS-zone tier; the Workspace-deployment spoke documents the per-tenant authoritative DNS-zone publication discipline whose publication boundary structurally coincides with the per-policy-domain TLS-RPT publication boundary THIS page documents.
• Email authentication glossary — the cluster-wide canonical entity-first DefinedTermSet vocabulary reference whose per-term DefinedTerm JSON-LD entries (RFC 8460 §3 TLS-RPT-policy-record byte-grammar, RFC 8460 §4 TLSRPT-aggregate-report JSON schema, RFC 8461 MTA-STS-policy-mode enum, RFC 7672 DANE TLSA-record-format, STARTTLS-handshake-failure-class taxonomy, certificate-validation-error taxonomy, policy-string-mismatch error) are the per-protocol-concept vocabulary substrate the per-policy-domain TLS-RPT JSON-aggregate-report payload THIS page documents structurally instantiates at the per-receiver-emission boundary. Where THIS page documents the RFC 8460 §4 per- policy-domain per-receiver per-day TLS- RPT JSON-aggregate-report payload schema (the organization-name / date-range / contact-info / report-id / policies[] top-level envelope, the per-policy policy-type + policy-string + policy-domain + mx-host nest, the per- policy summary + failure-details[] tally, the per-failure result-type + sending-mta-ip + receiving-mx-hostname + receiving-mx-helo + receiving-ip + failed-session-count / additional-information / failure-reason-code row emission), the email-authentication- glossary spoke is the DEFINED-TERM- DEFINITION reference documenting the canonical vocabulary substrate every TLS-RPT JSON-aggregate-report payload field structurally instantiates. Four TLS-RPT-PAYLOAD-TO-GLOSSARY- DEFINED-TERM coupling dimensions the glossary spoke documents: (i) per-report policy-type field as per- policy-domain instantiation of the RFC-8461-MTA-STS-vs-RFC-7672-DANE-vs- no-policy DefinedTerm vocabulary — the per-report policy-type: sts / policy-type: tlsa / policy-type: no-policy-found token vocabulary the TLS-RPT JSON payload THIS page documents emits is the per-policy-domain instantiation of the MTA-STS-policy-discovery / DANE-TLSA- record-discovery / no-policy-discovery DefinedTerm vocabulary the glossary catalogues; (ii) per-failure result-type field as per- session instantiation of the STARTTLS- handshake-failure-class DefinedTerm vocabulary — the per-failure result-type: starttls-not-supported / result-type: certificate-host-mismatch / result-type: certificate-expired / result-type: certificate-not-trusted / result-type: validation-failure / result-type: tlsa-invalid / result-type: dnssec-invalid / result-type: sts-policy-fetch-error / result-type: sts-policy-invalid / result-type: sts-webpki-invalid token vocabulary the TLS-RPT payload THIS page documents emits is the per-session instantiation of the STARTTLS-handshake- failure-class + certificate-validation- error + policy-string-mismatch DefinedTerm vocabulary the glossary catalogues; (iii) per-policy policy-string field as per-policy-domain snapshot of the RFC- 8461-MTA-STS-policy-file-byte-grammar DefinedTerm vocabulary — the per-policy policy-string snapshot field the TLS-RPT payload embeds is the per-policy-domain instantiation of the RFC 8461 MTA-STS version: STSv1 / mode: enforce / mode: testing / mode: none / mx: ... / max_age: ... per-policy- file byte-grammar DefinedTerm vocabulary the glossary catalogues; (iv) per-policy policy-domain + mx-host fields as per- policy-domain instantiation of the organizational-domain + Public-Suffix- List + MX-host DefinedTerm vocabulary — the per-policy policy-domain + mx-host field vocabulary the TLS-RPT payload embeds is the per- policy-domain instantiation of the organizational-domain + Public-Suffix- List + MX-host-resolution DefinedTerm vocabulary the glossary catalogues at the per-policy-domain MTA-STS-policy- discovery boundary. Read THIS page when AUTHORING the per-policy-domain TLS-RPT JSON-aggregate-report ingestion discipline; read the email- authentication-glossary spoke when CO-AUTHORING the per-policy-domain canonical DefinedTermSet vocabulary substrate every TLS-RPT payload field the schema THIS page documents structurally instantiates.
• DMARC deployment checklist — the 4-PHASE-ROLLOUT-DISCIPLINE companion to this RFC 8460 SMTP TLS Reporting reference. Where THIS page documents the per-publisher per-policy-domain TLS-RPT publication discipline (the _smtp._tls.<policy-domain> TXT-RR rua= tag carrying the JSON-aggregate-report delivery URI, the per-receiver per-policy-domain per-reporting-window aggregation granularity, the JSON-payload per-policy-domain per-MX-host per-failure-type schema, the per-publisher per-policy-domain TLS-RPT ingestion-pipeline observability surface), the DMARC-deployment-checklist spoke is the APPLICATION-LAYER-DMARC-RUA- AGGREGATE-REPORT-OBSERVABILITY companion documenting the cross- layer observability composition the 4-phase Discovery → Triage → Quarantine → Enforcement progression depends on: Phase 1 (Discovery) publishes p=none with DMARC rua= on the _dmarc.<policy-domain> TXT-RR to receive APPLICATION- LAYER per-message DMARC verdict aggregate-report XML deliveries — but the application-layer per- message verdict surface ONLY observes mail that REACHED the receiver; the per-policy-domain TLS-RPT publication THIS page documents is the TRANSPORT-LAYER observability complement delivering JSON-aggregate-reports about per-SMTP-session TLS encryption-and-integrity outcomes — TLS-handshake failures, policy- evaluation failures, certificate- validation failures, and STS-policy fetch failures the receiver experienced BEFORE the application- layer DMARC verdict could execute. Read together, the two aggregate- report streams give Phase 1 the complete two-layer per-publisher per-domain observability surface the 4-phase rollout requires: application-layer DMARC RUA surfaces every per-sender SPF / DKIM / alignment outcome on mail that COMPLETED transport-layer delivery; TLS-RPT THIS page documents surfaces every transport- layer policy-evaluation outcome on mail the receiver attempted to ingest — including downgrade-attack attempts, certificate-pinning mismatches, and policy-fetch failures that would otherwise silently degrade transport-layer security WITHOUT producing any application-layer DMARC verdict signal. Phase 2 (Triage) cannot cleanly distinguish "missing DKIM signature" from "DKIM signature stripped by transport-layer downgrade" without the TLS-RPT cross-reference; Phase 3 (Quarantine) and Phase 4 (Enforcement) promotions are gated on confirming TLS-RPT shows no receiver-side transport-layer policy-evaluation regression. Read THIS page when AUTHORING the per-publisher per-policy-domain TLS-RPT publication-and-ingestion discipline that powers the transport-layer half of the cross- layer aggregate-report observability surface; read the DMARC-deployment- checklist spoke when AUTHORING the overall 4-phase rollout plan that consumes the application-layer DMARC RUA stream and the transport-layer TLS-RPT stream THIS page documents as the two complementary observability inputs the Phase-1 Discovery / Phase-2 Triage / Phase-3 Quarantine-promotion / Phase-4 Enforcement-promotion gate decisions depend on.
• DMARC for transactional email — the per-publisher per-domain TRANSACTIONAL-EMAIL-DEPLOYMENT companion to this RFC 8460 SMTP TLS Reporting reference. Where THIS page documents the per-publisher per- policy-domain TLS-RPT publication discipline (the _smtp._tls.<policy-domain> TXT-RR rua= tag carrying the JSON-aggregate-report delivery URI, the per-receiver per-policy-domain per-reporting-window JSON-payload per-MX-host per-failure-type schema, the per-publisher per-policy-domain TLS-RPT ingestion-pipeline observability surface), the DMARC- for-transactional-email spoke documents the per-publisher per-domain high- volume transactional-sender DMARC deployment discipline whose per- receiver per-MX-host transport-layer failure-attribution observability TLS-RPT delivers. The composition operates through the per-transactional- sender per-receiver per-MX-host transport-layer-failure-observability gap: per-publisher per-domain transactional senders push high per-day per-publisher per-receiver per-MX-host message volumes through per-ESP outbound MTAs, and any per- receiver per-MX-host transport-layer regression (per-MX-host TLS-handshake failure, per-MX-host certificate- validation failure, per-receiver STS-policy-fetch failure, per-MX-host downgrade-attack attempt) produces per-recipient transactional-email delivery degradation that is INVISIBLE to the per-publisher per-domain DMARC RUA application-layer aggregate-report stream — the receiver never produced a DMARC verdict for the messages because the per-SMTP-session transport-layer failure prevented application-layer evaluation entirely. The per-publisher per-policy-domain TLS-RPT JSON- aggregate-report stream THIS page documents is therefore the ONLY per- publisher per-domain transactional- sender observability surface that captures per-receiver per-MX-host transport-layer-failure attribution — a per-publisher per-domain transactional- sender operator MUST publish TLS-RPT alongside DMARC RUA to achieve complete per-receiver per-MX-host transport-and- application-layer delivery observability. Read THIS page when AUTHORING the per- publisher per-policy-domain TLS-RPT publication discipline; read the DMARC- for-transactional-email spoke when SCALING the per-publisher per-domain transactional-sender DMARC deployment whose per-receiver per-MX-host transport- layer-failure observability the per- publisher per-policy-domain TLS-RPT publication discipline THIS page documents materially provides.
• DKIM cryptography basics (RSA-2048 / Ed25519 / SHA-256) — the MESSAGE-AUTHENTICATION-LAYER- CRYPTOGRAPHIC-PRIMITIVE-PUBLICATION- DISCIPLINE companion to this TLS-RPT transport-layer reporting protocol reference. Where THIS page documents the RFC 8460 TLS-RPT TRANSPORT-LAYER reporting protocol (per-receiver- organisation SMTP-receive-TLS-handshake failure-reporting via the _smtp._tls.<domain> TXT record + the JSON-payload failure- report schema covering certificate- chain validation failures, STARTTLS handshake errors, MTA-STS policy enforcement failures, certificate- not-trusted result-types), the DKIM- cryptography-basics spoke documents the PARALLEL MESSAGE-AUTHENTICATION-LAYER per-publisher per-selector cryptographic- primitive publication discipline (RFC 6376 §3.3 rsa-sha256 / ed25519- sha256 algorithm catalogue, the per- selector 2048-bit RSA modulus floor, the per-publisher key-rotation cadence, the per-selector public-key TXT record v=DKIM1; k=rsa; p=<BASE64-key> byte-shape) whose per-publisher per- selector cryptographic-anchor publication is the structural-parallel message- authentication-layer cryptographic- primitive publication discipline to the per-publisher per-MX-host STARTTLS- certificate-chain cryptographic primitive whose validation failures the TLS-RPT transport-layer reporting pipeline THIS page documents observes. The TLS-RPT- VS-DKIM-CRYPTOGRAPHY cross-reference establishes FOUR structurally-distinct cross-layer cryptographic-primitive- publication coupling dimensions: (i) BOTH protocols depend on per- publisher cryptographic-primitive publication at DNS — DKIM publishes per- selector public-key TXT records; TLS-RPT observability targets per-MX-host STARTTLS-certificate-chain validation whose per-publisher anchoring depends on per-domain MX-RR-set + DANE TLSA RR publication discipline — the per-publisher DNS-rooted-cryptographic- anchor publication substrate is shared; (ii) TLS-RPT observability captures TRANSPORT-LAYER cryptographic failures (X.509 certificate-chain validation errors, STARTTLS handshake errors, DANE TLSA mismatches); DKIM cryptographic-primitive publication feeds MESSAGE-LAYER cryptographic verification (per-message DKIM-Signature rsa-sha256 / ed25519-sha256 validation against the per-selector published key) — the two protocols occupy complementary cryptographic- layer publication / observation dimensions (transport-layer vs message- layer) of the per-publisher per-domain cryptographic-publication stack; (iii) per-publisher DKIM per-selector key-rotation cadence and per-publisher per-MX-host STARTTLS-certificate renewal cadence share an identical operational discipline — both require per-publisher scheduled rotation with DNS-propagation- aware overlap windows — the operator-side per-publisher cryptographic-primitive rotation discipline transfers directly between DKIM per-selector key rotation per RFC 6376 §3.6.1 and per-MX-host STARTTLS- certificate renewal cadence the TLS-RPT pipeline observes failures of; (iv) per-publisher DKIM cryptographic- algorithm-choice (rsa-sha256 vs ed25519- sha256) selection materially determines per-message DKIM-verify-pass evaluation cost the same way per-publisher per-MX- host STARTTLS-certificate cipher-suite + cryptographic-algorithm selection materially determines per-receiver STARTTLS-handshake-pass evaluation cost — the per-publisher cryptographic-primitive-selection discipline transfers directly between the two protocol layers; the DKIM- cryptography-basics spoke documents the per-publisher per-selector cryptographic- primitive-selection discipline whose message-layer evaluation is the structural-parallel of the transport- layer STARTTLS-cipher-suite selection discipline the per-MX-host cryptographic-failure rows observed by the TLS-RPT pipeline THIS page documents capture. Read this TLS-RPT pillar when DEPLOYING the per-publisher per-policy- domain transport-layer-cryptographic- failure-observability publication posture; read the DKIM-cryptography- basics spoke when UNDERSTANDING the message-authentication-layer per- publisher per-selector cryptographic- primitive publication discipline whose per-message DKIM-verify-pass / fail verdict is the structural-parallel message-layer cryptographic-evaluation contract to the transport-layer STARTTLS-handshake-pass / fail observation contract THIS page's TLS-RPT pipeline documents.
• Email security glossary — the TLS-RPT-TRANSPORT-LAYER-VOCABULARY- RESOLVES-TO-CROSS-CLUSTER-EMAIL-SECURITY- TERMINOLOGY-HUB companion to this TLS-RPT pillar reference. Where THIS page documents the per-publisher per-domain TLS-RPT protocol pillar (the RFC 8460 §3 _smtp._tls.<d> publication discipline, the RFC 8460 §4 JSON failure-report format, the 13 canonical result-type values, the per-publisher deployment workflow, the MTA-STS-and-DANE protocol-stack relationship), the email-security- glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every TLS-RPT- pipeline discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term TLS-RPT record-publication vocabulary resolution — the TLS-RPT record-publication vocabulary (TLS-RPT, _smtp._tls underscored attribute-leaf, v=TLSRPTv1 version-stamp, rua= mailto/HTTPS RUA-URI tag, RFC 8460 §3 TXT-RR byte-syntax, per-publisher per-domain reporting- channel publication) THIS page's TLS-RPT pillar structurally references at every per-deployment-step entry is canonically defined in the glossary spoke; the per-publisher per-domain record-publication terminology vocabulary that drives every TLS-RPT- deployment-workflow discussion lives in the glossary's per-tag entry-set; (ii) per-term transport-layer- encryption vocabulary resolution — the transport-layer-encryption vocabulary (opportunistic TLS, STARTTLS extension, SMTP-over-TLS handshake, MTA-MITM, downgrade attack, certificate-validity verification, certificate-chain trust- anchor verification, DNSSEC-validated TLSA-RR, certificate-host-mismatch, certificate-not-trusted) THIS page's TLS-RPT pillar references when describing per-failure-row causation is canonically defined in the glossary spoke; the per-receiver-side TLS- handshake-failure terminology vocabulary that drives every TLS-RPT-failure-row- decode discussion lives in the glossary's per-term transport-layer- encryption entry-set; (iii) per- term TLS-RPT failure-mode vocabulary resolution — the TLS-RPT failure-mode vocabulary (the 13 canonical RFC 8460 §4.3.3 result-type values: starttls-not-supported, certificate-host-mismatch, certificate-not-trusted, certificate-expired, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid) THIS page's TLS-RPT pillar references when describing per- failure-row decode is canonically defined in the glossary spoke; the per-failure-row keyword-set terminology vocabulary that drives every operator-side per-failure-row-triage discussion lives in the glossary's per- term failure-mode-vocabulary entry-set; (iv) per-term cross-layer protocol-stack vocabulary resolution — the cross-layer protocol-stack vocabulary (transport-layer vs application-layer protocol-stack boundary, MTA-STS policy- file publication, DANE TLSA-RR publication, MTA-STS vs DANE protocol- choice, mta-sts.txt policy file, per- MX-host TLSA-RR DNSSEC anchor) THIS page's TLS-RPT pillar references when describing the transport-layer-pillar relationship is canonically defined in the glossary spoke; the per- receiver-side TLS-policy-source terminology vocabulary that drives every TLS-RPT-vs-MTA-STS-vs-DANE-coordination discussion lives in the glossary's per- term protocol-stack-vocabulary entry- set. Read the email-security-glossary spoke alongside this TLS-RPT pillar reference when authoring per-publisher per-domain transport-layer-observability runbooks and per-failure-row-coordination documents that need the shared terminology hub.
• DKIM alignment with DMARC — the PER-MESSAGE-DKIM-D-EQUALS-VS-FROM- DOMAIN-IDENTIFIER-ALIGNMENT-AS-LOAD-BEARING- APPLICATION-LAYER-COMPLEMENT-OF-TLS-RPT- TRANSPORT-LAYER-OBSERVABILITY companion to this RFC 8460 TLS-RPT pillar. Where THIS page documents the per-publisher per-domain TLS-RPT transport-layer cryptographic- channel-evidence-stream at the protocol layer (the per-publisher per-domain _smtp._tls.<domain> TXT-RR v=TLSRPTv1; rua=mailto:... publication, the per-receiver per-day per- MX-IP per-session per-failure-class JSON-aggregate-report payload, the per- publisher per-domain transport-layer STARTTLS-failure observability discipline), the DKIM-alignment-with-DMARC spoke is the APPLICATION-LAYER-DKIM-D-EQUALS-VS-FROM- DOMAIN-IDENTIFIER-ALIGNMENT-AS-STRUCTURAL- COMPLEMENT companion documenting the per- message DKIM-Signature d=-tag vs RFC 5322 From-header organisational- domain alignment evaluation per RFC 7489 §3.1.1 (relaxed = organisational-domain match per Public-Suffix-List walk; strict = exact-domain match) whose per-publisher per-domain application-layer DKIM-aligned- pass rate IS the load-bearing application- layer authentication-evidence-stream. Four TLS-RPT-vs-DKIM-alignment cross-layer coordination dimensions matter at the per- publisher per-domain cross-layer aggregate- evidence-coordination boundary: (i) per- publisher per-domain per-day cross-layer evidence triangulation — when a per- receiver per-publisher per-domain per- message DKIM-fail event surfaces in the per-publisher per-domain DMARC RUA aggregate-XML-report row's auth_results/dkim sub-field, the per-publisher per-domain TLS-RPT JSON- aggregate-report row at the same per- receiver per-MX-IP per-day key provides per-publisher per-domain transport-layer forensic-evidence (e.g., certificate-host-mismatch, starttls-not-supported) that triangulates whether the per-publisher per-domain DKIM-fail is per-message- cryptographic-side or per-transport- downgrade-induced-body-modification side; (ii) per-publisher per-domain per-MX-host DKIM-Signature-body-modification attribution — the per-publisher per-domain TLS-RPT starttls-not-supported failure- mode the TLS-RPT JSON-payload THIS page documents enumerates correlates with the per-publisher per-domain per-message DKIM-Signature-body-hash failure variant (per-receiver-MX-host body-modification during opportunistic-TLS-downgrade intermediate-relay), so the per-publisher per-domain DKIM-alignment-with-DMARC evaluation depends on the per-publisher per-domain TLS-RPT cross-layer evidence- stream for per-message-failure-class root- cause attribution; (iii) per-publisher per-domain per-stream DKIM-d= subdomain- scope vs MTA-STS per-MX-cone scope consistency — when a per-publisher per- domain operates multi-stream signing (per-stream DKIM-Signature d=- subdomain segmentation), the per-publisher per-domain MTA-STS mx: cone publication discipline the TLS-RPT observability stream THIS page documents covers must be coordinated against the per- publisher per-domain per-stream DKIM-d=- subdomain alignment-evaluation discipline the DKIM-alignment-with-DMARC spoke documents at the per-publisher per-domain per-stream cross-layer publication- coordination boundary; (iv) per-publisher per-domain per-message ARC-chain DKIM- alignment recovery through forwarder-hop TLS-encrypted relay — when per-publisher per-domain mail is forwarded through ARC- aware mailing-list-expander hops, the per- publisher per-domain per-message ARC chain- validation IS the per-publisher per-domain application-layer DKIM-alignment-recovery primitive AND the per-publisher per-domain TLS-RPT JSON-payload at the per-receiver per-MX-IP per-day key documents the per- hop transport-layer STARTTLS-encrypted- relay observability the ARC-recovered per-publisher per-domain DKIM-alignment evaluation depends on for per-message- verdict reception integrity. Read THIS page when CONSUMING the per-publisher per- domain TLS-RPT transport-layer cryptographic- channel-evidence-stream; read the DKIM- alignment-with-DMARC spoke when EVALUATING the per-publisher per-domain application- layer DKIM-d=-tag vs RFC 5322 From-header organisational-domain alignment whose per- publisher per-domain application-layer authentication-evidence-stream complements the per-publisher per-domain TLS-RPT transport-layer observability stream THIS page documents at the cross-layer aggregate-evidence-coordination boundary.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) and SPF flattening — the PER-PUBLISHER-PER-DOMAIN-SPF- LOOKUP-PERMERROR-AS-PARALLEL-ENVELOPE- LAYER-OBSERVABILITY-FAILURE-MODE companion to THIS per-publisher per-domain TLS-RPT transport-layer observability reference. Where THIS page documents the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate- report transport-layer observability pipeline (per-publisher per-domain _smtp._tls.<d-domain> TXT-RR v=TLSRPTv1; rua=mailto:tls- rpt@<d-domain> publication + per-MX-host per-day JSON-aggregate-report per-organisation per-failure-type-bucket ingestion + per-publisher per-domain MTA- STS policy-enforcement-failure-rate-floor observability + per-publisher per-domain DANE TLSA-binding-validation-failure-rate- floor observability + per-publisher per- domain TLS-cipher-suite-negotiation-failure- rate-floor observability) at the per- publisher per-domain transport-layer observability stream boundary, the SPF- lookup-limit spoke is the PER-PUBLISHER-PER- DOMAIN-ENVELOPE-MAIL-FROM-LAYER- OBSERVABILITY-FAILURE-MODE catalogue companion at FOUR per-observability-stream- protocol-layer-coordination dimensions: (i) per-publisher per-domain SPF- permerror-disposition observability stream AS structurally-parallel envelope-MAIL- FROM-layer counterpart to per-publisher per- domain MTA-STS-mode-enforce-rejection observability stream THIS page documents the transport-layer counterpart of — the per-publisher per-domain SPF- permerror catastrophic-disposition cascade the SPF-lookup-limit spoke documents (per- publisher per-domain RFC 7208 §4.6.4 10-DNS- lookup cap breach producing per-receiver per-message envelope-MAIL-FROM SPF =permerror disposition cascading to per- publisher per-domain DMARC composite- verdict-fail) IS the per-publisher per- domain envelope-MAIL-FROM-layer per-message catastrophic-rejection-rate-floor observability stream structurally-parallel to the per-publisher per-domain MTA-STS- mode-enforce per-MX-host SMTP-connection- rejection-rate-floor observability stream the per-publisher per-domain TLS-RPT JSON- aggregate report THIS page documents the transport-layer ingestion discipline of; per-publisher per-domain operators reconcile BOTH observability streams at the per- publisher per-domain envelope-MAIL-FROM- layer-and-transport-layer composite observability-floor-monitoring boundary; (ii) per-publisher per-domain SPF- flattening remediation pipeline AS per- publisher per-domain envelope-MAIL-FROM- layer publisher-side remediation pipeline structurally-parallel to per-publisher per- domain MTA-STS policy-file refresh-and- republish pipeline THIS page documents the transport-layer counterpart of — the per-publisher per-domain SPF- flattening remediation pipeline the SPF- lookup-limit spoke documents (per-publisher per-domain daily cron-driven include- cascade resolution to per-publisher per- domain ip4: / ip6: literal mechanisms, per- publisher per-domain monitored-pipeline cron-job-failure on-call alerting discipline, per-publisher per-domain subdomain-delegation to split per-publisher per-mail-stream 10-lookup budget) IS the per-publisher per-domain envelope-MAIL- FROM-layer publisher-side remediation pipeline structurally-parallel to the per- publisher per-domain MTA-STS policy-file refresh-and-republish pipeline THIS page documents the transport-layer counterpart of (per-publisher per-domain /.well-known/mta-sts.txt per-publisher per-MX-host policy-refresh cadence, per-publisher per-domain max_age- driven cache-window discipline, per- publisher per-domain policy-version-bump cache-invalidation protocol); BOTH per- publisher per-domain remediation pipelines preempt per-publisher per-domain catastrophic per-publisher per-domain envelope-and-transport-publication failures at the per-publisher per-domain operational- hygiene-discipline boundary; (iii) per-publisher per-domain SPF + DKIM + DMARC + MTA-STS + TLS-RPT composite-publication-floor coordination AS load-bearing per-publisher per-domain operator-side unified-trust-signal- publication-discipline-floor — the per-publisher per-domain SPF- lookup-budget-audit discipline the SPF- lookup-limit spoke documents (per-publisher per-domain SPF-lookup-count monitoring, per- publisher per-domain include-cascade-depth- audit cadence, per-publisher per-domain ESP-include-list consolidation discipline) IS one load-bearing leg of the per- publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication- floor coordination posture the per- publisher per-domain TLS-RPT publication discipline THIS page documents the transport-layer-observability leg of; per- publisher per-domain operators publish BOTH per-publisher per-domain envelope-MAIL- FROM-layer SPF + per-publisher per-domain transport-layer-observability TLS-RPT publication coordinated at the per- publisher per-domain unified-trust-signal- floor publication-readiness boundary; (iv) per-publisher per-domain composite SPF + DKIM permerror co-occurrence cross-protocol-observability evidence attribution AS load-bearing per-publisher per-domain authoritative-DNS-infrastructure- outage diagnostic input pairing with per- publisher per-domain TLS-RPT per-MX-host per-day transport-layer-observability evidence stream — per- publisher per-domain composite-message rows where the per-publisher per-domain SPF- evaluation returns permerror AND the per- publisher per-selector DKIM-evaluation returns permerror simultaneously the SPF- lookup-limit spoke documents the per- publisher per-domain authoritative-DNS- infrastructure-outage attribution of co-occur per-receiver per-day with per- publisher per-domain per-MX-host TLS-RPT JSON-aggregate-report transport-layer- observability failure-bucket evidence rows the per-publisher per-domain TLS-RPT observability pipeline THIS page documents; per-publisher per-domain operators cross-reference the per-publisher per- domain envelope-and-application-layer composite SPF + DKIM permerror evidence- stream against the per-publisher per-domain per-MX-host transport-layer-observability evidence-stream for per-publisher per- domain authoritative-DNS-infrastructure- outage attribution at the per-publisher per-domain three-layer-cross-protocol composite-observability diagnostic boundary. Read THIS page when INGESTING the per-publisher per-domain TLS-RPT JSON- aggregate-report transport-layer observability stream; read the SPF-lookup- limit spoke when AUDITING the per-publisher per-domain SPF-include-cascade-depth budget against the RFC 7208 §4.6.4 10-DNS-lookup cap whose per-publisher per-domain envelope-MAIL-FROM-layer-permerror- observability stream is the load-bearing sibling per-publisher per-domain authentication-observability stream coordinated with the per-publisher per- domain TLS-RPT transport-layer- observability stream THIS page documents.
• BIMI Verified Mark Certificates (VMC and CMC)
• BIMI SVG Tiny PS requirements — the per-publisher per-domain BIMI SVG-asset HTTPS-host publication-discipline companion to this TLS-RPT transport-layer aggregate-report observability reference. Where THIS page documents the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate-report transport- layer-handshake-failure observability discipline (the per-publisher per-day per- receiver TLS-handshake-success-rate floor + per-receiver per-day STARTTLS-policy-mismatch + per-receiver per-day certificate-validation- failure evidence-stream the operator-side transport-layer-observability surface consumes), the BIMI SVG Tiny PS requirements companion documents the per-publisher per- domain receiver-side brand-indicator SVG asset publication discipline (the per-publisher per- domain BIMI Tiny PS profile structural- element whitelist + per-publisher per-domain BIMI l=<svg-uri> URI HTTPS- host publication cadence + per-publisher per- domain BIMI SVG asset cache-eviction-window discipline) whose per-publisher per-domain BIMI SVG-host HTTPS-resource publication cadence directly consumes the per-publisher per-domain transport-layer TLS-handshake- success-rate floor THIS page's TLS-RPT observability stream emits at FOUR per- publisher per-domain BIMI-SVG-HTTPS-host- publication-vs-TLS-RPT-observability coupling dimensions: (i) per-publisher per-domain BIMI SVG-host HTTPS-resource publication discipline (the per-publisher per- domain BIMI l=<svg-uri> HTTPS-served brand-indicator SVG asset) directly consumes the per-publisher per-day per-receiver TLS-handshake-success-rate floor — when the BIMI SVG asset HTTPS host's TLS- handshake fails at the per-receiver per-day TLS-handshake aggregate-evidence-emission boundary, the per-receiver BIMI-evaluator cannot fetch the SVG asset and per-receiver brand-indicator display eligibility degrades — THIS page's TLS-RPT JSON-aggregate-report per-day per-receiver per-MX TLS-handshake- success-rate evidence-stream IS the operator- actionable observability surface gating the per-publisher per-domain BIMI SVG asset HTTPS- host-publication-readiness diagnosis; (ii) per-publisher per-domain BIMI SVG Tiny PS profile structural-element whitelist publication discipline (the BIMI Group SVG Tiny PS validator-enforced byte- layer restrictions on SVG element types, scripting, animation, and external resource references) as the application-display-layer cryptographic-byte-grammar publication discipline peer-pair of the per-publisher per- domain transport-layer MTA-STS policy-file byte-grammar publication discipline whose per- publisher per-day per-receiver TLS-handshake- failure-evidence-emission discipline THIS page's TLS-RPT JSON-aggregate-report observability stream catalogues — both per- publisher per-domain byte-grammar publication disciplines are operator-side strict-grammar- validation publication-decisions whose per- publisher per-day per-receiver compliance- failure-evidence streams the per-publisher per-domain operator MUST monitor; (iii) per-publisher per- domain BIMI SVG asset HTTPS-host certificate publication discipline (the per-publisher per- domain BIMI SVG-host X.509-certificate ACME- DNS-01-or-HTTP-01-validation renewal cadence) structurally parallels the per-publisher per- domain MTA-STS HTTPS-host X.509-certificate publication discipline at the per-publisher per-domain HTTPS-served-resource-X.509- certificate-publication-cadence coordination boundary — both per-publisher per-domain HTTPS-served-resource-X.509-certificate publication-cadence references emit per- publisher per-day per-receiver TLS-handshake- evidence into THIS page's TLS-RPT JSON- aggregate-report per-day per-receiver per-MX observability stream; and (iv) per-publisher per-day per-receiver TLS-RPT JSON-aggregate-report per-MX per-receiver TLS-handshake-evidence emission discipline (the per-publisher per- day per-receiver per-MX per-receiver-side TLS-handshake-success-vs-failure-evidence stream THIS page documents) as the joint per- publisher per-day per-receiver transport- layer-observability evidence stream feeding both the per-publisher per-domain MTA-STS- policy-file-publication-readiness-diagnosis gate (THIS page's transport-layer- observability operational rationale) AND the per-publisher per-domain BIMI-SVG-asset- HTTPS-host-publication-readiness-diagnosis gate (the BIMI-SVG-requirements companion's operational rationale) at the per-publisher per-domain per-receiver per-day cross-layer transport-and-display-asset-publication evidence-stream composition boundary.
• DKIM canonicalization — the canonical RFC 6376 §3.4 reference on DKIM c= tag header-and-body canonicalization mode-selection (simple/simple vs relaxed/relaxed). Where THIS page documents the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate-report transport-layer observability stream that quantifies per-day per-receiver STARTTLS-handshake-success-rate evidence, the DKIM-canonicalization reference documents the parallel per-publisher per- selector application-layer DKIM-Signature byte-normalisation discipline that determines whether per-receiver per-message DKIM verification succeeds after MTA / forwarder / mailing-list-server header-or-body whitespace-modification at the application- layer (a complementary failure-mode the transport-layer TLS-RPT JSON-aggregate-report observability stream does NOT surface, requiring per-publisher per-domain operators to read both references for composite per- message authentication-and-encryption failure-mode attribution).
• SPF qualifiers explained
• Email authentication overview
• Business Email Compromise (BEC) defence stack — the per-publisher per-policy-domain TLS-RPT-failure-details-observability-as-load- bearing-anti-BEC-transport-layer-MITM-detection companion to this TLS-RPT observability pillar. Where THIS page documents the per- publisher per-policy-domain TLS-RPT JSON- aggregate-report observability-pipeline (the _smtp._tls.<policy-domain> DNS TXT-RR publication discipline per RFC 8460 §3, the policy + summary + failure-details attribution per RFC 8460 §4.3 the per-receiver per-day per-policy-domain transport-layer observability stream emits), the BEC defence-stack spoke documents the per-publisher per-domain anti- BEC transport-layer-MITM defence-detection boundary the TLS-RPT observability underpins. Four coupling axes connect them: (i) per- publisher per-policy-domain TLS-RPT failure-details enumeration of per-day per-receiver starttls-not-supported / certificate-host-mismatch / certificate-expired / tls-protocol-not-supported attribution IS the load-bearing anti-active- STARTTLS-stripping-attack detection primitive — attackers conducting per-message STARTTLS-downgrade MITM to intercept BEC pretext-emails-in-transit (for credential- harvesting or wire-transfer-instruction modification) surface as per-day per-receiver TLS-RPT starttls-not-supported spikes the per-publisher per-policy-domain operator can baseline against; (ii) per-publisher per- policy-domain TLS-RPT certificate-host-mismatch attribution IS the load-bearing anti-MX- host-impersonation MITM-detection primitive — attackers conducting per-policy- domain DNS-cache-poisoning + per-MX-host certificate-presentation MITM to intercept per-policy-domain inbound traffic for BEC reply-thread compromise surface as per-day per-receiver per-policy-domain certificate-host-mismatch failure-attribution spikes; (iii) per- publisher per-policy-domain TLS-RPT pre-MTA- STS-enforce-ramp-readiness diagnostic-baseline IS the load-bearing anti-BEC transport-layer ramp-progression discipline — per- publisher per-policy-domain operators MUST baseline per-receiver per-day TLS-RPT failure-details distribution BEFORE per- publisher per-policy-domain MTA-STS mode: testing → enforce ramp progression closing the anti-BEC transport- layer-MITM defence boundary; (iv) per- publisher per-policy-domain TLS-RPT transport- layer observability IS the structurally- parallel transport-layer-observability companion to the per-publisher per-domain DMARC RUA application-layer-observability + DMARC RUF forensic-failure-attribution observability composing the per-publisher per-domain composite cross-layer anti-BEC observability-portfolio — per-publisher per-domain BEC defence depends on the COMPOSITE per-receiver per-day per-policy- domain transport-layer + application-layer + forensic-failure-attribution observability- portfolio closing the anti-BEC defence- observability-boundary at the per-publisher per-domain composite cross-layer observability-coordination boundary. Read the BEC defence-stack spoke alongside this TLS-RPT observability pillar when AUDITING per-publisher per-policy-domain TLS-RPT failure-details attribution against per-day per-receiver anti-BEC MITM- detection baseline, when AUTHORING per- publisher per-policy-domain TLS-RPT observability-ramp ahead of MTA-STS mode: enforce progression closing the anti-BEC transport-layer-MITM defence-boundary, or when PLANNING per- publisher per-policy-domain composite cross- layer anti-BEC observability-portfolio sequencing against TLS-RPT + DMARC RUA + RUF composite per-receiver per-day per-publisher per-domain observability-stream coordination.
• DMARC multi-domain strategy
• Phishing protection
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF-ENVELOPE-MAIL-FROM-LAYER-MECHANISM-CLASS-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-COMPANION-TO-PER-PUBLISHER-PER-DOMAIN-TLS-RPT-TRANSPORT-LAYER-AGGREGATE-OBSERVABILITY-PUBLICATION-DISCIPLINE companion at four per-publisher per-domain SPF-mechanism-vs-TLS-RPT-transport-layer-observability coupling dimensions: (i) per-publisher per-domain SPF TXT-RR publication at apex-domain with mechanism-class vocabulary per RFC 7208 §5 IS structurally parallel envelope-MAIL-FROM-layer DNS-publication-discipline primitive to per-publisher per-domain TLS-RPT TXT-RR publication at _smtp._tls.<domain> per RFC 8460 THIS page documents the transport-layer aggregate-observability publication-discipline of — both per-publisher per-domain DNS-TXT-RR-published publication-discipline references jointly compose the per-publisher per-domain composite cross-protocol cross-layer DNS-publication-discipline floor; (ii) per-publisher per-domain SPF mechanism-class evaluation surfaces in DMARC policy_evaluated/spf per-row attribution per RFC 7489 §5.6.2 IS structurally parallel application-layer aggregate-observability companion to per-publisher per-domain TLS-RPT JSON-aggregate-report transport-layer policy + summary + failure-details per-event-type attribution per RFC 8460 §4 — both per-publisher per-domain receiver-emission evidence-streams surface per-publisher per-domain operator-actionable cross-layer drift-closure visibility at the composite cross-layer-observability coordination boundary; (iii) per-publisher per-domain SPF 10-DNS-lookup-cap budget per RFC 7208 §4.6.4 IS structurally parallel envelope-MAIL-FROM-layer DNS-publication-discipline-budget primitive to per-publisher per-domain TLS-RPT JSON-aggregate-report per-day per-MX-host per-failure-class attribution publication-and-collection budget — both per-publisher per-domain operator-side publication-budget references are per-publisher per-domain operational-decision-matrix primitives at the per-publisher composite cross-layer DNS-publication-budget coordination boundary; (iv) per-publisher per-domain SPF mechanism-class publication-discipline drift (premature -all hardfail cutover surfacing as per-source-IP per-day DMARC RUA spf=fail attribution-distortion + permerror on 10-DNS-lookup-cap exhaustion surfacing as SPF-aligned-pass-rate floor regression) IS structurally parallel envelope-MAIL-FROM-layer publication-discipline-drift class to per-publisher per-domain TLS-RPT TXT-RR DNS-publication-discipline drift surfacing as transport-layer observability blind-spot the TLS-RPT primer THIS page documents the per-publisher per-domain transport-layer-failure-mode aggregate-observability publication-discipline of materially depends on for cross-layer publication-discipline drift-closure visibility floor preservation.
• DKIM for Microsoft 365
• DMARC alignment — the PER-PUBLISHER-PER-DOMAIN-DMARC- APPLICATION-LAYER-ALIGNMENT-EVALUATION companion to this TLS-RPT transport-layer aggregate-observability reference at four cross-layer aggregate-evidence-stream coupling dimensions: (i) per-publisher per-domain DMARC RUA aggregate-XML evidence stream per RFC 7489 §7.2 surfacing per-message policy_evaluated/dkim + policy_evaluated/spf + auth_results/dkim + auth_results/spf per-receiver per-day alignment-evaluation attribution IS structurally parallel application-layer aggregate-observability evidence-stream to per-publisher per-domain TLS-RPT JSON- aggregate-report transport-layer evidence stream per RFC 8460 §4 surfacing per-receiver per-day per-MX-host policy + summary + failure-details STARTTLS-handshake transport-layer attribution THIS page documents the publication-discipline of — both per- publisher per-domain receiver-emission aggregate-evidence streams jointly compose the per-publisher per-domain composite cross-layer per-day per-receiver observability floor; (ii) per-publisher per-domain DMARC alignment-mode publication-decision (adkim=r/ adkim=s + aspf=r/ aspf=s per RFC 7489 §6.3) IS structurally parallel application-layer publication-decision to per-publisher per- domain MTA-STS mode: testing vs mode: enforce transport- layer publication-decision whose per- receiver per-day TLS-RPT sts-policy-fetch-error / sts-policy-invalid result-type attribution THIS page documents the observability publication-discipline of; (iii) per-publisher per-domain DMARC composite-verdict aligned-pass disjunction per RFC 7489 §3.1.1 (any-DKIM-aligned- pass OR SPF-aligned-pass = DMARC composite alignment) per-message verdict-attribution surfacing in DMARC RUA per-row policy_evaluated/disposition attribution IS structurally parallel application-layer per-message verdict- attribution stream to per-publisher per- domain TLS-RPT JSON-aggregate-report failure-details[] result-type per-day per-MX- host transport-layer per-failure-class attribution stream THIS page documents the publication-discipline of; (iv) per- publisher per-domain DMARC alignment- evaluation publication-discipline drift (premature p=reject + adkim=s + aspf=s strict-mode cutover surfacing as per-receiver per-day RUA aligned-pass-rate regression) IS structurally parallel application-layer publication-discipline-drift class to per- publisher per-domain TLS-RPT TXT-RR publication-discipline drift surfacing as transport-layer observability blind-spot the TLS-RPT primer THIS page documents the per-publisher per-domain transport-layer- failure-mode aggregate-observability publication-discipline of materially depends on for cross-layer publication- discipline drift-closure visibility floor preservation. Read the DMARC alignment spoke when COORDINATING per-publisher per- domain composite cross-layer application- and-transport-layer aggregate-observability publication-discipline against the per- publisher per-domain DMARC alignment-mode + MTA-STS enforcement-mode publication- decision boundaries the TLS-RPT observability stream THIS page documents observes.
• DMARC for shared-hosting — the per-publisher per-domain TLS-RPT transport-layer aggregate-observability primer companion at four per-publisher per-domain TLS-RPT-observability-vs-shared-hosting-DMARC-deployment coupling dimensions: (i) per-shared-hosting-tenant per-custom-domain DMARC RUA aggregate-XML evidence stream per RFC 7489 §7.2 (with `policy_evaluated/dkim` + `policy_evaluated/spf` + `auth_results/dkim` + `auth_results/spf` per-row per-source-IP per-day attribution surfacing per-tenant per-custom-domain DKIM-aligned-pass-rate-floor and SPF-aligned-pass-rate-floor under shared-IP-pool egress) IS structurally parallel application-layer per-tenant per-custom-domain aggregate-observability evidence-stream to per-shared-hosting-tenant per-policy-domain TLS-RPT JSON-aggregate-report per-day per-MX-host per-failure-class attribution stream THIS page documents — both per-tenant per-custom-domain per-day per-receiver per-leg aggregate-observability evidence-stream references coordinate at the per-shared-hosting-tenant per-custom-domain composite application-and-transport-layer aggregate-observability coordination boundary the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of structurally depends on; (ii) per-shared-hosting-tenant per-custom-domain shared-MX-cluster intermediate-relay STARTTLS-handshake failures surfacing in per-tenant per-policy-domain TLS-RPT `failure-type: starttls-not-supported` / `certificate-host-mismatch` attribution per RFC 8460 §4.3 IS the load-bearing per-tenant per-custom-domain transport-layer observability evidence-stream gating per-tenant per-custom-domain DMARC ramp-readiness decision the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain Step 5 (Advance from `p=quarantine` to `p=reject`) terminal-stage enforcement-ramp publication-discipline of structurally depends on for per-tenant per-custom-domain composite transport-layer-aware ramp-progression; (iii) per-shared-hosting-tenant per-custom-domain MTA-STS / DANE / STARTTLS publication-discipline drift surfacing in per-tenant per-policy-domain TLS-RPT `sts-policy-fetch-error` / `sts-policy-invalid` / `dane-mismatch` / `dnssec-invalid` attribution per RFC 8460 §4.3 IS structurally parallel per-tenant per-custom-domain transport-layer per-failure-class catalogue THIS page documents the per-publisher per-policy-domain per-failure-class catalogue of, to per-tenant per-custom-domain DMARC RUA per-row `auth_results/dkim=permerror` + `auth_results/spf=permerror` attribution surfacing application-layer per-tenant per-custom-domain DKIM/SPF publication-discipline drift the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM publication-discipline of structurally depends on; (iv) per-shared-hosting-tenant per-custom-domain shared-MX-cluster cross-tenant TLS-RPT publication contention (per-tenant per-policy-domain `_smtp._tls.<custom-domain>` TXT-RR publication-discipline floor coordination with per-shared-hosting-cluster per-MX-host-DV-cert validity-window publication-discipline) IS the load-bearing per-tenant per-custom-domain composite cross-tenant transport-layer observability publication-discipline whose per-tenant per-custom-domain per-day per-MX-host per-failure-class attribution stream the per-tenant per-custom-domain DMARC ramp-readiness decision the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain SPF + DKIM + DMARC composite publication-discipline coordination of structurally depends on for per-tenant per-custom-domain composite cross-layer ramp-readiness publication-discipline coordination floor.
• include vs ip4 vs a vs mx — the SPF-mechanism-selection companion to this TLS-RPT explainer. TLS-RPT JSON aggregate reports attribute per-day TLS delivery outcomes per receiving mail-exchanger host per RFC 8460 §4.3, and that per-MX-host reporting axis is the same MX-record host set the SPF mx mechanism resolves — so the publisher's decision to authorize senders via mx / a or to flatten them into explicit ip4: ranges under the ten-DNS-lookup cap is taken over the same mail-exchanger inventory TLS-RPT observes. Read the mechanism-selection spoke when correlating the SPF authorization host set with the per-MX-host TLS-RPT delivery stream.
• Why SPF alone is insufficient — the protocol-layer rebuttal of the “SPF is enough” mental model. SPF is one necessary-but-insufficient leg at the application layer (it authorises only the envelope and breaks under forwarding), just as TLS-RPT documents the transport-layer integrity SPF/DKIM/DMARC do not address — the defense-in-depth case for the full SPF + DKIM + DMARC + MTA-STS/TLS-RPT stack.
• DKIM selectors — the application-layer signing-key pointer that sits one layer above the transport integrity this page reports on. TLS-RPT surfaces STARTTLS and certificate regressions at the transport layer; the DKIM selector names the <selector>._domainkey.<domain> TXT-RR whose published public key is the trust anchor for every d=-aligned DKIM pass DMARC depends on. Just as TLS-RPT gives an operator visibility to rotate an expiring certificate before it breaks delivery, the selector namespace is where the operator stages and rotates the signing keys before a stale one silently fails authentication. Read the DKIM selectors spoke for the application-layer half of the defense-in-depth stack this transport-layer reporting protocol completes.
• Email spoofing explained — the threat-class reference whose seven-technique taxonomy includes the TLS-downgrade / STARTTLS-stripping transport-layer variant; the TLS-RPT JSON stream this page documents is the observability feed that proves whether that transport-layer spoofing surface is actually being closed in production, complementing the message-layer SPF, DKIM, and DMARC anti-spoofing legs.
• DKIM signatures explained — the message-layer counterpart to this transport-layer reporting protocol. TLS-RPT proves the channel encryption held in transit; the DKIM-Signature header documented there proves the message itself was not altered, its b=/bh=/d=/s= tag grammar carrying the cryptographic binding a receiver verifies — read it for the application-layer half of the integrity story this transport-layer feed observes.
• RFC 8460 - SMTP TLS Reporting — the TLS-RPT specification itself.
• RFC 8461 - SMTP MTA Strict Transport Security — the MTA-STS policy standard TLS-RPT reports against.
• RFC 7672 - DANE for SMTP — the DNSSEC-based alternative transport-security policy.
• 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.

12. Ingest your TLS-RPT reports now

DMARC Analyzer's TLS-RPT parser (includes/TlsRptParser.php) ingests JSON and GZIP-compressed reports via the upload page or via the same IMAP / Microsoft Graph mailbox-fetch pipeline used for DMARC aggregate reports. Reports surface in the dashboard as per-policy success rates, failure breakdowns by result-type, and per-MX session histograms so you can audit MTA-STS / DANE rollout health in one place. The Domain Security Checker also performs live _smtp._tls lookups against any domain to verify a TLS-RPT record is syntactically valid and the rua= destination is reachable.

Check my TLS-RPT record Sign up — Free plan