Multi-Domain DMARC Reporting

Most organisations manage more than one domain. Your primary brand domain, regional variants, legacy domains, and product-specific domains all need DMARC — and all generate aggregate reports. This guide explains how to centralise DMARC reporting from multiple domains into a single mailbox, including the DNS authorization records required to make it work.

The problem

Each domain's DMARC record contains a rua= tag that tells receiving mail servers where to send aggregate reports. By default, the rua= destination must be an address at the same domain:

# DMARC record for primary.com
_dmarc.primary.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

This works fine for a single domain. But when you have 10, 20, or 50 domains, you don't want 50 separate mailboxes. You want one central mailbox that collects reports from every domain.

Sending reports to a different domain

You can point any domain's rua= to a mailbox on a different domain:

# DMARC record for secondary.co.uk — reports go to primary.com
_dmarc.secondary.co.uk TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

However, the DMARC specification (RFC 7489) requires the receiving domain to explicitly authorise this. Without authorization, most report generators will silently drop the reports.

The _dmarc-report._dmarc authorization record

To authorise a domain to receive DMARC reports on behalf of another domain, you publish a DNS TXT record in the receiving domain's zone. The record format is:

<sending-domain>._report._dmarc.<receiving-domain> TXT "v=DMARC1"

What this means

• Sending domain — the domain whose DMARC reports you want to redirect (e.g., secondary.co.uk)
• Receiving domain — the domain that hosts the mailbox collecting the reports (e.g., primary.com)
• The record is published in the receiving domain's DNS zone
• The value is simply v=DMARC1 — no other tags are needed

Example

If you want secondary.co.uk to send its DMARC reports to [email protected], you need:

In secondary.co.uk's DNS:

_dmarc.secondary.co.uk TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

In primary.com's DNS:

secondary.co.uk._report._dmarc.primary.com TXT "v=DMARC1"

The second record is the authorization. It tells report generators: "Yes, primary.com is willing to accept DMARC reports on behalf of secondary.co.uk."

Why authorization is required

Without this check, anyone could point their rua= at your mailbox and flood it with reports. The authorization record ensures that the receiving domain has opted in to accepting reports for a specific sending domain.

Wildcard authorization

If you manage many domains and want to accept reports from all of them without creating individual records, some implementations support a wildcard:

*._report._dmarc.primary.com TXT "v=DMARC1"

This authorises any domain to send DMARC reports to primary.com. Use this with caution — it means anyone on the internet can direct their DMARC reports to your mailbox. For most organisations, individual authorization records are safer.

Full worked example: 3 domains, 1 mailbox

Let's walk through a complete setup. You manage three domains:

• primary.com — your main brand, uses Microsoft 365
• secondary.co.uk — your UK regional domain, forwards to primary.com
• brand.io — a product domain, uses SendGrid for transactional email

You want all DMARC reports to arrive at [email protected].

Step 1: Create the receiving mailbox

In Microsoft 365, create a shared mailbox called [email protected]. A shared mailbox is ideal because:

• It doesn't consume an M365 licence
• Multiple admins can access it
• It can be polled by the Graph API for automated processing
• It has a 50 GB mailbox quota (same as a user mailbox)

Step 2: Set DMARC records on all three domains

primary.com (no authorization record needed — reports stay in the same domain):

_dmarc.primary.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

secondary.co.uk:

_dmarc.secondary.co.uk TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

brand.io:

_dmarc.brand.io TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]"

Step 3: Add authorization records in primary.com's DNS

Since secondary.co.uk and brand.io are sending reports to primary.com, you need authorization records in primary.com's DNS zone:

secondary.co.uk._report._dmarc.primary.com TXT "v=DMARC1"
brand.io._report._dmarc.primary.com         TXT "v=DMARC1"

No authorization record is needed for primary.com itself, because the reports are staying within the same domain.

Step 4: Verify DNS propagation

After publishing the records, verify them:

# Check DMARC records
dig TXT _dmarc.primary.com +short
dig TXT _dmarc.secondary.co.uk +short
dig TXT _dmarc.brand.io +short

