DMARC reporting is the feedback system in DMARC that lets a domain owner see how email claiming to be from its domain authenticated at receiving mail servers. Most DMARC reports are aggregate XML summaries sent to the address in the rua tag; they show sending sources, message volumes, SPF and DKIM results, alignment, and the receiver’s applied disposition.

What DMARC reporting means in plain language

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. The reporting portion answers a practical question that every serious sender eventually faces: who is using my From domain, and is that mail authenticating correctly?

A DMARC record lives in DNS and tells receivers how to evaluate mail that uses a domain in its visible From: header. It also gives a domain owner a way to request feedback. The reports are generated by participating receiving systems after they evaluate messages that claim the domain.

That feedback matters because a sending domain is rarely used by one system alone. A company might send transactional receipts through an application email provider, newsletters through a marketing platform, support replies through a help desk, invoices through an accounting system, and employee mail through a workspace suite. Each source can have different SPF, DKIM, return-path, and visible From-domain settings.

Without DMARC reporting, a team may know that its own application sends messages, but not whether every legitimate source is aligned—or whether unauthorized systems are impersonating the domain. The current DMARC standards describe reporting as feedback about received messages that use the domain, with aggregate reports delivered to the domain owner’s requested destination. (rfc-editor.org)

Why DMARC reporting matters for deliverability

DMARC reporting is not a deliverability score, and publishing a DMARC record does not automatically put messages in the inbox. The original DMARC specification explicitly notes that authentication does not create elevated delivery privileges. Reputation, recipient engagement, complaint rates, message quality, sending consistency, and infrastructure still affect placement.

However, DMARC reports are extremely useful for finding authentication defects that can contribute to delivery problems. They expose whether a receiver saw an aligned SPF or DKIM result, whether a receiver treated a message as passing DMARC, and what it did when a message did not pass.

For deliverability work, that turns vague symptoms into diagnosable facts. Instead of saying, “Our marketing mail sometimes lands in spam,” a team can establish that the marketing vendor signs as vendor.example rather than example.com, the envelope sender is also unaligned, and therefore DMARC fails even though DKIM itself may technically pass.

Visibility before enforcement

Most organizations begin with a monitoring policy:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

p=none asks receivers to monitor DMARC failures without requesting quarantine or rejection through the published policy. It gives the sender a safer discovery period: catalog legitimate senders, correct their authentication, and identify apparent spoofing before increasing enforcement.

A monitoring policy should not be mistaken for no protection. It gives a receiver no requested enforcement action for DMARC failures, though individual receivers can still make their own filtering decisions. Its core value is observability.

Once reports show that legitimate mail reliably passes, a domain owner can consider stronger policy values such as p=quarantine or p=reject. Google recommends reviewing DMARC reports to identify authorized sources and authentication results before moving from none toward quarantine or reject. (knowledge.workspace.google.com)

Better campaign and transactional-email operations

DMARC reporting helps both marketing and product teams because it detects changes that happen outside a normal campaign dashboard:

A new CRM is enabled and begins sending with an unaligned From domain.
An old vendor keeps sending after a contract ends.
A DNS change removes an SPF authorization or DKIM public key.
A developer changes the return-path domain during a transactional-email migration.
A spoofing campaign starts using the company’s recognizable From domain.
A forwarding or mailing-list flow breaks SPF, leaving DKIM as the essential aligned authentication path.

For a developer-owned sending program, reports are also a useful release-control signal. When adding a new application, subdomain, or email provider, establish the intended authentication identity first, then monitor aggregate reports after deployment. The right operational question is not merely whether the provider says a domain is verified; it is whether independent receivers observe the messages passing DMARC at real destinations.

The two kinds of DMARC reports

DMARC reporting is usually discussed as though it were one thing, but there are two report categories with very different purposes and availability.

Aggregate reports, requested with `rua`

Aggregate reports are the main form of DMARC reporting. A receiver sends a structured XML summary covering a reporting period. The destination is requested through the rua tag, short for Reporting URI for Aggregate reports.

A basic record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

The report destination is normally a mailbox, group, parser, or managed DMARC-analysis service. Reports often arrive as compressed attachments, such as ZIP or GZIP files, containing XML. The data is grouped rather than presented as one row per original email.

Aggregate reports typically show:

The reporting organization that generated the report.
The beginning and end of the reporting period.
The domain and policy the receiver evaluated.
A source IP address.
A message count for that source and authentication-result combination.
The visible header From domain.
SPF result and SPF-authenticated domain.
DKIM result and DKIM signing domain.
Whether the receiver applied no action, quarantine, reject, or a policy override.

