# DMARC policy: moving from p=none to quarantine and reject

> Your DMARC policy decides what happens to mail that forges your domain. What none, quarantine and reject do, how to fix "DMARC policy not enabled", and a safe path to p=reject.

Updated 2026-09-26 · Security · HTML version: https://getreport.app/guides/dmarc-policy-none-quarantine-reject

A DMARC policy is the `p=` tag in your DMARC record, and it tells receiving servers what to do with mail that uses your domain but fails authentication: `p=none` delivers it and only reports, `p=quarantine` sends it to spam, and `p=reject` refuses it. Only quarantine and reject protect your domain, which is why scanners flag `p=none` as "DMARC quarantine/reject policy not enabled". The fix is to move up in steps, once your reports show every real sender passing.

This guide is for anyone who already has a DMARC record, or has just been told by a scanner or a security questionnaire that theirs is not enforced. It covers what each policy does, the alignment rule behind most failures, and a rollout plan that does not lose real mail. If you have no DMARC record yet, start with [what DMARC is and your first record](https://getreport.app/guides/what-is-dmarc); the [SPF, DKIM and DMARC setup guide](https://getreport.app/guides/spf-dkim-dmarc-email-authentication) is the map of the whole topic.

## Quick answer

- **`p=none`:** monitor only. Failing mail is delivered; you get reports.
- **`p=quarantine`:** failing mail goes to spam (or is held, depending on the receiver).
- **`p=reject`:** failing mail is refused during delivery and never reaches the recipient.
- **"DMARC policy not enabled"** means your record uses `p=none`. It is not an error; it is a reminder that monitoring protects nobody.
- **The path:** 2 to 4 weeks at `p=none` reading reports, fix every failing real sender, then `p=quarantine`, then `p=reject` a few weeks later.
- **Most failures are alignment problems:** a service passes SPF or DKIM for its own domain, not yours.

## What the three DMARC policies do

| Policy | What receivers do with failing mail | Protects you? | Use it when |
| --- | --- | --- | --- |
| `p=none` | Deliver as normal, include it in reports | No | You are finding all your senders |
| `p=quarantine` | Treat as suspicious: usually the spam folder | Mostly | Every known sender passes, and you want a safety margin |
| `p=reject` | Refuse the message during delivery | Yes | Reports have been clean for several weeks |

The policy only affects mail that **fails** DMARC. Mail that passes SPF or DKIM with alignment is delivered as normal under any policy, so a correct setup loses nothing when you tighten it.

Receivers treat the policy as a strong request, not an order, and each applies its own judgement. Gmail, for example, refuses mail that fails a `p=reject` policy with the bounce `550 5.7.26`, and sends mail failing `p=quarantine` to spam.

## "DMARC quarantine/reject policy not enabled": what it means

Security scanners, email checkers and vendor security questionnaires report "DMARC quarantine/reject policy not enabled", or just "DMARC policy not enabled", when your record exists but uses `p=none`. Your domain is set up for monitoring, and anyone can still send mail that looks like yours.

It is not a misconfiguration, and nothing is broken. It is the right place to *start*, and the wrong place to stay. The fix is to change `p=none` to `p=quarantine` and later to `p=reject`, but only after the checks below, because a jump that catches a real sender means invoices, password resets or order confirmations go missing.

> **Check: DMARC policy.** p=none only collects reports; receivers still deliver mail that fails. Quarantine sends it to spam and reject refuses it, which is what actually protects your name.
>
> 1. Read the DMARC reports until every real sender passes, then set p=quarantine, and p=reject a few weeks later.
> 2. To move in steps, add t=y while on quarantine: receivers then apply one level softer (none) until you remove it. The old pct tag was dropped in RFC 9989 (May 2026).

## DMARC alignment: why real mail fails

A message passes DMARC when SPF or DKIM passes **and** the domain it checked matches the domain in the From line. That match is called alignment:

- **SPF alignment:** the envelope sender domain (the `Return-Path`) matches the From domain.
- **DKIM alignment:** the `d=` domain in the DKIM signature matches the From domain.

By default, alignment is **relaxed**: `mail.example.com` aligns with `example.com`, because they share an organisational domain. Setting `aspf=s` or `adkim=s` demands an exact match; leave those out unless you have a specific reason.

Real mail usually fails DMARC because a service passes authentication, but for its own domain:

| What the headers show | What it means | Fix |
| --- | --- | --- |
| `spf=pass` for `bounces.sendservice.example`, From is `example.com` | SPF passed for the service, not for you | Set up the service's custom domain authentication (DKIM, and a custom bounce domain if offered) |
| `dkim=pass` with `d=sendservice.example` | DKIM signed with the service's key | Publish the service's DKIM records for your domain and switch signing on |
| `dkim=pass` with `d=yourtenant.onmicrosoft.com` | Microsoft 365 without custom-domain DKIM | Enable DKIM for your domain in the Defender portal |
| `spf=fail`, `dkim=pass` with your domain | Forwarded mail | Nothing: DKIM is aligned, so DMARC passes |

DKIM with your own domain is the most reliable way to align, because it survives forwarding. The [DKIM guide](https://getreport.app/guides/what-is-dkim) shows how to find which domain a service signs with.

## Before you move up: a checklist

Work through this before each step:

1. **At least two weeks of reports** at your current policy, better four. Monthly senders (invoicing runs, newsletters) need a full cycle to show up.
2. **Every sending IP in the reports is accounted for.** Each one is either your service, passing with alignment, or something you have decided is not yours.
3. **Every real service passes DKIM with your domain,** not only SPF. SPF-only senders fail as soon as a message is forwarded.
4. **Subdomains are covered.** If `news.example.com` or `mail.example.com` send mail, they appear in the same reports; check them too.
5. **Someone reads the reports after the change.** The first week after a policy change is when a forgotten sender shows up.

## A safe path from p=none to p=reject

**Step 1: monitor (2–4 weeks).**

```dns
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
```

**Step 2 (optional): quarantine in test mode.** RFC 9989, published in May 2026, added the `t=y` flag. It asks receivers to apply one level softer than your policy, so `p=quarantine; t=y` is handled like `p=none` by receivers that support it. Some receivers use it to try out special handling, such as rewriting the From address on mailing-list mail.

```dns
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com"
```

**Step 3: quarantine (2–4 weeks).** Remove `t=y`. Failing mail now goes to spam, where a missed real message can still be found.

```dns
_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com"
```

**Step 4: reject.** Forged mail is now refused.

```dns
_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
```

Keep `rua` at every step. The reports are how you notice a new service someone in your company signed up for next year.

> **Note:**
> The old `pct` tag, which applied the policy to a percentage of failing mail (`pct=25`), was removed in RFC 9989 because receivers applied it inconsistently. If you still have `pct=100` in your record, it is harmless. Do not rely on `t=y` as a safety net either: a receiver that does not support it simply applies your policy as written. The reports are the real safety net.

## Quarantine vs reject

`p=quarantine` is a resting place, not a failure. It is a reasonable long-term setting when a few low-volume senders are still hard to fix, or when losing a message outright is worse than losing it to a spam folder.

`p=reject` is the goal:

- Forged mail never reaches the recipient, not even their spam folder, where people still click things.
- It is required, together with `p=quarantine`, for [BIMI](https://getreport.app/guides/what-is-bimi), which shows your logo in supporting inboxes.
- Rejection happens during delivery, so the sender of a real but misconfigured message gets a bounce and knows something is wrong. With quarantine, nobody is told.

If you are unsure, go to quarantine first, leave it for a month, and move to reject when the reports show nothing new.

## Subdomains: sp and np

Your policy applies to subdomains too, unless you say otherwise:

- `sp=` sets a separate policy for existing subdomains. `v=DMARC1; p=reject; sp=quarantine` rejects forgeries of the main domain while being more forgiving with `shop.example.com`.
- `np=` (new in RFC 9989) sets a policy for subdomains that **do not exist** in DNS. Forgers like invented names such as `billing.example.com`; `np=reject` refuses them even while your main policy is still moving up.

A subdomain with its own `_dmarc` record uses that record instead.

## Parked domains: go straight to reject

A domain that never sends email has nothing to monitor. Publish reject at once, with an SPF record that allows no one:

```dns
_dmarc.parked-example.com.  TXT  "v=DMARC1; p=reject"
parked-example.com.         TXT  "v=spf1 -all"
```

## How to check your DMARC policy

> **Free tool:** [DMARC, SPF, DKIM and MX record checker](https://getreport.app/tools/email-dns-check): Free DMARC checker that also tests SPF, DKIM and MX. See what is missing or broken and get the exact DNS records to add. No sign-up, results in seconds.

The email and DNS health check reads your record, names the policy and lists its tags. `p=none` shows as a warning with the next step; quarantine and reject pass. It also flags two DMARC records, an unknown policy value and a missing report address.

> **Check: DMARC reports.** The aggregate reports (rua) are how you find every service that sends as your domain before you tighten the policy. Without them you are guessing.
>
> 1. Add rua=mailto:dmarc@yourdomain (or the address of a free DMARC report reader) to the DMARC record.

After each change, send a test message to a Gmail address and choose **Show original**. `DMARC: PASS` confirms your own mail still passes under the new policy.

## If something breaks

If a real sender starts bouncing after you move to reject, step back to `p=quarantine` (a single edit, effective as soon as the TTL runs out), fix the sender's DKIM, and move up again. DMARC records usually have a TTL of an hour; lowering it to 5 minutes a day before a change makes a rollback faster.

## Questions people ask

### What is a DMARC policy?

A DMARC policy is the `p=` value in your DMARC record, telling receivers what to do with mail that uses your domain but fails SPF and DKIM alignment. `none` delivers it and only reports, `quarantine` sends it to spam, and `reject` refuses it. Only quarantine and reject protect your domain from being forged, so none is a starting point, not a destination.

### How do I fix "DMARC policy not enabled"?

Change the policy in your `_dmarc` TXT record from `p=none` to `p=quarantine`, and later to `p=reject`. Before you do, read at least two weeks of DMARC reports and make sure every service that sends as your domain passes DKIM or SPF with alignment. Otherwise the stricter policy sends your own mail to spam or bounces it.

### Should I use p=quarantine or p=reject?

Aim for `p=reject`: forged mail is refused and never reaches a spam folder where someone might open it. Use `p=quarantine` as the step before it, for two to four weeks, or longer if a few legitimate senders are still hard to fix. Both policies satisfy BIMI and count as enforcement for security scanners.

### How long should I stay on p=none?

Two to four weeks is usually enough, as long as the period covers every kind of mail you send, including monthly invoices or newsletters. Stay longer only while reports still show real services failing. Staying on `p=none` for years is common and protects nobody; the reports have told you what you need well before that.

### What is DMARC alignment?

Alignment means the domain SPF or DKIM checked matches the domain in the From line. SPF aligns when the bounce domain matches; DKIM aligns when the signature's `d=` domain matches. By default the match is relaxed, so subdomains count. A message passes DMARC only when at least one of them passes and aligns.

### What happened to the pct tag in DMARC?

RFC 9989, which replaced RFC 7489 in May 2026, removed `pct` because receivers applied partial percentages inconsistently. Its replacement for gradual rollout is `t=y`, a testing flag that asks receivers to apply one level softer than your policy. A leftover `pct=100` in your record is harmless, since receivers ignore tags they do not know.

### What is the np tag in a DMARC record?

The `np` tag, added in RFC 9989, sets the policy for subdomains that do not exist in DNS, such as an invented `billing.example.com`. Without it, those fall back to `sp` and then `p`. Setting `np=reject` stops forgers using made-up subdomains of your domain, even while your main policy is still at none or quarantine.