DMARC RUA: How to Send Reports to Multiple Addresses
Learn how to configure multiple DMARC RUA destinations, set up DNS authorization for external report domains, and avoid common reporting mistakes.
DMARC aggregate reports are the foundation of email authentication visibility. The rua tag in your DMARC record tells receiving servers where to send these reports — and you are not limited to a single address. Sending reports to multiple destinations is common, practical, and sometimes essential.
Why Send Reports to Multiple Addresses
Most businesses have more than one reason to collect DMARC data:
- Internal monitoring — your IT team needs reports to track authentication health
- Third-party analysis — a DMARC reporting service that parses XML into readable dashboards
- Security team — a separate mailbox for incident investigation
- Managed service provider — your email or DNS provider may want copies for support
With a single RUA address, you have to choose one destination. With multiple addresses, everyone who needs the data gets it directly from the source.
How to Configure Multiple RUA Addresses
Add multiple mailto: URIs in the rua tag, separated by commas:
v=DMARC1; p=reject; rua=mailto:[email protected],mailto:[email protected]; fo=1
Each address receives an identical copy of every aggregate report. There is no limit defined in the DMARC specification on how many addresses you can include, but in practice, two or three is typical. More than that can make your DNS record unnecessarily long.
Use a dedicated mailbox
Don't send DMARC reports to a personal or shared team inbox. Even moderately active domains generate dozens of XML reports daily. A dedicated address — or better, a reporting service — keeps things manageable.
Same-Domain vs External Addresses
This is where most people run into trouble. Sending reports to an address on the same domain as your DMARC record works automatically. Sending reports to a different domain requires an extra DNS record.
| Scenario | Example | Extra DNS needed? |
|---|---|---|
| Same domain | `rua=mailto:[email protected]` | No |
| Subdomain of same domain | `rua=mailto:[email protected]` | No |
| External domain | `rua=mailto:[email protected]` | Yes |
The DNS Authorization Record
When your RUA address is on a different domain, the receiving domain must publish a DNS TXT record that explicitly authorizes it to receive reports for your domain. Without this record, most email providers will silently drop the reports.
Your DMARC record (on yourdomain.com):
v=DMARC1; p=reject; rua=mailto:[email protected]
Authorization record (on analyticsprovider.com):
yourdomain.com._report._dmarc.analyticsprovider.com TXT "v=DMARC1"
The format is: [monitored-domain]._report._dmarc.[receiving-domain]
This tells email providers: "Yes, analyticsprovider.com has agreed to receive DMARC reports for yourdomain.com."
No authorization = no reports
If the external domain hasn't published this TXT record, providers like Google and Microsoft will not send reports to that address. Your DMARC record won't show an error — the reports simply won't arrive. Always verify the authorization record is in place before relying on an external address.
Wildcard Authorization
Some DMARC reporting services publish a wildcard authorization record so they can receive reports for any domain:
*._report._dmarc.analyticsprovider.com TXT "v=DMARC1"
If your reporting provider uses this approach, you don't need to ask them to create a per-domain record. Check their documentation or ask their support team to confirm.
Practical Examples
Internal Monitoring + Reporting Service
The most common setup. Your internal team gets copies and a third-party service provides dashboards and alerts.
v=DMARC1; p=reject; rua=mailto:[email protected],mailto:[email protected]; fo=1
Make sure dmarcservice.com has published the authorization record for your domain — or has a wildcard record in place.
Multiple Internal Teams
Your security team and your IT operations team both want separate copies.
v=DMARC1; p=quarantine; rua=mailto:[email protected],mailto:[email protected]
Both addresses are on the same domain, so no external authorization is needed.
MSP Managing Client Domains
A managed service provider monitoring DMARC for a client needs reports sent to their own domain.
v=DMARC1; p=reject; rua=mailto:[email protected],mailto:[email protected]
The MSP must have published:
clientdomain.com._report._dmarc.msp.com TXT "v=DMARC1"
Common Mistakes
Missing the Authorization Record
This is the number one issue. You add an external address to your RUA tag, reports never arrive, and you assume DMARC reporting is broken. In reality, the external domain just hasn't authorized itself to receive your reports.
Use the free DMARC record checker to verify your record is valid, then confirm the authorization record separately using a DNS lookup tool.
Comma Formatting Errors
The separator between multiple RUA addresses must be a comma with no spaces around the mailto: prefix:
# Correct
rua=mailto:[email protected],mailto:[email protected]
# Incorrect — space after comma can cause parsing issues
rua=mailto:[email protected], mailto:[email protected]
# Incorrect — missing mailto: prefix
rua=mailto:[email protected],[email protected]
Some receivers are forgiving about whitespace, but others are not. Keep it clean to ensure compatibility.
DNS Record Length Limits
A standard DNS TXT record has a 255-character string limit per chunk, though multiple chunks can be concatenated. If your DMARC record gets very long — multiple RUA addresses, RUF addresses, and other tags — it can cause DNS issues.
In practice, two or three RUA addresses rarely hit this limit. But if you're adding more, check that your DNS provider handles long TXT records correctly.
Not Monitoring the Reporting Addresses
Setting up RUA addresses and never reading the reports is a missed opportunity. DMARC reports tell you:
- Which IPs are sending email as your domain
- Whether your SPF and DKIM are passing
- Whether your alignment is correct
- If anyone is spoofing your domain
For details on what's inside these reports and how to read them, see DMARC RUA and RUF Explained and Understanding DMARC Reports.
How to Verify Your Setup
After configuring multiple RUA addresses, verify everything is in place:
- Check your DMARC record to confirm the rua tag has all addresses with correct formatting
- Verify external authorization records for any address on a different domain
- Wait 24-48 hours for the first aggregate reports to arrive
- Confirm both addresses receive reports — if one is missing, the authorization record is likely the issue
If you need to create or update your DMARC record with multiple RUA destinations, DMARC Creator generates properly formatted records. For a deeper dive into DMARC reporting strategy, see the DMARC Reporting Guide.
Monitor Beyond the Reports
Aggregate reports tell you about email that has already been sent. Continuous monitoring of your DNS records catches problems before they affect delivery — like an accidental change to your DMARC record that removes an RUA address or changes your policy.
Never miss a DMARC issue
Monitor your SPF, DKIM, DMARC and MX records daily. Get alerts when something breaks.
Start Monitoring