A DMARC policy is the instruction you give receiving mail servers about what to do with messages that claim to come from your domain but fail authentication. It is a single tag in your DMARC record, p=, with three possible values: none, quarantine and reject. Choosing among them is the most consequential DMARC decision you will make, and it is also where most people get stuck. Searches such as "DMARC policy", "DMARC policy not enabled" and "DMARC policy reject" are common because the warning appears in mailbox tools and security scans, and the fix sounds risky: set the policy too strict too early and you can block your own legitimate mail. This guide explains what each policy does, what the related tags (pct, sp, rua, adkim and aspf) change, how to move from monitoring to enforcement in safe stages and how to read the warnings that tell you the policy is not enabled. We do not give timelines that fit every domain, because the right pace depends on how many systems send mail for you. For the record syntax itself, see DMARC record syntax.
What a DMARC policy does
DMARC builds on SPF and DKIM. A message passes DMARC when SPF or DKIM passes and the domain that passed aligns with the domain in the visible From address. See DMARC alignment. When neither aligned check passes, the message fails DMARC and the receiver looks at your policy to decide how to treat it. The policy is a request, not a command: receivers consider it together with their own filtering, but major providers generally honour it, and enforcing it is what stops people spoofing your domain.
The three policies
| Policy | What you ask receivers to do | When to use it | Main risk |
|---|---|---|---|
p=none | Take no action based on DMARC; deliver as normal, send reports | Starting out; discovering all senders | No protection from spoofing, and some tools flag "policy not enabled" |
p=quarantine | Treat failing mail with suspicion, commonly delivering to spam or junk | Intermediate step once legitimate senders are aligned | Legitimate mail from a forgotten sender lands in spam |
p=reject | Refuse failing mail at the SMTP stage | Target state for domains that send mail | Legitimate mail from a forgotten sender is bounced |
Why "none" is not the end state
A none policy is valuable, because it produces reports without risking delivery, but on its own it does nothing to stop spoofing. Treat it as a measurement phase. Domains that stay on none indefinitely get the paperwork of DMARC without the protection. Mailbox providers also expect bulk senders to publish a DMARC record; check their current requirements rather than relying on a summary. See the Gmail and Yahoo bulk sender requirements.
The tags that go with the policy
| Tag | Purpose | Notes |
|---|---|---|
p | Policy for the domain | Required |
sp | Policy for subdomains | If absent, subdomains inherit p |
pct | Percentage of failing mail the policy applies to | Lets you roll out gradually; support varies by receiver, so treat it as a request |
rua | Where to send aggregate reports | Essential for the monitoring phase |
ruf | Where to send failure reports | Support is limited and reports can contain message content; many domains omit it |
adkim, aspf | Alignment mode, relaxed or strict | Relaxed is the default and suits most senders |
An example of a monitoring record, with a reporting mailbox you control:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:[email protected]"And an example of an enforcing record:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"Both are illustrations of structure. Replace the domain and mailbox with your own.
A safe path from none to reject
- Publish
p=nonewith aruaaddress. Make sure the mailbox can receive reports, or use a reporting service that reads them for you. See reading aggregate reports. - Inventory your senders. Aggregate reports show every source sending as your domain: your mailbox suite, your sending service, billing tools, support desks, forms, newsletters and servers you forgot about.
- Align each legitimate sender. For each one, set up DKIM signing for your domain and, where possible, a return-path that aligns. See authenticating your sending domain and custom return-path domains. Retire senders you do not recognise after checking they are not legitimate.
- Move to
quarantine. Many teams start withpctat a low value and raise it while watching reports and support mail. Keep an eye on bounces and complaints from people who report missing mail. - Move to
reject. Once reports show that legitimate mail passes consistently, enforce. Keep monitoring afterwards, because new tools get added over time. - Decide about subdomains. Use
spif you need a different policy for subdomains, and publish locked-down records for domains that never send. See parked and non-sending domains.
There is no universal schedule. A domain with two senders may finish in weeks; one with many departments and legacy systems takes longer. Move when the reports say you are ready, not when the calendar says so.
"DMARC policy not enabled": what the warning means
Security scanners and mailbox tools show this message in three situations.
- No DMARC record exists. Publish one, starting with
p=noneif you have not done any monitoring. - The record exists but the policy is
none. The tool is telling you that nothing is enforced. Plan the move to quarantine and then reject. - The record is malformed. A typo, a missing
v=DMARC1, two DMARC records on the same name or the record published at the wrong hostname (it must be at_dmarcunder the domain) all make receivers ignore it. Check with our SPF, DKIM and DMARC checker.
Common mistakes
- Jumping straight to reject without a monitoring phase and blocking mail from forgotten systems.
- Not receiving reports because
ruapoints to a mailbox that does not exist or a domain that needs authorisation to receive reports for yours. - Forgetting subdomains. Spoofers use them. Set
spdeliberately. - Misunderstanding forwarding. Forwarded mail can break SPF, and mailing lists that modify messages can break DKIM. This is why aggregate reports show some legitimate failures. Know the patterns before enforcing.
- Assuming DMARC improves inbox placement. It protects your domain from spoofing and supports trust, but it does not guarantee delivery.
Does DMARC affect sending through a relay?
Yes, because your mail passes DMARC only when aligned authentication is in place. When you send through our SMTP relay or email API, add the SPF and DKIM records shown in your dashboard domain settings, send from an address on that domain and check the results in the headers. See how to read email headers. Then enforce your policy.
How to tell you are ready to enforce
A practical readiness test has three parts. First, your aggregate reports show that all the volume you recognise passes with alignment. Second, the volume that fails is either unknown sources you have decided to block or small, understood patterns such as forwarding. Third, you have told the teams who send on behalf of the company, so a new tool does not surprise anyone. Write the decision down with the date, so the next person knows why the policy is what it is.
Check your DMARC record now See your current policy, spot syntax errors and confirm SPF and DKIM with the free checker.
References and further reading
Frequently asked questions
What is a DMARC policy?
The p tag in your DMARC record. It tells receivers what to do with mail that fails DMARC: none (monitor), quarantine (treat as suspicious) or reject (refuse).
What does DMARC policy not enabled mean?
Either no DMARC record exists, the policy is set to none so nothing is enforced, or the record is malformed or at the wrong hostname.
Should I use quarantine or reject?
Reject is the usual target for domains that send mail, but quarantine is a sensible intermediate step. Move when aggregate reports show legitimate mail passing consistently.
Is p=none safe to leave forever?
It is safe for delivery but gives no protection against spoofing. Use it for monitoring and plan to enforce.
Does DMARC policy apply to subdomains?
Subdomains inherit the main policy unless you set the sp tag. Set it deliberately and lock down domains that never send.