DMARC Analyzer

TL;DR

• DMARC forensic reports (also called RUF reports after the ruf= tag, or failure reports) are per-message reports a receiver sends back to a domain owner whenever an individual message fails DMARC. Defined in RFC 7489 §7.3.
• Unlike aggregate (RUA) reports — daily statistical summaries with no message content — forensic reports include the failing message's headers (From, To, Subject), sometimes the body, and structured fields naming the authentication failure mode.
• The envelope is the Authentication Failure Reporting Format (AFRF) defined in RFC 6591 — a multipart/report MIME message with report-type=feedback-report carrying three parts: human-readable description, machine-readable message/feedback-report key-value block, and the original failing message (or its headers).
• The fo= tag (failure-reporting options, RFC 7489 §6.6.4) controls WHEN reports are emitted: fo=0 on full DMARC failure, fo=1 on partial failure (recommended for active rollouts), fo=d on DKIM failure, fo=s on SPF failure.
• Major receiver coverage is poor: Google has never sent RUF, Microsoft / Outlook does not send RUF, Yahoo stopped years ago. Mostly small corporate gateways and a handful of niche ISPs still emit forensic reports.
• Privacy / GDPR: forensic reports include personal data belonging to email recipients who never consented to forwarding. Most receivers stopped sending RUF specifically because of GDPR Article 5 / CCPA data-minimisation concerns. Treat the ruf= mailbox as a restricted-access security inbox.
• DMARC Analyzer ingests RUF via includes/ForensicReportParser.php (RFC 6591 AFRF envelope, with auto- detection for MIME multipart, plain feedback-report, and the arf+xml variant). Records persist to dmarc_forensic_reports.

1. What is a DMARC forensic report?

A DMARC forensic report — also called a RUF report after the ruf= tag in the DMARC record that publishes the destination address, or a failure report — is a per-message report a receiving mail provider sends back to the domain owner whenever a specific inbound message fails DMARC. The format is defined in RFC 7489 §7.3 and the underlying envelope (Authentication Failure Reporting Format, AFRF) is defined in RFC 6591, which itself extends the older Abuse Reporting Format defined in RFC 5965.

The data model is fundamentally different from the aggregate-report sibling:

• Granularity: per message (not per-day-grouped). One failing message produces one forensic report.
• Payload: the original failing message's headers (From:, To:, Subject:, all Received: chain), often the full message body, and a structured key-value block (Feedback-Type, Reported-Domain, Auth-Failure, Source-IP, Original-Mail-From, DKIM-Domain, DKIM-Selector).
• Cadence: triggered the moment the receiver processes a failing message — typically delivered within minutes rather than the daily 24-hour batch cadence of RUA.
• Volume: zero (most receivers do not send RUF) to a steady trickle (smaller corporate gateways) to very rarely a flood (a misconfigured sender producing many failures).

Operators publish ruf= for two legitimate reasons:

• Deep-dive diagnostics — when an aggregate-report record shows a cluster of failures from an unexpected IP and the operator needs the per-message headers to identify the sender (the aggregate report only carries the source IP, not the Received: chain or the Subject:).
• Active phishing investigation — when an operator suspects an active spoofing campaign and needs immediate per-message visibility rather than waiting for the next daily aggregate report.

For everyday rollout monitoring, aggregate reports (see DMARC aggregate reports) are the primary diagnostic stream. Forensic reports are a targeted supplement, not a replacement.

2. The RUF mechanism: how forensic reports get generated and delivered

1. The sender publishes a DMARC TXT record at _dmarc.example.com with a ruf= tag listing one or more report destination URIs (typically mailto: addresses). ruf=mailto:dmarc-forensic@example.com is the minimum.
2. The sender optionally publishes a fo= tag to scope which failures trigger a report. The default fo=0 fires only when both SPF and DKIM fail to produce an aligned pass — fo=1 fires on either failure (recommended for active rollouts; see Section 5 below).
3. The receiver consumes the DMARC record on every inbound message claiming the sender's domain in From:. For each such message the receiver evaluates SPF, DKIM, and alignment.
4. If the message fails per the published fo= options, the receiver constructs an AFRF MIME message: a multipart/report envelope containing the human-readable description, the machine-readable message/feedback-report key-value block, and the original failing message (or its headers).
5. The receiver emails the AFRF message to every mailto: address in ruf=. Delivery is typically within minutes of the failing message arriving — there is no daily batching as in RUA.
6. The sender ingests the AFRF message (typically via tooling like includes/ForensicReportParser.php), parses the multipart envelope, persists the structured fields, and surfaces the per-message forensic record in the dashboard.

Two RFC-defined nuances matter for the forensic mechanism:

• Cross-domain authorisation (RFC 7489 §7.1): just as for aggregate reports, the ruf= mailbox does not have to be on the same domain as the DMARC-protected sender. The receiver checks for a example.com._report._dmarc.aggregator.example authorisation record before sending cross-domain. Without it, receivers SHOULD NOT send reports across domain boundaries.
• Sampling (RFC 7489 §7.3): receivers MAY sample forensic reports rather than emitting one per failing message — for example, sending a forensic report for only one out of every N failing messages from the same source IP. Sampling is implementation-defined; do not depend on a 1:1 message-to-report ratio when sizing the ruf= mailbox.

3. The AFRF MIME and feedback-report schema

The keystone reference for this page. RFC 6591 extends RFC 5965 to define the feedback-report part used by DMARC forensic reports. An AFRF message is a multipart/report MIME message with report-type=feedback-report containing three parts in order.

MIME envelope structure

The feedback-report part — key-value fields

The message/feedback-report part is the structured payload every parser extracts. Fields are Key: Value pairs in RFC 5322 header style.

DMARC Analyzer's parser at includes/ForensicReportParser.php handles three input variants of this schema:

• Raw MIME .eml / .txt — the full multipart/report message emitted by RFC 6591-compliant receivers.
• Plain feedback-report body — a bare key-value block without the surrounding MIME envelope (some legacy receivers emit this).
• XML arf+xml — a non-standard XML serialisation a small number of providers use instead of the RFC 6591 MIME format. The parser normalises XML field names to the standard MIME field names.

4. A worked forensic-report example

A minimal AFRF forensic report from a smaller receiver about a spoofing attempt against example.com:

From: dmarc-forensic@receiver.example
To: dmarc-forensic@example.com
Subject: DMARC failure report for example.com from receiver.example
Date: Sun, 19 May 2026 14:23:11 +0000
MIME-Version: 1.0
Content-Type: multipart/report; report-type=feedback-report;
    boundary="----=_NextBoundary_PROD_1716163391"

------=_NextBoundary_PROD_1716163391
Content-Type: text/plain; charset=UTF-8

This is an authentication failure report for an email message received
from 192.0.2.200 on Sun, 19 May 2026 14:23:08 +0000.  For more information
about this format please see https://datatracker.ietf.org/doc/html/rfc6591

------=_NextBoundary_PROD_1716163391
Content-Type: message/feedback-report

Feedback-Type: auth-failure
Version: 1
User-Agent: ReceiverFBL/2.4
Original-Mail-From: bounce@attacker.example
Original-Rcpt-To: alice@receiver.example
Arrival-Date: Sun, 19 May 2026 14:23:08 +0000
Source-IP: 192.0.2.200
Reported-Domain: example.com
Auth-Failure: dmarc
DKIM-Domain: attacker.example
DKIM-Selector: default
DKIM-Identity: @attacker.example
Identity-Alignment: none
Delivery-Result: policy
Authentication-Results: receiver.example;
    spf=fail smtp.mailfrom=attacker.example;
    dkim=fail (signature did not verify) header.d=attacker.example header.s=default;
    dmarc=fail action=quarantine header.from=example.com

------=_NextBoundary_PROD_1716163391
Content-Type: message/rfc822-headers

Received: from mta-out.attacker.example (mta-out.attacker.example [192.0.2.200])
    by mx.receiver.example with ESMTPS id ABC123
    for <alice@receiver.example>; Sun, 19 May 2026 14:23:08 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=attacker.example;
    s=default; t=1716163388; bh=...; b=...
From: "Example Support" <support@example.com>
To: alice@receiver.example
Subject: Your account requires verification
Date: Sun, 19 May 2026 14:23:08 +0000
Message-ID: <abc-1234@attacker.example>

------=_NextBoundary_PROD_1716163391--

Reading the report:

• The reporter is a smaller receiver (receiver.example) that still emits forensic reports. Source-IP: 192.0.2.200 identifies the sending host — cross-reference this against the operator's known legitimate sending IPs.
• The claimed sender is example.com (the Reported-Domain and the From: header in the original message) but the SMTP envelope From is bounce@attacker.example — the canonical SPF-misalignment signature.
• DKIM signed over attacker.example with selector default — the DKIM signature is valid for the wrong domain, so DKIM alignment fails too.
• Identity-Alignment: none confirms neither SPF nor DKIM aligned to example.com. Delivery-Result: policy means the receiver applied the published DMARC policy (p=quarantine or p=reject).
• The Subject: — "Your account requires verification" — and the From: header confirm the message was a phishing lure. This is the per-message forensic detail aggregate reports cannot provide.

5. The fo= tag — failure-reporting options

The fo= tag in the DMARC record (defined in RFC 7489 §6.6.4) controls WHEN receivers emit forensic reports. Without an explicit fo= tag, the default value is fo=0 — emit reports only when DMARC evaluation produces a full failure.

Multiple values can be combined with a colon separator:

fo=d:s   # forensic report on any DKIM OR any SPF failure
fo=0:d:s # default DMARC failures + DKIM failures + SPF failures

Recommendation for new rollouts: publish fo=1 so partial-fail edge cases surface (these are the exact misalignments a rollout needs to remediate before enforcement). Switch to fo=0 after enforcement to scope reports to active phishing attempts.

Receivers honour fo= on a best-effort basis — many receivers ignore the tag entirely and emit reports per their own internal policy. Do not depend on fo= for precise filtering.

6. Who still sends DMARC forensic reports?

A clear-eyed assessment of major-receiver coverage in 2026:

The practical reality: a domain that publishes ruf= and receives 10 GB / day of legitimate mail through major consumer mailboxes will receive zero forensic reports from those receivers. The trickle of reports that does arrive comes from smaller corporate gateways and niche ISPs covering a small fraction of consumer mail volume.

This is the single most common misconception about DMARC forensic reports: operators publish ruf= expecting a per-message firehose, and instead receive a tiny stream they cannot rely on for diagnostic purposes.

7. Privacy, GDPR, and CCPA implications

Forensic reports include personal data belonging to email recipients who never consented to having their messages forwarded to the report destination. Specifically:

• The recipient's email address (Original-Rcpt-To) — direct personal data under GDPR Article 4 (1).
• The sender's email address (Original-Mail-From) — direct personal data for any human sender (less so for automated systems).
• The subject line — often contains personal context (e.g. "Your account verification", "Order confirmation #12345"), which can be special-category data under GDPR Article 9 if the subject reveals health, political, religious, or other sensitive attributes.
• The full message body (if the receiver does not redact it) — the most sensitive payload, potentially carrying any content the original sender included.
• The full Received: chain — the routing path through intermediate mail servers, which can identify network infrastructure.

Why most receivers stopped sending RUF: when GDPR took effect in May 2018 most major European and US receivers re-evaluated forensic-report emission. The legal conclusion at most major receivers was that forwarding recipient-PII to third-party domains required a lawful basis under GDPR Article 6 that most domain-owner arrangements did not document. The operational conclusion was that aggregate reports provide sufficient diagnostic value for DMARC rollouts without the privacy exposure, so forensic emission was a net risk with limited benefit. Yahoo's high-profile decision to stop emitting RUF in 2018 set the precedent the industry followed.

If you receive forensic reports, treat the mailbox as restricted-access security data:

• Limit mailbox access to the security / deliverability team only.
• Document a retention limit (e.g. 90 days) and automate purges.
• Do not log report contents in third-party ticketing, observability, or analytics platforms without explicit DPA coverage.
• Restrict sharing of forensic-report artefacts to the minimum necessary personnel.
• If your DPO has not classified the ruf= mailbox, document its data category and retention before publishing the tag.

For most rollouts, the cleanest legal posture is to not publish ruf= at all and rely exclusively on aggregate reports. The diagnostic gap is small (aggregate reports name the source IP, the count, the auth-results domains, and the disposition); the legal exposure of forensic reports is not. Publish ruf= only when your security team has explicit retention, access, and processing-basis documentation.

8. Reading forensic reports operationally

Forensic reports are dense, individually information-rich, but sparse in volume — a single forensic report carries more diagnostic signal than a single aggregate- report record, but you receive far fewer of them. The operational reading pattern is fundamentally different from aggregate-report consumption.

DMARC Analyzer's ingestion pipeline at includes/ForensicReportParser.php parses the AFRF MIME envelope, extracts the feedback-report key-value block, persists structured fields to the dmarc_forensic_reports table, deduplicates by (arrival_date, source_ip, reported_domain, original_mail_from), and surfaces per-report drill-downs in the dashboard.

The diagnostic questions forensic reports answer that aggregate reports cannot:

• What did the spoofed message actually say? The Subject: and message body identify whether the attack was a phishing lure, a malware delivery, a business-email-compromise impersonation, or commercial spam abusing the brand. Aggregate reports never carry this content.
• What is the full sending infrastructure? The Received: chain shows every intermediate hop between the spoofing host and the receiver — useful for identifying compromised relays, botnet infrastructure, or open proxies.
• What DKIM signature did the attacker attempt? DKIM-Domain + DKIM-Selector identify which domain the attacker tried to sign with. A signed message from attacker.example with selector default is the canonical naive-spoof signature; a signature with the protected domain's own selector but a wrong key is the canonical compromised-key signature.
• Which legitimate sender is misaligned? When forensic reports arrive for a known legitimate sending IP, the Identity-Alignment field names exactly which mechanism failed alignment — letting you choose between fixing the SPF include: chain or fixing the DKIM signing domain.

Operational workflow:

1. Aggregate reports surface a suspicious cluster (e.g. 200 messages from a new IP with disposition quarantine).
2. If forensic reports arrive for that IP, drill into the per-message Subject: and Received: chain to classify the activity (phishing / BEC / commercial spam / misconfigured legit sender).
3. If forensic reports do not arrive (the majority case), use the Header Analyzer (header_analyzer.php) on any captured sample message, or check the source-IP via blacklist_checker.php to triage from the aggregate-report data alone.

9. ruf= mailbox best practices

• Use a dedicated address. Forensic-report traffic is small but irregular — bursts can happen during active spoofing campaigns. Do not point ruf= at a shared inbox or a personal mailbox. A dedicated dmarc-forensic@ mailbox keeps the surface scoped and auditable.
• Restrict access. Only the security / deliverability team should read forensic reports. Apply principle of least privilege and document who has access.
• Automate ingestion. Use DMARC Analyzer's IMAP fetcher (see imap_fetch.php + includes/ImapFetcher.php) or the Microsoft Graph fetcher (includes/GraphFetcher.php) to pull reports automatically rather than reading them by hand.
• Document retention. Forensic reports contain personal data. Apply a documented retention limit (90 days is typical) and automate purges. DMARC Analyzer's dmarc_forensic_reports table can be pruned by arrival_date.
• Host the mailbox on a DMARC-passing domain. Just like the rua= mailbox, the ruf= mailbox must itself pass DMARC at the destination — otherwise the receiver may reject the report email and you lose the signal silently.
• Use cross-domain authorisation if the forensic mailbox is at a different domain than the DMARC-protected sender. Publish a TXT record at protected-domain._report._dmarc.forensic-host containing v=DMARC1. Without it, receivers SHOULD NOT send cross-domain reports.
• Start with fo=1 for active rollouts so partial-fail edge cases surface. Tune down to fo=0 after the rollout stabilises.
• Treat forensic reports as a supplement, not a primary signal. Aggregate reports are the everyday diagnostic stream; forensic reports are the rare targeted deep-dive.

10. Common forensic-report mistakes

• Publishing ruf= without a documented privacy process. Forensic reports contain recipient PII. Without a documented data-processing basis, retention limit, and access policy, the ruf= mailbox is a GDPR / CCPA liability. Most rollouts should NOT publish ruf= until this paperwork exists.
• Expecting major-receiver coverage. Google, Microsoft, Yahoo do not send forensic reports. Operators who scope their rollout plan around forensic-report availability will be permanently disappointed; aggregate reports must be the primary signal.
• Pointing ruf= at a high-traffic shared mailbox. Forensic-report bursts during a spoofing campaign can flood a shared inbox. Use a dedicated mailbox with automated ingestion.
• Using the same mailbox for rua= and ruf=. Aggregate reports are bulky binary attachments; forensic reports are smaller text MIME messages. Routing both to one mailbox makes triage harder. Keep them separate.
• Treating ruf= as a real-time alert stream. Even receivers that emit forensic reports often batch them with several minutes' delay. They are not a substitute for inline phishing detection.
• Forgetting cross-domain authorisation. If the ruf= mailbox is at a third-party aggregator, the protected domain must publish the _report._dmarc authorisation record. Without it, well-behaved receivers silently drop the report.
• Mixing fo= values without understanding the combinatorics. fo=d:s emits reports for ALL DKIM failures plus ALL SPF failures, which can be high volume on a domain with many legitimate-but-unaligned senders. Start with fo=1.
• Storing forensic-report bodies in third-party observability platforms. Forensic reports contain recipient PII. Logging the body to a SaaS observability vendor without DPA coverage exports the PII outside your data boundary.

11. Forensic-report troubleshooting

My ruf= mailbox is empty. Why?

Most likely the major receivers your mail interacts with do not send forensic reports — Google, Microsoft, Yahoo never do. Verify by checking which receivers your aggregate reports come from (report_metadata/org_name in the XML) and consulting Section 6 above. A trickle from smaller corporate gateways is the realistic expectation.

I see a stale daemon-rejection bounce loop from the ruf= mailbox. Why?

The ruf= mailbox is on the same domain that DMARC protects and the mailbox itself fails DMARC — receivers reject reports they cannot deliver, creating a feedback loop. Host the ruf= mailbox at a different domain or ensure the mailbox-hosting subdomain has its own DMARC pass.

The forensic-report email arrives but the AFRF parser fails to extract fields.

Verify the report is actually Content-Type: multipart/report; report-type=feedback-report. Some receivers emit a text/plain human-readable report only, with no message/feedback-report machine-readable part — these are not RFC-compliant AFRF and the parser cannot extract structured fields. Save the .eml and inspect manually.

I receive forensic reports from a receiver I do not recognise.

Cross-reference the From: domain of the report email against the receiver's published DMARC documentation. A report from a domain you cannot authenticate may itself be a phishing lure — do not click links in the report and do not blindly ingest body content. The DMARC Analyzer ingestion pipeline runs XML-external-entity protection on all parsed reports.

The forensic report's Authentication-Results: header disagrees with the aggregate-report auth_results.

Aggregate reports summarise the evaluation OUTCOME the receiver applied during disposition; forensic reports include the RAW Authentication-Results: header at receive time. The two can differ slightly when the receiver's ARC-validation step or DMARC override rules apply between receive-time and disposition. The forensic-report header is the canonical authentication answer at receive time.

I want to receive forensic reports but only for true spoofing, not for misaligned legitimate senders.

