The Small Business DMARC Bridge: From p=none to p=reject in Four Weeks
A pragmatic 4-week sprint plan for small businesses to take DMARC from p=none to p=reject. Real services, real timelines, real guardrails.
TL;DR
Most small businesses send mail from five services, not fifty. Four weeks is enough. Week 1: discover every sender, publish p=none. Week 2: fix SPF and DKIM for each platform. Week 3: read the reports, fix what’s failing. Week 4: ramp to p=quarantine, then p=reject. Don’t ship on a Friday.
Why four weeks, not six months?
Enterprise programmes run for six months because enterprise estates have a hundred sending services, three legacy domains, and a procurement cycle that adds a fortnight to every DKIM key request.
A typical SMB sender estate is M365 or Google Workspace, one marketing platform, an accounting system, maybe a transactional sender, and a help desk. Five services. Almost never twenty. Five services is a four-week problem.
Week 1: Who’s actually sending?
Day 1: Run a DNS scan against your apex domain: SPF, DKIM, DMARC, MX, blacklists. Screenshot the result.
Days 2–3: Walk the business. What sends newsletters? What sends invoices? Payroll provider? Every “yes” is a service that needs SPF and DKIM.
Day 4: Publish p=none with reporting on: v=DMARC1; p=none; rua=mailto:reports@yourdomain.co.za; fo=1;. This protects nothing. It turns on the report feed.
Days 5–7: Aggregate reports arrive daily. By week’s end at least one source IP will be a service nobody mentioned on Day 2. Add it to the inventory. Route reports to a parsing service. Raw XML will drown a person’s inbox.
Week 2: Authenticate the legitimate senders
| Sender | // spf Include | // dkim Selector(s) | // gotcha Notes |
|---|---|---|---|
| Microsoft 365 | include:spf.protection.outlook.com |
selector1, selector2 |
Enable signing in Defender portal. Records existing isn't enough. |
| Google Workspace | include:_spf.google.com |
google |
Generate and turn on signing in Admin Console → Gmail → Authenticate email. |
| Mailchimp | include:servers.mcsv.net |
k1, k2 |
Verify the sending domain in Mailchimp. |
| HubSpot | Hub-specific include | hs1-XXXXX, hs2-XXXXX |
"Connect email sending domain" in HubSpot DNS settings. |
Watch the 10-lookup SPF cap. M365 alone burns three lookups. Add Google Workspace, Mailchimp, HubSpot, and any transactional relay and you’re at the ceiling. Past 10, receivers return PermError and every message fails. Where you can only get one mechanism right on a platform, get DKIM right. It survives mail forwarding where SPF doesn’t.
By Friday of Week 2, send a test message from each platform to a Gmail address and check the original. Look for dkim=pass and spf=pass in the Authentication-Results header.
Week 3: Read the reports. Fix what’s failing.
Still at p=none. Open the reports in any in-browser DMARC viewer: per-source table showing SPF result, DKIM result, alignment, and disposition.
Three patterns:
Known sender failing. Mailchimp DKIM shows fail. Probably a missed CNAME or signing not switched on. Fix it at the platform and check the next day’s report.
Sender you forgot. Messages from IPs not on your inventory. Reverse-DNS the IP; it usually resolves to something obvious. Authenticate it or shut it off.
Real spoofing. Foreign IPs, SPF and DKIM both failing. Note it. The ramp closes the door on this category.
If more than 1% of legitimate volume is failing by Friday of Week 3, don’t move to enforcement yet.
Week 4: Ramp to p=reject
Monday: p=quarantine; pct=10. Receivers quarantine 10% of failing mail; the other 90% goes through. Watch reports daily.
Wednesday: pct=50.
Thursday morning: pct=100. Do not ship this on a Friday afternoon. If something legitimate is broken and you don’t notice until Monday, that’s three days of outbound mail in spam.
Day 7: p=reject. Final record:
v=DMARC1; p=reject; sp=reject; aspf=s; adkim=s; pct=100; rua=mailto:reports@yourdomain.co.za; fo=1;
Spoofers get rejected at the SMTP layer. Done.
Guardrails: don’t move during a major campaign week, on a Friday, while a key person is on leave, or if Week 3’s reports show more than 1% legitimate failure.
What comes next
DKIM keys age. Vendors rotate IPs. Marketing buys new tools. Somebody needs to read reports each week and react before deliverability tanks.
OSH runs the four-week sprint as a fixed-scope engagement, then offers managed reporting: hosted RUA endpoint, XML parsing, alerting on new sources, and a two-page monthly executive summary. Services page has the details.
