Email error

Cause · impact · fix

dmarc=none

A receiver reports dmarc=none when it finds no enforcing DMARC policy for your From domain: either you publish no DMARC record, or the one you publish is set to p=none. Here is why it appears, what it costs you, and how to fix it.

What it means

The cause.

dmarc=none is a result the receiving server writes into the Authentication-Results header after it evaluates DMARC. The method is dmarc and the result value is none, which the specification defines as: no DMARC policy record was published for the aligned identifier, or no aligned identifier could be extracted. In plain terms, the receiver looked up _dmarc.yourdomain and found nothing it can enforce.

There are two ways to land on none. The first is that you have no DMARC record at all — nothing published at _dmarc.yourdomain — so the receiver has no policy to apply. The second is that you do have a record but its policy is p=none, the monitoring-only setting, which explicitly tells receivers to take no action on messages that fail. Either way the reported disposition is none.

This is a result, not a failure. dmarc=none is different from dmarc=fail: fail means a DMARC record exists and the message did not authenticate or align against it. none means there was no policy to test against in the first place. So dmarc=none never blocks the individual message on its own — but it tells you your domain has no DMARC protection in force.

Why it matters

The impact.

With no enforcing policy, nothing stops another sender from forging your From address, and receivers get no instruction on what to do with mail that fails as you. On its own that is a spoofing exposure. But the sharper cost is the bulk-sender rules: since 2024 Gmail and Yahoo require any domain sending in volume to personal accounts to publish a DMARC record with at least p=none for the From domain. If dmarc=none means you have no record at all, you are failing that requirement, and receivers can throttle, spam-folder or reject your mail regardless of how any single message authenticates.

If dmarc=none instead reflects an existing p=none policy, you satisfy the minimum requirement and legitimate mail keeps flowing — but you gain no protection and no enforcement. Messages that fail SPF and DKIM in your name are not quarantined, so spoofed and phishing mail carrying your domain can still reach inboxes, and receivers that treat unauthenticated mail as suspicious may still route it to spam.

What to do

The fix, in order.

Work top to bottom, then re-check — DNS changes take a few minutes to take effect.

  1. 1 Confirm which case you are in. Run your domain through the DMARC checker. It tells you whether a record exists at all and, if one does, whether the policy is p=none or something stronger. That decides everything below: publish a record, or tighten the one you have.
  2. 2 Publish a DMARC record if you have none. Add a single TXT record at the host _dmarc with the value v=DMARC1; p=none; rua=mailto:[email protected]. This meets the Gmail and Yahoo bulk-sender requirement and, via the rua address, starts sending you aggregate reports showing every source using your domain.
  3. 3 Get SPF and DKIM passing and aligned first. Before you enforce, make sure your legitimate mail authenticates. DMARC passes only when SPF or DKIM passes and its domain aligns with your From: domain. Check every sending service — your mail platform, CRM, newsletter and helpdesk tools — is covered, or tightening the policy will bounce your own mail.
  4. 4 Read your aggregate reports for a few weeks. The rua reports arrive as daily XML from each receiver. Use them to build a complete picture of who sends as you and confirm your real senders all pass and align. Do not skip this: it is how you avoid blocking legitimate mail when you move off none.
  5. 5 Raise the policy to quarantine, then reject. Once your legitimate sources authenticate cleanly, change p=none to p=quarantine, watch the reports, then move to p=reject. This is what actually stops spoofing — p=none only monitors. Step up gradually so any missed sender surfaces before it hits enforcement.
  6. 6 Re-check after DNS propagates. DNS changes take a few minutes to spread. Run the DMARC checker again to confirm the record is live and the policy reads as you intend before you rely on it.

Starter DMARC record (monitoring mode)

host  _dmarc type  TXT
v=DMARC1; p=none; rua=mailto:[email protected]

Confirm the error is gone.

Run a full check on your domain — it reads SPF, DKIM and DMARC live and tells you, in plain terms, whether the thing behind this error is fixed. Free, no account.

Common questions

About this error.

What does dmarc=none mean? It is the DMARC result a receiver records in the Authentication-Results header when it finds no enforcing policy for your From domain. That happens either because you publish no DMARC record at all, or because the record you publish is set to p=none, which tells receivers to take no action.
Is dmarc=none a failure? No. It means there was no policy to enforce, not that your message failed authentication. That is different from dmarc=fail, which means a DMARC record exists and the message did not pass or align against it. dmarc=none does not block the individual message, but it does mean your domain has no DMARC protection in force.
How do I fix dmarc=none? If you have no record, publish a TXT record at _dmarc with v=DMARC1; p=none; rua=mailto:[email protected] to meet the bulk-sender minimum and start reporting. If you already have p=none, get SPF and DKIM passing and aligned, review your aggregate reports, then raise the policy to p=quarantine and then p=reject.
Does dmarc=none mean I have no DMARC record? Not necessarily. It can mean either no record exists, or a record exists with the monitoring policy p=none. Check with a DMARC lookup: if there is genuinely no TXT record at _dmarc.yourdomain, you need to publish one; if p=none is present, you need to strengthen it.
Is p=none good enough for Gmail and Yahoo? It meets the minimum. Since 2024 Gmail and Yahoo require bulk senders to publish a DMARC record with at least p=none, so a record set to p=none satisfies that rule and keeps your mail flowing. It gives no protection against spoofing, though — only p=quarantine or p=reject enforce, so treat p=none as a starting point, not the destination.
Should I move from p=none to reject straight away? No. Stay on p=none long enough to collect aggregate reports and confirm every legitimate sender passes SPF or DKIM and aligns with your From domain. Jumping to p=reject before that will quarantine or bounce your own mail. Step up through p=quarantine first, watching the reports at each stage.