What are the requirements for RUA and RUF in DMARC policies?
Michael Ko
Co-founder & CEO, Suped
Published 4 May 2025
Updated 25 May 2026
8 min read
Summarize with
The direct answer is simple: a DMARC record does not need both RUA and RUF to be valid. A basic DMARC policy needs v=DMARC1 and p= with a policy value. RUA is optional in the standard, but I treat it as the normal minimum for any domain that sends mail. RUF is optional, privacy-sensitive, and not sent by many receivers even when requested.
So the practical advice is: publish RUA unless you have a very specific reason not to, and only add RUF when you understand the privacy, retention, and processing burden. Current sender requirements from major mailbox providers focus on DMARC policy, SPF or DKIM authentication, domain matching, spam rate, and unsubscribe handling. They do not require both RUA and RUF.
Minimum: Publish a valid DMARC record with v=DMARC1 and a policy such as p=none, p=quarantine, or p=reject.
Recommended: Add RUA so aggregate reports show who is sending as your domain and whether SPF or DKIM passes with the visible From domain.
Optional: Add RUF only for controlled investigations, because failure reports can contain message-level details and personal data.
Exception: A locked single-source sending subdomain at p=reject can run without RUA, but that is a deliberate exception, not the default.
The direct requirement
RUA and RUF are reporting addresses. They do not make SPF, DKIM, or DMARC pass. They tell receivers where to send reports after DMARC evaluation. That distinction matters because the policy can be valid without reporting, but operating without reports means you have less evidence when delivery changes or a legitimate sender breaks authentication.
For day-to-day DMARC monitoring, RUA is the signal that matters most. It gives you aggregate XML reports, usually daily, grouped by source IP, sending domain, authentication result, policy result, and message count. That is enough for most rollout, troubleshooting, and spoofing analysis.
Item
Requirement
Practical answer
DMARC policy
Required
Needs version and policy tags.
RUA
Optional
Strongly recommended for senders.
RUF
Optional
Rarely useful as a baseline.
External RUA
Verified
Needs destination DNS approval.
Provider rules
Policy-focused
Do not require both reports.
How RUA and RUF compare in a DMARC policy.
Operational rule
If someone asks whether clients need to publish both RUA and RUF, the clean answer is no. If they ask what they should publish, the answer is RUA at minimum for normal sending domains.
Use RUA: It catches broken senders, unknown mail streams, and unauthorized use at scale.
Limit RUF: It has privacy implications and inconsistent receiver support.
Avoid guessing: A domain that sends through several platforms should not run blind.
How RUA works
RUA means aggregate reporting URI. In a DMARC record, the rua tag asks receivers to send aggregate reports to one or more mailboxes. These reports are usually compressed XML files. They do not contain full message content. They summarize authentication outcomes and help you map real sending sources.
If you need a deeper breakdown of report fields, the useful companion topic is RUA report content. The short version is that RUA shows source IPs, volumes, pass and fail outcomes, header From domains, DKIM domains, SPF domains, and policy disposition.
The RUA address must use the mailto: prefix. A raw email address is not a valid DMARC reporting URI. Multiple RUA destinations are allowed, but I keep them limited because reports can become noisy and receivers apply size and rate limits.
When reports go to a different domain, the destination domain needs to publish a verification TXT record. This prevents one domain owner from flooding an unrelated domain with DMARC reports.
Flowchart showing mail sent, receiver checks, DMARC result, aggregate report, and owner review.
How RUF works
RUF means failure reporting URI. The ruf tag asks for message-level failure reports when DMARC fails. This is why RUF is more sensitive than RUA. A failure report can include headers, authentication details, and in some cases redacted or partial message data. That creates privacy and legal concerns for receivers and domain owners.
The practical issue is receiver support. Some receivers do not send RUF at all. Others send it only under narrow conditions. Even where RUF is available, heavy redaction can remove the details you hoped to use. If you are deciding between the two, read RUA versus RUF first.
RUA aggregate reports
Scope: Domain-level summary data grouped by source and result.
Privacy: Lower risk because message bodies are not included.
Use: Best for rollout, audits, source discovery, and trend tracking.
Coverage: Broadly sent by major receivers.
RUF failure reports
Scope: Message-level failure data for specific events.
Privacy: Higher risk because personal data can appear.
Use: Useful for limited incident investigation.
Coverage: 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. That means the domain owner receives personal data they did not already have.
Review access: Limit who can read RUF reports.
Set retention: Delete reports when the investigation no longer needs them.
Check contracts: Confirm processing terms before routing RUF to a third party.
Avoid defaults: Do not add RUF just because it exists as a tag.
For a new DMARC rollout, I would start with RUA and no RUF. That gives you operational visibility without pulling message-level failure data into your process. After you know every legitimate source and SPF or DKIM is passing with the visible From domain, move the policy toward enforcement.
If the domain is already well controlled, the same RUA pattern works with p=quarantine or p=reject. The policy value tells receivers what to do with failing mail. The RUA value tells you what is happening after receivers evaluate that mail.
Recommended reporting posture
A practical scale for deciding how much DMARC reporting to request.
No reporting
Weak
Valid but low visibility.
RUA only
Recommended
Best default for most senders.
RUA plus enforcement
Strong
Best mature-state posture.
RUA plus RUF
Sensitive
Use for controlled investigations.
A validator is useful before DNS changes go live. Suped has a DMARC checker for record checks and a DMARC record generator when you want a clean TXT value without hand-editing every tag.
For teams that change senders often, Hosted DMARC reduces DNS churn because policy staging can happen in the platform after the initial setup. That is useful when security, marketing, and IT all touch the same domain.
DMARC record generator
Choose your policy, reporting addresses, and alignment settings.
The key is to avoid treating the generated record as a one-time task. RUA reports should feed a process: identify sources, fix missing DKIM, correct SPF paths, move to enforcement, then keep watching for drift.
Suped's product is the best overall fit for most teams that want that process handled in one place. It turns RUA XML into source-level findings, gives automated issue detection, shows steps to fix, supports real-time alerts, and connects DMARC with SPF, DKIM, hosted SPF, hosted MTA-STS, SPF flattening, and blocklist (blacklist) monitoring.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Provider and compliance reality
The newer DMARC standard set separates the core protocol, aggregate reporting, and failure reporting into separate documents. That change makes the reporting types clearer, but it does not turn RUA or RUF into mandatory tags for every sender. RUA remains the operational default. RUF remains a specialized request.
Major mailbox provider sender rules have pushed DMARC adoption forward, especially for bulk senders, but the requirement is not "publish both RUA and RUF." The requirement is much closer to this: authenticate mail, use a domain in the From header that matches SPF or DKIM identity, keep complaint rates low, and publish a DMARC policy.
Infographic contrasting required DMARC policy tags with recommended RUA and optional RUF reporting.
That is why RUA is the advice I give clients even when it is not required by the record syntax. RUA closes the feedback loop. Without it, you find out about problems through delivery drops, ticket volume, or a sender telling you something broke after the fact.
Client-ready advice
The clean recommendation for most organizations is simple: publish RUA, skip RUF by default, and revisit RUF only when there is a defined security investigation with approved data handling.
Baseline: Every active sending domain gets RUA reporting.
Enforcement: Move toward reject after legitimate sources pass consistently.
RUF review: Require privacy approval, access controls, and retention rules.
MSP use: Use a multi-tenant dashboard when managing reports across many domains.
When omitting RUA is acceptable
There are cases where no RUA is defensible. The most common one is a dedicated subdomain used by one known sending platform, with SPF and DKIM already configured, and a strict DMARC policy already enforced. If nothing else ever sends from that subdomain, the value of ongoing reports is lower.
I still prefer keeping RUA on unless there is a reason to remove it. Domains change. Vendors change. A marketing team adds a sending integration. A billing platform starts sending receipts. RUA is the early warning system for those changes.
Keep RUA
Shared domain: Several teams or vendors send mail.
New rollout: Sources are still being discovered.
Compliance work: Evidence is needed for controls and reviews.
High volume: Small failures affect many messages.
Omit RUA only when
Single source: One platform sends all mail.
Strict policy: The subdomain already uses reject.
Documented owner: One team owns the sender.
Review path: Another control catches sending drift.
For organizations with many brands, regions, or client domains, the reporting problem becomes an operations problem. Suped's MSP and multi-tenancy dashboard is built for that setup: separate organizations, domain status views, alerts, client reporting, and source-level findings in one place.
The same logic applies to RUF in reverse. Instead of asking why RUF is missing, ask what decision RUF would help you make 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 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 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
Practical bottom line
RUA and RUF are not both required. RUA is the practical minimum for most sending domains. RUF is a specialist option, not a baseline requirement. If I were advising a client, the default record would include RUA, omit RUF, and move toward enforcement once reports confirm every legitimate source is passing.
Suped fits this workflow because it focuses on the operational side of DMARC: parsing RUA reports, identifying verified and unverified sources, surfacing issues, giving steps to fix, and alerting when authentication health changes. That is what makes RUA valuable in practice.
Frequently asked questions
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