This is population-level operational data. It is excellent for answering, “How much mail did this receiving system observe from this source, and did it pass?” It is not an inbox-placement report and not a complete log of every message delivered across the internet.

Failure reports, requested with `ruf`

Failure reports are message-specific reports associated with mail that fails DMARC evaluation. The ruf tag requests these destinations:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com

The modern failure-reporting specification calls these “failure reports” or “failed message reports” and describes them as containing details about individual messages that failed DMARC authentication. (rfc-editor.org)

In practice, do not build a DMARC program around receiving failure reports. Receiver support varies, privacy considerations limit what can be shared, and many receivers either do not send them or restrict their content. Treat ruf as an optional supplementary signal, not a replacement for aggregate reporting.

Aggregate reports are the reliable workhorse for inventorying senders and measuring authentication patterns. Failure reports, when available, can add context for a particular issue.

How DMARC evaluation connects SPF, DKIM, and alignment

To interpret DMARC reporting, it helps to separate three ideas that are often blurred together: SPF authentication, DKIM authentication, and identifier alignment.

SPF verifies whether the connecting sending infrastructure is authorized to send for the envelope sender domain, often surfaced as the return-path domain. DKIM verifies whether a message has a valid cryptographic signature associated with a signing domain. DMARC then asks whether at least one successful SPF or DKIM result is aligned with the domain visible to recipients in the From: header.

That last step is crucial. A message can pass SPF and still fail DMARC. It can also pass DKIM and still fail DMARC.

A simple aligned pass

Suppose recipients see:

From: Billing <billing@example.com>
Return-Path: bounce@example.com
DKIM-Signature: d=example.com; s=mail1; ...

If SPF passes for example.com, DKIM passes with d=example.com, or both occur, the authentication identifiers align with the visible From domain. DMARC passes.

A common unaligned failure

Now suppose recipients still see:

From: Billing <billing@example.com>
Return-Path: bounce@mailer-vendor.net
DKIM-Signature: d=mailer-vendor.net; s=prod; ...

The vendor may have valid SPF and DKIM for mailer-vendor.net, but neither identifier aligns with example.com. Unless another aligned DKIM signature or aligned SPF result exists, DMARC fails.

This is why “SPF passed” or “DKIM passed” is not enough to close an incident. A DMARC report must be read through the alignment relationship to the visible From domain. Google’s Postmaster Tools documentation also defines DMARC authentication around this match between the From domain and the SPF or DKIM domain. (support.google.com)

Relaxed and strict alignment

DMARC can use relaxed or strict alignment for SPF and DKIM. The relevant record tags are aspf for SPF alignment and adkim for DKIM alignment.

Relaxed alignment permits an organizational-domain relationship. For example, a visible From domain of news.example.com can align with an authenticated identifier at example.com under relaxed alignment. Strict alignment requires an exact domain match.

A practical monitoring record might be:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r

Here, r means relaxed alignment. Use strict alignment only when the organization has mapped every legitimate sending flow and understands the operational consequences. Strictness can improve identity precision, but it also creates more opportunities for legitimate mail to fail after a vendor configuration change.

What is inside an aggregate DMARC report

Raw aggregate XML can look intimidating, but most records boil down to a handful of questions: who sent, how many messages, did SPF pass, did DKIM pass, did either one align, and what policy action did the receiver apply?

Here is a simplified illustrative record:

<record>
  <row>
    <source_ip>192.0.2.44</source_ip>
    <count>1250</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounce.vendor-mail.net</domain>
      <result>fail</result>
    </spf>
  </auth_results>
</record>

In this example, the receiver observed 1,250 messages from one source IP. SPF failed for the vendor’s bounce domain, but DKIM passed for example.com. Because the DKIM domain aligns with the visible header_from domain, the messages can pass DMARC despite the SPF failure.

That is a healthy pattern if the source IP is a known, authorized sender. It shows why teams should avoid treating every SPF failure as a deliverability emergency. DMARC is intentionally designed so that aligned DKIM can carry authentication when SPF is unavailable or disrupted.

Fields worth reviewing first

When analyzing aggregate reports, prioritize these fields:

