What are the requirements for RUA and RUF in DMARC policies?
Updated on 11 Oct 2026: We clarified RUA and RUF reporting requirements and added checks for missing reports.
A DMARC record does not need either RUA or RUF to be valid. Under RFC 9989, v=DMARC1 is the only required tag and it must appear first. The p tag is recommended; if it is omitted from an otherwise valid record, receivers treat the policy as p=none. For real deployments, publish p explicitly for compatibility with older receivers and to meet mailbox provider sender requirements.
RUA is optional in the standard, but it is the practical minimum for an active sending domain because it provides aggregate visibility. RUF is optional, privacy-sensitive, and not sent by many receivers even when requested. Major mailbox provider requirements focus on an explicit DMARC policy, SPF and DKIM authentication, alignment, complaint rates, and unsubscribe handling. They do not require RUA or RUF.
- Publish v=DMARC1 first. An omitted p defaults to none under RFC 9989.
- For mailbox provider requirements, state p=none, p=quarantine, or p=reject explicitly.
- Add RUA so aggregate reports show who is sending as your domain and whether SPF or DKIM passes in alignment with the visible From domain.
- Add RUF only for a controlled investigation, because failure reports can contain message-level details and personal data.
- A locked single-source sending subdomain at p=reject can run without RUA, but that should be a documented decision.
Are RUA and RUF mandatory?
RUA and RUF are reporting destinations. They do not make SPF, DKIM, or DMARC pass. They tell receivers where to send reports after DMARC evaluation. A policy record can be valid without reporting, but operating without reports leaves less evidence when delivery changes or a legitimate sender breaks authentication.
For day-to-day DMARC monitoring, RUA is the main signal. It provides aggregate XML reports grouped by source IP, authentication result, policy result, and message count. Combining reports over time and mapping source IPs to recognizable sending services makes lower-volume failures easier to find.
|
|
|
|---|---|---|
DMARC version | Required | v=DMARC1 must appear first. |
DMARC policy | Recommended by RFC 9989 | Omission defaults to none; state p explicitly. |
RUA | Optional | Strongly recommended for active senders. |
RUF | Optional | Use for controlled investigations. |
External RUA or RUF | Authorization required | The destination DNS must authorize the domain publishing the applied DMARC policy. |
Provider rules | Policy-focused | Do not require either report tag. |
How RUA and RUF compare in a DMARC policy.
Operational rule
If someone asks whether a client needs to publish both RUA and RUF, the answer is no. If they ask what to publish for normal operations, use an explicit policy and RUA.
- Use RUA to find broken senders, unknown mail streams, and unauthorized use at participating receivers.
- Limit RUF because it has privacy implications and inconsistent receiver support.
- A domain that sends through several platforms should not run without aggregate evidence.
How RUA works
RUA specifies the reporting URI for aggregate reports. In a DMARC record, the rua tag asks receivers to send aggregate reports to one or more destinations. These reports are usually compressed XML files sent daily. They do not contain full message content. They summarize authentication outcomes and help map legitimate and unauthorized sending sources. They include passing and failing messages, including when the policy is p=none. RFC 9990 defines aggregate reporting.
For a deeper breakdown of report fields, see RUA report content. RUA shows source IPs, volumes, pass and fail outcomes, header From domains, DKIM domains, SPF domains, and the policy disposition evaluated by the receiver. A reported disposition is not confirmation of inbox placement.
Basic DMARC record with RUAdns
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"
Use the mailto: scheme for reliable interoperability. RFC 9989 permits any valid URI, but receivers are only required to support mailto:. A raw email address is not a valid reporting URI. Separate multiple RUA destinations with commas, and keep the list limited because report delivery is still subject to receiver limits. The same URI syntax applies to ruf.
When reports go to a different organizational domain, the destination must publish an authorization TXT record for the domain publishing the applied DMARC policy. This prevents a domain owner from directing report traffic at an unrelated mailbox. If authorization is missing, a conforming receiver does not send reports to that external destination. Destinations within the same organizational domain do not need this external authorization.
For rua=mailto:aggregate@reports.example.net in the DMARC policy at _dmarc.example.com, the administrator of reports.example.net publishes this record. Use the exact destination host and the domain where the applied policy was found.
External report authorizationdns
example.com._report._dmarc.reports.example.net. IN TXT "v=DMARC1"
RUA aggregate reporting workflow showing email delivery, DMARC checks, report generation, and owner review.
How RUF works
RUF specifies the reporting URI for failure reports, also called forensic reports. The ruf tag requests message-specific reports for authentication failures. The fo tag requests which failure conditions trigger a report; its default is fo=0, and receivers ignore fo when ruf is absent.
RUF is more sensitive than RUA because a report can include headers, authentication details, and the entire original message, depending on the receiver's privacy policy. That creates privacy, retention, and security concerns for receivers and domain owners. External RUF destinations use the same DNS authorization process as external RUA destinations. RFC 9991 defines the Authentication Failure Reporting Format (AFRF) used for DMARC failure reports.
Receiver support remains the practical limit. Some receivers do not send RUF. Others send it only under narrow conditions, and redaction can remove the details needed for an investigation. The RUA versus RUF comparison explains the report fields in more detail.
|
|
|---|---|
fo=0 | A DMARC failure report if neither SPF nor DKIM passes with the required domain alignment (default). |
fo=1 | A DMARC failure report if either mechanism lacks a passing result with the required domain alignment, even when the other makes DMARC pass. |
fo=d | A DKIM-specific failure report for a signature that fails evaluation, regardless of domain alignment. |
fo=s | An SPF-specific failure report when SPF evaluation fails, regardless of domain alignment. |
Failure reporting options defined by RFC 9989.
DMARC evaluation and the p policy are independent of fo. Combine compatible options with colons, such as fo=1:d; 0 and 1 are mutually exclusive. RFC 9989 defines the options.
RUA aggregate reports
- Reports summarize domain-level data grouped by source and result.
- Privacy risk is lower because message bodies are not included.
- RUA supports rollout, audits, source discovery, and trend tracking.
- Major receivers broadly support aggregate reporting.
RUF failure reports
- Reports contain message-specific failure data for individual events.
- Privacy risk is higher because personal data can appear.
- RUF supports a limited incident investigation.
- Failure reporting is inconsistent and often unavailable.
Treat RUF as sensitive data
RUF can create a data-sharing problem. A receiver can send failure details about a recipient who has no relationship with the domain owner. The domain owner then receives personal data it did not already have.
- Limit who can read RUF reports.
- Delete reports when the investigation no longer needs them.
- Confirm processing terms before routing RUF to a third party.
- Do not add RUF just because the tag exists.
DMARC record with RUA and RUFdns
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-agg@example.com; ruf=mailto:dmarc-fail@example.com; fo=1"
Receivers apply support rules and rate limits. Immediate reports or one report for every failure are not guaranteed.
What the current DMARC RFCs changed
- Only v=DMARC1 is required, and it must be the first tag.
- The p tag is recommended, and omission is processed as p=none.
- The pct, rf, and ri tags are historic in the current registry. The URI suffix for requesting a maximum report size was also removed.
- Publishing rua or ruf requests reports. It does not guarantee that every receiver will send them.
Older examples that use pct for a staged rollout describe the previous specification. RFC 9989 introduces the optional t testing tag, but explicit policy changes combined with RUA review remain easier to audit.
A practical starting record
For a new DMARC rollout, start with RUA and no RUF. That provides operational visibility without pulling message-specific failure data into the process. After every legitimate source is known and SPF or DKIM passes in alignment with the visible From domain, move the policy toward enforcement.
Recommended starting recorddns
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-agg@example.com"
These examples use DNS zone-file notation. In a DNS control panel, enter _dmarc as the host if the zone name is appended automatically, select TXT, and enter the v=DMARC1; ... value without the surrounding zone-file quotes. Keep all policy and reporting tags in one DMARC TXT record.
If the domain is already well controlled, the same RUA pattern works with p=quarantine or p=reject. The policy value tells receivers how the domain owner wants failing mail handled. The RUA value requests evidence about what receivers evaluated.
Reporting choices and enforcement
Reporting options for routine operations and targeted investigations.
No reporting
Low visibility
Valid, with no aggregate visibility.
RUA only
Recommended
The normal default for most senders.
RUA plus enforcement
Enforcement
Monitor authentication after quarantine or reject.
RUA plus RUF
Sensitive
Use for controlled investigations.
Check a record before publishing and confirm the live DNS value afterward. Suped has a DMARC checker for syntax and policy checks, plus a DMARC record generator for building a clean TXT value.
For teams managing DMARC policy changes, Suped's Hosted DMARC reduces DNS changes because policy staging can happen in Suped after the initial setup. This is useful when several teams share the same domain.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
DNS TXT record
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com
Do not treat a generated record as a one-time task. RUA reports should feed a repeatable process: identify sources, fix missing DKIM or broken SPF paths, move to enforcement, and keep watching for authentication drift.
Suped's DMARC reporting product turns RUA XML into source-level findings, flags authentication issues, provides remediation steps, and alerts teams when results change. Use those findings to confirm legitimate sending sources before changing the policy.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Provider requirements and report tags
Mailbox provider sender rules have increased DMARC adoption, especially among bulk senders, but they do not require RUA or RUF. For covered bulk mail to personal Gmail accounts, Google sender guidelines require SPF and DKIM, an explicit DMARC policy that can be p=none, and alignment between the visible From domain and at least one authenticated identity.
Under Yahoo sender requirements, covered bulk senders must publish a valid DMARC policy with at least p=none and pass DMARC. Yahoo strongly recommends a properly configured rua tag for monitoring, but recommendation is different from a requirement.
DMARC infographic comparing provider policy requirements with recommended RUA and optional RUF reporting.
RUA remains practical advice even when it is not required by record syntax or provider rules. RUA provides feedback on authentication outcomes. Without it, teams often discover problems through delivery drops, support tickets, or a sending service reporting a failure after the fact.
Client-ready advice
The recommendation for most organizations is simple: publish an explicit policy with RUA, skip RUF by default, and revisit RUF only for a defined investigation with approved data handling.
- Request RUA reporting for every active sending domain.
- Move toward reject after legitimate sources pass consistently.
- Require privacy approval, access controls, and retention rules before using RUF.
- Use tenant separation when managing reports across client domains.
Why RUA or RUF reports are missing
RUA reports usually cover a daily reporting period, so they are not immediate delivery receipts. Allow 24-48 hours after publishing the record and sending mail before investigating missing aggregate reports. This is an operational waiting window, not a delivery guarantee.
- Check the live TXT record at _dmarc.yourdomain. Confirm that it contains rua or ruf with a valid mailto: URI, and remove duplicate DMARC policy records.
- Check that the reporting mailbox exists and accepts external mail and compressed XML attachments. Review storage limits and spam quarantine.
- Verify external destination authorization at the exact DNS name described above.
- Confirm that mail reached a receiver that generates reports. No observed traffic means no aggregate data for that receiver to report.
- For RUF, confirm receiver support and the requested fo conditions. Rate limits and privacy policies restrict failure reports even when the DNS record is correct.
When omitting RUA is acceptable
There are cases where no RUA is defensible. The most common is a dedicated subdomain used by one known sending platform, with SPF and DKIM already configured and a strict DMARC policy enforced. If nothing else sends from that subdomain, the value of ongoing reports is lower.
Keeping RUA is still the safer operational choice unless there is a reason to remove it. Domains and vendors change. A team adds a sending integration, or a billing platform starts sending receipts. RUA provides early evidence of those changes.
Keep RUA
- Several teams or vendors send mail through a shared domain.
- Sending sources are still being discovered during a new rollout.
- Evidence is needed for controls and compliance reviews.
- High message volume means small failures affect many messages.
Omit RUA only when
- One platform sends all mail.
- The subdomain already uses reject.
- One documented team owns the sender.
- Another control catches sending drift.
For organizations with many brands or client domains, reporting becomes an operations task. Suped's MSP and multi-tenancy dashboard keeps organizations separate while providing domain status, alerts, client reporting, and source-level findings in one place.
Apply the same logic to RUF in reverse. Ask what decision RUF would support that RUA cannot. If there is no concrete decision, leave RUF out.
Views from the trenches
Best practices
Publish RUA on every active sending domain unless a documented exception explains why.
Treat RUF as sensitive data and approve access, routing, and retention before use.
Use dedicated subdomains for narrow mail streams when teams need simpler enforcement.
Common pitfalls
Adding RUF by default creates privacy work without reliable report volume or coverage.
Leaving RUA out on shared domains hides legitimate senders until delivery breaks.
Publishing reports to another domain fails when the destination has no approval TXT.
Expert tips
Start with RUA-only reporting, fix known sources, then move policy to enforcement.
Keep RUA on enforced domains so later vendor or routing changes do not go unnoticed.
Use RUF only when the investigation needs message-level evidence and controls exist.
Expert view
Expert from Email Geeks says neither RUA nor RUF is mandatory, but RUA is strongly recommended because it prevents blind operation.
2024-01-23 - Email Geeks
Marketer view
Marketer from Email Geeks says RUA matters more than RUF because failure reports are rare and most teams need aggregate visibility first.
2024-01-23 - Email Geeks
