What to Do When a Vendor Sets Your DMARC Policy to Reject Overnight

The Situation: Vendor Changed Your DMARC Policy and Mail Stopped Working

Friday afternoon. The help desk is lighting up. Someone noticed that emails to a major customer are bouncing, and a few team members say they cannot receive any mail from their own domain. You trace it back within an hour: a vendor -- Proofpoint, Mimecast, IronScales, Cisco, Barracuda, or another security gateway -- changed your DMARC policy to reject without telling you first. This is not rare. It happens often enough that it has its own pattern in DMARC support forums and Reddit threads. The vendor enabled p=reject on their side of the configuration, often as part of a security hardening push or a default setting they apply across all customer accounts. Your legitimate mail starts failing DMARC alignment checks at receiving servers, and those servers silently drop it. Here is what to do next.

How to Confirm a DMARC Policy Change Is the Cause

Before assuming anything, confirm the cause. Email can break for many reasons, and solving the wrong problem wastes time.

1. Look up your DMARC record in DNS. Run:

ord in DNS. Run:

dig txt _dmarc.yourdomain.com

or use an online DNS lookup tool. Check the p= value. If it says p=reject, that is a policy change worth investigating. If it says p=none or p=quarantine, the vendor change is probably not the cause.

1. Check when the record last changed. If you do not have DNS change logs saved, use the Wayback Machine at web.archive.org to compare the current record against the last snapshot. A shift from p=none to p=reject is visible immediately this way.

1. Pull your DMARC aggregate reports. If you receive them, look for a sudden jump in rejection counts starting on or around the date the vendor says they made the change. High DKIM failures and SPF failures from IPs you do not recognise -- or from IPs associated with your vendor -- are the signature of a vendor-initiated policy change.

1. Ask the vendor directly. Most will confirm within minutes if they changed a policy setting. They may call it "security hardening" or "enabling DMARC reject mode." Get them to specify exactly what they changed and when.

What Actually Breaks When the Policy Changes to Reject

p=reject tells receiving mail servers: drop any message purporting to be from your domain that fails DMARC alignment. The three alignment checks are SPF alignment, DKIM alignment, and the combination of both. When a vendor initiates this change, breakage usually shows up in one of three forms. DKIM alignment failure The vendor is not signing outbound mail with your DKIM key. Their mail servers use their own DKIM key, which signs mail under their domain, not yours. When the receiving server checks DKIM alignment against your header-from domain, the result is fail. DMARC rejects the message. This is the most common breakage pattern with Proofpoint and similar SEG vendors. SPF alignment failure The vendor rewrites the envelope-from address. Outbound mail that should appear to come from yourdomain.com instead shows envelope-from as something like from-vendor.yourdomain.com or a completely different domain the vendor controls. SPF checks the envelope-from domain against the sending IP, not the header-from. SPF alignment fails. DMARC rejects. Forwarding chain breakage The vendor relay introduces extra hops. The original auth results from your mail server get stripped or rewritten by the time the message reaches the next hop. By the time the final receiving server evaluates the message, none of the original SPF or DKIM results are available. DMARC fails. All three patterns produce the same result: silent message rejection. The sending server may not get a bounce message back. The rejection happens at the receiving server, and the sender has no indication anything went wrong except missing replies.

Immediate Steps to Restore Mail Flow

Stop the bleeding first. Then fix the root cause. Step 1: Contact the vendor and request an immediate revert Ask the vendor to set the DMARC policy back to p=none or p=quarantine while you investigate. Most vendors will do this within the same business day if you frame it as an active email outage. Get written confirmation of what they changed and when. You want a paper trail in case this happens again. Step 2: If the vendor cannot or will not revert: use pct= to limit exposure Add a percentage directive to your DMARC record while you work the problem:

v=DMARC1; p=reject; pct=10; rua=mailto:your-reports@yourdomain.com

pct=10 means 10% of messages that fail DMARC are rejected; the other 90% are delivered normally. This buys you time to fix the root cause without turning off protection entirely. Monitor your aggregate reports for 24 to 48 hours before raising the percentage. Step 3: Get the vendor to sign with your DKIM key This is the cleanest long-term fix. Ask the vendor whether their platform supports DKIM signing under your domain rather than theirs. Most major SEG platforms support this, though it requires configuration on the vendor side. If they support it, you provide them your DKIM selector and they publish it. Their mail now passes DKIM alignment automatically. If they cannot do DKIM signing under your domain, ask about SRS (Sender Rewriting Scheme). SRS is a protocol that rewrites the envelope-from in a way that preserves SPF alignment through vendor relays. Not all vendors support it, but the ones that do tend to document it clearly. Step 4: If neither of those is available: isolate the affected flow to a subdomain Move the sending flow that the vendor controls to a subdomain that has its own DMARC record with p=none:

