What to Do With DMARC Aggregate Reports: A Practical Triage Workflow

You have DMARC set up. You are receiving aggregate reports. Here is what to actually do with them.

Most DMARC documentation explains the report format -- the XML schema, the data fields, which providers send them and when. What it does not explain is the workflow between opening a report and knowing what to do next. That gap is what this post fills.

This is a triage guide. It gives you a repeatable process for sorting through DMARC failures, deciding which ones matter, and knowing whether to fix, ignore, or escalate each one. The workflow described here is also what tools like DMARCFlow automate for operators who manage multiple domains and cannot afford to manually review every report from every provider.

What DMARC Failures Mean Operationally

Every DMARC aggregate report describes what happened when a receiver checked your domain's authentication. There are three possible outcomes:

SPF alignment fail means the sending server's IP is not in your SPF record, or the envelope-from domain does not match your From domain. This is the most common failure type. It shows up when a third-party platform sends email on your behalf and you have not added that platform to your SPF record.

DKIM alignment fail means the message was signed with a DKIM key, but the selector domain does not match your From domain. This happens when a platform sends signed email but the signature uses its own domain instead of yours.

Both fail means neither SPF nor DKIM aligned. The message came from a server that is not authorized and was not DKIM-signed with your domain. This is the case most likely to indicate spoofing, though it can also result from misconfigured third-party senders.

The p=fail tag in your policy tells receivers what to do when both checks fail. It does not tell receivers what to do when only one fails. That distinction matters: a single alignment failure is not the same as a full DMARC rejection.

The Triage Priority Order

Not all failures deserve the same attention. Sort them in this order:

Highest priority: legitimate sources failing DMARC. A marketing platform, a CRM, a billing system -- any tool you intentionally use to send email on your behalf that is showing up in your failure data. This is the category where you can actually fix something and see immediate results.

Second priority: new sources you did not authorize. A server that is sending email using your domain that you cannot identify. This may be a misconfigured integration, a former vendor you forgot about, or an early-stage spoofing attempt. You need to identify it before you can decide what to do with it.

Third priority: forwarding-related failures. When a mail server forwards your message, the forwarder becomes the new sender from an SPF perspective. The original SPF check passes, but the forwarder's server is now the one trying to deliver -- and it is not in your SPF record. This is expected behavior and cannot be fixed without changing how the forwarding works.

Lowest priority: internal mail relay failures. If you have internal mail servers that relay messages on behalf of your domain, those servers will fail DMARC by design. This is normal. You do not need to fix it as long as those messages stay internal.

The Three-Step Action Framework

For each failure source you decide to act on, follow these three steps.

Step 1: Identify the sending source. Look at the source IP and envelope-from domain in the report. The envelope-from (RFC 5321 Mail From) tells you which platform initiated the message. The source IP tells you which server actually sent it. If a vendor sends through its own infrastructure, these will differ. If it sends through your infrastructure, the IP will be yours.

Step 2: Check if it is legitimate. Ask: is this a vendor, platform, or integration I authorized? Is this email traffic I want to keep receiving? If the answer is yes, proceed to Step 3. If the answer is no -- if you do not recognize the source and it is not a known vendor -- treat it as a potential security issue.

Step 3: Fix or block. If the source is legitimate and failing because of a missing SPF include or DKIM selector, add the required DNS record. If the source is not in your control (a forwarding chain, an external mailing list), accept that DMARC cannot authenticate through that path without changing how the forwarding works. If the source is unknown and sending volume is high, that is a spoofing indicator worth investigating further.

How to Verify Your Fix Worked

Aggregate reports are not real-time. Most providers send them daily, though some send hourly and some on irregular schedules. Do not assume your fix worked the same day you made it.

Wait for at least one full report cycle before drawing conclusions. If your provider sends daily reports, check tomorrow's or next week's report. If they send weekly, wait for the next delivery.

In the next report, look for the source IP you fixed. Confirm that it is now passing DMARC alignment. If the same IP still appears in failures, the fix did not take -- check the DNS record again, verify the include is correct, and confirm the DKIM selector is pointing to the right key.

One concrete example: if you added include:_spf.example.com to your SPF record and a vendor is still failing after 48 hours, the vendor may be sending from an IP address that is not covered by that include. Ask the vendor for their current sending IP ranges and update the record accordingly.

Common False Positives That Trigger Unnecessary Action

Before you act on any failure, check these first:

Internal mail relays and backend SMTP servers. If your mail infrastructure has servers that move messages between systems without changing the From address, those servers will appear as failures. This is expected. Adding those IPs to your SPF record solves it, but only if those servers are not reachable from the public internet.

Mailing list forwarders. When a subscriber forwards a message to another provider, the forwarding provider becomes the new sender. Their server is not in your SPF record. The message will fail DMARC. This is normal and cannot be fixed without using ARC (Authenticated Received Chain) to preserve the original sender information.

Legacy CRM integrations. Some CRM systems send email on your behalf using their own mail servers even after you have set up custom DKIM. The DKIM signature uses the CRM's domain, not yours, which causes alignment failures. This is a configuration issue on the CRM side -- either they support custom-domain DKIM signing, or you need to list their sending IPs in your SPF record.

Bulk marketing platforms that do not support DMARC alignment. Some platforms send from your domain in the From header but use their own servers for delivery. They pass DKIM but with the platform's domain as the signer. This fails DMARC alignment by design. If the platform does not offer a way to align their DKIM signature with your domain, you cannot fix this without switching to a platform that supports proper DMARC alignment.

When DMARCFlow Helps

The workflow described in this post works well when you have one domain and check your reports manually. It becomes a burden when you manage multiple domains, receive reports from dozens of providers, and need to track new failure sources across all of them.

DMARCFlow automates the monitoring, alerting, and change-detection parts of this workflow. Rather than reviewing each report manually, you get notified when a new sending source appears in your failure data, when an authorized vendor starts failing after a configuration change, or when your own infrastructure starts producing new failures after a migration. The triage process above -- identifying sources, checking legitimacy, deciding what to fix -- runs continuously in the background so you only act when something actually needs your attention.

FAQ

How often do DMARC aggregate reports arrive?
Most major providers send DMARC aggregate reports daily. Google, Microsoft, and Yahoo all send daily reports for domains with p=none or higher policies. Some providers send hourly. Some smaller providers send weekly or on no fixed schedule at all.

How long should I wait before checking if a DMARC fix worked?
Wait for at least one full report cycle. If your provider sends daily, wait 24 to 48 hours. If they send weekly, wait one to two weeks. Checking the same day you made a DNS change will almost always show the old data.

What does p=fail mean in practice -- should I always act on it?
p=fail describes the action a receiver should take when both SPF and DKIM alignment fail. It does not mean every p=fail event is an attack. It means the receiver could not verify the message was authorized by the domain owner. Some percentage of p=fail events will always be legitimate mail from misconfigured authorized senders. Triage first, act second.

My marketing platform is failing DMARC. What do I do?
First, check whether the platform supports custom-domain DKIM signing. If it does, set up DKIM with your domain as the selector. If it does not, add the platform's sending IP ranges to your SPF record. If neither option is available, the platform cannot send authenticated email on your behalf and you need a different platform or a workaround like a custom sending domain that the platform does support.

I see failures from my own internal mail servers. Is that normal?
If those servers relay messages to external recipients without changing the From address, they will fail DMARC. This is normal for internal relays that handle outbound mail for your domain. Add those server IPs to your SPF record. If the servers are only used for internal mail that never leaves your domain, the failures are expected and you can safely ignore them.