How to move DMARC from p=none to p=quarantine
Your DMARC record already exists and sits at p=none, so receivers report but nothing is enforced. Moving to p=quarantine is not a one-line DNS edit, it is a readiness check: every system that sends as your domain has to authenticate and align first, otherwise the first thing quarantine catches is your own invoices. Run the email check on this page to see what receivers currently see for your domain, then work through the steps below.
Check your site
-
Confirm every legitimate sender authenticates
Enforcement only affects mail that fails, so the sender list has to be complete and clean before you touch the policy. Run the email check on this page: it shows your MX, the SPF record, the DKIM selectors it can find, and the DMARC policy currently published. If it finds no DKIM selectors, stop here, you would be enforcing with SPF alone and SPF does not survive forwarding. The checker probes common selector names, so an unusual selector can be missed; confirm on the DKIM page of each sending service as well (mail host, CRM, invoicing, marketing, helpdesk, monitoring).
-
Read aggregate reports long enough to see everyone
Two weeks of rua data shows your daily senders, not your quarterly ones. Billing runs, seasonal campaigns, the annual renewal notice, a helpdesk that only mails when a ticket opens: these show up in reports late or not at all. Wait for at least one full billing cycle, four to six weeks is a reasonable minimum, and read the reports as a list of source IPs and the domains they authenticate as, not just as an overall pass rate.
-
Verify alignment, not just a pass
DMARC does not care that SPF or DKIM passed, it cares whether the domain that passed matches the From header. A message can pass SPF for the sending provider's own bounce domain and still fail DMARC. Relaxed alignment (the default, adkim=r and aspf=r) accepts a match on the organizational domain, so mail.yourdomain.com aligns with yourdomain.com; strict (s) demands an exact match. In your reports, look for rows where SPF or DKIM says pass but the DMARC result is fail: that is misalignment, and it is fixed at the sending service, by setting a custom Return-Path under your domain or signing DKIM with d=yourdomain.com.
-
Check that SPF is not over the 10-lookup limit
SPF allows 10 DNS lookups; beyond that receivers return PermError and the SPF path is effectively gone before you tighten anything. The check on this page counts how many lookups your record costs. If it reports 10 or more, fix that first: drop includes for services you no longer use, or replace a bloated include with the specific IPs it resolves to. If the count is comfortably under 10 and DKIM is in place, you have both authentication paths and can move on.
-
Switch to quarantine on a small percentage
Edit the _dmarc TXT record, change p=none to p=quarantine, keep rua, and add pct=10 so the policy applies to roughly a tenth of failing mail: v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@yourdomain.com. Give it a week, then step up to 25, 50, 100, waiting a full reporting cycle at each level. Treat pct as a rollout aid rather than a permanent setting: the updated DMARC specification removes the tag and not every receiver honours it, so drop pct once you are at full quarantine.
-
Keep rua on and watch after every increase
Never remove the rua tag while you are tightening, it is the only feedback you get. After each step up, read the next reports and look for legitimate sources that started failing. If one appears, lower pct or go back to p=none, fix authentication or alignment for that sender, then continue. Decide on subdomains too: without an sp tag they inherit your policy, and adding sp=none temporarily to keep a noisy subdomain out of enforcement is a reasonable move.
How to verify the result
Re-run the email check on this page. The DMARC line should show the new policy (p=quarantine, with pct if you kept it), SPF should still be valid with its lookup count under 10, and the DKIM selectors you rely on should still be found. If DMARC still reads p=none, either the TXT change has not propagated yet (wait out the TTL of the old record) or the new record was added next to the old one: exactly one DMARC record may exist at _dmarc, and with two receivers treat the domain as having no usable policy at all.
Tip: Forwarded mail routinely fails SPF because the forwarding server sends from its own IP, which is exactly why a valid DKIM signature with an aligned d= is what carries a message through enforcement. Mailing lists go further and rewrite the subject or body, breaking DKIM too; most well-run lists work around this by putting their own domain in the From header. Jumping straight from p=none to p=reject without this preparation is the classic way to lose real mail, and when the sender is a third-party service its bounces usually never reach you, so you hear about it from the customer instead.