What to Do When DMARC Monitoring Shows Failures at p=none

If you set up DMARC at p=none and are now staring at failure reports you do not understand, you are in exactly the right place. p=none is the monitoring phase. It deliberately takes no action on failing mail, which means you get data instead of chaos. That data is only useful if you know what to do with it.

This guide walks you through interpreting those failure reports, deciding which failures are your problem versus an external spoofing attack, and building a practical 30-60-90 day action plan. If you want a tool that tracks these failures automatically and alerts you when something new appears, DMARCFlow handles that layer so you can focus on fixing problems instead of finding them.

Why p=none Gives You Reports Instead of Blocking Mail

p=none is the DMARC policy that says "do nothing to mail that fails alignment, but tell me about it." It is an observe-and-learn setting. The receiver processes the mail normally, delivers it, and sends you an aggregate report summarizing what it saw.

The purpose of this phase is not to protect your domain. It is to let you understand what your email ecosystem actually looks like before you enforce a policy. You might have 15 legitimate sending sources you did not know about. You might have forwarding chains that break alignment. You might have an attacker spoofing your domain right now. p=none tells you all of that.

Without understanding your ecosystem first, moving to a stricter policy is guesswork. Most organizations that skip the monitoring phase and go straight to p=reject end up scrambling to fix legitimate mail that suddenly stops being delivered.

What Your DMARC Failure Report Is Telling You

A DMARC aggregate report arrives daily from each receiver that processes mail from your domain. It is an XML file that summarizes authentication results in batches. Here is what matters in that file:

• Source IP - the IP address that sent the failing mail
• SPF result - pass or fail for that IP
• DKIM result - pass or fail for that domain
• Alignment result - did the From domain align with SPF or DKIM
• Count - how many messages from this source had this result

A failure in the alignment field means the sending server was authorized (SPF passed) or had a valid signature (DKIM passed), but the domain in the From header did not match. This is where most legitimate failures hide.

The challenge with these reports is volume. A single report from a large receiver like Gmail can contain thousands of entries. A tool that normalizes and categorizes these failures over time is far more useful than reading raw XML batches.

A Simple Decision Tree for Triaging Failures

When you open a failure report, ask three questions in order:

1. Is the failing source one of your own mail servers?

Check the source IP against your known sending infrastructure. If it is your own mail server and it is failing, your SPF record may be incomplete, or your DKIM signing may not be aligned with your From domain.

If this is the source of the failure, it is a legitimate failure you need to fix. Add the IP to your SPF record or check your DKIM selector configuration.

2. Is the failing source a third-party service you use?

Marketing automation platforms, CRM systems, legacy SaaS tools, and internal apps often send email on your behalf from IPs you do not control. If the failing source is a service you recognize, the issue is usually that they are not DKIM signing with your domain, or their sending IPs are not in your SPF record.

For third-party senders, the fix is either a DKIM key they control and sign with your domain, or an SPF record that includes their sending IPs. If neither is possible, you route their mail through your own SMTP infrastructure.

3. Is the failing source unfamiliar and potentially spoofing your domain?

If the source IP is not yours and not a service you pay, you are likely looking at someone sending mail that pretends to be from your domain. This is spoofing, and p=none means no action is taken against it yet.

In this case, your action is to document the evidence and move toward enforcement faster. The failure report is your early warning system.

Common Legitimate Failures and How to Fix Them

Some failures repeat across nearly every organization at the p=none stage.

Email forwarding breaking alignment

When a recipient server forwards your message to another inbox, the forwarding server becomes the new sender from the receiver's perspective. SPF passes on the forwarding server's IP, not yours. DKIM may still pass if the original message had a valid signature. But alignment fails because the From domain and the envelope sender no longer match.

For example: you send an invoice from billing@example.com to a client who has their email forwarded to a personal Gmail account. Google's servers see the forwarding server's IP as the sender. If that IP is not in example.com's SPF record, it fails SPF. If the forwarding service does not preserve DKIM signatures, it fails DKIM too.

The fix depends on whether you control the forwarding setup. If it is a corporate email routing rule, you may be able to use ARC headers to preserve the original sender information. If it is individual human forwarding, there is no server-side fix.

Third-party marketing platforms not sending on your behalf

Services like marketing automation tools, event platforms, and billing systems often send from their own infrastructure using your domain in the From address. If they are not DKIM signing with your domain, every message looks like a failure to receivers.

The solution is to configure the third party to send with your DKIM key, or to route their mail through your own SMTP infrastructure so your servers do the sending. Many platforms support custom DKIM signing. Some do not, and for those, your only option is routing through your own infrastructure.

SPF soft failures from shared hosting

