Skip to Content
EmailExchangeEmail SecurityDMARC Reports

DMARC Reports

View and analyze DMARC (Domain-based Message Authentication, Reporting, and Conformance) aggregate and forensic reports for your domains. DMARC reports help you understand who is sending email using your domain and whether authentication is passing.

Note: DMARC reports are sent by receiving mail servers to the address specified in your DMARC DNS record. Configure the rua (aggregate) and ruf (forensic) tags to receive reports.

DMARC Report Dashboard

MetricDescription
Total ReportsNumber of DMARC reports received
Sending SourcesUnique IPs sending as your domain
Pass RatePercentage of messages passing DMARC
Fail RatePercentage of messages failing DMARC
Policy AppliedNone, Quarantine, or Reject actions taken

Report Types

Aggregate Reports (RUA)

XML reports sent daily by receiving servers summarizing authentication results:

  • Volume — Number of messages from each sending IP
  • SPF result — Pass, fail, softfail, or neutral for each source
  • DKIM result — Pass or fail for each source
  • DMARC alignment — Whether SPF/DKIM aligned with the From domain
  • Policy applied — What action the receiver took (none, quarantine, reject)

Forensic Reports (RUF)

Individual message failure reports with details about specific authentication failures:

  • Specific message headers that failed
  • Authentication check results
  • Sending IP and envelope information

Warning: Many mail servers do not send forensic reports due to privacy concerns. Aggregate reports are more reliable.

Understanding DMARC Results

Alignment

DMARC requires alignment between the From domain and the authenticated domain:

  • SPF alignment — The envelope sender (MAIL FROM) domain matches the From header domain
  • DKIM alignment — The DKIM signing domain (d=) matches the From header domain
  • Relaxed mode — Subdomains of the organizational domain also align
  • Strict mode — Exact domain match required

Common Failure Sources

  • Third-party services — Marketing platforms, CRM, SaaS apps sending as your domain
  • Forwarding — Auto-forwarded messages break SPF alignment
  • Misconfigured servers — On-premises or legacy servers without proper authentication
  • Spoofing — Unauthorized senders impersonating your domain

DMARC Policy Progression

Recommended progression for implementing DMARC:

  1. p=none — Monitor only. Collect reports without affecting delivery.
  2. p=quarantine — Failed messages sent to spam/quarantine.
  3. p=reject — Failed messages are rejected entirely.

Note: Start with p=none and review reports for at least 2-4 weeks before advancing to quarantine or reject.

Best Practices

  • Start with monitoring — Use p=none to identify all legitimate sending sources before enforcing.
  • Configure SPF and DKIM first — Ensure all legitimate sources authenticate before enabling DMARC enforcement.
  • Review reports weekly — Monitor for new sending sources and authentication failures.
  • Use a DMARC reporting service — Aggregate XML reports can be complex. Use a service to parse and visualize data.

API Reference

GET /api/exchange/dmarc-reports List DMARC reports

GET /api/exchange/dmarc-reports/:domain/summary Get DMARC summary for domain

GET /api/exchange/dmarc-reports/:domain/sources List sending sources for domain

GET /api/exchange/dmarc-reports/:domain/failures List authentication failures

Last updated on