source_ip — The source seen by the reporting receiver. Map it to your mail provider, cloud workload, office suite, CRM, help desk, or an unknown party.
count — The number of messages represented by that row. A tiny failure may be a test; a high-volume failure can affect a production program.
header_from — The visible domain DMARC protects and the domain recipients see.
SPF domain and result — Useful for identifying the envelope sender or return-path identity used by a stream.
DKIM domain and result — Often the most resilient signal for modern mail flows, especially when forwarding is involved.
Policy disposition — The action represented in the report, such as none, quarantine, or reject, plus any policy override context.

A receiving organization chooses its own reporting schedule, coverage, aggregation, and delivery behavior. Therefore, reports are meaningful visibility data, but the sum of report counts should not be treated as an exact universal count of all mail sent by a domain.

How to calculate a DMARC pass rate

DMARC reporting itself is not a rate. It is the data source from which you calculate useful rates, especially the DMARC pass rate.

The basic formula is:

DMARC pass rate = (messages that pass DMARC / total messages evaluated) × 100

For aggregate reports, use the count field as the message volume. Sum counts for rows that pass DMARC, then divide by the total counts for the selected scope.

Worked numeric example

Assume an organization processes its aggregate reports for one day and sees these rows:

Sending source	Message count	DMARC outcome
Transactional email API	18,400	Pass
Marketing platform	6,100	Pass
Support platform	1,250	Fail
Unknown source	250	Fail

Total evaluated messages:

18,400 + 6,100 + 1,250 + 250 = 26,000

Total messages that pass DMARC:

18,400 + 6,100 = 24,500

DMARC pass rate:

(24,500 / 26,000) × 100 = 94.23%

The resulting DMARC pass rate is 94.23%.

That number requires interpretation. The unknown source represents only 250 messages, but it could be active impersonation and deserve an immediate investigation. The support platform represents 1,250 messages, almost 5% of observed volume, and is more likely to be a legitimate but misconfigured sending system.

A useful companion metric is the authorized-source pass rate:

authorized-source pass rate = (authorized messages passing DMARC / all authorized messages) × 100

This isolates operational configuration quality from spoofing. If known services send 25,750 messages and 24,500 pass, then:

(24,500 / 25,750) × 100 = 95.15%

That tells the email team that a legitimate source is failing. Separately, the organization can measure the volume of unauthorized observed mail and monitor whether it declines after enforcement becomes more restrictive.

Common causes of DMARC reporting problems

A DMARC failure in a report does not automatically mean the report is wrong or that an attacker is involved. It means the receiver could not establish an aligned SPF or DKIM pass for that evaluated message. The cause must be determined row by row.

A third-party sender is not configured for domain alignment

This is the most common cause. A marketing platform or support tool sends visible mail from example.com but uses its own domain for both the return path and DKIM signature.

Fix: Configure the vendor’s custom sending domain, branded return-path domain, custom DKIM domain, or equivalent authentication settings. The exact labels differ by provider, but the goal is consistent: make SPF and/or DKIM authenticate with a domain aligned to the visible From domain.

Prefer configuring aligned DKIM whenever available. SPF can break in forwarded flows because forwarding commonly changes the path that SPF evaluates. DKIM is usually more durable if the message remains intact.

SPF passes, but SPF is not aligned

A report can show SPF pass for a domain such as bounces.mailer.example while the visible From domain is example.com. Whether that passes DMARC depends on the organizational-domain relationship and the alignment mode.

Fix: Use a return-path domain that aligns under the selected SPF alignment setting, or ensure a DKIM signature using the From domain passes and aligns. Do not weaken or broaden SPF records merely to chase a pass result; an overgrown SPF record can create DNS lookup-limit problems and make maintenance harder.

DKIM passes, but the signer is not aligned

A vendor may apply a valid signature using d=vendor-domain.tld. The signature is cryptographically valid, but it does not establish that the owner of example.com authorized the message.

Fix: Enable custom DKIM signing with d=example.com or an aligned subdomain such as mail.example.com when relaxed alignment is used. Confirm after DNS propagation by sending live test mail and reviewing aggregate results.

DKIM fails after a DNS or key change

If the DKIM selector record is missing, malformed, expired in a provider configuration, or replaced incorrectly, receivers cannot retrieve the public key needed to validate a signature.

Fix: Check the selector named in the message’s DKIM-Signature header, verify the corresponding DNS TXT record, and make sure the sending service is signing with the expected selector and domain. Avoid deleting an old selector immediately during key rotation; keep it published until all mail signed with the former key has aged out of delivery and retry windows.

A new, unapproved sender appears

