A great many domains have a DMARC record with p=none published years ago and never touched again. It is a useful first step, because it enables reports, but it protects against nothing: a forged message that fails DMARC is delivered as if nothing had happened. Real protection comes with p=quarantine and above all with p=reject. The fear of blocking legitimate email holds many companies back, and it is a justified fear if the change is made without a method. With an orderly path, however, the risk becomes manageable.
The three policies at a glance
| Policy | What it asks the receiver | Protection |
|---|---|---|
p=none |
only monitor and send reports | none |
p=quarantine |
treat failing messages as suspicious, usually spam | partial |
p=reject |
reject failing messages during the SMTP session | full |
Remember that DMARC is a request, not an order: each receiver applies the policy according to its own rules. In practice the large providers honor it fairly faithfully.
Stage 1: monitoring and inventory
With p=none and an active rua= address, collect reports for at least a few weeks. The ideal period covers a full business cycle: month end, invoice runs, any seasonal campaigns. Some services send little and rarely, and those are exactly the ones people forget.
The output of this stage is a list of every legitimate source, with the status of each:
- main mail server;
- marketing and newsletter platforms;
- CRM, helpdesk, billing systems;
- web applications that send notifications;
- multifunction printers or scanners that send via SMTP;
- external suppliers who write «on behalf» of the company.
Stage 2: fixing legitimate sources
For each source that does not pass DMARC, pick a solution:
- Configure DKIM with your own domain, if the service allows it. This is the preferred solution.
- Use a custom bounce domain, so that SPF is aligned.
- Move the service to a dedicated subdomain, for example
notifications.example.com, with its own authentication. - Change the sender, if the service supports none of the options above: better for it to send with its own domain than with yours, unauthenticated.
The stage is complete when, in the reports, the share of legitimate messages failing DMARC is close to zero. What remains is usually forwarding and mailing lists, which are outside your control.
Stage 3: progressive quarantine
The pct= tag lets you apply the policy to only a percentage of failing messages. The typical path is:
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
After a few weeks without complaints, move to 50, then 100. Note that support for intermediate pct values is not uniform across receivers, so treat it as an aid, not a guarantee of gradual rollout. During this stage it is important to have a channel for internal reports: «a customer says our invoice went to spam» is exactly the information you need.
Stage 4: reject
With quarantine at 100% stable and clean reports, switch to:
_dmarc.example.com. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"
From this point on, anyone trying to use your domain in From from an unauthorized server is turned away by receivers that enforce DMARC. Rejection happens during the SMTP session, so a legitimate sender with a misconfiguration gets an immediate error, easier to diagnose than a message that silently vanished into spam.
Don't forget subdomains
The sp= tag defines the policy for subdomains. If it is absent, subdomains inherit p=. Two recurring mistakes:
- leaving
sp=noneout of caution and forgetting it: an attacker can send frominvoices.example.comunhindered; - moving to
p=rejectwithout knowing that a service sends from an unconfigured subdomain.
A subdomain that needs a different policy can publish its own _dmarc.subdomain.example.com record, which takes precedence over the main domain's.
What can still go wrong
- Mailing lists: some modify the subject or body, breaking DKIM, and resend from their own server, breaking SPF. Modern lists rewrite From to avoid the problem; older ones don't.
- Plain forwarding: SPF always fails, DKIM survives if the message is not altered.
- New services: the marketing team enables a new platform and the first sends are rejected. That is why reports must be read after the switch too, not only before.
In my work I recommend setting one simple rule: no service may send with the company domain until someone has verified its DKIM and alignment.
In short
p=noneonly gathers data; protection comes with quarantine and reject.- Before tightening the policy, take a full inventory of sources across an entire business cycle.
- Every legitimate source must be aligned, preferably with DKIM on your own domain.
- The move to quarantine can be gradual with
pct=, then you reach reject. - The subdomain policy (
sp=) and reading reports after the switch are part of the job.
