DMARC Analyzer

TL;DR

• DMARC aggregate reports (also called RUA reports after the rua= tag that publishes the destination) are daily XML documents receivers send back to domain owners summarising how mail claiming to be from the domain was processed. Defined in RFC 7489 §7.2.
• The report is grouped by source IP with per-group message counts, SPF / DKIM authentication results, alignment outcome, and the disposition (none, quarantine, or reject) the receiver applied.
• The XML root is <feedback> with three child element types: <report_metadata> (sender identity + reporting window), <policy_published> (the DMARC record the receiver saw), and one or more <record> elements (one per source-IP / authentication-result combination).
• Delivery: email attachment, gzip-compressed XML (.xml.gz) or ZIP, filename convention receiver!sender-domain!begin-ts!end-ts.xml.gz. Reports arrive at the mailbox(es) listed in the rua= tag.
• Cadence: one report per receiver-sender pair per day by default (ri=86400). Major receivers deliver daily, typically 04:00-09:00 UTC. Smaller receivers vary or send no reports at all.
• RUF (forensic) reports — defined in RFC 7489 §7.3, addressed by ruf= — are per-message failure reports including header content. Privacy implications mean most major receivers no longer send RUF.
• DMARC Analyzer ingests aggregate reports via includes/DmarcParser.php (XML, ZIP, and GZ formats per RFC 7489 §7.2.1.1) and forensic reports via includes/ForensicReportParser.php (RFC 6591 ARF envelope).

1. What is a DMARC aggregate report?

A DMARC aggregate report — also called a RUA report after the rua= tag in the DMARC record that publishes the destination address — is an XML document that a receiving mail provider sends back to the domain owner once per day, summarising every message claiming to be from the domain that the receiver processed during the reporting window. The format is defined in RFC 7489 §7.2 and the underlying XSD schema is published in RFC 7489 Appendix C.

The data model: receivers group every observed message by source IP and authentication outcome. Each group becomes one <record> element in the report, with a message count and the underlying SPF / DKIM evaluation results. The result is a per-day, per-IP snapshot of every authentication path your domain was associated with — legitimate or not. That snapshot is the primary diagnostic stream for any DMARC deployment.

Aggregate reports are the artefact every DMARC rollout depends on:

