DMARC RUA is the reporting address inside your DMARC record that tells mailbox providers where to send aggregate reports. If you publish DMARC without dmarc rua, you're flying half-blind. You have a policy, but you can't see which services pass, which ones fail, and which random servers are spoofing your domain. If you're still sorting out the basics of domain mail, start with business email for small business first, then come back here.
That blind spot gets expensive fast. One CRM is misconfigured. A forgotten WordPress plugin still sends from your root domain. A forwarded message breaks SPF. Suddenly Gmail starts distrusting your mail, and you don't know why. The whole point of dmarc rua is to turn that mess into something you can actually inspect.
This guide gets to the answer fast: what dmarc rua is, how to publish it, what the XML reports mean, and what you should fix first when the numbers look bad.
What is dmarc rua?
dmarc rua is the DMARC tag that tells receivers where to send aggregate authentication reports. Those reports summarize SPF, DKIM, alignment, sending IPs, and DMARC disposition over a reporting period, usually daily.
In a DMARC record, rua=mailto:... means "send aggregate reports here." Per RFC 7489, the presence of the rua tag specifies where to send feedback, and those reports contain data about authentication results, alignment, sending and receiving domains, message counts, and applied policy.
That matters because DMARC enforcement without visibility is guesswork. You can set p=none, p=quarantine, or p=reject, but dmarc rua is what shows whether your real traffic is ready for that policy.
What dmarc rua reports actually show
dmarc rua reports are aggregate summaries, not copies of individual emails. They tell you who sent mail claiming to be from your domain, whether SPF and DKIM passed, and whether DMARC alignment passed.
Think of dmarc rua as a daily operational report. You won't get message bodies. You will get enough to spot broken vendors, spoofing, and alignment problems.
| Tag | What it does | What you get | Best use |
|---|---|---|---|
rua | Requests aggregate reports | XML summaries by source IP and auth result | Daily monitoring and rollout |
ruf | Requests failure reports | Per-message forensic samples, when supported | Targeted troubleshooting only |
Most teams should start with dmarc rua and ignore ruf unless they have a very specific reason. Aggregate reports are widely used. Forensic reports are inconsistently sent and raise more privacy questions.
Example: Your domain sends from Google Workspace, a billing app, and a help desk. dmarc rua will show all three sources. If the help desk is failing DKIM alignment, you'll see it. If a server in another country is spoofing your domain, you'll see that too.
How to publish a dmarc rua record
To publish dmarc rua, add a TXT record at _dmarc.yourdomain.com and include a valid rua=mailto: address. Start with monitoring mode before you tighten enforcement.
This is the safest starter record for most domains:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"If you just want the bare minimum, this also works:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Use a dedicated mailbox or a dedicated parsing service for dmarc rua. Don't point it at your main support inbox unless you enjoy reading compressed XML attachments all week.
If you're setting this up inside TrekMail, the DNS side is covered in Required DNS Records. TrekMail checks for valid SPF, DKIM, and DMARC records during domain setup, which cuts down on the usual typo-driven outages.
How to verify your dmarc rua record
You verify dmarc rua the same way you verify any DNS-based mail setting: query DNS directly, then wait for reports to arrive. If DNS is wrong, no receiver will know where to send the data.
Use dig or nslookup:
dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.comYou should see your DMARC TXT record in the answer. Per RFC 7489, a record like this is valid:
"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"Then wait. dmarc rua reports usually arrive on a daily cadence, but not every provider sends them on the same schedule. Some send more often. Some barely bother. That's normal.
How to read a dmarc rua report without getting lost
A dmarc rua report looks ugly in raw XML, but the logic is simple: find the source, check SPF and DKIM, then check alignment and DMARC disposition. Ignore the format. Follow the sequence.
Read dmarc rua reports in this order:
- Find the source IP and reverse DNS. Identify whether it's one of your systems or a stranger.
- Check message count. A source with 2 messages matters less than a source with 20,000.
- Check SPF result, DKIM result, and alignment. A pass without alignment can still fail DMARC.
- Check disposition.
nonemeans monitored,quarantinemeans marked,rejectmeans blocked. - Decide whether the source is legitimate, misconfigured, or spoofed.
Google's current sender guidance is blunt: for mail sent directly to personal Gmail accounts, the organizational domain in the From: header must align with either SPF or DKIM, and Google recommends always setting up DMARC. That's why dmarc rua matters. It shows where your real-world alignment breaks before inbox placement gets worse.
The three dmarc rua failure patterns that matter
Most dmarc rua noise falls into three buckets: legitimate senders missing auth, forwarding-related SPF failures, and outright spoofing. Treat them differently or you'll break good mail while chasing bad mail.
1. Legitimate sender, bad setup
This is the common one. A real system is sending for your domain, but it's not in SPF, not signing with aligned DKIM, or both. Fix the source. Don't touch policy first.
If you're using TrekMail with your own sender, match the DNS instructions to the sending path. If you bring your own provider, see Bring Your Own SMTP. If you're on TrekMail's included sending, Managed TrekMail SMTP handles the sending layer and DKIM signing on paid plans.
2. SPF fails because of forwarding
This is expected. A forwarded message often breaks SPF because the forwarder is now the connecting server. That doesn't mean the message is bad. If DKIM still passes and aligns, DMARC passes anyway. TrekMail's own spam troubleshooting docs call this out directly: SPF fail plus DKIM pass is commonly fine for forwarded mail.
If forwarding is part of your setup, read email forwarding and forward domain email to Gmail. This is where operators confuse SPF failure with DMARC failure and create their own outage.
3. Unknown source, obvious spoofing
If dmarc rua shows mail from an IP or provider you don't use, the system is doing its job. Don't add that sender to SPF. Don't whitelist it. Tighten policy once you're sure your real sources are clean.
Should you point dmarc rua to a third-party service?
Yes, if you want easier parsing. No, if you don't understand the DNS requirement. External dmarc rua destinations need authorization or some receivers will ignore them.
This is a detail people miss. RFC 7489 says that when your rua destination is outside your organizational domain, the receiving side may require an authorization record at a host like:
example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"If that confirming record doesn't exist, some report generators will ignore the external destination. So if you use a DMARC analyzer vendor, follow their exact setup steps. One missing TXT record and your dmarc rua inbox stays quiet for the wrong reason.
When to move from p=none to quarantine or reject
Use dmarc rua data first, then change policy. If your legitimate senders are passing consistently and the remaining failures are spoofing or junk, move from monitoring to enforcement.
A practical rollout looks like this:
- Publish dmarc rua with
p=none. - Watch reports for at least 1 to 2 weeks.
- Fix every legitimate sender that fails SPF or DKIM alignment.
- Move to
p=quarantineif failures are mostly spoofing. - Move to
p=rejectwhen you're confident no valid traffic is left behind.
If you skip the observation phase, you'll learn about the broken sender from a customer instead of from dmarc rua. That's the expensive version.
Old Way vs New Way for dmarc rua operations
The old way is manual XML triage across every domain. The new way is standardized DNS, visible auth status, and one place to manage domains, mailboxes, migration, and sending.
| Old way | New way with TrekMail |
|---|---|
| Every domain has different SPF, DKIM, and DMARC habits | One dashboard to track domain DNS and mailbox operations |
| Admins guess which sender broke alignment | Clear DNS setup flow and mail troubleshooting docs |
| Forwarding problems get blamed on SPF alone | Standards-first setup with DMARC, DKIM, and forwarding in mind |
| Per-user pricing punishes growth across many domains | Flat-rate plans start at $3.50/mo, with pooled storage and no per-user fees |
TrekMail isn't a DMARC analyzer. That's not the point. The point is cleaner infrastructure around the problems dmarc rua exposes: custom domains, IMAP mailboxes, catch-all, mailbox forwarding, built-in IMAP migration, and either BYO SMTP or included SMTP depending on plan. For teams managing lots of domains, that cleanup matters more than another dashboard full of red charts.
Plans start at $3.50/month. The Nano plan stays free and doesn't need a card. Paid plans include a 14-day free trial.
Conclusion: dmarc rua is your visibility layer
dmarc rua gives you the reporting loop that makes DMARC usable in production. Without dmarc rua, you're guessing. With it, you can see failed senders, forwarding side effects, spoofing attempts, and whether your domain is actually ready for enforcement.
If you run one domain, dmarc rua helps you stop stupid mistakes before they hurt deliverability. If you run fifty or five hundred, dmarc rua is how you keep policy changes grounded in evidence instead of hope. Set it up, read it weekly, and fix the real sources before you touch policy.
Then get the rest of the stack under control. TrekMail gives you flat-rate multi-domain hosting, pooled storage, invite-based mailbox provisioning, and built-in IMAP migration without the usual per-seat tax. Start at trekmail.net if you want the mail platform to stop being the bottleneck.
