In short
"DMARC policy not enabled" means a scanner found no DMARC record for your domain, or one set to p=none, which only monitors. Spoofed mail using your exact domain can still be delivered. Fix it by publishing DMARC with a reporting address, making every legitimate sender pass SPF or DKIM with alignment, then moving to p=quarantine and p=reject.
Get a quote for DMARC policy fixes
Tell us roughly how many users or sites you have and we will reply by email with options and a quote.
What the warning means
Scanners word it differently ("DMARC policy not enabled", "DMARC quarantine/reject policy not enabled", "DMARC not enforced"), but they are all checking the TXT record at _dmarc.yourdomain and reading the p= value:
| What the scanner finds | What it means | Usual result |
|---|---|---|
| No DMARC record | Receivers get no instruction and you get no reports | Flagged: DMARC missing or not enabled |
| p=none | Monitoring only; receivers are asked to take no action on failures | Flagged: quarantine or reject policy not enabled |
| p=quarantine | Failing mail should be treated as suspicious, usually sent to junk | Often accepted; some checks look for reject |
| p=reject | Failing mail should be refused | Passes |
| A record with a syntax error, or two records | Receivers may ignore it | Flagged as invalid or missing |
The warning can turn up in external vulnerability scans and security ratings, cyber insurance and supplier security questionnaires, and domain checks such as the NCSC's free Check your cyber security service, which looks at email anti-spoofing. It is about your domain's DNS, not about your mailboxes or your email security product.
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 p=none is flagged
A p=none policy is a sensible place to start: it costs nothing, breaks nothing and gets you reports. Microsoft describes it as the value for testing and tuning a DMARC policy. The problem is staying there. Under p=none, a criminal can still send a fake invoice that shows your exact domain in the From address, and receivers are asked to treat it no differently.
Many organisations stop at p=none because it satisfies the Google bulk sender guidelines and the matching Outlook.com and Yahoo rules, which only ask for a record with at least p=none. That makes the mail deliverable; it does not protect your domain. Protection starts at quarantine and is strongest at reject. Our guides to email spoofing and invoice fraud show what that protection is for, and our sister site's DMARC guide explains the record in full.
Check every sender before you enforce
Moving to quarantine or reject is safe only when every legitimate service sending as your domain passes SPF or DKIM with alignment to your From domain. The services that get missed are rarely the main mail platform:
| Sender type | Examples | Usual fix |
|---|---|---|
| Main mail platform | Microsoft 365, Google Workspace | SPF include plus DKIM signing with your own domain |
| Marketing and CRM | Newsletter tools, CRM sequences, event platforms | The platform's domain authentication: DKIM for your domain, often on a subdomain |
| Finance and HR | Invoicing, accounts, payroll and e-signature services | DKIM for your domain, or send from a subdomain |
| Support and web | Helpdesk, website contact forms, booking systems | DKIM where offered; otherwise SPF with a custom return-path |
| Devices and on-premises | Scanners, line-of-business apps, on-premises servers | Relay through Microsoft 365 or Google Workspace, or add the IP to SPF |
| Gateways and forwarders | Outbound gateways, mailing lists | SPF for the gateway; check DKIM survives any changes |
DMARC aggregate (rua) reports are how you find them: they list every source sending as your domain and whether it passed. A reporting tool turns the XML into a readable list, and the NCSC lists choosing one as the first step of its plan. If your reports used to go to the NCSC's Mail Check service, note that it was retired on 31 March 2026, so check where your rua address points.
Is DMARC policy fixes the right fit for you?
We will check it against your systems and requirements and recommend the right option.
The safe path from none to quarantine to reject
A careful rollout looks like this, shown with example records for example.co.uk:
- Publish p=none with a reporting address: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk. Google recommends setting up SPF and DKIM at least 48 hours first.
- Collect and read the reports. Google suggests at least a week at none, reviewing reports daily; complex organisations usually need longer to find every sender.
- Fix each legitimate sender until it passes SPF or DKIM with alignment, and decide what to do about anything you do not recognise.
- Move to quarantine: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.co.uk. Watch the reports for anything legitimate that still fails.
- Move to reject: v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.co.uk.
- Cover subdomains and parked domains. Subdomains inherit the main policy unless they have their own record or an sp= tag says otherwise. Domains that send no mail can go straight to v=DMARC1; p=reject; with an SPF record of v=spf1 -all.
- Keep watching. New services, staff changes and supplier switches can quietly break authentication after you reach reject.
A note on pct and the 2026 standard
Google's and Microsoft's help pages still show the pct= tag for applying a policy to a percentage of failing mail. In May 2026 the IETF published RFC 9989, the updated DMARC standard, which replaces RFC 7489, retires pct because receivers applied it inconsistently, and adds a t=y testing flag that asks receivers to apply one level less than your stated policy. It also adds an np= tag for subdomains that do not exist. Receivers that follow the new standard may ignore pct, so do not rely on it as a safety net: the reports are your safety net.
Fixing the warning in Microsoft 365
Microsoft 365 has no admin page for DMARC records on custom domains: you publish them at your DNS host. The Microsoft-specific steps are:
- Turn on DKIM for each custom domain in the Defender portal (Email authentication settings, DKIM tab), because Microsoft 365 does not sign with your custom domain until you do. Our DKIM guide has the steps.
- Check SPF includes spf.protection.outlook.com and every other sender; see our SPF record guide.
- Add DMARC for the onmicrosoft.com domain in the Microsoft 365 admin center under Settings, Domains. Microsoft's instructions use the record v=DMARC1; p=reject, with optional reporting addresses.
- Expect aggregate reports only. Microsoft 365 sends DMARC aggregate reports (when your MX points directly to it) but not forensic reports.
Once you enforce, Microsoft routes outbound mail that fails DMARC through its high-risk delivery pool, another reason to fix every sender first. For mail coming in, the anti-phishing policy's Honor DMARC record policy setting decides how Microsoft 365 treats other domains' failures; our Microsoft 365 phishing protection guide covers it.
Fixing the warning in Google Workspace
In Google Workspace the DMARC record also lives at your DNS host, as a TXT record at _dmarc. Before you publish it:
- Turn on DKIM in the Admin console under Apps, Google Workspace, Gmail, Authenticate email, ideally with a 2,048-bit key, and click Start authentication.
- Check SPF includes _spf.google.com and every other sender.
- Wait 48 hours after setting up SPF and DKIM before publishing DMARC, as Google advises.
Google's recommended rollout is a week at none, reviewing reports daily, then quarantine. Our Google Workspace email security hub and Gmail security settings guide cover the rest of the Admin console.
Tools that get you to reject
The record is easy; the sender detective work is the hard part, and it is where projects tend to stall at p=none. These options do that work in a console instead of a spreadsheet:
| Option | Best fit | Read more |
|---|---|---|
| Valimail Core or Pro | Many senders or domains; hosted SPF that avoids the lookup limit | Valimail |
| IRONSCALES DMARC | Guided enforcement from p=none to p=reject, with hosted records; fits IRONSCALES email security customers | IRONSCALES DMARC |
| Sophos DMARC Manager | Sophos Email customers; included in Sophos Email Plus | Sophos DMARC Manager |
| Check Point DMARC Management | Check Point Email Security customers | DMARC Management |
For a single domain that only sends from Microsoft 365 or Google Workspace, a careful set of records and a free report viewer can be enough. Our email authentication hub compares the options in more detail.
How we help
Forever Systems can clear the warning properly: we audit your domains, connect DMARC reporting, find and fix every sender, then move each domain through quarantine to reject at a pace your reports support, with parked domains locked down along the way. We can also give you a short written summary for your insurer or customer once enforcement is in place. Licence costs for any hosted tool depend on the number of domains: ask us for a quote. Contact us to fix the warning without blocking your own mail.
How Forever Systems helps with email security
We are an independent UK IT and cyber security provider. We supply several email security platforms, so we can suggest what suits your mail system, your risks and your budget rather than pushing one product.
- Start with what you have: we can review the protection already built into Microsoft 365 or Google Workspace before suggesting anything extra
- Compare like for like: API-based protection, secure email gateways, encryption and DLP from the vendors we supply, explained in plain English
- Get authentication right: we help you plan SPF, DKIM, DMARC and MTA-STS so genuine mail is delivered and spoofed mail is not
- Deployment help: connecting a platform to Microsoft 365 or Google Workspace, mail routing changes and policy set-up, scoped at quote
- People and backup too: security awareness training, Check Point Harmony Email & Collaboration and Sophos from our specialist sites
Tell us about your mail system and we will suggest options, with pricing confirmed at quote.
Frequently asked questions
What does 'DMARC policy not enabled' mean?
It means your domain either has no DMARC record or has one set to p=none, which only monitors. Receivers are given no instruction to quarantine or reject mail that fails authentication, so criminals can still send messages that show your exact domain in the From address.
How do I fix 'DMARC quarantine/reject policy not enabled'?
Publish DMARC at p=none with a reporting address, use the reports to make every legitimate sender pass SPF or DKIM aligned with your domain, then change the policy to p=quarantine and finally p=reject. Moving straight to reject without checking senders risks blocking your own mail.
Is a DMARC policy of p=none bad?
No, it is the right starting point because it gives you reports without affecting delivery. It only becomes a problem if you stay there, because p=none takes no action against spoofed mail.
How long should I stay at p=none?
Long enough to see and fix every service that sends as your domain. Google suggests at least a week of daily report reviews; organisations with many sending platforms may need longer.
Will p=reject stop my own emails being delivered?
Only mail from services that fail SPF and DKIM alignment, which is why you fix every legitimate sender first and step through quarantine. If you prepare with the reports, legitimate mail keeps flowing.
How do I fix 'DMARC policy not enabled' in Office 365?
Turn on DKIM for each custom domain in the Microsoft Defender portal, check your SPF record, then publish a DMARC TXT record at your DNS host and step it from p=none to quarantine and reject. Add a DMARC record for your onmicrosoft.com domain in the Microsoft 365 admin center too.
Still have a question about DMARC policy fixes?
Ask us and a member of our team will reply by email.