A DMARC policy is the instruction you publish telling receiving mail servers what to do with messages that fail authentication for your domain. It's the `p=` tag in your DMARC record, and it has three possible values: `none`, `quarantine`, and `reject`. Choosing the right one, and ramping between them, is most of the work in a DMARC rollout.

## What are the three DMARC policies?

Each is a different level of enforcement, from watching to blocking.

| Policy         | What the receiver does                                           | When to use it                                              |
| -------------- | ---------------------------------------------------------------- | ----------------------------------------------------------- |
| `p=none`       | Nothing different. Delivers as usual and just sends you reports. | Starting out, while you confirm legitimate mail aligns.     |
| `p=quarantine` | Treats failing mail as suspicious, usually routing it to spam.   | Once reports look clean and you're ready to enforce gently. |
| `p=reject`     | Refuses failing mail outright, so it never arrives.              | Full protection, once you trust your authentication.        |

The thing to understand is that your policy is a request. Receivers decide whether to honor it, and the big mailbox providers generally do. Publishing `p=reject` doesn't guarantee every server worldwide blocks spoofed mail, but the providers that matter for most senders will act on it.

## Why start with p=none?

Because it changes nothing while you learn. This is the clever part of the design: `p=none` turns on reporting without touching delivery, so you get a complete picture of who sends mail under your domain before you enforce anything. You'll almost always find a surprise, a regional office, a billing system, an old marketing tool, sending real mail you'd have broken by jumping straight to reject.

Stay in monitor mode until every legitimate source is passing and aligning in your reports. [Reading a DMARC report](/blog/how-to-read-a-dmarc-report) shows you how to confirm that. There's no fixed timeline, but a few weeks is typical for a domain with several senders.

## How do you ramp from none to reject?

Gradually, watching the reports at each step. The usual path:

1. Publish `p=none` and collect reports until the picture is clean.
2. Move to `p=quarantine`, ideally with `pct=` set low at first (more on that below).
3. Raise the percentage as confidence grows, until you're at `p=quarantine; pct=100`.
4. Switch to `p=reject` for full enforcement.

If failures appear when you tighten, slow down and fix them rather than reverting. The causes are predictable, and [how to fix DMARC failures](/blog/how-to-fix-dmarc-failures) walks through them.

## What does pct do?

The `pct` tag applies your policy to a percentage of failing mail instead of all of it. Setting `p=quarantine; pct=25` tells receivers to quarantine a quarter of the messages that fail and treat the rest under the next-weaker policy. It's a pressure valve for the ramp: you test enforcement on a slice of traffic, watch for fallout, and turn it up. Once you're at `pct=100` and comfortable, you graduate to `reject`.

## What about subdomains?

That's the `sp` tag. By default your `p` policy covers your subdomains too, but `sp` lets you set a different one. A common pattern is a strict main domain with a looser subdomain rule, for example `p=reject; sp=none` while you bring a subdomain's senders into alignment. Leave `sp` out and subdomains simply inherit `p`. For the full tag list, see [what is a DMARC record](/blog/what-is-a-dmarc-record).

## Which policy should you aim for?

`p=reject` is the destination, because it's the only policy that actually stops spoofed mail from reaching anyone. `p=none` protects nobody on its own, so treat it as a starting line and keep moving. Plenty of domains stall at monitor mode for years and draw a false sense of security from it. If your domain is worth spoofing, and most recognizable domains are, reject is the goal worth ramping toward. Whether you need to get there urgently is the subject of [do I need DMARC](/blog/do-i-need-dmarc).

The reassuring part is that the pace is yours. Publish `none`, read the reports, tighten when the data says it's safe, and you'll reach `reject` without ever gambling with legitimate mail. The [authentication guide](/docs/guides/email/dkim-spf-dmarc) has the Bird-specific steps, and you can manage policies from your [sending domains](/products/email/domains).