Unknown source IPs and unknown authenticated domains are one of the most valuable findings in DMARC reporting. They may be shadow IT, a forgotten vendor, a business-unit project, a compromised system, or direct impersonation.

Fix: Investigate before allowlisting. Identify the source owner, message type, sending domain, and volume. If it is legitimate, formally configure aligned authentication. If it is unauthorized, do not add it to SPF or otherwise legitimize it. After authorized streams are corrected, stronger DMARC enforcement can reduce successful spoofing with the protected From domain.

Forwarding or mailing lists alter the message path

Forwarded mail can fail SPF because the final receiver sees a forwarding server rather than the original authorized sender. Mailing lists can also modify message content, which can invalidate DKIM if the modified fields or body were signed.

Fix: Ensure your normal outbound mail has a robust aligned DKIM signature. For systems that operate mailing lists or forwarding services, evaluate modern handling methods such as ARC according to the infrastructure’s needs. Do not assume every report row involving a forwarding source is a configuration error by the original sender.

Subdomains are overlooked

A parent-domain DMARC policy may affect subdomains, but individual subdomains can have their own records and different sending uses. alerts.example.com, news.example.com, and example.com may each need separate analysis.

Fix: Maintain a sender inventory by visible From domain, not merely by company. Decide which domains and subdomains send mail, who owns each one, what DKIM domain they use, what envelope sender they use, and what policy should apply.

How to improve DMARC reporting and authentication results

Improving DMARC reporting is less about making the XML prettier and more about building a repeatable identity-management process. The reports become valuable when each observed sending source has an accountable owner and a known intended authentication configuration.

1. Publish a valid monitoring record

Start with a syntactically simple record on _dmarc.example.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Use a dedicated inbox or group for reports. High-volume domains can receive a large number of compressed XML files, and mixing them with a human support mailbox creates unnecessary operational risk. Google specifically recommends a dedicated mailbox or group because report volume can become substantial. (knowledge.workspace.google.com)

2. Set up a reliable report-processing workflow

Raw XML is standardized but not designed for casual manual reading. Use a parser, internal data pipeline, or DMARC analysis service that can preserve the raw files while producing searchable views by source IP, sending domain, volume, alignment outcome, and date.

The workflow should retain enough historical data to identify changes. One report can show a failure. A multi-week trend can show whether a vendor rollout is improving, whether spoofed volume is recurring, or whether a DNS change caused a sudden drop in DKIM alignment.

3. Build an authorized-sender inventory

Create a practical table with at least these columns:

Visible From domain.
Product or message stream.
Business owner.
Technical owner.
Sending platform.
Expected source IP range or provider identity.
Envelope sender domain.
DKIM signing domain and selector.
Expected DMARC result.
Last validation date.

This inventory is the bridge between report data and action. It prevents a common failure mode where email operations knows a vendor exists, security knows there is an unfamiliar report row, and neither side can prove whether the source is approved.

For application and transactional streams, keep the sender identity stable through deployments. When adding an SMTP or REST provider, validate the authenticated From domain, return-path behavior, and DKIM signing domain before putting production volume through it. Review your platform’s email API setup guides alongside its DNS instructions so the application’s From addresses match the authenticated identity you designed.

4. Fix alignment before changing enforcement

Do not move rapidly to p=quarantine or p=reject because a dashboard shows a high overall pass rate. First investigate all meaningful legitimate failures. A 99% pass rate can still conceal a critical low-volume stream, such as password resets, invoices, legal notices, or support replies.

Prioritize failures by a combination of volume and business impact:

High-volume legitimate mail that fails DMARC.
Essential low-volume transactional mail that fails.
Unknown high-volume sources.
Unknown low-volume sources with suspicious patterns.
Intermittent DNS, key-rotation, or vendor-routing failures.

5. Move gradually toward enforcement

After legitimate traffic is consistently authenticated and aligned, choose the appropriate enforcement path. p=quarantine asks receivers to treat failing mail suspiciously, while p=reject asks them to reject it. Receivers retain discretion, so policy is a request rather than an absolute guarantee.

Use reporting continuously after every policy change. Enforcement is not a one-time project completion event; new vendors, mergers, marketing tools, and product launches can create new sending paths later.

How DMARC reporting relates to Gmail and Yahoo requirements

Authentication expectations at major mailbox providers make DMARC operationally important even for senders that are not primarily focused on spoofing defense. Gmail requires bulk senders—defined in its guidelines as those sending more than 5,000 messages per day to Gmail accounts—to set up SPF, DKIM, and DMARC; Gmail permits a DMARC enforcement policy of none for that baseline requirement. (support.google.com)

