DMARC Analyzer

TL;DR

A TLS-RPT report is a JSON document (MIME application/tlsrpt+json or application/tlsrpt+gzip when compressed) whose top-level object carries metadata plus a policies[] array. The on-the-wire schema is defined by RFC 8460 §4.

• Top-level fields: organization-name (free-form), date-range (ISO 8601 UTC start/end), contact-info, report-id (dedup key), policies[].
• Per-policy fields: policy.policy-type is one of sts, tlsa, or no-policy-found; policy.policy-string reproduces the evaluated policy verbatim; policy.policy-domain and policy.mx-host identify the scope.
• Summary: summary.total-successful-session-count and summary.total-failure-session-count — both counts are per SESSION, not per message.
• Failure details: failure-details[] array of per-failure-shape records. result-type classifies the failure into one of 12 canonical values; failed-session-count aggregates sessions with the same (result-type, sending-mta-ip, receiving-mx-hostname) shape.
• 12 canonical result-type values: starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid, dane-required, certificate-error.
• Filename convention (mailto: delivery): <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz]. Exclamation-mark separator. Tracks the 24-hour aggregation window.
• Dedup key: the top-level report-id. Receivers MUST skip re-ingestion of any report whose report-id has already been processed.

DMARC Analyzer ingests TLS-RPT reports and surfaces per-policy session counts and per-result-type breakdowns in the dashboard. The Domain Security Checker confirms the TLS-RPT DNS record that triggers report delivery.

1. What "JSON report format" means for TLS-RPT (and where the syntax lives)

TLS-RPT is a layered specification. The SYNTAX LAYER defines how the recipient domain advertises a reporting destination at the DNS — the v=TLSRPTv1; rua=<uri-list> record at _smtp._tls.<domain> plus the cross-domain authorisation record at <recipient>._report._smtp._tls.<external>. The SEMANTIC LAYER defines what the actual report document looks like once delivered: the JSON schema, field semantics, result-type catalogue, MIME types, filename conventions, and redelivery rules.

This page covers the SEMANTIC LAYER exhaustively. The syntax layer is covered by the sibling reference pages:

• TLS-RPT DNS record syntax — the focused byte-level reference for the _smtp._tls.<domain> TXT record per RFC 8460 §3 (v=TLSRPTv1, rua=, schemes, cross-domain authorisation, 255-octet chunking).
• TLS-RPT explained — the protocol pillar — the whole-protocol survey (what TLS-RPT is, how it works, deployment workflow, relationship to MTA-STS and DANE).

Why the schema layer matters independently: the report-format semantics determine what an ingestion pipeline can DO with the data. A parser that does not understand policy-type=no-policy-found loses the visibility-into-opportunistic-TLS signal entirely. A parser that conflates failed-session-count with message-count produces misleading dashboards. A parser that does not dedup on report-id double-counts redelivered reports. The schema-layer failure modes are operator-introduced and trivially avoidable once the schema is understood. Most "my TLS-RPT dashboard numbers do not match my MTA logs" tickets trace back to a schema-layer misunderstanding.

The canonical TLS-RPT report document:

{
  "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"
        }
      ]
    }
  ]
}

Every section below documents one object or field in this schema.

2. Top-level fields (RFC 8460 §4.1)

The top-level JSON object carries five fields plus the policies[] array.

organization-name

Type: string (free-form, UTF-8).
Required: yes.
Semantics: the human-readable name of the reporting organisation. Used for dashboard display and reporter attribution. Examples: "Google Inc.", "Microsoft Corporation", "Yahoo!". Not interpreted programmatically by receivers — used for display only.

date-range

Type: object with two ISO-8601 string fields.
Required: yes.
Semantics: the time window the aggregated counts cover. start-datetime is the inclusive start of the window; end-datetime is the inclusive end. RFC 8460 §4.1 specifies ISO 8601 UTC with the Z suffix (2026-05-17T00:00:00Z). The canonical window length is 24 hours.

contact-info

Type: string (free-form).
Required: yes (may be empty).
Semantics: follow-up contact channel for the reporter — usually an email address or operator-portal URL where the recipient operator can ask questions about the report. Not parsed programmatically.

report-id

Type: string (reporter- defined opaque identifier).
Required: yes.
Semantics: reporter- assigned unique identifier for the report document. Receivers MUST use this as the dedup key when ingesting redelivered reports. Format is reporter-defined; Google uses ISO 8601 timestamps concatenated with the policy domain, Microsoft uses GUIDs. Treat as opaque at ingestion.

policies[]

Type: array of policy objects (see §3).
Required: yes (may be empty array).
Semantics: one entry per distinct recipient policy seen during the aggregation window. The vast majority of reports contain exactly one entry; reports covering multiple recipient domains or mixed sts+tlsa+no-policy-found observations contain multiple entries.

3. The policy object (RFC 8460 §4.2)

Each entry in policies[] contains a policy object identifying which policy the reporter evaluated.

policy.policy-type

Type: enum-string, one of sts / tlsa / no-policy-found.
Required: yes.
Semantics: sts means the sender evaluated an MTA-STS policy (RFC 8461). tlsa means the sender evaluated a DANE TLSA record (RFC 7672). no-policy-found means neither applied — the session used opportunistic TLS or plaintext. Each value implies a different shape for the policy-string field.

policy.policy-string

Type: array of strings.
Required: yes (may be empty for no-policy-found).
Semantics: the verbatim policy that was evaluated, reproduced line-by-line. For policy-type=sts this is the per-line content of the retrieved mta-sts.txt file (e.g., ["version: STSv1", "mode: enforce", "mx: mail.example.com", "max_age: 604800"]). For policy-type=tlsa this is the TLSA resource-record values formatted as strings. For policy-type=no-policy-found this is typically an empty array ([]).

policy.policy-domain

Type: string (DNS name).
Required: yes.
Semantics: the recipient domain whose policy was evaluated. Typically the same as the To:-header recipient domain but may differ when the sender follows CNAMEs or when multiple policy domains share an MX.

policy.mx-host

Type: string (DNS name or wildcard pattern).
Required: no — present when the policy named a specific MX.
Semantics: the MX hostname (or wildcard pattern from the MTA-STS policy) involved in this aggregation bucket. For policy-type=sts this is one of the mx: entries in the MTA-STS policy file.

4. The summary object (RFC 8460 §4.2)

Each policy entry includes a single summary object with two integer counts.

summary.total-successful-session-count

Type: non-negative integer.
Required: yes.
Semantics: count of inbound SMTP sessions that succeeded under the policy during the window. "Success" means the sender's TLS validation passed and the session proceeded (i.e., the policy did not cause the connection to abort). Per SESSION, not per MESSAGE — a single TCP connection may carry multiple messages.

summary.total-failure-session-count

Type: non-negative integer.
Required: yes.
Semantics: count of inbound SMTP sessions that failed the policy. This is the sum of all failure-details[].failed-session-count entries in the same policy. Verifying that the sum matches the total-failure-session-count is a good sanity check for ingestion pipelines.

5. The failure-details[] array (RFC 8460 §4.3)

Each policy entry includes an array of per-failure-shape records. Each entry describes a distinct failure mode aggregated over the window, deduplicated by the (result-type, sending-mta-ip, receiving-mx-hostname) tuple.

result-type

Type: enum-string, one of 12 canonical values (see §6).
Required: yes.
Semantics: classifies the failure into one of the canonical categories defined in RFC 8460 §4.3. Determines the operator remediation step.

sending-mta-ip

Type: string (IPv4 or IPv6 address).
Required: yes.
Semantics: the IP address (IPv4 or IPv6) of the sending MTA that attempted the TLS session. Used to attribute the failure to a specific outbound IP. To identify the operator, do a reverse-DNS / WHOIS lookup on the IP. Not the HELO/EHLO hostname, the From: header domain, or the MAIL FROM envelope.

receiving-mx-hostname

Type: string (DNS name).
Required: yes.
Semantics: the MX hostname the sender attempted to deliver to. One of the values in the recipient domain's MX RRset.

receiving-mx-helo

Type: string (DNS name).
Required: no.
Semantics: the EHLO/HELO identity the receiving MX advertised when the connection was established. Usually equal to receiving-mx-hostname but may differ when the MX is behind a load-balancer with a separate HELO name.

receiving-ip

Type: string (IPv4 or IPv6 address).
Required: no.
Semantics: the IP address of the specific MX instance hit. Useful when the operator runs multiple backends behind a single hostname. Reporters MAY omit it for policy-fetch-layer failures where no TCP connection occurred.

failed-session-count

Type: non-negative integer.
Required: yes.
Semantics: count of sessions matching this failure shape during the window. Per SESSION, not per MESSAGE.

additional-information

Type: string (URL or free-form).
Required: no.
Semantics: reporter- specific incident pointer — typically a URL to an incident page in the reporter's operations portal. Stored verbatim by receivers; not parsed.

failure-reason-code

Type: string (reporter-defined identifier).
Required: no.
Semantics: a more machine-readable identifier complementing result-type. Reporter- defined; common values include OpenSSL or BoringSSL error names ("X509: cert SAN does not include MX hostname", "X509: certificate has expired", "DANE: TLSA certificate mismatch").

6. The 12 canonical result-type values (RFC 8460 §4.3)

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.

7. MIME types (application/tlsrpt+json and application/tlsrpt+gzip)

RFC 8460 §4 defines two MIME types for TLS-RPT report delivery:

application/tlsrpt+json

Uncompressed UTF-8 JSON document. Used for small reports (typically under 50KB) and as the default for HTTPS POST delivery. Receiver parses the body directly as JSON.

application/tlsrpt+gzip

Gzip-compressed JSON document. The report body is a single gzip stream that decompresses to the application/tlsrpt+json payload. Reporters typically use this when the uncompressed JSON exceeds approximately 50KB; gzip cuts the size by 80% or more for repetitive aggregated data. Receiver MUST gunzip before parsing.

For HTTPS delivery, the MIME type is conveyed in the Content-Type request header. For mailto: delivery, the MIME type is conveyed in the Content-Type of the email attachment and the filename suffix (.json vs .json.gz) provides a redundant signal.

Some receivers also accept the older application/x-gzip or application/gzip MIME types as fallbacks for legacy reporters that have not migrated to application/tlsrpt+gzip. Robust ingestion pipelines inspect the body's first two bytes — the gzip magic number 1F 8B — to decide whether to decompress, ignoring the declared MIME type when it conflicts with the actual body shape.

8. The mailto: attachment filename convention

For mailto: delivery, RFC 8460 §5.1 specifies the attachment filename as:

<reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz]

Four exclamation-mark-separated components:

<reporter>

The reporting organisation's domain (e.g., google.com, outlook.com).

<policy-domain>

The recipient domain whose policy the report covers (e.g., example.com).

<unix-start>

Unix epoch seconds at the start of the 24-hour aggregation window.

<unix-end>

Unix epoch seconds at the end of the 24-hour aggregation window.

Example:

google.com!example.com!1747353600!1747439999.json.gz

Meaning: Google reporting on example.com for the 24-hour window starting 2026-05-15T00:00:00Z, gzip- compressed. The exclamation-mark separator lets receivers sort filenames lexically by reporter then domain then time without fancy parsing. The .json suffix indicates uncompressed; .json.gz indicates gzip.

Receivers SHOULD use the filename for log routing and operational tracking, and use the in-body report-id for semantic deduplication.

9. Redelivery and deduplication (report-id semantics)

Reporters MAY redeliver reports if the initial delivery failed (5xx HTTP response, mailbox bounce, network timeout) or if internal reporter operations re-run the aggregation pipeline. Redelivered reports carry the SAME report-id as the original; receivers MUST use report-id as the deduplication key.

Operational rule: ingestion pipelines maintain a set of seen report-id values (typically indexed in a database with a unique constraint on the column). On every incoming report, the pipeline checks the set; if the report-id is already present, the report is logged as a duplicate and the parse-and-store step is skipped.

Dedup window: recipients typically retain seen report-id values for the report retention window (often 30-90 days). Older reports are unlikely to be redelivered after that horizon.

Cross-reporter collisions: different reporters MAY use overlapping report-id formats (e.g., two reporters both using ISO 8601 timestamps). Robust receivers dedup on the tuple (organization-name, report-id) rather than report-id alone to avoid the rare cross-reporter collision case. RFC 8460 does not mandate this but it is a defensive pattern.

