What to Do When DMARC Monitoring Finds Failures

You have DMARC monitoring running. Your aggregate reports show failures. Before you assume someone is spoofing your domain, work through this triage.

Most DMARC guides focus on the setup phase. This article is for the operational phase that comes after: you are staring at failure data and you do not know what it means or what to do next. The short answer is that many DMARC failures come from your own infrastructure, not from spoofing, and most of those are fixable. Here is the framework practitioners use to sort real threats from noise.

Start Here: Is It Actually Spoofing?

The first question is always whether the failures represent actual spoofing or legitimate mail that is failing DMARC for a structural reason. The distinction matters because spoofing is a threat, while infrastructure failures are an operational problem you can solve.

Spoofing indicators:

• Source IP is not in your SPF record


• Source IP does not belong to any known sending system


• Failure volume spikes suddenly without a corresponding increase in your own sending


• No mail from this source appears in your sent folder or logs

Legitimate failure indicators:

• Source IP is in your SPF record


• The sender is a known vendor or internal system


• Failures are consistent and moderate over time, not sudden spikes


• Mail from this source was sent but was delayed, rejected, or redirected

A DMARC failure from an internal mail relay that is not in your SPF record is not spoofing. It is a misconfigured internal system. Fix the relay, not the DMARC record.

The Five Most Common Non-Spoofing Failure Causes

These five causes account for the majority of DMARC failures seen in aggregate reports that are not from spoofing:

1. Third-party email senders that do not use your domain correctly

Marketing automation platforms, CRM systems, support desk tools, and billing platforms often send mail from their own infrastructure but with your domain in the From address. Their servers are not in your SPF record, and they do not sign their mail with your DKIM key. DMARC alignment fails because the From domain and the auth results do not match.

The fix depends on what the vendor supports. Many major platforms let you configure custom domain sending with proper DKIM signing. Some only offer shared-domain sending, which cannot pass DMARC alignment no matter how you configure your DNS. In that case, the fix is either switching to a vendor that supports proper alignment or adding their sending IPs to your SPF record if they send on your behalf.

2. Mailing list and forwarding services that rewrite the From header

When a mailing list server forwards your message, it typically rewrites the From address to show the list address instead of your original sender. This breaks DKIM alignment because the DKIM signature was applied to your original From header, not the list's rewritten version. SPF alignment also fails because the envelope-from at the time of forwarding may differ from your original sending domain.

Some modern forwarding services use ARC (Authenticated Received Chain) headers to preserve the original authentication results through the forwarding chain. Receiving servers can check ARC to see that the mail was originally authenticated for your domain. ARC is not a universal solution, but it is becoming more common and is worth checking before assuming forwarding will always break DMARC.

3. Legacy internal mail relays

Internal systems that send notifications, alerts, or bulk mail often do so from internal IP addresses using your domain in the From address. Those internal IPs are not in your SPF record. The moment those systems send enough mail to appear in DMARC aggregate reports, they show as alignment failures.

The fix: add those IPs to your SPF record if they are fixed and known, or reconfigure those systems to relay through your primary mail server so SPF and DKIM are applied correctly at the boundary.

4. Recently migrated email platforms

When you move to a new email platform, DNS changes take time to propagate. Your DKIM selector record may not yet be published at the time of the first test sends. DKIM signatures may fail because the receiving server cannot find the public key for the selector being used. This is a temporary issue that resolves itself as DNS propagates, but it can persist for 24-48 hours or longer if TTL values are high.

The fix: verify your DKIM selector record is published and returning the expected public key before sending mail from the new platform. Use a DKIM checker to confirm the record is live before drawing conclusions from aggregate reports during a migration window.

5. Subdomains sending mail without their own alignment

Transactional mail, notification systems, and marketing platforms often send from subdomains like marketing.yourdomain.com or no-reply.yourdomain.com. If those subdomains have their own SPF and DKIM but your DMARC policy covers the parent domain, alignment fails because the From domain (the subdomain) does not match the organizational domain in the DMARC check.

The fix: either add those subdomains to your DMARC record with a separate policy, or ensure those systems send in a way that passes alignment for their own subdomain. Do not leave subdomain sending unaddressed just because the main domain policy is p=none.

DMARC Failure Triage Workflow

Use this numbered sequence every time you open an aggregate report:

