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 DMARC Reporting access
• dashboard access so you can add and enable the domain
• DNS access so you can update the DMARC TXT record

DMARC Reporting is included in DMARC Starter ($19/mo, 2 domains, 100k volume), Core ($34/mo, 5 domains, 100k volume), Pro ($59/mo, 25 domains, 150k included), and Business ($129/mo, 50 domains, 500k included).

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.

Sources are grouped into five buckets:

This is where most operational decisions happen.

Authorized Senders engine

mxio identifies sending infrastructure automatically using reverse DNS, ASN data, and a database of known ESPs and mail providers.

When a source IP maps to a recognized provider — Google Workspace, Microsoft 365, Mailchimp, SendGrid, Postmark, HubSpot, Amazon SES, and others — the provider name and logo appear alongside the IP in the Sources view. You know immediately which service is responsible for that traffic without manually looking up the IP.

The engine also surfaces missing configuration: if mxio recognizes the ESP but the DKIM selector or SPF alignment is incomplete, the source is classified as Misconfigured rather than Unknown. That distinction matters — it means you have a fixable configuration gap, not an unrecognized sender.

For sources the engine cannot identify, you can classify them manually: mark a source as authorized (it is yours), denied (it is not), or flag it for follow-up.

Renaming sources for your account

Any source row in the sources tab or discovery card in the advisor panel that has a recognized ESP identity shows a Rename button. Click it to set a display name and category that only apply to your account.

Renaming is display-only. It does not change alignment math, traffic counts, authorization status, or which bucket the source lands in. It just makes the row read the way you think — "Marketing team's Mailchimp" instead of "Mailchimp," or "HR onboarding mailer" instead of "SendGrid."

Renamed sources show a small Local label badge next to the display name. Hover it to see: "You named this sender. mxio has not verified it." The badge keeps the distinction between your labels and mxio-verified identifications visible at all times.

If the source you rename is already an authorized sender, the modal shows a disclosure: the authorized status is separate and unchanged. Your label controls how the row is displayed; the authorization controls how DMARC policy treats it. They do not interfere with each other.

Sources that show up as "Unknown senders" cannot be renamed individually. Our daily report groups every unmatched sender on a domain into a single bucket, so naming one would relabel them all. We are widening that grouping in a follow-up so you can name unfamiliar senders too.

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.

Anomaly cards and AI explain

When the dashboard detects an unusual traffic pattern — a sudden volume spike from an unknown source, a sharp drop in your pass rate, a new IP sending high volume before it has been classified — it surfaces an anomaly card in the overview.

Each anomaly card has an AI explain button. It gives a plain-language summary of what the pattern likely represents, what data the analysis is based on, and what to investigate next. This is not a replacement for your own judgment, but it cuts the initial diagnosis time when something unexpected appears.

New-sender notifications

mxio watches for high-volume unrecognized senders as reports arrive. When a source exceeds 1,000 emails in a 7-day window and is not in your authorized sender list and is not a known forwarder, you receive an email alert.

The alert includes:

• the source IP address
• reverse DNS hostname (if available)
• total email count over the detection window
• date the source was first seen

Alerts are suppressed per domain for 7 days after each notification to avoid repeated alerts for the same source.

To receive these alerts, enable the Unrecognized sender event type in the DMARC Reporting notification group in notification settings.

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.

Enforcement readiness assessment

The Enforcement advisor panel in the dashboard tracks your progress through this journey. It continuously evaluates your report data against a set of readiness criteria:

• Authorized sender coverage — what percentage of your total sending volume comes from sources you have classified as authorized
• Alignment rate — of your authorized senders, what percentage are passing DMARC alignment
• Unknown volume — whether you have significant unclassified traffic that would be affected by tightening policy
• Open misconfiguration issues — authorized senders that are not yet aligned

The advisor tells you when you meet the threshold to move to the next policy level, and it shows you specifically what is blocking you if you do not. When you are ready to move from p=none to p=quarantine, or from p=quarantine to p=reject, the advisor surfaces the exact record change to make.

This replaces the manual process of reading XML reports, counting passing IPs, and doing the arithmetic yourself.

For the full step-by-step enforcement process and policy record syntax, see DMARC Deployment Guide: From p=none to p=reject. For the enforcement decision in isolation — what "ready" looks like at each stage, how long to wait, and when not to move — see Moving 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
• Understanding DMARC Aggregate Reports — what the XML contains and how to read it
• Moving from p=none to p=reject — the enforcement decision, step by step
• 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