# Check authorization records
dig TXT secondary.co.uk._report._dmarc.primary.com +short
dig TXT brand.io._report._dmarc.primary.com +short

Each authorization record should return "v=DMARC1".

Step 5: Wait for reports

DMARC aggregate reports are generated by receiving mail servers (Google, Microsoft, Yahoo, etc.) and sent once every 24 hours. After publishing your records, expect to wait 24-48 hours before the first reports arrive. Some large providers may take up to 72 hours.

Microsoft 365 specifics

Shared mailbox behaviour

When DMARC reports arrive in a shared mailbox, the display name shown in Outlook is the sender's identity — typically the report generator (e.g., [email protected] or [email protected]). You cannot customise this per domain. All reports from all domains land in the same inbox, and you'll need to look at the email subject or attachment filename to determine which domain the report covers.

Report filenames follow this convention:

<report-generator>!<reporting-domain>!<date-start>!<date-end>.xml.gz

For example:

google.com!secondary.co.uk!1711843200!1711929600.xml.gz

Graph API integration

For automated processing, use the Microsoft Graph API to poll the shared mailbox:

1. Register an app in Entra ID with Mail.Read application permission for the shared mailbox
2. Use the /users/{mailbox}/messages endpoint to list messages
3. Filter by subject or attachment name to identify DMARC reports
4. Download and decompress the .xml.gz attachments
5. Parse the XML to extract pass/fail statistics per source IP

Sentura automates this entire pipeline — it polls your mailbox, parses the reports, and presents the data in a dashboard with actionable insights.

Licencing

Shared mailboxes in Microsoft 365 do not require a licence as long as the mailbox is under 50 GB. Since DMARC reports are small XML files (typically 1-50 KB each), even an organisation receiving reports for hundreds of domains will stay well under this limit.

Adding a new domain later

When you add a new domain to your portfolio, you need two DNS changes:

1. In the new domain's DNS: Add a DMARC record with rua=mailto:[email protected]
2. In primary.com's DNS: Add an authorization record: newdomain.com._report._dmarc.primary.com TXT "v=DMARC1"

If you forget step 2, reports for the new domain will be silently dropped by most report generators.

Troubleshooting

Reports not arriving

If you've set up the DMARC record and authorization record but reports aren't arriving after 72 hours:

1. Verify the DMARC record is published correctly. Use dig TXT _dmarc.yourdomain.com +short and confirm the rua= tag contains the correct mailto: address.

2. Verify the authorization record exists. Use dig TXT yourdomain.com._report._dmarc.receivingdomain.com +short and confirm it returns "v=DMARC1".

3. Check for typos in the rua address. A missing mailto: prefix is a common mistake. The correct format is rua=mailto:[email protected], not [email protected].

4. Confirm the mailbox exists and can receive mail. Send a test email to the rua address manually. If it bounces, the reports will too.

5. Check your spam/junk folder. Some mail filtering systems may quarantine DMARC reports because they contain XML attachments.

6. Verify the domain actually sends email. If nobody is sending email from a parked or inactive domain, there's no mail to generate reports about. Send a test email from that domain to a Gmail or Outlook address to trigger a report.

Authorization record not working

• Ensure the record is in the receiving domain's DNS zone, not the sending domain's
• Ensure the format is exactly sendingdomain._report._dmarc.receivingdomain TXT "v=DMARC1" — the sending domain comes first in the record name
• Some DNS providers add the zone suffix automatically — make sure you're not creating secondary.co.uk._report._dmarc.primary.com.primary.com
• Allow up to 48 hours for DNS propagation, though most changes are visible within an hour

Wrong rua format

The rua= tag must use the mailto: URI scheme. These are wrong:

[email protected]           # Missing mailto:
rua=mailto:[email protected],   # Trailing comma
rua=mailto:dmarc-reports@primary .com   # Space in domain

The correct format:

rua=mailto:[email protected]

To send reports to multiple addresses, separate them with commas:

rua=mailto:[email protected],mailto:[email protected]

Further reading

• What is DMARC?
• DMARC Enforcement Guide
• Understanding SPF