Yahoo’s sender best-practices guidance similarly says bulk senders should implement SPF and DKIM, publish a valid DMARC policy at least at p=none, have DMARC pass, and strongly recommends a properly configured rua destination for monitoring during setup. (senders.yahooinc.com)

The key point is that a published record alone is not the finish line. A domain can have p=none in DNS and still have major delivery exposure if its most important streams fail alignment. DMARC reporting supplies the evidence needed to determine whether the organization is truly meeting the intended authentication standard across its email ecosystem.

Practical limits of DMARC reports

DMARC reporting is valuable, but it has boundaries. Treat it as an important source of authentication telemetry, not a complete email observability platform.

First, not every receiver sends reports, and report cadence can vary. A rua tag asks for reports; it does not guarantee identical coverage from every destination.

Second, aggregate-report counts are observed message counts within a reporting organization’s data, not a canonical sent-mail ledger. Compare them with your provider’s delivery events, SMTP logs, campaign totals, and application telemetry rather than expecting an exact one-to-one match.

Third, aggregate reports do not reveal inbox versus spam placement. A message can pass DMARC and still perform poorly because of reputation, complaints, low engagement, unsafe content, or recipient-level filtering.

Finally, a pass result does not prove that every message is desirable or that every source is authorized in a business sense. It proves that the receiver observed the required aligned authentication condition. A compromised, properly configured system could still send unwanted mail. Security, access control, vendor governance, and reputation monitoring remain necessary.

A practical DMARC reporting review cadence

A manageable routine is more effective than an occasional deep dive triggered by a crisis.

Daily checks

Review alerts for new source IPs, unknown DKIM domains, sudden changes in message volume, and spikes in authentication failure. Focus on changes from an established baseline.

Weekly checks

Review the DMARC pass rate by sending platform and visible From domain. Confirm that expected marketing, transactional, support, and workplace-mail sources appear as intended. Investigate any vendor that suddenly disappears from reports or changes its authentication profile.

Monthly checks

Reconcile reports against the authorized-sender inventory. Retire unused sending domains, selectors, and vendor configurations only after confirming they no longer handle mail. Review whether the existing DMARC policy remains appropriate and whether newly added systems have owners and documented authentication settings.

Before major changes

When changing DNS, rotating DKIM keys, switching email platforms, launching a new subdomain, or consolidating brands, establish a short-term reporting watch period. Compare pre-change and post-change pass rates and source identities. This small discipline catches issues before they turn into a widespread campaign or transactional-delivery incident.

Conclusion

DMARC reporting is the monitoring layer that makes DMARC usable in the real world. Aggregate reports show which systems send as your domain, how much mail they send, whether SPF and DKIM authenticate, whether those identifiers align with the visible From domain, and how receivers handle failures.

The best use of DMARC reporting is not to chase a single perfect percentage. It is to maintain a trustworthy sender inventory, detect unknown activity, repair legitimate alignment failures, and make policy decisions with evidence. Start with p=none and a working rua address, validate every legitimate mail stream, then use the reporting data continuously as your email infrastructure changes.

FAQ

What is the `rua` tag in DMARC reporting?

rua is the DMARC record tag used to request aggregate reports. It commonly contains a mail URI, such as rua=mailto:dmarc-reports@example.com, where participating receivers can send XML summaries of DMARC evaluation activity.

Is DMARC reporting the same as a DMARC pass rate?

No. DMARC reporting is the feedback data received from mail servers. A DMARC pass rate is a metric calculated from that data: passing messages divided by total evaluated messages, multiplied by 100.

Why does a message fail DMARC when SPF or DKIM passes?

DMARC requires alignment. SPF or DKIM can pass for another domain, such as an email vendor’s domain, while the visible From address uses your domain. DMARC passes only when at least one successful SPF or DKIM identifier aligns with the visible From domain under the selected alignment policy.

Should every domain use `p=reject` immediately?

No. Begin by monitoring with p=none, collect reports, identify all legitimate senders, and fix their alignment. Moving to enforcement before discovering essential but misconfigured streams can disrupt legitimate email.

Do DMARC reports tell me whether messages reached the inbox?

No. Aggregate DMARC reports show authentication and policy-evaluation information, not inbox placement. Use them alongside delivery events, reputation tools, complaint data, and engagement metrics to assess overall deliverability.

DMARC Reporting: What It Is, How to Read Reports, and How to Fix Failures