v=DMARC1; p=none; rua=mailto:your-reports@yourdomain.com

Your main domain keeps its reject policy. The subdomain handles the vendor flow without triggering rejections on your primary domain. This is not ideal -- you lose protection on that subdomain -- but it stops the bleeding.

Reading Your DMARC Aggregate Report to Find Exactly What Is Failing

Aggregate reports arrive daily from participating receivers. Each report covers a 24-hour window and tells you which IPs sent mail on your domain, what the SPF and DKIM results were, and what the receiving server did with the message. The fields worth focusing on:

• Source IP: the IP address that sent the message. Match this to your vendor's IP ranges using ARIN or your vendor's documentation.
• SPF result: pass or fail against the envelope-from domain.
• DKIM result: pass or fail against the header-from domain.
• Disposition: none, quarantine, or reject -- what the receiver did with the message.
• Count: how many messages from this source failed.

Sort by count. High-volume failures are your priority. A source sending 10,000 messages a day with 100% DKIM failure is more urgent than one sending 50 messages with occasional SPF issues. Raw aggregate reports arrive as XML. Reading XML by hand is time-consuming. If you are reading XML manually, you are spending time that would be better spent fixing the sources. DMARCFlow parses aggregate reports automatically and converts them into structured summaries: which IPs failed, why they failed, and how many messages were affected. For a vendor-induced policy change, that means you can identify the problematic vendor IPs within minutes of the report arriving, rather than spending an afternoon reading XML entries one by one.

Preventing This From Happening Again

Once the immediate crisis is resolved, take three steps that make this scenario less likely to repeat. Add a vendor notification clause to your contracts Require written notice -- 10 business days minimum -- before any vendor makes a DMARC policy change. Include a testing window. Most vendors will agree to this if you frame it as a SLA requirement rather than a request. Get it in writing. Verbal agreements with vendor support staff do not survive staff turnover. Set up DNS change monitoring for your DMARC record You should know within hours, not days, when your DMARC record changes. Several DNS monitoring services can alert you to TXT record changes on your DMARC record. Combine this with your aggregate report delivery: if both alerts fire at the same time, you have a vendor-initiated change rather than an attack. DMARCFlow includes DNS change monitoring for this reason -- you get the alert before your mail starts bouncing. Move to p=reject on your own timeline, not the vendor's If you have been running at p=none, plan your own migration to p=reject. The process looks like this:

1. Set pct=50 with p=reject. Monitor aggregate reports for 48 hours. Fix any legitimate sources that appear.
2. Raise to pct=75. Monitor for another 48 hours.
3. Raise to pct=100. You are now at full reject policy.

This puts you in control of the timeline. You find the problems on your schedule, not the vendor's. You can stop at any percentage if something breaks. And when you finally reach p=reject without pct=, you know you have already handled every legitimate source in your aggregate reports.

Frequently Asked Questions

Can I stop a vendor from changing my DMARC record? You control your own DNS. If the vendor has write access to your _dmarc DNS record, you can revoke that access after the vendor configures their side. The fix is to review what DNS access you have granted each vendor and tighten it to read-only after initial setup. For the current incident, the fix is contractual: add the notification and testing window clause to future vendor contracts. My vendor says they cannot configure DKIM alignment under my domain. What are my options? Your options are: SRS (if the vendor supports it), subdomain isolation with a local p=none policy, or finding an alternative vendor that supports domain-aligned DKIM signing. Most large SEG vendors support DKIM alignment -- if yours does not, escalate with their technical team before accepting "we cannot do that" as a final answer. How long until aggregate reports show me what failed? Typically 24 to 48 hours after the rejection event. Receiving servers send aggregate reports on their own schedule, and some do not send them at all. For immediate visibility, you need DNS change monitoring. Aggregate reports tell you what failed after the fact; DNS change alerts tell you within hours that something changed. Does pct= actually work as a safety net when transitioning? Yes. pct= is a built-in DMARC directive that controls what percentage of failing messages are affected by the policy. Setting p=reject with pct=10 means 10% of failing messages are rejected, 90% are delivered. This lets you see real-world results from your aggregate reports before you raise the percentage. Start at pct=50 unless the volume of failures is very high -- you want to find failures quickly, not minimise disruption at the cost of speed.