From p=none to p=reject: A Practitioner's DMARC Playbook
Many organisations stay at p=none indefinitely, collecting reports but enforcing nothing. This guide walks through a controlled path to enforcement: finding and authorising senders, handling subdomains and moving to p=reject without disrupting legitimate mail.
Key points
- SPF, DKIM and alignment, explained for practitioners
- How to find, verify and authorise every legitimate sender
- Subdomain policy and the exposure it leaves
- A staged path to enforcement, including DMARCbis test mode
On this page
Why organisations stall at p=none
DMARC at p=none is a monitoring posture, not a defence. It asks receiving mail servers to report authentication results but deliver failing mail anyway, so anyone can still send email that claims to be from your domain. Many organisations publish a p=none record, collect reports and never move further.
The stall is rarely apathy. It is fear of breaking legitimate mail. A typical organisation sends email through many separate services: CRM, marketing automation, HR, payroll, support desks, e-signature and monitoring alerts. Enforce before each of those senders is authenticated and aligned, and invoices, offer letters and password resets can quietly fail. This playbook is about removing that fear with evidence.
The mechanics: SPF, DKIM and alignment
DMARC passes when a message passes SPF or DKIM and the passing identifier aligns with the visible From domain. Alignment is where most people trip. An SPF pass on your marketing platform’s return-path domain (for example bounces.mailvendor.com) does nothing for DMARC unless that domain aligns with yourdomain.com. Similarly, a DKIM signature from d=mailvendor.com passes DKIM but fails DMARC alignment. For every sender, the question is not “does it authenticate?” but “does it authenticate as us?”
In practice, DKIM alignment does most of the work. SPF breaks on forwarding and is limited to 10 DNS lookups, a limit that long include chains often exceed, turning SPF results into permerror. DKIM survives forwarding and has no lookup budget. The reliable pattern is to configure a custom, aligned DKIM signing domain on every legitimate sender, treat SPF as a secondary signal, and never rely on SPF alone for a sender that matters.
Discovery: finding every sender
Enforcement depends on knowing who sends as you. DMARC aggregate (RUA) reports are your census: receivers that support DMARC report which sources sent mail using your domain and whether they authenticated. They usually arrive once a day, and the raw XML is hard to read at volume, so a tool that groups sources and identifies the services behind them saves a great deal of time.
Plan for a long tail. The first weeks of monitoring show your highest-volume senders: the email platform, the CRM, the marketing tool. The risky senders are the occasional ones, such as the board-portal mailer, the annual benefits platform or a regional office’s invoicing tool. Monitor across at least one full business quarter, and treat any source you cannot attribute to an owner as a work item, not noise.
Authorising senders safely
For each discovered sender, work through a checklist: identify the internal owner, confirm the sending is still wanted (abandoned tools are better decommissioned than authenticated), configure DKIM with an aligned custom domain following the vendor’s documentation, and add SPF only if the vendor supports an aligned return-path and your lookup budget allows. Confirm the result in your DMARC reports rather than the vendor’s dashboard before marking it done.
Avoid “fixing” failures by widening SPF with broad includes or, worse, ip4 ranges covering shared vendor infrastructure. Shared ranges mean other customers of that vendor can send DMARC-passing mail as your domain. Authorise the narrowest mechanism that covers your actual traffic, review it periodically and watch for drift: an SPF record that was correct in January can be broken by June.
Subdomains: the exposure people forget
Subdomains inherit the organisational domain’s DMARC policy unless they publish their own record or the parent sets a different subdomain policy with sp=. A common gap: the organisational domain reaches p=reject while a sending subdomain such as billing.yourdomain.com remains spoofable because a weaker subdomain policy or a forgotten record applies to it.
The safer pattern is explicit. Set sp=reject alongside p=reject once legitimate subdomain senders are authenticated, add np=reject for non-existent subdomains under DMARCbis, and publish explicit records on important sending subdomains. Pair this with subdomain-takeover checks: a dangling CNAME on an old marketing subdomain can give an attacker both a hosting foothold and a way to send mail.
The enforcement ramp
Do not jump from p=none to p=reject in one move. Move to p=quarantine first, so failing mail goes to spam rather than disappearing, and hold each stage while you watch reports for legitimate sources you missed. Under the original DMARC specification, the pct tag limited policy to a sample of failing mail; DMARCbis removes pct and replaces it with a test mode (t=y), in which receivers apply the next-lower policy while you validate.
At each stage, the go/no-go decision rests on one question: is any mail you believe is legitimate still failing DMARC? When the answer stays no for a sustained period, advance. After p=reject, the work becomes operational: new SaaS procurement should include DKIM setup, DNS changes need watching for drift, and the failure stream becomes useful intelligence, because once legitimate mail passes, much of what fails is someone imitating you.
Related reading
All guides →
Put this into practice
See how PhishSheriff runs simulations, assigns training and reports on human risk and email-domain trust.