There are two ways to arrive at p=reject. In the first, you publish it on a Tuesday afternoon because a security questionnaire asked for it, and spend Wednesday finding out which departments send mail you did not know about. In the second, you spend a few weeks reading reports, fix each sender, and the final change is uneventful.
The destination is identical. The difference is whether your invoices, password resets and campaign mail keep arriving while you get there.
What the policy actually controls
DMARC (RFC 7489) publishes an instruction for messages that claim to come from your domain and fail authentication. The p= tag has three values:
p=none— take no special action. Monitoring only. You still receive reports.p=quarantine— treat failures as suspicious, which in practice means the spam folder.p=reject— refuse failing messages at the SMTP level so they are never delivered.
A message passes when SPF or DKIM passes and the passing domain aligns with the visible From: address. Both halves matter: a vendor can pass SPF for its own bounce domain all day and still fail DMARC for yours.
p=reject stops other people receiving forged mail in your name. That is worth a great deal for your brand and for phishing resistance — but it does not improve the delivery of mail that was already failing. Fixing your own senders is what does that.Stage 0: write down who sends as you
Before touching DNS, list every system permitted to use your domain in a From address. In most organisations the list is longer than expected: the mail platform, CRM, invoicing or accounting software, helpdesk, marketing automation, applicant tracking, e-signature tools, monitoring and alerting, website contact forms, payroll, and whatever a department signed up for last quarter.
You will not get this list complete from memory. That is fine — the reports in the next stage exist precisely to finish it for you.
Stage 1: publish p=none and collect reports
Publish a monitoring policy with a reporting address:
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"
This changes nothing about how your mail is handled. What it does is ask receivers to send you daily aggregate reports: XML summaries listing every IP address that sent mail claiming to be your domain, how many messages each sent, and whether SPF and DKIM passed and aligned.
Leave it running for at least two to four weeks so monthly processes — payroll, invoicing runs, quarterly campaigns — appear at least once. Expect three groups in the data: systems you knew about, systems you had forgotten, and outright forgery. All three are useful.
example.com._report._dmarc.vendor.example. Without it, many receivers will simply not send the reports, and you will conclude nobody is sending as you.Stage 2: fix each sender until it aligns
For every legitimate source in the reports, the goal is one aligned pass. In order of preference:
Prefer aligned DKIM
Configure the platform to sign with your domain (the signature's d= tag should read example.com), which normally means publishing a CNAME or TXT record the vendor gives you. Aligned DKIM survives forwarding, so it is the sturdier of the two.
Then align SPF where you can
Some platforms let you set a custom Return-Path or bounce domain such as bounce.example.com. That brings the envelope domain into alignment with your From header. Remember that every vendor you add to your SPF record costs DNS lookups — see the ten-lookup limit before adding another include.
Move what cannot be fixed
If a system genuinely cannot sign as your domain, have it send from a subdomain with its own policy, or from a different domain entirely. A subdomain keeps the problem contained instead of holding your whole rollout hostage.
Stage 3: quarantine, gradually
When the reports show your known senders aligned, start enforcing on a fraction of traffic using the pct tag:
_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.com"
A quarter of failing messages are now treated as spam; the rest are still delivered. Watch the reports and your support queue, then raise to 50, then 100. Do not let this stage drag on for months — partial enforcement is a testing tool, not a destination.
Stage 4: reject
_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s"
Two tags are worth considering at this point. sp= sets the policy for subdomains, and np= sets it for subdomains that do not exist at all — useful because attackers often invent names such as billing.example.com. Strict alignment (adkim=s, aspf=s) is stronger but requires exact domain matches, so only tighten it once the reports show you can.
What breaks without it
- Anyone can send as you. Without enforcement, a forged invoice with
billing@example.comin the From header is delivered to your customers with nothing to stop it. - You are blind. No
ruameans no reports, and no way to know which of your own systems are failing until someone complains. - Enforcing too early takes your own mail down. Every unaligned legitimate sender is silently rejected, typically including something nobody remembers until the month-end run.
- Stalling at p=none. Monitoring alone protects nobody. It is a stage, not an answer.
Forwarding and mailing lists
Two situations break authentication through no fault of yours. Plain forwarding — a university alias, a personal redirect — relays your message from an IP that is not in your SPF record, so SPF fails; an aligned DKIM signature is what saves the message. Mailing lists are harder, because many rewrite the subject or append a footer, which invalidates the DKIM signature as well.
ARC (RFC 8617) exists for exactly this: an intermediary records the authentication results it observed and signs that record, so the final receiver can see the message was authentic before the list touched it. You do not implement ARC as a sender; you rely on receivers honouring it. In practice, reject-level policies are widely deployed and mailing lists have largely adapted, but if you run a discussion list on your own domain, check its rewriting behaviour before enforcing.
How to check it in 30 seconds
Run a DMARC Lookup for your domain. It reads the record from your authoritative name servers, validates every tag, explains the effective policy including inherited subdomain behaviour, and checks whether external reporting addresses are authorised — the failure that quietly stops reports arriving.
To build or edit a record safely, use the DMARC Generator. To read the XML that starts arriving, upload it to the DMARC Report Analyzer, which turns it into a per-source table with reverse DNS, disposition and alignment.
Fix it
- Inventory every system that sends from your domain.
- Publish
p=nonewith aruaaddress and, if it is on another domain, the matching authorisation record. - Collect reports for two to four weeks, long enough to capture monthly sending.
- Give each legitimate sender an aligned DKIM signature; align SPF where the platform allows it.
- Move senders that cannot align onto a subdomain.
- Set
p=quarantine; pct=25, then 50, then 100, watching the reports at each step. - Move to
p=reject, and addsp=andnp=for subdomains. - Keep reading reports afterwards — new vendors appear all the time.
Then keep it that way
A DMARC record is a single line of text that any administrator with DNS access can weaken in seconds. Records get relaxed "temporarily" during a migration and never restored; a pct value set for a test is forgotten; an entire record vanishes when a zone is rebuilt.
StatusDNS re-checks your DMARC record on a schedule alongside SPF and DKIM, and alerts you by email, Slack or webhook the moment the policy changes or the record disappears — so a weakened policy is something you are told about rather than something you discover in the next audit.