Backfill semantics: some reporters provide a "backfill" mechanism where the operator can request historical reports for a date range. The backfill API typically reuses the original report-id values from the original aggregation window — so a well-implemented receiver dedupes the backfilled reports against the originally- received ones without operator intervention.

10. Canonical examples

Example 1 — minimal report, no-policy-found, all successes:

{
  "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_001",
  "policies": [
    {
      "policy": {
        "policy-type":   "no-policy-found",
        "policy-string": [],
        "policy-domain": "example.com"
      },
      "summary": {
        "total-successful-session-count": 5000,
        "total-failure-session-count":    0
      },
      "failure-details": []
    }
  ]
}

Example 2 — MTA-STS report with a certificate-host-mismatch failure:

{
  "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_002",
  "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"
        }
      ]
    }
  ]
}

Example 3 — multi-failure report (sts-policy-fetch-error + starttls-not-supported):

{
  "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_003",
  "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": 12000,
        "total-failure-session-count":    105
      },
      "failure-details": [
        {
          "result-type":           "sts-policy-fetch-error",
          "sending-mta-ip":        "203.0.113.10",
          "receiving-mx-hostname": "mail.example.com",
          "failed-session-count":  100,
          "failure-reason-code":   "HTTP 503 from mta-sts.example.com"
        },
        {
          "result-type":           "starttls-not-supported",
          "sending-mta-ip":        "203.0.113.20",
          "receiving-mx-hostname": "backup.example.com",
          "failed-session-count":  5,
          "failure-reason-code":   "EHLO response missing STARTTLS"
        }
      ]
    }
  ]
}

Example 4 — DANE TLSA report:

{
  "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_secure.example_001",
  "policies": [
    {
      "policy": {
        "policy-type":   "tlsa",
        "policy-string": [
          "3 1 1 1234567890abcdef1234567890abcdef1234567890abcdef1234567890abcd"
        ],
        "policy-domain": "secure.example",
        "mx-host":       "mail.secure.example"
      },
      "summary": {
        "total-successful-session-count": 800,
        "total-failure-session-count":    2
      },
      "failure-details": [
        {
          "result-type":           "tlsa-invalid",
          "sending-mta-ip":        "2001:db8::1",
          "receiving-mx-hostname": "mail.secure.example",
          "failed-session-count":  2,
          "failure-reason-code":   "DANE: TLSA hash mismatch after cert rotation"
        }
      ]
    }
  ]
}

Example 5 — multi-policy report (two policy domains in a single document):

{
  "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_multi_001",
  "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": 10000,
        "total-failure-session-count":    0
      },
      "failure-details": []
    },
    {
      "policy": {
        "policy-type":   "no-policy-found",
        "policy-string": [],
        "policy-domain": "sub.example.com"
      },
      "summary": {
        "total-successful-session-count": 500,
        "total-failure-session-count":    1
      },
      "failure-details": [
        {
          "result-type":           "starttls-not-supported",
          "sending-mta-ip":        "203.0.113.5",
          "receiving-mx-hostname": "sub.example.com",
          "failed-session-count":  1
        }
      ]
    }
  ]
}

11. Common ingestion mistakes

Ten canonical ingestion-pipeline failure modes, enumerated as a punch list. Every one produces incorrect dashboard numbers or silent data loss even when the upstream reports are well-formed.

1. Counting failed-session-count as messages — the field is per SESSION, not per message. A dashboard labelling the count as "failed messages" misleads operators; label as "failed sessions".
2. Not deduplicating on report-id — redelivered reports double-count if the ingestion pipeline does not maintain a seen-id set. Use a UNIQUE constraint on the report_id column.
3. Ignoring policy-type=no-policy-found — pipelines that filter for sts+tlsa only lose the opportunistic-TLS visibility signal. Index every policy-type.
4. Not gunzipping application/tlsrpt+gzip — parsing the gzip-compressed body as JSON produces a parse error. Inspect the body's first two bytes (gzip magic 1F 8B) before parsing.
5. Conflating sending-mta-ip with From: header domain — they are different identities. sending-mta-ip is the IP address of the connecting sending MTA, not the message-author identity.
6. Ignoring failure-details=[] reports — successful aggregation windows produce empty failure-details arrays. These are NOT errors; they are the baseline "everything was fine" data operators need for trend analysis.
7. Treating certificate-error as cert-trust failure — certificate-error is the legacy catch-all category. Inspect additional-information / failure-reason-code for the specific cause before assigning a remediation.
8. Hard-failing on unknown result-type values — future RFC updates may add new result-type values. Robust ingestion pipelines log unknown values but store the report anyway under an "other" category.
9. Not validating that summary.total-failure-session-count equals the sum of failure-details[].failed-session-count — mismatches indicate either a reporter bug or a truncation during delivery. Worth a log warning.
10. Storing policy-string as a single string — the field is an array of strings (per-line policy content). A pipeline that joins it before storing loses round-tripping fidelity for operator audit.

DMARC Analyzer's ingestion pipeline is built to avoid all ten of these failure modes. See help_tls_rpt_explained.php §7 for the receiver-side architecture.

12. Frequently asked questions

What is the difference between application/tlsrpt+json and application/tlsrpt+gzip?

They are the two MIME types RFC 8460 §4 defines for TLS-RPT report delivery. application/tlsrpt+json carries the JSON document verbatim (uncompressed UTF-8). application/tlsrpt+gzip carries the same JSON document gzip-compressed; the report body is a single gzip stream that decompresses to the application/tlsrpt+json payload. Reporters typically use application/tlsrpt+gzip when the uncompressed JSON exceeds approximately 50KB because gzip cuts the size by 80% or more for repetitive aggregated data. The filename suffix follows: .json for uncompressed, .json.gz for gzipped. A receiver MUST inspect the MIME type (for HTTPS delivery) or the filename suffix (for mailto: delivery) to decide whether to gunzip before parsing. Some receivers also accept the older application/x-gzip or application/gzip MIME types as fallbacks but the application/tlsrpt+gzip type is the canonical one.

Is failed-session-count counting per-message or per-session?

Per-session, not per-message. RFC 8460 §4.3 specifies failed-session-count as the number of TLS-failed SMTP sessions (TCP connections that attempted STARTTLS or evaluated the TLS policy and failed) within the 24-hour window, deduplicated by the (result-type, sending-mta-ip, receiving-mx-hostname) shape. A single SMTP session may carry zero, one, or many messages depending on connection reuse and pipelining — so failed-session-count is typically smaller than the message-level count. When troubleshooting, the operator interprets failed-session-count as "this many TLS-handshake attempts from this sending MTA hit this failure" rather than "this many emails were affected". For message-level metrics, cross-reference with DMARC RUA reports which count messages directly.

What does policy-type=no-policy-found mean?

It means the sending MTA found no MTA-STS policy and no DANE TLSA record for the recipient domain — the session used opportunistic TLS (or plaintext if STARTTLS was not advertised) with no enforced TLS policy to evaluate. RFC 8460 §4.2 specifies no-policy-found as the policy-type for sessions where neither MTA-STS (RFC 8461) nor DANE (RFC 7672) provided a binding policy. The summary still counts successful and failed sessions, but the failure-details entries describe failures of opportunistic TLS rather than policy-enforcement failures. Operationally, no-policy-found entries are useful for assessing the baseline TLS health of the recipient domain BEFORE deploying MTA-STS or DANE — the policy-type=no-policy-found summary shows what fraction of inbound TLS attempts already succeed without enforcement, which informs whether moving to MTA-STS testing mode is safe.

How do reporters deduplicate redelivered TLS-RPT reports?

Through the top-level report-id field. RFC 8460 §4.1 specifies report-id as a reporter-assigned unique identifier that recipients use to deduplicate redelivered reports. The recipient ingestion pipeline indexes incoming reports by report-id and skips the parse-and-store step on any report whose report-id has already been ingested. The dedup window is typically the report retention window (often 30-90 days) — long enough to absorb any reasonable redelivery timeline. report-id format is reporter-defined; Google uses ISO 8601 timestamps concatenated with the policy domain (e.g., 2026-05-17T00:00:00Z_example.com), Microsoft uses GUIDs, and other reporters use various concatenations of date + domain + reporter-internal-counter. The recipient ingestion pipeline should not parse report-id semantically — treat it as an opaque dedup key. Cross-reporter collisions are theoretically possible but vanishingly rare in practice given the reporter-internal-counter component.

What is the filename convention for TLS-RPT email attachments?

RFC 8460 §5.1 specifies the filename as <reporter>!<policy-domain>!<unix-start>!<unix-end>.json[.gz] with the four exclamation-mark-separated components carrying: <reporter> the reporting organisation domain (e.g., google.com), <policy-domain> the recipient domain whose policy this report covers (e.g., example.com), <unix-start> the Unix epoch seconds of the aggregation window start, <unix-end> the Unix epoch seconds of the aggregation window end. The .json or .json.gz suffix names the encoding (uncompressed JSON vs gzipped). The exclamation-mark separator lets receivers sort filenames lexically by reporter then domain then time. Example: google.com!example.com!1747353600!1747439999.json.gz — meaning Google reporting on example.com for the 24-hour window starting 2026-05-15T00:00:00Z, gzip-compressed. The receiver typically uses the filename for log routing and uses the in-body report-id for dedup.

What is sending-mta-ip and how do I use it?

RFC 8460 §4.3 specifies sending-mta-ip as the IPv4 or IPv6 address of the sending MTA that attempted the TLS session that failed. It attributes the failure to a specific outbound IP rather than to a hostname. To identify the responsible mail provider, do a reverse-DNS / WHOIS lookup on that IP, then contact the operator with the failure-details for diagnosis. sending-mta-ip is distinct from the From: header domain (the message-author identity) and the MAIL FROM envelope (the bounce-address identity); it is also NOT the SMTP HELO/EHLO hostname the sender announced — it is the actual connecting IP address observed by the receiving MTA.

What is the additional-information field and what do reporters put there?

RFC 8460 §4.3 specifies additional-information as a free-form string the reporter may use to point at reporter-specific incident details — typically a URL to an incident page in the reporter's operations portal where the recipient operator can find packet captures, certificate snapshots, or extended failure traces. The field is optional and reporter-defined; Google fills it with a console URL, Microsoft with an Azure incident link, and smaller reporters typically leave it empty or fill with a short free-text note. Recipient ingestion pipelines store the value verbatim but do not parse it. When troubleshooting a specific failure-details entry, the operator clicks the additional-information URL (if present) to access the reporter-specific incident detail beyond the structured fields. The field complements failure-reason-code (a more machine-readable identifier).

Why do some failure-details entries lack receiving-ip while others have it populated?

RFC 8460 §4.3 specifies receiving-ip as the IPv4 or IPv6 address of the receiving MX that the sender connected to (or attempted to connect to). The field is OPTIONAL — reporters MAY include it but are not required to. Reporters that omit it typically do so for one of three reasons: (1) the failure occurred at the policy-evaluation layer before the actual TCP connection (e.g., sts-policy-fetch-error happens when fetching the policy file, not when connecting to the MX, so receiving-ip is meaningless), (2) the reporter aggregates across multiple receiving-ip values that all share the same (result-type, sending-mta-ip, receiving-mx-hostname) shape and chooses to omit the IP rather than pick one, (3) the reporter has privacy-policy constraints on IP disclosure. When receiving-ip IS present, it is the most precise identifier the operator has for which specific MX instance hit the failure — useful when the operator runs multiple MX backends behind the same hostname.

What happens if a TLS-RPT report is delivered with a malformed JSON body?

The receiver ingestion pipeline MUST treat the report as undeliverable and SHOULD log the parse failure for operator review. RFC 8460 does not specify a feedback channel back to the reporter — the reporter has no way to learn that its report failed to parse at the recipient. The practical consequence is that a malformed report from a specific reporter is silently lost; the operator will see a gap in coverage from that reporter. The most common malformed-report causes are (1) a truncated body where the HTTP POST was interrupted or the email attachment was truncated by a mailbox size limit, (2) a UTF-8 encoding issue where reporter-side string handling produced invalid byte sequences (rare but seen with operator-name fields containing non-ASCII characters), (3) an unexpected JSON shape from a reporter not strictly following RFC 8460. Robust ingestion pipelines log every parse failure with the full raw body so the operator can debug; DMARC Analyzer logs the failure and continues processing.

How does a TLS-RPT report differ from a DMARC aggregate report?

