DMARC Aggregate Reports: A Practical Triage Workflow

You have DMARC set up. You are receiving aggregate reports. You have no idea what to do with them.

This is the most common gap in email authentication deployment. The standards are well documented. The report format is defined in RFC 7489. What is rarely explained is the operational workflow: what to look for, what to act on, and what to ignore.

This guide gives you that workflow.

What DMARC Failures Mean Operationally

Before the triage steps, you need to know what you are actually looking at.

A DMARC aggregate report groups authentication results by sending domain and sending source. Each failure record tells you one of three things:

SPF alignment failure -- the senders IP is not authorized by your SPF record. The envelope-from domain matched your DMARC policy domain, but the SMTP envelope-from domains SPF record did not authorize that IP. This means an unauthorized server tried to send as your domain.

DKIM alignment failure -- the message was signed, but the signature did not cover the domain that matches your DMARC policy. The sending server might be legitimate but is signing with the wrong domain. This is common with third-party email platforms that send on your behalf but sign with their own domain.

Both SPF and DKIM alignment failure -- neither authentication mechanism passed. This is the most serious. It means the message has no valid authentication at all and is almost certainly unauthorized.

The severity is not uniform. A failure from an authorized vendors server that has not been included in your SPF record is a configuration problem, not an attack. A failure from an IP you have never seen, sending at unusual volumes, is a different situation.

The Triage Priority Order

Not all failures deserve the same attention. Use this order:

Highest priority: new sources that pass neither SPF nor DKIM

These are the failures that require immediate investigation. If a source is failing both checks and you did not authorize it, it could be spoofing your domain. Look at the source IP, the volume, and the time pattern. A single low-volume failure from a new source may be a forwarding case. High-volume failures from an IP you do not recognize are a different matter.

This is also where DMARCFlow provides the most direct value. Tracking which failure sources are new -- versus ones you have already reviewed and accepted -- is repetitive manual work. A monitoring tool that alerts you specifically to new sources, rather than showing you the full report every time, turns this from a tedious daily review into an event-driven response.

Second priority: known sources failing either SPF or DKIM but not both

A vendor or platform you work with is sending on your behalf but is not fully authenticated. This is a configuration problem you can usually fix. The most common cause is a marketing platform, CRM, or support tool that sends from your domain but uses its own DKIM signing infrastructure without proper alignment.

Lowest priority: failures that appear consistently from your own infrastructure

Internal mail servers, mail transfer agents on development environments, or systems that relay mail without proper SPF inclusion will always fail DMARC. These are known failures. They do not need fixing in the DMARC sense -- they need either adding to your SPF record or accepting as legitimate unauthenticated internal traffic that will never pass DMARC.

The reason for this priority order: your time is limited. Spamming yourself over known false positives is noise. Missing a new spoofing source because you were looking at forwarding failures is the actual risk.

The Three-Step Action Framework

For each failure category you decide needs action, follow this:

Step 1: Identify the sending source

Use the source IP and the envelope-from address in the report. The envelope-from tells you which domain the sender claimed to be sending from. The source IP tells you where it actually came from. Cross-reference the IP against your SPF record -- is it listed as an authorized sender? Is it a vendor you recognize?

If the source IP belongs to a major cloud provider (AWS, Azure, Google Cloud) but you do not run any EC2 or VM instances there, that is a different risk profile than a source IP belonging to your known CRM platform.

Step 2: Check if it is legitimate

Ask the basic question: did you authorize this source to send as your domain?

Authorized sources include internal mail servers, third-party platforms you have set up with proper DKIM alignment, and any ESP that sends transactional email for your domain. Unauthorized sources include spoofing attempts, compromised internal systems you were not aware of, and shadow IT -- departments that set up their own email tools without telling you.

If you do not recognize the source and it is sending at volume, treat it as unauthorized until proven otherwise.

Step 3: Fix or block

For authorized sources with configuration problems: fix the SPF record or DKIM alignment. For third-party platforms, check whether they support DKIM signing with your domain rather than theirs. Most major platforms do -- they just need to be configured correctly.

For unauthorized sources: this is where your DMARC policy matters. If you have p=quarantine, failing messages go to spam. If you have p=reject, they are dropped. p=none means you are in monitoring mode and the mail delivers regardless.

