If you’re seeing “DMARC quarantine/reject policy not enabled” or a bounce reading 554 5.7.5 permanent error evaluating DMARC policy, those are two very different problems. The first is a warning from a security scanner telling you your DMARC record exists but isn’t enforcing anything. The second is a rejection — a receiving server refused your message because your domain’s DMARC policy told it to. One is advice you can plan around; the other is mail not being delivered right now.
This guide covers both, plus how to read a DMARC failure and what actually causes legitimate mail to fail authentication. It also reflects the 2026 DMARC specification (RFC 9989), which changed several things most guides on this topic haven’t caught up with.
| “Quarantine/reject policy not enabled” | Your record has p=none. It’s monitoring only. Nothing is being blocked — and nothing is being protected either |
| 554 5.7.5 evaluating DMARC policy | A receiver rejected your message. Either your SPF/DKIM alignment is broken, or your record has a syntax error |
| DMARC fail on legitimate mail | Almost always alignment, not authentication. SPF or DKIM passes, but for the wrong domain |
Table of Contents
What a DMARC failure actually means
DMARC doesn’t authenticate anything by itself. It sits on top of SPF and DKIM and asks a single question: does the domain that passed authentication match the domain the recipient sees in the From field?
That matching requirement is called alignment, and it’s where nearly every confusing DMARC failure comes from. A message can have a perfectly valid SPF pass and still fail DMARC, because the SPF passed for a different domain than the one in the From header.
DMARC passes if either SPF or DKIM passes and is aligned. Both failing means DMARC fails, and the receiver then applies whatever policy your record specifies.
| Situation | DMARC result |
|---|---|
| SPF passes, aligned | Pass |
| DKIM passes, aligned | Pass |
| SPF passes, not aligned | Fail — this is the confusing one |
| Both fail, or both misaligned | Fail — policy applies |
“DMARC quarantine/reject policy not enabled”
This message comes from a security scanner or a compliance tool, not from a mail server. It means your DMARC record exists but has p=none, which tells receivers: check my mail, report back, but take no action either way.
So nothing is being blocked — including messages that are forging your domain. Monitoring mode is the correct starting point, but staying there indefinitely means you get the reports without the protection.
Your record probably looks like this:
v=DMARC1; p=none; rua=mailto:reports@yourdomain.com
To enforce, change p=none to p=quarantine (failing mail goes to spam) or p=reject (failing mail is refused outright).
Moving to p=reject before confirming that all your legitimate senders pass alignment is how organizations block their own invoices, newsletters and CRM notifications. Sit at p=none long enough to read the aggregate reports — at least a month — identify every service sending on your behalf, and only then tighten. The scanner flagging you isn’t an emergency; sending your own mail to nowhere is.
Error 554 5.7.5: permanent error evaluating DMARC policy
This one is a delivery failure, and it means a receiving server evaluated your DMARC policy and refused the message. Unlike the previous warning, mail is not arriving.
Note the distinction from a temporary rejection: a 554 is permanent, so the message bounces immediately. A 4xx rejection would keep it in your server’s queue for retries instead — our guide on emails stuck in the queue covers how to read the deferral reason when that happens.
Three things cause it:
1. Your mail genuinely fails alignment
The most common case. Your domain publishes p=reject, and a message was sent through a service that isn’t aligned — a marketing platform, a CRM, a form on your website, an invoicing tool. The receiver did exactly what you asked it to do.
Check the full bounce message: it usually names the sending IP and the domain that failed. That tells you which service is misconfigured.
2. Your DMARC record has a syntax error
A malformed record can produce a permanent evaluation error rather than a simple pass or fail. Common mistakes:
- Missing semicolons between tags, or a semicolon after the last one
v=DMARC1not being the first tag — it must come first- Two DMARC records published on the same
_dmarchostname - The record published at the wrong hostname — it must be
_dmarc.yourdomain.com, not the root domain - A
ruaaddress on a different domain without the corresponding authorization record
3. You’re not the one at fault
If you’re receiving this bounce when replying to someone, or forwarding mail, the failing domain may not be yours. Forwarding breaks SPF alignment by design, and mailing lists rewrite headers in ways that break DKIM. Read the bounce carefully to see whose domain is being evaluated.
Why legitimate mail fails DMARC
Almost always alignment, and almost always one of these five:
| Cause | Fix |
|---|---|
| A third-party service sends as your domain — CRM, newsletter, invoicing, helpdesk | Add it to your SPF record and set up DKIM signing with your domain in that service |
| Forwarding — the message is relayed to another address | Nothing you can fix at the sending end. DKIM survives forwarding better than SPF, so make sure DKIM is configured |
| Mailing lists — they rewrite headers and break DKIM signatures | A known limitation. It’s one reason the 2026 spec discourages p=reject for domains whose users post to lists |
| Your website sends mail via PHP without SMTP authentication | Configure the site to send through your mail server with proper credentials |
| SPF record broken or over the lookup limit | SPF allows a maximum of 10 DNS lookups. Beyond that it returns permerror, and DMARC fails with it |
The SPF lookup limit deserves attention, because it’s silent: adding services one at a time eventually crosses the threshold, and everything that was working starts failing at once.
How to diagnose a DMARC failure
1. Read the message headers. In Gmail, open the message and choose “Show original”. Look for the Authentication-Results line, which reports SPF, DKIM and DMARC individually, along with the domain each one evaluated. If SPF says pass but for a domain other than yours, you’ve found the alignment problem.
2. Check your records from outside. Tools like MXToolbox query your DNS as a receiver would, and flag syntax problems. Confirm the record is at _dmarc.yourdomain.com and that only one exists. Our guide on DNS TXT lookups covers the commands for checking SPF, DKIM and DMARC — including how to find your DKIM selector, which you need before you can query it.
3. Read your aggregate reports. If your record includes a rua address, receivers send you daily XML reports listing every IP that sent mail claiming to be your domain, and whether it passed. Raw XML is hard to read — a report parser makes it usable, and it’s the only way to see the full picture of who sends on your behalf.
What changed in DMARC in 2026
Worth knowing, because most guides on this topic still describe the 2015 specification.
In May 2026 the IETF published RFC 9989, replacing RFC 7489 and making DMARC a Proposed Standard rather than an Informational document. Two companion documents cover reporting: RFC 9990 (aggregate) and RFC 9991 (failure).
| Change | What it means |
|---|---|
pct, rf and ri removed | Remove them at your next DNS edit. Unknown tags are ignored, so nothing breaks meanwhile |
New t tag replaces pct | t=y means testing — a stated policy is applied one step softer. t=n is the default and enforces normally |
New np tag | Sets a policy for non-existent subdomains. np=reject blocks spoofing from subdomains you never created |
| Public Suffix List replaced by DNS Tree Walk | Changes how receivers find the relevant record. Nothing for you to configure |
Guidance on p=reject reversed | Now discouraged for domains hosting general user mailboxes, because of mailing lists and forwarding |
That last one is a genuine reversal. For years the standard advice was to work towards p=reject as the goal. The current guidance is more nuanced: reject suits domains that send only transactional and marketing mail from controlled sources, while domains where people have ordinary mailboxes — and post to mailing lists, and forward messages — are better served by p=quarantine.
Setting up DMARC correctly
DMARC is a TXT record at _dmarc.yourdomain.com. In cPanel, add it under Zone Editor. A sensible starting record:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Then, once reports confirm your legitimate senders all pass:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; np=reject
The order matters: SPF and DKIM must be correct before DMARC enforces anything. A strict policy on top of a broken SPF record rejects your own mail. Our guide on what an email domain is covers how the three records fit together, and the email migration guide explains why these records are the most common casualty of a host change.
Copahost email hosting configures SPF and DKIM automatically when you create an account, and the DNS Zone Editor lets you add or adjust DMARC yourself. Full IMAP, POP3 and SMTP support, unlimited mailboxes at your domain, and support that reads the headers with you when mail doesn’t arrive.
See hosting plans with emailFrequently asked questions
What does “DMARC quarantine/reject policy not enabled” mean?
It means your domain has a DMARC record but it’s set to p=none, which only monitors. Receivers report on failures but take no action, so messages forging your domain are still delivered. Moving to p=quarantine or p=reject enables enforcement — but only after confirming your legitimate senders pass alignment.
What causes the error 554 5.7.5 permanent error evaluating DMARC policy?
A receiving server evaluated your domain’s DMARC policy and rejected the message. Either the mail genuinely failed alignment — sent through a service not covered by your SPF or DKIM — or your DMARC record has a syntax error that prevents proper evaluation. Check the full bounce message, which usually names the sending IP and the failing domain.
Why does my email fail DMARC when SPF passes?
Because of alignment. DMARC requires that the domain which passed SPF matches the domain in the From header. A sending service can produce a valid SPF pass for its own domain while your From address shows yours, and DMARC treats that as a failure. Setting up DKIM signing with your domain in that service is the usual fix.
Should I set my DMARC policy to reject?
Not necessarily. The 2026 specification actually discourages p=reject for domains that host general user mailboxes, because forwarding and mailing lists break alignment for legitimate mail. Reject suits domains sending only from controlled sources; for ordinary business mailboxes, p=quarantine is often the better setting.
What changed in DMARC in 2026?
RFC 9989 replaced RFC 7489 in May 2026, making DMARC a Proposed Standard. The pct, rf and ri tags were removed, three new tags were added (t, np, psd), the Public Suffix List was replaced by a DNS Tree Walk, and the guidance on p=reject was reversed for domains with general user mailboxes. Existing records remain valid and still use v=DMARC1.
Where do I publish the DMARC record?
As a TXT record at _dmarc.yourdomain.com — not at the root domain. In cPanel, add it through the Zone Editor. Only one DMARC record should exist for a domain; two published records cause evaluation errors.
Does forwarding break DMARC?
It breaks SPF alignment, because the forwarding server becomes the sender while the From address stays the same. DKIM survives forwarding better, since the signature travels with the message, which is why having DKIM configured matters more than SPF alone if your domain enforces a policy.
How long should I stay at p=none before enforcing?
At least a month, and long enough to see aggregate reports covering all your sending sources — including services that only send occasionally, like annual invoicing or seasonal campaigns. Enforcing before you’ve identified every legitimate sender is how organizations block their own mail.
Conclusion
The two messages that bring people here mean opposite things: “quarantine/reject policy not enabled” is a scanner telling you your DMARC isn’t protecting anything, while 554 5.7.5 is a receiver telling you it’s protecting a bit too enthusiastically. Between them sits the concept that explains nearly every DMARC problem — alignment, the requirement that whatever passed authentication belongs to the same domain the recipient sees. Get SPF and DKIM aligned for every service that sends on your behalf, read your aggregate reports for a month before tightening, and remember that the current guidance no longer treats p=reject as the destination for every domain.
