DMARC Reporting in mxio: Setup, First Data, and What To Do Next

What DMARC Reporting Does

DMARC Reporting shows you who is sending email as your domain and whether those messages are actually authenticated.

Without reporting, DMARC is mostly blind. You can publish p=none, p=quarantine, or p=reject, but you do not have a clear picture of:

• which services are sending as your domain
• which of those services are passing or failing
• whether failures are legitimate configuration problems, forwarding, or spoofing

mxio receives the aggregate reports from mailbox providers, parses the XML, groups the traffic by sender, and turns it into a dashboard you can use.

Before You Start

To set up DMARC Reporting in mxio, you need:

• a paid mxio plan with the DMARC Reporting add-on
• dashboard access so you can add and enable the domain
• DNS access so you can update the DMARC TXT record

DMARC Reporting starts at $15 per month for up to 100,000 emails, with higher-volume tiers available.

The Fast Version

The real setup flow in mxio is:

1. Add the domain to monitoring
2. Enable DMARC Reporting for that domain
3. Copy the mxio reporting address and suggested DMARC record
4. Publish the DMARC change in DNS
5. Wait for the first reports

That is the sequence a new user should follow.

Step 1: Add the Domain

Start in the DMARC Reporting section of the dashboard and add the domain you want to monitor.

This creates the domain inside mxio's monitoring system and starts the DMARC setup flow. At this stage, you have not finished setup yet. You still need to enable reporting for the domain and publish the DNS change.

Step 2: Enable DMARC Reporting

After the domain exists in monitoring, enable DMARC Reporting for that domain in the dashboard.

This is the step that tells mxio to create a dedicated reporting address for the domain and prepare the setup record guidance.

Once enabled, mxio generates a unique reporting address for that exact domain. It looks like this:

rua+abc123@rua.mxdns.io

That address is unique to the domain. You cannot reuse it for another domain.

Step 3: Update Your DMARC Record

After enablement, the dashboard shows the reporting address and a suggested DMARC record.

Your job is to put mxio's address into the rua= tag of the DMARC TXT record for the domain.

If you already have a DMARC record

Add mxio's reporting address to the existing rua= tag.

Example:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com,mailto:rua+abc123@rua.mxdns.io"

If you already send reports to your own mailbox or another service, you can keep both. Separate the addresses with commas inside the rua= value.

If you do not have a DMARC record yet

Start with a simple monitoring record:

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:rua+abc123@rua.mxdns.io"

p=none is the correct place to begin. It gives you visibility without telling receivers to quarantine or reject mail yet.

Step 4: Let mxio Handle the External Authorization

Because mxio's reporting address is on a different domain, mailbox providers need to see that mxio is authorized to receive those reports.

This is the External Domain Verification step, often shortened to EDV.

In mxio, you do not publish that authorization record yourself. mxio handles it automatically after the domain is enabled for DMARC Reporting.

If you inspect DNS later, you may see a TXT record under the _report._dmarc authorization path for your domain. That is expected. It is part of the cross-domain reporting authorization, not another step you need to perform manually.

Step 5: Wait for the First Reports

DMARC aggregate reports are usually sent once per day. Most users should expect first data within 24 to 48 hours after publishing the updated DMARC record.

Some providers take longer. Some low-volume providers may not send reports consistently. That is normal.

What Success Looks Like

A first-time user should see this sequence:

1. The domain appears in the DMARC Reporting dashboard
2. The domain has a unique mxio reporting address
3. The suggested DMARC record includes that address
4. DNS is updated with the new rua= value
5. The dashboard moves from setup or awaiting state to receiving reports

If you have completed step 4 and the dashboard is still waiting, the most common cause is simply that the first daily reports have not arrived yet.

What DMARC Reports Actually Tell You

DMARC aggregate reports answer one question: who is sending email as your domain, and are they aligned well enough to pass DMARC?

Each report is a summary, not a copy of the mail. You see message counts, IPs, policy observations, and authentication results. You do not see message bodies or private content.

That distinction matters. DMARC Reporting is about authentication visibility, not message archiving.

Why Alignment Matters

This is the part that confuses most new users.

SPF and DKIM can both pass while DMARC still fails. That happens when SPF or DKIM authenticated the wrong domain.

Example:

• the visible From: domain is example.com
• SPF passes for sendgrid.net
• DKIM passes for sendgrid.net
• DMARC still fails because neither result aligned with example.com

For DMARC to pass, at least one mechanism must both:

• pass
• align with the visible From: domain

That is why DMARC Reporting is useful. It shows not just whether SPF or DKIM passed, but whether the passing result actually belonged to your domain.

