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 multi-domain DMARC reporting works, why sending reports across domains normally requires extra DNS authorization, and how Sentura handles that for you.

The problem

Each domain’s DMARC record contains a rua= tag that tells receiving mail servers where to send aggregate reports. The simplest setup points it at an address on 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 report destinations to create, monitor, and parse. You want every domain’s reports collected and processed in one place — without losing track of which report belongs to which domain.

Sentura customers

This whole problem is already solved for you: each domain you add in Sentura gets its own reporting address — [email protected], shown on your Domains page. Publish it in that domain’s DMARC record and you’re done. Reports are delivered straight to Sentura, separated per domain by design, and the cross-domain DNS authorization described below is managed by Sentura automatically — you never publish it yourself.

How Sentura handles multiple domains

Each domain gets its own dedicated reporting address:

Domain	Reporting address
primary.com	[email protected]
secondary.co.uk	[email protected]
brand.io	[email protected]

Because every domain has its own address, reports arrive pre-separated — there’s no shared inbox to untangle and no parsing of filenames to work out which domain a report covers. The exact address for each of your domains is generated when you add the domain in Sentura and displayed on your Domains page.

Worked example: 3 domains

You manage three domains:

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

The setup for each domain is the same three steps:

Step 1: Add each domain in Sentura. Each one is assigned its own reporting address, shown on the Domains page.

Step 2: Publish each domain’s DMARC record with its own Sentura address:

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

(Use the exact addresses from your Domains page — the ones above are illustrative.)

Step 3: Verify on the Domains page. Sentura checks each domain’s published DMARC record and confirms the rua= is correct.

That’s it. No mailboxes to create, no forwarding rules, no authorization records of your own to publish. There is no step 4.

When do reports arrive?

DMARC aggregate reports are generated by receiving mail servers (Google, Microsoft, Yahoo, and others) and sent roughly once every 24 hours. After publishing your records, expect to wait 24–48 hours before the first reports arrive — some providers may take up to 72 hours. A domain that sends no email generates no reports, so a quiet or parked domain showing no data is normal.

Adding a new domain later

Add the domain in Sentura, publish the DMARC record with the address it’s assigned, and verify on the Domains page. The same three steps every time — the authorization plumbing below is already in place.

Under the hood: cross-domain report authorization

You don’t need any of this section to use Sentura — it’s background on what’s happening beneath the per-domain address, and it’s useful general knowledge if you ever process DMARC reports yourself.

Why authorization is required

Your domains’ reports are being sent to an address at sentura.io — a different domain from the one being reported on. The DMARC specification (RFC 7489) requires the receiving domain to explicitly authorise this. Without authorization, most report generators silently drop the reports.

The rule exists for a good reason: without it, anyone could point their rua= at your mailbox and flood it with reports you never asked for. The authorization record proves the receiving domain has opted in.

The _report._dmarc record

The authorization is a DNS TXT record published in the receiving domain’s zone:

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

• Sending domain — the domain whose DMARC reports are being redirected (e.g., secondary.co.uk)
• Receiving domain — the domain that hosts the report destination (e.g., sentura.io)
• The record lives in the receiving domain’s DNS zone
• The value is simply v=DMARC1 — no other tags are needed

For example, for secondary.co.uk to send its reports to an address at sentura.io, this record must exist in sentura.io’s DNS:

secondary.co.uk._report._dmarc.sentura.io TXT "v=DMARC1"

It tells report generators: “Yes, sentura.io is willing to accept DMARC reports on behalf of secondary.co.uk.”

Who publishes it

Sentura does. The authorization record belongs in the receiving domain’s zone — that’s sentura.io, which Sentura controls. When you add a domain, Sentura ensures the corresponding authorization is in place on the sentura.io side. You publish exactly one record per domain: the DMARC record itself, in your own DNS.

If you were centralising reports yourself — say, collecting reports for all your domains at an address on your primary domain — the same mechanics would apply, but you’d be the one publishing the authorization records, one per sending domain, in your primary domain’s zone:

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

You can verify any authorization record with dig:

dig TXT secondary.co.uk._report._dmarc.sentura.io +short

It should return "v=DMARC1".

Troubleshooting

Reports not arriving

If you’ve published a domain’s DMARC record but no reports have arrived 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 exact address from your Domains page — or just check the Domains page, which verifies this for you.

2. 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].

3. Confirm there’s only one DMARC record. Multiple TXT records at _dmarc.yourdomain.com are invalid — receivers ignore all of them. Keep exactly one.

4. 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.

5. Give it time. Report generators batch and send roughly daily; 24–48 hours of silence after publishing is normal.

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+yourdomain@sentura .io   # Space in domain

The correct format:

rua=mailto:[email protected]

To send reports to multiple destinations — for example, Sentura plus an internal archive — separate the addresses with commas:

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

Further reading

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