In short
"DMARC policy not enabled" means a domain has no DMARC record, or one set to p=none, so receivers are not asked to act on spoofed mail. It is a prompt, not an outage. The UK's NCSC advises starting at none, then moving to quarantine and reject once reports show your genuine senders pass.
Get a quote for DMARC policy fix
Tell us roughly how many users or sites you have and we will come back to you with options and a quote.
What the warning means
Domain scanners and email health checks look up the TXT record at _dmarc.yourdomain and read its p tag. If the record is missing, or the policy is none, they report that a quarantine or reject policy is not enabled. EasyDMARC's guide to the warning (opens in a new tab), which its own domain scanner shows, explains that it most often means the policy is set to p=none.
The wording varies between tools. These are the common versions and what lies behind them:
| What the scanner says | What it found | What to do |
|---|---|---|
| DMARC policy not enabled (opens in a new tab) | A record at p=none, or no record | Check your senders, then move towards quarantine |
| DMARC quarantine/reject policy not enabled | A record at p=none | Plan the move to quarantine, then reject where it suits |
| No DMARC record found | Nothing at _dmarc.yourdomain | Publish a p=none record with a rua address first |
| DMARC policy is none or monitoring only | A record at p=none | As above: use the reports to get to enforcement |
A record at p=none is what RFC 9989 calls Monitoring Mode (opens in a new tab): receivers still check DMARC and send you reports, but you are expressing no preference about failing mail. Two other records behave the same way: a valid record with no p tag at all is treated as p=none, and a record of p=quarantine with t=y (test mode) asks receivers that support RFC 9989 to apply none. Our DMARC checker shows which applies to your domain.
Not sure which option fits? Ask us
Tell us what you need and we will recommend the right option for your organisation, with a quote.
Why scanners flag it and how urgent it is
The warning is about spoofing. With no enforcement policy, anyone can send email that claims to be from your domain, and receivers have no instruction from you to stop it. With p=quarantine or p=reject, messages that fail DMARC will not reach the inbox (opens in a new tab) at receivers that honour your policy.
How urgent that is depends on what you see:
- If your domain is being spoofed, act sooner. Yahoo's sender FAQs (opens in a new tab) say that if you have a spoofing problem you should be implementing a DMARC enforcement policy (quarantine or reject) regardless
- If you are just starting out, p=none is the right first step. The warning is a reminder that it is a stage, not the finish
- If you send to UK public sector bodies, note that gov.uk's Securing government email (opens in a new tab) guidance requires them to enforce DMARC on inbound email, so mail that fails DMARC is more likely to be held there
The warning is not a sign that anything is broken. RFC 9989 section 5.4 (opens in a new tab) says p=none must not change how receivers handle your mail, so your email flows as normal while you prepare the fix.
The safe fix: from none to quarantine and reject
It is tempting to change p=none to p=reject and make the warning disappear. If a genuine sender is not yet authenticated, that sender's mail would then be refused. The safe fix takes a little longer:
- If there is no record, publish v=DMARC1; p=none; rua=mailto:dmarc@yourdomain (or a reporting address from your DMARC platform) so the reports start
- Use the aggregate reports to list every service that sends as your domain, and fix SPF and DKIM for each genuine one until it passes with alignment
- Publish v=DMARC1; p=quarantine; t=y; rua=... to test, then remove t=y so quarantine applies. 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
- Once quarantine has run cleanly, move to p=reject where it suits the domain, and add sp and np policies for subdomains
- Keep reading the reports, so a new sender is spotted before its mail goes missing
The NCSC's phased plan says many organisations move on from none after about 6 to 8 weeks (opens in a new tab) and from quarantine to reject after about 3 months (opens in a new tab). RFC 9989 suggests domains whose users post to mailing lists should spend at least a month at none and as long again at quarantine before considering reject, and some of those domains settle at quarantine. Our DMARC policy guide explains which end state suits which kind of domain.
Is DMARC policy fix the right fit for you?
We will check it against your systems and requirements and recommend the right option.
The Google Workspace version of the warning
Google Workspace does not publish a DMARC record for you. Google's Set up DMARC (opens in a new tab) page explains that DMARC is a TXT record you add at your domain host, so domain scanners report a Workspace domain as "DMARC policy not enabled" until you add a record and move it beyond none.
Google's own recommended DMARC rollout (opens in a new tab) follows the same safe path:
- Set up DKIM and SPF at least 48 hours before you set up DMARC
- Start with p=none for one week, reviewing the daily reports to find any issues with your outgoing email or senders
- Then move to quarantine for a small share of messages and increase it over time, or use reject if required
Google's examples use the pct tag for that gradual increase. Under RFC 9989 pct is historic, so you may prefer t=y for testing; the step-by-step approach is the same. Third-party services that send as your Workspace domain, such as your CRM or newsletter platform, need their own SPF and DKIM set-up before you enforce. See DMARC for Google Workspace, or DMARC for Microsoft 365 if that is your platform.
Check your policy and fix it now
Start by looking at what is published today with the DMARC checker. When you are ready to change it, the DMARC generator builds a valid record at the policy you choose.
If you have changed the record and the scanner still shows the warning, work through these:
| Why the warning is still there | What to check |
|---|---|
| The old record is still cached | Resolvers keep the previous answer until its TTL expires. Wait for the TTL to pass, then check again |
| There are now two DMARC records | Receivers discard every record if more than one is found (RFC 9989 section 4.10 (opens in a new tab)), so the domain has no policy at all. Delete the old one |
| The record is at the wrong name | Some DNS hosts add your domain automatically, so entering the full name can create _dmarc.example.co.uk.example.co.uk. Enter just _dmarc |
| v=DMARC1 is not first | The whole record is ignored. Start it with v=DMARC1; |
| Test mode is on | p=quarantine with t=y asks receivers to apply none, so receivers that support RFC 9989 still treat the domain as monitoring. Remove t=y when testing is done |
| The scanner checks a different domain | Subdomains and other domains you own each need a policy, or an sp or np policy on the main domain |
Remember the NCSC's advice that every domain you own, including parked ones, should have a DMARC record. A domain that sends no email at all can go straight to p=reject, because there is no genuine mail to lose.
Help getting to enforcement safely
Clearing the warning properly means knowing every sender, and that is where a DMARC platform earns its keep. We can:
- Assess your domains: check the DMARC, SPF and DKIM records on every domain you own and explain what each scanner warning means
- Set up reporting: point your rua address at a platform that turns the daily reports into a list of named senders
- Choose and supply the platform: EasyDMARC, Valimail or the Check Point Email Security DMARC Management add-on, whichever suits your domains and team
- Move you to enforcement: work through each sending service with you and plan each policy step, at a pace that suits you
Licences can be billed monthly, with terms confirmed at quote. See DMARC management or contact us for free advice.
Frequently asked questions
Will enabling quarantine stop my email?
Not if your genuine senders pass DMARC first. Quarantine only affects messages that fail, and receivers typically deliver those to spam or junk rather than refusing them. That is why the safe fix starts with the reports: once every service that sends as you passes SPF or DKIM with alignment, quarantine affects only spoofed mail.
How long should I stay at p=none?
Long enough to see every sender in your reports. Google suggests at least a week, the NCSC (opens in a new tab) says many organisations move on after about 6 to 8 weeks, and RFC 9989 suggests at least a month for domains whose users post to mailing lists. If you send some mail only monthly or quarterly, wait until those runs have appeared in the reports.
Why does my scanner still say "not enabled" after I changed it?
Usually because the old record is still cached until its TTL expires, or because there are now two DMARC records (receivers then ignore both). Also check that the record name is just _dmarc at your DNS host, that it starts with v=DMARC1, and that t=y is not still set. Run the domain through our DMARC checker to see what is live.
Is "DMARC policy not enabled" a security breach?
No. It is a configuration finding, not evidence that anything has happened. It means receivers have no instruction from you to stop mail that pretends to be from your domain. Your aggregate reports show whether anyone is actually doing that.
Do I need to fix it on domains that don't send email?
Yes, and those are the easiest to fix. The NCSC says all your domains, including parked ones, should have DMARC records. With no genuine mail to protect, a parked domain can publish v=DMARC1; p=reject; sp=reject straight away, ideally with a rua address so you can see any spoofing attempts.
Still have a question about DMARC policy fix?
Ask us and a member of our team will get back to you.