You published a DMARC record, waited a day, and now the reports are rolling in. Congratulations. You now have more data about your email than you’ve ever had, and very little idea what to do with it.

That’s normal. Your first DMARC report is mostly a list of IP addresses, message counts, and pass/fail results. Nothing in it says “fix this one first.” So here’s the order I’d go through it in, from “is this even working?” to “is someone spoofing us?”

One rule before you start: don’t change your DMARC policy based on your first report. One day of data is a snapshot. Some senders only run weekly or monthly (payroll, invoicing, newsletters), so give it at least a couple of weeks before you draw conclusions.

1. Check who’s reporting

Start with the basics: are reports arriving, and from whom? Each aggregate report includes the organization that sent it in its <report_metadata> block:

<report_metadata>
  <org_name>google.com</org_name>
  <email>[email protected]</email>
  <date_range>
    <begin>1791158400</begin>
    <end>1791244799</end>
  </date_range>
</report_metadata>

For most organizations the first reports come from Google, Microsoft (Outlook.com), and Yahoo, because that’s where a lot of mail goes. Google says its reports are usually sent once a day. If you’re seeing reports from those big receivers, your rua= record is working.

If you see nothing after 48 hours, check that your _dmarc record is published and spelled correctly before you go any further. Our MonitorDMARC setup guide has a troubleshooting checklist that applies to any reporting setup.

2. Look at your overall pass rate

Next, add up the message counts. How many messages claimed to be from your domain, and how many passed DMARC?

A message passes DMARC if either SPF or DKIM passes and is aligned with the domain in the From: header. That’s the part most people miss the first time. In each record, look at <policy_evaluated>:

<policy_evaluated>
  <disposition>none</disposition>
  <dkim>pass</dkim>
  <spf>fail</spf>
</policy_evaluated>

This one passes DMARC. DKIM passed with alignment, so SPF failing doesn’t matter.

Don’t panic if your pass rate is lower than you expected. That’s what you’re here to find out. The number to track is the trend over the next few weeks as you fix things.

3. Confirm your own mail platform passes

Your primary platform, Microsoft 365 or Google Workspace, should be the largest source of mail in the report, and it should be passing. If it isn’t, fix that first, because it’s most of your volume.

The most common culprit on Microsoft 365 is DKIM that was never turned on for the custom domain. Microsoft signs outbound mail with your onmicrosoft.com domain by default, and Microsoft’s own documentation notes that DKIM only passes DMARC when the signing domain aligns with the From: domain. In the report it looks like this: DKIM result pass in <auth_results>, but for contoso.onmicrosoft.com instead of contoso.com, and <dkim>fail</dkim> under <policy_evaluated>.

The fix is to enable DKIM for your custom domain in the Defender portal and publish the two selector1 and selector2 CNAME records Microsoft gives you.

For Google Workspace, check that DKIM is set up in the Admin console (the default selector is google) and that the TXT record is published.

4. Find the legitimate senders that are failing

This is where most of the real work is. Look for sources with meaningful volume that are failing DMARC, and figure out what they are. Usually it’s a SaaS vendor sending on your behalf: a CRM, a marketing platform, a helpdesk, an invoicing tool.

The pattern almost always looks like this:

<auth_results>
  <spf>
    <domain>bounce.some-vendor.com</domain>
    <result>pass</result>
  </spf>
</auth_results>

SPF passed, but for the vendor’s bounce domain, not yours. So it isn’t aligned, and it doesn’t count for DMARC. Adding the vendor to your SPF record won’t fix this. The fix is to set up DKIM in the vendor’s admin panel so mail is signed with your domain, or configure a custom return-path domain if the vendor supports it.

Reverse DNS on the source IP is the quickest way to identify a vendor:

dig +short -x 203.0.113.25

If you want a deeper process for this, our post on finding every service sending email as your domain walks through building a full sender inventory.

5. Recognize forwarding before you chase it

You’ll probably see a scatter of small-volume sources with SPF failing but DKIM passing, from IPs belonging to other companies’ mail servers or mailing list services. That’s usually forwarding: someone who received your message has it auto-forwarded to another mailbox, or it went through a mailing list.

SPF breaks on forwarding, because the forwarding server’s IP isn’t in your SPF record. DKIM usually survives as long as the message isn’t modified along the way. If those records show DKIM passing and aligned, they’re passing DMARC, and you can move on. Mailing lists that modify messages (adding footers or subject tags) can break DKIM too. Those are worth noting, but they’re rarely your biggest problem.

6. Then look at what’s left: unknown senders

After you’ve accounted for your platform, your vendors, and forwarding, what’s left is the interesting part. These are sources nobody recognizes that fail both SPF and DKIM.

Some will be harmless, like an old server or a scanner nobody told you about. Some may be someone spoofing your domain. Warning signs include bursts of volume from IPs in countries you don’t do business in, IPs on hosting providers you don’t use, and senders that show up suddenly and disappear. Our guide on detecting domain spoofing covers how to investigate.

While you’re at p=none, spoofed mail still gets delivered. That’s the reason to work through this list and eventually move to enforcement.

7. Write down your baseline

Before you change anything, record where you’re starting:

  • Total message volume per day
  • DMARC pass rate
  • Number of distinct sending sources
  • A list of failing sources and who owns each one

Two weeks from now you’ll want to compare. When the pass rate is high and every remaining failure is either forwarding or something you’re happy to block, you’re ready for the DMARC enforcement journey.

Doing this without reading XML

All of the above works with raw XML and some patience. If you want the walk-through of every field, see How to Read DMARC Reports (Without Losing Your Mind). Doing it every day, for weeks, is where most people give up.

MonitorDMARC does the parsing for you. It breaks down pass and fail results by domain, sending source, country, and IP address, and it emails you when a new failing source appears or your pass rate drops, so you only need to look when something changes. It’s a 14-day free trial with no credit card, and plans start at $19.99/month for two domains with a year of report history.

References