For a deeper explanation, see DMARC Alignment Failure: Why SPF/DKIM Pass But DMARC Fails.

The DMARC Dashboard

Once reports start arriving, the dashboard helps you answer three practical questions:

1. Who is sending as my domain
2. Which senders are healthy and which need work
3. Am I ready to move toward enforcement

Overview

The overview is your domain list. It shows, at a glance:

• the domain
• current policy seen in reports
• reporting status
• DMARC pass rate
• message volume

For a new user, this is the place to confirm that reports are arriving at all.

Sources

The Sources view is the most important part of the dashboard. It tells you which services and IPs are sending as your domain.

Common groups include:

This is where most operational decisions happen.

Timeline

The timeline shows daily or monthly trends in:

• total message volume
• DMARC pass rate
• SPF alignment rate
• DKIM alignment rate

Use it to spot sudden drops, gradual drift, or spikes that do not match normal sending patterns.

Geography

Geography shows where the sending infrastructure is located, not where the human sender was sitting.

That means a message sent by your employee in London through Google Workspace may still show as the United States because Google's mail servers were in the US.

Reports

The Reports tab lists the raw aggregate reports by reporting organization and time period. Use it when you need to confirm that certain providers are sending reports or when you want to download the XML directly.

How To Interpret Common Situations

Authorized sender, failing DMARC

This is the most common real-world issue.

Usually the fix is one of these:

• DKIM is not set up for that service yet
• SPF is passing for the service's domain, not yours
• the service needs a custom return-path or branded bounce domain

Check DKIM first. It is usually the fastest path to alignment for third-party senders.

Unknown or suspicious traffic

Do not assume every unknown sender is an attack, but do investigate it.

Useful signals:

• reverse DNS hostname
• country
• network or ASN
• message volume
• whether the traffic matches a service your team actually uses

Low-volume unknown traffic is often noise or legacy systems. Large unexplained volume is more serious.

Forwarded mail

Forwarding often breaks SPF because the forwarding server is not in your SPF record. That is expected.

If DKIM survives and aligns, DMARC can still pass. This is why forwarded sources should be treated differently from a sender that simply is not configured correctly.

Subdomains

DMARC reporting often reveals subdomains you forgot about or did not know were sending mail.

Examples:

• marketing.example.com
• support.example.com
• notifications.example.com
• dev.example.com

This matters because DMARC policy can affect subdomains too.

How subdomains appear in mxio

Subdomains can show up because:

1. reports referenced them directly
2. mxio discovered related DNS records
3. you added the subdomain to domain management and then enabled dedicated reporting for it

That third case is important. In the current product, the subdomain workflow is not "type any child into a DMARC subdomain box." The user-facing actions are closer to:

• leave the subdomain under the parent's reporting
• add it to domains
• enable dedicated reporting when that path is available

Policy inheritance

Subdomains follow these rules:

1. if the subdomain has its own DMARC record, that record wins
2. otherwise, the parent's sp= policy applies if present
3. otherwise, the parent domain's p= policy applies

That is why subdomain review matters before moving to p=reject.

Grouping Rules

If you have many subdomains, grouping rules let you organize them into named buckets.

Each rule has:

• a pattern
• a label

Rules are matched top to bottom. First match wins.

Pattern examples

Reordering rules

Order matters. In the current dashboard, you reorder rules with the arrow controls, not drag and drop.

Preview

The dashboard shows a preview of how the rules match your current subdomains. For large sets, the preview is a sample of up to 200 subdomains. That makes it good for validation, but not a full audit by itself.

The Enforcement Journey

DMARC Reporting exists so you can move toward enforcement without guessing.

The usual path is:

1. Discovery: learn who sends as your domain
2. Configuration: fix legitimate senders that are failing
3. Readiness: make sure authorized senders are stable
4. Enforcement: move from p=none toward p=quarantine and then p=reject
5. Steady state: monitor for drift, new senders, and policy changes

Do not skip straight to p=reject unless you already know your sender inventory is complete and aligned.

For the step-by-step enforcement process, see DMARC Deployment Guide: From p=none to p=reject.

Ongoing Review Cadence

Once reporting is live, a simple review cadence works well:

Related Articles

• DMARC Deployment Guide: From p=none to p=reject — how to advance safely
• Why Is DMARC Failing? — diagnosing failures
• DMARC Alignment Failure: Why SPF/DKIM Pass But DMARC Fails — understanding alignment
• DMARC p=none: Why You Should Move to Enforcement — why monitoring is only the first step
• No DMARC Record Found — how to start if DMARC is missing