DMARC Troubleshooting: Reports, Alignment, and Rollout

Choose a policy that matches your rollout stage

DMARC evaluates messages using the domain in the visible From: header. A message passes when at least one authentication method passes and its authenticated identifier aligns with that From domain. The policy in p= describes the domain owner's requested handling when neither aligned method passes.

p=none · monitor

Ask receivers not to change handling because of DMARC. Use this while you build an inventory of legitimate senders and correct alignment gaps. It does not promise inbox delivery; normal receiver filtering still applies.

p=quarantine · suspicious

Ask receivers to treat failing messages as suspicious. They may place them in spam or another quarantine, depending on the receiver's handling.

p=reject · strongest request

Ask receivers not to accept messages that fail DMARC. A policy is an input to a receiver's decision, not a guarantee of a particular SMTP response or final disposition.

Start in monitoring mode, examine reports across your normal sending cycle, and identify every legitimate stream before moving to quarantine and then reject. Pause at a step if a known service is missing or its alignment is unclear. Fix the source first and collect enough new report data to judge the change. The current core specification marks the older pct sampling tag as historic, so do not rely on it as a rollout control.

Trace SPF and DKIM alignment

SPF and DKIM authentication can each pass while DMARC fails. For SPF, compare the authenticated envelope or HELO domain reported by the receiver with the visible From domain. For DKIM, compare the signature's d= signing domain with From. Relaxed alignment accepts identifiers under the same organizational domain; strict alignment requires the domains to match exactly. At least one passing method must also align for DMARC to pass.

From: billing@acme.example
SPF: pass for bounce.mail-vendor.example
DKIM: pass with d=mail-vendor.example

Alignment settings can be relaxed or strict independently for SPF and DKIM. If a sender changed from a subdomain to the organizational domain (or the reverse), inspect the published aspf and adkim values before changing policy. Strict mode can expose a vendor setup that previously aligned under relaxed matching.

Read aggregate reports as evidence, not a complete mail log

An aggregate report is a receiver's summary for a reporting period. It groups observations by source and reports message counts, the visible From domain, authentication results, alignment evaluation, requested policy, and disposition. Reports are commonly delivered daily, but receiver participation, timing, and coverage vary. A quiet mailbox or a missing source in one report is not proof that no one is sending for your domain.

In an XML report, start with source_ip, count, identifiers/header_from, policy_evaluated, and auth_results. The policy-evaluated SPF and DKIM values help show whether an authenticated identifier aligned; the auth-results section shows the underlying method and identifier. Check the report's date range and any policy-override reason before interpreting a disposition as a DNS error.

policy_evaluated: SPF=fail, DKIM=fail, disposition=none
auth_results: SPF=pass (bounce.mail-vendor.example)
               DKIM=pass (d=mail-vendor.example)
header_from: acme.example

1. Group repeated rows by sending IP and From domain; use the count and reporting period to distinguish a recurring stream from an isolated event.
2. Compare those rows with campaign records, transactional systems, CRM/helpdesk settings, invoices, and vendor accounts. Ask the mail or security owner about services you cannot identify.
3. Label each source as authorized, retired, forwarding/indirect mail, or unrecognized. A report identifies observed infrastructure and results; it may not identify the person or application behind a shared provider IP.
4. Check DNS and a received message before editing records. Do not add every unknown IP to SPF: first establish that the service is authorized and follow its current sending instructions.

Work through common rollout problems

A sender you do not recognize

Check the report's source IP, From domain, volume, date range, and provider identifiers against an internal sender list and vendor records. Ask the application, DNS, and security owners about forgotten sign-up forms, invoices, alerts, old ESPs, and test environments. A new legitimate stream needs the same SPF or DKIM authentication and alignment review as an established one. If it is unauthorized spoofing, do not authorize it merely to remove a failure row.

A third-party ESP authenticates but does not align

Ask the provider to enable DKIM signing with your domain (an aligned d= value) and, when supported, a custom MAIL FROM or return-path domain for SPF. Publish only the DNS records the provider specifies. Send a test through the real configuration, inspect the received headers, and confirm later aggregate data shows at least one passing aligned method.

A subdomain behaves differently

Query _dmarc.subdomain.example first. A valid record there governs that From domain. If there is no subdomain record, the organizational-domain policy can apply: sp= sets policy for existing subdomains, while np= sets policy for non-existent subdomains. Map sending and non-sending subdomains before tightening the parent policy.

Reports never arrive

Confirm the rua=URI is present in the DMARC record, correctly spelled, and delivered to a monitored mailbox or reporting service. Check mailbox rejection/quota, DNS publication, and whether the receiver sends reports for the domain. If the destination is hosted by another organization, its domain must authorize it to receive reports for yours. The reporting service's setup guide should give the required authorization record. Do not infer that the configuration is healthy from an empty inbox.

Choose and protect report destinations

The rua= tag requests aggregate feedback. Use a mailbox or reporting service someone owns and checks, with enough capacity for compressed XML attachments and a process to retain or delete them. For example, this illustrative record sends reports to a reserved example domain; replace it with your own domain and an address that you control:

_dmarc.example.test TXT
  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.test"

When a reporting service receives data at another domain, follow its instructions for DNS authorization. Without that authorization, receivers may decline to send reports to the external destination. Protect report access: even aggregate data can reveal details about an organization's mail patterns.

Protocol references

• RFC 9989: DMARC core protocol
• RFC 9990: DMARC aggregate reporting
• RFC 9991: DMARC failure reporting and privacy considerations

For more email-authentication context, continue with the SPF, DKIM, and DMARC overview.