• Phase 1 (Discovery) of the rollout — see DMARC policy rollout — uses aggregate reports to inventory every legitimate sender that currently sends mail claiming to be from your domain.
• Phase 2 (Alignment fix-up) uses aggregate reports to verify each remediation landed (a misaligned SaaS sender flips to aligned in the next day's report).
• Phase 3-5 (Enforcement) uses aggregate reports to confirm no unexpected legitimate flows are being blocked.
• Post-rollout steady state keeps aggregate-report monitoring forever as the detection mechanism for newly misaligned senders (new SaaS deployments, new partner integrations).

The mechanism is asymmetric: the receiver knows everything (every message, every SPF / DKIM result, every disposition) but the sender knows only what the receiver chooses to report. Without aggregate reports, the sender is blind. With aggregate reports, the sender has near-complete visibility into the full sending estate — including senders the sender did not know existed.

2. The RUA mechanism: how reports get generated and delivered

1. The sender publishes a DMARC TXT record at _dmarc.example.com with a rua= tag listing one or more report destination URIs (typically mailto: addresses). rua=mailto:dmarc-reports@example.com is the minimum.
2. The receiver consumes the DMARC record on every inbound message claiming the sender's domain in From:. For each such message the receiver records the source IP, the SPF / DKIM outcomes, and the disposition applied.
3. At the end of the reporting interval (default 86400 seconds, the ri= tag overrides), the receiver groups the day's observations by source-IP / auth-result combinations and emits one XML report per sender-receiver pair.
4. The report is gzip-compressed (or sometimes ZIP-compressed) and emailed as an attachment to every mailto: address in rua=. Filename convention: receiver!sender-domain!begin-ts!end-ts.xml.gz where the timestamps are Unix epoch seconds.
5. The sender ingests the XML (typically via tooling like includes/DmarcParser.php), decodes the records, and surfaces the per-sender authentication breakdown.

Two RFC-defined nuances matter for the mechanism:

• Cross-domain authorisation (RFC 7489 §7.1): the rua mailbox does not have to be on the same domain as the DMARC-protected sender. To accept reports for example.com at reports.aggregator.example, the aggregator must publish a TXT record at example.com._report._dmarc.aggregator.example containing v=DMARC1. Without the authorisation record, receivers SHOULD NOT send reports across domain boundaries.
• Report-size limits (RFC 7489 §7.2.1): receivers MAY truncate oversized reports. A report with thousands of source-IP groups may exceed the receiver's email-attachment size limit, in which case the receiver typically emits the most-active groups and drops the long tail. High-volume senders should expect truncation and plan around it.

3. The aggregate-report XML schema

The keystone reference for this page. RFC 7489 Appendix C defines the full XSD; the table below summarises the elements every parser encounters in real-world reports.

The XML root is <feedback> rather than the more obvious <report> for historical reasons — DMARC reports were originally modelled on RFC 5965 Abuse Reporting Format (ARF), which uses feedback-type in its email-headers form. The aggregate- report XML kept the feedback root.

4. A worked aggregate-report example

A minimal aggregate report from Google for the sending domain example.com during a 24-hour window:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>12345678901234567890</report_id>
    <date_range>
      <begin>1716163200</begin>
      <end>1716249600</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>quarantine</p>
    <sp>quarantine</sp>
    <pct>100</pct>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.220.41</source_ip>
      <count>1547</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
      <envelope_from>bounce.example.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <selector>mail</selector>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>bounce.example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>

  <record>
    <row>
      <source_ip>192.0.2.200</source_ip>
      <count>23</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <spf>
        <domain>attacker.example</domain>
        <result>none</result>
      </spf>
    </auth_results>
  </record>
</feedback>

Reading the report:

• The reporter is Google (org_name), the window covers 2024-05-20 00:00 UTC to 2024-05-21 00:00 UTC (date_range in Unix epoch), and the published DMARC record at the time was v=DMARC1; p=quarantine; sp=quarantine; adkim=r; aspf=r; pct=100.
• Record 1 covers 1,547 messages from 209.85.220.41. Both DKIM and SPF aligned and passed — legitimate mail through a properly- configured custom-bounce domain (bounce.example.com) and custom DKIM (selector mail). Disposition is none (delivered normally) because DMARC passed.
• Record 2 covers 23 messages from 192.0.2.200 claiming to be from example.com. SPF produced no result (result=none for attacker.example — the wrong domain), no DKIM signature was present, alignment failed for both, and the receiver quarantined per the published p=quarantine policy. This is the spoofing-attempt signal the rollout is designed to surface.

The count field is critical — it is the per-day message count for that source-IP / auth-result combination. A legitimate sender shows up as one record with a high count; a spoofing source shows up as one record with a low count (or as several records with low counts from a botnet).

5. Report cadence and delivery

Aggregate reports are delivered as email attachments to every mailto: address in the DMARC record's rua= tag. The attachment is compressed XML — typically .xml.gz from major receivers, occasionally .zip from smaller receivers.

Filename convention

receiver-domain!sender-domain!begin-timestamp!end-timestamp!unique-id.xml.gz

Example:
google.com!example.com!1716163200!1716249600.xml.gz

The exclamation-mark-separated fields encode the receiver, the sender domain, the reporting-window epoch timestamps, and an optional unique identifier. Not every receiver includes the unique-id suffix.

Reporting interval

The default interval is 86400 seconds (one report per sender-receiver pair per day). RFC 7489 §6.6.5 defines the ri= tag for requesting different intervals (ri=3600 for hourly), but most receivers honour only the default and ignore custom ri= values.

Delivery timing

Major receivers deliver reports at consistent times. Typical schedule:

• Google — daily, 04:00-06:00 UTC.
• Microsoft / Outlook — daily, 06:00-08:00 UTC.
• Yahoo — daily, 07:00-09:00 UTC.
• Comcast, AOL, Mail.ru — daily, varies.

A new DMARC record takes one full reporting interval to surface in aggregate reports — receivers cached the old record for the TTL duration plus the reporting-interval window. Expect 24-48 hours after publishing or changing a record before the next report reflects the change.

6. Reading aggregate reports operationally

Aggregate reports are dense, repetitive, and tedious to read by hand — a typical daily report from a single major receiver is several hundred lines of XML covering a dozen source-IP groups. Tooling is essential. DMARC Analyzer's ingestion pipeline at includes/DmarcParser.php parses XML, ZIP, and GZ formats, deduplicates by report_id + org_name, persists per-record rows to the dmarc_records table, and surfaces per-sender / per-IP / per-day aggregations in the dashboard.

The diagnostic questions reports answer:

• Who is sending mail claiming to be from my domain? Group records by auth_results/spf/domain and auth_results/dkim/domain; every distinct domain is a candidate sending source. Legitimate senders use recognised domains (your bounce domain, SaaS DKIM domains you provisioned); unknown domains are either shadow IT or spoofing.
• Which legitimate senders are misaligned? Filter to records where the source IP belongs to a known legitimate sender but policy_evaluated/dkim or policy_evaluated/spf is fail. These are your rollout-blocking remediations.
• What is the apex pass rate? Sum count across all records where both alignment outcomes are pass; divide by total count. A healthy apex sits at 99%+ aligned; a rollout-ready apex sits at 99.5%+.
• What is the current disposition distribution? Group by policy_evaluated/disposition. At p=none, every disposition is none by definition; at p=quarantine, you see a mix of none (passing mail) and quarantine (failing mail); at p=reject, you see none + reject.
• Are receivers seeing the policy I published? Check policy_published/p matches the intended value. Mismatch indicates a propagation delay or a typo in the DNS record.

7. Forensic (RUF) reports

DMARC defines a second report type — the forensic or failure report (also called RUF after the ruf= tag). RUF reports are per-message rather than per-day, triggered by individual DMARC-failing messages, and they include header content from the failing message (From:, To:, Subject, sometimes a body excerpt).

RUF is specified in RFC 7489 §7.3 and uses the RFC 6591 Abuse Reporting Format (ARF) envelope rather than the XML schema. A RUF report is an email message with a multipart structure: a machine-readable message/feedback-report part plus a message/rfc822 part containing the actual failing message headers and body (or excerpt).

Privacy implications: RUF reports include actual From: addresses and subject lines from failing messages — which means user PII from every legitimate alignment failure is forwarded to the rua mailbox. Mailing-list forwarding, SaaS sender misconfiguration, and forwarding chains all generate forensic reports that include user data. The privacy posture led the major consumer mailbox providers to stop sending RUF reports entirely:

• Google — never sent RUF.
• Microsoft / Outlook — does not send RUF.
• Yahoo — does not send RUF.
• Comcast, AOL — do not send RUF.

Some smaller receivers and enterprise gateways still send RUF reports. DMARC Analyzer ingests them via includes/ForensicReportParser.php (RFC 6591 ARF envelope, RFC 7489 §7.3 forensic-content format), persists to dmarc_forensic_reports, and surfaces them alongside aggregate-report data in the dashboard. The fo= tag in the DMARC record controls forensic report generation (fo=0 default, fo=1 any auth failure, fo=d DKIM failure, fo=s SPF failure) but only influences the receivers that actually emit RUF.

Practical guidance: publish ruf=mailto:dmarc-forensic@example.com if your mail-flow can handle the privacy implications, but treat any RUF data as a bonus signal. The major-receiver RUA stream is sufficient to drive a rollout; RUF is supplemental, not primary.

For a deeper dive into RUF including the full AFRF MIME schema, the message/feedback-report key-value fields (Feedback-Type, Reported-Domain, Auth-Failure, Source-IP, Original-Mail-From, Identity-Alignment), a worked AFRF example, GDPR / CCPA implications, and operational reading patterns, see the dedicated DMARC forensic (RUF) reports guide.

8. RUA mailbox best practices

1. Host the rua mailbox at a different domain. Reports for example.com delivered to rua@example.com create a chicken-and-egg problem: if example.com fails DMARC during rollout, its own reports may fail to deliver. Use rua@reports.example-corp.com or a dedicated reports domain.
2. Disable spam filtering for the rua mailbox. Aggregate reports arrive from dozens of receiver domains with attachments and varied DKIM signatures — exactly the pattern that triggers spam filters. Allowlist or skip spam filtering for the rua mailbox.
3. Use a parser, not a human. Aggregate reports are dense XML — the diagnostic value comes from per-sender aggregation across many reports. Pipe the mailbox into DMARC Analyzer (includes/DmarcParser.php) or another reporting tool.
4. Deduplicate by report_id + org_name. Receivers occasionally resend reports after delivery failures; without deduplication the same observations are counted twice.
5. Publish cross-domain authorisation if needed. If the rua mailbox is at a different domain, publish example.com._report._dmarc.aggregator.example with v=DMARC1 so receivers will send across domain boundaries (RFC 7489 §7.1).
6. Retain reports for at least 13 months. Aggregate-report history is the only artefact that documents what the sending estate looked like at a given point in time. Year-on-year comparisons require at least one full year of retained reports plus margin.
7. Monitor for missing receivers. If you typically receive daily reports from Google, Microsoft, and Yahoo and one stops arriving, something changed — either at the receiver, in the DNS propagation of your record, or in your rua mailbox delivery path.
8. Alert on new spoofing IPs. The same record-pattern (failing DMARC, high count, unfamiliar source IP) is the spoofing signal. Alert on it.
9. Treat aggregate reports as confidential. Reports list every IP that sent mail claiming to be from your domain — including internal infrastructure IPs. The report itself does not contain user PII but the IP inventory is sensitive for an attacker mapping your sending infrastructure.
10. Never disable RUA after p=reject. Aggregate-report monitoring is the detection mechanism for newly misaligned senders. Drop rua= and you lose visibility into every future configuration drift.

9. Common aggregate-report mistakes

1. Publishing rua= without a plan for the reports. Reports arrive in volume from day one. A mailbox that fills up and bounces means receivers stop sending and you lose the diagnostic stream.
2. Hosting the rua mailbox on the same domain DMARC is protecting. Chicken-and-egg delivery problem during rollout. Host at a different domain or publish cross-domain authorisation.
3. Treating each report in isolation. A single report from one receiver covers a fraction of total volume — the diagnostic value comes from aggregating across receivers across days. Use tooling.
4. Confusing auth_results with policy_evaluated. The auth_results block is the raw SPF / DKIM verdict before alignment is checked; the policy_evaluated block is the final DMARC outcome after alignment. SPF can pass in auth_results and fail in policy_evaluated if the SPF-authorised domain does not align with the From: header.
5. Setting ri= too short. The default is 86400 seconds (daily). Lower values are explicitly allowed by RFC 7489 §6.6.5 but most receivers ignore them — and the few that honour them produce far more report email than is operationally useful.
6. Publishing rua= at a non-existent mailbox. Receivers attempt delivery, bounce, and may stop retrying. A non-existent rua destination is silently zero reports.
7. Forgetting to deduplicate. Some receivers resend reports after transient delivery failures. Without report_id + org_name deduplication, a resent report is double-counted.
8. Treating RUF as primary. RUF reports are sparse (major receivers don't send them) and carry user-PII privacy risk. The diagnostic-stream commitment is RUA; treat RUF as a bonus.
9. Disabling rua after rollout. Aggregate-report monitoring is the post-rollout detection mechanism. Drop rua= and a new misaligned sender is invisible until it produces a support ticket.
10. Mistaking spoofing volume for a problem to fix. A report showing 10,000 DMARC-failing messages from a Russian IP block is not a misalignment — it is the spoofing being blocked by your DMARC record. The win is that the receiver applied the policy.

10. Aggregate-report troubleshooting

Reports are not arriving at the rua mailbox

Verify the mailbox accepts mail and is not over-quota. Test by sending a message from a different domain. If the rua mailbox is on the same DMARC-protected domain, publish cross-domain authorisation at example.com._report._dmarc.aggregator.example or move the mailbox to a separate domain. Confirm the DMARC record has propagated — receivers typically need 24-48 hours after a record change before reports reflect the new configuration.

Reports are arriving but the parser rejects the XML

Some receivers produce malformed XML (missing required elements, encoding glitches, broken gzip streams). A robust parser (such as includes/DmarcParser.php) handles common defects: optional elements, both draft and RFC 7489 formats, and disables external entity loading for XXE defence-in-depth. Inspect the raw attachment in a text editor before assuming a parser bug.

The report shows unfamiliar source IPs

The full list: legitimate senders you forgot, SaaS senders sending without custom-domain DKIM, partners forwarding mail (envelope-rewrite from the forwarder's IP), and spoofing sources. Look up each unfamiliar IP using reverse DNS (dig -x) and WHOIS. Legitimate SaaS senders resolve to recognisable provider names (SendGrid, Mailgun, Marketo); spoofing sources typically resolve to consumer-ISP or hosting-provider ranges.

Disposition is none even though p=reject is published

Check policy_published/p in the report — if it shows none, the receiver was still seeing the previous record at the time of the reporting window (TTL propagation delay). If it shows reject but disposition is none, the record passed DMARC and the receiver delivered normally (the none disposition is the DMARC-passing-mail label, not the p=none policy label).

Volume is dropping week over week

Usually benign — a legitimate seasonal cycle, a one-off marketing campaign that ended, or a SaaS sender that was retired. Compare against historical baselines (the 13-month retention recommendation exists for exactly this purpose). A sharp drop across all senders may indicate an outbound mail-flow problem.

The report references a domain I do not own

If policy_published/domain is a domain you do not control, something is wrong with your DMARC record publication. Check that the TXT record at _dmarc.your-domain is actually serving the intended content using domain_checker.php or dig +short TXT _dmarc.your-domain.

Reports stopped from one receiver

If a specific major receiver stops sending reports, the receiver may have observed a delivery failure to the rua mailbox and stopped retrying. Some receivers re-enable after a quiet period; others require a manual unblock request through the receiver's postmaster interface.

11. Frequently Asked Questions

What is a DMARC aggregate report?

A DMARC aggregate report (also called a RUA report, from the rua= tag that publishes the destination address) is an XML document that a receiving mail provider sends back to the domain owner once per day. It summarises every message claiming to be from the domain that the receiver processed during the reporting window, grouped by sending IP, with per-group SPF / DKIM authentication results, alignment outcome, and the disposition the receiver applied. RFC 7489 §7.2 defines the format. Aggregate reports are the primary diagnostic stream for any DMARC deployment.

What is the difference between RUA and RUF reports?

RUA reports (aggregate) are daily XML summaries describing message volumes and authentication outcomes per sending IP — defined in RFC 7489 §7.2, addressed via the rua= tag in the DMARC record. RUF reports (forensic, or failure reports) are per-message reports describing individual DMARC-failing messages, including header content — defined in RFC 7489 §7.3, addressed via the ruf= tag. RUF reports include sensitive content (the From: header, subject line, sometimes the message body) and have meaningful privacy implications, which is why most major receivers stopped sending RUF entirely. RUA is universal; RUF is patchy at best.

How often are aggregate reports sent?

The default reporting interval is 86400 seconds (one daily report per sender-receiver pair). The ri= tag in the DMARC record allows a domain owner to request a different interval (e.g. ri=3600 for hourly), but most receivers honour only the daily default. Major receivers (Google, Microsoft, Yahoo, Comcast, AOL, Mail.ru) send reports daily at consistent times, typically between 04:00 and 09:00 UTC. Smaller receivers may send less frequently or not at all.

How are aggregate reports delivered?

Reports are delivered as email attachments to the mailbox(es) listed in the rua= tag. The attachment is a gzip-compressed XML file (.xml.gz) — or sometimes a ZIP-compressed XML — named by convention: receiver!sender-domain!begin-timestamp!end-timestamp.xml.gz. The email itself follows RFC 5322 with a body referencing the attached report. Domain owners parse the XML using tooling like DMARC Analyzer's ingestion pipeline at includes/DmarcParser.php (RFC 7489 §7.2.1.1 specifies the email-attachment delivery mechanism).

What are the main elements of the aggregate report XML?

A DMARC aggregate report has three top-level child elements under the root <feedback>: <report_metadata> (the receiver organisation name, the report_id, the date_range begin/end timestamps, optional extra_contact_info), <policy_published> (the DMARC record as the receiver saw it during the reporting window — domain, adkim, aspf, p, sp, pct, fo), and one or more <record> elements (one per source-IP / authentication-outcome combination). Each <record> contains a <row> (source_ip, count, policy_evaluated/ disposition + dkim/spf evaluation), an <identifiers> block (header_from, envelope_from, envelope_to), and an <auth_results> block (the underlying SPF and DKIM results).

Why are aggregate reports not arriving at my rua mailbox?

Most common causes: (1) The rua= mailbox is on the same domain that DMARC protects and the mailbox itself fails DMARC — receivers reject reports they cannot deliver, creating a chicken-and-egg loop. Host the rua mailbox at a different domain, or publish a cross-domain authorisation TXT record per RFC 7489 §7.1 at your-domain._report._dmarc.rua-mailbox-domain. (2) The mailbox mail-flow is filtering reports as spam — DMARC report mail comes from many varied receiver domains with attachments, which spam filters often flag. Allowlist or unfilter the rua= mailbox. (3) A new DMARC record hasn't propagated to receivers yet — receivers cache DMARC records for the duration of the TTL, so changes take up to TTL seconds plus one reporting interval (typically 24-48 hours) to surface in reports.

Do all receivers send DMARC aggregate reports?

No. The major consumer-mailbox providers (Google, Microsoft / Outlook, Yahoo, AOL, Comcast, Mail.ru, Tencent QQ, Rambler) reliably send aggregate reports. Smaller corporate gateways and ISP mailers vary — many enforce DMARC at delivery time without ever sending reports back. RFC 7489 §7.2 specifies SHOULD-strength language for report generation rather than MUST, and receivers exercise that discretion. The major-receiver coverage is sufficient to power a useful rollout (those receivers handle the vast majority of consumer mail volume) but expect gaps for B2B and niche-receiver traffic.

12. Related guides

• DMARC policy rollout — the operational migration from p=none to p=reject. Aggregate reports are the data this rollout depends on.
• DMARC policy modes — p=none vs p=quarantine vs p=reject — the head-to-head COMPARISON of the three DMARC enforcement values. Read this to decode the <disposition> element in every aggregate-report record: each value (none / quarantine / reject) maps 1:1 to the published p= tag that produced it.
• DMARC alignment explained — identifier alignment (the SPF/DKIM-domain-matches-From: rule) that produces the policy_evaluated/dkim and policy_evaluated/spf values in every aggregate-report record.
• DMARC myths and misconceptions debunked (the RUA-EVIDENCE-DEBUNKS-MYTHS companion to this aggregate-report data-stream reference) — the RUA-EVIDENCE-DEBUNKS-MYTHS companion documenting the 18 common DMARC myths that the per-record evidence in the aggregate-report stream THIS page documents empirically refutes. Where THIS page documents the AGGREGATE-REPORT DATA-STREAM REFERENCE (the <feedback> XML schema, per-record block fields, daily cadence, RUA mailbox delivery, policy_evaluated / auth_results decode), the myths-and- misconceptions spoke documents the 18 defender-side mental-model ERRORS that the aggregate-report data REPEATEDLY DEBUNKS in operator practice: (i) "DMARC blocks all phishing" — the aggregate report shows display-name spoofing and lookalike- domain attacks with policy_evaluated=pass for the attacker's authored domain (alignment is evaluated against the From: address domain not the display-name phrase), (ii) "p=none does nothing" — the aggregate report immediately surfaces the sender-inventory empirical evidence (every legitimate-sender IP space, every third- party SaaS sender's vendor IPs, every forwarder hop) without changing receiver disposition, (iii) "p=quarantine and p=reject are different policies" — the aggregate report <disposition> field shows they are the SAME policy with DIFFERENT receiver-side enforcement outcomes that the published p= tag selects, (iv) "I published p=reject so I'm protected" — the aggregate report shows ARC-aware forwarders mark aligned=true on the upstream-DMARC-passing message, but ARC-unaware forwarders break SPF AND DKIM at the second hop producing legitimate-mail false positives, (v) "DMARC is just for outbound protection" — the aggregate report empirically demonstrates DMARC ALSO protects inbound deliverability by producing the third-party-sender inventory that catches misconfigured legitimate senders BEFORE the policy advances to p=reject. Read THIS page WITH the myths-and-misconceptions spoke when an operator reading their first aggregate report draws a wrong conclusion from a single row pattern: the spoke documents the 18 most common misreadings of the data this page catalogues, each tied back to RFC 7489 evidence and per-row aggregate-report decode patterns. Where THIS page documents the DATA STREAM, the myths- and-misconceptions spoke documents the 18 DEFENDER-MINDSET ERRORS that misinterpret the data stream — and the evidence-based correction for each.
• Why SPF alone is insufficient — the DMARC-MONITORING-EXPOSES-SPF-INSUFFICIENCY raison-d'être companion this aggregate-report data empirically demonstrates — the DMARC-MONITORING-EXPOSES-SPF-INSUFFICIENCY companion documenting WHY DMARC monitoring (the aggregate-report stream this entire page documents) was necessary in the first place, and what concrete SPF gaps the aggregate-report per-record block empirically exposes that an SPF-only deployment cannot. Where this page documents the WHAT and HOW of the aggregate reporting pipeline (the <feedback> XML schema, the per-record block fields, the daily cadence, the RUA mailbox delivery, the policy_evaluated / auth_results decode), the why-SPF-alone-is- insufficient spoke documents the WHY — the five SPF-only-deployment gaps that DMARC aggregate-report monitoring (and only DMARC aggregate-report monitoring) makes visible: (i) the From:-header spoofing gap (SPF authenticates the envelope MAIL FROM domain, not the From: header — operators see spf=pass + aligned=false on every spoofed message in the aggregate report data), (ii) the forwarding gap (SPF breaks on the second SMTP hop when forwarders rewrite the envelope but receivers see the original — operators see spf=pass at forwarder.example + aligned=false), (iii) the mailing-list gap (mailing-list expansion rewrites both envelope AND From: — same signature pattern), (iv) the third-party- sender gap (CRM/marketing platforms send From: customer-domain.com via vendor infrastructure — aggregate reports surface the vendor IP space as legitimate-but- unaligned), (v) the DKIM-replay-from- cooperating-spammer gap (SPF cannot detect Body-modification-style replay attacks). Read the why-SPF-alone-is-insufficient spoke when an operator reading their first aggregate report asks "why am I deploying DMARC at all if I already have SPF" — the spoke is the authoritative answer using the aggregate- report stream this page documents as the empirical evidence.
• DKIM alignment with DMARC (the DKIM-half operator-reference for aggregate-report dkim=pass + aligned=false rows) — the DKIM-HALF-ONLY operator reference for the AGGREGATE-REPORT-ROW interpretation question that operators reach this page with most often: "I see auth_results/dkim/result=pass in the per-record block but policy_evaluated/dkim=fail on the same row — which alignment- failure pattern is biting me". Where the DMARC-alignment-explained spoke above documents the JOINT SPF+DKIM alignment evaluation algorithm (the pass-if-either OR rule across the two underlying authentication mechanisms), the DKIM-alignment-with-DMARC spoke is the focused decision-tree reference for the DKIM half: the DKIM-Signature d=-tag extraction (whose value is recorded verbatim as auth_results/dkim/domain in every aggregate-report record), the From: header organizational-domain extraction, the adkim=r relaxed (organizational-domain match via Public Suffix List) vs adkim=s strict (FQDN equality) policy knob and the receiver- side decision tree, and the THREE CANONICAL alignment-failure provenance patterns each mode produces — every observed dkim=pass + aligned=false row in the aggregate-report stream traces back to one of these three: (i) the M365 onmicrosoft.com gotcha (d=<tenant>.onmicrosoft.com defaults), (ii) the Google Workspace gappssmtp.com gotcha (d=<domain>.gappssmtp.com defaults), (iii) ESP shared-domain signing patterns at SendGrid / Mailchimp / Postmark / Mandrill / Amazon SES. Read this DKIM-alignment spoke when the per-row auth_results/dkim/domain value (the verbatim d=-tag) does not match the policy_evaluated/dkim=pass expectation — the spoke catalogues the mapping from observed d=-tag pattern back to the corresponding signing-infrastructure misconfiguration and the per-platform remediation procedure (Defender DKIM blade for M365, Workspace Admin Console DKIM for Workspace, ESP-specific CNAME-delegated authenticated-domain DKIM for the ESP-shared-domain pattern).
• DKIM failure verdicts explained — the per-verdict decode reference for the auth_results/dkim/result XML element this page documents — the CONSUMER-SIDE XML-ELEMENT-DECODE companion to this aggregate-report reference. Where this page documents the per-XML-element semantics the receiver embeds in every aggregate report (including the <auth_results><dkim><result> sub-element that carries one of seven RFC 8601 §2.7.1 verdict keywords on every signed message), the DKIM-failure-verdicts spoke is the canonical operator translation from raw verdict keyword to remediation step. Concretely, every row in the aggregate- report stream this page is the consumer reference for surfaces ONE of the seven verdict values in the auth_results/dkim/result field: none (no DKIM-Signature header at all on the inbound message — signing infrastructure not deployed at the sender), neutral (verifier deliberately abstained per RFC 8601 §2.7.1 (3)), pass (cryptographically valid — DMARC pass-or-fail then determined by the alignment check the <policy_evaluated><dkim> sibling element records), fail (signature cryptographically invalid — one of the 12+ canonical sub-cause patterns catalogued on the verdict-decode spoke), policy (verifier-side local- policy rejection per RFC 8601 §2.7.1 (6) — weak-key / body-length-limit / wallclock- skew / disallowed-canonicalization rejections), temperror (DNS resolver transient failure on the selector lookup — typically self-resolves within one report interval), permerror (key parsing or DKIM-Signature header syntax permanently broken — operator-side fix required). Read the verdict-decode spoke when the per-row auth_results/dkim/result value on the aggregate-report dashboard surfaces a non-pass verdict that needs triage — the spoke is the canonical operator translation from "raw verdict keyword in the XML stream this page documents" to "what action does each verdict class require".
• DKIM troubleshooting — the RUA-DKIM-FAILURE-ROW-AS-CANONICAL- ENTRY-POINT-TO-PER-SELECTOR-PER-SENDING- INFRA-OPERATIONAL-DIAGNOSTIC-PLAYBOOK companion to this aggregate-report reference. Where this page documents the per-XML-element semantics of the <auth_results><dkim> sub-tree (the result, domain, selector and human_result fields the receiver populates per signature attempt) and the adjacent dkim-failures-explained spoke is the per-VERDICT decode reference, the dkim-troubleshooting spoke is the per-MAIL-STREAM OPERATIONAL DIAGNOSTIC PLAYBOOK operators execute once a dkim=fail row surfaces in their RUA dashboard: the canonical seven-step diagnostic decision tree (1: confirm the selector still resolves to a public TXT record at the time of the failure window — a rotated / retired / accidentally-deleted selector is the single most common root cause; 2: confirm the published TXT record's p= base64 key still matches the signer's current private key — split- brain DNS / cache-poisoning / partial replication failures produce mismatches; 3: confirm the message hasn't been modified in transit — body-hash mismatch from mailing-list footer-appender, antivirus body-injection scanner, gateway-rewriting forwarder; 4: confirm the DKIM-Signature header's signed-headers h= tag includes only headers present at signing time — Outlook's Conversation-Index header insertion at outbound is a recurring source of signed-but-absent-on-receive header mismatch; 5: confirm the canonicalization algorithm declared in the DKIM-Signature c= tag matches what the signer actually performed — simple vs relaxed canonicalization implementation bugs at the signer-side produce deterministic verification failure; 6: confirm the timestamp t= and expiration x= tags leave the message within the signature's validity window — clock-drift between signer and verifier or expired-signature replay attempts surface here; 7: confirm the per-receiver DKIM verifier implementation isn't itself broken — Microsoft 365 EOP's historical body-hash-canonicalization-edge-case bugs, Gmail's RFC8551-strict-vs-lenient- mode toggles, and Yahoo's DKIM-signature- header-folding handling have all produced dkim=fail rows on legitimately- signed mail in specific time windows the receiver later corrected via silent verifier patches), the per-control-panel / per-platform / per-ESP DKIM authoring UI quirks the dkim-troubleshooting spoke enumerates as the canonical signer-side forensic-instrumentation surface, and the iterative narrow-by-pivoting RUA analysis pattern operators run (pivot by source_ip-pool to find the mis-signing infrastructure, pivot by selector to find the rotated-but-still-in-use key, pivot by header_from to find the un-coordinated-third-party-sender) that the RUA aggregate-report XML schema documented on this page makes operationally tractable. The dkim- troubleshooting spoke is the diagnostic-action layer where dkim-failures-explained is the verdict- decode layer — both consume the aggregate-report XML stream this page documents.
• DMARC record tags explained — every tag in the DMARC DNS record including rua, ruf, ri, fo.
• DMARC multi-domain strategy — interpreting aggregate-report streams across the domain portfolio — the portfolio-level interpretation reference for aggregate-report streams spanning multiple sender domains. Where THIS page documents the per-XML-element semantics (<policy_published>, <record>, <auth_results>, <policy_evaluated>, <disposition>, <count>, <source_ip>) the receiver embeds in every aggregate report, the multi-domain-strategy spoke documents how the operator AGGREGATES those per-XML records across a portfolio of N sender domains into a coherent posture: per-domain abuse-volume baseline (which brand attracts the most impersonation traffic), the organizational-domain vs. subdomain volume split that informs whether sp= should diverge from p=, the per-domain alignment-rate dashboards that drive the strict-alignment decision per-domain rather than portfolio-wide, the parked-domain zero-legitimate-volume invariant that aggregate reports continuously re-prove against attacker fabrication attempts, and the cross-domain spoof-pattern correlation when the same attacker infrastructure (shared <source_ip> blocks) targets multiple brands in the portfolio simultaneously.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT THREAT-DISCOVERY companion to this aggregate-report consumer reference. Where THIS page documents the per-XML-element semantics the receiver embeds in every aggregate report, the BEC spoke documents the FINANCIAL-IMPACT threat scenarios operators investigate IN the aggregate- report stream this page is the consumer reference for. Specific operator-detection patterns the BEC spoke catalogues that surface as recognisable shapes in this page's data structure: (a) CEO-fraud spike — sudden volume of <header_from> matching a known executive identity from <source_ip> NOT on the operator's SPF authorised list with policy_evaluated/disposition=quarantine or reject; (b) invoice-fraud pattern — finance-department subdomain traffic from off-list IPs with policy_evaluated/spf=fail AND policy_evaluated/dkim=fail; (c) cousin-domain attacker reconnaissance — aggregate-report streams from DEPENDENT-RFC-9091-related cousin- domain attempts that trigger no aggregate- report rows on the cousin domain BUT do appear in the operator's monitoring of finance / executive mailboxes' inbound reception statistics; (d) hijacked-vendor VEC — DMARC-pass mail from legitimate vendor domains the operator's policy does NOT directly enforce, requiring out-of-band recipient-side detection rather than aggregate-report-driven signal. The BEC spoke documents the TRIAGE PROCEDURE for each pattern using the aggregate-report fields documented on this page — critical operator knowledge when reading the data stream this page references because the aggregate-report's <disposition> values map directly to whether an identified BEC attempt was BLOCKED at the receiver vs DELIVERED-and-flagged vs DELIVERED-clean. Read the BEC spoke when triaging unfamiliar source_ip rows on the aggregate-report dashboard that match a finance / executive header_from identity — the threat-pattern catalogue is the canonical operator playbook for the financial-impact threat-scenario side of the consumer-side aggregate- report monitoring workflow this page documents.
• Phishing protection — the AGGREGATE-REPORT-STREAM-AS- PHISHING-CAMPAIGN-DETECTION-AND-DEFENSE- EFFECTIVENESS-OBSERVABILITY companion to this aggregate-report consumer-side reference. Where THIS page documents the per-XML-element semantics the receiver embeds in every aggregate report (<policy_published>, <record>, <auth_results>, <policy_evaluated>, <disposition>, <count>, <source_ip>, <header_from>), the phishing-protection spoke is the DEFENSE-PROGRAM-EFFECTIVENESS-MEASUREMENT companion that turns the aggregate-report data stream THIS page is the consumer-side reference for into the empirical per-attack-pattern observability layer a phishing-defense program is measured against, across FOUR per-row classifier dimensions: (i) direct-domain spoofing detection via policy_evaluated/spf=fail + policy_evaluated/dkim=fail + policy_evaluated/disposition= reject on the publisher's exact domain — the aggregate-report row with the publisher's exact <header_from> but attacker source_ip and full-stack authentication failure is the canonical direct-domain phishing-attempt signature; the phishing-protection spoke documents the per-source_ip triage playbook that distinguishes attacker-volume-spike from misconfigured-legitimate-sender-spike using the per-row volume + source_ip- reputation + temporal-pattern evidence THIS page's data structure surfaces; (ii) lookalike-cousin-domain reconnaissance gap — RFC 9091 dependent- domain attack signatures that produce NO aggregate-report rows on the cousin domain — when the attacker registers examp1e.com or example-corp.com for phishing, the cousin-domain publishes no DMARC policy so no aggregate-report stream reaches the operator at all; the phishing-protection spoke documents the OUT-OF-BAND detection signals the operator must rely on (out-of-band recipient-side reports, brand-protection SaaS tools, DNS-monitoring lookalike- domain registration alerts) when the aggregate-report stream THIS page is the consumer-side reference for produces ZERO rows precisely because the attacker chose the cousin-domain attack vector to evade DMARC observability; (iii) display-name-impersonation detection via aggregate-report policy_evaluated=pass rows on the attacker's authored domain — the display-name field is NOT part of the DMARC alignment evaluation (alignment evaluates against the From-header DOMAIN, not the display-name phrase), so a display-name spoof from "CEO Name" <random@attacker- domain.com> produces a policy_evaluated=pass row on the attacker-domain's aggregate-report stream (which the publisher never sees); the phishing-protection spoke documents the MUA-layer + receiver-side-filter defense layer that catches this attack class which the aggregate-report stream THIS page documents the consumer-side schema of structurally CANNOT detect; (iv) DMARC-policy-bypass campaign observability via the policy_evaluated/disposition + <count> + source_ip + temporal-pattern composite signature in the aggregate-report stream this page documents — the phishing- protection spoke documents the canonical operator playbook for reading the per-row disposition-vs-policy-mode composite signature in the aggregate- report stream: a sustained disposition=quarantine at policy_published/p=reject signals receiver-side override (the receiver-side reputation engine rate-limited the attacker before enforcing the publisher's p=reject policy); a sustained disposition=none at policy_published/pct=<100 signals the attacker landed in the pct-sampling exemption cohort the publisher's gradual-enforcement-ramp produced. Read the phishing-protection spoke when the aggregate-report dashboard surfaces a per-day source_ip- clustered anomaly on the publisher's exact <header_from> domain and the operator needs the canonical defense-program-effectiveness playbook that maps the per-row evidence in the aggregate-report stream this page documents to the per-attack- pattern defense-layer decision (DMARC policy advancement, SPF qualifier tightening, DKIM key rotation, MUA- layer banner-warning configuration, out-of-band lookalike-domain monitoring) the phishing-protection spoke catalogues.
• DMARC reporting pipeline — RUA / RUF ingestion, parsing, and delivery — the end-to-end transport-and-ingestion path that turns a published rua= mailbox into the per-day aggregate XML this page documents. Aggregate reports do not arrive at the operator by magic: every report on this page traverses the receiver-side report-generator → DNS resolution of the rua= URI → MIME-attached send via SMTP / HTTPS → operator-side inbound mailbox / webhook → MIME-part extraction → gzip-or-zip decompression → XML schema-validation → row-by-row ingestion into the analyzer's dmarc_records table. Read the pipeline page when aggregate reports stop arriving (typical causes: the publishing domain's rua= mailbox is bouncing, the inbound mail-server's TLS / DKIM verification is rejecting the report, the operator's IMAP-fetcher credentials have rotated, the gzip decompression failed on a malformed report, or the XML schema validation rejected a non-conformant aggregate document).
• MX records explained — the RUA-MAILBOX-DOMAIN-MX-RR-AS-DELIVERY- DESTINATION companion to this aggregate- report consumer-side reference, and the DNS-RR-LAYER prerequisite that gates every aggregate-report row this page documents from ever arriving in the analyzer's dmarc_records table at all. Where THIS page documents how operators READ the per-day XML aggregate-report stream (per-XML-element semantics <policy_published>, <record>, <auth_results>, <policy_evaluated>), the mx-records spoke documents the RFC 1035 §3.3.9 MX resource-record syntax for the DNS-RR class that determines WHERE on the public Internet every receiver-side aggregate-report MTA worldwide ATTEMPTS to deliver the per-day XML report it generates for the publishing domain. Concretely: when the publisher publishes _dmarc.example.com IN TXT "v=DMARC1; p=none; rua=mailto:reports@ dmarc-mailbox.example.org", every Gmail / Yahoo / Microsoft / Apple / Comcast / etc. receiver-side aggregator that generates a per-day aggregate XML for example.com resolves the dmarc-mailbox.example.org portion of the RUA URI through the DNS-RR resolution chain: (a) MX RRset lookup on dmarc-mailbox.example.org (per RFC 5321 §5.1 — the mx-records spoke documents the byte-grammar of the 16-bit priority + target-FQDN MX RR format), (b) for each MX RR in priority-ascending order, A/AAAA lookup on the MX-target FQDN, (c) SMTP delivery attempt to the resolved IP. A missing, mis-prioritised, NXDOMAIN, or misconfigured MX RR on the RUA-mailbox domain causes EVERY receiver-side aggregate-report delivery worldwide to SILENTLY FAIL at the SMTP-DNS-resolution hop — producing the operationally catastrophic "aggregate reports stopped arriving" state the dmarc-reporting- pipeline spoke listed above documents the DOWNSTREAM-INGESTION-LAYER troubleshooting loop for. The "null MX" pattern (example.com IN MX 0 . per RFC 7505) declaring a domain accepts no mail is a SPECIFIC RUA-mailbox-domain ANTI-PATTERN that operators occasionally misconfigure on a marketing-domain publisher's RUA mailbox-domain, causing the same silent-aggregate-report-loss outcome. Pair this page (the aggregate- report consumer-side reference) with the mx-records spoke (the DNS-RR-LAYER delivery-destination prerequisite) when diagnosing the "aggregate reports stopped arriving" failure state — the mx-records spoke is the AUTHORITATIVE DNS-RR-CLASS reference for the receiver-side MTA resolution chain every aggregate report traverses BEFORE reaching the operator's ingestion mailbox.
• DMARC deployment checklist — the PRE-FLIGHT GREEN-PATH operator quick-reference whose successful execution is the OPERATIONAL PRE-CONDITION for every aggregate-report row this page documents the consumer-side schema of. Where THIS page documents how operators READ the per-day XML aggregate-report stream (per-XML-element semantics <policy_published>, <record>, <auth_results>, <policy_evaluated>, the operator drilldown procedure for each row), the deployment-checklist spoke documents the PRE-FLIGHT phases that operationally REACHED the steady-state aggregate-report stream this page is the consumer-side reference for: (a) Phase 0 sender-inventory enumeration (the authoritative roster of WHICH sender domains will surface in the per-row <header_from> + <source_ip> data documented on this page); (b) Phase 1 SPF + DKIM prerequisite verification (the cryptographic-authentication baseline whose presence is the PRE-CONDITION for non-fail outcomes in the auth_results/spf and auth_results/dkim XML blocks documented on this page); (c) Phase 2 DMARC record publication with p=none + a rua= mailbox that ACTIVATES the receiver-side per-day report-generator (without which the aggregate-report stream documented on this page never reaches the operator); (d) Phase 3 baseline instrumentation (the operator-side ingestion pipeline that turns inbound rua-MIME-attached XML into the dashboard data this page is the consumer-side reference for); (e) Phase 4 post-publication monitoring cadence (the operational discipline ensuring the aggregate-report stream documented on this page CONTINUES arriving cleanly). Read the deployment-checklist spoke when a brand-new operator arrives at this aggregate-report consumer-side reference WITHOUT a prior aggregate-report stream already flowing — the checklist is the FIRST-STEP entry point that activates the upstream data-source this page documents the consumer-side reading of.
• DMARC explained — the central DMARC primer covering the broader DMARC ecosystem, mailing-list / forwarding interactions, and the cluster context.
• SPF explained — Sender Policy Framework (RFC 7208). The auth_results/spf block in every aggregate-report record carries an SPF result.
• SPF include: vs ip4: vs a: vs mx: decision tree — the RUA-AGGREGATE-EVIDENCE- RETROACTIVELY-IDENTIFIES-WHICH-IP- PROVIDING-MECHANISM-MATCHED companion to this DMARC aggregate-report consumer-side reference. Where THIS page documents the per-day per-domain aggregate-report ingestion infrastructure the operator consumes to extract per-message auth_results/spf/ result evidence rows from receiver-emitted RUA payloads, the include-vs-ip4-vs-a-vs-mx decision-tree spoke is the UPSTREAM-MECHANISM-CHOICE companion documenting the FOUR structurally-distinct SPF IP-providing mechanism choices the operator authored at the SPF-record-publishing boundary, whose per-message evaluation outcomes the aggregate-report stream THIS page consumes retroactively attribute one of: (i) ip4: / ip6: — direct CIDR enumeration produced a pass row whose source_ip XML element matches a CIDR block authored explicitly in the SPF record (the operator can pin the matched mechanism by intersecting the report's source_ip against the published ip4:/ ip6: blocks); (ii) include: — delegated authorization to a third- party SaaS sender produced a pass row whose source_ip falls inside the transitively-included SaaS-domain SPF record (the operator cannot pin the matched mechanism from the report alone — they must intersect against the recursively- expanded SPF tree at evaluation time, treating the include: chain as the implicit attribution); (iii) a:<name> / bare a — name-based IP authorization via A/AAAA-record lookup produced a pass row whose source_ip matches the A/AAAA-resolved set of the named host AT REPORT-EVALUATION-TIME (which may differ from AT-RECEIVER-EVALUATION-TIME if the operator inspects the report retrospectively and the A/AAAA record has renumbered since); (iv) mx:<name> / bare mx — MX- server-based IP authorization produced a pass row whose source_ip matches the MX-resolved-to-A/AAAA set, doubling the retrospective- attribution ambiguity (the operator must reconstruct BOTH the MX targets AND their A/AAAA bindings at evaluation time to confirm the matched mechanism). For every auth_results/spf/result = pass row in the aggregate report stream THIS page documents, the operator's PER-MESSAGE MECHANISM-ATTRIBUTION investigation (which is the prerequisite for any SPF-mechanism-rationalisation or SaaS-sender-add/remove decision) relies on the include-vs-ip4-vs-a- vs-mx decision-tree spoke as the UPSTREAM-CHOICE-REFERENCE documenting how each of the four mechanisms participates in the evaluation. Read the four-IP- providing-mechanism decision-tree spoke alongside this aggregate- report consumer-side reference when the operator faces the feedback-loop question "given a spike in pass rows from a new source_ip range we did not authorise, which mechanism (if any) accidentally admitted them" or the retrospective question "given a spike in fail rows from a SaaS- partner range we DID authorise, which mechanism (include: chain depth, a:-vs-mx: rotation, ip4: CIDR drift) explains the evaluation breakage that this aggregate-report stream surfaces".
• SPF mechanisms explained — the per-mechanism decode reference for interpreting WHICH mechanism matched (or didn't) on every auth_results/spf/result row — the SPF-MECHANISM-INTERPRETATION companion to this DMARC aggregate-report consumer-side reference. Where THIS page documents the RFC 7489 §A.1 auth_result_type XML schema and the six allowed result values (none / pass / fail / softfail / neutral / temperror / permerror), the mechanisms-explained spoke documents the eight SPF mechanisms (RFC 7208 §5 — all, include, a, mx, ip4, ip6, ptr, exists) and the check-host algorithm whose per-mechanism evaluation produces the spf= verdict in every aggregate-report row this page documents the schema of. Read the mechanisms spoke when triaging a high-volume spf=fail source_ip in your aggregate-report stream and you need the per-mechanism reference to determine whether the failure is (a) a missing include: of a legitimate downstream sender's macro-expanded SPF record, (b) a bare a mechanism over-pointing at a web-server apex, (c) an overly-narrow ip4: range omitting a recently-added cloud IP block, or (d) an mx mechanism that worked when MX was self- hosted but broke after switching to a cloud-MX provider whose MX targets are not in the outbound IP pool — each of which surfaces as the same spf=fail verdict in the aggregate-report XML this page documents.
• SPF forwarding issues (the second-hop break) — the FORWARDER-MEDIATED-SPF-BREAK companion to this DMARC aggregate-report consumer-side reference. Where THIS page documents the auth_results/spf/result XML schema and the row-level fields a DMARC analyst reads, the forwarding- issues spoke documents the canonical forwarder-second-hop SPF break (RFC 7208 §10.2) that produces a high-volume category of spf=fail rows from LEGITIMATE downstream senders: when an aliased recipient forwards a message through a corporate mailing list, vacation .forward rule, MLM expander (Mailman, GNU Mailman, Listserv), alumni-alias service, or .edu redirect, the connecting client IP at the FINAL receiver is the FORWARDER's IP — not the ORIGINAL sender's IP — so the receiver's SPF check evaluates against the forwarder's IP against the original-sender's SPF record, which fails by construction. Read the forwarding-issues spoke when triaging aggregate-report rows showing legitimate-domain header_from with unfamiliar source_ip values and spf=fail + dkim=pass + aligned=true (DKIM) — the forwarder-second-hop pattern this spoke documents. Covers the three forwarder-survival fixes: SRS (Sender Rewriting Scheme rewriting the envelope MAIL FROM to a forwarder-owned domain whose SPF authorises the forwarder's IP), ARC (Authenticated Received Chain cryptographic sealing of the original authentication outcome), and the DKIM-only-alignment design choice (DMARC pass on DKIM alignment alone without SPF participation).
• SPF PermError vs TempError — the two failure-result-codes appearing in auth_results/spf/result rows — the focused per-error-code deep dive on the two SPF-failure result codes (RFC 7208 §2.6.7 PermError + §2.6.8 TempError) that appear in the auth_results/spf/result field of aggregate-report records THIS page documents the row-schema of. Where THIS page documents the XML schema (RFC 7489 §A.1 auth_result_type complexType — the six allowed values none / pass / fail / softfail / neutral / permerror / temperror) and the operator workflow for reading the rows, the permerror-vs-temperror spoke documents the FULL RFC 7208 §2.6 byte-level evaluation rules distinguishing the two failure verdicts: PermError on record-grammar violations + the 10-DNS-lookup limit (§4.6.4) + macro-expansion failures (§7); TempError on DNS resolver timeouts + SERVFAIL + transient name-resolution failures. Critical for operators triaging aggregate-report rows showing auth_results/spf/result=permerror (the operator's SPF record is actually broken — audit grammar and lookup-count first) vs =temperror (a transient DNS-resolver event — likely resolves itself; investigate only if persistent across many reporting intervals). Receiver treatment differs: Gmail and Microsoft both fail-open on TempError to avoid delivery loss during transient DNS outages, but treat PermError as a hard SPF-fail feeding DMARC evaluation. Read this spoke when the operator sees a non-trivial PermError / TempError row count in the daily aggregate-report drilldown and needs the per-code diagnostic workflow.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). The auth_results/dkim blocks (zero or more per record) carry the DKIM signing-domain and selector that produced each result.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the PER-AGGREGATE-REPORT-ROW-AUTH-RESULTS- DKIM-VERDICT-AS-LOAD-BEARING-DOWNSTREAM- CONSUMER-OF-PUBLISHER-SIDE-DKIM-TXT-RECORD- BYTE-CORRECT-PUBLICATION companion to this DMARC aggregate-report XML-payload reference. Where THIS page documents the aggregate- report XML payload structure (the auth_results/dkim/result verdict-keyword element, the auth_results/dkim/domain d-tag-identity element, the auth_results/dkim/selector selector-identity element) and the per-row verdict-keyword decode reference, the DKIM- DNS-syntax spoke documents the PUBLISHER-SIDE TXT-RECORD BYTE-LEVEL AUTHORING REFERENCE that every per-row auth_results/dkim/ result verdict-keyword the aggregate- report THIS page documents structurally traces back to as upstream cause. The PER- DKIM-TXT-RECORD-TAG-VS-AUTH-RESULTS-VERDICT cross-reference establishes FOUR structurally- distinct per-publisher-side-DKIM-TXT-record- tag-to-aggregate-report-verdict-keyword coupling dimensions: (i) missing v=DKIM1 version-prefix or missing p= public-key-material tag as upstream cause of the auth_results/dkim/result=permerror verdict class — a selector TXT record missing the mandatory v=DKIM1 version-prefix or publishing an empty p= tag at steady-state (rather than as a deliberate revocation event) produces dkim=permerror (key syntax) at every receiver per §6.1.2; the DKIM-DNS- syntax spoke documents the canonical publisher-side authoring rule whose violation produces this per-row verdict class; (ii) 1024-bit RSA p= public-key-material on legacy selectors as upstream cause of the auth_results/dkim/result=fail (insufficient key strength) verdict class at modern receivers — selectors still publishing pre-2018 1024-bit RSA p= public-key material produce per-row dkim=fail verdicts at every modern Microsoft / Google / Yahoo receiver that has tightened minimum- accepted RSA key-length to 2048 bits; the DKIM-DNS-syntax spoke documents the RFC 8301 §3 RSA-2048 floor as the publisher-side publication discipline whose violation produces this per-row verdict class; (iii) 2048-bit RSA p= public-key-material published WITHOUT correct multi-string TXT chunking per RFC 1035 §3.3.14 as upstream cause of the auth_results/dkim/result=permerror (key syntax) verdict class — selectors publishing 2048-bit RSA p= public-key material exceeding the 255-octet per-TXT-character- string boundary that are published WITHOUT correct multi-string chunking produce per-row dkim=permerror (key syntax) verdicts at every receiver; the DKIM-DNS- syntax spoke documents the multi-string chunking discipline as the canonical publisher-side publication discipline whose violation produces this per-row verdict class; (iv) stale t=y testing-flag past the burn-in window as upstream cause of the DECEPTIVELY-SILENT per-row auth_results/dkim/result=pass verdict that DMARC-evaluation SILENTLY ignores — selectors with the t=y testing flag still published after the burn-in window produce per-row dkim=pass verdicts in the aggregate-report XML but the policy_evaluated/dkim alignment verdict SILENTLY treats the per-row verdict as none rather than pass per RFC 6376 §3.6.1 — the most DECEPTIVE per-row verdict-class defect because the auth_results/dkim/result=pass element appears VALID in the aggregate XML while the downstream DMARC alignment evaluation SILENTLY ignores it; the DKIM- DNS-syntax spoke documents the t=y burn-in cap as the canonical publisher-side publication discipline whose violation produces this DECEPTIVELY-SILENT per-row verdict class. Read THIS aggregate-reports XML-payload reference WITH the DKIM-DNS-syntax spoke when a per-row auth_results/dkim/result verdict-keyword decode arrives at the operator's queue: the aggregate-reports page documents the PER-ROW VERDICT-KEYWORD DECODE REFERENCE, the DKIM-DNS-syntax spoke documents the PER-TAG PUBLISHER-SIDE TXT- RECORD AUTHORING discipline whose violation is the upstream cause of every per-row verdict-class defect this aggregate-reports page enumerates.
• DKIM-Signature header anatomy (byte-level field reference) — the byte-level reference for the DKIM-Signature: header whose verification produces the auth_results/dkim blocks documented on THIS page. Where the DKIM-explained pillar above introduces the protocol at a conceptual level and the aggregate-report auth_results/dkim block records the OUTCOME of each signature verification (the <domain> value verbatim from the signature's d= tag, the <selector> value verbatim from the signature's s= tag, the <result> value as one of pass / fail / neutral / none / policy / permerror / temperror), the DKIM-signatures-explained spoke documents the FULL field grammar of the DKIM-Signature header byte by byte that produced each block: the v=1 version tag floor, a=rsa-sha256 / a=ed25519-sha256 algorithm selection (the latter requires modern verifier support; older verifiers report permerror), the c=relaxed/relaxed vs c=simple/simple canonicalisation modes (different whitespace-collapsing produces different signature inputs — the most-confused source of DKIM-pass-fail variance under forwarding scenarios reflected in aggregate-report fail outcomes), the s=<selector> / d=<domain> pair that names the <selector>._domainkey.<d-tag> DNS TXT record holding the public key, and the h= signed-headers list that enumerates which headers the signature covers (omission of From: from h= is signed-DKIM-with-no-From-protection — a defect only catchable by reading the signature byte by byte, not via the aggregate report's coarse-grained result enum). Read this when an aggregate-report auth_results/dkim block reports a <result>fail</result> and the operator needs to map the verbatim <domain> + <selector> pair back to which signing key on the sending infrastructure produced the signature and which field (body-hash mismatch, canonicalisation mismatch, header-coverage gap, expired-key rotation) caused the failure — the aggregate-report fail enum does NOT carry that diagnostic granularity; the structural mapping from result back to header byte-pattern is in the DKIM-signatures spoke.
• DKIM canonicalization - the RUA-AGGREGATE-DKIM=FAIL-PER-SOURCE- DISTRIBUTION-AS-PUBLISHER-VS-VERIFIER- CANONICALIZATION-MISMATCH-DIAGNOSTIC companion to this RFC 7489 §7.2 aggregate- report consumer-side reference. Where THIS page documents the aggregate-report XML schema and the per-row auth_results/dkim/result enum producing per-source-IP dkim=fail row distributions, the dedicated DKIM- canonicalization spoke documents the STRUCTURALLY-LOAD-BEARING publisher-side c=header/body algorithm-pair- choice at four per-source RUA-evidence- class dimensions whose pattern signature identifies the canonicalization-mismatch sub-class of dkim=fail rows that the aggregate-report fail enum does NOT diagnostically decompose at the XML-schema level: (i) per-source-IP dkim=fail row distributions concentrated on a small set of MLM/mailing-list-server IPs (Mailman / Sympa / Google Groups / listserv) with publisher's c= tag set to c=simple/simple diagnose as body-canonicalization-too- strict-for-MLM-footer-injection failure class - the per-source pattern signature (MLM-IP cluster + dkim=fail dominance) is the RUA evidence-stream surface for the publisher's c=simple/simple choice being structurally mismatched to the mail-stream's MLM-traffic profile; the DKIM-canonicalization spoke documents the per-MLM-platform body-rewrite signature taxonomy that converts the aggregate-report per-source dkim=fail pattern into a publisher-side c=relaxed/relaxed remediation decision; (ii) per-source-IP dkim=fail row distributions concentrated on enterprise-MTA forwarder IPs (Exchange Online forwarding rules, on-premises Postfix/Sendmail forwarders, university forwarding clusters) diagnose as header-canonicalization-too-strict-for- MTA-header-re-folding failure class - the per-source pattern signature (forwarder- IP cluster + dkim=fail dominance + body- hash-intact-but-header-canonicalization- invalid signature-tag debugging) is the RUA evidence-stream surface for the publisher's c=simple header- algorithm choice being structurally mismatched to the mail-stream's forwarder- traffic profile; the DKIM- canonicalization spoke documents the header-re-folding / case-folding / whitespace-normalisation tolerance differential between simple-header and relaxed-header algorithms that decodes the per-source dkim=fail pattern into the operator-actionable c=relaxed header-algorithm remediation; (iii) per-source-IP dkim=fail row distributions concentrated on anti-virus scanner / content-filtering gateway IPs diagnose as body-modification-exceeds- canonicalization-tolerance failure class - this class is STRUCTURALLY UNRECOVERABLE via c=-tag adjustment because the body modification (banner injection, scan-tag insertion, Content-Type rewriting) exceeds even relaxed-body tolerance scope and invalidates bh= regardless of publisher's c= choice; the DKIM-canonicalization spoke documents the body-mutation-class taxonomy that identifies the aggregate-report dkim=fail pattern as the unrecoverable-via- canonicalization sub-class requiring RFC 8617 ARC attestation as the structurally- correct receiver-side remediation; and (iv) per-source-IP dkim=fail row distributions concentrated on the publisher's OWN signing MTA (rather than any intermediate forwarder) with signature-tag debugging revealing canonicalization-tag inconsistency between signing-time and verifier-time bytes diagnose as publisher-side canonicalization-implementation-bug failure class - the RUA per-source-IP pattern signature (publisher's own signing-MTA cluster + dkim=fail dominance) is the operator-visible evidence the publisher's signing-stack implementation has a canonicalization algorithm bug that no forwarder is responsible for and no c=-tag adjustment can rescue; the DKIM-canonicalization spoke documents the publisher-side signing-implementation reference contract that converts the aggregate-report per- source dkim=fail pattern into a publisher-side signing-stack-vendor diagnostic and remediation pathway.
• DKIM cryptography basics — the RUA-AGGREGATE-DKIM-RESULT-RESOLVES- TO-CRYPTOGRAPHIC-PRIMITIVE-MATHEMATICAL- CONSTRUCTION companion to this RFC 7489 §7.2 aggregate-report consumer-side reference. Where THIS page documents the aggregate-report XML schema and the per-row auth_results/dkim/result enum (one of pass / fail / neutral / none / policy / permerror / temperror) that records the per-message verification outcome, the cryptography-basics spoke is the MATHEMATICAL- CONSTRUCTION REFERENCE documenting the cryptographic-primitive byte-anatomy whose per-day per-domain per-algorithm verification outcome the aggregate-report stream makes operator-observable at population scale. The four-axis RUA-AGGREGATE-PER-DAY-OBSERVABILITY- VS-CRYPTOGRAPHIC-PRIMITIVE mapping exposes the structurally-distinct aggregate-evidence-to- mathematical-construction observability resolutions: (i) per-domain dkim=pass rate at population scale → RSA-2048 + SHA-256 signature- verification mathematical-construction steady-state observability — the aggregate-report's per-day per-domain dkim=pass row count at typical production magnitude (≥95% pass rate for well-deployed direct-flow signers, 70–90% for forwarder-traversing flows after canonicalisation-mediated body modifications) is the OBSERVABILITY SURFACE the cryptography-basics spoke's RSA-2048-modulus + 65537-public-exponent + SHA-256-hash verification operation produces at population scale — when the steady-state pass-rate regresses, the operator's first diagnostic hypothesis is a per-key cryptographic-primitive failure (weak modulus, key rotation drift, algorithm misconfiguration) the spoke's mathematical-construction reference enumerates; (ii) per-domain dkim=fail rate trend → per-attack-class + per- weak-algorithm + per-canonicalization- mismatch root-cause distribution — the aggregate-report's per-day dkim=fail row count trend (the OBSERVABILITY METRIC operators alert on) decomposes into FOUR cryptographic-primitive root-cause classes the spoke documents: (a) a=rsa-sha1 weak-algorithm rejection per RFC 8301 §3.2 (the spoke's SHA-1 deprecation rationale identifies the 2018 cutoff and the SHAttered collision- attack basis), (b) sub-2048-bit modulus rejection per RFC 8301 §3.1.1 (the spoke's RSA key-size guidance identifies the cryptographically-suspect-but-still- protocol-valid 1024-bit threshold), (c) SHA-256 body-hash mismatch from post- signing body modification (the spoke's FIPS 180-4 §6.2 hash construction identifies the avalanche-criterion cascade single-byte modifications trigger), (d) signature-syntax permerror per RFC 6376 §3.5 tag-grammar violation (the spoke's signature-algorithm tag-format reference identifies which tag the signer emitted in non-conformant byte-shape); (iii) per-domain dkim=permerror rate as cryptographic-key-publication- infrastructure health-KPI → DNS- published p=-tag SubjectPublicKeyInfo blob byte-anatomy observability — the aggregate- report's per-day dkim=permerror row count is the OBSERVABILITY METRIC for per-key DNS-publication infrastructure failures the spoke's DER/PEM-encoded SubjectPublicKeyInfo blob byte-anatomy identifies: missing <selector>._domainkey.<d=> TXT record (key rotation that retired the old selector before all in-flight messages cleared the receiver-side processing queue), corrupted base64-encoded p=-tag value (publication- time byte-truncation at the DNS-provider UI), or algorithm-mismatch between k=-tag in DNS and a=-tag in signature (the spoke's algorithm-identifier byte-format reference catalogues the conformance contract); (iv) per-domain k=ed25519-selector dkim=pass-rate observability → RFC 8463 Ed25519 post-quantum migration adoption KPI — the aggregate-report's per-domain per-selector dkim=pass-rate broken down by k=rsa vs k=ed25519 selector is the OBSERVABILITY METRIC for the operator's algorithm-migration adoption progress (the spoke documents the Ed25519 8.5× faster-signing + 2.3× faster-verification + 32-byte-vs-2048-byte key-size advantage motivating the migration), the receiver-side adoption gap (modern receivers like Gmail / Yahoo / Microsoft 365 all implement RFC 8463 Ed25519 verification, but per-receiver rollout cadence varies), and the operator-side dual-algorithm-publication pattern (parallel k=rsa + k=ed25519 selectors during the migration window so the aggregate-report can attribute per-selector pass-rate to each algorithm independently). Read the cryptography- basics spoke when the per-day per-domain per-selector aggregate-report auth_results/dkim/result rate distribution needs to resolve to the mathematical-construction layer the verifier applied — the spoke is the canonical reference for the cryptographic- primitive byte-anatomy whose per-message verification outcomes the aggregate- report stream observes at population scale, the per-algorithm-rate KPIs the operator monitors against the cryptographic- primitive deployment baseline, and the per-RFC-deprecation-cutoff observability contract (the spoke's algorithm-deprecation timeline identifies which algorithms the modern verifier independently fails under policy-class disposition irrespective of the signer's signature-validity).
• DKIM best practices — the RUA-AGGREGATE-EVIDENCE-AS-FEEDBACK- LOOP-FOR-THE-13-RULE-DKIM-OPERATOR- DISCIPLINE-CHECKLIST companion documenting the 13-rule platform-agnostic DKIM operator-discipline whose continuous- verification feedback channel is the per-day per-domain auth_results/dkim block stream this page's RUA aggregate-report ingestion layer surfaces. Where THIS page documents the RUA aggregate-report INGESTION infrastructure (the receiver-side XML report-generator, the gzip-or-zip compressed MIME-attached payload format, the rua= URI delivery channel, the per-row auth_results/dkim block with <domain> + <selector> + <result> sub-elements, and the operator-side per-day dkim=pass-rate aggregation), the DKIM-best- practices spoke is the 13-RULE OPERATOR- DISCIPLINE SYNTHESIS whose continuous- verification depends on the aggregate- report stream THIS page documents: rule #1 (2048-bit RSA / Ed25519 algorithm floor) is verified by absence of dkim=permerror from algorithm- incompatibility, rule #2 (6-to-12-month rotation cadence) is verified by the observed <selector> rotation pattern across the daily report stream, rule #3 (relaxed-relaxed canonicalisation default) is verified by forwarder-induced dkim=fail row absence, rule #4 (post-DMARC alignment discipline) is verified by the per-d=-domain dkim=pass-AND-aligned subset on the aggregate-report row, rules #5–#13 (selector hygiene, public-key retirement, signing- algorithm migration, platform-portability) all surface in the per-day evidence stream as either anomalous result-distribution patterns or as auth_results/dkim/domain + auth_results/dkim/selector misalignment from the operator's expected publication. Read the DKIM-best-practices spoke when scoping the operator-discipline the daily aggregate-report ingestion this page operationalises is supposed to continuously verify — the 13-rule checklist is the rubric against which the RUA stream's per-day dkim= verdict distribution is interpreted for operator-discipline compliance.
• DKIM replay attacks — the RUA-PER-MESSAGE-COUNT-INFLATION- AS-DKIM-REPLAY-EVIDENCE-STREAM companion reference. Where THIS page documents the receiver-side RUA aggregate-report ingestion infrastructure (the per-row <row><count> sub-element that aggregates the number of receiver-observed messages sharing the same source_ip + auth_results tuple over the report window), the DKIM-replay- attacks spoke documents the RFC 6376 §6.2.2 attack class in which a single legitimately-signed message is captured and re-injected to many receivers under the ORIGINAL DKIM-Signature header — the receiver-side auth_results/dkim/result block reports pass on every replayed instance because the body-hash and signing-key remain byte-identical, and the receiver's aggregate-report generator records each replay-instance as one additional message under the same <source_ip> / <header_from> bucket, producing the abnormally-inflated per- message <count> value that surfaces on RUA-ingestion dashboards when a downstream replayer harvests the signed corpus and bulk-redelivers. Read this when a daily RUA aggregate-report ingestion run surfaces a source_ip whose per-message <count> is an order of magnitude above the per-day median for that signing tuple — the DKIM-replay-attacks spoke documents the RFC 6376 §3.5 x= expiration timestamp tag, the l=-tag-as-replay-extension- attack-vector, the per-selector retire- and-rotate cadence, and the receiver- side DKIM-Signature header tracking that bound the replay-window the attacker has between message-signing and signature- expiry. The aggregate-report <count> field documented on THIS page is the canonical evidence stream that surfaces the replay event to operators; the DKIM-replay- attacks page is the structural reference for the underlying attack mechanics and the operator-side mitigation surface (short x= expiry, selector rotation, l=-tag avoidance, receiver-side DKIM-Signature replay detection).
• DKIM for Microsoft 365 — the RUA-PER-AUTH-RESULTS-DKIM-BLOCK- AS-M365-EXCHANGE-ONLINE-SELECTOR1- SELECTOR2-CNAME-PUBLICATION-OUTCOME- EVIDENCE-STREAM companion reference. Where THIS page documents the RUA aggregate-report auth_results/dkim block with its <domain> + <selector> + <result> sub-elements recording each DKIM-signature verification outcome at receiver-side, the DKIM-for-Microsoft-365 spoke documents the M365-tenant-specific DKIM publication mechanics whose outcomes those XML rows record verbatim. The M365 DKIM publication model is structurally distinct from most ESP-managed DKIM deployments: the domain-owner publishes TWO CNAME records (selector1._domainkey. <domain> → selector1-<tenant-id> ._domainkey.<tenant>. onmicrosoft.com and the equivalent for selector2) rather than a TXT record holding the public key directly, and Microsoft rotates the underlying private key on the onmicrosoft.com side without the domain-owner needing to re-publish DNS records. The aggregate-report auth_results/dkim block documented on THIS page surfaces the per-message outcome of those CNAME- chain DKIM verifications: <domain> <your-tenant-domain> </domain> + <selector>selector1 </selector> on a healthy M365-outbound mail-stream; <result>permerror </result> when the CNAME chain has been deleted prematurely or the M365 tenant's DKIM-enable toggle in the Defender portal has not been switched ON after CNAME publication; <result>fail</result> when an outbound connector re-routes mail through a third-party hop that modifies the body or signed-headers AFTER M365's DKIM signing stage. Read the DKIM-for-Microsoft-365 spoke when an aggregate-report drilldown surfaces anomalous dkim= verdicts on outbound mail-streams routed through Exchange Online — the spoke documents the publication mechanics, the Defender-portal enable toggle, the selector1/selector2 dual-selector rotation discipline, and the outbound-connector / hybrid-Exchange topology variants whose configuration surface determines whether the RUA auth_results/dkim verdict rows match operator expectation.
• SPF for Microsoft 365 — the RUA-PER-AUTH-RESULTS-SPF-BLOCK- AS-M365-TENANT-PUBLICATION-OUTCOME- EVIDENCE-STREAM companion to this aggregate-report consumer-side reference. Where THIS page documents the RFC 7489 §A.1 aggregate-report XML schema and the consumer-side ingestion pipeline that decodes the auth_results/spf + auth_results/dkim + policy_evaluated/disposition per-row evidence, the SPF-for- Microsoft-365 spoke is the M365- tenant-specific PUBLICATION-SIDE reference whose authoring choices directly materialise as specific row patterns in the aggregate stream operators ingest. M365-tenant operators see FIVE M365-specific RUA row patterns: (i) the canonical EOP-outbound source_ip block + spf=pass + envelope-domain=tenant-domain attribution — the canonical Microsoft-managed EOP outbound netblock (40.92.0.0/15 + 40.107.0.0/16 + 52.100.0.0/14 + 104.47.0.0/17 and the receiver-side recursive-include expansion's announced ranges) appears in RUA source_ip / count blocks with auth_results/spf/result=pass + envelope-domain matching the M365 tenant's published apex — the canonical attestation that the M365 SPF authoring is intact and operating; (ii) the permerror row spike correlated with the 10-lookup ceiling breach — when an M365 operator adds excess third-party SaaS include: tokens past the ceiling, aggregate reports surface auth_results/spf/result=permerror rows across receivers that comply with §4.6.4 — the canonical first- suspect when M365-tenant RUA evidence shows uniform permerror at all major receivers; (iii) the hybrid- Exchange dual-egress source_ip attribution split — M365 tenants running hybrid topology (on-prem Edge + Exchange Online dual- egress) see RUA rows partitioned between EOP-egress source_ips (passing SPF via include:spf.protection.outlook.com) and on-prem-egress source_ips (passing SPF only if the operator enumerated the on-prem IPs via ip4:<CIDR> or a secondary include token) — the canonical RUA-evidence pattern that reveals an under-enumerated hybrid SPF record; (iv) the forwarder-second-hop spf=fail row at legitimate Outlook.com / Gmail forwarders — RUA evidence from receivers downstream of an Outlook.com auto-forward or Gmail auto-forward shows auth_results/spf/result=fail on the M365 tenant's envelope-domain because the forwarder re-emits from its own outbound IPs — distinguishable from actual attacker forgery by cross-referencing the auth_results/dkim/result=pass verdict on the same row (a forwarded- legitimate-message preserves DKIM signature integrity even when SPF breaks), and (v) the attacker-bypass row at uniformly- IP-unauthorised source_ips with spf=fail + dkim=fail + disposition=quarantine or reject — RUA evidence of actual attacker forgery against the M365-tenant's apex domain, identifiable by the absence of any DKIM-pass on the same per-message row and the receiver- side enforcement-disposition column showing the publisher's p=quarantine or p=reject verdict reached actual enforcement. Pair this aggregate- report consumer-side reference with the SPF-for-Microsoft-365 spoke when triaging the M365-tenant per-source_ip row attribution — the spoke is the publication-side reference whose authoring choices DETERMINE which row patterns appear in the M365 tenant's aggregate stream and which authoring defect each pattern signals.
• SPF for Google Workspace — the RUA-PER-AUTH-RESULTS-SPF-BLOCK-AS- WORKSPACE-TENANT-CANONICAL-_SPF.GOOGLE.COM- INCLUDE-CASCADE-PUBLICATION-OUTCOME- EVIDENCE-STREAM companion to this aggregate-report consumer-side reference. Where THIS page documents the per-record auth_results/spf result-code taxonomy (pass / fail / softfail / neutral / permerror / temperror / none) + the per-source_ip attribution model + the per-policy-evaluated row representation, the SPF-for-Google-Workspace spoke is the WORKSPACE-TENANT-PUBLICATION-SIDE-MIRROR companion documenting WHICH Workspace- tenant SPF authoring choices DETERMINE which row patterns appear in the Workspace tenant's aggregate stream. The four-axis RUA-VS-WORKSPACE-SPF-PUBLICATION comparison exposes the structurally- distinct WORKSPACE-RUA-PUBLICATION-MIRROR roles: (i) Workspace-tenant outbound auth_results/spf/result rows in RUA derive from the canonical v=spf1 include:_spf.google.com ~all publication — every Workspace-tenant message receiving SPF=pass at a receiver consumed the _spf.google.com-included netblock match path — the SPF- for-Workspace spoke documents the _spf.google.com cascade (_netblocks.google.com + _netblocks2.google.com + _netblocks3.google.com) whose ~4-lookup baseline footprint determines the Workspace-tenant SPF-pass row population in the aggregate stream; (ii) Workspace-tenant per- source_ip RUA attribution rows surface Google-managed egress IPs as the canonical source_ip identifier for every legitimately-outbound Workspace tenant message — but operators triaging the aggregate-report source_ip field for non- Workspace IPs must consult the SPF-for- Workspace spoke's third-party-sender catalogue to disambiguate legitimate- SaaS-vendor egress (SendGrid / Mailchimp / Salesforce SFMC) from unauthorised third-party use of the Workspace tenant's domain; (iii) Workspace- tenant Google-Groups + Workspace-routing- rules outbound surfaces in RUA as a DIFFERENT source_ip class than direct Workspace user outbound — the SPF-for-Workspace spoke documents the Google-Groups-as-mailing-list-mediator + Workspace-routing-rule-redirect outbound patterns the operator MUST learn to attribute correctly when reading RUA rows for these scenarios — without the spoke's reference, Workspace-managed list-rewriting rows are misattributed as forwarder-failure or spoofing- attempt; (iv) Workspace-tenant SMTP-relay-from-outside-Workspace integration produces aggregate-report rows with envelope-MAIL-FROM domain DIFFERENT from From-header domain — the SPF-for-Workspace spoke documents the SMTP-relay-from-on-prem and SMTP- relay-from-partner-infrastructure envelope-MAIL-FROM authoring discipline that determines whether these rows produce SPF-aligned-pass or SPF- aligned-fail in the Workspace tenant's aggregate stream. Pair this aggregate- report consumer-side reference with the SPF-for-Google-Workspace spoke when triaging the Workspace-tenant per- source_ip row attribution — the spoke is the publication-side reference whose authoring choices DETERMINE which row patterns appear in the Workspace tenant's aggregate stream and which authoring defect each pattern signals, STRUCTURALLY-PARALLEL to the SPF-for- Microsoft-365 RUA-evidence reference documented above but at the Workspace- tenant cohort.
• BIMI explained — Brand Indicators. Aggregate reports document the DMARC pass- rate that BIMI deployment requires.
• BIMI SVG Tiny PS logo requirements — the RUA-MONITORING-OF-BIMI-DISPLAY- CANDIDATE-MAIL-STREAM-DMARC-PASS-RATE companion reference. Where THIS page documents the aggregate-RUA stream that operators consume to verify that the mail-stream BIMI is supposed to display on IS in fact passing DMARC at the steady-state pass-rate floor BIMI display requires (p=quarantine pct=100 or p=reject with consistent identifier alignment on every legitimate mail-stream in the RUA- reported per-source_ip breakdown), the BIMI-SVG-requirements spoke documents the STRUCTURALLY-PARALLEL VISUAL-ASSET- BYTE-COMPLIANCE GATE that the brand logo asset must satisfy in parallel before the BIMI display threshold is crossed at the MUA: the SVG file served at the BIMI record's l= URL must conform to the SVG Tiny PS profile (a strict subset of SVG 1.1 + SVG 2 forbidding <script>, <foreignObject>, external references, raster image embeds, animation elements, and non-presentation namespaces; requiring a square viewBox, the baseProfile="tiny-ps" root attribute, and a <title> element immediately after the <svg> root) AND must hit a strict 32KB file-size ceiling for Gmail's BIMI rendering path AND must pass the BIMI Group SVG validator's byte-precise conformance check before either CMC or VMC certificate issuance can proceed. The implication: the aggregate-RUA pass-rate verify gate this page documents is one of TWO structurally-orthogonal prerequisites BIMI display requires — the OTHER prerequisite is the SVG-byte-compliance gate the BIMI-SVG-requirements spoke documents — both gates must pass for the brand logo to render at the MUA's inbox display surface. Read the BIMI-SVG-requirements spoke alongside this page when planning a BIMI rollout — the aggregate-RUA pass-rate gate confirms the DMARC half of the prerequisite, the SVG-byte-compliance gate confirms the visual-asset half, and BOTH must be verified in the operator's pre-launch checklist before the brand-logo investment produces inbox-visible value.
• BIMI Verified Mark Certificates (VMC and CMC) — the RUA-AGGREGATE-PASS-RATE-FLOOR-AS- VMC-ISSUANCE-PRECONDITION-CONTINUOUS- EVIDENCE-STREAM companion reference. Where THIS page documents the RFC 7489 §7.2 aggregate-report XML schema (the per-source_ip / policy_evaluated / auth_results row breakdown the receiver-cohort serialises at the daily reporting cadence), the BIMI- certificates spoke documents the VMC/CMC X.509 trademark-bound certificate whose Mark Verifying Authority issuance gate AND continued MUA-side display validity is STRUCTURALLY GATED on the aggregate-RUA evidence stream THIS page documents, across four VMC-lifecycle aggregate- evidence dimensions: (i) the BIMI WG AuthIndicators specification requires DMARC enforcement at p=quarantine pct=100 or p=reject as the issuance- time prerequisite — the aggregate-RUA stream this page documents is the canonical empirical evidence pipeline operators use to validate that the steady-state per-source_ip pass-rate is sufficient to graduate from p=none to enforced policy BEFORE the VMC procurement cycle is worthwhile, (ii) post-issuance, the VMC validity window (typically 1-3 years per the issuing CA's MPKI contract) is in effect a per-domain commitment to MAINTAIN the DMARC pass- rate floor — RUA-monitored pass-rate degradation surfaces the leading indicator that the brand-display signal will start failing at Gmail / Apple Mail / Yahoo / Fastmail MUAs before the trademark-CA monitoring cycle ever produces a renewal-blocking signal, (iii) per-receiver-cohort VMC evaluation is observable in the RUA feed indirectly through DMARC-pass-rate- per-source_ip — Gmail's BIMI evaluator consumes its own internal DMARC-pass- rate-per-source_ip metric (the same metric this page's RUA stream exposes for operator-side verification) so a per-receiver-cohort degradation pattern in the operator's RUA-ingested feed maps directly to the corresponding receiver's BIMI- evaluator-side display-eligibility verdict, and (iv) RUA-aggregate evidence is the cross-domain attribution mechanism for diagnosing when an attacker-procured cousin- domain VMC's brand-impersonation attempt produces measurable RUA-row patterns (the §7.4 BIMI-impersonation attack class) — operators cross-correlate their own RUA feed with the attacker's cousin-domain RUA feed (where they have monitoring delegation) to surface the trademark- layer attack before the MVA's trademark-evidence-validation gate catches it. Read the BIMI-certificates spoke alongside this page when scoping a BIMI rollout's aggregate-RUA observability discipline — the RUA stream's per-day per-source_ip per- disposition row counts THIS page documents are the empirical evidence operators consult to validate that the VMC investment is worthwhile (issuance prerequisite), is being maintained (continued-validity prerequisite), is being honoured by receiver MUAs (per-receiver-cohort display verification), and is not being impersonated at the cross-domain attribution layer (impersonation- attack surveillance).
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). Companion transport-security standard with its own reporting stream (TLS-RPT).
• DANE explained — the DNSSEC-anchored transport-security primitive that secures the rua= aggregate-report delivery channel — the TRANSPORT-LAYER COMPANION the DMARC aggregate-reporting protocol on this page structurally depends on for report-delivery confidentiality and integrity. Where THIS page documents the per-XML-element semantics of the DMARC aggregate-report payload (<policy_published>, <record>, <auth_results>, <policy_evaluated>, per-source-IP counters, identifier- alignment verdicts), the DANE-explained spoke documents the RFC 7672 DNSSEC-anchored TLSA-record protocol that secures the SMTP delivery channel the rua= ZIP payload flows through. The operational dependency is structural: DMARC aggregate reports contain OPERATIONALLY-SENSITIVE data (per-source-IP send patterns, per-domain alignment verdicts, the full enumeration of every unauthenticated sender attempting to spoof the receiver's evaluated domain) — exactly the data an attacker positioned for STARTTLS-stripping or rogue-CA MITM at the receiver's MX would harvest to enumerate the receiver's authentication infrastructure and design downstream attacks. DANE prevents this by binding the receiver MX's TLS certificate to a DNSSEC-signed TLSA record — every TLS handshake the rua= report traverses is cryptographically pinned to the publisher's intended certificate (or certificate-issuing CA in DANE-TA mode). The DMARC failure mode without DANE is silent: an MTA attacker strips STARTTLS or presents a rogue certificate, the SMTP server falls back to plaintext or accepts the rogue cert, the rua= ZIP is delivered (so no SMTP-level error surfaces in the sender's logs) but in transit-readable to the attacker. Read this spoke when deploying DMARC aggregate reporting on a high-value domain and needing the transport-security adjacent-layer reference for the threat model rua= delivery sits within.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). The transport-layer equivalent of DMARC aggregate reporting.
• TLS-RPT report format (RFC 8460 §4 JSON schema) — the field-by-field JSON schema reference for the TLS-RPT report format that completes the cross-protocol-cluster pairing between DMARC aggregate reporting (XML, RFC 7489 §7.2) and SMTP TLS reporting (JSON, RFC 8460 §4). Where THIS page documents the per-XML-element semantics (<policy_published>, <record>, <auth_results>, <policy_evaluated>) of the DMARC aggregate-report AUTHENTICATION-LAYER feedback loop, the TLS-RPT report-format spoke documents the per-JSON-field semantics (organization-name, date-range, contact-info, report-id, policies, policy-type, policy-string, policy-domain, mx-host, summary, total-successful-session-count, total-failure-session-count, failure-details, result-type, sending-mta-ip, receiving-mx-hostname, failed-session-count) of the analogous TRANSPORT-LAYER feedback loop. The two report formats are designed to be operated in parallel: DMARC aggregate reports catalogue authentication-verdict distributions per source-IP per day, TLS-RPT reports catalogue STARTTLS handshake-success vs downgrade-failure distributions per sending MTA per day — together they provide the end-to-end sender-side mail-flow audit trail from the authentication gate down to the wire-level transport-encryption gate.
• CAA records explained — Certification Authority Authorization (RFC 8659).
• Reverse DNS / PTR records for mail servers — the SOURCE-IP-RESOLUTION OPERATOR-COMPANION to this aggregate- report consumer reference. Aggregate reports surface every send-side IP that emitted mail under the operator's domain as the <source_ip>1.2.3.4</source_ip> element in each <record> block (RFC 7489 §7.2.1.1), but the XML schema does NOT include a hostname companion field — the operator's analysis workflow MUST perform a per-source_ip reverse-DNS PTR lookup to translate every raw IP into a human-readable sender identifier (mail-1.sendgrid.net, outbound-mail.mailchimp.com, mta-1.yourcompany.com) before any operator can confidently triage the report's policy_evaluated/disposition rows. The reverse-dns-ptr spoke documents the EXACT operator procedure: the per-record dig -x lookup, the FCrDNS (forward-confirmed reverse DNS) verification, the bidirectional consistency check between PTR and A/AAAA, and the attribution heuristics for distinguishing legitimate-but-unfamiliar senders from suspect-spoofed source_ips. This page documents the AGGREGATE-REPORT STREAM — the consumer-side data structure where every source_ip row arrives needing attribution. The reverse-dns-ptr spoke documents the PER-source_ip PROCEDURE every aggregate-report analysis workflow applies BEFORE the operator can meaningfully act on the report's contents. Read the reverse-dns-ptr spoke when triaging unfamiliar source_ip rows on the aggregate-report dashboard ("which sender is 34.213.215.74?" — the answer is the PTR lookup the reverse-dns-ptr spoke documents the canonical procedure for).
• Email deliverability fundamentals — the operational-outcome companion to this aggregate-reports page. Aggregate reports surface the policy_evaluated/dkim and policy_evaluated/spf verdicts plus the auth_results per-mechanism block, but the verdicts themselves are only one input into the receiving mailbox provider's inbox-placement decision. The deliverability page documents the full control stack that determines whether DMARC-pass mail lands in the inbox vs the spam folder vs the bulk folder vs gets deferred / throttled / tarpitted: IP reputation (Sender Score / Talos / Spamhaus ZEN — every aggregate report's source_ip element is what these reputation systems track), domain reputation (Google Postmaster Tools / Microsoft SNDS — these read the header_from element from every aggregate-report record), FCrDNS (forward-confirmed reverse DNS), Feedback Loop (FBL) signals, list hygiene, content filtering, throttling / greylisting / tarpitting, and engagement signals. Read the deliverability page when aggregate reports show a clean 100 % DMARC pass rate but inbox-placement metrics (Postmaster Tools / SNDS / FBL) show degradation — the deliverability page catalogues every operator-side control that aggregate reports do not directly surface but always interact with.
• DMARC for Shared Hosting — shared-IP-reputation RUA-consumption diagnostic for Plesk / DirectAdmin / ISPConfig / generic-no-control-panel platforms — the SHARED-HOSTING-RUA-CONSUMPTION-DIAGNOSTIC companion to this aggregate-reports reference for the SMB operator population whose RUA stream is structurally different from the dedicated-IP-pool operator the canonical RUA-decode workflow this page documents is calibrated for. Where THIS page documents the universal RFC 7489 §7.2 aggregate-report XML schema, per-row decode methodology, source_ip / count / policy_evaluated / auth_results field semantics, and the major-receiver-specific XML-schema quirks (Google snake_case canonicalisation, Microsoft empty-record XML, Yahoo per-receiver-aggregation), the shared-hosting spoke documents the SHARED-IP-POOL-SPECIFIC RUA-CONSUMPTION DIAGNOSTIC the shared-hosting operator persona must overlay on the universal decode methodology: source_ip rows from the operator's shared-IP-pool will register IN ALL CO-TENANT-PAIRED operators' RUA streams under the same /24 (the shared-IP-pool's reputation signal is attributable to ANY tenant on the pool, so the operator's own RUA shows source_ip entries the operator did not author); auth_results/dkim and auth_results/spf rows for source_ip entries the operator does NOT recognise are commonly co-tenant churn on the shared pool not malicious spoofing (a structurally-different triage workflow than the dedicated-IP-pool operator's RUA-decode); policy_evaluated/disposition fields showing receiver-side overrides are commonly correlated with shared-IP-pool reputation drag at the receiver-level not operator-side authoring errors (Gmail's override registers as a shared-IP-pool- wide reputation signal not a per-tenant authoring signal); the identifiers/header_from field is the operator's primary attribution-correctness signal on shared-hosting because source_ip attribution is collapsed across the shared pool. Read the shared-hosting spoke when this page's universal RUA-decode methodology produces source_ip entries the operator does not recognise — the spoke documents the per-row triage workflow the shared-IP-pool operator persona must apply that the dedicated-IP- pool operator's RUA-decode does not need.
• DMARC for cPanel & Shared Hosting — the CPANEL-SHARED-IP-POOL-AND-EXIM_DKIM- DEFAULT-SELECTOR-SOURCE_IP-ATTRIBUTION- RECONCILIATION companion reference. Where THIS page documents the universal RFC 7489 §7.2 aggregate-report XML schema, per-row decode methodology, and source_ip / count / policy_evaluated / auth_results field semantics, the DMARC-for-cPanel deployment spoke documents the CPANEL-TENANT-SPECIFIC RUA-CONSUMPTION DIAGNOSTIC operators must overlay on the universal decode methodology across FIVE cPanel-default RUA-row materialisation patterns: (1) source_ip rows from the cPanel-server's outbound /28 cohabitant block register UNDER ALL cPanel-tenant-protected domains hosted on the same server (the operator's own RUA shows source_ip entries from OTHER cPanel-tenants on the same physical server — these are NOT spoofing); (2) auth_results/spf rows materialise with the rewritten envelope-MAIL-FROM domain bounces+<tenant-id>@<cpanel-server-hostname> (NOT the protected From:-domain) when cPanel's Sender Verification feature is active, which collapses SPF alignment and forces the receiver to rely on DKIM-aligned-pass for the DMARC verdict; (3) the include:websitewelcome.com cohabitant SPF entry produces RUA rows from the websitewelcome.com-cohabitant IP space whose alignment-evaluation outcome is per-cohabitant-IP-reputation rather than per-tenant authoring discipline; (4) policy_evaluated/disposition overrides at major receivers register as cPanel-server-wide reputation signals not per-tenant authoring errors — Gmail's per-/24 inbox-placement model treats the cPanel-server's outbound cohabitant block as a single reputation unit; (5) auth_results/dkim rows materialise with selector default._domainkey under the protected From:-domain when EXIM_DKIM is enabled — the absence of this row (or its appearance with result="fail") is the canonical first-suspect when a cPanel- tenant's RUA stream shows policy_evaluated DMARC-fail despite the operator believing DKIM is enabled. Read the DMARC-for-cPanel spoke when this page's universal RUA-decode methodology produces source_ip entries from the cPanel-server's cohabitant block the operator does not recognise — the spoke documents the cPanel-tenant-specific per-row triage workflow that overlays on the universal decode methodology.
• DMARC for Hybrid Exchange (on-prem + M365) — the RUA-PER-EGRESS-PATH-RECONCILIATION- IN-HYBRID-DUAL-EGRESS-EXCHANGE-COEXISTENCE- TOPOLOGY companion reference. Where THIS page documents the universal RFC 7489 §7.2 aggregate-report XML schema and per-row decode methodology, the DMARC-for-Hybrid- Exchange spoke documents the canonical HYBRID-TOPOLOGY OPERATOR-WORKFLOW the aggregate-report stream surfaces in production: a hybrid Exchange + EOP organisation emits mail via TWO orthogonal egress paths whose source_ip rows in the RUA stream MUST be reconciled together to produce a complete sender-inventory. (i) Mail egressing via Exchange Online's outbound path produces source_ip rows from the M365 outbound IP range (typically 40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 104.47.0.0/17, 2a01:111:f400::/48) with auth_results/dkim/domain = the M365-tenant protected domain and auth_results/spf/scope = the EOP-outbound SPF token contributor; (ii) Mail egressing via the on-prem Edge Transport role produces source_ip rows from the operator's on-prem Edge IP (a SINGLE IP or small range outside the M365 outbound ranges), with auth_results/dkim/domain = either the on-prem DKIM key's d= (legacy on-prem DKIM signing) or NO DKIM signature at all (a common misconfiguration), and auth_results/spf/scope = the per-IP ip4:<on-prem-edge-IP> SPF mechanism (or SPF=fail if the on-prem Edge IP isn't covered in the SPF record). The operator's RUA-decode workflow on a hybrid-Exchange topology must recognise BOTH source_ip-row populations as legitimate-sender egress paths, NOT confuse the on-prem-Edge source_ip with an attacker source, and SEPARATELY drive the M365-side and on-prem-side DKIM-signing and SPF-mechanism authoring steps. Read the hybrid-Exchange spoke alongside this RUA-decode reference when the operator's aggregate report shows TWO orthogonal source_ip populations whose policy_evaluated/dkim and policy_evaluated/spf results diverge — hybrid-Exchange is the single most common topology producing this dual-egress RUA-row pattern.
• DMARC for transactional email — the RUA-PER-ESP-SOURCE-IP-ANALYSIS-FOR- MULTI-TENANT-TRANSACTIONAL-SENDER-INVENTORY- RECONCILIATION-WITH-SHARED-EGRESS-IP-POOL- DISAMBIGUATION companion reference. Where THIS page documents the universal RFC 7489 §7.2 aggregate-report XML schema and per-row decode methodology, the DMARC-for-transactional-email spoke is the per-ESP operator-workflow reference the aggregate-report stream surfaces in production for any organisation outsourcing transactional mail (password resets, receipts, shipping notifications, MFA codes, account-action confirmations) to a third-party ESP. The four-axis RUA-VS-TRANSACTIONAL-ESP comparison exposes the structurally-distinct RUA-DECODE roles: (i) each transactional ESP egresses mail via its own shared-customer IP pool — SendGrid (159.183.0.0/16 + Mailgun's egress range + Amazon SES's regional egress / SES production IPs + Postmark's 168.245.0.0/16 envelope + SparkPost's egress + MailChimp Transactional's egress) is each an ORTHOGONAL source_ip cohort in the protected-domain's RUA stream, and a protected domain using multiple transactional ESPs sees N orthogonal per-ESP source_ip populations that must be reconciled independently from the corporate-Exchange / Workspace / on-prem-Postfix egress populations; (ii) transactional ESPs sign with the ESP's d= by default (delegated DKIM signing) producing dkim=pass + aligned=false rows that look like attacker-bypass but are legitimate — the DMARC-for-transactional-email spoke documents the per-ESP delegated- signing-vs-customer-signing decision tree that determines whether the protected domain's RUA stream shows the canonical legitimate-but-non- aligned ESP pattern or the aligned-pass cohort produced by custom-d= delegated-DKIM signing; (iii) per-ESP envelope-MAIL- FROM authoring conventions produce per-ESP SPF-aligned-pass rates distinct from the corporate-Exchange SPF-aligned-pass rate — each ESP has its own envelope-MAIL-FROM return-path domain (SendGrid's em.<customer>.com bounce domain, Mailgun's mg.<customer>.com domain, SES's <region>.amazonses.com default vs custom-Return-Path, Postmark's signed-bounce-domain convention) requiring an ESP-specific SPF authoring discipline distinct from the corporate-Exchange SPF record this page surfaces via the auth_results/spf/domain field; (iv) recipient-side auto-forwarding pollution is highest for transactional ESP mail-class — the recipient-side mailbox-rule auto-forwarding scenario produces a SPF-aligned-fail row population in the protected-domain's RUA stream that is most commonly attributable to forwarding loss rather than spoofing — the DMARC-for-transactional-email spoke documents the forwarding-failure-vs-actual-spoofing disambiguation discipline operators need when triaging per-ESP-cohort RUA rows.
• DMARC for SaaS senders — the RUA-PER-SAAS-MARKETING-PLATFORM- SOURCE-IP-ANALYSIS-PER-CUSTOMER-TENANT companion to this aggregate-reports reference. Where THIS page documents the universal RFC 7489 §7.2 aggregate-report XML schema and per-row decode methodology, the DMARC-for-SaaS-senders spoke is the per-SaaS-marketing-platform operator-workflow reference the aggregate-report stream surfaces in production for any organisation outsourcing high-volume marketing / promotional / nurture-campaign mail to a third-party SaaS marketing platform. Concretely, the spoke documents FOUR per-SaaS-marketing-platform-RUA-row- decode dimensions: (i) each SaaS marketing platform egresses mail via its own shared-IP-pool published in the platform-managed SPF include — Salesforce Marketing Cloud's _spf.exacttarget.com, HubSpot's servers.mcsv.net, Marketo's mktomail.com and SparkPost's sparkpostmail.com ranges each publish a CIDR cohort (typically /22 to /18) shared across ALL the platform's customer tenants — per-platform attribution of RUA-row source_ip values requires the operator to maintain a published-cohort inventory keyed by platform-managed- SPF-include; (ii) per-customer- tenant signing-identity discriminator is the per-row d= alignment field — within a single SaaS platform's shared-IP-pool, multiple customer- tenants emit mail from the SAME source IPs but with DIFFERENT DKIM signing identities (the platform-managed per-customer-tenant CNAME-delegated selector like k1._domainkey.<customer-domain> → platform key zone), and the RUA-row auth_results/dkim/domain field is the only reliable discriminator between "this row is OUR SaaS-platform egress" and "this row is a SIBLING customer-tenant's egress masquerading as our domain via shared-IP-pool spoofing"; (iii) per-SaaS- platform sub-account tenancy surfaces as multi-row RUA partitioning — Salesforce Marketing Cloud's Business Units, HubSpot's Marketing Hub seats, Marketo's smart-list partitions, and Mailchimp's audience segments each produce DISTINCT per-sub-account RUA-row patterns (each sub-account gets its own per-customer-tenant DKIM-signing identity AND its own per-list-management Friendly-From- header local-part patterns), and operator-side per-sub-account attribution requires correlating the per-row source_ip + d= + From header_from local-part to the operator-internal sub-account inventory; and (iv) SaaS- platform shared-IP-pool reputation cross-contamination is visible at the receiver-side disposition tier in RUA rows — when a sibling customer-tenant on the same SaaS- platform shared-IP-pool emits high- volume spam (a SaaS-platform deliverability team's standing operational concern), the RUA-row policy_evaluated/disposition for legitimate operator mail emitted through the same shared-IP-pool can drift toward quarantine / reject even when the operator's per-customer-tenant DKIM signing identity is correct — cross-tenant reputation contamination only the per-platform-SPF-include cohort-monitoring discipline the SaaS-senders spoke documents can detect. Read the DMARC-for-SaaS- senders spoke alongside this aggregate-reports reference when the operator's RUA-row triage workflow repeatedly surfaces source_ip values from a SaaS-platform shared-IP-pool cohort, when investigating per- customer-tenant DKIM-signing-identity alignment failures that affect ONE sub-account but not sibling sub- accounts, or when shared-IP-pool reputation cross-contamination forces the operator's per-customer-tenant DMARC-pass rate to drift below the eligibility threshold for terminal p=reject advancement.
• Email security glossary — RUA-DECODE-THREAT-VOCABULARY for source_ip attribution when policy_evaluated/disposition signals attacker-generated mail — the RUA-DECODE-THREAT-VOCABULARY companion to this aggregate-reports reference for the operator population reaching the source_ip attribution decision point in RUA-row triage. Where THIS page documents the universal RFC 7489 §7.2 aggregate-report XML schema plus per-row decode methodology in infrastructure-agnostic protocol terms (source_ip, count, policy_evaluated/dkim, policy_evaluated/spf, auth_results, policy_evaluated/reason/type override codes), the email-security glossary documents the THREAT-CLASS TAXONOMY the operator needs when translating an unrecognised source_ip row from "protocol-decode complete" to "attribution-correctness complete": lookalike domain rows appear in the operator's RUA as identifiers/header_from organizational-domain entries with Unicode-homoglyph / typo-squatting / TLD- swap patterns differing from the operator's apex domain by one or two characters, account-compromise BEC rows appear as spf=pass + dkim=pass + DMARC-aligned entries from source_ip addresses the operator does recognise but during unexpected sending windows or to unexpected recipient sets, APT / DKIM-replay rows appear as repeated dkim=pass entries with the same signature against multiple recipient sets in temporal patterns inconsistent with legitimate mail flow, compromised- ESP-account rows appear as source_ip entries from the operator's own ESP infrastructure but during sending windows the operator did not author, spear phishing / whaling rows appear as identifiers/header_from entries matching the operator's executive- impersonation pattern in display-name construction, and vendor invoice fraud rows appear in the operator's RUA as compromised-partner source_ip entries whose protocol-layer authentication passes but whose business- context attribution fails. Read the email-security glossary when this aggregate-reports decode workflow reaches an unrecognised source_ip row that protocol-decode alone cannot attribute — the glossary is the authoritative reference for the threat-class taxonomy that determines whether the next step is operator-side authentication hardening, ESP-vendor remediation, treasury-team notification, or full incident-response escalation.
• DMARC monitoring — the RUA-AGGREGATE-REPORT-STREAM-AS-PRIMARY-INPUT-TO-CONTINUOUS-OBSERVABILITY-INFRASTRUCTURE-COMPANION spoke to this DMARC-aggregate-reports XML-schema reference. Where THIS page documents the RFC 7489 §7.2 RUA aggregate report XML envelope structure (report_metadata, policy_published, record arrays with row + identifiers + auth_results, plus the Appendix-C XSD enumerating policy_evaluated/disposition, dkim/result, spf/result, and the per-source_ip aggregation grain), the DMARC-monitoring deployment spoke documents the OPERATIONAL CONSUMER of the aggregate-report stream this page documents — the dashboard / alert / SLO-threshold / drift-detection infrastructure an operator runs on top of the parsed XML stream to surface the ALIGNMENT-PASS-RATE, the DISPOSITION-DISTRIBUTION, the SOURCE_IP-ANOMALY-DETECTION, and the per-third-party-sender DKIM-aligned-pass- rate-by-cohort drift trends in time-windowed aggregations. The monitoring spoke is the canonical reference for the per-phase KPI thresholds an operator uses to gate the DMARC rollout sequence (p=none → p=quarantine → p=reject) on alignment-pass-rate plateau evidence derived from the aggregate-report stream documented here, plus the per-tenant / per-third-party-sender ALERT-RULES that fire when a previously-aligned sender cohort drifts below threshold (a new-third-party-ESP-onboarding-without- DKIM-aligned-publication regression, a DKIM-selector-rotation-misconfiguration regression, an envelope-MAIL-FROM-rewriter-breaking-SPF- alignment regression). The monitoring spoke is structurally distinct from the DMARC-Analyzer-Dashboard tool linked below — the dashboard is THIS product's 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-report XML rows; the monitoring spoke documents the SLO-threshold / on-call-alert-routing / drift-detection-windowing / third-party-sender-attribution evidence-aggregation discipline that elevates per-row visualisations into a continuous-monitoring posture). Read the monitoring spoke alongside this page when designing the observability infrastructure for a domain's DMARC posture — the aggregate-report XML decode pipeline described here is the INPUT to the monitoring posture documented in the monitoring spoke, and the monitoring spoke is the canonical reference for WHICH metrics derived from the aggregate-report stream feed which operational decisions (rollout-phase advancement, regression alerting, third-party-sender remediation escalation).
• DMARC Analyzer Dashboard — ingests aggregate (RUA) and forensic (RUF) reports via the includes/DmarcParser.php and includes/ForensicReportParser.php pipelines.
• Email spoofing — the RUA-AGGREGATE-REPORT-AS-PRIMARY- SPOOFING-CAMPAIGN-DETECTION-EVIDENCE- STREAM companion to this aggregate- reporting protocol reference. Where THIS page documents the daily-aggregated per-source_ip per-disposition-action row schema (RFC 7489 §7.2 + Appendix C XSD — record/row/source_ip with the originating IP cohort, record/row/count with the per-IP per-disposition aggregated message count, record/row/policy_evaluated/ disposition with the receiver's applied action (none / quarantine / reject), record/row/policy_evaluated/ dkim + spf with the aligned-pass-vs-fail per-mechanism verdict, record/identifiers/header_from with the From: organisational-domain) the receiver POSTs to the publisher's rua=mailto:dmarc-aggregate@… destination once-daily, the email-spoofing spoke is the DETECTION-PATTERN-CATALOGUE companion documenting the SEVEN distinct per-spoofing-variant RUA-row signatures that surface ongoing spoofing-campaign activity at the publisher's domain: (i) direct-domain CEO-fraud / invoice-fraud variants surface as RUA rows with header_from = publisher's organisational-domain, source_ip from a residential-proxy / freshly-rented-VPS / compromised-mailbox cohort, dkim = fail, spf = fail, disposition = reject (at p=reject publishers) or quarantine (at p=quarantine) or none (at p=none) — the row count itself is the campaign- volume signal, surging from baseline background-noise (0-3 unauthenticated messages per day) to campaign-scale (hundreds to thousands per day) within 24-48 hours of campaign onset; (ii) lookalike-domain campaigns (attacker uses yourcornpany.com as the From: domain) do NOT surface in the publisher's RUA stream at all because the receiver POSTs RUA to the DMARC record of the From: domain (the attacker's lookalike, which has no DMARC record or one with no rua= tag) — the email-spoofing spoke documents the cross-publisher RUA-blindness pattern and the brand-protection / domain- monitoring services that close this detection gap; (iii) compromised- account campaigns surface as RUA rows with header_from = publisher domain, source_ip = LEGITIMATE publisher- authorized cohort, dkim = pass, spf = pass, disposition = none — the message authenticates correctly because it WAS sent through the legitimate signing-and-relay infrastructure with stolen credentials — RUA cannot distinguish this from legitimate traffic at all, the spoofing-detection signal must come from compromised-account-detection systems (anomalous-IP login, impossible-travel, sudden-volume-anomaly alerts) layered ABOVE the DMARC authentication layer; (iv) the per-source_ip cohort attribution in record/row/source_ip is the load-bearing detection signal — a sudden surge in source_ip rows from previously-unseen IP cohorts with dkim=fail / spf=fail is the unmistakable signature of an active direct-domain spoofing campaign and the trigger for SIRT activation. Read the email-spoofing catalogue when authoring the RUA-stream operational detection playbook — the per-variant RUA-row signatures and the cross-variant detection-coverage matrix the spoke documents enables triage of a RUA-row anomaly into a specific spoofing-variant and the corresponding per-variant response plan (publisher- domain SIRT activation vs vendor-management escalation vs compromised-account credential-rotation vs lookalike-domain UDRP filing).
• How attackers bypass weak DMARC — the AGGREGATE-REPORT-AS-OBSERVABILITY- CHANNEL-SURFACING-ATTACKER-BYPASS- ATTEMPTS-AT-PUBLISHER-FORENSIC- DASHBOARD companion to this aggregate- reporting protocol reference. Where THIS page documents the daily-aggregated per-source_ip per-disposition-action row schema (RFC 7489 §7.2 + Appendix C XSD — record/row/source_ip with the originating IP cohort, record/identifiers/header_from with the published-from-header organisational-domain, record/row/policy_evaluated/disposition with the receiver's enforcement-tier verdict, the per-record SPF + DKIM verdict pair under auth_results), the attacker-bypass spoke documents how EACH of the structural attacker-bypass- vector classes the publisher must defend against produces a STRUCTURALLY-DISTINCT row-signature in the aggregate-report feed THIS page documents — the feed becomes the primary EVIDENCE STREAM for detecting ongoing attacker-bypass-campaign activity. FOUR structurally-distinct AGGREGATE-REPORT-VS-ATTACKER-BYPASS- OBSERVABILITY dimensions emerge from cross-mapping the per-record row schema against the attacker-bypass-vector taxonomy. (1) Per-source_ip record-level visibility of unaligned- but-policy-evaluated-pass attacker- bypass attempts at the policy_evaluated/spf=pass AND policy_evaluated/dkim=pass BUT source_ip ∉ publisher's expected egress IP set row- signature — the bypass-spoke documents the attacker-bypass class where an attacker who has captured a legitimately-signed DKIM message (or forged an aligned SPF macro via an ESP-customer cohabitant attack) produces a DMARC=pass-aligned verdict from a source_ip the publisher has NEVER authored sending from. The aggregate-report row records the anomalous source_ip + aligned-verdict combination as a PERMANENT EVIDENCE SIGNATURE — the bypass-spoke documents the attack-class taxonomy that maps each source_ip cohort to its attacker-bypass-vector class. THIS page's per-source_ip row granularity is the publisher-side observability primitive the bypass-spoke proves determines this attack-class's detection feasibility. (2) Per-disposition record granularity reveals attacker-bypass attempts that policy enforcement already mitigated at the disposition=none vs disposition=quarantine vs disposition=reject row-signature — the bypass- spoke documents how the attacker- bypass-vector ceiling DROPS as the publisher's policy advances from p=none through p=quarantine to p=reject. The aggregate- report row's disposition field at quarantine or reject is the publisher's EVIDENCE that the attacker-bypass attempt was mitigated at receiver-side policy-enforcement time — but the row's PRESENCE in the report still records the attacker's attempted-bypass intent. THIS page's disposition-action documentation per RFC 7489 §6.3 is the publisher-side observability primitive the bypass- spoke proves determines this attempted-vs-successful classification. (3) Per-fromHeader record granularity surfaces cousin-domain attacker-bypass attempts at the header_from-organisational- domain-vs-publisher-domain-Lookalike- distance row-signature — the bypass-spoke documents the cousin- domain attacker-bypass class (paypa1-vs-paypal punycode lookalike, rnicrosoft-vs-microsoft visual- confusion, target.com.attacker.tld sub-domain-impersonation). The aggregate-report row records the attacker's chosen lookalike header_from VERBATIM — only domains the receiver configured to send aggregate reports FOR (the protected publisher's org-domain) will surface, but per-receiver publisher_published_domain field provides the publisher-side cross-reference. THIS page's header_from-vs-policy-published-domain documentation per RFC 7489 §4.1 is the publisher-side observability primitive the bypass-spoke proves determines this cousin-domain attack-class's cross-receiver visibility horizon. (4) Per-source_ip volume- baseline-deviation reveals attacker- bypass-campaign-detection at the per-source_ip per-day per-disposition count-time-series row-signature — the bypass-spoke documents how attacker-bypass-vector exploitation operates as a CAMPAIGN at scale — an attacker doesn't send one bypass message, they send thousands across a target-receiver cohort. The aggregate-report feed's per-source_ip per-day per-disposition count granularity is the time-series substrate the publisher's RUA-consumer applies baseline-deviation detection over. A source_ip with a previously-zero baseline that suddenly emits 10,000 per-day messages with header_from of the publisher's protected domain is an attacker-bypass campaign in progress — THIS page's count-time- series documentation per RFC 7489 §7.2.1 is the publisher-side observability primitive the bypass- spoke proves determines this campaign- detection class's signal-to-noise floor. Read the attacker-bypass spoke alongside THIS page when configuring the publisher's RUA-consumer infrastructure: this page tells you WHAT the aggregate-report feed REPORTS at the protocol layer, the bypass-spoke tells you WHAT ATTACK-CLASS each row-signature EVIDENCES against the publisher's threat-model AND WHY the per-source_ip per-disposition per-fromHeader row schema functions as an active per- message attacker-bypass-attempt evidence stream.
• TLS-RPT record syntax deep dive — the PARALLEL-REPORTING-FEED- PUBLISHER-SIDE-DNS-RR-PAIR companion reference. Where THIS page documents the DMARC aggregate-report feed (RFC 7489 §7.2 + RFC 9091 schema) — the publisher-side rua=mailto: endpoint declared on the _dmarc.<domain> TXT-record produces daily XML/GZIP report deliveries from receiver-side reporters (Google, Microsoft, Yahoo, Comcast, AOL, Mail.ru, etc.) containing per-source-IP / per-day SPF + DKIM + DMARC alignment-disposition rollups the publisher's analyzer pipeline ingests — the TLS-RPT record-syntax spoke is the authoritative reference for the STRUCTURALLY-PARALLEL publisher-side reporting-feed DNS-RR-pair counterpart that watches the transport-layer below the message- authentication layer DMARC operates on. Both reporting feeds share the PUBLISHER-DECLARES-DNS-TXT- WITH-rua-MAILTO-ENDPOINT design pattern (RFC 8460 §3.1 explicitly models TLS-RPT record syntax on DMARC's), the DAILY-AGGREGATE-REPORT delivery cadence (per-day rollup batches arriving via SMTP at the mailto: endpoint or HTTPS POST at the https: endpoint), the FEEDBACK-LOOP role (publisher-side observability of receiver-side outcomes the publisher otherwise has zero visibility into), and the ZERO-PUBLISHER-SIDE- ENFORCEMENT property (neither record exerts policy on receivers — both are pure reporting endpoints). The feeds DIVERGE on report format and reported domain: DMARC reports use XML (compressed GZIP / ZIP) and report SPF/DKIM/DMARC per- message-alignment outcomes per source IP per day; TLS-RPT reports use JSON (per RFC 8460 §4 schema) and report per-sending-MTA SMTP-TLS handshake-success-rate + per-failure-mode classification (starttls-not-supported, certificate-host-mismatch, certificate-expired, certificate-not-trusted, validation-failure, sts-policy-fetch-error, sts-policy-invalid, sts-webpki-invalid, tlsa-invalid, dnssec-invalid) per-sending-domain per-day. The TLS-RPT record-syntax spoke documents the publisher-side authoring step (the v=TLSRPTv1 version-tag + the rua=mailto: and rua=https: report-recipient endpoint forms + the absence-of- p= policy-tag + canonical publication-ordering relative to MTA-STS deployment) that BOOTSTRAPS the transport-layer reporting feed THIS page's message-layer reporting feed runs in parallel to. Read the TLS-RPT record-syntax spoke alongside this aggregate- reports page when authoring the publisher-side reporting- feed inventory and analyzer- pipeline ingest configuration — the receiver-side feed producers of TLS-RPT reports (Google, Microsoft, Comcast, Yahoo, etc.) substantially overlap the DMARC aggregate- report producer set, and a publisher running mature DMARC analyzer infrastructure SHOULD enable TLS-RPT ingest in parallel to extend the observability surface from message-layer alone to message-layer-and-transport- layer joint surface.
• ARC (Authenticated Received Chain) explained — the PER-FORWARDER-HOP-AUTHENTICATION- PRESERVATION-CHAIN-AS-LOAD-BEARING-PER- AGGREGATE-XML-REPORT-PER-MESSAGE-PER-HOP- arc=pass-AUTH_RESULTS-EVIDENCE-ROW- VOCABULARY companion to this DMARC aggregate-report reference. Where THIS page documents the RFC 7489 §7 per- publisher per-domain DMARC aggregate-XML report-format byte-grammar reference (per-record per-source-IP per-message per-row record-set + per-row auth_results body's per-mechanism dkim= / spf= / arc= result-class evaluation evidence vocabulary + per-row policy_evaluated body's disposition + dkim + spf alignment-evaluation result vocabulary + per-record identifiers body's header_from + envelope_from + envelope_to per-message attribution vocabulary), the ARC-explained spoke is the canonical RFC 8617 per-forwarder-hop authentication- preservation primitive whose per-hop arc=pass / arc=fail authentication-result- row IS the load-bearing per-record-level per-message per-hop evidence-row vocabulary the per-row auth_results body of the per-publisher per-domain aggregate-XML report-stream this page documents the parsing-and-attribution pipeline of at four per-aggregate-XML- record-level-to-ARC-chain-evidence coupling dimensions: (i) per-row auth_results-body arc=pass / arc=fail result-row as load-bearing per-forwarder- hop ARC-chain-pass-rate-attribution- primitive in per-publisher per-domain aggregate-XML report-stream — every per-publisher per-domain aggregate- XML report-stream the per-record per-row auth_results body's arc= mechanism result-row vocabulary documents per-hop ARC-chain pass-vs-fail attribution evidence; the per-publisher per-domain per-forwarder-hop ARC-chain pass-vs-fail attribution evidence the ARC-explained spoke documents the per-hop chain- mechanism of IS the load-bearing per- publisher per-domain per-day per-source-IP per-message per-hop arc=-result-row attribution primitive the per-publisher per-domain aggregate-XML report-stream documents the parsing-and-attribution pipeline of; (ii) per-row policy_evaluated-body local_policy_override comments as load- bearing per-forwarder-hop ARC-trusted- sealer override-attribution vocabulary in per-publisher per-domain aggregate-XML report-stream — every per- publisher per-domain aggregate-XML report-stream's per-record per-row policy_evaluated body's local_policy_ override reason / comment vocabulary documents per-forwarder-hop ARC-trusted- sealer override-application evidence; the per-receiver-side Gmail / Microsoft 365 Exchange Online / ProtonMail / Yahoo Trusted-ARC-Sealer-list override- application (per-row local_policy_override type=arc_pass / reason=arc-trusted-sealer) IS the load-bearing per-publisher per- domain per-forwarder-hop alignment- preservation override-evidence vocabulary the per-publisher per-domain aggregate- XML report-stream documents the parsing- and-attribution pipeline of; (iii) per-message-multi-hop ARC-chain- validation-result aggregate per-record attribution surface as load-bearing per- forwarder-hop per-publisher per-domain chain-validation result-class attribution primitive — every per-publisher per-domain aggregate-XML report-stream's per-record per-message per-hop ARC-chain- validation-result (cv=pass / cv=fail / cv=none) aggregate per-record per-message per-hop attribution surface documents per-forwarder-hop per-publisher per- domain chain-validation-result evidence; the per-publisher per-domain per-forwarder- hop chain-validation-result aggregate attribution surface the ARC-explained spoke documents the per-hop ARC-chain- evaluation primitive of IS the load- bearing per-publisher per-domain per-day per-source-IP per-message per-hop chain- validation result-class attribution primitive the per-publisher per-domain aggregate-XML report-stream documents the parsing-and-attribution pipeline of; (iv) per-publisher per-domain per- forwarder-hop ARC-trusted-sealer-coverage- rate as load-bearing per-publisher per- domain per-day per-receiver-cohort alignment-loss-mitigation-effectiveness attribution evidence in per-publisher per-domain aggregate-XML report-stream — every per-publisher per-domain aggregate-XML report-stream's per-record per-message per-source-IP per-hop ARC- trusted-sealer-coverage-rate aggregate per-publisher per-domain attribution evidence documents per-publisher per- domain per-forwarder-hop ARC-trusted- sealer-coverage-rate per-receiver-cohort alignment-loss-mitigation-effectiveness per-day aggregate evidence; the per- publisher per-domain per-forwarder-hop ARC-trusted-sealer-coverage-rate per- receiver-cohort alignment-loss-mitigation- effectiveness per-day aggregate evidence IS the load-bearing per-publisher per- domain per-day per-receiver-cohort alignment-loss-mitigation-effectiveness attribution primitive the per-publisher per-domain aggregate-XML report-stream documents the parsing-and-attribution pipeline of. Read the ARC-explained spoke ALONGSIDE this DMARC aggregate- report reference whenever a per-publisher per-domain per-record per-row per-hop arc=-result-row / local_policy_override- type=arc_pass / cv=-chain-validation- result attribution question emerges — THIS page gives the per-publisher per- domain aggregate-XML report-format byte- grammar parsing-and-attribution pipeline, the ARC-explained spoke gives the canonical per-forwarder-hop ARC-chain primitive every per-row per-hop arc=- evidence-row / per-row policy_evaluated- body local_policy_override-attribution / cv=-chain-validation-result-attribution consumes as the load-bearing per- forwarder-hop authentication-preservation primitive.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC results plus the alignment evaluation — complementary to aggregate-report data when debugging individual messages.
• Domain Security Checker — live DNS lookups for the DMARC record and the rua= / ruf= destinations.
• DMARC troubleshooting — the RUA-STREAM-AS-DIAGNOSTIC-SOURCE-OF- TRUTH companion to THIS aggregate-report XML schema reference. Where THIS page documents the RFC 7489 §7.2 + Appendix C aggregate- report XML schema (the <record> element's per-source-IP <row> with <count> / <policy_evaluated> / <auth_results> nesting, the <identifiers> <header_from> domain, the <policy_published> tag sub-tree) as the DATA-MODEL the receiver emits, the troubleshooting spoke documents the SYMPTOM-DRIVEN debugging playbook whose per-symptom root-cause attribution depends ENTIRELY on the per-record per-source-IP per-disposition data the aggregate-report XML schema this page documents emits. Four XML-SCHEMA-VS-TROUBLESHOOTING-PLAYBOOK axes the troubleshooting spoke documents that THIS page is the data-model reference for: (1) <source_ip>- per-row symptom partition — the troubleshooting spoke's "DMARC verdict = fail despite SPF = pass + DKIM = pass" symptom partitions the <record> rows by <source_ip> (per RFC 7489 §7.2.1.4) to attribute the per-source-IP DMARC-fail-rate distribution to the per-source-IP root cause (legitimate unsigned-tenant / shadow-IT discovery / attacker spoofing); the <source_ip> element documented in this page's XML schema is the partition key the troubleshooting playbook depends on; (2) <policy_evaluated> + <auth_results> divergence diagnosis — the troubleshooting spoke's "verdict-vs-result divergence" symptom traces the per-row <policy_evaluated> disposition (none / quarantine / reject) AGAINST the <auth_results> <spf> result + <dkim> result + <auth_results> domain attribution per-row to attribute the alignment-mode-mismatch root- cause; both elements are documented in this page's XML schema; (3) <header_from>- scoped subdomain coverage diagnosis — the troubleshooting spoke's "subdomain unexpectedly enforced" symptom traces the per-record <identifiers> <header_from> domain AGAINST the <policy_published> <sp> + <p> organisational-domain inheritance rule per row to attribute the sp=-inheritance root cause; (4) per-reporter <org_name> coverage-gap diagnosis — the troubleshooting spoke's "no rua reports from Microsoft / Yahoo / Gmail" symptom traces the <report_metadata> <org_name> / <email> / <report_id> + date-range elements per-reporter to attribute the per-receiver rua-delivery-failure root cause (rua-mailbox-domain MX failure / receiver- side rua= external-domain verification gap / per-receiver SLO drift). Read THIS page to UNDERSTAND the rua XML schema; read the troubleshooting spoke when OPERATING on the per-record per-source-IP per-disposition data the schema emits.
• DMARC for Google Workspace — the WORKSPACE-TENANT-DOWNSTREAM-CONSUMER companion to this RFC 7489 §7.2 XML aggregate-report reference. Where THIS page documents the provider-agnostic record-level evidence-row vocabulary emitted by every conforming aggregate reporter, the Workspace deployment spoke is the WORKSPACE-TENANT-SPECIFIC operational consumer at FOUR per- Workspace-tenant-to-aggregate-evidence coupling dimensions: (i) per- Workspace-tenant rua=mailto:dmarc@<domain> mailbox configuration in the _dmarc TXT record published through Workspace DNS-manager infrastructure — the Workspace spoke documents the Workspace-tenant- specific publication step that BOOTSTRAPS the per-receiver per-source- IP per-day rua evidence stream THIS page documents the schema for; (ii) per-Workspace-tenant Workspace- emitted SPF-aligned-pass-row aggregation via record-level row/policy_evaluated/spf=pass + row/auth_results/spf/domain=<workspace-tenant-domain> evidence-row attribution against Workspace-managed include:_spf.google.com envelope-MAIL-FROM emission — the Workspace spoke documents the per- Workspace-tenant SPF-alignment-pass-row observability surface operators consume to confirm Workspace-managed envelope-MAIL-FROM alignment with Workspace-tenant From:<domain> header; (iii) per-Workspace-tenant google._domainkey DKIM- aligned-pass-row aggregation via record- level row/policy_evaluated/dkim=pass + row/auth_results/dkim/domain=<workspace-tenant-domain> + row/auth_results/dkim/selector=google evidence-row attribution against Workspace-managed google._domainkey CNAME publication discipline — the Workspace spoke documents the per- Workspace-tenant DKIM-alignment-pass-row observability surface operators consume to confirm Workspace-managed google._domainkey signing- key alignment with the Workspace-tenant domain after the CNAME publication step; (iv) per-Workspace-tenant per- receiver per-source-IP per-day post- cutover regression-monitoring via record-level row/policy_evaluated/disposition=reject aggregation cross-referenced against Google Postmaster Tools per-Workspace- tenant sender-reputation telemetry — the Workspace spoke documents the per-Workspace-tenant post-cutover regression-detection workflow operators execute after Phase-5 cutover on Workspace tenants. Read the Workspace deployment spoke ALONGSIDE this aggregate-reports schema reference when consuming Workspace-tenant rua evidence — the spoke is the canonical Workspace- tenant-specific downstream-consumer reference whose Workspace-tenant- specific record-level evidence-row attribution patterns are the LOAD- BEARING per-Workspace-tenant operational consumption discipline every Workspace- tenant aggregate-evidence-driven decision depends on.
• DMARC for Microsoft 365 — the M365-TENANT-DOWNSTREAM-CONSUMER companion to this RFC 7489 §7.2 XML aggregate-report reference. Where THIS page documents the provider-agnostic record-level evidence-row vocabulary emitted by every conforming aggregate reporter, the M365 deployment spoke is the M365-TENANT-SPECIFIC operational consumer at FOUR per-M365-tenant-to- aggregate-evidence coupling dimensions: (i) per-M365-tenant rua=mailto:dmarc@<domain> mailbox configuration in the _dmarc TXT record published through M365 tenant DNS- manager infrastructure (Microsoft 365 admin center → Settings → Domains, or the customer-owned authoritative DNS zone delegated to the tenant) — the M365 spoke documents the M365- tenant-specific publication step that BOOTSTRAPS the per-receiver per-source- IP per-day rua evidence stream THIS page documents the schema for; (ii) per-M365-tenant Exchange- Online-emitted SPF-aligned-pass-row aggregation via record-level row/policy_evaluated/spf=pass + row/auth_results/spf/domain=<m365-tenant-domain> evidence-row attribution against Exchange-Online-managed include:spf.protection.outlook.com envelope-MAIL-FROM emission from <tenant>.mail.protection.outlook.com source IPs — the M365 spoke documents the per-M365-tenant SPF- alignment-pass-row observability surface operators consume to confirm Exchange-Online-managed envelope-MAIL- FROM alignment with M365-tenant From:<domain> header; (iii) per-M365-tenant selector1._domainkey + selector2._domainkey DKIM-aligned-pass-row aggregation via record-level row/policy_evaluated/dkim=pass + row/auth_results/dkim/domain=<m365-tenant-domain> + row/auth_results/dkim/selector=selector1 / selector2 evidence-row attribution against Exchange-Online- managed CNAME publication discipline pointing at the <tenant>.onmicrosoft.com signing-key delegation — the M365 spoke documents the per-M365- tenant DKIM-alignment-pass-row observability surface operators consume to confirm Exchange-Online-managed selector1 / selector2 signing-key alignment with the M365-tenant domain after the CNAME publication + Defender-portal DKIM-enablement steps; (iv) per-M365-tenant per- receiver per-source-IP per-day post- cutover regression-monitoring via record-level row/policy_evaluated/disposition=reject aggregation cross-referenced against Microsoft Defender for Office 365 Threat Explorer per-M365-tenant sender- telemetry — the M365 spoke documents the per-M365-tenant post- cutover regression-detection workflow operators execute after Phase-5 cutover on M365 tenants. Read the M365 deployment spoke ALONGSIDE this aggregate-reports schema reference when consuming M365-tenant rua evidence — the spoke is the canonical M365-tenant-specific downstream- consumer reference whose M365-tenant- specific record-level evidence-row attribution patterns are the LOAD- BEARING per-M365-tenant operational consumption discipline every M365- tenant aggregate-evidence-driven decision depends on.
• SPF 10-DNS-lookup limit — the canonical upstream-root-cause diagnostic-reference documenting how the RFC 7208 §4.6.4 ten-DNS-lookup ceiling (counted recursively across include:, a, mx, ptr, exists:, and redirect= mechanisms during receiver-side SPF evaluation) is the canonical upstream root-cause class producing the per-row row/auth_results/spf/result=permerror verdict AND the per-row row/policy_evaluated/spf=fail verdict that aggregate-report consumers observe in the RFC 7489 §7.2 XML evidence stream THIS page documents the schema of — a single shared-pool include-graph exceedance produces spf=permerror across EVERY source_ip × From:-domain × disposition row the receiver emits per its 24-hour-batch cadence, which then propagates to the policy_evaluated.spf=fail verdict regardless of legitimate publisher provenance because the RFC 7489 §6.6.2 alignment-evaluation step requires an spf=pass UPSTREAM verdict to evaluate. Read the SPF-lookup-limit spoke ALONGSIDE this aggregate-reports schema reference when the per-row auth_results/spf/result=permerror + policy_evaluated.spf=fail pattern dominates the per-domain row stream — the spoke documents the four canonical publisher-side remediation strategies (envelope-domain split, third-party-include flattening via static IP/CIDR publication, SPF-record macro consolidation, and the redirect=-as-single-lookup- replacement pattern) that restore spf=pass to the per-row evidence stream and unblock the rollout-advancement gate-keeping decision discipline that depends on the aggregate-report evidence schema THIS page documents.
• DKIM selectors explained — the PER-ROW-auth_results.dkim.selector- FIELD-AS-LOAD-BEARING-DOWNSTREAM-CONSUMER- OF-PUBLISHER-SIDE-DKIM-SELECTOR-NAMESPACE- PUBLICATION companion documenting the DKIM selector-namespace primitive whose per-publisher per-signer per-selector TXT-record publication produces every <auth_results><dkim><selector> per-row field this aggregate-report schema serialises. Where THIS page documents the RFC 7489 §7.2 + Appendix C aggregate-report XML schema (the <feedback> envelope, per-record block fields, per-row <auth_results><dkim> verdict decode), the dkim_selectors_ explained spoke documents the DKIM-SELECTOR-NAMESPACE PRIMITIVE the per-row <selector> sub-element identifies: the <selector>._domainkey.<d> TXT-record namespace, the per-provider canonical selector catalogue (Microsoft 365's selector1 / selector2, Google Workspace's google, cPanel's default, SendGrid's s1 / s2), the dual-selector rotation publishing-window / cutover- window / retirement-window mechanics, and the seven selector-publication failure modes (NXDOMAIN on selector, stale t=y still emitted, empty p= revocation, truncated p=, key-rotation mid-cutover gap, selector-reuse across operator-distinct signers, SERVFAIL on selector zone). FOUR structurally-distinct PER-ROW-auth_ results.dkim.selector-FIELD-DEPENDENCY dimensions every aggregate-report consumer encounters: (i) per- row <auth_results><dkim><selector>X</selector> sub-element AS LOAD-BEARING-PER-ROW SIGNER-IDENTITY-ATTRIBUTION INPUT — every aggregate-report row in the per-receiver per-publisher per-day XML stream THIS page documents carries the per-signer <selector> sub-element whose value (M365's selector1 vs Workspace's google vs SendGrid's s1) the dkim_selectors_ explained spoke catalogues as the canonical per-provider signer-identity- attribution-tag; the per-row sender-inventory partition the aggregate-report consumer builds from the <source_ip> + <header_from> + <selector> triple depends on the selector-namespace primitive being correctly published per-signer for the attribution to resolve; (ii) per-row <auth_results><dkim><result>permerror</result> AS LOAD-BEARING-PUBLISHER-SIDE- SELECTOR-PUBLICATION-DEFECT-EVIDENCE — the per-row dkim=permerror verdict the aggregate-report schema THIS page documents maps 1:1 to the seven selector-publication failure modes the dkim_selectors_explained spoke enumerates: a stable per-row dkim=permerror + non-empty <selector> pattern diagnoses the publisher-side selector- publication defect at the canonical TXT-record level the selectors- explained spoke documents; (iii) per-row <policy_evaluated><dkim>fail</dkim> on third-party SaaS sender vendor IPs AS LOAD-BEARING-MULTI-SIGNER-SELECTOR- CUSTODY-ISOLATION-DEFECT-EVIDENCE — the per-row policy_evaluated.dkim=fail + auth_results.dkim.selector=X pattern surfaces selector-custody- isolation defects (selector-reuse across operator-distinct signers, or a third-party SaaS sender signing with the wrong d=-domain organisational alignment) the dkim_selectors_explained spoke catalogues as the canonical multi- signer custody-isolation invariant violation; (iv) per-row <auth_results><dkim> verdict-shift mid-rotation AS LOAD- BEARING-DUAL-SELECTOR-CUTOVER- OBSERVABILITY-EVIDENCE — the per-receiver per-publisher per-day aggregate-report row stream is the canonical observability surface for the dual-selector rotation publishing- window / cutover-window / retirement- window mechanics the dkim_selectors_ explained spoke documents (per-rotation per-receiver per-selector DKIM-pass- rate baseline-shift evidence; new- selector traffic-ramp empirical confirmation; old-selector retirement zero-traffic confirmation; rollback- trigger anomaly evidence). Read the dkim_selectors_explained spoke ALONGSIDE this aggregate-reports schema reference when the per-row <auth_results><dkim> sub-element decode requires the publisher-side selector-namespace- primitive reference the spoke catalogues — the spoke is the canonical PUBLISHER-SIDE-DKIM- SELECTOR-NAMESPACE-PUBLICATION REFERENCE the aggregate-report consumer needs to ground every per- row selector-field interpretation in the per-provider publication discipline that produced it.
• DKIM key rotation — the PUBLISHER-SIDE KEY-ROTATION-CADENCE companion to this aggregate-report data-stream schema reference. Where THIS page documents the RFC 7489 §7.2 XML aggregate-report record-level evidence vocabulary (per-row auth_results.dkim.selector + auth_results.dkim.result fields), the DKIM-key-rotation spoke documents the publisher-side per-selector key-rotation cadence whose old-and-new selector grace- period coexistence discipline produces the per-row selector field-value transitions the aggregate-report consumer observes and MUST interpret correctly (old-selector rows tapering off, new-selector rows ramping up during the rotation window). Read THIS page when DECODING the per-row evidence stream schema; read the DKIM-key-rotation spoke when AUTHORING the per-selector rotation cadence whose publisher-side operational discipline produces the per-row selector-field evidence the aggregate-report consumer interprets.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- TXT-RR-BYTE-GRAMMAR-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-UPSTREAM- DETERMINANT-OF-PER-ROW-AUTH-RESULTS- SPF-FIELD-EVIDENCE companion documenting the per-publisher per- domain SPF TXT-RR byte-grammar publication discipline at the authoritative DNS zone apex boundary whose per-record per-token byte- correctness IS the load-bearing upstream determinant of the per-row auth_results.spf.result and policy_evaluated.spf and per-row source_ip SPF-aligned-pass-rate field evidence the per-publisher per-domain RUA- aggregate-XML evidence-stream THIS page documents the schema of materially consumes. Where THIS page documents the RFC 7489 §7.2 + Appendix C aggregate- report XML schema (the per-publisher per-domain per-receiver per-day RUA XML evidence-stream covering report_metadata + policy_published + per-record row with source_ip + count + policy_evaluated.disposition + policy_evaluated.dkim + policy_evaluated.spf + per-record auth_results with per-protocol verdict fields (auth_results.spf.result ∈ {none, neutral, pass, fail, softfail, temperror, permerror})), the SPF- DNS-syntax spoke is the LOAD-BEARING UPSTREAM SPF-publication-discipline companion whose four per-SPF-DNS- syntax-publication-discipline-to- aggregate-report-row-field-coupling dimensions structurally couple per- publisher per-domain SPF authoring discipline to per-publisher per-domain RUA-aggregate-XML row-field outcomes: (i) per-publisher-per-domain- SPF-TXT-RR-byte-grammar-defects-as- canonical-root-cause-of-per-row- auth_results.spf.result=permerror- verdicts — per-publisher per- domain SPF TXT-RR byte-grammar publication discipline defects (typo'd v=spf1 version-prefix-byte sequence, per-mechanism-token byte- corruption, multiple v=spf1 TXT-RR siblings at the same FQDN violating RFC 7208 §3.2 per-domain per- FQDN cardinality constraint, per-record TXT-RR byte-length budget exhaustion) produce per-row auth_results.spf.result=permerror verdicts in every per-receiver per-day RUA-aggregate-XML row this page documents the schema of; (ii) per-publisher-per-domain-SPF- mechanism-choice-as-load-bearing- determinant-of-per-row-source_ip-vs- per-row-spf=pass-aligned-rate — per-publisher per-domain SPF mechanism-choice authoring discipline (the per-record per-mechanism authoring choice among include: / ip4: / ip6: / a / mx tokens) directly DETERMINES the per- publisher per-domain authorised sending-IP set; per-row source_ip field evidence in the per-receiver per-day RUA- aggregate-XML evidence-stream surfaces whether each per-publisher per-message per-source-IP achieves auth_results.spf.result=pass AND the per-row aligned-vs-unaligned- From-org-domain SPF-alignment outcome the per-publisher per-domain DMARC evaluation discipline composes; (iii) per-publisher-per-domain-SPF- qualifier-prefix-byte-choice-as-load- bearing-determinant-of-per-row- auth_results.spf.result=softfail-vs- fail-vs-neutral-verdicts — per-publisher per-domain SPF qualifier- prefix-byte choice (the 4-prefix-byte choice + / - / ~ / ? preceding each mechanism token) directly DETERMINES the per-row SPF-verdict classification when the per-message per- source-IP does not match an explicit per-publisher SPF-authorising mechanism; the per-record end-of-record ~all vs -all vs ?all per-record qualifier-prefix-byte choice is THE single most consequential per-publisher per-domain SPF authoring discipline decision determining whether per-source- IP-set per-row evidence surfaces as auth_results.spf.result=softfail vs fail vs neutral; (iv) per-publisher-per-domain- SPF-modifier-choice-as-load-bearing- determinant-of-per-publisher-per-domain- SPF-evaluation-evaluation-flow — per-publisher per-domain SPF modifier-choice authoring discipline (the 2-modifier choice redirect= / exp=) controls per- receiver-side per-message per-source-IP SPF-evaluation flow (per-record evaluation control-flow handoff to another per-domain SPF record under redirect=, per-record explanation-string customisation under exp=); per-publisher per- domain SPF modifier-choice defects produce per-row auth_results.spf.result verdicts whose per-receiver-side evaluation flow CANNOT be reconstructed from per-record per-mechanism-token byte-grammar evidence alone. Read THIS page when CONSUMING per-publisher per- domain RUA-aggregate-XML evidence- stream rows containing per-row auth_results.spf.result and policy_evaluated.spf field evidence; read the SPF-DNS- syntax spoke when AUTHORING per- publisher per-domain SPF TXT-RR byte- grammar publication discipline as the LOAD-BEARING UPSTREAM SPF-publication- discipline whose per-record per-token byte-correctness DIRECTLY DETERMINES the per-publisher per-domain RUA- aggregate-XML row-field SPF-verdict outcomes.
• MTA-STS policy-file syntax — the PER-PUBLISHER-PER-DOMAIN- RFC-8461-MTA-STS-POLICY-FILE-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- PEER-TRANSPORT-LAYER-AGGREGATE-REPORTING- PROTOCOL-PUBLICATION companion to this DMARC aggregate-XML report-schema reference. Where THIS page documents the RFC 7489 §7.2 application-layer DMARC aggregate-XML rua-report schema (per- record auth_results.dkim / auth_results.spf / policy_evaluated / source_ip per-row field protocol), the MTA-STS-policy-syntax spoke is the peer per-publisher per-domain RFC 8461 transport-layer policy-file publication discipline whose per-policy- file byte-grammar correctness contract determines the per-publisher per-domain per-receiver per-session per-MX hop TLS- RPT failure-details aggregation row emission at FOUR per-aggregate-reporting- protocol coupling dimensions: (i) per-publisher per-domain peer aggregate-reporting-protocol-publication- layer parallelism — the RFC 7489 §7.2 DMARC aggregate-XML rua- report stream is the application-layer per-publisher per-domain per-message authentication-and-alignment evidence- stream THIS page documents the schema of, the RFC 8460 TLS-RPT failure-details aggregation stream the MTA-STS-policy- syntax spoke is the publication-discipline upstream of is the transport-layer per- publisher per-domain per-receiver per- session per-MX hop encryption-and-policy- enforcement evidence-stream, and the per- publisher per-domain operator-side receiver-side aggregate-reporting-protocol ingestion discipline is the load-bearing per-layer parallel rhythm BOTH protocols share; (ii) per-publisher per- domain policy_evaluated.policy-field- at-application-layer vs MTA-STS-policy- file-mode-field-at-transport-layer policy- enforcement-state parallelism — the per-publisher per-domain DMARC aggregate-XML policy_evaluated.policy field surfaces the application-layer DMARC three-mode policy state (none / quarantine / reject) at per-message aggregation time, the per-publisher per- domain MTA-STS policy-file mode: field publishes the transport-layer MTA-STS three-mode policy state (none / testing / enforce) at per-policy-file-publication time the MTA-STS-policy-syntax spoke documents the byte-grammar of, and the per-publisher per- domain operator-side per-layer three-mode policy-state cross-layer cross-protocol coordination discipline is the load-bearing per-mode parallel rhythm BOTH protocols share; (iii) per-publisher per- domain policy-publication-syntax-correctness as load-bearing upstream determinant of receiver-side aggregate-report row emission — the per- publisher per-domain SPF TXT-RR byte- grammar correctness determines the per- receiver per-message SPF-verdict row emission in the DMARC aggregate-XML rua- report stream THIS page documents the schema of, the per-publisher per-domain MTA-STS policy-file byte-grammar correctness the MTA-STS-policy-syntax spoke documents determines the per- receiver per-session per-MX hop policy- fetch-success / sts-policy-invalid / sts- webpki-invalid / sts-policy-fetch-error failure-mode row emission in the TLS-RPT failure-details aggregation stream, and the per-publisher per-domain operator-side publication-syntax-correctness discipline is the load-bearing per-layer publication- correctness rhythm BOTH protocols share at the receiver-side aggregate-report emission boundary; (iv) per- publisher per-domain cross-protocol-aggregate-report co- ingestion as load-bearing per-publisher- per-domain operator-side cross-layer observability stream — the per-publisher per-domain operator- side per-publisher per-domain observability stream that ingests BOTH the DMARC aggregate-XML rua-report stream THIS page documents AND the TLS-RPT failure-details aggregation stream the MTA-STS-policy-syntax spoke is the publication-discipline upstream of is the load-bearing per-publisher per-domain cross-layer authentication-and-encryption observability stream every per-publisher per-domain DMARC-deployment programme requires for the per-publisher per-domain Bulk-Sender-Requirements-2024 deliverability-floor composition coverage. Read THIS page when AUTHORING per- publisher per-domain DMARC aggregate-XML rua-report ingestion discipline; read the MTA-STS-policy-syntax spoke when CO- AUTHORING the per-publisher per-domain peer transport-layer policy-file publication discipline whose per-policy- file byte-grammar correctness contract determines the per-publisher per-domain per-receiver per-session TLS-RPT failure- details aggregation row emission at the transport layer.
• Email authentication glossary — the cluster-wide canonical entity-first DefinedTermSet vocabulary reference whose per-term DefinedTerm JSON-LD entries (organizational domain, Public Suffix List, identifier alignment, strict-vs-relaxed alignment-mode, adkim=s vs adkim=r, aspf=s vs aspf=r, policy_evaluated.dkim, policy_evaluated.spf, auth_results.dkim.result, auth_results.spf.result, DKIM d=-tag, DKIM AUID, SPF MAIL FROM identifier, SPF HELO identity, RFC 7489 §7.2 aggregate-report row schema, RFC 5965 ARF forensic-report envelope) are the per-protocol-concept vocabulary substrate the per-publisher per-domain DMARC aggregate-report XML row schema THIS page documents is the load-bearing downstream consumer of. Where THIS page documents the RFC 7489 §7.2 + Appendix C per-day per-publisher per-domain aggregate-report XML row schema (the <record> block per source_ip × From:-domain × alignment- outcome combination, the <policy_evaluated> nest with dkim / spf verdict fields, the <auth_results> nest with raw DKIM/SPF result, the <source_ip> + per-row <count> per-receiver emission cadence), the email- authentication-glossary spoke is the DEFINED-TERM-DEFINITION reference documenting the canonical entity-first definition-lede vocabulary substrate every aggregate-report row field structurally instantiates. Four AGGREGATE-REPORT-SCHEMA-TO-GLOSSARY- DEFINED-TERM coupling dimensions the glossary spoke documents: (i) per-row policy_evaluated field as per-message instantiation of the identifier-alignment DefinedTerm vocabulary — the per-row policy_evaluated.dkim / policy_evaluated.spf verdict field the aggregate-XML schema THIS page documents emits is the per-message instantiation of the identifier- alignment / strict-vs-relaxed-alignment- mode / adkim=s vs adkim=r / aspf=s vs aspf=r DefinedTerm vocabulary the glossary catalogues; (ii) per-row auth_results field as per- message instantiation of the raw- authentication-result DefinedTerm vocabulary — the per-row auth_results.dkim.result / auth_results.spf.result field is the per-message instantiation of the DKIM-verification-result DefinedTerm vocabulary (pass, fail, neutral, policy, temperror, permerror — RFC 8601 §2.4.1) and the SPF-evaluation- result DefinedTerm vocabulary (none, neutral, pass, fail, softfail, temperror, permerror — RFC 7208 §2.6) the glossary catalogues; (iii) per-report policy_published field as per-publisher instantiation of the DMARC-record-tag DefinedTerm vocabulary — the per-report policy_published block emitting the v=DMARC1; p=<policy>; rua= ...; ruf=...; sp=...; pct=...; adkim=...; aspf=...; fo=...; rf=...; ri=... per-publisher per-domain DMARC-record-tag-set is the per-report instantiation of the every DMARC-tag DefinedTerm vocabulary the glossary catalogues at the per-publisher publication-discipline boundary; (iv) per-record identifiers field as per- message instantiation of the organizational-domain / Public-Suffix- List / RFC-5321-MAIL-FROM-vs-RFC-5322- From DefinedTerm vocabulary — the per-record identifiers.header_from / identifiers.envelope_from / identifiers.envelope_to field is the per-message instantiation of the RFC-5322-header-From-vs-RFC-5321- MAIL-FROM-identifier-distinction + organizational-domain + Public-Suffix- List DefinedTerm vocabulary the glossary catalogues. Read THIS page when AUTHORING the per-publisher per-domain DMARC aggregate-report XML row schema consumption discipline; read the email- authentication-glossary spoke when CO-AUTHORING the per-publisher per- domain canonical DefinedTermSet vocabulary substrate every aggregate- report row field the schema THIS page documents structurally instantiates.
• SPF qualifiers explained — the LOAD-BEARING per-publisher per-domain SPF-QUALIFIER-CHOICE-DRIVES- AGGREGATE-REPORT-SPF-VERDICT-DISTRIBUTION upstream-publisher-discipline companion documenting the four RFC 7208 §4.6.2 qualifiers (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose per-publisher per-domain choice at the terminal mechanism (typically ~all during deployment monitoring or -all after enforcement-ramp completion) directly determines the spf=pass / spf=fail / spf=softfail / spf=neutral verdict distribution surfaced in the auth_results/spf/result field of every per-record block in the aggregate-report XML schema THIS page documents. Where THIS page documents the AGGREGATE-REPORT DATA-STREAM consumption pattern (the <feedback> schema, per-record block fields, daily cadence, RUA delivery, policy_evaluated / auth_results decode), the qualifiers spoke documents the UPSTREAM PUBLISHER DISCIPLINE that produces the verdict distribution the aggregate report catalogues per-row — the qualifier choice in the publisher's SPF record IS the configuration variable whose downstream observable consequence is the per-row spf=* result field this page's schema documents. Read THIS page when READING / CONSUMING the per-publisher per-domain aggregate- report XML row-schema spf-verdict distribution; read the qualifiers spoke when AUTHORING / CHOOSING the per- publisher per-domain SPF terminal- qualifier that PRODUCES the spf-verdict distribution the aggregate-report row schema this page documents downstream- catalogues.
• MTA-STS for Google Workspace — the LOAD-BEARING per-Workspace- tenant per-custom-domain PER-WORKSPACE-TENANT-MTA-STS- PUBLICATION-AS-LOAD-BEARING-TRANSPORT- LAYER-DELIVERY-PROTECTION-DISCIPLINE- FOR-THE-PER-PUBLISHER-PER-DOMAIN-RUA- AGGREGATE-REPORT-DELIVERY-PIPELINE companion to this RUA aggregate-report payload-schema reference. Where THIS page documents the per-publisher per- domain RUA aggregate-report payload schema (the per-row source-IP / message-count / disposition / DKIM- verdict / SPF-verdict / from-domain columns and the per-report envelope org-name / report-id / date-range metadata), the GW MTA-STS spoke documents the per-Workspace-tenant per-custom-domain TRANSPORT-LAYER DELIVERY-PROTECTION discipline that gates the per-publisher per-RUA- endpoint inbound RUA aggregate-report delivery whenever the RUA endpoint is a Google-Workspace-hosted mailbox: the _mta-sts.<d> TXT-RR version + policy ID publication, the https://mta-sts.<d>/.well-known/mta-sts.txt HTTPS-policy-host file publication listing mx: *.aspmx.l.google.com as the enforced-mode MX cone, and the per-tenant mode: enforce policy-mode choice. Read the GW MTA- STS spoke when HARDENING the per- Workspace-tenant TRANSPORT-LAYER DELIVERY PROTECTION discipline for the per-publisher per-domain RUA pipeline's receive-side endpoint when that endpoint is Workspace-hosted — the GW half of the M365 ↔ GW transport-layer protection pair for the application- layer RUA aggregate-report delivery pipeline this page documents.
• DNS propagation timelines — the TTL-bounded publish-and-verify-cycle primitive whose four DNS-propagation-vs- RUA-aggregate-report-pipeline coupling dimensions THIS RUA-aggregate-evidence- stream reference materially depends on: (i) per-publisher per-domain DMARC TXT-record rua=mailto: URI publication propagation tail before per-receiver report-emitters begin sending aggregate reports to the new address — per-receiver per- resolver caches still serve the prior DMARC record (no rua= tag, or stale destination) until the prior TTL elapses, producing a per-publisher per-domain aggregate-report-stream coverage gap that can last hours to days depending on the per-publisher per-domain DMARC TXT-record TTL choice; (ii) RFC 7489 §7.1 external- destination DNS validation (_report._dmarc.<sender> TXT-record per-receiver publication discipline) STRUCTURALLY DEPENDS on per-receiver per-resolver cache TTL convergence — when a per-publisher per-domain operator authorises a third-party report-receiver via rua=mailto:reports@analyzer.example and a corresponding _report._dmarc.<sender> TXT record at the analyzer's domain, per-receiver report-emitters MUST successfully resolve BOTH records BEFORE emitting aggregate reports; per-receiver per-resolver cache TTL on EITHER record gates the per-publisher per-domain RUA- stream activation timeline this RFC 7489 §7.1 external-destination authorisation flow structurally consumes; (iii) per-publisher per-domain rua= URI rotation discipline (migrating between analyzer providers, decommissioning a deprecated rua= mailbox) STRUCTURALLY CONSUMES the dual-destination-publication overlap-window pattern parallel to per- publisher per-selector DKIM dual-selector overlap — operators publishing a comma-separated rua=mailto:old@, mailto:new@ URI list MUST maintain both destinations through the per-receiver per-resolver cache TTL window of the prior single-destination publication BEFORE retiring the old destination, otherwise per-publisher per-domain RUA-stream coverage gaps surface in the analyzer's per-receiver per-day report-count timeline; (iv) per-publisher per-domain SPF + DKIM + ARC + MTA-STS upstream- evidence-producer DNS-record propagation tail directly attributing per-receiver per-day RUA-row volume swings — every per-publisher per-domain DNS-record republication (SPF qualifier flip from ~all to -all, DKIM selector rotation, MTA-STS policy mode-flip via _mta-sts.<d> TXT-record version bump) generates post-publish per-receiver per-resolver cache TTL-bounded transient spf=permerror / spf=fail / dkim=permerror RUA-row spikes the per-publisher per- domain analytics team's regression- detection runbook MUST correlate against the per-publisher per-domain DNS-record publication timeline to distinguish legitimate propagation-tail signals from true operator-discipline regressions. Read the DNS-propagation timelines spoke alongside this RFC 7489 §7.2 aggregate-reports reference when planning per-publisher per-domain DMARC TXT-record republication that flips the rua= destination, when authoring per-publisher per-domain analyzer-migration runbooks with dual-destination overlap-window discipline, or when interpreting per- receiver per-day RUA-row volume swings immediately after upstream-evidence- producer DNS-record republication.
• DKIM for Google Workspace
• Email authentication overview
• MTA-STS vs DANE — the per-publisher per-domain transport-layer protocol-choice decision-matrix companion at four per-publisher per-domain DMARC-aggregate-report-ingestion-vs-MTA-STS-vs-DANE coupling dimensions: (i) per-publisher per-domain DMARC RUA aggregate-XML application-layer per-receiver per-day per-source-IP per-disposition evidence-row attribution stream per RFC 7489 §7.2 + Appendix C XSD IS the structurally-parallel application-layer aggregate-observability companion to per-publisher per-policy-domain TLS-RPT JSON-aggregate-report transport-layer per-day per-MX-host per-failure-class evidence-row attribution stream per RFC 8460 §4.3 the MTA-STS-vs-DANE transport-layer protocol-choice both drive failure-class catalogue divergence in (MTA-STS-enforce surfaces sts-policy-fetch-error/sts-policy-invalid/certificate-host-mismatch classes vs DANE-enforce surfaces dnssec-invalid/dane-mismatch/tlsa-invalid classes) — both per-publisher per-domain aggregate-observability evidence-row streams coordinate at the per-publisher per-domain composite cross-layer application-and-transport-layer aggregate-observability coordination boundary; (ii) per-publisher per-domain DMARC RUA aggregate-XML auth_results/spf + auth_results/dkim per-leg authentication-leg verdict-pair attribution per RFC 7489 §7.2 + Appendix C XSD IS structurally parallel per-leg-verdict-attribution observability primitive to per-publisher per-policy-domain TLS-RPT JSON-aggregate-report policy + summary + failure-details per-policy per-day per-MX-host evidence-row attribution per RFC 8460 §4.3 surfacing MTA-STS-vs-DANE protocol-choice differential coverage — both per-publisher per-domain per-leg observability evidence-row streams coordinate at the per-publisher per-domain composite per-leg-verdict-attribution observability coordination boundary; (iii) per-publisher per-domain DMARC rua=mailto: aggregate-report-URI publication-discipline per RFC 7489 §6.2 IS structurally parallel per-publisher per-domain DNS-TXT-RR aggregate-report-URI publication-discipline primitive to per-publisher per-policy-domain TLS-RPT rua=mailto: aggregate-report-URI publication-discipline per RFC 8460 §3 the MTA-STS-vs-DANE protocol-choice decision-matrix consumes — both per-publisher per-domain DNS-TXT-RR-published aggregate-report-URI publication-discipline references coordinate at the per-publisher per-domain composite aggregate-report-URI-publication-discipline coordination boundary; (iv) per-publisher per-domain DMARC RUA aggregate-XML per-receiver per-day per-source-IP per-disposition row-attribution stream surfaces per-attacker MTA-STS-vs-DANE protocol-choice exploitation via STARTTLS-strip-downgrade-vs-DNSSEC-bypass differential as per-source-IP per-day DMARC-aligned-pass-rate-distribution shape the per-publisher per-domain MTA-STS-vs-DANE protocol-choice decision-matrix surfaces the operator-actionable per-receiver-population transport-layer-protocol-coverage divergence of (German/Dutch/Czech DANE-dominant receiver-population vs Gmail/M365/iCloud/Yahoo MTA-STS-dominant receiver-population) — both per-publisher per-domain per-receiver-population transport-layer-protocol-coverage observability evidence streams coordinate at the per-publisher per-domain composite per-receiver-population transport-layer-protocol-coverage coordination boundary the DMARC aggregate-report ingestion pipeline THIS page documents the per-publisher per-domain operator-side per-receiver per-day per-source-IP attribution discipline of structurally surfaces.
• MTA-STS for Microsoft 365
• RFC 7489 §7.2 — Aggregate Reporting — the foundational aggregate- report specification.
• RFC 7489 §7.3 — Failure Reporting — the forensic (RUF) report specification.
• RFC 7489 Appendix C — Aggregate Report XSD — the formal XML schema.
• RFC 6591 — ARF for Authentication Failures — the envelope format for forensic reports.
• Microsoft SNDS + JMRP monitoring — the third leg of the sender-observability triad alongside DMARC aggregate reports and TLS-RPT: per-IP spam-filter verdicts and Junk-click complaints from Microsoft's consumer network (Outlook.com/Hotmail), fetched via the 30-day Automated Data Access key.

13. Ingest your aggregate reports now

DMARC Analyzer's ingestion pipeline at includes/DmarcParser.php parses aggregate-report XML, ZIP, and GZ formats (RFC 7489 §7.2.1.1), deduplicates by report_id + org_name, persists per-record rows to the dmarc_records table, and surfaces per-sender / per-IP / per-day aggregations in the dashboard. Forensic (RUF) reports flow through includes/ForensicReportParser.php (RFC 6591 ARF envelope) into dmarc_forensic_reports.

Sign up — Free plan Check my rua= destination