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.

ScenarioExampleExtra 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:

  1. Check your DMARC record to confirm the rua tag has all addresses with correct formatting
  2. Verify external authorization records for any address on a different domain
  3. Wait 24-48 hours for the first aggregate reports to arrive
  4. 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