Publish fo=0 rather than fo=1. The default fo=0 fires only when both SPF and DKIM fail to produce an aligned pass — i.e. real DMARC failures. Misaligned legitimate senders typically produce a partial-fail (one mechanism aligns, the other doesn't) which fo=0 does not trigger on.

12. FAQ

What is a DMARC forensic report?

A DMARC forensic report (also called a RUF report after the ruf= tag, or a failure report) is a per-message report a receiver sends back to the domain owner whenever a specific message fails DMARC evaluation. Unlike aggregate (RUA) reports — which summarise message volumes statistically once per day — forensic reports are emitted per failing message and contain the failing message's headers, From: address, subject, and sometimes the body. The format is specified in RFC 7489 §7.3 with the underlying envelope defined in RFC 6591 (Authentication Failure Reporting Format, AFRF). Forensic reports are the highest-fidelity signal a domain owner can request, but most major receivers stopped sending them because of the privacy implications.

What is the difference between RUA and RUF reports?

RUA reports (aggregate, RFC 7489 §7.2) are daily statistical XML summaries describing message volumes and authentication outcomes per sending IP. They contain no message content. RUF reports (forensic, RFC 7489 §7.3) are per-message MIME reports describing individual DMARC-failing messages, including the failing message's headers and sometimes the body. RUA is universally supported by major receivers (Google, Microsoft, Yahoo); RUF is patchy at best because the per-message payload includes user-identifying information (sender + recipient addresses, subject lines, and sometimes message body) that conflicts with GDPR § 5 / CCPA data-minimisation principles. The aggregate-report stream is the everyday rollout signal; the forensic-report stream is the rare diagnostic deep-dive.

Do major receivers send DMARC forensic reports?

No. Google has never sent DMARC forensic (RUF) reports. Microsoft / Outlook does not send RUF. Yahoo stopped sending forensic reports years ago. Comcast, AOL, Mail.ru, and the major consumer mailbox providers do not send RUF. The receivers that still occasionally send forensic reports are smaller corporate gateways and a handful of niche ISPs — together they cover a small percentage of consumer mail volume. Operators who publish ruf= should expect a trickle of reports, not the firehose RUA delivers. If your priority is rollout monitoring, focus on aggregate reports; if your priority is per-message forensics, publish ruf= and accept that coverage is partial.

What does the fo= tag in the DMARC record do?

The fo= tag is the failure-reporting-options tag defined in RFC 7489 §6.6.4. It tells receivers WHEN to emit forensic (RUF) reports. Values are: fo=0 (default) — emit a forensic report only when BOTH SPF and DKIM fail to produce an aligned pass; fo=1 — emit a forensic report when EITHER SPF or DKIM fails to produce an aligned pass (the most useful value for active rollouts because it surfaces partial-fail edge cases); fo=d — emit a forensic report on every DKIM failure regardless of alignment; fo=s — emit a forensic report on every SPF failure regardless of alignment. Multiple values can be combined with a colon, e.g. fo=d:s. fo=1 is the recommended starting value for operators who choose to receive forensic reports.

What is the AFRF format and which RFCs define it?

AFRF stands for Authentication Failure Reporting Format. It is the MIME-based envelope that wraps a DMARC forensic report. The envelope structure is defined in RFC 6591 (extending the older RFC 5965 Abuse Reporting Format). An AFRF report is a multipart/report MIME message with report-type=feedback-report containing three parts: (1) a human-readable text/plain description of the failure, (2) a machine-readable message/feedback-report part with key-value fields like Feedback-Type, Reported-Domain, Auth-Failure, Source-IP, Original-Mail-From, DKIM-Domain, DKIM-Selector, and (3) a message/rfc822 (or message/rfc822-headers) part containing the original failing message or its headers. DMARC Analyzer's ingestion pipeline at includes/ForensicReportParser.php parses all three parts and persists the structured fields to the dmarc_forensic_reports table.

Are DMARC forensic reports a GDPR risk?

Yes — forensic reports include personal data (sender address, recipient address, subject line, sometimes message body) belonging to email recipients who never consented to having their messages forwarded to the report destination. Under GDPR Article 5 (data minimisation) and Article 6 (lawful basis), processing those reports outside the receiver's own infrastructure requires a documented purpose, a lawful basis, and recipient transparency. Most major European receivers stopped sending forensic reports for exactly this reason. Operators who do receive RUF should: (a) restrict mailbox access to the security team only, (b) document retention limits, (c) avoid logging report contents in third-party systems without explicit DPA coverage, and (d) prefer aggregate reports for non-forensic investigations. The fo=1 value is the most defensible because it scopes reports to actual authentication failures rather than every email a receiver processed.

How does DMARC Analyzer ingest forensic reports?

The ingestion pipeline at includes/ForensicReportParser.php (RFC 6591 ARF envelope) auto-detects three input formats: raw .eml / .txt MIME messages (multipart/report with report-type=feedback-report), plain feedback-report bodies (key-value pairs), and XML forensic reports (the arf+xml variant some providers use). The parser persists structured fields — Feedback-Type, Reported-Domain, Auth-Failure, Source-IP, Original-Mail-From, Reported-URI, DKIM-Domain, DKIM-Selector, Identity-Alignment, Delivery-Result — to the dmarc_forensic_reports table, deduplicates by report-id, and surfaces per-report drill-downs in the dashboard. Operators can upload .eml files directly via the upload form on index.php or auto-ingest from an IMAP / Microsoft Graph mailbox listed in their profile settings.

13. Related guides

• Business Email Compromise (BEC) — the FINANCIAL-FRAUD-INCIDENT-RESPONSE- PER-MESSAGE-EVIDENCE-FEED companion to THIS DMARC forensic-report (RUF / failure-report) reference. Where THIS page documents the RFC 6591 ARF / RFC 5965 AFRF MIME envelope (multipart/report content-type, per-failure message/feedback-report section, the Auth-Failure / Authentication-Results / Original-Mail-From / Received-SPF / DKIM- Signature evidence rows, the receiver-side per-failure-event emission cadence, the publisher-side ruf=mailto: configuration, the fo=0/1/d/s filter-tag emission-control grammar, the GDPR Art 28 legal-basis processor-relationship analysis for cross-tenant RUF transport), the business_email_compromise spoke documents the FINANCIAL-FRAUD-INCIDENT-RESPONSE PATHWAY whose first-stage forensic-evidence feed is the per-message ARF / AFRF MIME envelope THIS page documents. Four structurally-distinct RUF-as-BEC-incident-response-evidence operational classes the spoke covers that THIS forensic-reports reference intentionally elides: (i) per-BEC- variant the canonical RUF-AFRF evidence-row signature — each of the six BEC variants (CEO fraud, invoice fraud, payroll diversion, gift-card scam, M&A fraud, VEC) produces a structurally-distinct AFRF evidence-row signature on the forensic envelope (direct-domain From- header forgery surfaces in the Original-Mail-From AFRF row with a body-content-fingerprint flagging wire-transfer-request keywords; lookalike- domain attacks surface with the lookalike From: domain in the Reported-Domain row and the publisher's domain in the Original-Mail-From row; hijacked-legitimate-sender attacks surface with the publisher's own domain in BOTH rows AND a Source-IP AFRF row outside the publisher's expected source-IP set); (ii) FBI Financial Fraud Kill Chain forensic-evidence-preservation prerequisite for AFRF data — the FBI IC3 incident-response playbook documented on the BEC spoke REQUIRES the operator capture the raw RUF / AFRF MIME envelope BEFORE any remediation step (lest the remediation alter the publish state and destroy the per-message forensic evidence the kill-chain depends on); (iii) RUF / AFRF stream as BEC-defense-in-depth REACTIVE- DETECTION layer — the BEC spoke documents a SIX-LAYER PROACTIVE defense stack whose REACTIVE-DETECTION layer depends on the per-message forensic- evidence feed THIS page documents; without a published ruf=mailto: mailbox the per-message attacker-attempt evidence is invisible to the operator's incident- response team; (iv) RUF per-message-attacker-evidence-stream as BEC-cost-statistic-supporting telemetry for executive-sponsorship — the BEC spoke catalogues BEC vs ransomware cost statistics that justify the executive sponsorship for the BEC defense program; the per-message evidence stream THIS page documents is the operational telemetry that QUANTIFIES the per-tenant BEC attack volume the cost statistics contextualise at industry scale. Required reading once an operator deploying RUF / AFRF ingestion per THIS page's publisher-side configuration needs to cross-reference the per-BEC- variant attacker-technique signature catalogue for incident-response classification.
• DMARC aggregate (RUA) reports — the daily statistical sibling of forensic reports. The everyday diagnostic stream every rollout depends on. Most operators should focus here first.
• DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery — the end-to-end transport-and-ingestion path that turns a published ruf= mailbox into the per-failure ARF document this page documents. Forensic reports share the same physical transport with aggregate reports: receiver-side report-generator → DNS resolution of the ruf= URI → MIME-attached send via SMTP → operator-side inbound mailbox / webhook → ARF MIME-part extraction → parser ingestion. Read the pipeline page when forensic reports stop arriving (typical causes: the receiver opted out of forensic reporting because of GDPR / CCPA concerns, the fo= tag is misconfigured so failures the receiver considers reportable are silently dropped, the inbound mail-server's TLS / DKIM verification is rejecting receiver-generated reports, or the ARF parser rejected a non-conformant forensic document).
• DMARC record tags explained — every tag in the DMARC DNS record including rua=, ruf=, fo=, ri=.
• DMARC policy rollout — the operational migration from p=none to p=reject. Forensic reports can supplement (but not replace) aggregate reports during the rollout.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the FORENSIC-EVIDENCE-STREAM-FOR- POLICY-MODE-DECISION companion to this DMARC forensic-reports reference. Where THIS page documents the per-message RUF (AFRF) failure-report payload (the full original headers, the SPF and DKIM authentication results, the identifier-alignment evaluation, the delivery-result disposition) the receiver emits when a publisher's mail fails DMARC and the publisher has published a ruf= mailto-URI, the DMARC policy-modes spoke documents the publisher-side p=none / p=quarantine / p=reject tag whose enforcement decision is INFORMED by the per-message forensic-report evidence stream — an operationally-load-bearing decision dimension structurally DOWNSTREAM of every forensic-report observation this page documents because (i) the forensic-report stream is the PER-MESSAGE EVIDENCE CHANNEL the publisher consults when deciding whether the forensic-report failure-row signatures justify advancing from p=quarantine to p=reject (low forensic- failure-row count + all rows attributable to known false-positive sources = operationally-safe to advance), (ii) the forensic-report stream is the PER-MESSAGE EVIDENCE CHANNEL the publisher consults when deciding whether to ROLLBACK from p=reject to p=quarantine after a false-positive incident (sustained forensic-report rows from a known-legitimate sender requires immediate rollback), (iii) the forensic-report stream is the PER-MESSAGE EVIDENCE CHANNEL the publisher consults to populate the post-mortem incident-response artefacts for any p=reject deployment outage. Read the DMARC policy-modes spoke when interpreting the forensic- report stream this page documents into the publisher-side policy-mode decision — particularly when the publisher is evaluating whether the steady-state forensic-report-failure rate justifies the next policy-mode ratchet, or when assembling the operational case for a temporary rollback to a less-restrictive policy mode during a forwarder-induced forensic-row spike.
• Reverse DNS (PTR) and FCrDNS explained — the AFRF-SOURCE-IP-EVIDENCE-ROW- AS-PER-IP-RDNS-AND-FCrDNS-ATTRIBUTION- INPUT companion to this RFC 6591 / RFC 5965 forensic-failure-report reference. Where THIS page documents the per-message AFRF MIME envelope — including the Source-IP evidence row that captures the receiver-observed envelope-sending IP for every per-failure sample — the reverse-DNS / PTR / FCrDNS spoke documents the per-source-IP rDNS publication discipline whose in-addr.arpa / ip6.arpa PTR record AND the corresponding forward-confirmed forward-A / AAAA back-lookup is the canonical per-IP identity-attribution surface the operator runs on each Source-IP AFRF row at FOUR per-AFRF-Source-IP-evidence-row-to-PTR-FCrDNS- attribution dimensions: (i) per-AFRF- Source-IP-row rDNS lookup as receiver-side per-IP cohort-attribution input — when the per-message AFRF evidence stream surfaces a Source-IP outside the publisher's expected source-IP set, the operator's first triage step is to resolve the IP's PTR record (and the corresponding FCrDNS round-trip) to classify the IP into a sender-cohort (legitimate-but-unenrolled third-party-sender vs forwarder vs attacker- controlled origin); the rDNS spoke documents the per-resolver PTR-RR resolution semantics and the FCrDNS forward-A-lookup-must-match- original-IP validation contract whose outcome seeds this attribution; (ii) per-IP FCrDNS-pass-or-fail as legitimacy-signal ORTHOGONAL to per-message DMARC verdict — Gmail, Yahoo, Microsoft and other major mailbox-providers run per-source-IP FCrDNS validation as a per-connection legitimacy signal SEPARATE from the per-message DMARC verdict THIS page's AFRF stream attests; an FCrDNS-pass IP whose AFRF rows show DMARC=fail suggests a misconfigured legitimate sender, while an FCrDNS-fail IP with the same AFRF rows suggests an attacker-controlled or unconfigured origin — the rDNS spoke catalogues the per-receiver FCrDNS-validation discipline the operator uses to disambiguate these per-AFRF-row root-cause classes; (iii) shared-IP-pool per-tenant rDNS contamination as AFRF cross-tenant attribution ambiguity source — when the per-tenant outbound mail egresses via a shared-IP pool (cPanel-shared-hosting, marketing-ESP, transactional-ESP), the Source-IP AFRF row's PTR record may resolve to a hosting-vendor-canonical hostname (e.g. mail-out-NNN.<vendor>.com) identifying the SHARED pool rather than the per-tenant publisher — the rDNS spoke documents the per-tenant rDNS-attribution boundary the operator triages when an AFRF evidence-row Source-IP resolves to a vendor- canonical hostname whose tenant-of-origin must be inferred from the AFRF row's Original-Mail-From / DKIM-d / Authentication- Results combination; (iv) per-AFRF- Source-IP rDNS-publication discipline as publisher-side legitimacy-signal authoring prerequisite — operators ingesting AFRF streams for their own egress IPs use the rDNS spoke's per-IP PTR + FCrDNS publication checklist to ensure every legitimate egress IP carries forward-confirmable rDNS, removing the FCrDNS-fail false-positive class from the per-IP attribution analysis the AFRF stream downstream consumes. Read the reverse-DNS / PTR / FCrDNS spoke when triaging an AFRF evidence-row Source-IP whose attribution to a legitimate sender, a forwarder, or an attacker-controlled origin depends on the per-IP rDNS publication state the AFRF row elides but the per-receiver per-connection legitimacy evaluation depends on.
• DMARC alignment explained — identifier alignment (the SPF/DKIM-domain-matches-From rule). The Identity-Alignment field in every forensic report reports this evaluation.
• DMARC troubleshooting — the SYMPTOM-DRIVEN-DMARC-FAIL-DIAGNOSTIC- LADDER-CONSUMER-OF-PER-MESSAGE-RUF-FORENSIC- EVIDENCE companion to THIS DMARC forensic- report reference. Where THIS page documents the RFC 6591 / RFC 5965 forensic-failure- report MIME envelope (the multipart/report content-type carrying per-failure Auth-Failure + Authentication-Results + Original-Mail-From + Received-SPF + DKIM- Signature + Identity-Alignment evidence rows, the publisher-side ruf=mailto: + fo=0/1/d/s emission-control grammar, the receiver-side per-failure-event emission cadence), the DMARC-troubleshooting spoke is the STRUCTURAL DOWNSTREAM CONSUMER of every per-message forensic-evidence row this page documents — the symptom-driven diagnostic ladder operators apply when triaging the per-failure RUF evidence stream to attribute each row to one of the 7 canonical DMARC-failure patterns. Four per-forensic-payload-diagnostic-coupling dimensions: (i) PER-FAILURE-AUTH-FAILURE- FIELD-AS-PATTERN-SELECTOR (the Auth-Failure field's dkim / spf / dmarc / bodyhash / revoked-key / signature / syntax code-set is the canonical pattern-selector input the symptom-driven diagnostic ladder consumes — each code-value branches the operator to a different remediation playbook in the DMARC-troubleshooting spoke), (ii) PER- MESSAGE-IDENTITY-ALIGNMENT-FIELD-AS- ALIGNMENT-FAILURE-ROOT-CAUSE-ATTRIBUTION- INPUT (the Identity-Alignment field reports the per-message alignment evaluation verdict THIS page documents; the DMARC- troubleshooting spoke's alignment-failure diagnostic branch consumes the field to attribute alignment-failure root cause between strict-vs-relaxed mode misconfiguration, organisational-domain Public-Suffix-List drift, DKIM d=-vs-5322.From boundary tampering, and SPF 5321.From-vs-5322.From envelope-vs-header divergence), (iii) PER-FAILURE-AUTHENTICATION-RESULTS-FIELD- AS-AUTH-RESULTS-COMPONENT-INTERPRETATION- INPUT (the per-failure Authentication- Results field RFC 8601 §2.7 canonical- decoding the troubleshooting spoke documents at the per-component spf= / dkim= / dmarc= token-decode step — the forensic evidence row's verbatim citation of the receiver-side verdict provides the ground-truth input the diagnostic ladder consumes), (iv) PER-FAILURE-ORIGINAL-MAIL- FROM-AND-RECEIVED-SPF-FIELD-AS- FORWARDING-ROOT-CAUSE-ATTRIBUTION-INPUT (the Original-Mail-From + Received-SPF evidence rows verbatim citation of the per-hop envelope chain are the canonical forwarding-vs-spoofing root-cause attribution input the DMARC-troubleshooting spoke's Pattern-4 forwarding-and-mailing- list diagnostic branch consumes — per-failure-row attribution distinguishes legitimate-forwarder-induced SPF-break from attacker-side spoofing). Critical when operators investigating a per-failure RUF forensic payload need to attribute the evidence-row to one of the 7 canonical DMARC-failure patterns and traverse the symptom-driven remediation playbook — the DMARC-troubleshooting spoke is the canonical downstream diagnostic reference for every forensic-evidence row this page documents.
• DKIM alignment with DMARC — the RUF-FORENSIC-PAYLOAD-IDENTITY- ALIGNMENT-FIELD-AS-PER-MESSAGE-DKIM-d- TAG-VS-RFC-5322-FROM-ORGANISATIONAL- DOMAIN-EVALUATION-VERBATIM-CITATION- DECODE-COMPANION reference. Where THIS page documents the per-message ruf forensic-payload byte-anatomy (the RFC 6591 + AFRF/ARF envelope grammar, the Authentication-Results + DKIM-Signature + verbatim message-source evidence fields the forensic verifier serialises into the per-message failure report sent to the publisher's ruf=mailto: mailbox), the DKIM-alignment-with-DMARC spoke documents the BYTE-LEVEL ALIGNMENT-EVALUATION DISCIPLINE the forensic verifier APPLIES at the per-message-DKIM-verdict-attribution step that produces the Identity-Alignment field's per-message verbatim citation: (i) the per-message comparison between the forensic-payload-cited DKIM-Signature header's d=-tag signing- domain and the RFC 5322 From: header's organisational-domain — the comparison whose outcome populates the forensic-payload Identity- Alignment field with aligned=true versus aligned=false; (ii) the strict-vs-relaxed alignment mode (the publisher's adkim=s / adkim=r DMARC-record tag- value) that the forensic verifier applies at evaluation time; (iii) the canonical forensic-row class — per- message dkim=pass with aligned=false — where the per-message DKIM signature is cryptographically valid (a per-message dkim=pass protocol verdict) but the signing-domain (d=sendgrid.net, d=mandrillapp.com, d=amazonses.com) fails organisational-domain alignment with the author-domain, producing the forensic-row's aligned=false evidence verbatim; and (iv) the per-forensic-row triage decision class — every per- message ruf forensic payload with dkim=aligned=false evidence becomes a per-author-domain Phase 2 backlog entry to delegate a CNAME-based signing-domain to the third-party ESP (the canonical alignment remediation pattern). Read this WITH the forensic- reports page when the operator's per-message ruf payload's Identity-Alignment field shows dkim=aligned=false: the forensic-reports page documents the per-message PAYLOAD WIRE-FORMAT, the DKIM-alignment-with-DMARC spoke documents the per-message ALIGNMENT- EVALUATION DISCIPLINE the Identity-Alignment field's verbatim verdict surfaces.
• DMARC explained — the central DMARC primer covering the broader DMARC ecosystem.
• SPF explained — Sender Policy Framework (RFC 7208). The Auth-Failure: spf value in forensic reports identifies SPF-specific failures.
• Why SPF alone is insufficient — the PER-AFRF-ROW-spf=pass-WITH- dkim=fail-OR-PER-AFRF-ROW-spf=pass-WITH- dmarc=fail-AS-PER-MESSAGE-FORENSIC- EVIDENCE-STREAM companion to this AFRF / RUF per-message forensic-report channel reference. Where THIS page documents the RFC 6591 AFRF per-message forensic-report envelope-and-decode catalogue (the per- AFRF-row Auth-Failure: spf / dkim / dmarc identifier-class, the per-AFRF-row per-source-IP attribution, the per-AFRF- row per-Reported-Domain authentication- result decode, the per-AFRF-row per- Source-IP-RFC822-rebroadcast forensic- replay reconstruction), the why-SPF- alone-is-insufficient spoke is the per- publisher-per-receiver defense-in-depth motivation reference whose per-attack- class arguments are DIRECTLY EVIDENCED by per-AFRF-row evidence at FOUR per- AFRF-evidence-class-vs-SPF-alone-gap rebuttal-evidence dimensions: (i) per-AFRF-row spf=pass-WITH-dkim= fail evidence as load-bearing forensic- proof for per-publisher operator commitment to per-source-IP SPF-alone publication discipline ships per- publisher per-receiver per-message DKIM- side defense-gap — per-AFRF-row spf=pass-with-dkim=fail evidence catches per-publisher per-receiver per-message legitimate-author-domain spoofing under per-attacker per-source-IP-from- legitimate-publisher SPF authorization; (ii) per-AFRF-row spf=pass-WITH- header-From-spoofed-or-tampered evidence as load-bearing forensic-proof for per-source-IP SPF-aligned-pass-cannot- defend-header-From gap — per- AFRF-row per-source-IP authentication- result spf=pass + per-message-embedded Reported-Domain ≠ per-publisher- organisational-domain evidence catches per-attacker per-message header-From- spoofing under per-source-IP-from- legitimate-publisher SPF authorization; (iii) per-AFRF-row spf=pass- WITH-per-forwarder-modified-body evidence as load-bearing forensic-proof for SPF-breaks-under-forwarding RFC 7208 §10.4 gap — per-AFRF-row per- Source-IP-from-forwarder spf=pass-on- SRS-rewritten-envelope-MAIL-FROM evidence catches per-publisher per-receiver per- forwarder-hop per-message body-modified- in-transit attacks that per-source-IP SPF-alone authorization cannot detect without per-publisher per-message DKIM- side cryptographic-trust-anchor verification gates; (iv) per- AFRF-row per-source-IP-from-compromised- authorized-sender evidence as load- bearing forensic-proof for per-source-IP SPF-cannot-detect-compromised-legitimate- sender gap — per-AFRF-row per- Source-IP-from-legitimate-SaaS-sender spf=pass-but-per-message-content-malicious evidence catches per-publisher per- receiver per-message compromised-account attacks that per-source-IP SPF-alone authorization on per-SaaS-sender published-as-legitimate cannot detect without per-publisher per-attacker- tampered-message DKIM-side cryptographic- trust-anchor verification gates.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). The DKIM-Domain + DKIM-Selector fields in forensic reports identify which DKIM signature attempt failed.
• DKIM key rotation playbook — the DKIM-KEY-ROTATION-WINDOW-AS- PER-MESSAGE-FORENSIC-EVIDENCE-PRODUCER companion to this DMARC forensic (RUF / AFRF) per-message-failure evidence-stream reference. Where THIS page documents the per-message AFRF payload format (the verbatim DKIM-Signature header citation, the DKIM-Domain + DKIM-Selector attribution fields, the Auth-Failure: bodyhash / signature / revoked-key root-cause rows the receiver's evaluator emits per RFC 6591), the key-rotation spoke documents the OPERATIONAL CAUSE the forensic stream attributes — the dual-selector zero-downtime rotation procedure whose seven enumerated failure modes (premature old-key retirement, late new-key publication, stale resolver-cache observation, RFC 8767 serve-stale re-emergence, multi-signer key-overlap drift, third-party-vendor rotation gap, operator-side DNS-TTL misestimate) each surface in the per-message AFRF stream as a distinct DKIM-Selector-attributed per-receiver per-day evidence cohort the operator's incident-response team triages from the publisher's ruf=mailto: mailbox. The forensic-report channel this page documents is the EVIDENCE layer; the key-rotation spoke is the PREVENTION layer whose disciplined dual-selector overlap-window cadence eliminates the rotation-attributable AFRF cohort upstream — and whose seven failure modes provide the canonical attribution vocabulary the forensic-sample analyst consumes when an unexpected rotation-induced dkim=fail spike surfaces in the per-message evidence stream.
• DKIM-Signature header explained — the RUF-FORENSIC-REPORT-PER-MESSAGE- DKIM-SIGNATURE-HEADER-EVIDENCE-VERBATIM- CITATION-DECODE companion to this RFC 6591 DMARC forensic-report consumer-side reference. Where THIS page documents the RFC 6591 AFRF per-message failure-payload schema (the Auth-Failure: / DKIM-Domain: / DKIM-Selector: / DKIM-Identity: / DKIM-Canonicalization: AFRF evidence rows AND the verbatim DKIM-Signature MIME header carried inside the message/rfc822- headers third-part of the forensic-report multipart envelope), the DKIM-Signature-explained spoke is the BYTE-BY-BYTE TAG DECODE reference for the verbatim signature header the operator reads off the AFRF payload during per-message- failure triage. Four structurally- distinct RUF-AFRF-EVIDENCE-VS-DKIM- SIGNATURE-HEADER operational classes the spoke covers that THIS forensic- reports reference intentionally elides: (i) verbatim signature-header tag-by-tag decode for bodyhash-mismatch attribution — when the AFRF evidence row carries Auth- Failure: bodyhash, the operator reads the cited DKIM-Signature header's c= tag (the canonicalization pair the signer used) AND the bh= tag (the body-hash the signer committed to) AND the a= tag (the hash algorithm) to determine WHICH bytewise-modification class breached the body-hash contract — the spoke documents the byte-format of each tag so the operator can decode the verbatim header even when the receiver-side DKIM- Canonicalization AFRF row is truncated or missing; (ii) signature-syntax-permerror attribution via tag-grammar conformance check — when the AFRF evidence row carries Auth-Failure: signature or dkim= permerror, the operator reads the cited DKIM-Signature header against the RFC 6376 §3.5 tag-grammar the spoke documents to identify which tag violated the grammar (missing required v= / a= / d= / s= / h= / bh= / b= tag, malformed tag-value-list delimiter, base64-decode-failure on bh= or b=, illegal characters in d= or s=, signed-header list h= omitting the RFC 6376 §5.4 mandatory From header) — without the byte-grammar reference the spoke documents, the operator cannot distinguish a sender-side syntax bug from a receiver-side parser bug; (iii) weak-key + signature- expiration + signed-header-tampering evidence-row attribution — the AFRF evidence row's verbatim signature header carries the a= algorithm tag (whose rsa-sha1 value indicates RFC 8301 §3.2 receiver-side weak-algorithm rejection), the x= expiration tag (whose receiver-side wallclock comparison materialises the signature-expiration failure class), and the h= signed-header list (whose post-signing header modification by an upstream MTA materialises the signed-header- tampering failure class) — the spoke documents the per-tag operator-side discipline that distinguishes legitimate-failure from misconfiguration each class retroactively implicates; (iv) two-hash-design failure- domain isolation — the spoke's TWO-HASH-DESIGN section documents how the body-hash check (bh= recomputation over canonicalised body) is INDEPENDENT of the signed- header-set signature verification (b= over canonicalised header set including the DKIM-Signature header itself with b= temporarily empty), which determines WHICH of the two cryptographic verifications failed for the per-message-failure forensic- report row the operator triages — a bodyhash-mismatch evidence row implicates upstream-MTA body modification (footer-insertion, whitespace-rewrap, content-transfer- encoding change); a signature- verification-mismatch evidence row WITHOUT a bodyhash mismatch implicates header-set tampering (Subject rewriting, Return-Path injection, Received-chain footer insertion into the signed header list). Required reading once an operator deploying RUF / AFRF ingestion per THIS page's publisher-side configuration needs to decode the verbatim DKIM-Signature header carried in each per-message- failure payload during incident triage.
• DKIM cryptography basics — the RUF-FORENSIC-REPORT-VERBATIM-DKIM- SIGNATURE-PAYLOAD-RESOLVES-TO-CRYPTOGRAPHIC- PRIMITIVE-MATHEMATICAL-CONSTRUCTION companion to this RFC 6591 DMARC forensic-report consumer-side reference. Where THIS page documents the AFRF per-message-failure payload schema and its verbatim DKIM- Signature header citation (the Auth-Failure: + DKIM-Domain: + DKIM-Selector: evidence rows AND the verbatim DKIM-Signature MIME header carried inside the third part of the multipart/report envelope), the cryptography-basics spoke is the BYTE- ANATOMY REFERENCE for the cryptographic- primitive mathematical construction the signer applied and the verifier reversed to produce the per-message verification verdict the AFRF payload reports. The four-axis AFRF-VERBATIM-DKIM-SIGNATURE- PAYLOAD-VS-CRYPTOGRAPHIC-PRIMITIVE mapping exposes the structurally-distinct cryptographic-evidence-to-mathematical- construction resolutions: (i) a=rsa-sha256-tag evidence → RSA-2048 modulus + public-exponent verification mechanics — the AFRF payload's verbatim signature carries the a=rsa-sha256 algorithm tag whose verifier-side mathematical reversal requires the per-domain RSA-2048 public key (fetched from <selector>._domainkey.<d=> TXT-record's p=-tag SubjectPublicKeyInfo blob) — the cryptography-basics spoke documents the RSA-2048 2048-bit-modulus + 65537- public-exponent byte-anatomy the verifier applies during the signature-verification operation that produced the dkim=fail verdict the AFRF evidence row reports, the per-tag-input SHA-256 hash bytes the modular-exponentiation consumes, and the structural reason a weak-modulus (1024-bit DKIM key still common in 2010s-era publications) yields a cryptographically-suspect but protocol-valid signature whose RFC 8301 §3.1.1-recommended ≥2048-bit-modulus threshold the modern verifier may now independently fail under policy-class disposition; (ii) a=rsa-sha1-tag evidence → RFC 8301 §3.2 weak- algorithm-rejection rationale — when the AFRF verbatim signature carries a=rsa-sha1, the receiver- side Auth-Failure: signature evidence row attributes failure to RFC 8301 §3.2 weak-algorithm-rejection (SHA-1 deprecated for DKIM in 2018 after the 2017 SHAttered collision attack) — the cryptography-basics spoke documents the FIPS 180-4 §6 SHA-1-vs-SHA-256 hash-construction differences, the cryptographic collision-resistance rationale for the 2018 deprecation, and the operator-side remediation pattern (rotate to a=rsa-sha256 signing immediately on any signer where the AFRF evidence-row stream cites a=rsa-sha1); (iii) bh=-tag-mismatch + Auth-Failure: bodyhash evidence → FIPS 180-4 §6.2 SHA-256 body-hash construction — when the AFRF payload carries Auth-Failure: bodyhash, the verifier's independently-recomputed body-hash bytes did not match the bh=-tag value the signer committed to; the cryptography-basics spoke documents the FIPS 180-4 §6.2 SHA- 256 256-bit-output hash-construction the verifier applies to the canonicalised body bytes, the mathematical reason a single-byte body modification produces an avalanche of statistically-independent bits in the output (50% expected bit-flip per FIPS 180-4 strict-avalanche- criterion), and the canonical forensic-triage workflow whereby the operator captures the verbatim body bytes downstream of the AFRF-payload- sample at the verifier's MTA and re- applies the SHA-256 construction to identify which mutation class produced the body-hash divergence; (iv) k=ed25519 evidence + post-quantum-cryptography migration path → RFC 8463 EdDSA signature- algorithm verification mechanics — when the AFRF payload cites a per-selector signature whose <selector>._domainkey.<d=> TXT-record publishes k=ed25519 per RFC 8463, the cryptography-basics spoke documents the Edwards-curve EdDSA signature-algorithm + Curve25519 elliptic-curve parameter set the verifier applies, the 32-byte-vs-2048-byte key- size advantage relevant for high-volume signer publication zones with limited TXT-record byte-budget, and the operator- side dual-algorithm-publication pattern whereby modern publishers ship parallel k=rsa + k=ed25519 selectors during algorithm-migration windows. Read the cryptography-basics spoke when the AFRF payload's verbatim DKIM-Signature header citation needs to resolve to the mathematical-construction layer the verifier applied — the spoke is the canonical reference for the RSA- 2048-vs-Ed25519 signature-algorithm choice, the SHA-256-vs-SHA-1 hash- deprecation timeline, and the FIPS 180-4 §6.2 SHA-256 body-hash byte-construction whose verification produced the per-message dkim=fail verdict the AFRF evidence rows on this forensic-reports page report.
• DKIM canonicalization — the RUF-FORENSIC-REPORT-PER-MESSAGE- DKIM-CANONICALIZATION-FAILURE-ATTRIBUTION companion to this RFC 6591 DMARC forensic- report consumer-side reference. Where THIS page documents the RFC 6591 AFRF per-message failure-payload schema (the Auth-Failure: / DKIM-Domain: / DKIM-Selector: / DKIM-Identity: / DKIM-Canonicalization: fields and their operator-side triage workflow), the DKIM- canonicalization spoke is the UPSTREAM-ALGORITHM-CHOICE companion documenting the FOUR canonicalization- combinations the sender chose at signing time (c=simple/simple, c=simple/relaxed, c=relaxed/simple, c=relaxed/relaxed) and per-pair survival profile under each modification-class the forensic- report's Auth-Failure: bodyhash evidence row retroactively attributes: (i) c=simple/simple bodyhash-mismatch evidence in a forensic report indicates ANY byte-level body modification post-signing (a single whitespace change, a mailing-list footer prepended, an SMTP-server line-ending normalisation — whichever class of byte-mutation occurred is bounded only by "any byte differs"), so the operator's diagnostic next step is to inspect the forensic report's Received: chain to identify which hop produced the modification; (ii) c=relaxed/relaxed bodyhash-mismatch evidence in a forensic report indicates a more substantive byte-mutation (the relaxed body canonicalisation already normalises trailing whitespace and empty trailing lines), so the operator's diagnostic next step is to focus on content-changes rather than whitespace-noise — e.g. a security-gateway inserting an HTML disclaimer, a mailing-list manager rewriting the body, a forwarder modifying URLs; (iii) c=*/simple header-hash-mismatch evidence in a forensic report indicates the signed-header list was modified (a header added/removed/re-ordered in the h= tag), so the operator's diagnostic next step is to inspect which intermediary added a List-* header or a Reply-To rewrite; (iv) c=*/relaxed header-hash-mismatch evidence in a forensic report indicates more substantive header-content modification (the relaxed header canonicalisation already normalises case + whitespace + folded-header continuation), so the operator's diagnostic next step is to focus on actual header-value changes — a forwarder rewriting Subject:, a gateway adding X-Authentication- Results: before the signing. Read the DKIM- canonicalization spoke alongside this RFC 6591 forensic-report consumer-side pillar when the operator receives an Auth-Failure: bodyhash or Auth-Failure: signature row in a RUF payload and must attribute the failure to a specific upstream signing- algorithm-choice + downstream message-modification-event combination — the canonicalization spoke is the FIRST-PRINCIPLES algorithm- survival reference the operator's forensic-evidence triage workflow consumes.
• DKIM selectors explained — the FORENSIC-REPORT-PER-MESSAGE- SELECTOR-ATTRIBUTION companion to this DMARC forensic-report (RUF / AFRF) pillar. Where THIS page documents the DMARC RUF per-message failure-report ingestion (the RFC 6591 AFRF MIME-wrapped report-format, the DKIM-Domain + DKIM-Selector per-failure attribution fields, the Original-Mail-From + Source-IP + Auth-Failure + Authentication-Results diagnostic header set, the GDPR-sensitive per-message-payload exposure surface, and the receiver-side per-failure emission discipline gated on the publisher's ruf= + fo= + rf= tags), the DKIM-selectors spoke is the SELECTOR-IDENTITY-PUBLICATION-DISCIPLINE companion documenting the per-selector DNS-publication mechanics whose s=-tag identity the forensic report's DKIM-Selector field VERBATIM CITES to identify which specific DKIM key in the operator's per-vendor selector portfolio produced the per- message failure outcome. The four-axis FORENSIC-REPORT-VS-SELECTOR-IDENTITY comparison exposes the structurally- distinct PER-FAILURE-SELECTOR-DIAGNOSTIC roles: (i) a forensic report's DKIM-Selector: selector1 field maps DIRECTLY to the operator's Microsoft 365 default DKIM key at selector1._domainkey.<domain> per the M365 dual-selector convention the DKIM-selectors spoke catalogues — the forensic-report operator uses this attribution to triage M365-specific DKIM-failure modes (M365 selector rotation between selector1 and selector2, the CNAME-delegation-to-M365 misconfig, the <tenant>.onmicrosoft.com d-domain alignment gotcha) without manually inspecting RUA aggregate-report per-day pattern data; (ii) a forensic report's DKIM-Selector: s1 or DKIM-Selector: s2 field maps DIRECTLY to a SendGrid / Twilio-SendGrid third-party-ESP DKIM- signing key per the per-vendor selector catalogue the DKIM-selectors spoke documents — the forensic-report operator uses this attribution to identify the specific SendGrid sub-account whose DKIM-signing relationship is producing the failure mode; (iii) a forensic report's DKIM-Selector: google field maps DIRECTLY to the operator's Google Workspace single-selector DKIM key at google._domainkey.<domain> per the Workspace convention the spoke catalogues — the forensic-report operator uses this attribution to triage Workspace-specific DKIM-failure modes (the manual-rotation gappssmtp.com gotcha, the SMTP-Relay-Service unsigned outbound, the 2048-bit key split-string publication failure mode); (iv) a forensic report with EMPTY DKIM-Selector field indicates a dkim=none per-message outcome — no DKIM signature was present on the message at all — the selectors spoke documents the per-vendor selector-publication-absence diagnostic workflow operators run to identify which sending infrastructure is emitting unsigned messages. Read the DKIM-selectors spoke alongside this forensic-report pillar when ingesting a per-message RUF AFRF payload — the DKIM-Selector field's value is the load-bearing PRIMARY-KEY into the operator's per-vendor selector-publication catalogue documented in the spoke, identifying WHICH specific DKIM key in the operator's portfolio produced the per-message DKIM-failure outcome the forensic report carries.
• DKIM troubleshooting (symptom-driven debugging) — the RUF-AFRF-PER-MESSAGE-DKIM-FAIL- EVIDENCE-AS-DKIM-TROUBLESHOOTING-DRILL- DOWN companion documenting the symptom- driven diagnostic playbook the operator runs WHEN a per-message RUF AFRF payload arrives carrying a dkim=fail verdict whose root cause must be identified from the per-message evidence the forensic report captures. Where THIS page documents the per-message RFC 6591 AFRF envelope's evidence-row anatomy (the Auth-Failure field's six-value enumeration of bodyhash / dkim / dmarc / revoked-key / signature / spf class labels, the DKIM-Domain + DKIM-Selector + DKIM-Identity + DKIM- Canonicalization per-signature attribution fields, the original-message MIME part carrying the full DKIM-Signature header for verification-reproducibility), the DKIM-troubleshooting spoke documents the SYMPTOM-CLASSIFIED diagnostic ladder that maps each Auth-Failure class label onto a remediation playbook: (i) Auth-Failure: bodyhash → forwarder-body-modification diagnostic class — the DKIM-troubleshooting spoke walks the operator through the relaxed-vs-simple canonicalization choice + the l= body-length-limit configuration + the forwarder-class identification (mailing- list / SaaS-support-ticket-relay / vacation- forwarder / consumer-domain auto-forward) whose body-modification rewrote the signed byte range AFTER the publisher's signing boundary; the AFRF evidence stream surfaces the bodyhash class label and the DKIM-troubleshooting spoke routes to the forwarder-class identification + remediation path; (ii) Auth-Failure: dkim → signature-tag-invalidity diagnostic class — the DKIM-troubleshooting spoke catalogues the signature-tag corruption classes (corrupted b= base64 payload, missing h= header-list scope, unrecognised a= algorithm, invalid t= timestamp or x= expiry) whose AFRF capture surfaces them as evidence rows the operator must triage; (iii) Auth- Failure: signature → DNS-key- resolution diagnostic class — the DKIM-troubleshooting spoke walks the <selector>._domainkey.<d=domain> TXT-lookup NXDOMAIN diagnosis, the decoded p= public-key crypto- verification failure, the RFC 8301 RSA- key-too-small floor, the v=DKIM1 tag absence or misordering — all classes the AFRF evidence stream surfaces and the DKIM-troubleshooting spoke routes to the per-class remediation; (iv) Auth-Failure: revoked-key → key-rotation-window or compromised-key diagnostic class — the DKIM-troubleshooting spoke documents the publish-new → wait-TTL → sign-new → wait-TTL → retire-old safe-rotation procedure whose mid-rotation window produces transient revoked-key AFRF evidence rows AND the emergency-revocation empty-p= procedure for confirmed key-compromise scenarios. Read the DKIM-troubleshooting spoke alongside this forensic-reports reference WHEN triaging an AFRF stream that carries dkim=fail verdicts — this page is the evidence-format reference; the DKIM-troubleshooting spoke is the per-cause remediation playbook the operator runs ON the evidence to close the per-message failure-class root cause.
• ARC explained — Authenticated Received Chain (RFC 8617). The Authentication-Results: header in a forensic report often carries an ARC verdict from a forwarding hop.
• How attackers bypass DMARC — the RUF-AFRF-PER-MESSAGE-EVIDENCE-AS- BYPASS-ATTEMPT-DETECTION-CHANNEL companion to this RFC 6591 DMARC forensic-report reference. Where THIS page documents the RFC 6591 AFRF per-message failure-payload schema (the Auth-Failure: class label, the Original-Mail-From envelope identity, the Authentication-Results: per-mechanism verdict, the Identity-Alignment evaluation, the Delivery-Result receiver disposition, the original Headers / Body extract) the receiver emits when a publisher's mail fails DMARC, the attacker-bypass spoke documents the STRUCTURED 22-TECHNIQUE BYPASS CATALOGUE the publisher's blue-team consults when triaging whether an OBSERVED FORENSIC-REPORT FAILURE-ROW SIGNATURE represents an attacker-bypass-attempt (homoglyph-domain From: header §3.2, cousin-domain From: header §3.3, ARC-trust-chain forwarder re-signing §6.1, DKIM-replay-attack catalogued in dkim_replay_attacks §1, SPF +all-misconfiguration §4.2, dangling include cascade §4.5, subdomain-policy wildcard exploit §5.1, sp=none-and-p=reject publisher-side downgrade §5.2, …) or a benign forwarder-induced failure (typical Mailman-list / Gmail-forward / corporate-MTA- body-modification class). The 4 RFC 6591 Auth-Failure: class labels map STRUCTURALLY ONTO the attacker-bypass catalogue's 4 classes: (i) Auth-Failure: bodyhash + forwarder origin frequently benign vs + non-forwarder origin frequently DKIM-replay attack (attacker-bypass §6); (ii) Auth-Failure: dkim with valid signature-tag syntax but unknown selector frequently DKIM-key-rotation-window vs same signature with forged selector frequently DKIM-signature-forgery (attacker-bypass §6); (iii) Auth-Failure: signature with NXDOMAIN selector frequently selector- deprovision-window vs same NXDOMAIN with adjacent legitimate selector publishing frequently DKIM-selector-squatting (attacker- bypass §6); (iv) Auth-Failure: spf with relaxed-alignment-only result frequently legitimate-third-party- sender vs +DMARC strict-alignment consistently-failed frequently SPF-include- chain-hijack (attacker-bypass §4). Read the attacker-bypass spoke when a sustained cluster of forensic-report failure rows with consistent Source-IP, consistent Original-Mail-From domain-family, AND consistent Auth-Failure: class warrants triage as a CAMPAIGN-LEVEL BYPASS-ATTEMPT rather than per-message investigation — the attacker-bypass spoke's threat-actor- TTP catalogue maps each forensic-report signature onto the attacker capability (T1078 valid-accounts compromise, T1566.001 spearphishing-attachment, T1556.006 multi-factor-authentication- bypass) the forensic-evidence stream implies.
• DKIM replay attacks explained — the DKIM-REPLAY-AS-RUF-AFRF-EVIDENCE- STREAM-NON-EVENT companion to this RFC 7489 §B.2 / RFC 6591 forensic-report protocol reference. Where THIS page documents the per-message AFRF evidence- stream the receiver emits when DKIM / SPF / DMARC verification FAILS for a message, the DKIM-replay-attacks spoke documents the structurally-distinct attack-class where the attacker captures a legitimately-signed message and re- sends it to arbitrary additional recipients — the replayed message PASSES DKIM verification, PASSES DMARC alignment, and produces dmarc=pass at the receiver — so the per-failure AFRF generation gate THIS page documents NEVER FIRES for the replay-attack class, leaving the publisher STRUCTURALLY BLIND via the AFRF channel. The DKIM-REPLAY- AS-RUF-AFRF-EVIDENCE-STREAM-NON-EVENT cross-reference establishes FOUR structurally-distinct replay-attack-vs- forensic-evidence-visibility dimensions: (i) RFC-6591-Auth-Failure-MIME- envelope-only-generated-for-FAILED- authentication-events dimension — the AFRF envelope THIS page documents per RFC 6591 §3 is emitted by the receiver ONLY when at least one of DKIM / SPF / DMARC authentication produces a FAIL verdict; the replayed message produces PASS verdicts across all three protocols, so no AFRF envelope is ever generated and no per-message forensic artifact reaches the publisher's incident-response infrastructure; (ii) fo-tag-failure-reporting-options- tag-flags-do-not-cover-replay-attack- verdict-class dimension — the DMARC record's fo=0/1/d/s failure-reporting-options tag THIS page documents the operator publishes determines which authentication-failure events the receiver emits AFRF for; ALL FOUR fo-tag values produce AFRF emission only on receiver-side AUTHENTICATION FAILURES, so even the most permissive fo=1 ("emit AFRF on ANY mechanism failure") cannot cover the replay-attack class where authentication passes; the operator cannot publish a DMARC-tag value that enables replay- attack AFRF emission; (iii) replay-attack-detection-requires- VOLUME-BASELINE-and-RECIPIENT-LIST- CORRELATION-OUTSIDE-AFRF-CHANNEL dimension — the DKIM-replay- attacks spoke documents the structural non-AFRF detection patterns the publisher's incident-response team must adopt: per-domain volume-baseline anomaly detection (replay campaigns produce a sudden volume spike at the protected domain), per-recipient-list correlation (replayed messages target recipient lists OUTSIDE the publisher's legitimate mailing-list inventory), and per-message ID uniqueness audits (a repeated Message-ID: header across multiple per-recipient delivery attempts is a structural replay fingerprint) — none of these signals flows through the AFRF evidence-stream THIS page documents; (iv) x-tag- expiration-and-short-key-lifetime-as- AFRF-evidence-AT-REVOKED-KEY-PHASE-after- replay-campaign dimension — once the publisher detects a replay campaign via the OUT-OF-BAND signals above and ROTATES the DKIM key (per the DKIM-key-rotation cluster's emergency-revocation procedure), the attacker's continued replay attempts AFTER the rotation produce per-message DKIM signatures referencing the now- REVOKED selector — these post-revocation replay attempts produce permerror DKIM verdicts the receiver generates AFRF evidence for under the fo-tag THIS page documents the operator-side configuration of; the post-revocation AFRF stream becomes the per-message forensic artifact the SIRT correlates with the IP-routing-origin metadata to attribute the attacker-traffic and prepare the criminal-prosecution evidence chain. Read this DKIM-replay- attacks spoke alongside THIS forensic- reports protocol reference when authoring the per-replay-attack incident-response playbook that compensates for the AFRF-channel structural blind spot via the volume- baseline + recipient-list-correlation + message-ID-uniqueness detection patterns the DKIM-replay-attacks spoke documents the operator-discipline of.
• DMARC multi-domain strategy — the RUF-AFRF-PER-MESSAGE-EVIDENCE- AS-PER-DOMAIN-PER-PORTFOLIO-BRAND- LATERAL-MOVEMENT-DETECTION-CHANNEL companion to this forensic-reports protocol reference. Where THIS page documents the per-message RFC 6591 AFRF forensic-report payload (the Auth-Failure evidence envelope carrying verbatim message headers + DKIM-Selector + DKIM- Identity + Source-IP + Original-Mail- From + Original-Recipient + DKIM- Domain + Reported-Domain fields per receiver-side per-failure investigation), the multi-domain strategy spoke documents how a PORTFOLIO-MANAGEMENT operator running a publisher with MULTIPLE PROTECTED DOMAINS (org-domain + sister-brand-domains + acquired- company-domains + per-product subdomains) uses the per-message forensic-report stream as the primary cross-portfolio lateral- movement detection channel because the aggregate-report feed's daily- aggregated per-source_ip per- disposition row-granularity is too coarse to detect cross-domain campaign signatures that attackers deliberately fragment across the publisher's portfolio. FOUR structurally-distinct MULTI-DOMAIN- FORENSIC-EVIDENCE-CORRELATION dimensions emerge from cross-mapping the per-message AFRF payload against the portfolio-management workflow: (1) Per-message source_ip- across-portfolio-domains correlation for shared-attacker-infrastructure detection at the Source-IP-vs- Reported-Domain joint-evidence-row boundary — the multi-domain spoke documents how an attacker who targets MULTIPLE domains in the publisher's portfolio from the SAME source_ip-cohort produces a cross-portfolio Source-IP correlation in the union of per-domain forensic- report streams. Each domain's RUF feed independently reports per-message events; the portfolio- management operator's cross-domain Source-IP join surfaces the attacker's shared-egress infrastructure (compromised cloud tenant, malicious-relay open MTA, cousin-domain attacker-controlled SES customer egress) BEFORE the attacker has completed the campaign. THIS page's per-message Source-IP capture-granularity is the per- domain observability primitive the multi-domain spoke proves enables this cross-portfolio infrastructure- attribution analysis. (2) Per-message verbatim-message-headers cross-portfolio signature correlation for lateral-movement-pivot detection at the From-header + Subject + Date + Message-ID joint-fingerprint boundary — the multi-domain spoke documents the lateral-movement attack pattern where the attacker sends near-identical messages (shared template, shared call-to- action, shared phishing-landing-page URL, shared malicious-attachment SHA-256 hash) ACROSS MULTIPLE portfolio-domains simulating an org-wide compromised account or a cousin-brand spoofing campaign. The per-message AFRF payload captures verbatim message headers — the portfolio-management operator's cross-domain header-fingerprint match surfaces the campaign's lateral-movement pattern. THIS page's per-message verbatim-headers capture-granularity is the per- domain observability primitive the multi-domain spoke proves enables this lateral-movement-pivot detection. (3) Per-message DKIM-Selector-and-DKIM-Identity cross-portfolio cousin-domain- impersonation-correlation for per-brand abuse detection at the DKIM-Identity-vs-Reported-Domain joint-evidence-row boundary — the multi-domain spoke documents the cousin-domain impersonation attack class where the attacker publishes a near-lookalike domain (paypa1.com targeting paypal.com, rnicrosoft.com targeting microsoft.com, target-secure.com targeting target.com) AND uses per-cousin-domain DKIM-signing to produce dkim=pass-via-attacker- domain verdicts WHILE the From- header impersonates the publisher's brand portfolio. The per-message AFRF DKIM-Identity field captures the attacker's d=-tag verbatim — the portfolio- management operator's cross-domain DKIM-Identity-vs-portfolio-domain- lookalike-distance analysis surfaces cousin-domain attacks at the per-brand boundary. THIS page's per-message DKIM-Identity capture-granularity is the per- domain observability primitive the multi-domain spoke proves enables this cross-portfolio cousin-domain attribution. (4) Per- message Original-Recipient cross- portfolio targeting-pattern- correlation for high-value-target protection at the per-portfolio- VIP-mailbox + per-portfolio-shared- service-mailbox joint-recipient- targeting-detection boundary — the multi-domain spoke documents the targeting-pattern attack class where the attacker focuses per-message attempts on specific high-value recipients across the portfolio (CEO/CFO mailboxes, treasury@/wire-payments@ functional mailboxes, vendor-management@/ accounts-payable@ mailboxes). The per-message AFRF Original-Recipient field captures the targeted mailbox verbatim — the portfolio-management operator's cross-domain Original- Recipient-vs-portfolio-VIP-roster join surfaces concentrated targeting at the per-recipient granularity the aggregate-report feed cannot provide. THIS page's per-message Original-Recipient capture- granularity is the per-domain observability primitive the multi- domain spoke proves enables this cross-portfolio high-value-target protection workflow. Read the multi-domain spoke alongside THIS page when configuring the portfolio-management operator's per-domain RUF-stream ingestion and cross-domain correlation infrastructure: this page tells you WHAT EVIDENCE the forensic- report payload carries per-message, the multi-domain spoke tells you WHAT CROSS-PORTFOLIO CORRELATIONS the joint-evidence union surfaces AND WHY the per-message granularity is necessary for cross-domain campaign detection.
• BIMI explained — Brand Indicators. BIMI deployment depends on a stable DMARC pass rate that forensic reports help diagnose.
• BIMI SVG Tiny PS logo requirements — the RUF-PER-MESSAGE-FORENSIC-EVIDENCE- AS-PRIMARY-CROSS-DOMAIN-ATTRIBUTION- PIPELINE-FOR-BIMI-IMPERSONATION-AND-SVG- ASSET-MIS-SERVE-DIAGNOSTICS companion reference. Where THIS page documents the RFC 6591 DMARC forensic-report (RUF) per-message Auth-Failure payload (the ARF-formatted message/feedback-report body + original-message attachment + redacted headers + per-message authentication-failure-result evidence the receiver emits when a DMARC-fail message warrants per-message investigation), the BIMI-SVG-Tiny-PS spoke documents the byte-level SVG-Tiny- PS profile compliance contract whose publisher-side authoring violations AND cross-domain mis-serve patterns surface in the RUF-per-message forensic-report payload, across four RUF-forensic-BIMI- layer diagnostic dimensions: (i) the §7.4 BIMI-impersonation attack class (attacker publishes a cousin-domain BIMI record pointing at the victim's brand logo SVG URL) produces per-message RUF Auth- Failure rows at the victim domain's reporting mailbox WHEN the attacker's cousin-domain mail flow fails DMARC at the victim's receiver — the RUF payload's original-message-attachment header capture surfaces the attacker's BIMI l= URL pointer and the publisher can cross-reference against their own SVG-Tiny-PS asset's authored- URL to confirm cross-domain logo-asset- substitution attempts, (ii) RUF Auth- Failure rows for legitimate mail flow whose downstream BIMI display fails at the MUA layer composes the SVG-Tiny-PS byte-compliance failure-mode diagnostic (SVG asset fetch returns 4xx/5xx, SVG bytes fail BIMI Group validator conformance check, SVG file-size exceeds the 32KB Gmail rendering ceiling) with the per-message DMARC Auth-Failure forensic-evidence stream — operators MUST correlate the two evidence streams to disambiguate BIMI-display-failure root cause, (iii) per-tenant SaaS-platform forensic- evidence patterns where the BIMI l= URL points at the SaaS-platform's CDN-hosted SVG asset but the per-customer-domain mail flow fails DMARC at receivers (and thus BIMI display is gated off) produces distinctive cross-domain RUF attribution patterns the publisher's forensic-ingestion pipeline surfaces for incident-response triage, and (iv) the publisher's own SVG-Tiny-PS asset bytes are an out-of-band evidence surface that forensic-evidence ingestion pipelines cross-reference against to validate that an in-band DMARC-pass message's downstream BIMI display chain is not being broken by a downstream SVG-asset-fetch failure rather than the per-message authentication-failure-evidence the RUF payload captures directly. Read the BIMI-SVG-Tiny-PS spoke alongside this RUF-forensic-evidence reference when triaging BIMI-impersonation attempts or downstream BIMI-display- failure incidents — the per-message Auth-Failure forensic-evidence payload this page documents and the publisher- side SVG-Tiny-PS byte-compliance contract the BIMI-SVG-Tiny-PS spoke documents compose into the BIMI-layer diagnostic workflow at the cross- domain attribution boundary.
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Companion transport-security standard with its own reporting stream (TLS-RPT).
• DANE explained (RFC 7672 DANE-for-SMTP) — the RUF-PER-MESSAGE-AUTH-FAILURE- EVIDENCE-VS-DANE-TLSA-VALIDATION- OUTCOME-RECONCILIATION companion reference. Where THIS page documents the RFC 6591 DMARC forensic-report (RUF) per-message Auth-Failure evidence payload (the AFRF-format body containing the original Headers, Authentication-Results, signature verification details, and per-row SPF / DKIM / DMARC verdict reasons), the DANE-explained spoke documents the RFC 7672 DANE-for-SMTP per-MX-host TLSA-record validation outcome that constitutes a STRUCTURALLY SEPARATE evidence stream operating at the TRANSPORT LAYER rather than the MESSAGE-IDENTITY layer this page's RUF reports surface. The RECONCILIATION concern is that a RUF forensic report on a specific per-message DMARC failure (e.g., dkim=fail aligned= false) does NOT carry the receiver-side TLSA-validation verdict for the SMTP connection that delivered the message — the TLSA- validation outcome (TLSA-matched, TLSA-not-matched, TLSA-DNSSEC- bogus, no-TLSA-published-with-DANE- opportunistic-fallback) surfaces instead through TLS-RPT per-day-per-MX-host aggregated evidence per RFC 8460. The two evidence streams together complete the per-message authentication audit trail: the RUF payload documented on THIS page covers the application- layer message-identity authentication outcome; the DANE-explained spoke's TLSA-validation pipeline + the adjacent TLS-RPT reporting stream cover the transport-layer TLS- certificate-authentication outcome. Read this when a RUF report surfaces a per-message DMARC failure and the operator wants to reconcile whether the failure correlated with a transport-layer TLS-handshake anomaly — the DANE-explained spoke documents the TLSA record format, the DNSSEC- dependency model, the certificate- usage / selector / matching-type byte fields, and the receiver-side TLSA-validation logic whose outcome the TLS-RPT report stream aggregates.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). The transport-layer equivalent of DMARC reporting.
• TLS-RPT report format (RFC 8460 §4 JSON schema — the failure-record twin of DMARC RUF AFRF) — the per-incident failure-record format spoke that completes the cross-protocol-cluster FAILURE-REPORT pairing with the DMARC RUF AFRF format documented on THIS page. Where THIS page documents the RFC 6591 AFRF MIME format the receiver-side forensic-report generator emits PER FAILED AUTHENTICATION EVENT (the Feedback-Type: auth-failure header, the Authentication-Results, the per-incident Source-IP + Auth-Failure + Reported-Domain + Original-Mail-From + the redacted body), the TLS-RPT report-format spoke documents the JSON schema the receiver emits PER FAILED TLS HANDSHAKE EVENT (the failure-details[] array's per-incident result-type + sending-mta-ip + receiving-mx-hostname + failed-session-count + the optional additional-information URI). The two are structurally analogous — both decompose an aggregate-counter delta into a per-incident failure tuple operators can correlate against AiTM / misconfiguration / attacker-injection — but they sit at different protocol layers (DMARC RUF at the authentication-verdict layer, TLS-RPT failure-details at the transport-encryption-handshake layer) and they are emitted under different policy levers (fo=1 / fo=d / fo=s / fo=0 for DMARC RUF granularity vs. policy-type: tlsa / policy-type: sts / policy-type: no-policy-found for TLS-RPT scope). Together they provide the end-to-end PER-INCIDENT failure-archaeology stack from the authentication gate down to the wire-level transport-encryption handshake — operators investigating an authentication-AND-transport compound incident (e.g. a TLS-stripping AiTM that also injected an unsigned spoof) need BOTH report streams to reconstruct the attack chain.
• CAA records explained - the CAA-IODEF-CERT-ISSUANCE-LAYER- PARALLEL-FAILURE-REPORT-STREAM companion to this DMARC RUF forensic-reports reference, extending the cross-protocol cluster FAILURE-REPORT pairing established by the TLS-RPT-report-format sibling ABOVE to a THIRD per-incident evidence channel at the cert-issuance layer. Where the sibling TLS-RPT-report-format entry above documents the transport-encryption- handshake-layer per-incident JSON-schema twin to DMARC RUF AFRF, the dedicated CAA-records spoke documents the STRUCTURALLY-DISTINCT cert-issuance- layer per-CAA-violation-incident evidence stream produced by the RFC 8659 §3 CAA- property iodef tag whose publication establishes a cert-issuance- violation reporting URI parallel to the DMARC ruf= tag's per-message- failure reporting URI at FOUR cert-layer- vs-authentication-layer coordination dimensions: (i) both iodef= (CAA) and ruf= (DMARC) publish a per- domain incident-reporting URI the publisher controls - CAA-violation incidents (CA attempted to issue cert violating publisher's issue= permission, or CA observed an unauthorised cert-issuance request) flow to the publisher's iodef-URI mailbox; DMARC per-message authentication-failure incidents flow to the publisher's ruf= mailbox - the per- publisher mailbox-binding publication discipline is structurally identical across the two layers; the CAA- records spoke documents the per-publisher iodef-URI publication discipline that mirrors this page's per-publisher RUF- mailbox publication discipline; (ii) both evidence streams decompose aggregate failure counters into per- incident evidence tuples - DMARC RUF AFRF reports decompose <auth_result> dmarc=fail aggregate counts into per-message forensic samples; CAA iodef reports decompose cert-mis-issuance-attempt aggregate counts into per-incident cert-application-attempt evidence - both provide the per-incident granularity aggregate counts cannot; the CAA-records spoke documents the per- cert-mis-issuance-incident evidence- decomposition discipline parallel to this page's per-message-authentication- failure evidence-decomposition; (iii) both layers correlate against ATTACKER-attempt vs MISCONFIGURATION root causes - DMARC RUF AFRF reports distinguish attacker-injected unsigned spoof attempts from publisher-side misconfigured-SPF/DKIM-deployment legitimate-misalignment; CAA iodef reports distinguish attacker-attempted cert mis-issuance from publisher-side misconfigured-CAA-record-blocking- legitimate-cert-issuance - both layers require the same correlation discipline the operator's investigation playbook runs against per-incident evidence; the CAA-records spoke documents the per-cert-incident attacker-vs- misconfiguration root-cause-attribution discipline; and (iv) the two layers have DIFFERENT operator-side response playbooks - DMARC RUF incidents feed into the per-message attacker- bypass-detection / per-message-SPF-DKIM- misconfiguration-remediation workflow; CAA iodef incidents feed into the per- cert-issuance-incident CA-relationship- management / per-cert-issuance-incident cert-revocation-coordination workflow - operators publishing BOTH ruf= AND iodef= URIs maintain two structurally-distinct incident- response playbooks the dedicated CAA- records spoke catalogues alongside this page's DMARC-RUF playbook; the CAA-records spoke documents the per- cert-incident response-playbook the publisher must operate in parallel to this page's per-message-authentication- incident response-playbook. Read the dedicated CAA-records spoke alongside this DMARC RUF forensic-reports page when scoping the per-publisher per- incident evidence-stream publication discipline across the cert-issuance and authentication-verdict layers together - the spoke is the authoritative RFC 8659 §3 iodef- property reference whose four cert- layer-vs-authentication-layer failure- report coordination boundaries this DMARC RUF forensic-reports page is the authentication-layer-evidence-stream companion for.
• DMARC deployment checklist — the RUF-FORENSIC-REPORT-PUBLICATION-AS-OPTIONAL-CHECKLIST-STEP companion to this forensic-reports reference — the RUF-FORENSIC-REPORT-PUBLICATION-AS- OPTIONAL-CHECKLIST-STEP companion documenting WHERE the optional ruf= publication step sits in the linear DMARC deployment checklist sequence and WHICH operator-maturity threshold determines whether to publish forensic-report addressing at all. Where THIS page documents the forensic-report INGESTION mechanics in protocol-precise terms (RFC 7489 §7.3 failure-reporting URI scheme, RFC 6591 AFRF message format the ForensicReportParser consumes, the ruf=mailto: delegation pattern for external receivers and its _report._dmarc.example.com DNS authorization requirement), the deployment-checklist spoke documents the DEPLOYMENT-PHASE ORDERING of forensic-report adoption: ruf= is a Phase-3+ OPTIONAL step (introduced only after rua= is well-established and the per-IP-row aggregate-attribution work is producing actionable insights), and the checklist documents the operator-maturity prerequisites (RUA pipeline producing attribution-complete rows, on-call rotation ready to absorb per-message PII-bearing forensic copies, mailbox storage provisioned for the multiplicatively-larger AFRF stream volume). Read THIS forensic-report-ingestion page WITH the deployment-checklist reference when an operator asks "should we publish ruf=": the answer DEPENDS on the operator's current checklist phase and attribution-maturity per the checklist's Phase-3 readiness criteria. Where THIS page documents the INGESTION mechanics, the deployment-checklist spoke documents the OPERATIONAL-PHASE-ORDERING that gates forensic-report adoption.
• DMARC monitoring — the RUF-FORENSIC-REPORT-STREAM-AS-INCIDENT-RESPONSE-TRIGGER-INPUT-TO-CONTINUOUS-OBSERVABILITY-INFRASTRUCTURE-COMPANION spoke to this DMARC-forensic-reports RFC 7489 §7.3 / RFC 6591 AFRF reference. Where THIS page documents the RUF forensic-report AFRF envelope structure (the Feedback-Type: auth-failure / Authentication-Results: / Original-Mail-From: / Source-IP: / Reported-Domain: / Authentication-Failure: headers, plus the redacted / per-receiver-policy-bounded message-sample-attachment that surfaces per-failing-message evidence at the moment-of-failure grain), the DMARC-monitoring deployment spoke documents the OPERATIONAL CONSUMER of the per-message forensic-report stream this page documents — the on-call / alert-paging / incident-response triage workflow an operator runs ON TOP OF forensic-report ingestion to elevate per-message AFRF envelopes into a REAL-TIME SECURITY-INCIDENT-RESPONSE posture. The monitoring spoke documents the per-incident severity-triage matrix (FORENSIC-REPORT-VOLUME-SPIKE-AS- ONGOING-PHISHING-CAMPAIGN-INDICATOR, per-source_ip-attribution-to-known- third-party-sender-cohort vs unknown- IP-attacker-bypass-attempt-cohort, per-DKIM-selector-rotation-misconfigur ation-vs-key-compromise distinguishing criteria) and the alert-routing rules that fire per forensic-report severity class. The monitoring spoke documents the per-incident attribution-workflow for converting the forensic-report Source-IP: + Original-Mail-From: attribution into an action plan (a legitimate-third-party-vendor-onboarding- gap remediation, a DKIM-key-rotation emergency response, a treasury-team urgent-notification, a full incident- response escalation against an external-attacker-bypass attempt targeting the domain). The monitoring spoke is structurally distinct from the DMARC-Analyzer-Dashboard tool linked below — the dashboard is THIS product's forensic-report ingestion + visualisation surface; the monitoring spoke documents the cross-product OPERATIONAL POSTURE an operator runs ON TOP OF the dashboard (the dashboard ingests + visualises per-message AFRF envelopes; the monitoring spoke documents the SLO-threshold / on-call-alert-routing / per-incident-severity-class / per-source_ip-attribution triage-discipline that elevates per- message visualisations into a continuous- incident-response posture). Read the monitoring spoke alongside this page when designing the forensic-report-driven incident-response workflow for a domain's DMARC posture — the AFRF ingestion pipeline described here is the INPUT to the incident- response workflow documented in the monitoring spoke, and the monitoring spoke is the canonical reference for WHICH per-forensic-report attribution-and-severity classifications feed which operational decisions (third-party-vendor-onboarding-gap remediation, DKIM-key-compromise emergency rotation, attacker-bypass-attempt incident- response escalation).
• DMARC Analyzer Dashboard — ingests aggregate (RUA) and forensic (RUF) reports via the includes/DmarcParser.php and includes/ForensicReportParser.php pipelines.
• Email deliverability — the RUF-FORENSIC-FEEDBACK-LOOP-AS- DELIVERABILITY-DIAGNOSTICS-INPUT companion. Where THIS page documents the DMARC forensic (RUF / failure- report) feedback channel (RFC 6591 + RFC 7489 §7.3 forensic-report format, the receiver-side per-failure-event RUF emission discipline, the publisher- side ruf=mailto: mailbox configuration, the GDPR Art 28 / Art 6 legal-basis assessment for processor- side ingestion of recipient-PII- bearing forensic envelopes), the deliverability spoke documents the UMBRELLA RECEIVER-SIDE INBOX-PLACEMENT OUTCOME the per-message forensic feedback feed surfaces the diagnostics-grade detail for. RUF reports surface PER-MESSAGE FAILURE FORENSICS that aggregate (RUA) reports structurally cannot: (i) the per-message envelope SMTP-MAIL-FROM / SMTP-RCPT-TO / source-IP / receiver- side timestamp; (ii) the per-message SPF result with the specific mechanism that failed (the receiver- side spf=fail for the specific include: or ip4: mechanism); (iii) the per-message DKIM result with the specific selector and the specific failure reason (signature- verify / body-hash-mismatch / header-list-mismatch / canonicalization- mismatch); (iv) the per-message DMARC evaluation result with the specific alignment-failure reason (organisational-domain-mismatch / FQDN-mismatch under strict mode); (v) a redacted excerpt of the failing message's headers + body sufficient for forensic reconstruction. This per-failure granular signal lets the operator distinguish authentication- misconfiguration (publisher-side fix needed at the SPF / DKIM publication layer) from content-reputation deliverability degradation (positive- side fix needed at the message-content / sending-cadence / list-hygiene layer) — a distinction the deliverability spoke documents as fundamental to the umbrella inbox-placement-outcome debugging workflow. Read THIS RUF-forensic- reports page WITH the deliverability spoke when diagnosing a publisher whose aggregate-report-level authentication-pass-rate looks acceptable but whose inbox-placement-outcome is degrading — the per-message RUF feedback loop is the canonical diagnostic surface.
• DMARC for transactional email — the TRANSACTIONAL-ESP-PER-MESSAGE-AFRF- EMBEDDED-DKIM-CNAME-DELEGATED-SIGNATURE- EVIDENCE companion to this DMARC forensic- reports reference. Where THIS page documents the per-failure RFC 6591 / RFC 7489 §7.3 AFRF forensic-report payload format (per-message envelope SMTP-MAIL-FROM / SMTP-RCPT-TO / source-IP / receiver-side timestamp / per-message SPF + DKIM verdict with the specific failing mechanism / verbatim Authentication-Results header chain / verbatim DKIM-Signature header bytes / embedded message/rfc822 part with the offending message), the transactional-email deployment spoke is the PER-ESP-CUSTOMER-DOMAIN AFRF-EVIDENCE- ATTRIBUTION COMPANION documenting the FOUR TRANSACTIONAL-CLASS RUF-DIAGNOSTIC dimensions whose per-customer-domain AFRF evidence-extraction discipline is structurally distinct from the marketing-ESP / shared- hosting / cloud-provider AFRF-evidence patterns: (i) per-customer-domain DKIM-CNAME-delegated signature evidence verbatim citation in the AFRF message/rfc822 embedded part from the transactional ESP signing boundary — the per-failure AFRF payload preserves the verbatim DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=<customer- domain>; s=<esp-managed-selector>; ...; bh=<body-hash>; b=<signature> header stamped by the transactional ESP's signing infrastructure — enabling per- customer per-ESP-managed-selector attribution of which transactional-ESP- signed message produced the per-message verification failure; (ii) per-ESP- managed bounce-domain envelope SMTP-MAIL- FROM evidence as transactional-class return-path-vs-customer-SPF-record alignment diagnostic — the per- failure AFRF envelope SMTP-MAIL-FROM field preserves the per-customer return-path bounce domain (bounce.<customer>.com) the transactional ESP publishes as a delegated bounce-domain, enabling per- message attribution of whether the envelope-MAIL-FROM aligned with the customer's SPF record at the per-message receiver-side evaluation boundary; (iii) per-message t= timestamp + x= expiry tag verbatim citation as transactional-message replay-protection diagnostic — the per-failure AFRF message/rfc822 embedded part preserves the verbatim DKIM-Signature t=<issue-timestamp> + x=<expiry-timestamp> tag values the transactional ESP stamped at signing time — enabling per-message attribution of whether the message was verified within the publisher-side time- bound window the transactional ESP configured for the time-sensitive transactional class (OTPs typically have a 30-second-to-5-minute time-bound; password-resets typically have a 1-hour time-bound; order-confirmations typically have a 24-hour time-bound); (iv) per-receiver mailbox-rule auto- forwarding chain attribution via the AFRF Received: header verbatim citation — the per-failure AFRF message/rfc822 embedded part preserves the verbatim Received-header chain showing the message's per-hop transit path from the transactional ESP outbound MTA through any intermediate forwarders to the final receiver — enabling per-message attribution of whether a forwarder-induced SPF-break at the second- hop receiver triggered the per-message DMARC-fail outcome (a common transactional- ESP failure pattern when recipients configure Gmail-side / Outlook-side mailbox-rule auto-forwarding). Read the transactional-email spoke alongside this forensic-reports reference when a per- failure AFRF payload arrives from a transactional ESP outbound stream and the per-customer-domain DKIM-CNAME-delegated signature evidence + per-ESP-managed bounce-domain envelope evidence + per- message t=/x= time-bound evidence must be triaged against the transactional ESP's per- customer signing-and-bounce-handling publication discipline to attribute the per-message DMARC-fail root cause distinctly from marketing-ESP / shared- hosting / cloud-provider AFRF-evidence attribution patterns.
• DMARC for cPanel hosts — the SHARED-HOSTING-CPANEL-PER-ACCOUNT- DEPLOYMENT-AS-PER-SOURCE-IP-AFRF-EVIDENCE- ATTRIBUTION-PATTERN-DISTINCT-FROM- MARKETING-ESP-TRANSACTIONAL-ESP-CLOUD- PROVIDER-AFRF-ATTRIBUTION-CLASSES companion to this DMARC forensic-reports reference. Where THIS page documents the RFC 7489 §7.3 / RFC 6591 / RFC 5965 AFRF per-message forensic-report format and the per-sender-class attribution patterns operators apply to per-message DMARC- fail evidence streams, the DMARC-for- cPanel spoke is the SHARED-HOSTING per- tenant deployment-reference documenting the cPanel-host-operator's per-account deployment topology that produces a CANONICAL AFRF evidence attribution pattern distinct from every other sender class at FOUR per-cPanel-tenant-AFRF- evidence-attribution dimensions: (i) cPanel-host shared-source-IP attribution — every cPanel-tenant's outbound mail egresses from the SAME cPanel-host shared egress IP (or a small pool of cPanel-host egress IPs), so per- message AFRF evidence rows attributed to a cPanel-host source-IP exhibit MANY per-tenant-domains sharing ONE source- IP block — the DMARC-for-cPanel spoke documents the cPanel-host shared- IP egress topology whose AFRF-evidence- attribution fingerprint operators differentiate from per-source-IP attribution patterns of marketing-ESP (one ESP-IP-pool per ESP-tenant) / transactional-ESP (one ESP-IP-pool per transactional-tenant) / cloud-provider (one cloud-IP-pool per cloud-tenant) sender classes; (ii) per-tenant- domain attribution — every cPanel-tenant signs against its own tenant-domain d= identifier, so per- message AFRF evidence rows show MULTIPLE distinct d=<tenant-d> author- domain signing identities behind the SAME cPanel-host shared source-IP — the DMARC-for-cPanel spoke documents the cPanel-tenant per-tenant-domain signing topology whose AFRF-evidence- attribution fingerprint operators differentiate from marketing-ESP per- ESP-d= signing (one d=<esp-d> across many ESP-customers) / transactional-ESP per- customer d=<customer-d> signing (per-customer signing across one ESP-IP- pool); (iii) per-tenant-selector publication — every cPanel-tenant publishes its default._domainkey.<tenant-d> TXT-RR on the per-tenant DNS zone, producing per-tenant per-selector AFRF- evidence-attribution where each per- message DKIM-Signature header carries the canonical s=default; d=<tenant-d> cPanel-default selector publication fingerprint — the DMARC-for- cPanel spoke documents the cPanel-host- operator's canonical s=default selector publication discipline whose AFRF- evidence-attribution fingerprint operators differentiate from marketing- ESP per-customer selector partitioning (per-customer-named selectors) / transactional-ESP per-customer selector partitioning / cloud-provider per- tenant selector partitioning sender- class attribution patterns; (iv) per-tenant Return-Path rewrite — every cPanel-tenant's outbound mail carries an envelope-MAIL-FROM rewritten to the tenant-domain or the cPanel-host Return-Path domain, producing per- message AFRF evidence rows where the envelope-MAIL-FROM organisational-domain per-tenant alignment status the receiver- side validator records is per-cPanel- tenant DISTINCT — the DMARC- for-cPanel spoke documents the cPanel- host-operator's per-tenant Return-Path rewrite discipline whose AFRF-evidence- attribution fingerprint operators differentiate from marketing-ESP / per- customer / cloud-provider Return-Path rewrite patterns. Read the DMARC-for- cPanel spoke alongside this AFRF forensic-reports reference when AFRF evidence rows surface a per-source-IP attribution pattern matching the cPanel- shared-hosting fingerprint — the spoke documents the per-tenant cPanel-host deployment topology operators correlate against the cPanel-host shared-source- IP / per-tenant-domain / per-tenant- selector / per-tenant-Return-Path AFRF- evidence-attribution fingerprint THIS page documents.
• DMARC for Google Workspace — the PER-WORKSPACE-TENANT-PER-CUSTOM- DOMAIN-CLOUD-MAILBOX-PROVIDER-DEPLOYMENT- AS-PER-MESSAGE-AFRF-EVIDENCE-ATTRIBUTION- FINGERPRINT companion to this RFC 6591 AFRF forensic-reports reference. Where THIS page documents the per-publisher per-domain RFC 6591 ARF / RFC 5965 AFRF MIME-envelope per-message forensic-report payload (the verbatim per-failed-message evidence stream a publisher's ruf= mailto-URI per RFC 7489 §6.2 instructs receivers to emit), the DMARC-for-Google- Workspace spoke is the per-Workspace- tenant per-custom-domain DEPLOYMENT- TOPOLOGY REFERENCE whose per-tenant publication discipline directly produces a CANONICAL-GOOGLE-WORKSPACE-AFRF- EVIDENCE-ATTRIBUTION-FINGERPRINT distinct from every other sender-class this AFRF forensic-reporting reference catalogues (cPanel shared-hosting per-account deployment, Office 365 Hybrid Exchange dual-outbound-boundary deployment, transactional ESP per-customer-domain CNAME-delegated signing, SaaS multi- tenant relay per-customer-domain DMARC- via-CNAME-delegation, generic shared- hosting per-tenant deployment). The four- axis per-Workspace-tenant-AFRF-evidence- attribution comparison exposes the structurally-distinct per-Workspace- tenant per-custom-domain attribution- fingerprint dimensions: (i) per- Workspace-tenant per-custom-domain *.google.com outbound-source- IP envelope-attribution ↔ per-message AFRF Source-IP: field attribution — every per- Workspace-tenant outbound message connects to receivers from a Google-owned *.google.com source IP whose receiver-side AFRF Source-IP: per RFC 5965 §3.2.2 attribution value is attributable to the Google-Workspace- infrastructure (NOT the per-tenant custom-domain operator) — producing a per-Workspace-tenant AFRF-evidence attribution-fingerprint distinct from cPanel shared-hosting per-account-shared- IP attribution (where the cPanel-host operator's shared-source-IP attribution is per-cPanel-host-instance) AND distinct from Hybrid Exchange dual-outbound- boundary attribution (where the operator's per-message attribution alternates between on-prem outbound IP and cloud-M365 outbound IP based on per-mailbox routing policy); (ii) per-Workspace- tenant per-custom-domain DKIM d=<workspace-tenant-custom-domain> signing-identity ↔ per-message AFRF embedded message/rfc822 per RFC 5965 §3 DKIM-Signature header attribution — every per- Workspace-tenant outbound message carries a per-tenant per-custom-domain DKIM- Signature header signed under the per- tenant google._domainkey.<workspace- tenant-custom-domain> selector whose verbatim header bytes are preserved in the AFRF embedded message/rfc822 part, enabling per-publisher per-domain per-Workspace-tenant per-custom-domain per-message forensic reconstruction of the per-message DKIM-failure-mode (key- rotation cadence drift, body-hash mismatch from per-receiver content modification, canonicalisation drift) distinct from the per-M365-tenant selector1._domainkey.<tenant> + selector2._domainkey.<tenant> dual-selector rotation discipline; (iii) per-Workspace-tenant per-custom- domain include:_spf.google.com SPF-include-cascade envelope-MAIL-FROM- authorisation ↔ per-message AFRF embedded Authentication-Results header per RFC 8601 SPF-verdict attribution — every per-Workspace-tenant outbound message's per-receiver per-message envelope-MAIL-FROM evaluates the per- Workspace-tenant include:_spf.google.com ~3-lookup recursive SPF-cascade expansion producing a per-message SPF-verdict whose verbatim Authentication-Results header bytes are preserved in the AFRF embedded message/rfc822 part, enabling per-publisher per-domain per-Workspace- tenant per-message forensic reconstruction of the per-message SPF-failure-mode (per- receiver SPF-cascade-resolution permerror, per-message envelope-MAIL-FROM rewriting by per-receiver forwarder, per-message ARC-sealing forwarder boundary) distinct from the per-M365-tenant include:spf.protection.outlook.com ~5-lookup cascade attribution; (iv) per-Workspace-tenant per-custom- domain CANONICAL-GOOGLE-WORKSPACE-AFRF- EVIDENCE-ATTRIBUTION-FINGERPRINT ↔ per-message AFRF evidence-stream operator- triage discipline distinguishability from other sender-class fingerprints — the composite per-Workspace-tenant AFRF-attribution-fingerprint (Google- owned outbound source-IP + Google- Workspace-signed DKIM identity at google._domainkey.<d> + Google-Workspace envelope-MAIL-FROM include:_spf.google.com + mx.google.com Authentication- Results header canonicalisation) produces a per-publisher per-domain operator- triage-discipline-distinguishable AFRF- evidence-stream pattern enabling the per-publisher per-domain incident- response operator to ATTRIBUTE per- failed-message to per-Workspace-tenant deployment-topology (vs cPanel shared- hosting / Hybrid Exchange / transactional ESP / SaaS multi-tenant relay / shared hosting) at the per-message AFRF- evidence-stream triage boundary. Read the DMARC-for-Google-Workspace spoke when the operator's per-publisher per-domain AFRF-forensic-report ingestion pipeline is surfacing per-failed-message evidence whose attribution-fingerprint (Google- owned source-IP + per-Workspace-tenant DKIM-signed identity + per-Workspace- tenant SPF-include-cascade) points to the per-Workspace-tenant deployment-topology as the sender-class, and the operator needs the per-Workspace-tenant per- custom-domain DMARC publication-discipline reference to per-tenant key-rotation cadence, per-tenant SPF-cascade-budget, per-tenant Authentication-Results canonicalisation, and per-tenant Admin Console publication-surface for the per-message-incident root-cause attribution.
• DMARC for Hybrid Exchange (on-prem + Microsoft 365) — the HYBRID-COEXISTENCE-DUAL-OUTBOUND- BOUNDARY-AFRF-EVIDENCE-ATTRIBUTION companion to this RFC 6591 AFRF forensic-reports reference. Where THIS page documents the per-failure AFRF evidence-row schema operators consume from the per-receiver ruf emission, the hybrid-coexistence spoke is the HYBRID-TOPOLOGY-AFRF-ATTRIBUTION REFERENCE documenting the four per- hybrid-coexistence-AFRF-evidence- attribution dimensions operators differentiate from cloud-only-M365 and on-prem-only-Exchange attribution classes: (i) per-outbound- boundary source-IP attribution — the AFRF evidence-row's source-IP column carries either the on-prem outbound NAT'd public IP or the EXO cloud-egress pool IP depending on which outbound boundary the failed message traversed; the spoke documents the per- boundary IP-population enumeration the operator correlates against the AFRF evidence-row to attribute per-message failure-origin; (ii) per- boundary Authentication-Results header- canonicalisation drift — on- prem Exchange and Exchange Online canonicalise the Authentication-Results header differently, and the spoke documents the per-boundary canonical formatting the operator parses from the AFRF evidence-row to disambiguate which boundary the failure-attributable verdict originated at; (iii) ARC-Authentication-Results chain- evidence across the on-prem-to-cloud relay — when the failure traverses the on-prem-to-cloud relay the AFRF evidence-row carries a multi- hop ARC-Authentication-Results chain the spoke documents the per-hop evidence-attribution operator parses to identify per-relay ARC-seal verification regressions; (iv) dual-signer signing-identity ambiguity in the AFRF dkim= field — when the operator has BOTH on-prem and EXO signing the same domain the AFRF evidence-row's dkim= field carries a per-message signing-identity verdict operators correlate against the spoke's documented cloud-only / on-prem-only / dual-signer-avoid signing topology to attribute per-message signing- infrastructure failure-origin. Pair this AFRF forensic-reports reference (the per-failure evidence-row consumer reference) with the hybrid-coexistence spoke (the hybrid-topology per-message attribution reference) for any operator running hybrid Exchange.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC results plus the alignment evaluation — useful when only a sample failing message is available rather than a full forensic report.
• DMARC myths and misconceptions — the PER-AFRF-FORENSIC-REPORT-AVAILABILITY- DISCIPLINE-AS-LOAD-BEARING-REBUTTAL-EVIDENCE- AGAINST-EVERY-RUF-FORENSIC-REPORT-MYTH- COUNTERED-BY-THIS-CATALOGUE companion to THIS AFRF forensic-report pillar. Where THIS page documents the RFC 6591 AFRF per-message forensic-report format and the RFC 7489 §7.3 ruf= receiver-side emission discipline (per-receiver opt-in, per-message Authentication-Results capture, per-receiver privacy redaction policy, per-receiver emission-frequency throttle), the myths-and- misconceptions spoke is the OPERATOR-SIDE rebuttal catalogue documenting how every widely-held ruf-forensic-report myth collapses against the per-receiver- emission evidence THIS page establishes at FOUR ruf-myth-to-afrf-truth dimensions: (i) "ruf reports are universally produced by every DMARC receiver" myth — rebutted against THIS page's per-receiver ruf- emission evidence: Google, Yahoo, Outlook, Apple, and most large mailbox providers do NOT emit ruf per-message forensic reports — the "universal emission" misconception collapses against the per-receiver-opt-in evidence THIS page documents; (ii) "ruf reports give the full message body" myth — rebutted against THIS page's per- receiver privacy-redaction evidence: every emitter applies its own redaction policy (header-only emission, body-hashed emission, subject-line redaction, recipient-address truncation) under GDPR / CCPA / equivalent privacy constraints — the "full-message-body recovery" misconception collapses against the per-emitter redaction-policy evidence THIS page catalogues; (iii) "ruf and rua reports are interchangeable" myth — rebutted against the per-message-AFRF-vs-aggregate- XML format-distinction evidence THIS page establishes: rua is the per-receiver 24-hour aggregate-XML schema (RFC 7489 §7.2) while ruf is the per-message AFRF schema (RFC 6591), and operators conflate them at their peril — the "interchangeable streams" misconception collapses against the per- format schema evidence THIS page documents; (iv) "Publishing ruf= is required by DMARC" myth — rebutted against THIS page's RFC 7489 §7.2 ruf=- optional-tag evidence: the ruf= tag is OPTIONAL in the DMARC record (only v= + p= are required), and operators who publish ruf= without considering the per-receiver privacy-redaction policy risk surfacing recipient PII to attackers spoofing the ruf= destination — the "ruf-is-required" misconception collapses against the DMARC-tag-cardinality evidence THIS page establishes. Read THIS page when OPERATIONALISING the AFRF forensic-report intake; read the myths-and-misconceptions spoke when an operator, executive, or auditor cites a ruf-related DMARC misconception that contradicts the per-receiver emission / per-emitter redaction / per-format schema evidence THIS AFRF pillar documents.
• SPF forwarding issues — the PER-FORWARDER-ENVELOPE-REWRITE-AS- AFRF-EVIDENCE-PATTERN-CLASS companion to this DMARC forensic-reports reference. Where THIS page documents the AFRF per- message forensic-report intake architecture (RFC 6591 AFRF/ARF schema, per-receiver ruf= emission opt-in policy, per-emitter GDPR/CCPA privacy-redaction discipline, per-message envelope + header + body- excerpt evidence schema), the SPF- forwarding-issues spoke is the CANONICAL- AFRF-EVIDENCE-PATTERN catalogue documenting how the per-forwarder envelope-MAIL-FROM rewrite produces a distinct per-message evidence-pattern signature in the AFRF report stream at FOUR per-forwarded-message AFRF-evidence-attribution dimensions: (i) per-mailing-list-forwarder AFRF report-signature: rewritten envelope-MAIL- FROM domain attributing to the list's bounce-handler with original Header-From preserved unmodified — the canonical mailing-list AFRF evidence pattern operators identify as "envelope- MAIL-FROM rewrite to mailing-list bounce- handler" rather than a true spoofing attempt; the SPF-forwarding-issues spoke catalogues this AFRF-evidence pattern class that the per-message intake on THIS page surfaces to the operator's triage workflow; (ii) per-account- forwarder AFRF report-signature: rewritten envelope-MAIL-FROM attributing to the forwarding account's domain with unchanged Header-From and unchanged body content bytes — the canonical per-user Gmail-filter-forwarding / .forward / Outlook- rule AFRF evidence pattern that distinguishes legitimate-forwarder traffic from true Header-From spoofing; the SPF-forwarding- issues spoke catalogues this per-account- forwarder AFRF-evidence class the per- emitter redaction discipline on THIS page must NOT redact away (the rewritten envelope-MAIL-FROM IS the load-bearing forensic discriminant); (iii) per- SRS-rewriter AFRF report-signature: SRS- encoded envelope-MAIL-FROM (SRS0/SRS1 prefix + base32-encoded original domain) as canonical per-forwarder envelope-rescue fingerprint — the SRS-prefix marker in the AFRF envelope-MAIL-FROM evidence field is the unambiguous per- forwarder operational-discipline fingerprint every operator-side forensic triage workflow identifies; the SPF-forwarding-issues spoke catalogues this SRS-fingerprint AFRF- evidence class the per-message schema on THIS page preserves; (iv) per- forwarder ARC-chain AFRF report-signature: Authentication-Results header chain documenting the originating-hop SPF result plus subsequent forwarder sealer identities — the AFRF report's captured Authentication-Results-chain header sequence is the receiver-side per- hop cross-authentication-evidence the operator-side per-incident triage on THIS page consumes to differentiate a legitimate forwarder hop from a replay or spoofing attempt. Read the SPF-forwarding-issues spoke alongside this DMARC forensic- reports pillar when scoping the per-AFRF- evidence-pattern class catalogue every operator-side per-message triage workflow depends on for true-spoofing-versus- legitimate-forwarder differentiation.
• Email security glossary — the SECURITY-OPERATIONS-AND-INCIDENT- RESPONSE-VOCABULARY-CATALOGUE companion to this DMARC-forensic- reports operator-reference. Where THIS page documents the per-message RFC 6591 / RFC 5965 ARF / AFRF MIME envelope (multipart/report content- type, per-failure message/feedback- report section, Auth-Failure + Authentication-Results + Original- Mail-From + Received-SPF + DKIM- Signature evidence rows, receiver- side per-failure-event emission cadence, publisher-side ruf=mailto: configuration, fo=0/1/d/s filter-tag emission-control grammar) at the RFC 7489 §7.3 protocol layer, the glossary spoke catalogues the SOC-and-IR-and- threat-intel vocabulary every downstream analyst applies when consuming per-message AFRF evidence at four AFRF-evidence-row-to- security-operations-vocabulary coupling dimensions: (i) per- message AFRF Original-Mail-From + Reported-Domain + Source-IP evidence rows as load-bearing inputs to the glossary's IR- lifecycle entries (incident-response, detection-analysis, containment, eradication, recovery, lessons-learned, ioc, dwell-time, mttd-mttr) consumed by the SOC analyst progressing through NIST SP 800-61r2 phases on a confirmed direct-domain-spoof incident — the glossary's IR-lifecycle catalogue documents the per-phase analyst tradecraft applied to per-message AFRF evidence (the Source-IP row from the AFRF envelope is itself an IoC class shareable via STIX/TAXII; the per-failure-event emission timestamp feeds the SOC's dwell- time KPI; the per-publisher AFRF-stream cadence informs the containment-versus-eradication phase boundary), bridging the protocol-layer evidence row this page documents to the operational- response vocabulary the glossary defines; (ii) per-message AFRF body-content-fingerprint evidence rows as load-bearing inputs to the glossary's phishing + attack-taxonomy entries (phishing, spear-phishing, bec, ceo-fraud, invoice-fraud, payroll-diversion, credential-harvesting, conversation-hijacking, clone-phishing, brand-impersonation) consumed by the SOC analyst classifying the per-incident threat-pattern — the glossary's phishing-and-BEC-variant catalogue documents the per-fraud-pattern operator response (out-of-band verification thresholds, dual- approval workflows, executive- impersonation domain monitoring, FBI IC3 24-hour Financial Fraud Kill Chain reporting window) that the per-message AFRF body- fingerprint this page documents structurally consumes as the per-message attacker-attempt evidence whose pattern- classification drives the per- incident IR-playbook selection; (iii) per-message AFRF Reported-Domain look-alike evidence rows as load-bearing inputs to the glossary's look- alike-and-impersonation entries (typosquatting, homograph-attack, cousin-domain, combosquatting, lookalike-domain, display-name-attack, brand-impersonation) consumed by the brand-monitoring analyst pivoting from per-message AFRF evidence to per-attacker- domain takedown-service engagement — the glossary's look-alike catalogue documents the per-look-alike-class taxonomy (Punycode-renderer variants, cousin-TLD registrations, combosquatting modifiers, display- name spoofing patterns) that the per-message AFRF Reported-Domain row this page documents structurally surfaces, anchoring the per-publisher brand- monitoring + takedown-service + trademark-enforcement workflow to the per-message evidence stream the AFRF envelope carries; (iv) aggregate-rate per-source-IP per-Reported-Domain AFRF distributions as load-bearing inputs to the glossary's threat- intelligence and threat-modelling entries (threat-intelligence, mitre-attack, kill-chain, diamond-model, ttp, pyramid-of-pain, apt, nation-state-actor) consumed by the threat-hunter pivoting from per-message AFRF evidence to per-adversary infrastructure — the glossary's MITRE ATT&CK + kill-chain + Diamond Model + Pyramid-of-Pain catalogue documents the analytic scaffolding the threat-hunter applies when correlating per- publisher per-message AFRF evidence into per-adversary infrastructure pivots, anchoring the protocol-layer evidence row this page documents to the threat-intelligence pipeline the glossary defines. Read the glossary alongside this DMARC- forensic-reports reference when building the per-incident IR- playbook that consumes per-message AFRF evidence and operationally translates it into the SOC + IR + threat-intelligence + look-alike- defense vocabulary every downstream analyst consumes.
• Domain Security Checker — live DNS lookups for the DMARC record and the rua= / ruf= destinations.
• SPF PermError vs TempError — the LOAD-BEARING per-publisher per-domain PER-MESSAGE-SPF-PERMERROR- AND-TEMPERROR-AS-RUF-PAYLOAD- AUTHENTICATION-RESULTS-FIELD-VALUE- CATALOGUE companion documenting the spf=permerror / spf=temperror verdict family that appears in the per-message forensic-report Authentication- Results: header field as a first-class verdict alongside spf=pass / spf=fail / spf=softfail / spf=neutral — the receiver- side per-message DNS-resolver-failure- mode observation that THIS page's RFC 6591 AFRF MIME-multipart forensic- report payload structurally surfaces per individual failure-event to the per-publisher per-domain operator's per-publisher per-domain RUF mailbox. Operators investigating a per-message DMARC-fail forensic report MUST be able to distinguish a per-message spf=permerror verdict (publisher-side syntactically-invalid SPF record / non-existent include: domain / RFC 7208 §4.6.4 ten-DNS-lookup-limit exhaustion — a deterministic publisher-fix-required state) from a per-message spf=temperror verdict (per-receiver per-resolver- instance transient authoritative-DNS- server unreachability — a non- actionable per-message observation) from a per-message spf=fail verdict (the published SPF record successfully evaluated and authoritatively rejected the sender IP — the canonical per-message authentication failure the forensic-report payload exists to document). The receiver-side per-message DMARC-evaluation-failure- attribution path branches sharply on which of these three verdicts the per-message Authentication- Results: header field records. Where THIS page documents the per- message PER-MESSAGE RFC 6591 AFRF MIME-MULTIPART FORENSIC-REPORT PAYLOAD REFERENCE (the Feedback-Type: auth-failure envelope, the Authentication- Results: header field, the per-message Source-IP: / Original-Mail-From: / Original-Rcpt-To: / SPF-DNS: / DKIM- Domain: attribution fields), the PermError vs TempError spoke documents the per-publisher per-domain UPSTREAM-CAUSE CATALOGUE for the SPF- side per-message error verdicts the forensic-report payload THIS page documents surfaces. Read THIS page when CONSUMING the per-message forensic-report payload; read the PermError vs TempError spoke when DIAGNOSING the per-message spf=permerror / spf=temperror verdict attribution the consumed forensic- report payload's Authentication- Results: header field structurally catalogues per individual failure- event.
• DMARC for SaaS senders — the SaaS-multi-tenant-relay companion to this DMARC forensic-report (RUF) consumption discipline. Where THIS page documents the per-publisher per-failure AFRF (RFC 6591) forensic-report payload consumption discipline — the per-failure ARF envelope, per-message-evidence attribution to specific Auth-Results verdict patterns — the SaaS-senders spoke documents the canonical DOWNSTREAM SaaS-multi-tenant-relay topology where per-customer-domain forensic-report payloads ENABLE per- customer per-message attribution that no per-customer-aggregate-only observability surface provides. The DMARC-FORENSIC-VS-SAAS-RELAY cross- reference establishes FOUR coupling dimensions: (i) per-customer- domain forensic-report payload attribution to per-SaaS-vendor sub- tenant-ID per-message failure catalogue — when a SaaS relay publishes per-customer-domain DMARC ruf= with the SaaS- vendor's forensic-collector endpoint, the per-failure ARF payload becomes the per-customer per-sub-tenant attribution evidence the SaaS-vendor's incident- response queue consumes; the SaaS spoke documents the per-customer per- sub-tenant attribution discipline THIS page's RUF payload consumption pipeline depends on; (ii) per-customer- domain forensic-report payload empirical validation of per-SaaS-vendor per- customer-domain DKIM-CNAME-delegation signing-key cryptographic-correctness and per-customer SPF-include-cascade envelope-source-authorization- correctness — the per-failure forensic-report Authentication- Results: header field with per- message dkim=fail vs spf=fail attribution evidence empirically validates whether a per-customer per- SaaS-vendor signing-discipline regression is the root cause; the SaaS spoke documents the per-customer- domain delegation-discipline surface this empirical validation evidence anchors; (iii) per-customer- domain forensic-report payload consumption parallels the per-customer- domain aggregate-report consumption the SaaS DMARC-as-a-service offering provides — operators of SaaS relays consume both aggregate (RUA) and forensic (RUF) per-customer-domain payloads to build the per-customer per-domain per-message + per-day observability surface; the SaaS spoke documents the dual-report-stream consumption discipline whose per- customer per-vendor visibility this page's forensic-payload consumption catalogue contributes; (iv) per- customer per-SaaS-vendor per-message forensic-report opt-in coordination — not every receiver emits RUF (Google / Microsoft suppress; Yahoo / Mail.ru / Yandex emit); SaaS-vendors operating per-customer-domain DMARC publication must document the per-receiver RUF emission expectation to per-customer operators; the SaaS spoke documents the per-customer per-vendor per-receiver RUF expectation contract this page's per-receiver RUF emission catalogue anchors. Read the SaaS-senders spoke when consuming per-customer-domain DMARC forensic-report payloads on a SaaS-vendor's per-customer DMARC-as-a- service deployment.
• MX records explained — the APEX-MX-RR-AS-RUF-MAILBOX-RECEIVABILITY- PREREQUISITE companion to this DMARC forensic-report (RUF / failure-report) reference. Where THIS page documents the RFC 6591 ARF / RFC 5965 AFRF MIME envelope (multipart/report content-type, per-failure message/feedback-report section, the Auth-Failure / Authentication-Results / Original-Mail-From evidence rows, the receiver-side per-failure-event emission cadence, the publisher-side ruf=mailto: configuration, the fo=0/1/d/s filter-tag emission-control grammar, the GDPR Art 28 legal-basis processor-relationship analysis for cross-tenant RUF transport), the MX- records spoke is the APEX-MX-RR-PUBLICATION reference DMARC publishers consult when verifying the apex MX RRset on the ruf=mailto: mailbox's domain remains continuously resolvable so the receiver-side AFRF emission MTA can actually deliver the per-failure forensic envelope back to the publisher. Three structurally-distinct RUF-as-receiver- emitted-mail-receivability dimensions the MX-records spoke covers that THIS forensic-reports reference intentionally elides: (i) RUF mailbox domain's apex MX RR continuity is THE inbound-routing gate every receiver-side AFRF emission MTA evaluates before SMTP delivery to the publisher mailbox — a dropped or mis-ordered apex MX RRset on the RUF mailbox's domain produces silent receiver-side bounce-or-discard outcomes the publisher's per-failure evidence consumer cannot observe; (ii) fo=1 / fo=d / fo=s emission filter-tag escalation only amplifies the per-failure RUF emission rate downstream of an already-receivable publisher-side mailbox — flipping the filter tag without first verifying the RUF mailbox domain's MX RRset resolvability produces no observable forensic-evidence increase even when the receiver-side cron fires more frequently; (iii) cross-receiver RUF emission cadence differences between Google / Yahoo / Microsoft / Yandex amplify the per-domain MX RR continuity demand — a four-hour MX RRset outage that one receiver's AFRF cron silently retries past, another receiver's bounces against, dropping per- failure evidence asymmetrically across the publisher's per-receiver forensic- evidence catalogue.
• RFC 7489 §7.3 — Failure Reporting — the foundational DMARC forensic-report specification.
• RFC 6591 — AFRF — the Authentication Failure Reporting Format envelope used by DMARC forensic reports.
• RFC 5965 — ARF — the original Abuse Reporting Format that AFRF extends.
• RFC 8601 — Authentication-Results header — the canonical Authentication-Results: header forensic reports carry.
• Email spoofing — the DIRECT-DOMAIN-SPOOFING-AND- LOOK-ALIKE-AND-DISPLAY-NAME- SPOOFING-CANONICAL-THREAT-MODEL companion to this DMARC-forensic- reports operator-reference. Where THIS page documents the RFC 6591 / RFC 5965 ARF / AFRF per-failure-event MIME envelope (multipart/report, per-failure message/feedback-report section, Auth-Failure + Authentication- Results + Original-Mail-From + Received-SPF + DKIM-Signature evidence rows, receiver-side per-failure emission cadence, publisher-side ruf=mailto: + fo=0/1/d/s publication-discipline), the email-spoofing spoke documents the CANONICAL THREAT-MODEL each per-failure AFRF MIME envelope attests to, bridging the per- message AFRF evidence-row catalogue this page documents to the per-spoof-variant threat- model catalogue the email- spoofing spoke documents at four cross-protocol-AFRF-evidence- row-to-spoof-variant coupling dimensions: (i) per-message AFRF Original-Mail-From + Header-From + Source-IP evidence rows as load-bearing forensic-evidence signature for the direct-domain-spoofing spoof-variant the email- spoofing spoke catalogues — direct-domain-spoofing (attacker forges From: ceo@victim.com with envelope MAIL-FROM also spoofed) produces an AFRF evidence-row where Original-Mail-From matches the publisher's Header-From d-domain AND Source-IP falls outside the publisher's expected source-IP set; the email-spoofing spoke documents this AFRF evidence-signature as the canonical fingerprint of the direct-domain-spoofing spoof-variant; (ii) per- message AFRF Reported-Domain + Original-Mail-From evidence rows as load-bearing forensic- evidence signature for the look-alike-domain spoof-variant the email-spoofing spoke catalogues — look-alike- domain spoofing (attacker registers vict1m.com / victim-secure.com with its own SPF/DKIM/DMARC and sends from there with From: ceo@vict1m.com) produces a structurally- distinct AFRF evidence-row where Reported-Domain contains the look-alike domain and the publisher's own domain does NOT appear in the Original-Mail-From row; the email-spoofing spoke documents this AFRF evidence-signature as the canonical fingerprint distinguishing look-alike- domain spoofing from direct- domain-spoofing (a critical per-spoof-variant attribution every per-message forensic-analyst this page's evidence-row catalogue documents the discipline of consumes); (iii) per- message AFRF DKIM-Signature + Authentication-Results evidence rows as load-bearing forensic-evidence signature for the display-name-spoofing spoof-variant the email- spoofing spoke catalogues — display-name spoofing (attacker sets From: "Victim CEO" <attacker@gmail.com> — the address-portion d-domain is gmail.com which legitimately publishes DKIM + SPF + DMARC, but the display-name impersonates the publisher's executive) produces an AFRF evidence-row with dkim=pass + spf=pass + dmarc=pass at the Header-From d-domain (gmail.com) — DMARC does NOT flag this spoof-variant; the email- spoofing spoke documents the downstream pattern-matching + display-name lexical-analysis + executive-list correlation compensating control the per- message AFRF evidence-row this page documents structurally cannot detect; (iv) per- message AFRF body-content- fingerprint evidence as load- bearing forensic-evidence- signature for the conversation- hijacking + account-takeover spoof-variants the email- spoofing spoke catalogues — conversation-hijacking and account-takeover spoof-variants (attacker operates from inside a legitimate compromised account or hijacked thread) produce AFRF evidence-rows with all-authentication-pass verdicts and a per-message body-content-fingerprint showing wire-transfer keywords + invoice payment- detail-update patterns + urgency lures; the email- spoofing spoke documents the downstream behavioural-anomaly + thread-context analysis + out-of-band verification compensating control the per- message AFRF body-content- fingerprint evidence this page documents structurally surfaces. Read the email- spoofing spoke alongside this DMARC-forensic-reports reference when interpreting per-message AFRF evidence- rows against the per-spoof- variant threat-model catalogue every per-message forensic-analyst the per- publisher AFRF stream this page documents consumes.
• SPF qualifiers explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-QUALIFIER-CHOICE-AS-LOAD- BEARING-DETERMINANT-OF-PER-MESSAGE- SPF-FAIL-VS-SOFTFAIL-VS-NEUTRAL- VERDICT-WHOSE-fo-FAILURE-OPTION- TRIGGER-CRITERION-PUBLICATION- DISCIPLINE-GATES-AFRF-EVIDENCE- CAPTURE companion to this DMARC forensic-reports reference. Where THIS page documents the per-publisher per-message AFRF (Authentication Failure Reporting Format, RFC 6591) forensic-evidence capture pipeline (the per-publisher ruf= publication discipline as AFRF delivery endpoint, the per-publisher fo=0|1|d|s failure- options tag publication as AFRF trigger criterion, the per-publisher rf=afrf|iodef report- format selector, the per-message AFRF Original-Mail-From + Header- From + Source-IP + DKIM-Signature + Authentication-Results forensic- evidence row composition), the SPF-qualifiers-explained spoke is the STRUCTURALLY-UPSTREAM per- publisher per-domain SPF mechanism- qualifier-choice-publication- discipline reference whose RFC 7208 §4.6.2 qualifier-prefix primitive determines the per-message spf= verdict-class consumed as the load- bearing trigger criterion the per- publisher fo= tag publication discipline gates the per-message AFRF capture pipeline on. The SPF-qualifier-vs-AFRF- capture coupling establishes four specific per-publisher qualifier- choice-to-AFRF-trigger dimensions: (i) per-publisher -all Fail choice produces spf=fail verdict that triggers AFRF capture under per- publisher fo=0 complete-alignment-fail trigger + per-publisher fo=1 underlying-mechanism-fail trigger + per-publisher fo=s SPF-only failure trigger — per-publisher -all terminal-mechanism choice produces per-message spf=fail at receiver- side SPF evaluation; per-publisher fo=0 publication discipline triggers AFRF capture whenever per-message DMARC- aligned-pass fails (which includes any per-message spf=fail combined with no rescue-DKIM-aligned-pass); per-publisher fo=1 publication discipline triggers AFRF capture for ANY per-message underlying-mechanism failure including isolated spf=fail; per- publisher fo=s publication discipline triggers AFRF capture specifically for per- message spf=fail events; (ii) per-publisher ~all SoftFail choice produces spf=softfail verdict that does NOT trigger AFRF capture under per-publisher fo=s SPF-only failure trigger discipline — per-publisher ~all terminal-mechanism choice produces per-message spf=softfail at receiver-side SPF evaluation; per- publisher fo=s publication discipline does NOT capture per-message AFRF for spf=softfail events (the trigger is gated on spf=fail specifically, not on spf=softfail) — per- publisher per-source-IP unauthorized-sender forensic- evidence pipeline silently loses per-source-IP per-message AFRF capture; per-publisher Phase-3- rollout-progression discipline typically migrates per-publisher ~all → -all to RESTORE per-publisher per- source-IP AFRF capture coverage; (iii) per-publisher ?all Neutral choice produces spf=neutral verdict that does NOT trigger AFRF capture under any per-publisher fo= discipline — per-publisher ?all terminal-mechanism choice produces per-message spf=neutral at receiver-side SPF evaluation; per- publisher AFRF forensic-evidence capture pipeline silently produces zero per-source-IP per-message AFRF rows for the per-publisher per-source-IP unauthorized-sender cohort; per-publisher forensic-investigation discipline loses per-message Original-Mail- From + Source-IP + Header-From evidence-row capture for spoofing- campaign root-cause attribution; (iv) per-publisher per- mechanism explicit-qualifier choice + per-publisher fo=d DKIM-only failure trigger discipline as per-publisher cross-mechanism per-message AFRF capture composition — per- publisher per-mechanism explicit- qualifier publication (-ip4: per-rogue- host deny-list + -include: per-formerly-authorised-ESP deny- list) combined with per-publisher fo=1 underlying- mechanism-fail trigger discipline captures per-mechanism-match per- message AFRF evidence at maximum per-source-IP per-mechanism per- message granularity for the per- publisher forensic-investigation pipeline. Read the SPF-qualifiers- explained spoke alongside this forensic-reports reference when per-publisher per-source-IP per- message AFRF capture coverage falls below per-publisher per- domain forensic-investigation coverage-floor expectation (the upstream per-publisher per-domain SPF qualifier-choice publication is a load-bearing root-cause class), and when planning per- publisher per-domain SPF qualifier- migration discipline whose downstream impact on per-publisher per-message AFRF forensic-evidence capture coverage THIS forensic- reports page documents observes.
• TLS-RPT record syntax — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-PER-FAILURE-CLASS- EVIDENCE-CAPTURE-PUBLICATION-PRIMITIVE- STRUCTURALLY-PARALLEL-TO-MESSAGE-LAYER- AFRF-FORENSIC-EVIDENCE-CAPTURE companion to this DMARC forensic- reports reference. Where THIS page documents the per-publisher per-domain DMARC RUF AFRF per-message forensic- evidence capture publication discipline (per-publisher per-domain ruf= mailbox publication, per-publisher per-domain fo= failure-options-tag publication, per-receiver per-message ARF/AFRF report-generation discipline per RFC 7489 §7.3 + RFC 6591 + RFC 5965, per-publisher per-message forensic-evidence capture-coverage decision discipline), the TLS-RPT- record-syntax spoke documents the per- publisher per-domain RFC 8460 §3 TLS-RPT DNS TXT-RR publication discipline whose per-publisher per- domain rua TLS-RPT JSON-report evidence-capture publication discipline is the STRUCTURALLY-PARALLEL at the transport-layer per-failure-class evidence-capture publication discipline complement to the per-publisher per- domain DMARC RUF AFRF forensic- evidence capture publication discipline THIS page documents at the message- layer at FOUR per-publisher per-domain cross-layer per-failure-class evidence-capture-publication-discipline coupling dimensions: (i) per- publisher per-domain failure-evidence- capture publication discipline parallel at message-layer-DMARC-AFRF vs transport-layer-TLS-RPT-JSON evidence- capture publication boundaries — per-publisher per-domain DMARC RUF AFRF per-message forensic-evidence capture publication discipline THIS page documents publishes the per- publisher per-domain ARF/AFRF per- message forensic-evidence-capture boundary at message-layer (per-message X-DMARC-Failure / per-message Original-Authentication- Results / per-message original- envelope-message-bytes AFRF capture per RFC 6591 §3.1); per-publisher per- domain TLS-RPT JSON-report evidence- capture publication discipline the TLS-RPT-record-syntax spoke documents publishes the per-publisher per-domain per-MX-host per-failure-class evidence- capture boundary at transport-layer (per-receiver per-day per-MX-host per- failure-class JSON evidence-row capture per RFC 8460 §4.3 failure-type catalogue: starttls-not- supported / certificate- host-mismatch / certificate- expired / certificate-not- trusted / dane-required- tlsa-invalid / sts-policy- invalid) — BOTH publication disciplines are STRUCTURALLY-IDENTICAL per-publisher per-domain per-failure- class evidence-capture publication primitive at distinct cross-layer evidence-capture publication boundaries; (ii) per-publisher per-domain rua/ruf vs rua mailbox publication-discipline parallel at message-layer-DMARC vs transport- layer-TLS-RPT publisher-controlled per-domain mailbox publication boundaries — per-publisher per-domain DMARC RUF publishes the per-publisher per-domain ruf=mailto:<ruf-mailbox> publisher-controlled mailbox the per- receiver per-message AFRF forensic- report stream lands at; per-publisher per-domain TLS-RPT publishes the per- publisher per-domain rua=mailto:<rua-mailbox> publisher-controlled mailbox the per- receiver per-day per-MX-host TLS-RPT JSON-report stream lands at — BOTH publication disciplines compose the per-publisher per-domain cross-layer publisher-controlled evidence-capture mailbox publication discipline at per-publisher per-domain message-layer (DMARC RUF AFRF) + per-publisher per- domain transport-layer (TLS-RPT JSON) STRUCTURALLY-IDENTICAL publication- primitive boundaries; (iii) per- publisher per-domain cross-layer attribution-pipeline composition consuming message-layer-DMARC-AFRF + transport-layer-TLS-RPT-JSON as load- bearing per-publisher per-domain cross- layer per-failure-class evidence-row attribution-stream — per- publisher per-domain incident-response attribution-pipeline consumes per- publisher per-domain DMARC RUF AFRF per-message message-layer forensic- evidence (per-message X-DMARC-Failure reason + per-message original-envelope-bytes + per-message Authentication-Results header captured at receiver-side ARF/ AFRF report-generation boundary the per-publisher per-domain fo= failure-options-tag publication discipline THIS page documents gates) AND per-publisher per- domain TLS-RPT JSON-report transport- layer evidence (per-publisher per-day per-MX-host per-failure-class JSON- evidence-row captured at receiver-side per-MX-host SMTP-STARTTLS-handshake- boundary the per-publisher per-domain TLS-RPT TXT-RR publication discipline the TLS-RPT-record-syntax spoke documents gates) as the CROSS-LAYER per-publisher per-domain per-failure- class evidence-row composed attribution-stream the per-publisher per-domain incident-response attribution-pipeline structurally consumes; (iv) per-publisher per-domain cross-layer publication- discipline-stack composition message- layer-DMARC-AFRF + transport-layer- TLS-RPT-JSON as load-bearing per- publisher per-domain complete-evidence- capture publication-coverage prerequisite — per-publisher per-domain complete-evidence-capture publication-coverage prerequisite composes per-publisher per-domain message-layer DMARC RUF AFRF publication discipline THIS page documents AND per-publisher per-domain transport-layer TLS-RPT publication discipline the TLS-RPT-record-syntax spoke documents the per-publisher per- domain publication of AS the per- publisher per-domain cross-layer- publication-discipline-stack composed complete-evidence-capture publication- coverage prerequisite the per- publisher per-domain incident-response + post-mortem + audit-trail per- publisher per-domain cross-layer complete-evidence-capture discipline requires. Read the TLS-RPT-record- syntax spoke alongside this DMARC forensic-reports reference when planning per-publisher per-domain cross-layer evidence-capture publication-discipline-stack composition whose per-publisher per- domain message-layer AFRF forensic- evidence capture the per-publisher per-domain fo= failure- options-tag publication discipline THIS page documents enables PAIRS with per- publisher per-domain transport-layer TLS-RPT JSON-evidence capture the per- publisher per-domain TLS-RPT TXT-RR publication discipline the TLS-RPT- record-syntax spoke documents the per- publisher per-domain publication of enables, and when investigating per- publisher per-domain incident-response cross-layer per-failure-class evidence-row attribution discipline whose per-publisher per-domain complete-evidence-capture publication- coverage prerequisite composes per- publisher per-domain message-layer AFRF forensic-evidence capture this page documents AND per-publisher per- domain transport-layer TLS-RPT JSON- evidence capture the TLS-RPT-record- syntax spoke documents the per- publisher per-domain publication of.
• DKIM failures explained — the RFC 6376 §3.9 DKIM-VERDICT-CLASS- TAXONOMY-AS-LOAD-BEARING-AFRF-FAILED-AUTH- RESULTS-PER-MESSAGE-EVIDENCE-ROW- CLASSIFICATION-VOCABULARY companion to this DMARC forensic-reports (RUF / AFRF) reference. Where THIS page documents the per-message AFRF feedback-report channel — the RFC 6591 multipart/report MIME envelope with the machine-readable message/feedback-report body- part publishing the per-message Auth-Failure-Type + DKIM-Failure + DKIM-Identity + DKIM-Domain + DKIM-Selector failure- attribution fields and the redacted message/rfc822-headers body- part — the DKIM-failures-explained spoke is the UPSTREAM RFC 6376 §3.9 receiver-side DKIM-verdict-class taxonomy whose four verdict keywords are the load-bearing per-message evidence-row classification vocabulary every AFRF DKIM-failure row THIS page documents structurally consumes at four DKIM-verdict-class-to-AFRF-evidence- row coupling dimensions: (i) per- message bodyhash-mismatch verdict surfaces as the AFRF DKIM-Failure: bodyhash / Auth-Failure-Type: dkim per-message evidence row publishing the signature bh= value alongside the receiver-recomputed body hash and the per-message canonicalization-choice (c=simple/simple vs c=relaxed/relaxed) needed for body-modification root-cause attribution at the per-forwarder-hop boundary — the per-message AFRF evidence-row enables operator-side body-modification-source attribution (mailing-list-manager footer- injection vs link-tracking URL substitution vs character-set renormalization) downstream of the per-message bodyhash- mismatch verdict-class THIS DKIM-failures spoke catalogues; (ii) per-message signature-mismatch verdict surfaces as the AFRF DKIM-Failure: signature per-message evidence row publishing the per-message DKIM-Signature header value and the per-selector public- key TXT-record-at-the-time-of-verification for stale-public-key-cache-during-key- rotation-cutover root-cause attribution at the per-selector-rotation-boundary — the per-message AFRF evidence-row enables operator-side per-selector-rotation- cutover timing-window-overlap attribution downstream of the per-message signature- mismatch verdict-class THIS DKIM-failures spoke catalogues; (iii) per-message permerror verdict surfaces as the AFRF DKIM-Failure: syntax or DKIM-Failure: key-revoked per-message evidence row publishing the per-message DKIM-Signature header (syntactically-invalid form) and the public-key TXT-record (empty p= revocation signal vs missing-entirely) for per-publisher per-selector publication- discipline-failure-class root-cause attribution — the per-message AFRF evidence-row enables operator-side per- publisher per-selector deliberate- revocation-vs-accidental-deletion attribution downstream of the per-message permerror verdict-class THIS DKIM-failures spoke catalogues; (iv) per-message temperror verdict surfaces as the AFRF DKIM-Failure: key-unavailable per-message evidence row publishing the per-receiver-side per-resolver-cohort transient TXT-record retrieval-failure evidence stream for per-receiver-cohort recursive-resolver-reliability root- cause attribution downstream of the per- message temperror verdict-class — the per-message AFRF evidence-row enables operator-side per-receiver-cohort recursive-resolver-infrastructure-quality attribution decoupled from per-publisher publication-discipline-fault attribution. Read the DKIM-failures-explained spoke ALONGSIDE this DMARC forensic-reports reference whenever an operator triaging a per-publisher per-message AFRF DKIM- Failure evidence-row needs the per-message DKIM verdict-class taxonomy whose four failure-class verdicts are the load-bearing per-message evidence-row classification vocabulary the AFRF channel surfaces per- message at the auth_results/dkim/result field attribution boundary.
• Phishing protection — the canonical outcomes-layer anti-phishing defense framework reference documenting how the per- message AFRF forensic-report evidence stream THIS page architectures (the RFC 7489 §7.3 ruf= forensic- report-uri-tag + RFC 6591 multipart/ report MIME envelope + per-publisher fo= failure-option-tag- gated per-message AFRF capture) IS the canonical per-incident forensic- evidence source the SIRT (Security Incident Response Team) and the per-publisher anti-phishing defense team consume during phishing- campaign incident-response. Each AFRF forensic-evidence row maps to a canonical phishing-variant evidence classification: (i) AFRF rows showing dkim=none + spf=fail + Identity-Alignment-failure with the offending message's Friendly-From forging an executive's name classify as the display-name-phishing variant, (ii) AFRF rows showing spf=pass + spf-aligned=false where the envelope MAIL FROM domain is a typo-squatted lookalike classify as the lookalike-domain-phishing variant, (iii) AFRF rows showing dkim=pass-with-aligned=false where the d=-tag belongs to a legitimate third-party ESP included in the publisher's SPF / DKIM stack classify as the compromised-third- party-ESP variant, and (iv) AFRF rows showing dkim=pass + spf=fail but ARC-chain-validated where the forwarder ARC sealed the originating-hop result classify as the ARC-validated-forwarder- phishing variant. Read the phishing-protection spoke ALONGSIDE this DMARC forensic-reports reference whenever the SIRT triaging an active phishing campaign needs the per-AFRF-row phishing-variant classification catalogue and the cross-protocol defense-layer coordination playbook the anti-phishing defense team coordinates downstream of the per-message AFRF forensic-evidence feed THIS page documents the receiver-side emission discipline of — the forensic-evidence feed is the per-incident evidence source, the phishing-protection spoke is the per-incident response playbook.
• SPF mechanisms explained — the RFC-7208-§5-PER-MECHANISM- EVALUATION-SEMANTIC-CATALOGUE-AS- LOAD-BEARING-PER-AFRF-ROW-SPF- EVIDENCE-DECODE-REFERENCE companion to this DMARC forensic-reports reference. Where THIS page documents the per-message AFRF forensic-evidence feed receiver- side emission discipline + per- AFRF-row phishing-variant classification catalogue, the spf_mechanisms_explained spoke documents the canonical RFC 7208 §5 per-mechanism evaluation- semantic catalogue the per-AFRF- row SPF-evidence decode the per- SIRT-analyst consumes structurally depends on at the per-mechanism token level. FOUR structurally- distinct PER-AFRF-ROW-SPF-EVIDENCE- DECODE-VS-PER-MECHANISM-EVALUATION- SEMANTIC-COUPLING dimensions the per-message AFRF forensic-evidence feed THIS page documents structurally requires the per- SIRT-analyst to decode at the per- mechanism RFC 7208 §5 evaluation- semantic level the spf_mechanisms_ explained spoke catalogues: (i) per-AFRF-row spf=fail per-source-IP per-envelope-MAIL-FROM-domain AS LOAD-BEARING-PER-AFRF-ROW-SPF- AUTHORIZATION-FAILURE-EVIDENCE- DECODE-VIA-PER-MECHANISM-CATALOGUE — every per-message AFRF row the per-receiver emits THIS page documents carries the per-row spf=fail verdict + per-source-IP + per-envelope-MAIL- FROM-domain triple that the per- SIRT-analyst decodes against the per-publisher SPF-record mechanism catalogue the spf_mechanisms_ explained spoke documents — the per-SIRT-analyst examines which per-mechanism token (e.g., missing include:, missing ip4: CIDR, missing mx hostname) the per- source-IP failed to satisfy to produce the per-row spf=fail verdict; (ii) per-AFRF-row spf=permerror per- publisher per-envelope-MAIL-FROM- domain AS LOAD-BEARING-PER-AFRF- ROW-PUBLISHER-SIDE-SPF-PUBLICATION- DEFECT-EVIDENCE-DECODE-VIA-PER- MECHANISM-§4.6.4-LOOKUP-CAP- OVERFLOW — the per-AFRF- row spf=permerror verdict per RFC 6591 / RFC 5965 AFRF format the per-SIRT-analyst decodes against the per-publisher SPF-record per-mechanism RFC 7208 §4.6.4 10-DNS-lookup-cap contribution the spf_mechanisms_ explained spoke catalogues — the per-SIRT-analyst counts the per- publisher per-mechanism include- cascade lookup-contribution to diagnose which per-mechanism token- addition tipped the per-publisher SPF-record over the 10-lookup cap; (iii) per-AFRF-row spf=pass-with- aligned=false AS LOAD-BEARING- PER-AFRF-ROW-SUBDOMAIN-IDENTIFIER- ALIGNMENT-DEFECT-EVIDENCE-DECODE- VIA-PER-MECHANISM-PER-SUBDOMAIN- SPF-PUBLICATION-PARTITIONING — the per-AFRF-row spf=pass + aligned=false verdict per-message + per-envelope-MAIL- FROM-subdomain + per-RFC-5322-From- organisational-domain triple the per-SIRT-analyst decodes against the per-publisher per-subdomain SPF-mechanism partitioning the spf_mechanisms_explained spoke catalogues — the per-SIRT-analyst examines which per-publisher per- subdomain SPF-record-publication produced the per-source-IP per- envelope-MAIL-FROM-subdomain authorization the per-RFC-5322- From-organisational-domain alignment-check rejected; (iv) per-AFRF-row spf=fail + RFC 8617 ARC-rescued AS LOAD-BEARING-PER- AFRF-ROW-PER-FORWARDER-HOP-SPF- BREAK-EVIDENCE-DECODE-VIA-PER- MECHANISM-PER-FORWARDER-SOURCE-IP- ABSENCE — the per-AFRF- row per-forwarder-hop spf=fail verdict + ARC-rescued-pass + ARC-chain- validated metadata triple the per-SIRT-analyst decodes against the per-publisher SPF-record per- mechanism CATALOGUE the spf_ mechanisms_explained spoke documents — the per-SIRT-analyst examines whether the per- forwarder-hop per-source-IP is absent from the per-publisher SPF- mechanism token stack (the canonical per-forwarder-hop SPF- break root cause when the per- forwarder is not enumerated in the per-publisher include:-cascade) the per-receiver ARC-rescue validation depends on knowing. Read the spf_mechanisms_explained spoke ALONGSIDE this DMARC forensic-reports reference when the per-SIRT-analyst decoding a per-AFRF-row SPF-evidence feed requires the per-mechanism RFC 7208 §5 evaluation-semantic catalogue — the spoke is the canonical RFC 7208 §5 PER- MECHANISM EVALUATION-SEMANTIC CATALOGUE REFERENCE the per- AFRF-row SPF-evidence decode infrastructure THIS page documents structurally depends on at the per-mechanism token- by-token decode level.
• DNS propagation timing — the PER-PUBLISHER-RUF-MAILBOX-PUBLICATION- DNS-PROPAGATION-AS-LOAD-BEARING-UPSTREAM- INFRASTRUCTURE-LAYER-PRECONDITION-FOR-PER- FAILURE-AFRF-AND-IODEF-FORENSIC-REPORT- DELIVERY companion reference. Where THIS page documents the per-publisher per-failure forensic-report stream (the per-message AFRF / IODEF payload format at RFC 6591 the receiver MTA emits to the publisher's RUF mailbox when DMARC evaluation produces a per-message fail verdict subject to the per-publisher fo= tag-value forensic-report-generation policy), the DNS-propagation spoke documents the per- publisher RUF-mailbox-publication and per- publisher cross-domain reporter-authorization publication's DNS-zone-authoritative-server- to-receiver-side-recursive-resolver propagation-completion timing whose per- receiver-resolver-cache TTL-bounded completion gates whether receiver MTAs can resolve the per-failure forensic-report mailbox destination, across four per- publisher-RUF-mailbox-publication-to-per- failure-AFRF-IODEF-delivery-coupling dimensions: (i) per-publisher- DMARC-TXT-record-ruf-tag-publication- propagation-as-upstream-precondition-for- per-failure-AFRF-IODEF-delivery — the receiver-MTA-side DMARC evaluator resolves the publisher's _dmarc.<publisher-domain> TXT record to retrieve the per-publisher ruf=mailto:<forensic-mailbox>@ <forensic-host> tag-value the per-failure AFRF / IODEF stream must be delivered to; receiver-MTA-side resolver- cache propagation-incompleteness during the per-publisher DMARC TXT record publication window produces zero per- failure AFRF / IODEF stream delivery at receivers whose recursive resolvers have not yet propagated the publisher's ruf= tag-value; (ii) per-publisher-cross-domain- reporter-authorization-record-propagation- as-upstream-precondition-for-cross-domain- RUF-delivery — when the per- publisher RUF mailbox is hosted on a DIFFERENT domain from the publisher's domain (e.g. ruf=mailto:forensic@ third-party-aggregator.example), the receiver-MTA-side DMARC evaluator ADDITIONALLY resolves the <publisher-domain>._report. _dmarc.<forensic-host> cross-domain third-party-authorization TXT record per RFC 7489 §7.1 to confirm the forensic-host has authorized receipt of the publisher's per-failure AFRF / IODEF stream; receiver-MTA-side resolver- cache propagation-incompleteness during the cross-domain authorization record's publication window produces zero per- failure forensic-report delivery to the third-party-aggregator forensic host until the cross-domain authorization record has fully propagated to the receiver-MTA's recursive resolver; (iii) per- publisher-RUF-mailbox-MX-record- propagation-as-upstream-precondition-for- per-failure-SMTP-delivery — the receiver-MTA-side SMTP delivery sequence for the per-failure AFRF / IODEF payload resolves the per-publisher forensic-host's MX record to identify the inbound MTA the per-failure forensic-report payload must be SMTP-delivered to; receiver-MTA-side resolver-cache propagation-incompleteness during the per-publisher forensic-host MX record's publication window produces per- failure SMTP delivery failures (no-such- domain bounces during the propagation window) at receiver MTAs whose recursive resolvers have not yet propagated the forensic-host MX publication; (iv) per-publisher-fo-tag-policy- change-and-ruf-tag-rotation-as-DNS- propagation-window-bounded-rollout- discipline — per-publisher policy changes that modify the fo= tag-value (the per- publisher forensic-report-generation policy controlling which per-failure classes generate AFRF reports) or rotate the ruf= tag-value (to a new per-publisher forensic mailbox destination) only take operational effect at receiver- MTA-side per-failure forensic-report- generation evaluation after the per- publisher DMARC TXT record's fo= / ruf= tag-value change has fully propagated to ALL receiver-MTA-side recursive resolvers worldwide; per-publisher operators sequencing per-policy-change rollouts MUST account for the per-receiver-MTA-resolver- cache TTL-bounded propagation-completion window to ensure per-failure forensic- report generation and delivery reflects the post-change publisher policy. Read this WITH the per-failure AFRF / IODEF payload reference when the per-publisher RUF mailbox publication sequence or cross- domain third-party-aggregator authorization publication reaches the operator's queue: THIS page documents the per-failure forensic-report payload format and the per-publisher fo= / ruf= tag-value publication discipline, the DNS-propagation spoke documents the INFRASTRUCTURE-LAYER propagation-timing discipline whose per-receiver-MTA-resolver- cache TTL-bounded completion gates whether per-failure forensic-report delivery from receivers can actually reach the per- publisher RUF mailbox destination THIS page documents.
• DKIM best practices — the PER-PUBLISHER-DKIM-SIGNING-DISCIPLINE- GREEN-STATE-BASELINE companion to this forensic-report per-failure payload reference. Where THIS page documents the per-failure-row RFC 6591 forensic-report payload format and the per-publisher fo= / ruf= tag-value publication discipline that causes per-failure forensic reports to be emitted, the DKIM-best-practices spoke is the PER-PUBLISHER-DKIM-SIGNING-DISCIPLINE-GREEN- STATE-BASELINE reference documenting the per-publisher per-selector RSA-2048-key + per- message DKIM-Signature-header + per-message body-hash + per-message canonicalization-mode + per-selector rotation-cadence rule-set whose continuous adherence is the load-bearing baseline the operator must reference when triaging the per-failure-row DKIM-failure evidence stream forensic reports surface. The FORENSIC-REPORT-VS-DKIM-BEST-PRACTICE cross-reference establishes FOUR structurally- distinct per-publisher per-domain per-failure- row DKIM-failure-attribution-coupling dimensions: (i) per-failure-row DKIM- Signature-header-missing failures attributable to legitimate-but-unsigned per-publisher egress mail (third-party-sender egress without per-publisher DKIM-signing configured) vs attacker-spoofed unsigned mail — the DKIM-best- practices spoke documents the per-publisher per-third-party-sender DKIM-signing-coverage rule that makes this distinction possible at the per-failure-row triage boundary; (ii) per-failure-row DKIM-cryptographic- verification-fail failures attributable to per- publisher per-selector key-rotation timing violations (the previous selector retired before its per-receiver per-resolver cache TTL expired) — the DKIM-best-practices spoke documents the per-selector retention-window rule (≥7 days post-rotation) the per-failure- row evidence stream this page documents directly surfaces violations of; (iii) per-failure-row DKIM-body-hash-mismatch failures attributable to per-publisher per- canonicalization-mode-choice (simple vs relaxed) vs per-MTA-relay body-rewriting middleboxes — the DKIM-best-practices spoke documents the per-publisher per-mail-class canonicalization-mode-selection rule (relaxed/ relaxed for marketing, simple/simple for transactional) the per-failure-row body-hash- mismatch evidence stream signals violations of; (iv) per-failure-row DKIM- Signature-header-with-non-aligned-d-tag failures attributable to per-publisher third- party-sender DKIM-re-signing-with-non-publisher- d-tag pattern — the DKIM-best-practices spoke documents the per-publisher per-third-party- sender DKIM-re-signing-with-publisher-d-tag rule (vs the per-third-party-sender per-own- d-tag pattern) the per-failure-row d-tag- alignment-failure evidence stream surfaces. Read the DKIM-best-practices spoke alongside this forensic-reports reference when designing a per-publisher per-domain forensic-report triage discipline so the operator's per- failure-row attribution decisions are grounded in the per-publisher per-selector per-message DKIM-signing-discipline baseline the per-row evidence stream the forensic-reports payload this page documents enumerates violations of.
• DKIM DNS record syntax (RFC 6376 §3.6.2) — the byte-level encoding-layer reference for the public-key TXT record at <selector>._domainkey.<domain>. When a forensic-report failed-DKIM- signature row cites dkim=permerror, a missing-key lookup, or a base64- payload corruption, this DNS-syntax reference covers what the published TXT record should contain: the v=DKIM1 prefix, the p= base64 public-key payload, the k= / h= / t= / s= tags, TXT-chunking past the 255-octet limit, and key revocation via empty p=. Use this reference to triage every published-key syntactic defect the per-failure-row forensic-reports payload enumerates — the encoding-layer contract whose violations the per-row evidence stream this forensic-reports page documents surfaces at receiver-side verification time.
• MTA-STS vs DANE — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-AUTHENTICATION- PUBLICATION-DISCIPLINE-CHOICE-AS-LOAD- BEARING-PEER-TRANSPORT-LAYER-FAILURE- CONTEXT companion to this DMARC- forensic-reports reference. Where THIS page documents the per-message DMARC forensic-failure-report payload schema (RFC 5965 ARF envelope, RFC 7489 §7.3 ruf-report per-message payload, per- message original-headers preservation, per-failure-row authentication-results evidence stream), the MTA-STS-vs-DANE spoke is the peer per-publisher per- domain transport-layer authentication- publication-discipline choice whose Web-PKI-anchored MTA-STS or DNSSEC- anchored DANE approach is the per- publisher per-domain transport-layer peer-authentication-publication-discipline context that per-publisher per-domain forensic-failure-report-stream investigators read alongside per- message ruf evidence streams at FOUR per-forensic-failure-investigation coupling dimensions: (i) per- publisher per-domain peer per-protocol- layer-failure-investigation-context parallelism — the per- message DMARC forensic-failure-report payload THIS page documents the schema of is the per-message application-layer authentication-and-alignment failure evidence stream, the per-publisher per- domain MTA-STS or DANE transport-layer peer-authentication-publication- discipline choice the MTA-STS-vs-DANE spoke documents is the per-publisher per-domain transport-layer peer- authentication context determining whether per-message forensic-failure rows can be correlated to per-receiver per-session per-MX hop transport-layer anomalies, and the per-publisher per- domain operator-side per-layer forensic-failure-investigation discipline reads BOTH per-protocol-layer evidence streams in parallel; (ii) per- publisher per-domain transport-layer- downgrade-as-per-message-DKIM-fail- upstream-cause forensic-attribution parallelism — the per- message DKIM-fail / DKIM-permerror forensic-failure-report rows THIS page documents the payload schema of can be upstream-caused by per-receiver per- session per-MX hop transport-layer downgrade-to-plaintext or certificate- validation failure that the per-publisher per-domain MTA-STS-or-DANE transport- layer peer-authentication-publication- discipline choice the MTA-STS-vs-DANE spoke documents the trust-root rationales of structurally defends against, and the per-publisher per-domain operator-side forensic-failure-investigation discipline attributes per-message DKIM-fail rows to per-session transport-layer-anomaly upstream causes BY READING per-publisher per-domain MTA-STS-or-DANE transport- layer peer-authentication-publication- discipline state; (iii) per- publisher per-domain cryptographic-trust- anchor-publication-layer choice as load- bearing forensic-failure-investigation framing-context — the per-publisher per-selector DKIM cryptographic-trust-anchor publication is the per-publisher per-domain application-layer trust-root the per- message forensic-failure-report payload THIS page documents reports against, the per-publisher per-domain MTA-STS Web- PKI-anchored or DANE DNSSEC-anchored trust-root choices the MTA-STS-vs-DANE spoke documents are the per-publisher per-domain transport-layer trust-roots per-publisher per-domain transport- layer-anomaly forensic-failure investigations frame their per-session per-MX hop evidence against, and the per-publisher per-domain operator-side per-layer cryptographic-trust-anchor- publication framing-context discipline is the load-bearing per-layer forensic- failure-investigation rhythm BOTH per- protocol-layer evidence streams share; (iv) per-publisher per-domain forensic-failure-stream cross-layer co-ingestion as load-bearing per- publisher per-domain operator-side complete forensic-investigation- capability posture — the per-publisher per-domain operator-side cross-layer forensic-investigation- capability that composes the per- message DMARC forensic-failure-report ruf payload THIS page documents at the application layer with the per-publisher per-domain MTA-STS-or-DANE transport- layer peer-authentication-publication- discipline forensic-context the MTA- STS-vs-DANE spoke documents is the per- publisher per-domain complete cross- layer authentication-and-encryption forensic-investigation-capability posture every per-publisher per-domain DMARC-deployment programme requires for complete cross-layer forensic- investigation coverage. Read THIS page when AUTHORING per-publisher per- domain DMARC forensic-failure-report ingestion discipline; read the MTA-STS- vs-DANE spoke when CO-INVESTIGATING per-publisher per-domain peer transport- layer authentication-publication- discipline forensic-context (Web-PKI- anchored MTA-STS or DNSSEC-anchored DANE) whose per-publisher per-domain per-session per-MX hop transport-layer- anomaly state is the load-bearing upstream-cause-candidate framing- context per-message DKIM-fail forensic-failure-row investigations structurally require.
• BIMI Verified Mark Certificates — the per-publisher per-domain BIMI VMC as downstream consumer of per-message DMARC- enforcement verdict companion to this RFC 6591 AFRF forensic-failure-report payload reference. Where THIS page documents the per-message authentication-failure-context AFRF MIME forensic-failure-report payload the receiver-side DMARC engine emits when a per-message DMARC verdict produces a fail-disposition, the BIMI-VMC spoke documents the downstream consumer of that DMARC verdict — the per-message BIMI logo- display gate at Yahoo / Gmail / Apple Mail / Fastmail SUPPRESSES the per-publisher per-domain logo render at any receiver that evaluates per-message DMARC-fail, and the per-message forensic-failure- report payload is the LOAD-BEARING per- message forensic evidence operators read to investigate the BIMI-display-suppression root cause. Four DMARC-FORENSIC-REPORT-VS- BIMI-VMC-DISPLAY-SUPPRESSION cross- correlation axes the BIMI-VMC spoke documents: (i) the per-message DMARC-fail-driven BIMI-display-suppression at the receiver is the operational consequence of the per-message DMARC verdict the forensic-failure-report payload captures — the per-message AFRF MIME payload's Original-Mail-From / Source-IP / Original-Envelope-Id / Identity-Alignment fields are the per-message forensic- evidence operators read to reconstruct the per-message DMARC-fail attribution chain that suppressed the BIMI logo display; (ii) the per- publisher per-domain BIMI display-rate KPI is structurally affected by the per- publisher per-domain DMARC-enforcement forensic-failure-report-row volume — a per-publisher per-day forensic-failure- report-row cliff against a stable baseline is the canonical per-publisher per-domain BIMI-display-rate degradation signal operators read alongside the per-publisher per-day per-receiver BIMI display-rate telemetry; (iii) the per-publisher per-domain VMC-issuance- readiness gate at Mark Verifying Authorities STRUCTURALLY REQUIRES sustained per- publisher per-domain DMARC-enforcement with minimal forensic-failure-report attribution against legitimate-publisher sending infrastructure — the per-message forensic-failure-report payload THIS page documents is the LOAD-BEARING evidence stream Mark Verifying Authorities and per-publisher operators co-investigate per-publisher per-domain VMC-issuance- readiness against; (iv) the per-publisher per-domain cross-protocol- pillar per-message investigation discipline couples the per-message forensic-failure- report payload with the per-publisher per- domain BIMI display-suppression telemetry — together they form the complete per- message DMARC-fail-driven BIMI-display- suppression root-cause investigation stream. Read THIS page when AUTHORING per-publisher per-domain DMARC forensic-failure-report ingestion discipline; read the BIMI-VMC spoke when INVESTIGATING per-publisher per-domain BIMI-display- suppression root cause whose receiver- side display gate consumes the per-message DMARC verdict THIS page's forensic-failure- report payload reconstructs.
• Email authentication glossary — the cluster-wide canonical entity-first DefinedTermSet vocabulary reference whose per-term DefinedTerm JSON-LD entries (RFC 5965 ARF feedback-type, RFC 7489 §7.3 ruf-failure-report-format, RFC 6591 Authentication-Failure-Report message- format, DKIM-Signature header verification, SPF policy-evaluation result, DMARC identifier-alignment failure-reason attribution, original-mail-from / original-rcpt-to / original-message envelope) are the per-protocol-concept vocabulary substrate the per-message DMARC forensic-failure-report (ruf) payload THIS page documents structurally consumes at the per-receiver-emission boundary. Where THIS page documents the RFC 7489 §7.3 + RFC 5965 ARF per-message DMARC forensic-failure- report payload format (the Feedback-Type: auth-failure envelope header, the Auth-Failure: dmarc attribution, the Delivery-Result: smtp disposition, the DKIM-Failure / SPF-Failure sub-attribution, the Authentication-Results raw verdict snapshot, the optional redacted- body original-message attachment), the email-authentication-glossary spoke is the DEFINED-TERM-DEFINITION reference documenting the canonical vocabulary substrate every forensic-report header- field structurally instantiates. Four FORENSIC-REPORT-PAYLOAD-TO-GLOSSARY- DEFINED-TERM coupling dimensions the glossary spoke documents: (i) per-report Auth-Failure: header field as per-message instantiation of the DMARC- failure-attribution DefinedTerm vocabulary — the per-report Auth-Failure: dmarc / Auth-Failure: dkim / Auth-Failure: spf / Auth-Failure: signature attribution-token vocabulary the forensic-report payload THIS page documents emits is the per-message instantiation of the DMARC-failure-class / DKIM-failure-class / SPF-failure-class DefinedTerm vocabulary the glossary catalogues; (ii) per-report Authentication-Results: header snapshot as per-message instantiation of the RFC-8601 Authentication-Results header field DefinedTerm vocabulary — the per-report Authentication-Results header snapshot the forensic-report payload embeds is the per-message instantiation of the RFC 8601 §2 ARID Authentication-Results identifier chain + the dmarc=pass / dmarc=fail + dkim=pass / dkim=fail + spf=pass / spf=fail verdict-token DefinedTerm vocabulary the glossary catalogues at the per-receiver evaluation boundary; (iii) per-report DKIM-Failure: / SPF-Failure: sub- attribution as per-message instantiation of the DKIM-verdict-class / SPF-result-class DefinedTerm vocabulary — the per-report DKIM-Failure: bodyhash / DKIM-Failure: signature / DKIM-Failure: revoked-key and SPF-Failure: mailfrom / SPF-Failure: helo sub-attribution vocabulary the forensic-report payload THIS page documents emits is the per-message instantiation of the RFC 6376 §3.9 DKIM-verdict-class taxonomy (bodyhash- mismatch / signature-mismatch / permerror / temperror) and the RFC 7208 §2.6 SPF-result-class taxonomy (none / neutral / pass / fail / softfail / temperror / permerror) DefinedTerm vocabulary the glossary catalogues; (iv) per-report Identity-Alignment: attribute as per-message instantiation of the identifier-alignment + organizational- domain + Public-Suffix-List DefinedTerm vocabulary — the per-report Identity-Alignment: dkim / Identity-Alignment: spf attribute the forensic-report payload embeds is the per-message instantiation of the identifier-alignment / strict-vs- relaxed-alignment-mode / DKIM d=-tag / SPF MAIL FROM identifier / RFC 5322 From: identifier DefinedTerm vocabulary the glossary catalogues. Read THIS page when AUTHORING the per-publisher per-domain DMARC forensic-failure-report ingestion discipline; read the email- authentication-glossary spoke when CO-AUTHORING the per-publisher per- domain canonical DefinedTermSet vocabulary substrate every forensic- report header-field the per-message payload THIS page documents structurally instantiates.
• DMARC for shared hosting — the per-shared-hosting-tenant per-custom- domain DMARC-DEPLOYMENT-TUTORIAL companion to this per-publisher per-domain RFC 6591 AFRF forensic-failure-report payload reference. Where THIS page documents the per-publisher per-domain DMARC forensic- report (ruf=) ingestion discipline — the RFC 6591 AFRF (Abuse Reporting Format) MIME multipart message/feedback-report payload byte-grammar, the per-message envelope-from / RFC 5321 MAIL FROM / RFC 5322 From identifier triple, the per-message Authentication-Results header chain, the per-message redacted- original-message envelope, the per- receiver per-publisher per-domain forensic-emitter authorisation discipline — the DMARC-for-shared-hosting spoke documents the structurally-paired per- shared-hosting-tenant per-custom-domain DMARC deployment tutorial whose ruf= publication is the FORENSIC-REPORT- INGESTION-PRE-CONDITION the per-publisher per-domain forensic-ingestion pipeline consumes. The composition operates through three per-shared-hosting-tenant per-custom-domain DMARC-and-forensic- report dependencies the per-publisher per-domain forensic-investigation discipline materially relies on: (i) per-shared-hosting-tenant per-custom- domain DMARC-record ruf= mailbox publication is the per-publisher per-domain forensic-report ingestion target the per-receiver per-publisher per- domain forensic-emitter dispatches per- message AFRF payloads against — without the per-shared-hosting-tenant per-custom- domain DMARC-record's ruf= publication, the per-publisher per- domain forensic-investigation discipline has NO per-message payload substrate to analyse; (ii) per-shared-hosting-tenant per-custom-domain DMARC ramp progression (p=none → p=quarantine → p=reject) gates which per- message DMARC-verdict-fail attributions the per-receiver per-publisher per-domain forensic-emitter actually dispatches per- message AFRF payloads against (per RFC 7489 §7.2 the per-receiver per-publisher per-domain forensic-emitter only emits forensic reports for per-message DMARC- verdict-fail outcomes under the per- publisher per-domain DMARC-policy applicable cohort); (iii) per-shared- hosting-tenant per-custom-domain operator-empowerment-ceiling (the spoke's load-bearing concept distinguishing Plesk / DirectAdmin / ISPConfig from cPanel / Workspace / M365 tiers) gates whether the per-shared-hosting-tenant operator has self-service DKIM-toggle access necessary to ramp DMARC past p=none and thereby populate the per-publisher per-domain forensic- report ingestion pipeline THIS page's forensic-investigation discipline consumes. Read THIS page when AUTHORING the per-publisher per-domain DMARC forensic-failure-report ingestion discipline; read the DMARC-for-shared- hosting spoke when AUTHORING the per- shared-hosting-tenant per-custom-domain DMARC deployment tutorial whose ruf= publication and p=quarantine-or- p=reject ramp-completion gates the per-publisher per-domain forensic-report ingestion pipeline THIS page's per-message payload analysis discipline materially depends on.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) and SPF flattening — the PER-PUBLISHER-PER-DOMAIN-SPF- LOOKUP-PERMERROR-AS-LOAD-BEARING- PUBLISHER-SIDE-ROOT-CAUSE-ATTRIBUTION- REFERENCE-FOR-FORENSIC-REPORT-SPF- PERMERROR-EVIDENCE-ROWS companion to THIS DMARC-forensic-reports operator-reference. Where THIS page documents the per-publisher per-domain RFC 7489 §7.3 + RFC 6591 + RFC 5965 AFRF / ARF per-message forensic-report MIME envelope (per-failure multipart/report Content-Type with per-failure message/feedback-report section, per-failure Auth-Failure + Authentication-Results + Source-IP + Original-Mail-From + Original-Rcpt-To + Reported-Domain + Delivery-Result evidence fields, per-failure full-message message/rfc822 or redacted text/rfc822-headers attachment) and the per-publisher per- domain RUF stream operational reception pipeline (per-publisher per-domain RUF consumption rate-limiting per receiver policy, per-receiver-organisation per- publisher per-domain forensic-report delivery cadence variation, per-receiver- organisation per-publisher per-domain per-message PII-redaction discipline variation), the SPF-lookup-limit spoke is the PER-PUBLISHER-PER-DOMAIN-SPF-PERMERROR- ROOT-CAUSE-ATTRIBUTION reference at FOUR per-permerror-forensic-evidence root-cause attribution dimensions: (i) per- publisher per-domain forensic-report Authentication-Results header SPF=permerror evidence-rows AS load-bearing per-message evidence-stream attributing to per- publisher per-domain RFC 7208 §4.6.4 10- DNS-lookup cap breach root cause — the per-publisher per-domain RUF per-failure message/feedback-report section the per-publisher per-domain forensic- report ingestion pipeline THIS page documents surfaces per-message SPF=permerror Authentication-Results header rows the per-publisher per-domain receiver-side SPF evaluator emitted; per-publisher per-domain operators consult the SPF-lookup-limit spoke's per-publisher per-domain include- cascade audit discipline (per-publisher per-domain SPF-lookup-count monitoring, per-publisher per-domain include-cascade- depth-audit cadence) for the per-publisher per-domain publisher-side root-cause attribution of each per-message SPF=permerror evidence-row surfaced in the forensic- report stream; (ii) per-publisher per-domain RUF per-message Reported-Domain AS load-bearing per-publisher per-domain SPF-include-cascade-attribution input — the per-publisher per-domain forensic-report per-message Reported-Domain field the per-message MIME-envelope parsing discipline THIS page documents identifies the per-publisher per-domain SPF record whose per-publisher per-domain include- cascade exhausted the RFC 7208 §4.6.4 10-DNS-lookup budget; per-publisher per- domain operators cross-reference the Reported-Domain against the per-publisher per-domain SPF-record body the SPF-lookup- limit spoke documents the audit-discipline of to attribute the per-message permerror to the per-publisher per-domain offending include: tail (per-publisher per-domain per-ESP include:_spf.sendgrid.net , per-publisher per-domain per-CRM include:_spf.salesforce.com, per-publisher per-domain per-marketing include:_spf.hubspot.com) at the per-publisher per-domain include- cascade-depth root-cause attribution boundary; (iii) per-publisher per- domain RUF Source-IP field AS load-bearing per-publisher per-domain forwarder-vs- publisher-vs-attacker SPF-permerror attribution discriminator — the per-publisher per-domain forensic- report per-failure Source-IP field the per-message MIME-envelope parsing discipline THIS page documents discriminates per- publisher per-domain forwarder-class SPF- permerror (per-mailing-list per-source-IP forwarder hops where the per-publisher per- domain SPF-include-cascade against the per-publisher per-domain Reported-Domain is per-source-IP traceable to a per-mailing- list per-source-IP forwarder per-source-IP identity) from per-publisher per-domain publisher-side SPF-permerror (per-publisher per-domain per-source-IP-pool egress where per-publisher per-domain SPF-include-cascade is per-source-IP attributable to per- publisher per-domain mainline ESP egress) from per-attacker per-source-IP spoofed- from-attacker-network SPF-permerror (per- attacker per-source-IP attempting per- publisher per-domain spoof where the per- publisher per-domain SPF-include-cascade is per-source-IP unrelated to per-publisher per-domain mainline outbound) at the per- publisher per-domain per-source-IP three- way attribution-discriminator boundary; the SPF-lookup-limit spoke documents the per-publisher per-domain SPF-include- cascade-audit discipline whose per- publisher per-domain include-list-membership check operators perform against the per- source-IP per-message attribution surfaced in the forensic-report stream; (iv) per-publisher per-domain SPF- flattening remediation pipeline AS load- bearing per-publisher per-domain operator- side remediation IS verifiable via per- publisher per-domain RUF SPF=permerror evidence-row-count baseline reduction — the per-publisher per-domain SPF- flattening remediation pipeline the SPF- lookup-limit spoke documents (per-publisher per-domain include-cascade-resolution to per-publisher per-domain ip4: / ip6: literal mechanisms via daily cron-driven refresh, per-publisher per-domain subdomain- delegation to split per-publisher per-mail- stream 10-lookup budget across per-publisher per-subdomain SPF records, per-publisher per-domain sender-consolidation to reduce per-publisher per-domain ESP-include cardinality) is verifiable per-publisher per-domain operationally via the per- publisher per-domain RUF SPF=permerror per-message evidence-row-count baseline reduction the per-publisher per-domain forensic-report ingestion pipeline THIS page documents the per-message MIME-envelope parsing discipline of; per-publisher per- domain operators measure per-publisher per- domain SPF-permerror-disposition rate before-and-after per-publisher per-domain SPF-flattening deployment as per-publisher per-domain remediation-effectiveness evidence at the per-publisher per-domain SPF-permerror-floor-reduction operational- validation boundary. Read THIS page when INGESTING the per-publisher per-domain forensic-report stream + parsing the per- message AFRF / ARF MIME-envelope evidence- rows; read the SPF-lookup-limit spoke when ATTRIBUTING per-message SPF=permerror Authentication-Results evidence-rows surfaced in the forensic-report stream to per-publisher per-domain RFC 7208 §4.6.4 10-DNS-lookup cap breach root causes whose per-publisher per-domain SPF-include- cascade-audit + per-publisher per-domain SPF-flattening remediation pipeline IS the load-bearing per-publisher per-domain publisher-side root-cause-attribution + remediation reference the per-publisher per-domain forensic-report ingestion pipeline THIS page documents materially depends on for SPF-permerror evidence-row attribution + remediation-effectiveness measurement.
• MTA-STS policy file byte-grammar — the per-publisher per-domain transport-layer per-failure-class evidence-capture publication discipline companion to this RUF AFRF forensic- report ingestion reference. Where THIS page documents the per-publisher per-domain RFC 7489 §7.3 RUF AFRF forensic-evidence capture publication discipline at the message-layer per- failing-message evidence-row boundary, the MTA- STS-policy-syntax spoke documents the per- publisher per-domain MTA-STS policy file byte- grammar publication discipline whose well-formed- ness is the upstream load-bearing input gating per-receiver per-day per-MX-host TLS-RPT JSON- aggregate-report failure-class emission. Four per-publisher per-domain cross-layer per-failure- class evidence-capture publication-discipline coupling dimensions matter at the per-receiver per-day per-publisher per-domain per-failure- class evidence-capture boundary: (i) per- publisher per-domain DUAL evidence-capture publication channel — per-publisher per-domain RUF AFRF forensic-evidence emission consumes per- message DMARC-fail trigger criterion, per- publisher per-domain TLS-RPT JSON-aggregate- report failure-class emission consumes per-day per-MX-host STARTTLS-handshake-failure-class trigger criterion; (ii) per-publisher per-domain DUAL byte-grammar publication discipline — per- publisher RUF rua/ruf address byte-grammar at _dmarc.<domain> TXT-RR is per- receiver-side ingestion-pipeline-load-bearing, per-publisher MTA-STS policy file byte-grammar at /.well-known/mta-sts.txt is per- receiving-MTA-side enforcement-load-bearing; (iii) per-publisher per-domain DUAL failure-class attribution — per-publisher AFRF per-failure Feedback-Type / Auth-Failure / Source-IP / DKIM-Domain / DKIM-Selector evidence-row vs per- publisher TLS-RPT per-failure result-type enum (starttls-not-supported / certificate-host- mismatch / certificate-expired / sts-policy- invalid / sts-policy-fetch-error / validation- failure); (iv) per-publisher per-domain DUAL composite publication-and-observability portfolio — per-publisher message-layer DMARC RUF AFRF + per-publisher transport-layer MTA-STS policy + per-publisher transport-layer TLS-RPT JSON publication form the composite per-publisher per- domain cross-protocol-layer per-failure-class evidence-capture publication-discipline portfolio every per-publisher per-domain forensic-and- transport-observability deployment THIS page documents materially coordinates publication discipline against.
• DKIM for Microsoft 365
• SPF mechanism comparison (include: vs ip4: vs a: vs mx:) — (i) per-publisher per-domain envelope-MAIL-FROM-layer SPF TXT-RR mechanism-class publication discipline (include: recursive-include- chain vs ip4: literal-CIDR vs a: A-RR-resolved-IP vs mx: MX-RR-resolved-host) IS the load-bearing upstream-input determining per-message spf=pass / spf=softfail / spf=fail / spf=permerror / spf=temperror verdict per RFC 7208 §4.6 whose per-message composite-DMARC-fail-verdict per RFC 7489 §3.1 triggers the per-publisher per-domain RUF AFRF forensic-report emission cadence THIS page documents; (ii) per-publisher per- domain include: recursive- chain depth IS the load-bearing producer of the spf=permerror verdict- class (per RFC 7208 §4.6.4 ten-DNS- lookup budget exhaustion) whose per- message AFRF Auth-Failure / Delivery- Result evidence-row per RFC 6591 §3 attributes the per-mechanism-class root- cause back to the upstream include-chain depth at the per-publisher per-domain envelope-MAIL-FROM-layer publication discipline; (iii) per-publisher per- domain ip4: CIDR literal- mismatch vs a: / mx: DNS-resolution-staleness produces STRUCTURALLY DISTINCT per-message spf=fail verdict-class evidence at the AFRF Source-IP attribution row — ip4: literal-mismatch surfaces as per-source- IP unauthorised vs a: / mx: stale-DNS-resolution surfaces as per-source-IP unauthorised- BUT-was-authorised-at-publication-time, the per-mechanism-class distinction being the AFRF forensic-evidence root-cause attribution the per-publisher per-domain incident-responder operationally consumes; and (iv) per-publisher per-domain SPF terminal-qualifier (-all vs ~all vs ?all) as load-bearing companion-input to per- mechanism-class publication-decision — the per-message AFRF Auth-Failure evidence-row records BOTH the per- mechanism-class match-outcome AND the per-terminal-qualifier per-receiver enforcement-mode, the combined per- message evidence-row enabling the per- publisher per-domain forensic-evidence reviewer to distinguish per-message true-positive direct-domain spoof attack- evidence from per-message false-positive legitimate-sender publication-discipline- drift root-cause. Read the SPF-mechanism- comparison spoke when investigating per- message AFRF forensic-evidence rows whose spf=fail / spf=permerror verdict-class root-cause requires per- publisher per-domain envelope-MAIL-FROM- layer mechanism-class publication- discipline-drift attribution.
• DKIM for Google Workspace
• SPF DNS record syntax
• SPF for Microsoft 365
• Microsoft SNDS + JMRP monitoring — JMRP complaints arrive in the same ARF (RFC 5965) envelope as DMARC failure reports — but carry an Outlook.com Junk-click reputation signal instead of an authentication verdict, and have been redacted (no complainant address, no message body) since 2026-06.

14. Ingest your forensic reports now

DMARC Analyzer's ingestion pipeline at includes/ForensicReportParser.php parses AFRF MIME messages (RFC 6591), plain feedback-report bodies, and the arf+xml XML variant. Structured fields persist to the dmarc_forensic_reports table, deduplicated by (arrival_date, source_ip, reported_domain, original_mail_from), and surface in the dashboard with per-report drill-downs. Aggregate (RUA) reports flow through includes/DmarcParser.php (RFC 7489 §7.2) into dmarc_records.

Sign up — Free plan Check my ruf= destination