Shared hosting environments sometimes send mail from IP addresses that are not obviously yours. If your SPF record uses the ~all (softfail) qualifier, these failures may appear as soft failures rather than hard failures. If you are using -all (hardfail), legitimate mail may be rejected.

Review your SPF record and the actual IPs generating soft failures. You may need to include additional IP ranges or mechanisms.

When a Failure Means Someone Is Spoofing Your Domain

Spoofing failures have a specific pattern: the source IP is not yours, it is not a known service, and the From domain is yours. If you see this pattern and you did not send the mail, you have evidence of someone else using your domain.

At p=none, the receiver still delivers that spoofed mail. Your only action is to document the evidence and move toward enforcement faster. A p=quarantine policy tells receivers to treat suspicious mail from your domain as potentially unwanted. A p=reject policy tells them to block it outright.

The speed at which you escalate depends on how much legitimate mail you are sending through the same ecosystem. If spoofing is heavy, you may want to move quickly. If your legitimate sending is complex and not yet fully documented, you may need more time at p=none to avoid false positives.

Your 30-60-90 Day Action Plan at p=none

Use the p=none phase to build a complete picture of your email ecosystem before you enforce anything.

Days 1-30: Document everything

• Collect every failure report for 30 days
• Build a list of every IP address that sends mail from your domain
• Identify which failures are your own infrastructure problems versus external spoofing
• Fix the easy ones first: add missing IPs to SPF, correct DKIM selectors
• DMARCFlow automates the collection and normalization of these reports so you are not manually reading XML for 30 days straight

Days 31-60: Engage third parties

• Contact every third-party sender that is generating failures
• Get their DKIM keys or sending IPs added to your authentication record
• Remove any services you no longer use that are still sending mail from your domain
• Monitor whether your own infrastructure failures are decreasing

Days 61-90: Plan enforcement

• If your failure rate from legitimate sources has dropped to near zero, you are ready for p=quarantine
• If you still have multiple third-party senders that cannot authenticate, resolve those first
• Set a target date for moving to p=reject based on your risk tolerance and email ecosystem complexity

When and How to Move from p=none to p=quarantine

Moving to p=quarantine is a deliberate escalation. The signal you are looking for is this: you have fixed or eliminated all legitimate failures you can identify, and the remaining failures are either spoofing attempts or services you have decided to decommission.

The practical steps:

1. Change your DMARC record from p=none to p=quarantine 2. Monitor daily for the first week 3. Watch for any new legitimate sources that start sending and failing 4. If legitimate mail starts landing in spam folders, you have found something you missed - move back to p=none and investigate

p=quarantine does not block mail. It tells receivers to treat failing mail as suspicious, which usually means routing it to the spam folder. This is a safer intermediate step than going straight to p=reject.

How DMARCFlow Helps You Interpret Failure Reports at p=none

Reading DMARC aggregate reports by hand is time-consuming and error-prone. The files are XML, the volume can be high, and the same failure sources appear across many reports without an easy way to see patterns over time.

DMARCFlow imports your aggregate reports automatically, normalizes the data, and shows you which sources are failing, how often, and whether that rate is changing over weeks and months. When a new source appears that is spoofing your domain, you get an alert instead of discovering it in a monthly review.

For organizations at p=none, DMARCFlow tracks the failure rate from each source and helps you distinguish between a one-time glitch and a new third-party sender that needs configuration work. The 30-60-90 day plan above is much easier to execute when you have a dashboard showing your progress rather than a stack of XML files you have to parse manually.

If you are still reading XML files manually and trying to build this picture in a spreadsheet, DMARCFlow handles the interpretation layer so you can focus on fixing the problems instead of finding them.

FAQ

What does p=none mean in DMARC?

p=none tells receivers to take no action on mail that fails DMARC alignment. The mail is delivered normally. You receive aggregate reports describing what the receiver saw. This is the monitoring phase before you enforce a policy.

Why am I seeing failures from my own IP addresses?

Your SPF record may not include all IP addresses that send mail for your domain. If an IP is sending on your behalf but is not in your SPF record, it fails SPF. If your DKIM selector does not cover the domain in the From address, it fails alignment. Check both records against your actual sending infrastructure.

Can I ignore DMARC failures at p=none?

No. p=none means the receiver takes no action, but you are responsible for reviewing the reports. If you move to p=quarantine or p=reject without fixing legitimate failures, you will cause mail delivery problems for yourself.

How long should I stay at p=none?

Most organizations need 4 to 12 weeks at p=none to fully document their email ecosystem. Complex environments with many third-party senders may need longer. The goal is to reduce legitimate failures to near zero before you enforce a policy.

What happens if I move to p=reject too early?

If you move to p=reject before fixing legitimate failures, mail from sources that cannot authenticate will be blocked. This means you may stop receiving important business email. Always test with p=quarantine first and monitor for 2-4 weeks before moving to p=reject.