They are two distinct report formats covering different layers of email security. DMARC aggregate reports (RFC 7489 §7.2) describe SPF and DKIM authentication outcomes per (sending-source-IP, header-from-domain) bucket and are emitted by receiving MTAs to inform domain owners how their identity is being used. TLS-RPT reports (RFC 8460 §4) describe SMTP TLS session outcomes per (recipient-policy, sending-MTA, receiving-MX) bucket and are emitted by sending MTAs to inform recipient operators how their TLS policy enforcement is performing. DMARC reports are XML; TLS-RPT reports are JSON. DMARC reports cover message authentication; TLS-RPT reports cover transport security. Both are aggregated over 24-hour windows. Both can be delivered via mailto: and https:. Domains typically deploy both — DMARC RUA tells you "did this message come from the right sender", TLS-RPT tells you "did the connection use proper TLS". DMARC Analyzer ingests both and surfaces them in a unified dashboard.

13. Related guides

• TLS-RPT explained — the protocol pillar — what TLS-RPT is, how it works, the deployment workflow, the relationship to MTA-STS and DANE.
• TLS-RPT DNS record syntax — the focused byte-level reference for the _smtp._tls.<domain> TXT record (v=TLSRPTv1, rua=, schemes, cross-domain authorisation, 255-octet chunking).
• MTA-STS explained — TLS-RPT's natural deployment partner. MTA-STS enforces TLS; TLS-RPT reports what enforcement saw.
• MTA-STS for Google Workspace (provider deployment) — the provider-specific MTA-STS deployment walkthrough for the Workspace tenant topology whose TLS-RPT reports parse to the byte-level schema documented on THIS page. Where this page documents the JSON payload structure receivers send when reporting on a Workspace tenant's MTA-STS deployment, the Workspace MTA-STS spoke walks through the deployment end-to-end so the policy-string field in those JSON reports correctly reflects the aspmx.l.google.com / alt1-4.aspmx.l.google.com MX cluster enumeration (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), and the testing-mode burn-in workflow that pairs MTA-STS with TLS-RPT. Read this when triaging Workspace-tenant TLS-RPT reports carrying policy-type=sts records (the on-the-wire reports documented on this page reference the Workspace deployment topology by verbatim policy-string embedding the Workspace mx: directive lines plus the policy's mode, max_age, and any Workspace-specific deviations). The four MTA-STS-specific result-type values (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-host-mismatch) are the canonical diagnostics for Workspace deployment failures the Workspace spoke explicitly maps to its deployment-sequence steps.
• MTA-STS for Microsoft 365 (provider deployment) — the provider-specific MTA-STS deployment walkthrough for the Microsoft 365 / Exchange Online tenant topology whose TLS-RPT reports parse to the byte-level schema documented on THIS page. Where this page documents the JSON payload structure receivers send when reporting on an M365 tenant's MTA-STS deployment, the M365 MTA-STS spoke walks through the deployment end-to-end so the policy-string field in those JSON reports correctly reflects the <tenant>-com.mail.protection.outlook.com MX target enumeration (where <tenant>-com is the dashed transformation of your accepted domain), 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 policy file natively), the absence of any Defender-portal / Exchange Admin Center MTA-STS panel, the testing-mode burn-in workflow that pairs MTA-STS with TLS-RPT, and the hybrid-tenant MX-cutover discipline (the policy-string field in JSON reports from a hybrid tenant contains BOTH the on-prem and the M365 MX targets verbatim). Read this when triaging M365-tenant TLS-RPT reports carrying policy-type=sts records (the on-the-wire reports documented on this page reference the M365 deployment topology by verbatim policy-string embedding the M365 mx: directive lines plus the policy's mode, max_age, and any M365-specific deviations). The four MTA-STS-specific result-type values (sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, certificate-host-mismatch) are the canonical diagnostics for M365 deployment failures the M365 spoke explicitly maps to its deployment-sequence steps — and for M365 they are the ONLY TLS-enforcement diagnostics the report format will carry inbound (the protection.outlook.com MX cluster does NOT publish TLSA records, so no tlsa-invalid / dnssec-invalid result-types appear in TLS-RPT reports for M365 inbound).
• MTA-STS policy file syntax (RFC 8461 §3.2) — the operational reference for diagnosing the very failure-types this page documents. When a TLS-RPT report arrives carrying result-type=sts-policy-fetch-error the policy-file URL is unreachable; sts-policy-invalid the file was fetched but its byte content failed the RFC 8461 §3.2 grammar match; sts-webpki-invalid the HTTPS chain serving the policy file did not validate against the public-PKI roots; certificate-host-mismatch the MX cert CN/SAN did not match the connected hostname per the enforced policy. To turn these failure-types into actionable remediation steps an operator needs the byte-level reference for the policy file itself: the four canonical keys (version: STSv1, mode as case-sensitive enforce/testing/none enum, mx: with single-label wildcard semantics that match mail.example.com but NOT sub.mail.example.com — the most-confused matching rule in the spec, max_age: in seconds with RFC 8461 ceiling), the no-BOM constraint (Windows Notepad default produces UTF-8 BOM that silently breaks the version line match — the #1 silent-rejection cause producing sts-policy-invalid reports), the no-comments rule (any #-prefixed line causes full-policy rejection — operators migrating from MTA-STS reference implementations that allowed comments will see sts-policy-invalid on the first publish), the text/plain Content-Type expectation, the _mta-sts DNS id-token coupling with the policy-file id: rotation contract for zero-downtime updates, six canonical example policy files, and the ten common operator mistakes that produce each failure-type catalogued on this page. Read this when an ingestion pipeline starts surfacing the sts-* result-types documented above and the operator needs the upstream byte-syntax reference to diagnose the source policy file.
• MTA-STS vs DANE for SMTP — the policy-mechanism decision view between the two SMTP TLS enforcement models that show up in policy-type=sts vs policy-type=tlsa.
• DANE for SMTP — the TLSA-record-based TLS enforcement model behind policy-type=tlsa.
• DMARC aggregate reports — the parallel XML report format from RFC 7489 §7.2 covering message authentication (SPF/DKIM/DMARC verdicts) instead of transport-layer TLS.
• DMARC reporting pipeline — the end-to-end ingestion architecture DMARC Analyzer uses to process both DMARC and TLS-RPT reports.
• DMARC monitoring & reporting analysis — the CROSS-PROTOCOL-AGGREGATE-REPORT- FORMAT-AS-MONITORING-INPUT-STREAM-PARALLEL companion to this RFC 8460 §4 TLS-RPT report-format reference. Where THIS page documents the TLS-RPT JSON report-format wire-syntax (the policy-domain / policy-type / summary / failure- details field-set) consumed by the operator-side transport-layer monitoring dashboard, the DMARC-monitoring spoke is the STRUCTURALLY-PARALLEL APPLICATION-LAYER monitoring-discipline reference documenting the 8 core KPIs, anomaly-detection patterns, and operational review cadence applied to the DMARC aggregate-report XML stream (the application-layer cross-protocol twin of the transport-layer TLS-RPT JSON stream THIS page documents). The CROSS-PROTOCOL-AGGREGATE-REPORT-FORMAT- AS-MONITORING-INPUT-STREAM-PARALLEL cross-reference establishes FOUR structurally-distinct TLS-RPT-vs-DMARC- RUA-monitoring-discipline-parallel dimensions: (i) per-MX-TLS- negotiation-failure-rate-KPI-parallel- with-per-source-IP-DMARC-fail-rate-KPI dimension — the TLS-RPT report- format THIS page documents segments failure-details by per-MX-target STARTTLS-stripping / certificate- expired / certificate-host-mismatch / DANE-TLSA-validation-failure / STS-policy-violation classes per RFC 8460 §4.3.2; the DMARC-monitoring spoke documents the structurally- parallel per-source-IP-segmented DMARC-fail-rate KPI under the application-layer aggregate-report stream (per-source-IP-dkim=fail / spf=fail / dmarc=fail rates per RFC 7489 §7.2.1); both monitoring disciplines apply the same alert- threshold model (per-target-cohort baseline + spike-detection) to STRUCTURALLY-DISTINCT-LAYER per- target-cohort failure-rate KPIs; (ii) per-day-bucket-volume- baseline-KPI-parallel-with-per-day- bucket-DMARC-message-volume-baseline- KPI dimension — the TLS-RPT report-format THIS page documents emits per-day-bucket per-MX TLS- negotiation volume counts; the DMARC-monitoring spoke documents the parallel per-day-bucket per- source-IP message-volume baseline KPI under the DMARC aggregate- report stream; both monitoring disciplines use the per-day-bucket volume baseline as the canonical anomaly-detection denominator that the per-failure-rate KPI is computed against; (iii) per- reporter-cohort-coverage-quality- KPI-parallel-across-both-streams dimension — the TLS-RPT report-format THIS page documents is emitted by a subset of receiver- side cohorts (Google / Microsoft / Verisign / Comcast / etc.); the DMARC-monitoring spoke documents the parallel per-reporter-cohort coverage-quality KPI tracking which receivers emit aggregate reports for the publisher's sending streams; both monitoring disciplines apply the same reporter-coverage-gap detection pattern to STRUCTURALLY-DISTINCT receiver-cohort populations (TLS-RPT-emitting receivers vs DMARC-RUA-emitting receivers); (iv) per-source-cohort- inventory-drift-KPI-parallel- with-per-MX-inventory-drift-KPI dimension — the TLS-RPT report-format THIS page documents surfaces new per-MX-target cohorts appearing in the publisher's outbound-mail-flow inventory the operator's monitoring dashboard tracks via STS-policy-target-drift alerts; the DMARC-monitoring spoke documents the parallel per-source- IP-cohort inventory-drift KPI surfacing new per-source-IP-cohorts appearing in the publisher's DMARC-aggregate-report stream; both monitoring disciplines apply the same inventory-drift alert- routing pattern (auto-correlate to documented sending-system inventory + threat-intelligence indicators). Read this DMARC-monitoring spoke alongside THIS TLS-RPT-report- format reference when authoring the operator-side cross-protocol monitoring dashboard that SIMULTANEOUSLY consumes the transport-layer TLS-RPT JSON stream THIS page documents AND the application-layer DMARC RUA XML stream the monitoring spoke documents the discipline of.
• Email authentication overview — the SPF/DKIM/DMARC/BIMI/MTA-STS/TLS-RPT/CAA whole-cluster intro.
• DMARC help hub — the canonical entry point covering DMARC and the full email-authentication cluster.
• BIMI SVG-Tiny-PS image authoring requirements — the WIRE-FORMAT-RFC-CITATION-ANCHOR- PARALLEL companion. Where THIS page documents the TLS-RPT report-format normative specification per RFC 8460 §4 (the JSON object-shape grammar, the per-policy / per-failure-type / per- result-summary nesting, the policy-domain / policy-type / summary / failure- details field-set), the BIMI-SVG- Tiny-PS-image-authoring spoke documents the STRUCTURALLY-PARALLEL formal wire- format normative-specification authoring constraints per the BIMI Working Group's SVG-Tiny-PS authoring-rules-draft (the W3C SVG-Tiny-1.2 subset baseline, the per-element / per-attribute / per- property authoring rules, the BIMI- specific baseProfile="tiny-ps" root-element discipline, the UTF-8 / 32- KB-after-base64 / gzip-eligibility byte- envelope constraints). Both pages share the same publisher-side-canonical- document / formal-wire-format-with-RFC- and-draft-citation-anchor structural pattern: (i) the canonical document is machine-parsed by automated downstream receivers without humans-in-the-loop — any byte-syntax violation silently defeats per-document processing (TLS-RPT JSON-parse-failure → report discarded; SVG-Tiny-PS parse-failure → branded-inbox indicator suppressed); (ii) the canonical document is referenced by an upper-layer protocol element (TLS-RPT JSON is referenced by the _smtp._tls.<domain> TXT record's rua= mailto / https endpoint; BIMI SVG-Tiny-PS is referenced by the _bimi.<domain> TXT record's l= HTTPS URL); (iii) the receiver-side validation chain spans both DNS-resolved TXT-record byte- syntax AND fetched-content byte-syntax; either layer's silent-violation defeats end-to-end behaviour. Read THIS TLS-RPT- report-format page WITH the BIMI-SVG- Tiny-PS-image-authoring spoke when designing a publisher-side wire-format authoring discipline spanning the cluster's parallel formal-wire-format channels.
• BIMI explained — the per-publisher per- domain BIMI brand-indicator-rendering eligibility cascade companion to this RFC 8460 §4 TLS-RPT report-format reference at four per- TLS-RPT-report-format-vs-BIMI-indicator- rendering-cascade coupling dimensions (per- publisher per-domain RFC 8460 §4 TLS-RPT JSON-aggregate-report policy + summary.total-successful-session-count + summary.total-failure-session-count attribution stream IS structurally parallel per-publisher per-domain receiver-side per-day evidence-driven observability companion to per- publisher per-domain DMARC RUA XML-aggregate- report record/row/policy_evaluated attribution stream per RFC 7489 §7.2 whose per-publisher per-domain DMARC-aligned-pass-rate floor IS the load-bearing application-layer precondition for per-mailbox-provider BIMI indicator-rendering eligibility cascade gate / per-publisher per-domain RFC 8460 §4 TLS- RPT JSON-aggregate-report per-failure failure-details.failure-reason-code attribution (certificate-not-trusted, certificate-host-mismatch, certificate-expired, validation-failure) per RFC 8460 §4.4 IS structurally parallel observability stream to per-publisher per-domain BIMI VMC/CMC X.509-chain-of-trust attestation failure-class attribution at per-mailbox-provider per-receiver BIMI-evaluator HTTPS-fetch-and-validate decision- pipeline — both per-publisher per-domain per-receiver-side X.509-chain-of-trust failure- class attribution streams underpin per-publisher per-domain operator-actionable evidence-driven per-mailbox-provider BIMI indicator-rendering eligibility blind-spot closure / per-publisher per-domain TLS-RPT-aided MTA-STS mode: enforce transport-layer enforcement-mode publication-decision per RFC 8461 §5 IS load-bearing per-publisher per- domain anti-MITM-downgrade-attack defense- discipline preserving per-recipient per-message cryptographically-authentic SMTP-delivery channel whose per-recipient inbox-list-display BIMI indicator-rendering visual brand-authenticity signal is the per-mailbox-provider per-recipient consumer-side application-layer brand-protection- authority parallel — both per-publisher per-domain transport-layer-cryptographic-channel- integrity + application-layer brand-indicator- rendering visual brand-authenticity primitives coordinate per-publisher per-domain composite cross-layer brand-protection floor / per-publisher per-domain RFC 8460 §4 TLS-RPT JSON-aggregate- report publication-discipline drift (report publication missing / malformed JSON aggregate payload / per-failure failure-details attribution missing) directly opens per-publisher per-domain transport-layer-observability blind- spot IS structurally parallel to per-publisher per-domain default._bimi.<d> TXT-RR + VMC-URI publication-discipline drift opening per-publisher per-domain application- layer brand-indicator rendering-eligibility blind- spot at the per-publisher per-domain composite cross-protocol cross-layer publication-discipline- and-receiver-emission-evidence coordination boundary) — together the per-publisher per- domain RFC 8460 §4 TLS-RPT JSON-aggregate- report-format publication-discipline THIS page documents AND the per-publisher per-domain BIMI brand-indicator-rendering eligibility cascade compose the per-publisher per-domain composite transport-layer-observability-and-application- layer-brand-indicator-rendering coordination floor.
• DMARC forensic (RUF) reports — the TRANSPORT-LAYER-TLS-RPT-REPORT- FORMAT-PARALLEL-TO-APPLICATION-LAYER- DMARC-RUF-FORMAT companion to this RFC 8460 §4 TLS-RPT report-format reference. Where THIS page documents the RFC 8460 TLS-RPT JSON report-format byte-grammar + the §4.3 result-type registry + the §5.1 report-delivery contract + the per-failure- sample policy-evaluation evidence schema, the DMARC-forensic-reports (RUF) spoke is the STRUCTURALLY-PARALLEL APPLICATION-LAYER per-message-failure-sample reporting channel whose RFC 7489 §7.3 / RFC 6591 / RFC 5965 format-architecture pairs with this transport-layer report-format reference at FOUR per-report-format- parallel dimensions: (i) SHARED DISPATCH-VIA-EMAIL CONTRACT — both report formats are delivered via SMTP to a publisher-published mailbox address: TLS- RPT via RFC 8460 §5.1 to the rua=mailto: address at _smtp._tls.<org-domain>, DMARC RUF via RFC 5965 to the ruf=mailto: address at _dmarc.<org-domain> — the parallel publisher-side mailbox- provisioning + per-report-mailbox-storage- retention + per-report-mailbox-rate-limit considerations apply symmetrically to both protocols, enabling the publisher to author a unified report-receiving infrastructure (single dedicated operations mailbox cluster + single parser-pipeline + single per-report- format trend-analysis dashboard) serving both channels; (ii) PARALLEL JSON vs AFRF/EMAIL PAYLOAD ENCODING DECISIONS — TLS-RPT chose RFC 8460 §4 JSON-over-application/tlsrpt+gzip whereas DMARC RUF chose RFC 5965 AFRF (Abuse Reporting Format) over MIME- multipart/report; the structural decision between machine-parseable JSON (TLS-RPT) vs human-readable + machine-parseable AFRF (DMARC RUF) reflects each protocol's primary consumer (TLS-RPT: machine aggregation; DMARC RUF: human-operator forensic investigation) — operators consuming BOTH report streams must run per-format parsers in parallel and normalize to a common internal evidence schema for cross-protocol correlation; (iii) PARALLEL PER-FAILURE-SAMPLE REPORT SCOPE VS AGGREGATE COUNTS — TLS-RPT batches per-policy-evaluation- outcome per-receiver per-day into a single JSON report (per RFC 8460 §4), DMARC RUF emits a per-message-failure SAMPLE per receiver (per RFC 7489 §7.3) — both protocols emit failure-evidence SAMPLES rather than statistical aggregates (DMARC RUA is the aggregate-counts companion to DMARC RUF; the TLS-RPT JSON report folds both the aggregate counts AND the per- failure samples into a single per-day report-format unit) — the publisher's per- protocol report-volume-expectation per- receiver-per-day differs in shape but shares the per-failure-sample-grain evidence-yield property; (iv) PARALLEL ROLLING-WINDOW PUBLISHER-SIDE OBSERVABILITY DISCIPLINE — both report streams anchor a rolling-window observability discipline: TLS-RPT enables the publisher to track per-receiver STARTTLS-pass-rate + DANE-validation outcome + MTA-STS-enforcement-mode trends over the 7/30/90-day window, DMARC RUF enables the publisher to track per-receiver per-failure-class forensic-sample trends over the same rolling window — the parallel observability disciplines fold into a unified TRANSPORT-LAYER + APPLICATION-LAYER deliverability + email- authentication posture-monitoring discipline the operator must run as a single cross- protocol operational practice. Read the DMARC-forensic-reports spoke alongside this TLS-RPT-report-format reference when designing the publisher-side report- consumption infrastructure — the spoke is the canonical RFC 7489 §7.3 / RFC 6591 / RFC 5965 RUF-format reference whose four per-report-format-parallel dimensions this RFC 8460 TLS-RPT-report-format page is the STRUCTURALLY-PARALLEL transport-layer twin of.
• Reverse DNS and PTR records explained — the TLS-RPT-FAILURE-DETAILS-PER- SENDING-MX-HOST-IP-PTR-FCRDNS- VERIFICATION-AS-RFC-8460-§4.3-RESULT- TYPE-ROOT-CAUSE-DIAGNOSTIC companion to this RFC 8460 §4 TLS-RPT report- format reference. Where THIS page documents the TLS-RPT application/tlsrpt+json report payload byte-syntax (the organization-name / date-range / contact-info / report-id header fields, the policies[] array with policy-type / policy-string / policy-domain / mx-host entries, the summary object's total-successful-session-count / total-failure-session-count counters, and the failure-details[] array with per-failure result-type / sending-mta-ip / receiving-mx-hostname / receiving-mx-helo / receiving-ip / failed-session-count / additional-information / failure-reason-code diagnostic fields), the reverse-DNS / PTR spoke is the PER-SENDING-MX- HOST-IP-FCRDNS-DIAGNOSTIC primitive every TLS-RPT failure-details consumer must correlate against the sending-mta-ip field's published PTR record to root-cause a transport-layer TLS-session failure. The four-axis TLS-RPT- REPORT-FORMAT-VS-PTR-FCRDNS- DIAGNOSTIC comparison exposes the structurally-distinct per-result- type diagnostic coordination roles: (i) RFC 8460 §4.3 result-type registry values starttls-not-supported / certificate-host-mismatch / certificate-expired / certificate-not-trusted each emit a sending-mta-ip field whose forward-confirmed PTR publication is the SOLE diagnostic primitive available to attribute the failure to a SPECIFIC outbound- SMTP-relay IP at a SPECIFIC sending-tenant — without publishing a FCrDNS-confirmed PTR at the sending-MTA-IP boundary, the per-failure sending-mta-ip value is operationally orphaned from any sending-tenant identity the TLS-RPT-receiving operator can correlate against — the reverse-DNS / PTR spoke documents the per-sending-MTA-IP PTR- publication operational discipline every TLS-RPT-producing operator must execute to make their outbound-MX-host TLS-RPT failure- detail attribution chains diagnostically-actionable for the TLS-RPT-receiving operator decoding the report payload this page documents the wire-format of; (ii) RFC 8460 §4.3 result-type certificate-host-mismatch directly maps to a per-MX-host SAN mismatch where the receiving-mx-helo (EHLO hostname) does NOT match the X.509 TLS certificate SAN — and the receiving-MX-host side's PTR / FCrDNS publication is the canonical diagnostic primitive for confirming that the EHLO hostname FORWARDS-AND- REVERSES correctly through the receiving-MX-host's IP — the reverse-DNS / PTR spoke documents the per-receiving-MX- host PTR-RR publication operational discipline every TLS-RPT-receiving operator MUST coordinate with the per-MX-host X.509 certificate SAN authoring to eliminate the certificate-host-mismatch failure-class this page documents the wire-encoding of; (iii) RFC 8460 §4.3 result-type tlsa-invalid / dnssec-invalid / dane-required each derive their per-failure attribution from the sending-mta-ip AND the policy-domain / mx-host binding the TLSA-RR was retrieved against — making the per-MX-host FCrDNS verification (forward and reverse resolution of the MX-host hostname cross-checked against the sending-mta-ip / receiving-ip) the single most diagnostically- actionable primitive a TLS-RPT- receiving operator can rely on when the DANE TLSA-RR-validation path produces a tlsa-invalid verdict whose root cause may be MX- hostname / PTR drift rather than DNSSEC chain-of-trust corruption — the reverse-DNS / PTR spoke documents the per-MX-host PTR- publication-vs-DANE-TLSA-RR- publication coordination chain every DANE-deploying receiver must verify against to keep the TLS-RPT failure-detail tlsa-invalid result-type the page documents the wire-format of from spurious emission; and (iv) RFC 8460 §4 policies[] array policy-type sts / tlsa / no-policy-found each emit a per-policy-evaluation record whose downstream failure-details[] attribution to a SPECIFIC sending- IP requires the sending-mta-ip field to be PTR-resolvable to a FCrDNS-pass hostname the TLS-RPT- receiving operator can correlate against the sending-tenant identity — making the per-MX-host PTR publication the FOUNDATIONAL diagnostic primitive that determines whether a TLS-RPT failure-report is operationally actionable or merely observational — the reverse-DNS / PTR spoke documents the per-sending-MTA-IP PTR-as- diagnostic-primitive operational discipline every TLS-RPT consumer must internalise to convert the per-failure sending-mta-ip / receiving-mx-hostname pair this page documents the wire-encoding of into an actionable per-tenant root-cause attribution. Read the reverse- DNS / PTR spoke when ingesting the per-failure sending-mta-ip / receiving-mx-hostname / receiving-mx-helo fields documented on this page (correlate each sending-mta-ip with the published PTR record to attribute the failure to a sending-tenant), when authoring a TLS-RPT-producing publisher- side MX-host (ensure the per-MX-host PTR publication matches the EHLO hostname AND the X.509 SAN), and when diagnosing a certificate-host-mismatch / tlsa-invalid / starttls-not-supported failure-report whose root cause may be PTR / FCrDNS drift UPSTREAM of the TLS-handshake layer this page documents the report-format wire-encoding of.
• DMARC for shared hosting — the SHARED-HOSTING-TENANT-TRANSPORT- LAYER-OBSERVABILITY-VIA-PER-TENANT-TLS- RPT-PUBLICATION-AT-PROVIDER-MANAGED-MX- EDGE-AT-FOUR-PER-TENANT-TRANSPORT- OBSERVABILITY-CO-PUBLICATION- COORDINATION-DIMENSIONS companion to this TLS-RPT-JSON-report-format reference. Where THIS page documents the RFC 8460 §4 TLS-RPT JSON report wire encoding (the organization-name / date-range / contact-info / policies[] per-policy record body with its policy- type + policy-string + policy-domain + mx-host + summary {successful-session-count, failed- session-count} + failure- details[] per-failure-record block with its result-type enum + sending-mta-ip + receiving-mx-helo + receiving-mx-hostname + receiving-ip + failed-session-count per- failure-row fields), the shared-hosting spoke is the per-tenant message-layer DMARC publication-discipline reference whose load-bearing per-publisher per- source-IP DMARC-aligned-pass-rate observability discipline parallels the per-tenant transport-layer per-MX-host STARTTLS-handshake-success-rate observability discipline THIS TLS-RPT JSON report-format reference encodes at four per-tenant transport-observability co-publication coordination dimensions: (i) per-tenant TLS-RPT TXT publication at the SAME provider- managed DNS zone the DMARC TXT-RR publication targets — the shared-hosting tenant's per-domain _smtp._tls.<tenant- domain> TXT-RR publishing the TLS-RPT v=TLSRPTv1; rua=mailto:<tls-rpt-mailbox> endpoint that triggers the JSON report- delivery THIS page documents is co- published at the SAME hosting-provider- managed DNS zone (cPanel Zone Editor / Plesk DNS Template) where the per-tenant DMARC _dmarc.<tenant- domain> TXT-RR is published — meaning the per-tenant TLS-RPT publication ladder gates on the SAME provider-side DNS-publication-permission surface the per-tenant DMARC publication ladder bottoms out on; (ii) per- tenant MX-host STARTTLS-handshake- success-rate observability gap at the provider-operated shared-MX-edge boundary — without per-tenant TLS-RPT TXT publication, shared-hosting tenants CANNOT observe transport-layer STARTTLS-handshake failures the hosting-provider-operated MX edge silently incurs at the per-tenant mx.<provider>.com receiving-MX-hostname boundary — the per-tenant transport-layer observability gap is the EXACT structural-parallel of the per-tenant message-layer DMARC- aligned-pass-rate observability gap the shared-hosting spoke documents at the provider-operated shared-outbound-relay- pool boundary; (iii) per-tenant failure-row attribution via policy-domain + mx- host + receiving-mx- hostname field cross-correlation parallel — TLS-RPT JSON reports' per-tenant attribution depends on the policy-domain field matching the per-tenant publisher tenant-domain + the mx-host field naming the provider-operated MX edge + the receiving-mx-hostname field confirming per-tenant per-MX-host identity; this per-tenant attribution discipline is the EXACT structural- parallel of the per-tenant DMARC aggregate-XML per-source-IP attribution discipline via the policy_published / domain field + per-record source_ip field + per- record identifiers / header_from field cross-correlation the shared- hosting spoke documents; (iv) per-tenant cross-layer observability stack co-publication discipline at the provider-managed zone editor surface — shared- hosting tenants seeking full per-tenant observability across the message-layer + transport-layer stack must co-publish DMARC _dmarc.<tenant- domain> TXT (rua-aggregate- XML observability) + MTA-STS _mta-sts.<tenant-domain> TXT (transport-policy publication) + TLS-RPT _smtp._tls.<tenant- domain> TXT (rua-TLS-JSON observability — the SUBJECT of THIS page) at the SAME provider-managed zone-editor surface — the cross- protocol per-tenant co-publication ladder is the load-bearing per-tenant cross-layer observability stack the shared-hosting spoke documents. Read the shared-hosting spoke ALONGSIDE this TLS-RPT JSON report-format reference whenever a per-shared-hosting- tenant transport-layer observability configuration discipline question emerges — THIS page gives the RFC 8460 §4 JSON report wire encoding, the shared-hosting spoke gives the per- tenant cross-layer observability stack co-publication-discipline reference the per-tenant transport-layer observability ladder bottoms out on at the provider- managed DNS-zone-editor publication- permission boundary.
• DNS propagation explained — the TLS-RPT-TXT-RECORD-DNS-PUBLICATION- PROPAGATION-WINDOW-AS-LOAD-BEARING- UPSTREAM-GATE-OF-FIRST-RFC-8460-SECTION- 4-JSON-REPORT-DELIVERY-EMERGENCE-AT- PUBLISHER-RUA-MAILBOX-AT-FOUR-TLS-RPT- PUBLICATION-PROPAGATION-COUPLING- DIMENSIONS companion to this TLS-RPT- JSON-report-format reference. Where THIS page documents the RFC 8460 §4 TLS-RPT JSON report wire encoding (the per-day per-policy report-body structure delivered to the per- publisher rua mailbox after the per- receiver TLS-RPT-aware-MTA completes its daily aggregation cycle), the DNS- propagation spoke is the canonical propagation-window discipline reference whose per-resolver per-zone-version cache-aging behaviour determines WHEN the per-publisher per-domain TLS-RPT _smtp._tls.<tenant- domain> TXT-RR publication becomes globally resolvable at the per- receiver-MTA recursive-resolver cache tier — at four TLS-RPT-publication propagation coupling dimensions: (i) per-publisher per-domain TLS- RPT TXT-RR initial publication propagation window gate — the per-publisher per-domain _smtp._tls.<tenant- domain> TXT-RR publishing the TLS-RPT v=TLSRPTv1; rua=mailto:<tls-rpt-mailbox> endpoint that triggers the JSON report- delivery THIS page documents is subject to the per-resolver per-zone cache- aging propagation-window THIS DNS- propagation spoke documents; until the per-receiver-MTA recursive-resolver cache has aged the (cached negative) prior-state cache-entry and refetched the newly-published TLS-RPT TXT-RR from the authoritative server, the per-receiver TLS-RPT-aware-MTA's daily- report-generation workflow CANNOT observe the per-publisher rua-mailbox- target and will NOT deliver the first RFC 8460 §4 JSON report to the publisher; (ii) per-publisher per-domain TLS-RPT rua-target rotation propagation window gate — per-publisher per-domain rua-mailbox- target rotation (e.g. swapping rua=mailto:tls-old@domain for rua=mailto:tls-new@domain or onboarding a per-publisher third- party TLS-RPT-aggregation SaaS rua target) is gated by the per-resolver per-zone cache-aging propagation-window THIS spoke quantifies — the per- publisher per-rotation rua-target cutover discipline ladder bottoms out on the DNS-propagation-window- discipline reference for the per- receiver-MTA observability gate; (iii) per-publisher per-domain MTA- STS policy-version-rotation (id=-tag bump) propagation window gate — the per-publisher per-domain MTA-STS _mta-sts.<tenant- domain> TXT-RR's id=<policy-version-token> tag-rotation discipline (the canonical MTA-STS policy-version-cache- invalidation publication discipline) is subject to the per-resolver per- zone cache-aging propagation-window THIS DNS-propagation spoke documents — which determines when per-receiver-MTA TLS-RPT report generation switches from policy-string=mode: testing to policy-string=mode: enforce observability at the per-receiver-MTA per-day per-policy report-body boundary the JSON-report-format reference documents; (iv) per-publisher per-day TLS-RPT JSON report-emergence latency floor at the per-receiver-MTA daily aggregation cycle vs DNS- propagation-window stacked-delay boundary — the first TLS-RPT JSON report a per-publisher rua- mailbox observes after initial TLS-RPT TXT-RR publication is bounded BOTH by the per-receiver-MTA daily aggregation cycle (RFC 8460 §5 24-hour aggregation period) AND by the per-resolver per- zone cache-aging propagation-window THIS spoke documents — the STACKED- DELAY floor is the per-publisher per- deployment first-JSON-report-emergence latency the publisher's TLS-RPT deployment-validation discipline plans around. Read the DNS-propagation spoke ALONGSIDE this TLS-RPT JSON report-format reference whenever a per-publisher per-domain TLS-RPT publication timing question emerges — THIS page gives the RFC 8460 §4 JSON report wire encoding, the DNS- propagation spoke gives the upstream propagation-window discipline reference the per-publisher per- domain TLS-RPT publication observability ladder bottoms out on at the per-receiver-MTA recursive- resolver cache-aging boundary.
• MX records — the PER-POLICY-DOMAIN-MX-RRSET-AS- UPSTREAM-LOAD-BEARING-POLICY-DOMAIN- IDENTITY-RECORD-CLASS-FOR-PER-POLICY- DOMAIN-PER-MX-HOST-TLS-RPT-COVERAGE- ATTRIBUTION companion reference. Where THIS page documents the TLS-RPT JSON aggregate-report per-policy-domain.per- mx-host evidence-row partitioning surface at RFC 8460 §4 (the per-day per-policy-domain per-MX-host TLS- negotiation outcome rows the per- receiver-MTA aggregates and emits to the per-policy-domain rua=-tag-value mailbox in gzipped JSON form), the MX-records spoke documents the per-policy-domain MX RRset enumeration discipline (the priority-ordered per-policy-domain MX RDATA targets at the per-policy-domain master zone whose per-MX-host hostnames are the policy-domain's authoritative receiver-side inbound MTA targets), across four per-policy-domain-MX-RRset- to-per-policy-domain-per-MX-host-TLS- RPT-coverage-coupling dimensions: (i) per-policy-domain-MX-RRset- as-upstream-load-bearing-input-to-per- policy-domain-per-MX-host-TLS-RPT- coverage-axis — the TLS-RPT JSON aggregate-report per-policy- domain.per-mx-host evidence-row partitioning surface THIS page documents partitions the per-day per-policy-domain TLS-negotiation outcome rows BY the per- MX-host axis defined by the per-policy- domain MX RRset the MX-records spoke documents; a per-policy-domain MX RRset with N priority-ordered MX targets produces N per-MX-host partitions in the per-day per-policy-domain TLS-RPT JSON aggregate-report; (ii) per- policy-domain-MX-RRset-changes-as- cause-of-per-MX-host-TLS-RPT-evidence- row-baseline-drift — per- policy-domain MX RRset changes (adding a new fallback MX target, removing a deprecated MX target, re-prioritizing the priority-ordered RDATA list) cause per-day per-policy-domain TLS-RPT JSON aggregate-report per-MX-host partition baseline drift; the per-policy-domain operator interpreting the TLS-RPT evidence stream MUST correlate per-MX- host partition changes against per- policy-domain MX RRset publication events to distinguish authentic per- MX-host TLS-negotiation outcome shifts from per-MX-host inventory composition changes; (iii) per-policy- domain-MX-RRset-priority-ordering-as- per-MX-host-TLS-RPT-evidence-row- primary-vs-fallback-attribution — the per-policy-domain MX RRset's priority-ordered RDATA list (lowest priority value = primary MX, higher-priority-value = fallback MX in SMTP delivery sequence per RFC 5321 §5.1) feeds the per-day per-policy- domain TLS-RPT per-MX-host partition rows the per-policy-domain operator attributes to PRIMARY-MX vs FALLBACK- MX TLS-negotiation outcome classes; TLS-negotiation outcome regressions on the per-policy-domain PRIMARY MX produce per-day per-policy-domain delivery degradation signals materially distinct from FALLBACK-MX-only regressions; (iv) per-policy- domain-MX-RRset-as-load-bearing- coordination-record-with-MTA-STS- policy-mx-stanza-and-DANE-TLSA-record- per-MX-host-publication — the per-policy-domain MX RRset the MX- records spoke documents IS the load- bearing identity record the per- policy-domain MTA-STS policy mx: stanza pattern-matches AND the per-policy-domain DANE TLSA records publish per-MX-host _25._tcp.<mx-host> records for; per-policy-domain MX RRset composition changes cascade across MTA- STS policy mx-stanza maintenance + per- MX-host DANE TLSA publication maintenance + per-MX-host TLS-RPT evidence-row coverage attribution simultaneously. Read this WITH the TLS-RPT JSON aggregate-report format reference when the per-policy-domain per-MX-host TLS-RPT evidence-row interpretation sequence reaches the operator's queue: THIS page documents the per-day per-policy-domain per-MX- host TLS-RPT JSON aggregate-report partitioning surface, the MX-records spoke documents the LOAD-BEARING per- policy-domain MX RRset enumeration discipline whose per-MX-host inventory composition directly determines the per-policy-domain per-MX-host TLS-RPT coverage axis THIS page's per-policy- domain.per-mx-host evidence-row partitioning surface presupposes.
• DKIM for Google Workspace — the LOAD-BEARING per-Workspace-tenant per-custom-domain PER-WORKSPACE-TENANT- DKIM-PUBLICATION-AS-APPLICATION-LAYER- COMPANION-OF-TRANSPORT-LAYER-TLS-RPT- JSON-AGGREGATE-OBSERVABILITY companion documenting the per-Workspace-tenant per-custom-domain DKIM publication tutorial (the Google Admin console Apps > Google Workspace > Gmail > Authenticate email flow, the per- tenant 2048-bit google._domainkey.<d> DNS-TXT publication, the per-tenant DKIM-signing-domain verification step). Where THIS page documents the per- publisher per-policy-domain.per-mx-host RFC 8460 §4 TLS-RPT JSON-aggregate- report payload schema (the organization-name, date-range, contact-info, report-id, policies, policy, summary, failure-details field semantics; the per-policy-domain.per- mx-host result-type registry — starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, tlsa-invalid, dnssec-invalid, dane-required, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid; the per-receiver-MX evidence-row partitioning surface), the DKIM-for- Workspace spoke documents the APPLICATION-LAYER per-Workspace-tenant per-custom-domain DKIM-publication- discipline whose per-tenant per- custom-domain DKIM-signed outbound mail traffic flows over the per-policy- domain.per-mx-host STARTTLS-protected transport-layer paths whose per-MX-host per-result-type TLS-RPT JSON-aggregate- report evidence rows this page documents capture. Read THIS page when PARSING the per-policy-domain.per-mx- host RFC 8460 §4 TLS-RPT JSON-aggregate- report payload; read the DKIM-for- Workspace spoke when AUTHORING the per- Workspace-tenant per-custom-domain APPLICATION-LAYER DKIM publication whose per-tenant DKIM-signed message stream flows through the per-policy- domain.per-MX-host TRANSPORT-LAYER STARTTLS-protected paths whose per- result-type evidence rows THIS page documents.
• Domain Security Checker — validate the live TLS-RPT DNS record that triggers report delivery.
• DNS record generator — generate the _smtp._tls TXT record interactively (Enterprise tier).
• Email Header Analyzer — parse the Authentication-Results header to cross-check inbound-message TLS-RPT signals.
• DMARC for Office 365 hybrid — the LOAD-BEARING per-hybrid-Exchange- tenant HYBRID-EXCHANGE-DUAL-RECEIVE-MX- TLS-RPT-COVERAGE-OBSERVABILITY- PARTITION-AS-PER-INBOUND-LEG-PER-MX- HOST-EVIDENCE-ROW-PARTITIONING-SURFACE companion documenting the per-hybrid- Exchange-tenant DMARC + SPF + DKIM publication tutorial — specifically the hybrid topology's dual-receive MX publication that exposes BOTH the Exchange Online inbound MX hostname pattern <customer-domain-with-dashes>.mail.protection.outlook.com AND the on-prem Edge Transport / Mailbox server inbound MX hostname(s) to remote receiver MTAs. Each inbound leg produces its own per-MX-host TLS-handshake evidence-row partition in the per-policy- domain TLS-RPT JSON-aggregate-report this page documents. Where THIS page documents the per-publisher per-policy-domain.per- mx-host RFC 8460 §4 TLS-RPT JSON- aggregate-report payload schema (the policies[].policy.policy-domain field per-policy-domain partitioning, the policies[].policy.mx-host field per-MX-host partitioning surface, the policies[].summary.total-failure-session-count per-MX-host failure counter, the policies[].failure-details[] per-MX-host per-result-type evidence-row array), the DMARC-for-O365-hybrid spoke documents the per-hybrid-tenant DUAL- RECEIVE-MX TLS-RPT COVERAGE PARTITION DISCIPLINE — the per-tenant operator-side challenge of interpreting the per-policy- domain.per-mx-host evidence-row stream SEPARATELY for the Exchange-Online-leg inbound MX and the on-prem-leg inbound MX (because the two legs have distinct per-MX-host TLS-handshake postures: EOP publishes a Microsoft-managed PKI certificate at *.mail.protection.outlook.com with TLS 1.3 / TLS 1.2 / 2048-bit RSA baseline; the on-prem leg's TLS-handshake posture depends on operator-managed Exchange Server certificate publication which historically lags the cloud-leg's per-MX-host hardening cadence). Read THIS page when PARSING the per-policy- domain.per-mx-host TLS-RPT JSON- aggregate-report payload; read the DMARC-for-O365-hybrid spoke when INTERPRETING the per-tenant dual-receive MX per-leg TLS-handshake posture DIVERGENCE this page's per-MX-host evidence-row partitioning surface reveals.
• BIMI Verified Mark Certificates (VMC and CMC) — the PER-PUBLISHER-PER-DOMAIN-BIMI- ASSET-HTTPS-DELIVERY-VS-PER-PUBLISHER- PER-DOMAIN-TLS-RPT-JSON-RESULT-TYPE- FAILURE-CLASS-PARALLEL companion to this TLS-RPT report-format reference. Where THIS page documents the RFC 8460 §4 JSON aggregate-report byte-grammar whose per- failure result-type enum (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-webpki-invalid, tlsa-invalid) catalogues the per-receiver per- publisher per-day TLS-handshake-failure classes the publisher's MX-receive-side transport-layer surfaces to TLS-RPT- ingesting receivers, the BIMI VMC certificates spoke documents the STRUCTURALLY-PARALLEL per-publisher per-domain BIMI-asset (SVG + PEM) HTTPS-delivery transport-layer whose per-asset HTTPS handshake from the receiver-side BIMI evaluator (Gmail, Apple Mail, Yahoo, Fastmail) to the per-publisher HTTPS endpoint exercises the SAME PUBLIC-CA-rooted TLS-handshake- failure-class surface at FOUR per- publisher per-domain BIMI-asset-HTTPS- retrieval-vs-TLS-RPT-failure-class coupling dimensions: (i) per- publisher per-domain BIMI l=https://...svg asset- fetch HTTPS handshake certificate-host-mismatch failure-class structurally parallel to the per-publisher per-domain MTA-STS- MX-receive-side TLS-handshake certificate-host-mismatch result-type THIS report- format reference catalogues — when the per-publisher BIMI SVG-asset- serving HTTPS endpoint presents a cert whose CN/SAN does not match the l=-tag URL host, the per- receiver per-publisher per-day BIMI evaluator records a failure-class directly paralleling the per-publisher per-day MTA-STS-MX-receive-side certificate-host-mismatch evidence-class catalogued in TLS-RPT JSON; (ii) per-publisher per- domain BIMI a=https://...pem VMC cert- chain HTTPS-fetch handshake certificate-expired failure-class structurally parallel to per-publisher per-domain MTA-STS-MX- receive-side certificate-expired result-type THIS report- format reference catalogues — when the per-publisher VMC PEM-serving HTTPS endpoint's TLS cert reaches its validity-end the receiver-side BIMI evaluator's HTTPS fetch records a TLS-failure-class directly paralleling the per-publisher per-day MTA-STS-MX- receive-side certificate-expired evidence-class; (iii) per- publisher per-domain BIMI VMC cert- chain-trust-validation certificate-not-trusted / validation-failure failure-class structurally parallel to per-publisher per-domain MTA-STS-MX- receive-side certificate-not-trusted / validation-failure result-type THIS report- format reference catalogues — when the per-publisher VMC cert-chain fails to validate against the BIMI- evaluator's public-CA root-store (e.g. BIMI-evaluator's public-CA root-store does not include the issuing CA, or an intermediate cert is missing) the per- receiver per-publisher per-day BIMI evaluator records a cert-chain-trust- validation failure-class directly paralleling the per-publisher per-day MTA-STS-MX-receive-side certificate-not-trusted / validation-failure evidence-class; and (iv) per- publisher per-domain BIMI-asset HTTPS- endpoint reachability / DNS-resolution failure-class structurally parallel to per-publisher per-domain MTA-STS sts-policy-fetch-error result-type THIS report- format reference catalogues — when the per-publisher per-domain default._bimi.<publisher-domain> TXT-record-published l=/a= endpoint hostname fails DNS resolution OR refuses HTTPS connections the per- receiver per-publisher per-day BIMI evaluator records an endpoint- reachability failure-class directly paralleling the per-publisher per-day MTA-STS sts-policy-fetch-error evidence-class TLS-RPT catalogues. Pair THIS TLS-RPT report-format reference with the BIMI VMC certificates spoke when designing the per-publisher per- domain cross-protocol-pillar transport-layer observability discipline that fuses the per-publisher per-day MTA-STS-MX-receive-side TLS-handshake failure-class catalogue (TLS-RPT-JSON) with the per-publisher per-day BIMI- asset-HTTPS-delivery TLS-handshake failure-class catalogue (BIMI-evaluator- side log telemetry receivers are starting to expose) into the unified per-publisher per-domain public-CA- rooted transport-layer cryptographic- posture observability surface.
• DKIM replay attacks explained (RFC 6376 §8.6 + RFC 8617 ARC) — the DKIM-replay-attacks spoke documents the RFC 6376 §8.6 DKIM- replay threat-class as the per-publisher per-domain APPLICATION-layer per-message anti-replay diagnostic-evidence stream whose per-key-lifetime + per-message x= expiration-tag + Trusted ARC Sealer per-publisher operator- discipline runs STRUCTURALLY PARALLEL to the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate transport-layer- TLS-handshake-failure result-type evidence stream THIS page documents. Four CROSS- LAYER-DEFENSE-IN-DEPTH-OBSERVABILITY coupling axes the replay-attacks spoke documents: (i) per-publisher per- domain RFC 8460 TLS-RPT JSON-aggregate TRANSPORT-layer-TLS-handshake-failure result-type evidence stream (per-failure certificate-host-mismatch / certificate-expired / certificate-not-trusted / validation-failure / sts-policy-fetch-error rows) is STRUCTURALLY PARALLEL to the per- publisher per-domain APPLICATION-layer per- message DKIM-replay diagnostic evidence stream — per-publisher per- domain operators who consume BOTH the TLS- RPT JSON-aggregate transport-layer evidence stream THIS page documents AND the per- message DKIM-replay application-layer evidence stream the replay-attacks spoke catalogues operate the per-publisher per- domain UNIFIED FULL-STACK cryptographic- posture observability surface; (ii) per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate transport-layer evidence stream provides ZERO per-message- granularity anti-replay diagnostic signal STRUCTURALLY — an attacker who captures a per-publisher per-domain cryptographically-legitimate DKIM-signed message over a perfectly-MTA-STS-policy- fetch-successful TLS-handshake-successful connection STILL operates a per-publisher per-domain DKIM-replay attack-surface that produces ZERO transport-layer TLS-RPT JSON-aggregate evidence-row signal — the per-publisher per-domain DKIM- replay diagnostic-evidence stream the replay-attacks spoke catalogues is the ONLY per-message-granularity observability primitive that surfaces per-message DKIM- replay-attack signal at the per-publisher per-domain per-receiver per-day evidence granularity; (iii) per-publisher per-domain TLS-RPT JSON-aggregate transport-layer evidence-row SPIKE under certificate-host-mismatch / sts-policy-fetch-error result- types is the TRANSPORT-LAYER UPSTREAM evidence-signal that can RETROSPECTIVELY EXPLAIN application-layer per-publisher per-domain DKIM-replay diagnostic-evidence emission cascades — transport-layer TLS-handshake failures produce SMTP delivery latency cascades that in turn produce per-receiver verifier-side per-message DKIM verification timeout cascades that the application-layer DKIM- replay diagnostic-evidence stream captures as per-message dkim=temperror / dkim=fail evidence-rows; (iv) per-publisher per-domain joint consumption of the RFC 8460 TLS-RPT JSON-aggregate transport-layer evidence stream + per-message DKIM-replay application- layer diagnostic-evidence stream is the per-publisher per-domain DEFENSE-IN-DEPTH full-stack-observability operator- discipline primitive whose joint consumption empirically validates the per-publisher per-domain CROSS-LAYER cryptographic-anti-spoofing-and-anti-replay posture — per-publisher per- domain operators who consume ONLY the transport-layer evidence stream operate WITHOUT per-message-granularity anti-replay observability, and operators who consume ONLY the application-layer evidence stream operate WITHOUT per-connection transport- layer trust-anchor observability; the per-publisher per-domain DEFENSE-IN-DEPTH full-stack-observability operator-discipline REQUIRES JOINT consumption. Read THIS page when AUTHORING the per-publisher per-domain RFC 8460 TLS-RPT JSON-aggregate transport- layer evidence-stream ingestion + result- type-decode operator-discipline; read the replay-attacks spoke when AUDITING the per- publisher per-domain APPLICATION-layer per- message DKIM-replay diagnostic-evidence stream whose per-key-lifetime + per-message x= expiration-tag + Trusted ARC Sealer per-publisher operator-discipline runs STRUCTURALLY PARALLEL to the transport- layer evidence stream THIS page documents at the per-publisher per-domain DEFENSE- IN-DEPTH full-stack-observability boundary.
• CAA records explained — the PER-PUBLISHER-CAA-DEFINED-AUTHORIZATION- PERIMETER-VS-PER-RECEIVER-TLS-RPT-OBSERVED- DEVIATION companion to this TLS-RPT JSON report-format reference. Where THIS page documents the RFC 8460 §4 receiver-side per-failure-class JSON result-type evidence the per-publisher per-domain TLS-RPT ingestion pipeline consumes (the "result-type" catalogue including certificate-not-trusted, certificate-expired, certificate-host-mismatch, validation-failure failure- attribution rows), the CAA-records-explained spoke is the per-publisher per-domain UPSTREAM TLS-chain authorization-perimeter configuration-discipline reference documenting the per-publisher per-domain CAA RR-published 0 issue CA- allowlist whose per-publisher operator- side correctness is the load-bearing configuration-discipline floor that GATES whether receiver-side TLS-chain validation produces the canonical "policy-string" sts per-message TLS-chain-trust pass-evidence vs the per-failure-class certificate-mismatch / chain-trust-failure evidence the RFC 8460 §4 JSON report result-type catalogue THIS page documents enumerates. The PER-PUBLISHER-CAA-VS-PER- RECEIVER-TLS-RPT cross-reference establishes FOUR per-publisher per-domain TLS-chain authorization-and-observability coupling dimensions: (i) per- publisher CAA 0 issue allowlist defines the AUTHORIZED issuance perimeter; per-receiver TLS-RPT JSON report-format "result-type" rows surface DETECTED DEVIATION from that perimeter as receiver-side evidence the per-publisher per-domain TLS-chain audit pipeline consumes; (ii) per- publisher CAA iodef=mailto: per-CA unauthorized-issuance-attempt incident-report endpoint structurally pairs with per-publisher TLS-RPT rua=mailto: per-receiver- aggregate per-failure-class incident- report endpoint as the publisher-side full-stack TLS-chain incident-report channel covering both per-CA issuance- time incidents AND per-receiver validation-time incidents; (iii) per-publisher CAA RR-set publication cadence and per-publisher MTA-STS / TLS-RPT TXT-RR publication cadence at the SAME per-domain apex-zone-editor commit cycle forms the per-publisher per-domain unified TLS-chain authorization-and-observability deployment discipline; (iv) per-publisher per-domain CAA accounturi= ACME-account binding (RFC 8657) constrains which ACME-account-bound automated-issuance clients can fulfil per-publisher per- domain certificate-issuance requests, and receiver-side TLS-RPT JSON evidence surfaces per-failure-class evidence of misbound or revoked ACME-account issuance attempts.
• Email spoofing techniques and defenses — the SEVEN-TECHNIQUE-SPOOFING-ATTACK- CATALOGUE companion to this TLS-RPT JSON report-format byte-grammar reference. Where THIS page documents the RFC 8460 §4 per-publisher per- policy-domain JSON-aggregate report byte-grammar (the organization-name / date-range / contact-info / report-id envelope elements, the per-policies per-policy-type evaluation record, the per-failure-details per-result-type attribution payload with the 13 canonical result-type registry values), the email-spoofing spoke documents the seven-technique attack catalogue whose transport-layer spoofing-delivery variants the TLS-RPT result-type registry surfaces as forensic-evidence at four TLS-RPT-as-anti-spoofing coupling dimensions: (i) starttls-not-supported result-type rows surface the STARTTLS- strip cleartext-delivery spoofing technique class — the seventh spoofing technique in the catalogue (STARTTLS-strip-and-cleartext-delivery) produces per-receiver per-day spikes in this result-type at TLS-RPT- publishing receivers when an active attacker strips the receiver-MX STARTTLS EHLO advertisement, providing the per-spoofing-attempt forensic- attribution row the email-spoofing catalogue incident-response section consumes; (ii) certificate-host-mismatch and certificate-not-trusted result-type rows surface the MX- impersonation rogue-receiver spoofing sub-class — the catalogue documents MX-substitution delivery-redirection variants where attackers redirect MX resolution to an attacker-controlled MX hostname or BGP-hijack the MX IP-space; the TLS-RPT result-type catalogue surfaces per-receiver per-day per-sending-MTA- IP attribution rows distinguishing rogue-MX-substitution from rogue-CA- mis-issuance attempts the email- spoofing catalogue rogue-receiver sub-class catalogues; (iii) tlsa-invalid / dnssec-invalid / dane-required result-type rows surface the DANE-chain-tampering transport-layer spoofing variant — attackers attempting to tamper with the DNSSEC-anchored TLSA- RR chain produce these result-type rows feeding the per-sending-MTA-IP attribution-evidence the email- spoofing catalogue threat-modelling section consumes when characterising the cryptographic-trust-anchor- tampering attack class; (iv) sending-mta-ip per-failure attribution joined against per- receiver per-day RUA aggregate-report rows produces the unified spoofing- delivery-channel observability matrix — the JSON schema per- row sending-mta-ip attribution field combined with the per-receiver per-day per-source-IP DMARC-aligned-fail-rate distribution the email-spoofing catalogue empirical-detection section operationalises produces the per- attacker-infrastructure forensic- evidence matrix the incident-response retrospective workflow consumes across the application-layer and transport-layer authentication- evaluation boundaries. Read the email-spoofing catalogue alongside this TLS-RPT JSON report-format byte- grammar reference when constructing the security-team transport-layer- spoofing-delivery-detection workflow whose per-attack-attempt forensic- evidence-row record the email- spoofing catalogue defense-in-depth recommendations section operationalises.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-TLS-RPT- JSON-AGGREGATE-REPORT-CADENCE-AS-LOAD- BEARING-CROSS-LAYER-OBSERVABILITY-COMPLEMENT- OF-PER-PUBLISHER-PER-DOMAIN-DMARC-RUA- AGGREGATE-XML-REPORT-CADENCE companion to this RFC 8460 §4 TLS-RPT JSON-report-format byte-grammar reference. Where THIS page documents the per-publisher per-domain TLS-RPT JSON-aggregate-report byte-grammar at the RFC 8460 §4 schema layer (the per-publisher per-domain per-receiver per- day JSON-aggregate-report policies[] / failure-details[] / result-type registry enumeration, the per-receiver per-MX-IP per-session per-failure-class evidence- row payload, the per-publisher per-domain contact-info / report- id / date-range metadata fields), the DMARC-policy-rollout spoke is the PER-PUBLISHER-PER-DOMAIN- DMARC-RUA-AGGREGATE-XML-REPORT-CADENCE-AS- STRUCTURALLY-PARALLEL-COMPLEMENT companion documenting the per-publisher per-domain canonical DMARC policy-mode-ramp progression (p=none 30+ days monitoring → p=quarantine pct=10/25/50/100 per-cohort ramp → p=reject pct=100) whose per-phase per- publisher per-domain commitment-readiness gate consumes per-publisher per-domain DMARC RUA aggregate-XML-report evidence at the application-layer authentication boundary. Four TLS-RPT-vs-DMARC-rollout coupling dimensions matter at the per- publisher per-domain multi-phase ramp boundary: (i) per-publisher per-domain per-phase per-day per-receiver cross-layer observability stream — both per-publisher per-domain DMARC RUA aggregate-XML-report AND per-publisher per-domain TLS-RPT JSON- aggregate-report streams emit per-day per-receiver per-source-IP forensic- evidence rows whose per-phase per-publisher per-domain aggregate-pass-rate floor gates per-phase progression — application-layer DKIM-and-SPF-aligned-pass-rate floor for the DMARC leg, transport-layer STARTTLS- success-rate floor for the TLS-RPT leg; (ii) per-publisher per-domain per-phase rua-and-rua-mailbox subscription coordination — the per-publisher per- domain rua=mailto:<rua-mailbox> DMARC tag AND the per-publisher per- domain rua=mailto:<tls-rpt-rua- mailbox> TLS-RPT tag publication together compose the per-publisher per- domain operator-side per-day per-aggregate- stream subscription-and-monitoring discipline the per-publisher per-domain DMARC policy-rollout depends on for per- phase commitment-readiness evidence- gathering; (iii) per-publisher per-domain per-phase forensic-evidence triangulation — when a per-receiver per-publisher per- domain per-message DMARC-fail event surfaces in the per-publisher per-domain DMARC RUA aggregate-XML-report row, 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., starttls-not-supported, certificate-host-mismatch, validation-failure) that triangulates whether the per-publisher per-domain DMARC-fail is application-layer authentication-side or transport-layer downgrade-induced; (iv) per-publisher per- domain per-phase rollback observability — both per-publisher per-domain aggregate- report streams produce per-phase forensic- evidence the per-publisher per-domain DMARC policy-rollout depends on for per-phase rollback decisions when per- receiver per-message false-positive deliverability degradation surfaces; per- publisher per-domain DMARC p= quarantine pct=N downward-pct- adjustment + per-publisher per-domain DMARC p=none downgrade rollback options the per-publisher per- domain DMARC policy-rollout retains depend on cross-layer aggregate-report evidence the per-publisher per-domain TLS-RPT JSON-aggregate-report byte- grammar THIS page enables. Read THIS page when CONSUMING the per-publisher per- domain TLS-RPT JSON-aggregate-report byte-grammar evidence stream; read the DMARC-policy-rollout spoke when SEQUENCING the per-publisher per-domain DMARC policy-mode-ramp progression whose per- phase per-publisher per-domain commitment- readiness gate consumes the per-publisher per-domain TLS-RPT JSON-aggregate-report cross-layer observability stream THIS page documents the byte-grammar of.
• DKIM selectors explained — the PER-PUBLISHER-PER-DOMAIN-TLS-RPT- JSON-REPORT-BYTE-GRAMMAR-AS-TRANSPORT-LAYER- OBSERVABILITY-PUBLICATION-PARALLEL-TO-PER- SELECTOR-DKIM-APPLICATION-LAYER-OBSERVABILITY companion to THIS per-publisher per-domain TLS-RPT JSON-aggregate-report byte-grammar reference. Where THIS page documents the per-publisher per-domain RFC 8460 §4 TLS- RPT JSON-aggregate-report byte-grammar (the organization-name / contact-info / report-id / policies[] / summary{} / failure-details[] JSON-object publication discipline, the RFC 8460 §4.3 result-type-registry catalogue (starttls-not-supported, certificate-host-mismatch, certificate-expired, etc.), the RFC 8460 §5.1 MIME-type and filename conventions, the per-publisher per-domain JSON-aggregate-report inbound-mailbox ingestion cadence), the DKIM-selectors- explained spoke documents the per-publisher per-selector DKIM-selector publication discipline at FOUR per-TLS-RPT-report- format-vs-DKIM-selector coupling dimensions: (i) per-publisher per-domain TLS-RPT JSON-aggregate-report per-receiver per-day observability evidence stream AS transport- layer cross-layer observability complement to per-publisher per-selector DKIM-aligned- pass-rate per-receiver per-day RUA aggregate-XML evidence stream — the per-publisher per-domain TLS-RPT JSON- aggregate-report per-receiver per-day per- publisher per-domain TLS-handshake-failure- rate evidence stream IS the per-publisher per-domain transport-layer cross-layer observability complement; the per-publisher per-domain DMARC RUA aggregate-XML report per-receiver per-day per-publisher per- selector per-disposition row stream IS the per-publisher per-domain application-layer observability evidence stream that per- publisher per-selector DKIM-aligned-pass- rate-floor maintenance THIS per-selector publication discipline documents is observable through; the two are structurally parallel per-publisher per-domain transport- layer + application-layer observability- evidence-stream publication-coordination disciplines; (ii) per-publisher per- domain TLS-RPT failure-details per-failure- attribution JSON-row AS transport-layer per-failure-attribution observability primitive structurally parallel to per- publisher per-selector DKIM-Signature per- verdict per-failure-attribution observability primitive — the per- publisher per-domain TLS-RPT failure-details[] JSON-array per-failure-attribution structure IS the per-publisher per-domain transport-layer per-failure-attribution observability primitive at the per-publisher per-domain transport-layer cryptographic-channel- evaluation boundary; the per-publisher per- selector DKIM-Signature per-verdict per- failure-attribution observability (the per- publisher per-selector DKIM-verdict diagnostic catalogue dkim=fail / permerror / temperror) IS the per-publisher per-selector application-layer per-failure-attribution observability primitive at the per-publisher per-selector cryptographic-validation boundary; the two are structurally parallel per-publisher per-domain transport-layer + application-layer per-failure-attribution observability publication-coordination disciplines; (iii) per-publisher per-domain TLS-RPT JSON-aggregate-report cadence floor AS transport-layer- observability-floor publication-coordination complement to per-publisher per-selector DKIM-aligned-pass-rate-floor application- layer-observability-floor — the per- publisher per-domain TLS-RPT JSON-aggregate- report cadence floor (per-publisher per- domain daily aggregate-report ingestion cadence) IS the per-publisher per-domain transport-layer-observability-floor publication-coordination primitive; the per- publisher per-selector DKIM-aligned-pass- rate floor IS the per-publisher per-selector application-layer-observability-floor publication-coordination primitive; the two are structurally parallel per-publisher per- domain observability-floor publication- coordination disciplines at the per-publisher per-domain transport-layer + application- layer composite-observability-coordination boundary; (iv) per-publisher per- domain TLS-RPT JSON-aggregate-report publication-discipline AS per-publisher per- domain transport-layer-observability- publication input AND per-publisher per- selector DKIM-selector publication-discipline AS per-publisher per-domain application- layer-observability-publication input at unified composite-publication-coordination boundary — the per-publisher per- domain unified-trust-signal-floor publication posture rests on per-publisher per-domain TLS-RPT transport-layer-observability publication + per-publisher per-domain DMARC application-layer-observability publication; the per-publisher per-domain TLS-RPT report- format publication discipline THIS page documents IS the per-publisher per-domain transport-layer-observability publication input AND the per-publisher per-selector DKIM-selector publication discipline IS the per-publisher per-selector application-layer cryptographic-identity publication input that the per-publisher per-domain unified composite-publication-coordination boundary depends on. Read THIS page when AUTHORING per-publisher per-domain TLS-RPT JSON- aggregate-report ingestion-pipeline; read the DKIM-selectors-explained spoke when UNDERSTANDING how the per-publisher per- selector DKIM-selector publication discipline IS the per-publisher per-domain application-layer publication-discipline structurally parallel to the per-publisher per-domain TLS-RPT JSON-aggregate-report transport-layer-observability publication- discipline at the per-publisher per-domain composite-observability-coordination boundary.
• Email security & privacy glossary — the cross-protocol security-and- privacy threat-and-defense vocabulary registry consumed at four per-TLS-RPT- result-type vs cross-protocol-threat- catalogue coupling dimensions.
• DKIM cryptography basics — the APPLICATION-LAYER-DKIM-CRYPTOGRAPHIC- PRIMITIVE-CHOICE-AS-STRUCTURAL-PARALLEL-TO- TRANSPORT-LAYER-X.509-CHAIN-CRYPTOGRAPHIC- TRUST companion to this TLS-RPT report-format reference. Where THIS page documents the per-publisher per-domain RFC 8460 §4 TLS-RPT JSON aggregate-report byte-grammar for transport-layer cryptographic-observability (per-receiver per-day STARTTLS / MTA-STS / DANE result-type breakage classification), the DKIM-cryptography-basics spoke is the APPLICATION-LAYER cryptographic-primitive choice the per-publisher per-domain DKIM- signing posture publishes complementary to the transport-layer cryptographic-trust posture TLS-RPT observes. Four cross-layer cryptographic-primitive-coordination dimensions: (i) APPLICATION-LAYER-DKIM- PUBLIC-KEY-PUBLICATION-VS-TRANSPORT-LAYER- X.509-CHAIN-PUBLICATION (per-publisher per- selector DKIM DNS-TXT-RR p= public-key publication structurally parallel to per-MX-host TLS-certificate-chain presentation at per-TLS-session handshake; cryptographic-primitive choice at each layer is independently auditable); (ii) APPLICATION-LAYER-RSA-2048-VS-TRANSPORT- LAYER-X.509-RSA-2048-VS-ECDSA-P256 (modern application-layer DKIM-signing on RSA-2048 parallels modern transport-layer TLS certificates on RSA-2048 or ECDSA P-256; TLS-RPT does NOT observe application-layer DKIM-signing failures — they surface in DMARC RUA streams instead, requiring per-publisher per-domain operators to read both cryptographic-observability streams); (iii) APPLICATION-LAYER-DKIM-KEY-ROTATION- VS-TRANSPORT-LAYER-CERT-RENEWAL-CADENCE (per-publisher per-selector DKIM-key rotation cadence is structurally parallel to per-MX-host TLS-cert-renewal cadence; TLS-RPT's certificate-expired result-type observes per-MX-host cert- renewal slippage but does NOT observe per-selector DKIM-key rotation slippage); (iv) APPLICATION-LAYER-DKIM-CRYPTOGRAPHIC- FLOOR-AS-LOAD-BEARING-DMARC-AUTHENTICATION- LEG-VS-TRANSPORT-LAYER-CRYPTOGRAPHIC-FLOOR- AS-LOAD-BEARING-MTA-STS-ENFORCE-LEG (per- publisher per-selector DKIM cryptographic- strength gates DKIM-aligned-pass leg of DMARC; per-MX-host transport-layer cryptographic-strength gates STARTTLS- enforce leg of MTA-STS — both are independently observable cryptographic- publication-discipline-and-survival primitives at per-publisher per-domain composite cross-layer cryptographic- publication-portfolio coordination floor). Read the DKIM-cryptography-basics spoke alongside this TLS-RPT report-format reference when AUTHORING the per-publisher per-domain composite cross-layer cryptographic-publication discipline, when AUDITING per-publisher per-domain application-layer DKIM cryptographic- primitive choice against the transport- layer cryptographic-trust posture TLS-RPT observes, or when CORRELATING per-receiver per-day per-result-type transport-layer TLS-RPT breakage with per-publisher per- domain DMARC-RUA application-layer DKIM- aligned-pass-rate erosion at composite cross-layer cryptographic-floor regressions.
• DKIM best practices
• DKIM failures explained
• ARC (Authenticated Received Chain, RFC 8617) explained
• DKIM troubleshooting
• SPF for Microsoft 365 — per-M365-tenant per-accepted- domain SPF authorisation publication- discipline IS the canonical per-tenant envelope-MAIL-FROM-layer application- layer authentication-leg whose per- receiver SPF-evaluation cascades into per-tenant per-accepted-domain DMARC RUA aggregate-report policy_evaluated/spf attribution per RFC 7489 §6.6.1 application-layer per-leg verdict- evidence stream structurally parallel to the per-publisher per-policy-domain TLS-RPT JSON-aggregate-report failure-details transport-layer per-leg verdict- evidence stream per RFC 8460 §4.3 THIS page documents the per-publisher per-domain transport-layer aggregate- report-format publication-discipline of — the per-M365-tenant per- accepted-domain composite SPF + DKIM + DMARC application-layer authentication- leg per-day per-receiver-side per-leg- verdict-evidence observability stream IS the cross-protocol application-layer companion to the per-publisher per- policy-domain TLS-RPT transport-layer per-leg-verdict-evidence observability stream the TLS-RPT report-format reference architects at the per- publisher per-domain composite cross- protocol cross-layer per-day per-leg aggregate-observability coordination boundary.
• SPF (Sender Policy Framework) primer
• DKIM DNS TXT-record byte syntax
• DKIM key rotation
• DMARC troubleshooting — the application-layer diagnostic companion to this transport-layer TLS-RPT report-format reference. Where this page documents the per-publisher per-domain TLS-RPT JSON aggregate-report byte-structure (the failure-details per-event-type transport-layer failure catalogue — sts-policy-fetch-error, certificate-host-mismatch, certificate-expired, starttls-not-supported — delivered at _smtp._tls.<domain> per RFC 8460), the DMARC-troubleshooting spoke documents the structurally-parallel application-layer diagnostic path: how the operator triages the per-source dkim=fail / spf=fail / alignment-fail rows in the DMARC RUA aggregate stream back to their authentication root cause. Both are per-domain aggregate-report-driven diagnostic disciplines — the TLS-RPT report this page documents surfaces transport-layer TLS-delivery failures, while the DMARC-troubleshooting spoke surfaces application- layer authentication failures — and an operator monitoring one aggregate stream almost always needs the other. Read the DMARC-troubleshooting spoke when correlating a TLS-RPT transport-layer failure on this page with a concurrent DMARC authentication regression in the same per-domain reporting window.
• SPF for Google Workspace
• DMARC for SaaS & platform senders — a platform sending for many tenants needs both observability streams this report-format reference sits in: the TLS-RPT transport-layer JSON aggregate here, and the DMARC RUA application-layer aggregate the SaaS deployment relies on. Read the SaaS-senders guide alongside this report-format reference when you are operating a platform and need to separate a transport-layer STARTTLS regression from a per-tenant authentication-alignment fault across your customer domains.
• SPF qualifiers explained — the +/-/~/? prefix you publish is what turns an SPF mismatch into an actionable spf=fail in the DMARC aggregate stream, just as the TLS-RPT report format this page documents turns a transport failure into an actionable result; read the qualifier reference to decide whether ~all or -all matches the enforcement posture your reporting is meant to verify.
• SPF mechanisms explained — TLS-RPT reports transport-layer delivery security, while the DMARC RUA aggregate stream reports the spf= verdict each source IP produced; the SPF mechanism catalogue (a/mx/ip4/include/all + the RFC 7208 §4.6.4 10-DNS-lookup cap) is what builds the authorized-sender set behind those verdicts. Read it to understand which mechanism authorized (or failed to authorize) a sender before correlating the two companion report streams.
• DKIM for Microsoft 365 — the per-publisher per-domain application-layer message-signing companion to this transport-layer report-format reference for the same Microsoft 365 tenant. Where THIS page documents the RFC 8460 §4 TLS-RPT transport-layer JSON aggregate that surfaces STARTTLS-negotiation health on the M365 tenant's MX legs, the DKIM-for-M365 spoke documents the selector1/selector2._domainkey CNAME-delegated message-layer signing keys whose aligned dkim=pass the receiver verifies independently of the transport hop — the two are distinct-layer per-domain controls a Microsoft 365 operator publishes for the same domain: read the DKIM-for-M365 spoke alongside this TLS-RPT report-format reference when separating a transport-layer STARTTLS regression on this page from a message-layer DKIM-signature/alignment fault in the same M365 reporting window.
• DKIM canonicalization (relaxed vs simple c=) — THIS page documents the RFC 8460 §4 transport-layer JSON aggregate that reports STARTTLS-negotiation health on your MX legs; DKIM canonicalization governs message-layer signature integrity — whether the c= choice (relaxed vs simple header/body) keeps a signature valid after an intermediary alters whitespace, folding, or MIME encoding. The two are distinct-layer integrity controls: TLS-RPT surfaces a channel-security regression, while a canonicalization mismatch surfaces as a dkim=fail in your DMARC aggregate feed. Read it when separating a transport-layer STARTTLS fault on this page from a message-layer signature break in the same reporting window.
• RFC 8460 §4 — TLS-RPT report format — the normative specification.
• RFC 8460 §4.3 — result-type registry — the normative result-type catalogue.
• RFC 8460 §5.1 — report delivery — the MIME type and filename conventions.
• RFC 8460 — SMTP TLS Reporting — the full normative reference.
• 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.

Ingest TLS-RPT reports now

DMARC Analyzer ingests TLS-RPT JSON reports and surfaces per-policy session counts and per-failure result-type breakdowns in the dashboard. Configure the rua= destination to point at your DMARC Analyzer mailbox or upload an existing report file directly through the dashboard.

Sign up — Free plan Audit my TLS-RPT record