Are DMARC RUA and RUF tags mandatory for compliance and what are their benefits?
Published 2 Jul 2025
Updated 22 Oct 2026
11 min read
Summarize with
Updated on 22 Oct 2026: We clarified when DMARC reporting is optional and how to troubleshoot missing reports.
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 meets the minimum DMARC policy requirement, but does not satisfy all of their 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.
Publish rua for ongoing monitoring; add ruf only for a defined investigation. With a valid explicit policy, removing either reporting tag stops requests for that report type without disabling DMARC evaluation or changing the requested policy.
Are RUA and RUF required for DMARC compliance?
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 require SPF and DKIM authentication, plus a DMARC policy of at least p=none. A message passes DMARC when at least one of SPF or DKIM passes with domain alignment to the visible From 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: Google sender guidelines and Yahoo sender requirements require an explicit DMARC policy for bulk senders. Both recommend RUA for monitoring; neither requires RUA or RUF.
- Outlook.com: Microsoft's high-volume sender requirements apply to domains sending more than 5,000 messages per day to its consumer mailboxes. SPF and DKIM must pass, with DMARC at p=none or stricter and SPF or DKIM domain alignment. RUA and RUF are not listed as mandatory.
- 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 provides evidence for deciding whether policy changes are safe.
What RUA and RUF reports contain
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. RFC 9990 defines aggregate reporting. Reports include reporter metadata, the published policy, source IPs, message counts, dispositions, identifiers, and SPF or DKIM results for both passing and failing traffic. 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 requests message-specific failure reports, also called forensic reports, under the requested fo conditions. RFC 9991 defines DMARC failure reporting. 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.
Receiver authentication checks feed DMARC RUA aggregate reports used for policy decisions.
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.
DMARC record examples with and without reporting
An explicit policy without reporting can meet the DMARC policy requirement, but it gives no aggregate feedback. A monitoring record adds RUA, then uses the reports to identify legitimate senders before policy changes.
For example.com, publish one DMARC TXT record at _dmarc.example.com. Replace the example report address with a mailbox or ingestion address that you control. p=none requests no change to existing mail handling; other spam filtering still applies.
Minimal DMARC policy without reportingDNS
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 is outside the policy domain's organizational domain, that external report domain needs DNS authorization. Without that authorization, receivers must ignore the destination 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, with a mailto: prefix for each email address. Each external destination needs authorization.
|
|
|
|
|---|---|---|---|
v | Yes | DMARC version | Use DMARC1 first |
p | Recommended by RFC 9989; required by bulk sender rules | Policy | Publish p=none or stricter 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 one less restrictive policy: quarantine becomes none, and reject becomes quarantine. It does not affect report generation. Older receivers ignore this tag, so use p=none for an initial monitoring policy.
- General-purpose email: RFC 9989 advises against p=reject for domains whose users post to mailing lists. Before making an exception, measure indirect-mail impact with p=none for at least a month, then p=quarantine for an equally long period.
- Reporting cadence: Receivers should send aggregate reports at least once every 24 hours, but the historic ri tag no longer requests a custom interval. Reporting remains voluntary, so this is not a delivery guarantee.
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. Sending domains using p=reject must apply valid DKIM signatures rather than rely solely on SPF. RUA data provides evidence for assessing indirect-mail impact.
Why RUA belongs in most records
RUA turns a published DMARC policy into a monitored one. 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 to quarantine and for deciding whether reject suits the domain.
- Domain abuse: RUA helps identify unauthorized sources trying to use the domain. Forwarding can also create unfamiliar source IPs, so investigate before classifying a source as abuse.
- 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. Keep monitoring after enforcement to catch new senders or broken authentication. Publishing a reporting tag does not itself improve inbox placement.
When RUF failure reports are useful
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 neither SPF nor DKIM produces a pass with domain alignment. fo=1 requests a report if either mechanism fails to do so, even if the other mechanism produces a DMARC pass. The fo tag has no effect without ruf and does not change enforcement or RUA reporting. 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 outside the policy domain's organizational domain, the report destination's DNS administrator must 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.
Why DMARC reports are missing
A valid RUA tag requests reports; it does not guarantee delivery. Check the reporting path before changing the DMARC policy.
- Allow time: Wait for DNS caching to expire and at least one daily reporting cycle after traffic reaches a receiver that sends reports.
- Confirm traffic and coverage: Receivers report on mail they process, and some do not send reports. RUA totals are not a complete count of all mail sent using the domain.
- Check delivery: Inspect report delivery logs, spam filtering, attachment limits, and mailbox quotas. Aggregate reports arrive as XML attachments, often compressed.
- Verify external authorization: Check the TXT record in the report destination domain. Authorize every external destination in a comma-separated reporting list.
For example, if _dmarc.example.com requests rua=mailto:dmarc@reports.example.net, the DNS administrator for reports.example.net publishes the following authorization record, as specified in RFC 9990.
External reporting authorization exampleDNS
example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1;"
Missing RUF reports alone are not evidence of a configuration error. Google's DMARC documentation explicitly says Gmail does not support RUF failure reports.
How Suped processes RUA reports
Suped's DMARC reporting platform parses RUA XML into a source inventory and authentication diagnostics, with 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 groups received reports so teams can review sources and authentication failures. Hosted DMARC lets teams stage policy changes without repeated DNS edits after the initial delegation.
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 for investigation after reports are received.
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.
Frequently asked questions
Yes. A DMARC record with an explicit valid policy can pass validation without rua. Receivers will not generate aggregate reports for the domain without that tag, but DMARC evaluation and the requested policy still apply.
No. RUF is not required, and Gmail does not support the ruf tag for failure reports. Treat RUF as optional, not as a baseline sender requirement.
RUA is recommended for active sending domains. It is not mandatory, but it is the main way to see whether legitimate mail passes DMARC and whether unauthorized sources are using the domain. Keep reviewing reports after enforcement to catch changes.
RUA is useful for parked or non-sending domains because it shows attempted use of the domain. Pair it with a strict policy after confirming that the domain sends no legitimate mail. No traffic or limited receiver reporting can also explain an absence of reports.
Yes. When the destination is outside the policy domain's organizational domain, the destination's DNS administrator must publish the required reporting authorization TXT record. Without it, receivers must ignore that report destination.
No. RFC 9989 registers pct as historic and introduces t=y for testing treatment. Receivers that support t=y apply a policy one level less restrictive; older receivers ignore the tag. Start monitoring with p=none rather than relying on universal test-mode support.
