Learn · For MSPs

Onboarding a client domain to p=reject

The value of a client DMARC service is mostly decided by whether you can run the same sequence every time. This is that sequence: the per-domain playbook for taking a client from "no record" (or an ancient p=none) to enforced p=reject without bouncing a single legitimate invoice. Timings assume a typical small business; complex senders stretch the middle, never the shape.

Week 0: audit, access, and the baseline record

Audit what's there. Run the domain through a DMARC checker: existing DMARC record and policy, SPF record and lookup count, discoverable DKIM selectors, MX. Save the result — it's also the "before" picture for the client report.
Find who actually controls DNS. Registrar, DNS host, and whoever has the login — client, web agency, or a departed contractor. This is reliably the slowest dependency in the entire rollout, so start it first.
Publish the monitoring record. Hosted DMARC: one CNAME on _dmarc pointing at your monitoring platform, and every later policy change is a dashboard action instead of another DNS request. Classic alternative: a TXT record with v=DMARC1; p=none; rua=mailto:…. Either way the starting policy is p=none — pure observation, zero delivery risk.

Tell the client what happens next: one sentence manages every expectation — "Nothing about your mail changes yet; for the next few weeks we're building the list of everything that sends as your domain, then we'll lock it down in stages." The staged approach is a feature to sell, not a delay to apologize for.

Weeks 1–4: inventory the senders

Aggregate reports start arriving within a day or two, and the sender list builds fast. Give it two to four weeks — monthly processes like payroll and invoicing runs only reveal their senders when they fire. Expect surprises; every client has at least one:

The known senders — Google Workspace or Microsoft 365, and whatever ESP marketing uses. Usually passing something, not always aligned.
The forgotten senders — the payroll platform, the CRM's notification engine, the booking system, the scanner-to-email copier. Legitimate, unaligned, and one policy change away from being blocked.
The impostors — sources failing both SPF and DKIM from infrastructure nobody recognizes. IP enrichment does the triage here: a flagged VPS in a hosting ASN on another continent isn't a vendor to chase, it's the reason this project exists.

Every legitimate sender gets a decision: align it, or migrate it off the domain. Nothing tightens until that list is empty.

Weeks 2–6: align every legitimate sender

Alignment work is sender-by-sender and mostly done inside each platform's settings: add missing SPF include: mechanisms (watching the 10-lookup limit — flatten before you exceed it), and turn on custom-domain DKIM signing wherever the platform offers it (Mailchimp's version is typical of the genre). Prefer DKIM alignment where you can get it — it survives forwarding, and it keeps working when the ESP's SPF story is structurally unalignable.

The exit test is visual: in the sender table, every legitimate source shows SPF or DKIM passing aligned, and everything still failing both is something you're content to block.

Weeks 4–10: tighten in stages

Now the walk — each step is a policy change (a button under hosted DMARC, a DNS edit otherwise), a waiting period, and a check that failure volume is only the mail you mean to kill. The full mechanics are in the policy guide; the MSP-relevant shape:

Stage	Typical dwell	Exit criteria
`p=none`	2–4 weeks	Sender inventory complete; every legitimate sender aligned or migrated
`p=quarantine; pct=25`	1–2 weeks	No legitimate mail reported quarantined; no new unknown-but-real senders
`p=quarantine` (100%)	2–4 weeks	Failure volume is stable and entirely attributable to spoofing
`p=reject`	permanent	— arrival. Spoofed mail now bounces instead of reaching anyone's spam folder

Schedule policy steps early in the client's working week, tell their office manager a change is happening, and you'll hear about any real-mail casualty within hours instead of after the weekend. Casualties at this stage are almost always a sender the inventory missed — drop back one stage, align it, resume.

After reject: the service begins

Reaching p=reject ends the project and starts the product. Three things run forever:

Report monitoring — new senders appear (the client signs up for tools without telling you), and each needs the same align-or-block decision.
Drift watching — the records you set will be edited by someone eventually; daily re-checks with diffs catch it in a day. Why this is the long-tail risk.
Client reporting — the quarterly screen-share of their dashboard: senders seen, spoofs bounced, drift caught. It's ten minutes, and it's why the line item renews.

Then the playbook resets to Week 0 — next domain in the book.