Are DMARC RUA and RUF tags mandatory for compliance and what are their benefits?
Published 2 Jul 2025
Updated 14 Aug 2026
11 min read
Summarize with
Updated on 14 Aug 2026: We updated this guide for RFC 9989 reporting tags, rollout controls, and current Gmail and Yahoo requirements.
No, rua and ruf are optional DMARC tags under RFC 9989, and neither is a pass-or-fail requirement for Gmail or Yahoo bulk sender compliance. An explicit p=none policy remains the practical minimum for those sender requirements.
That answer needs one practical caveat: rua still belongs on almost every active domain because it shows which sources send as the domain, which messages pass, which messages fail, and whether a stricter policy is safe. ruf is different. It requests message-specific failure reports, and many receivers do not send them because the reports can expose private header or message data.
So the short version is simple: skip ruf unless there is a defined investigation need, but do not treat rua as optional in practice. A record without RUA can meet the provider baseline, but it gives the domain owner no aggregate feedback.
The direct compliance answer
DMARC compliance depends on the context. RFC 9989 requires the v tag, with v=DMARC1 first in the record, and recommends the p policy tag. If a syntactically valid record lacks a valid p value but has at least one valid rua URI, receivers process it as p=none. Without a valid policy or RUA URI, the receiver applies no DMARC processing. Gmail and Yahoo bulk sender rules expect a valid DMARC policy of at least p=none, plus authenticated mail and alignment between the visible From domain and an SPF or DKIM authenticated domain. RUA is strongly recommended, not required. RUF is not required.
- DMARC syntax: The v=DMARC1 tag is required and must appear first; p is recommended, while RUA and RUF are optional.
- Gmail and Yahoo: They require an explicit DMARC policy for bulk senders and strongly recommend RUA for monitoring, but neither provider requires RUA or RUF.
- RUA reports: These aggregate reports show source IPs, message counts, authentication results, published policy, and receiver actions.
- RUF reports: These failure reports are optional, sensitive, and often unavailable because receivers restrict them.
Practical answer
If the goal is minimum bulk sender compliance, RUA and RUF are not mandatory. If the goal is a deployable, supportable DMARC program, add RUA and review the reports. RUA is the evidence layer for deciding whether policy changes are safe.
Minimum provider-compliant DMARC recordDNS
v=DMARC1; p=none
What RUA and RUF actually do
RUA and RUF are the reporting tags in DMARC. The RUA and RUF difference matters because the two report types answer different operational questions.
RUA aggregate reports
RUA reports are XML summaries sent by receivers, typically for one UTC day. They include reporter metadata, the published policy, source IPs, message counts, dispositions, identifiers, and SPF or DKIM results. They are the main data source for DMARC monitoring. Aggregate data has lower privacy risk than failure samples, but source and volume patterns can still expose business information.
- Best for: Finding legitimate senders before enforcement.
- Data level: Aggregated counts, sources, authentication results, and receiver actions.
RUF failure reports
RUF asks receivers to send message-specific reports when DMARC fails under the requested fo conditions. A report can contain headers or the full message, subject to the receiver's privacy policy, so receivers and domain owners need tighter controls for this data.
- Best for: Investigating specific failures when receivers send useful samples.
- Data level: Individual failure events, headers, and sometimes redacted or complete content.
Flowchart showing email sent, receiver checks, DMARC result, RUA summary, and policy decision.
The reporting distinction matters during rollout. RUA shows whether normal mail passes at scale. RUF helps only when the receiving side sends failure reports and the team has an approved process for the sensitive data.
Valid records and better records
An explicit policy without reporting can meet the provider baseline, but it gives no aggregate feedback. A better record adds RUA, then uses the reports to identify legitimate senders before policy changes.
Minimum provider-compliant recordDNS
v=DMARC1; p=none
Monitoring record with RUADNS
v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com
Strict policy with reportingDNS
v=DMARC1; p=reject; rua=mailto:dmarc-aggregate@example.com
If the reporting address uses another domain, that external report domain needs DNS authorization. Without that authorization, receivers can refuse to send reports because anyone could otherwise point high-volume reports at someone else's mailbox. A comma-separated RUA list can request delivery to more than one URI, and each external destination needs authorization.
|
|
|
|
|---|---|---|---|
v | Yes | DMARC version | Use DMARC1 first |
p | Recommended | Policy | Publish p=none explicitly for provider rules |
rua | No | Aggregate reports | XML needs parsing and review |
ruf | No | Failure reports | Limited support and sensitive data |
DMARC reporting tags and when to use them
What RFC 9989 changes for rollout
RFC 9989 replaced the earlier DMARC specification in May 2026. RUA and RUF remain active optional tags, but the rollout controls around them changed. New records should follow the current tag registry even while older receiver documentation and deployed records catch up.
- Historic tags: The pct, rf, and ri tags now have historic status and should not be added to new RFC 9989 records.
- Testing mode: The new t=y tag requests testing treatment for quarantine or reject policies. It replaces the useful testing behavior formerly associated with pct=0.
- General-purpose email: RFC 9989 says domains used by people who post to mailing lists should not publish p=reject without first measuring the impact on indirect mail.
- Reporting cadence: Receivers should send aggregate reports at least once every 24 hours, but the historic ri tag no longer requests a custom interval.
RFC 9989 testing recordDNS
v=DMARC1; p=quarantine; rua=mailto:dmarc-aggregate@example.com; t=y
Do not assume reject is the endpoint
A strict reject policy remains valid for tightly controlled or non-sending domains. For general-purpose email, assess mailing lists and other indirect delivery paths first. RUA data provides the evidence for that decision.
Why RUA belongs in most records
RUA turns DMARC from a static DNS record into a feedback loop. Without it, a policy can be published, but there is no report stream showing whether a CRM, billing system, support desk, payroll platform, or marketing platform passes correctly.
- Sender inventory: RUA exposes the services and IPs sending mail with the domain in the visible From header.
- Failure diagnosis: RUA shows whether SPF, DKIM, or DMARC is failing and how often it happens.
- Policy staging: RUA provides evidence for moving from none to quarantine and for deciding whether reject suits the domain.
- Domain abuse: RUA helps identify unauthorized sources trying to use the domain.
- Change detection: RUA reveals new senders and authentication regressions after configuration changes.
Policy readiness bands
A practical way to judge whether RUA data supports a policy change.
Poor visibility
No RUA
Reports are missing or unread.
Early rollout
p=none
Reports exist, but senders are still unknown.
Enforced
p=quarantine
Known senders pass and failures are understood.
Strict policy
p=reject
Indirect-mail impact has been assessed.
The best time to add RUA is before enforcement. Once policy is strict, a missing report stream slows incident response because the team cannot quickly distinguish a legitimate sender failure from an unauthorized source.
Why RUF is usually optional
RUF has a narrower use case. Leave it out unless a security team needs message-specific failure data, has approval to handle it, and knows which reports will be reviewed. Many large receivers do not send RUF reports, so publishing the tag often changes little.
RUF caution
Do not add RUF just because the tag exists. Failure reports can expose private headers or message content, receiver support is uneven, and the reports need tighter data-handling controls than aggregate RUA XML.
When ruf is present, the optional fo tag requests which failures trigger reports. The default fo=0 requests a report when all underlying authentication mechanisms fail to produce an aligned pass. fo=1 requests one when any mechanism fails to produce an aligned pass. Receivers can still decide whether to send reports.
RUF request with the default failure conditionDNS
v=DMARC1; p=none; rua=mailto:dmarc-aggregate@example.com; ruf=mailto:dmarc-failures@example.com; fo=0
- Low coverage: Large receivers often suppress or redact message-specific failure reports.
- Sensitive data: Failure reports can include personal or confidential information that privacy controls need to cover.
- Limited payoff: RUA usually answers the operational questions needed for rollout and enforcement.
- Special cases: RUF can help with a specific investigation when a receiver sends useful reports and data handling has approval.
How to configure reporting safely
The safest setup is straightforward: publish RUA, keep RUF off unless needed, and collect reporting data before enforcing policy. A DMARC record generator helps avoid syntax mistakes.
- Create the address: Use a dedicated report address or platform ingestion address, not a personal inbox.
- Use mailto: DMARC email report URIs need the mailto: prefix.
- Authorize externally: If reports go to another domain, publish the required authorization record there.
- Start with none: Begin with p=none so failures can be measured before enforcement.
- Review reports: Group sources by owner, sending service, and pass or fail pattern.
- Tighten policy: Move to quarantine after legitimate senders pass consistently. Use reject only after assessing mailing lists and other indirect paths.
After publishing, run the domain through a DMARC checker to confirm syntax, tag values, and reporting URI formatting.
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Also confirm that the mailbox or platform endpoint receives real reports. A syntactically valid RUA tag is not useful if reports bounce, get filtered, or sit unread.
Where Suped fits
Suped's product parses RUA XML into a source inventory, authentication diagnostics, policy guidance, and alerts. This replaces a mailbox full of compressed XML with a workflow for assigning sources, finding SPF or DKIM gaps, and tracking policy readiness.
In Suped, DMARC monitoring sits alongside SPF, DKIM, blocklist and blacklist monitoring, hosted SPF, hosted MTA-STS, and real-time alerts. Hosted DMARC also lets teams stage policy changes without repeated DNS edits.
Suped DMARC dashboard showing email volume, authentication health, and source breakdown
The practical workflow is to send RUA reports into Suped, verify each legitimate sending source, fix SPF or DKIM gaps, then change policy in stages. Alerts flag new senders or failure spikes so the team can investigate before the issue affects more mail.
Practical setup
For a normal business domain, publish RUA, skip RUF at first, monitor reports in Suped, and tighten policy only after legitimate senders pass consistently and indirect-mail risks are understood.
Views from the trenches
Best practices
Point RUA at a monitored parser, not a shared mailbox that nobody checks after launch.
Start with p=none, find every sender, then tighten policy after failures are understood.
Keep RUF off unless security and privacy teams know who will review failure samples.
Use separate report addresses for key domains so ownership stays clear during incidents.
Common pitfalls
Publishing rua without the mailto: prefix means many receivers treat the URI as invalid.
Sending reports to an external domain without DNS approval causes reports to be withheld.
Leaving RUA unread creates a false sense that monitoring is happening when it is not.
Adding RUF to every domain creates sensitive data handling work with limited benefit.
Expert tips
Use RUA trends to prove readiness before moving a domain to quarantine or reject.
Check each new sender in DMARC reports before letting it send production mail safely.
Treat sudden unknown sources as an investigation trigger, even when policy is none.
Review low-volume domains too, because small systems often hide forgotten senders.
Expert from Email Geeks says RUA is recommended by major mailbox providers because it gives senders the evidence needed before reject policy.
2024-05-27 - Email Geeks
Marketer from Email Geeks says RUF is not mandatory, but some teams still receive useful reports that help diagnose specific issues.
2024-05-28 - Email Geeks
The practical choice
RUA and RUF are not mandatory for DMARC or bulk sender compliance. RUA still belongs in most records because it provides the operational data needed to identify legitimate sources, detect unauthorized use, and make policy decisions without guessing.
RUF belongs in a narrower security workflow. Start without it unless there is a specific investigation need and an approved data handling process. For most teams, the practical path is RUA into a monitored workflow, authentication fixes, then a policy chosen for the domain's mail patterns.
