DMARC RUA / RUF Not Working

DMARC reports provide visibility into authentication results across mailbox providers. The rua tag controls aggregate reports, and the ruf tag controls forensic reports where supported. If these reporting addresses are misconfigured or cannot receive mail, the domain owner will not get DMARC feedback.

One-Minute Fix

Verify that the reporting addresses exist, accept incoming mail, and are correctly published in the DMARC record.

Correct DMARC reporting tags
DNS TXT
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com

The rua and ruf values must point to working mailboxes or reporting endpoints that can actually receive DMARC reports.

Re-check

Wrong vs correct setup

Wrong setup

Wrong setup
DNS TXT
v=DMARC1; p=none; rua=mailto:reports@example.com; ruf=mailto:forensics@example.com

This is broken if those mailboxes do not exist, reject incoming mail, or were never configured to receive DMARC reports. The syntax may look correct, but reporting still fails operationally.

Correct setup

Correct setup
DNS TXT
v=DMARC1; p=none; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com

This is the correct pattern when the reporting mailbox exists and accepts incoming DMARC reports. The domain can now collect report data while monitoring authentication.

Why this happens

DMARC reports may fail when the reporting mailboxes do not exist, when inbox permissions are wrong, when the mailbox is full, when external reporting authorization is missing, or when providers do not send forensic reports in practice.

Why this is a problem

  • You lose visibility into authentication failures.
  • DMARC rollout becomes harder to monitor.
  • Abuse patterns become harder to detect.
  • You may think DMARC is working well when real failures are going unseen.

How this affects deliverability

Broken reporting does not usually break delivery directly, but it removes the visibility you need to deploy DMARC safely. Without reports, domains are more likely to stay weak for too long or enforce too aggressively without enough evidence.

Common causes

  • The reporting mailbox does not exist.
  • Incoming mail to the reporting mailbox is blocked or filtered incorrectly.
  • External reporting authorization is missing for third-party destinations.
  • Teams assumed forensic reports would arrive everywhere, even though many providers do not send them.

What we checked

We reviewed whether the DMARC record includes rua or ruf tags and whether those values appear to point to real reporting addresses using valid mailto syntax.

Live DNS lookup. No login. No saved domains. No tracking.

FAQ

What is the difference between rua and ruf?

rua is for aggregate DMARC reports, while ruf is for forensic or failure reports where providers support them.

Why do I get aggregate reports but not forensic reports?

Many mailbox providers either limit or do not send forensic reports at all, so missing ruf traffic is common even with correct syntax.

Can I send DMARC reports to a third party?

Yes, but external reporting can require additional DNS authorization depending on the destination and provider behavior.

Next steps

  • Confirm that the reporting mailbox exists and accepts mail.
  • Check that rua and ruf use valid mailto syntax.
  • Review any filtering or blocking on the reporting mailbox.
  • Verify external reporting authorization if using a third-party destination.
  • Send a new check after updating the record.
  • Review the full troubleshooting guidance in the DMARC Hub.
  • Explore sender authorization issues in the SPF Hub.
  • Check signing and selector issues in the DKIM Hub.

Related fixes

Explore more issues