In short
A DMARC policy is the p tag in your DMARC record: none (monitor only), quarantine (treat failing mail as suspicious) or reject. RFC 9989 advises that domains whose users post to mailing lists should not publish p=reject without testing first, while the UK's NCSC calls reject on all domains the best way to prevent spoofing. Reports show which end state suits each domain.
Not sure where to start?
Tell us what you need to achieve and we will point you to the right option.
The three DMARC policy options
The p tag is the heart of a DMARC record. RFC 9989 section 4.7 (opens in a new tab), the current DMARC standard, calls it the Domain Owner Assessment Policy and defines three values. If a valid record has no p tag at all, receivers treat it as p=none.
| Policy | What RFC 9989 says it means | What receivers usually do | When to use it |
|---|---|---|---|
| p=none | No expression of preference | Deliver as normal, and send reports if you asked for them | Starting out, and while you find every service that sends as you |
| p=quarantine | Failing mail is suspicious; it may still be valid | Treat as suspicious, typically delivering to spam or junk | Once your genuine senders pass; a common end state for mailbox domains |
| p=reject | Failure is a clear sign the use of the domain is not valid | Refuse the message during delivery, or treat it as suspicious | Domains whose senders are all confirmed, and domains that send no email |
Google's Set up DMARC (opens in a new tab) page describes the receiving side in the same terms: with none the message is delivered and logged in the daily report, with quarantine it is marked as spam, and with reject it is rejected, usually with a bounce message to the sending server. Typical records look like this:
| Stage | Record at _dmarc.example.co.uk |
|---|---|
| Monitoring | v=DMARC1; p=none; rua=mailto:dmarc@example.co.uk |
| Testing quarantine | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.co.uk |
| Quarantine | v=DMARC1; p=quarantine; rua=mailto:dmarc@example.co.uk |
| Reject | v=DMARC1; p=reject; rua=mailto:dmarc@example.co.uk |
You can see any domain's current policy with our DMARC checker, and build a new record with the DMARC generator. The DMARC record explained guide covers every other tag.
Not sure which option fits? Ask us
Tell us what you need and we will help you choose the right option.
Monitoring Mode and Enforcement
RFC 9989 gives names to the two states a domain can be in:
- Monitoring Mode (section 3.2.12 (opens in a new tab)): the policy for the domain and all its subdomains is p=none and you are receiving aggregate reports. Receivers still check DMARC, but you are expressing no handling preference while you use the reports to fix your senders
- Enforcement (section 3.2.9 (opens in a new tab)): the policy is anything other than p=none. Messages that fail DMARC will not reach the inbox at receivers that honour your policy
Monitoring Mode is safe by design. RFC 9989 section 5.4 (opens in a new tab) says a p=none policy must not change how receivers already handle mail, so publishing it cannot stop your email. It also cannot stop anyone spoofing your domain, which is why security scanners flag it as DMARC policy not enabled.
Test mode: the t tag
RFC 9989 adds a t tag for testing a stricter policy. With t=y, receivers are asked to apply one level below the stated policy: p=quarantine is applied as none, and p=reject as quarantine. It has no effect on p=none and does not change the reports you receive. Receivers that have not yet adopted RFC 9989 ignore the t tag and apply quarantine in full, so publish p=quarantine; t=y only once your reports show your genuine senders pass. It replaces the old pct tag, which RFC 9989 appendix A.6 (opens in a new tab) removed because it was "usually not accurately applied" unless set to 0 or 100. Much published guidance still shows pct, so expect to see it in older examples.
Which end state suits which domain?
Not every domain needs to end at the same policy, and the guidance you will read sets out two views. Both are worth knowing.
- RFC 9989 (section 7.4 (opens in a new tab)) warns that p=reject can cause problems for forwarded mail and mailing lists. It says domains whose users might post to mailing lists should not publish p=reject, and that any such domain wanting to should first publish p=none for at least a month, then p=quarantine for an equally long period, and compare the results. Domains that do publish p=reject must not rely on SPF alone and must sign their mail with DKIM (opens in a new tab)
- The NCSC says that having a DMARC policy of reject on all of your domains (opens in a new tab) is the best way to prevent spoofing of your email, and that all your domains, including parked ones, should have DMARC records
Check Point's DMARC Management guide (opens in a new tab) turns this into a practical rule of thumb, citing RFC 9989:
| Domain type | Recommended end state (Check Point) |
|---|---|
| Human mailbox or general-purpose domain | Usually p=quarantine |
| Transactional or outbound-only subdomain | Often p=reject |
| Non-sending domain or unused subdomain space | p=reject, often with sp=reject and np=reject |
| Mixed-use main domain | p=quarantine at the main domain, with stricter policies on dedicated sending subdomains |
In practice that means splitting your mail by purpose. Staff mailboxes stay on the main domain; invoices, alerts and marketing go from their own subdomains, each with a policy that suits it. Your aggregate reports show which approach fits, because they show what forwarding and mailing-list traffic your domain actually has.
Need help choosing?
We will recommend what fits your organisation and explain why, in plain English.
Moving to enforcement step by step
The safe route is the same whichever end state you choose: let the reports tell you when each step is ready.
- Publish p=none with a rua address, so receivers start sending aggregate reports. The NCSC says (opens in a new tab) reports from major providers arrive within 24 hours
- Read the reports and list every service sending as your domain: your mailbox platform, CRM, finance system, marketing platform, website forms and so on
- Fix SPF and DKIM for each genuine sender so it passes with alignment. RFC 9989 section 5.1.6 (opens in a new tab) says this must be done before you publish an enforcement policy
- Test with p=quarantine; t=y, then publish p=quarantine and watch for genuine mail that fails
- Move to p=reject on the domains where it suits (sending subdomains and non-sending domains first), keeping an eye on the reports
- Keep reading the reports, because new senders appear whenever a team adopts a new tool
How long each stage takes depends on how often your mail streams send. RFC 9989 section 5.1.7 (opens in a new tab) notes it may take many months of reports before you are sure everything is authenticated. The published timings vary:
| Guidance | At p=none | At p=quarantine | After moving to p=reject |
|---|---|---|---|
| NCSC (opens in a new tab) | Many organisations move on after about 6 to 8 weeks | Monitor for at least 4 weeks at full quarantine; many move to reject after about 3 months | Closely monitor for at least 2 weeks |
| RFC 9989 (opens in a new tab) (mailbox domains) | At least a month | An equally long period, then compare dispositions before choosing reject | Keep reading reports (no period given) |
| Google Workspace (opens in a new tab) | One week, reviewing reports daily | Start with a small share of messages and increase it | Review reports daily |
The figures are each organisation's own guidance rather than rules. A business with a quarterly mailing, for example, needs at least a quarter of reports before it has seen every sender.
Policies for subdomains
By default, the p policy on your main domain also covers its subdomains. The sp tag sets a separate policy for subdomains that exist, and np, new in RFC 9989 (opens in a new tab), covers names that do not exist in DNS at all, so a common pattern is quarantine for the main mailbox domain with reject for made-up or non-sending subdomains. The DMARC record explained guide covers the syntax of sp, np and subdomain records, with examples.
The rules receivers apply
Your policy is a request. RFC 9989 sets out how receivers should act on it:
- Pass or fail first. A message passes DMARC if SPF or DKIM passes for a domain aligned with the From address; otherwise it fails (section 5.3.5 (opens in a new tab)). The policy only matters for messages that fail
- DNS errors mean no verdict. If a DNS lookup needed for DMARC fails, the message cannot pass or fail, and the policy is not applied
- The final decision is the receiver's. Handling is a matter of the receiver's local policy (section 5.4 (opens in a new tab)). Receivers may quarantine or reject mail that passes DMARC, and may accept mail that fails
- p=reject is not applied blindly. Receivers must not reject messages solely because of a p=reject policy; without other knowledge and analysis they must treat failing mail as if the policy were quarantine (section 7.4 (opens in a new tab))
- Overrides are reported. When a receiver departs from your policy, for a mailing list or a known forwarder for example, it should say so in the aggregate report using the policy override reasons in RFC 9990 (opens in a new tab)
The record itself has rules too: v=DMARC1 must come first, unknown tags are ignored, and if a domain publishes more than one DMARC record, receivers discard them all (section 4.10 (opens in a new tab)). Our DMARC checker tests for each of these.
How we help you reach enforcement
Moving every domain to the right policy is mostly careful work with the reports, and the platforms we supply are built for it:
- EasyDMARC Managed DMARC (opens in a new tab) publishes your record once through a CNAME, then lets you change the policy from the dashboard with pre-save validation, gradual ramps, a versioned change history and one-click rollback to an earlier version
- Valimail Enforce, as Valimail describes it (opens in a new tab), automates SPF, DKIM and DMARC record management and sender authorisation to get the domain to enforcement
- Check Point DMARC Management, an add-on to Check Point Email Security (opens in a new tab), gives actionable recommendations (opens in a new tab) per domain, including when to implement a restrictive policy (which its guide ties to DMARC failures falling below 3%)
We can assess your domains and their current policies, set up reporting, help you choose and supply the platform that fits, and work with you through each sending service and each policy step, at a pace that suits you. Licences can be billed monthly, with terms confirmed at quote. See DMARC management for the platforms side by side, or contact us for free advice.
More on DMARC policy
Frequently asked questions
What is a DMARC policy?
A DMARC policy is the p tag in your DMARC record, published as a DNS TXT record at _dmarc.yourdomain. It tells receiving mail servers what you would like done with email that claims to come from your domain but fails DMARC: none (no preference, deliver as normal), quarantine (treat as suspicious, typically spam) or reject (refuse it).
Is p=none enough?
p=none is the right place to start, because it gets you reports without affecting delivery. On its own it does not stop spoofing, because receivers are not asked to act on failing mail. The NCSC (opens in a new tab) and RFC 9989 both treat it as a stage: read the reports, fix your senders, then move to quarantine and, where it suits the domain, reject.
What does a DMARC policy of reject mean for my email?
Mail from your own correctly authenticated senders is unaffected. Messages that fail DMARC, which should then be only spoofed mail and anything you have not yet set up, are refused by receivers that honour the policy. Forwarded mail and mailing-list posts can fail too, which is why RFC 9989 advises domains whose users post to mailing lists not to publish p=reject without testing first, and why many organisations use reject on sending subdomains and non-sending domains first.
Should I use quarantine or reject?
It depends on the domain. Check Point's guide, citing RFC 9989, suggests quarantine as the usual target for domains used by people's mailboxes and reject for transactional subdomains and domains that send no email. The NCSC recommends reject on all domains as the strongest protection against spoofing. Your reports show which fits: if forwarding and mailing-list traffic is rare, reject is easier to reach.
Do Google and Yahoo require p=reject?
No. Google's email sender guidelines (opens in a new tab) say bulk senders' DMARC enforcement policy can be set to none, and Yahoo asks bulk senders for at least p=none. Both require DMARC to pass, with the From domain aligned to SPF or DKIM. Yahoo adds that if you have a spoofing problem you should use quarantine or reject regardless. See DMARC sender requirements.
What happened to the pct tag?
RFC 9989, published in May 2026, removed pct and lists it as historic, because it was rarely applied accurately except at 0 or 100. The new t tag replaces it for testing: t=y asks receivers to apply one level below your stated policy. Some platforms and older guides still use pct ramps.
Still have a question about DMARC enforcement?
Ask us and a member of our team will get back to you.