If you are seeing unauthorized spoofing at volume and you are still at p=none, moving to p=quarantine is a reasonable escalation. Move to p=reject only after you have confirmed that all legitimate sources are properly authenticated, or you are willing to risk losing some legitimate mail during the transition.

How to Verify Your Fix Worked

DMARC aggregate reports are not real-time. Depending on how often your receivers send them, you may get reports daily, every few hours, or in some cases weekly. Do not check your report five minutes after making a change and conclude the fix did not work.

Wait for at least one full report cycle. If reports come daily, wait two days. If they come weekly, wait two weeks.

When the next report arrives, look for the same source IP or envelope-from domain that was failing. If it is still present, the fix did not apply or the change was not sufficient. If it is gone, check that the new authorized source is now passing -- sometimes you fix one problem and create another by adding a new authorized sender that is also misconfigured.

The feedback loop for DMARC is slow by design. This is why ongoing monitoring matters more than one-time checks. With DMARCFlow, you can set specific source fingerprints to watch -- so the next report automatically tells you whether the source you fixed is now passing, without manually comparing two reports side by side.

Common False Positives That Trigger Unnecessary Action

Some DMARC failures will never go away no matter what you do. Recognizing them saves you from wasting time:

Mailing list forwarders -- when a subscriber forwards a mailing list message to a Gmail or Yahoo recipient, the forwarding MTA changes the envelope-from but keeps the original From header. The forwarded message will fail SPF because the forwarding MTA is not in your SPF record. This is a known forwarding artifact. You cannot fix it without changing how the mailing list handles forwarded mail, which is almost never under your control.

Internal mail relays -- any internal mail relay or SMTP relay that sits between your mail server and the internet will appear as a source in DMARC reports. If these relays do not have valid SPF or DKIM, they will always fail. The right fix is not to block them -- it is to accept that internal mail relay traffic will always generate failures and to exclude it from your triaging attention.

Legacy marketing platforms -- some older ESP configurations send from your domain but sign with their own DKIM key. If they do not support DKIM alignment with your domain, the failure is structural. You can either accept the failure and set a policy that tolerates it, or you retire the platform.

None of these require emergency action. They require configuration decisions and documentation of your accepted risk.

When DMARCFlow Helps

The workflow above requires checking reports regularly -- not just when something breaks. DMARC aggregate reports are only useful if someone looks at them.

DMARCFlow automates the monitoring and alerting. It tracks changes in your failure patterns over time, flags new sources automatically, and alerts you when a new failure source appears that you did not previously see. This turns DMARC from a periodic manual review into an operational process.

You still need to do the triaging. DMARCFlow makes sure you notice when there is something new to triage.

FAQ

How often do DMARC aggregate reports arrive?

There is no standard. Gmail, Yahoo, and most major receivers send them at their own schedules -- typically daily or after a certain volume threshold is reached. Some receivers send hourly. You may receive multiple reports per day or one per week depending on your volume and receiver mix.

How long should I wait before checking if a DMARC fix worked?

Wait for at least one full report cycle. If reports arrive daily, wait two days. If they arrive weekly, wait two weeks. DMARC reports are not real-time. Checking immediately after a change will give you stale data.

What does p=fail mean in practice -- should I always act on it?

p=fail in a report record means the message failed DMARC alignment. Whether you should act depends on the source. If it is a known authorized sender with a configuration problem, yes -- fix the SPF or DKIM setup. If it is an unauthorized source you do not recognize, investigate. If it is a known forwarding or mailing list case, no action is needed on your part.

My marketing platform is failing DMARC. What do I do?

Most major marketing platforms support DKIM signing with your custom domain. Check the platforms documentation for DKIM setup with your domain. If the platform signs with its own domain rather than yours, that is a DKIM alignment failure and is structural -- you need the platform to sign with your domain, not theirs. If they do not support that, you have a configuration decision to make about using that platform.

I see failures from my own internal mail servers. Is that normal?

If the failing servers are internal mail relays, MTA relays, or development environment servers that do not have public DNS records, the failures are expected. Internal traffic often does not pass DMARC because it never goes through the public internet path where SPF and DKIM checks apply. Document these as known sources and do not treat them as security incidents.