p=reject, you are about to move mail to a new provider, and someone suggests dropping the policy to p=none 'just to be safe.' It sounds cautious. Sometimes it is the right call. Often, though, it guards against a problem a careful migration never has, and it switches off protection you already earned.
Whether relaxing makes sense depends on what DMARC actually checks, and which part of a migration touches it.
What DMARC is checking while you migrate
d= value, matches the From domain. That matching is called alignment. One aligned pass is enough. If both fail, the receiver looks at your policy tag. p=none means deliver as usual and report. p=quarantine means treat it as suspicious, usually the spam or junk folder. p=reject means refuse the message during the SMTP conversation.
One point clears up much of the confusion: DMARC is about mail sent from your domain. Changing your MX records moves where incoming mail lands. It has no effect on whether your outgoing mail passes DMARC. The only real risk during a move is that the new platform starts sending as your domain before its SPF and DKIM are set up to align. This is a common source of confusion at the support desk. People connect the MX cutover with the DMARC policy, when the two are independent.
A plain example
example.com sits at p=reject, and its mail has always gone out through the old host's server. The SPF record authorizes that server, and the old server signs DKIM as d=example.com. Everything aligns.
Now users start sending through the new provider. If nobody added the new provider to SPF, the SPF check fails. If the new platform signs DKIM with its own domain, the signature may be valid, but it does not align with example.com. Some platforms do this by default until you set up custom-domain signing. Both paths fail, so receivers honor p=reject and the mail bounces. That is the scenario people are trying to avoid.
The fix is not the policy. It is the order of work. The new provider gives you a DKIM public key to publish under its own selector, a name like selector1._domainkey.example.com. Selectors let the old and new keys live side by side, so publishing the new one breaks nothing. SPF can authorize both providers for the overlap period. If both records are in DNS and verified before anyone sends through the new platform, legitimate mail never has a failing window, and p=reject can stay exactly where it is.
When relaxing the policy is the reasonable call
p=quarantine is usually a better step than p=none. Under quarantine, a misconfigured legitimate message lands in junk, where the recipient can still find it. A spoofed message is kept out of the inbox. Under p=none, both go wherever the receiver's normal filtering puts them.
If only one subdomain is the problem, for example a marketing tool that sends from news.example.com, you do not need to touch the root policy. A subdomain policy (sp=) or a separate DMARC record on that subdomain limits the change to where the risk is.
The pct= tag is another option. It applies the policy to a percentage of failing mail, so a staged return to reject can start small. Receiver support varies, and the revised DMARC specification under work at the IETF proposes replacing pct with a simpler test flag. Treat it as a soft dial, not a precise control.
What p=none costs while it is in place
p=none, receivers get no DMARC instruction to act on failures. Anyone can put your domain in the From line, and the only defense is the receiver's own filtering. That filtering is often decent but not designed around your domain. You still get reports, so you can see the spoofing. You just cannot stop it.
There are side costs too. BIMI, the standard for showing a brand logo next to messages in supporting inboxes, requires an enforced DMARC policy. Dropping to p=none can make the logo disappear. Relaxing also brings no deliverability gain. Large mailbox providers that require DMARC for bulk senders accept p=none as the minimum, but a stricter policy does not hurt aligned mail. The only thing relaxing protects is your own misaligned mail.
Timing matters as well. Receivers cache your DMARC record for its TTL, so a relaxation does not take effect instantly, and neither does re-enforcement. If you relax, lower the record's TTL ahead of time so you can tighten again quickly.
Before deciding either way, confirm what receivers see right now:
BASH
# Show the DMARC policy currently published for the domain
dig +short TXT _dmarc.example.comv=DMARC1, with a p= tag and, ideally, a rua= address for aggregate reports. If there is no rua=, fix that first. Without it, you have no way to tell when the migration is done.
Reading aggregate reports to decide when to tighten again
rua= address, are XML files that participating receivers send, typically once a day. Each one groups mail by sending IP and lists the message count, the disposition applied, the SPF and DKIM results with the domains they were checked against, and whether each result aligned. Raw XML is tedious to read by hand, so most people run it through a parser or a reporting service.
During a migration you are looking for three things. First, the new provider's sending IPs should appear with DKIM passing and aligned on your domain, ideally SPF too. Second, the old provider's IPs should fade toward zero as users and tools move over. Third, every remaining failure should be explainable. Failures from IPs you recognize as your own tools mean there is still configuration work to do. Failures from IPs you do not recognize are usually spoofing, which is exactly what enforcement exists to block. Forwarded mail is a known source of noise. Forwarding typically breaks SPF, while DKIM usually survives unless a mailing list modifies the message.
A reasonable rule of thumb is to wait until the reports stay clean over a period that covers your normal business cycle. If invoices go out monthly, a week of clean reports may not include the invoicing system at all. A deeper checklist for this step is in What to Audit Before Switching DMARC Policy from None to Reject. To check a single message quickly instead of waiting for reports, send one from the new platform to an external mailbox and read the Authentication-Results header, as described in Reading Authentication-Results Headers to Fix DMARC Alignment.
Mistakes that turn a short relaxation into a long one
p=none causes no visible problems, so nothing reminds anyone to change it back. Put the re-enforcement date somewhere a person will see it.
Another is relaxing without reports. Without rua=, p=none gives you no visibility and no protection.
Cleanup order trips people up too. Removing the old provider's SPF include or DKIM selector while anything still sends through the old system creates the failures you were trying to avoid. Retire old records only after the reports show the old IPs have gone quiet.
SPF has its own limit to watch. Stacking includes for the old provider, the new provider, and several third-party tools can exceed SPF's limit of 10 DNS lookups. When that happens, SPF returns a permanent error for every message, and alignment falls back entirely on DKIM. Count lookups whenever you add an include.
The last mistake is blaming DMARC for every bounce. A rejection after a migration can come from a missing PTR record, a reputation issue on new IPs, or rate limiting. Read the bounce text before touching the policy.
In practice, the safest migration usually keeps the enforced policy and gets the order right: publish the new DKIM key and SPF entry, verify them, then move senders. If you cannot be sure every sender is covered, step down to p=quarantine with reports enabled and a lowered TTL. Watch the reports until the new platform aligns and nothing legitimate fails, then go back to p=reject on a date you set before you relaxed it.