1. Identify the source IP from the failure record. Note which sending domain and DKIM selector were used.
2. Check whether that IP appears in your SPF record. If yes, SPF alignment can pass. If no, note it as a potential untracked sender.
3. Check whether the DKIM selector used matches your published DKIM record for that domain. If the selector is not found or returns no key, the DKIM signature cannot verify.
4. Determine whether the sender is a known third-party platform. Check with your internal teams or vendors before assuming spoofing.
5. Check for evidence of forwarding: look for ARC headers in related messages or a mismatch between the envelope-from and the From header.
6. If the IP is unknown, the volume is high, and no legitimate explanation exists, treat it as potential spoofing and investigate further before adjusting your DMARC policy.

When to Update Your SPF or DKIM Configuration

DMARC failures that point to your own DNS records rather than a vendor problem are usually resolved by updating your SPF record or your DKIM configuration.

Update your SPF record when:

• A new sending system has a fixed IP range that legitimately sends on your behalf. Add it with an include or IP reference. Watch your total DNS lookups: SPF has a 10-lookup limit, and every include counts.


• An internal relay or system was sending untracked and needs to be brought into your infrastructure.

Update your DKIM configuration when:

• A new platform is sending custom-domain mail but the DKIM key is not yet published. Wait for DNS propagation before treating persistent DKIM failures as a configuration error.


• A DKIM selector was changed or rotated and old selectors are still in use by some sending systems.

Do not add every problematic vendor to your SPF record. If a vendor sends custom-domain mail without proper DKIM alignment, adding them to your SPF does not fix the alignment problem. Their mail will still fail DMARC because alignment requires the From domain to match the auth results. In that case, the fix is on the vendor side.

When to Tighten Your DMARC Policy

Moving from p=none to p=quarantine or p=reject is safe only when you have accounted for every significant failure source in your aggregate reports. A failure source is significant if it represents more than 1% of your total sending volume or if it corresponds to an important communication channel.

You are ready to move to p=quarantine when:

• Your baseline failure rate is stable and below 5%


• Every legitimate sending source has been identified and is passing DMARC


• At least four weeks of aggregate data have been reviewed without new unexplained failure sources appearing

Hold your policy at p=none if you cannot account for all significant sources, if your failure rate fluctuates, or if you recently changed your email infrastructure.

How DMARC Monitoring Tools Help

DMARC aggregate reports arrive as gzipped XML files. Parsing them manually works for a few domains and a low volume of failures. It stops working once you have multiple brands, several sending platforms, and regular changes to your infrastructure.

This is where automated tools change the workflow. DMARCFlow parses the XML reports automatically, groups failures by source IP, and alerts you when a previously passing source starts failing or when a new sending pattern appears. Instead of reviewing raw XML and building the triage picture manually every time, you receive a grouped view that tells you which sources are new, which have changed behavior, and which have become reliable. The triage workflow above still applies, but you apply it to data that is already organized rather than data you have to organize first.

The practical benefit for most teams is that automated monitoring turns the triage workflow into something you actually run instead of something you intend to run when you find the time.

FAQ

How do I tell spoofing from legitimate failures in my DMARC report?

Look at the source IP first. If it is in your SPF record, it is a known sender. If it is not, look at volume and pattern: sudden high-volume failures from unknown IPs are more likely spoofing. Consistent moderate failures from known IPs are more likely an infrastructure alignment problem.

Why do forwarded emails fail DMARC even when SPF and DKIM pass?

Forwarding often rewrites the From header or changes the envelope-from, which breaks DKIM alignment even if the original SPF check passed. This is normal behavior for most forwarding services and is not a misconfiguration on your end. ARC headers can help receiving servers verify original auth results through forwarding chains.

How often should I check DMARC reports?

Weekly is sufficient for most organizations. During a migration or after adding a new sending platform, check reports daily for the first two weeks to catch alignment problems early. Do not let reports sit unread for months: new failure sources can appear silently and affect your sending reputation.

My DMARC failures come from my own IP addresses. What does that mean?

It means something sending from your infrastructure is not covered by your SPF record or is using a DKIM selector that is not configured correctly. Internal mail relays, legacy notification systems, and IoT devices are common culprits. Add those IPs to your SPF record or reconfigure those systems to send through your primary mail server.

When should I move from p=none to p=quarantine?

Move to p=quarantine after you have resolved all known legitimate sending sources and reviewed at least four weeks of aggregate data. Your failure rate should be stable and below 5%. If you cannot account for all significant failure sources, stay at p=none until you can.

Do I need a paid tool to monitor DMARC reports?

You can read DMARC reports manually by unzipping the XML files and looking up individual IPs, but it does not scale. Paid tools like DMARCFlow aggregate and parse reports automatically, surface anomalies, and send alerts when something in your DMARC data requires attention.