Your domain publishes DMARC with p=none, or no DMARC record at all. Either way, receivers take no DMARC action on mail that fails DMARC, so anyone can still send as your domain. p=none is monitoring only and doesn’t hurt your delivery; a missing record can. Check which policy applies to your domain below, then move from none to quarantine to reject without blocking your own mail.
Last verified 2 October 2026.
A DMARC record at _dmarc.example.com tells receivers what to do with mail that uses example.com in the From: address but fails DMARC. The p= tag holds the answer: none, quarantine or reject. MXToolbox and other domain health checks show “DMARC Quarantine/Reject policy not enabled” when it is none (MXToolbox’s help page calls it “DMARC Policy Not Enabled”).
none asks for nothing. The two DMARC specifications define it like this:
RFC 9989 calls this Monitoring Mode (§3.2.12): receivers still check your mail and send reports to your rua address, but “the Domain Owner expresses no handling preference for messages that fail DMARC validation.” Microsoft’s documentation says the same: “p=none: No suggested action for messages that fail DMARC. What happens to the message depends on the email protection features in the destination email system. You use this value for testing and tuning of the DMARC policy.”
So p=none is a starting point, not a finished setup. Spoofed mail using your domain is filtered only by each receiver’s own spam checks, the same as if you had no policy. p=quarantine and p=reject are what RFC 9989 calls Enforcement (§3.2.9).
Sources: RFC 7489 §6.3; RFC 9989 §3.2.9, §3.2.12, §4.7 and §5.4; Microsoft Learn, Set up DMARC to validate the From address domain for cloud senders (checked 2 October 2026).
p=none a problem for delivery?No. The bulk sender rules at Gmail, Yahoo and Microsoft require a DMARC record, and all three accept p=none:
v=DMARC1; p=none as its example.Google’s rollout guide says of the none stage: “Messages are delivered normally. There is no risk of messages being rejected or marked as spam.” Moving to quarantine or reject doesn’t make your legitimate mail more deliverable either; it protects your domain from being spoofed. Yahoo’s FAQ: “If you have a spoofing problem, you should be implementing a DMARC enforcement policy (p=quarantine or p=reject) regardless.”
A missing record is different. Google’s FAQ lists this error for bulk senders: “Your email has been rate limited because the sending domain doesn’t have a DMARC record, or the DMARC record doesn’t specify a DMARC policy.” If the checker below finds no record, publish one with p=none first. See the full Gmail, Yahoo and Microsoft bulk sender requirements.
Sources: Gmail Help, Email sender guidelines and Email sender guidelines FAQ; Google Workspace Admin Help, Recommended DMARC rollout (updated 1 October 2026); Yahoo Sender Hub, Sender Best Practices and FAQs; Microsoft Support, Fix NDR error 550 5.7.515 in Outlook.com (all checked 2 October 2026).
Enter the domain in your From: address. The lookup runs in your browser against public DNS: it reads _dmarc for your domain, falls back to the parent domain’s record the way receivers do for a subdomain, and shows whether the policy is enforced, with the next step.
This reads what your DNS publishes right now through Cloudflare’s public resolver, or Google’s when Cloudflare’s fails. A lookup that fails (server error or timeout) shows as unknown, never as “not enabled”. If you just changed the record, an old answer can stay cached until its TTL runs out. For the full A–F grade with SPF, DKIM, MTA-STS, BIMI and DNSSEC, use the DMARC checker.
p=none to p=reject safelyEnforcing too early is how DMARC breaks mail: a newsletter tool, CRM or billing system that sends as your domain without aligned authentication starts landing in spam or bouncing. RFC 9989 §5.1.6 is explicit that these must be fixed first: “For such legitimate uses, these shortcomings MUST be addressed prior to any attempt by the Domain Owner to publish a Domain Owner Assessment Policy (Section 3.2.8) of Enforcement (Section 3.2.9) for the Author Domain.” Microsoft: “A gradual approach to setting up DMARC for your Microsoft 365 domains is recommended.”
rua= address to your record. Without it receivers send no reports, and you can’t see who sends as your domain. Reports arrive as XML attachments, roughly daily, from each receiver that sends them; a DMARC report service makes them readable. A rua address on another domain needs an authorization record on that domain.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.comp=quarantine. Failing mail now usually goes to spam, where recipients can still find it. To ease in, add t=y or a pct= value (see the next section), then remove it.
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.comp=reject once the reports stay clean. Receivers that honor it refuse failing mail during delivery, so it never reaches the inbox or the spam folder.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.comp=reject, an unauthenticated new tool bounces from day one.Change the existing record in place at each step. Don’t publish a second v=DMARC1 record next to it: two records cancel each other out.
Sources: RFC 9989 §5.1.6 and §5.1.7; Google Workspace Admin Help, Recommended DMARC rollout; Microsoft Learn, Set up DMARC to validate the From address domain for cloud senders (checked 2 October 2026).
t=y and pct=RFC 7489 had a pct= tag: apply the policy to only that percentage of failing mail. Google’s and Microsoft’s rollout guides still use it (for example p=quarantine; pct=5, rising to 100). RFC 9989 removed it (Appendix A.6): “Operational experience showed that the "pct" tag was usually not accurately applied, unless the value specified was either 0 or 100 (the default), and the inaccuracies with other values varied widely from one implementation to another.” In its place is t=y, test mode, “meant to be analogous in their application by mailbox providers and intermediaries to the "pct" tag values "0" and "100", respectively.”
t=y (RFC 9989) | Receivers apply one level lower: “if the policy is "quarantine" and the value of the "t" tag is "y", a policy of "none" will be applied to failing messages; if the policy is "reject" and the value of the "t" tag is "y", a policy of "quarantine" will be applied to failing messages” (§4.7). So p=reject; t=y is a safe step between quarantine and reject. Remove t=y (or set t=n) to enforce in full. |
|---|---|
pct= (RFC 7489) | Receivers that still read it apply the policy to about that share of failing mail. Under p=reject, the rest is quarantined: “If the email is not subject to the "reject" policy (due to the "pct" tag), the Mail Receiver SHOULD treat the email as though the "quarantine" policy applies.” (§6.6.4). Treat values between 1 and 99 as approximate, and remove pct= when you finish: 100 is the default. |
Either way the rollout isn’t finished until the tag is gone, which is why checkers (and the checker above) show t=y or pct below 100 as partially enforced.
sp= and np=A subdomain without its own DMARC record (news.example.com with nothing at _dmarc.news.example.com) gets the policy from the organizational domain’s record: its sp= value, or p= when there is no sp=. RFC 9989 also defines np= for subdomains that don’t exist in DNS, which fall back to sp=, then p=.
p=reject alone covers the domain and every subdomain without its own record. That is usually what you want.p=reject; sp=none leaves every subdomain unenforced: billing.example.com can be spoofed. Checkers flag it as partially enforced.np=none does the same for made-up names such as secure-login.example.com. No legitimate mail comes from a name that doesn’t exist, so np=reject is safe early, even while p= is still none._dmarc name, with its own rollout. sp= on a subdomain’s own record is ignored.The most common failure: a tool that sends as your domain from its own servers, signing DKIM with its own domain and using its own Return-Path. SPF and DKIM pass for the tool’s domain, not yours, so DMARC fails. At p=reject that mail bounces (at Outlook.com as 550 5.7.509). The aggregate reports show these sources before you enforce; fix them first.
When mail is forwarded (an alumni address, a role alias) or sent through a mailing list, it arrives from the forwarder’s server, so SPF usually fails. DKIM usually survives plain forwarding, but a mailing list that adds a footer or a subject tag changes the message and breaks the signature. RFC 9989 §7.4: “It is therefore critical that domains that publish "p=reject" MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures to their messages.”
For domains whose people post to mailing lists, the same section says they “SHOULD NOT publish Domain Owner Assessment Policies of "p=reject"”, and that any that want to should first gauge the impact “by publishing "p=none" for at least a month, followed by publishing "p=quarantine" for an equally long period of time, and comparing the message disposition results.” It also notes that mailing list software has adopted workarounds, such as rewriting the From: line, to cope with p=reject. If your users rely on lists, p=quarantine is a reasonable place to stop; put marketing and transactional mail on subdomains, where p=reject carries no list risk.
Source: RFC 9989 §7.4 (checked 2 October 2026).
From a terminal on macOS or Linux:
dig +short TXT _dmarc.example.comYou want one line starting "v=DMARC1; p=quarantine or "v=DMARC1; p=reject, with no sp=none, no t=y and no pct below 100 once you’re done. On Windows:
nslookup -type=TXT _dmarc.example.comIf you still see p=none, the resolver is serving a cached answer: wait for the record’s TTL and check again, or run the checker above. In the next day’s aggregate reports, the published policy shows as <p>quarantine</p> or <p>reject</p>, and failing messages show the disposition the receiver applied.
p=none bad for email delivery?No. RFC 9989 says discovered policies of p=none MUST NOT modify existing mail handling, and Google, Yahoo and Microsoft all accept p=none as the minimum DMARC policy for bulk senders. What p=none doesn’t do is protect your domain: mail that fails DMARC, including spoofed mail using your domain, gets no DMARC treatment. A missing DMARC record is different: Gmail rate limits bulk mail from a sending domain without one.
p=quarantine or p=reject?Both count as enforcement. Quarantine usually sends failing mail to the spam folder, so a mistake is recoverable; reject asks receivers to refuse it. Move to quarantine first, and to reject once your aggregate reports show all legitimate mail passing DMARC. Domains whose users post to mailing lists should be careful with reject: RFC 9989 §7.4 says they SHOULD NOT publish it.
pct= to roll out DMARC gradually?RFC 9989 removed pct because values other than 0 and 100 were applied inaccurately and inconsistently, and replaced it with t=y (test mode), which works like pct=0. Google’s and Microsoft’s rollout guides still show pct steps, and receivers that follow RFC 7489 still read it. You can use it, but don’t rely on the exact percentage; leave it out (or set 100) once you’re done.
p=reject cover my subdomains?Yes, unless you say otherwise. A subdomain without its own DMARC record gets the organizational domain’s sp= policy, or its p= policy when there is no sp=. sp=none leaves those subdomains unenforced, and np=none (RFC 9989) does the same for subdomains that don’t exist.
p=none?Until the aggregate reports show every legitimate sender passing. Google’s rollout guide says one week is usually enough for the reports to cover all mail streams; RFC 9989 says it may take many months for a domain to be sure it authenticates all of its mail. Mail that only goes out monthly or quarterly needs a report window long enough to include it.
If you manage domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with SPF, DKIM, DMARC and an A–F grade. Policies that aren’t enforced show up as issues: dmarc_p_none, dmarc_missing, dmarc_testing_mode, dmarc_partial_pct, dmarc_sp_none and dmarc_np_none, ready to filter in a CSV export. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Related: fixing “DMARC alignment failed”, fixing “multiple DMARC records found”, fixing Outlook’s 550 5.7.509 DMARC reject bounce, BIMI, which needs an enforced policy and the free DMARC, SPF and DKIM checker.