Most client domains an MSP inherits have some email authentication. Usually there is an SPF record that someone added years ago, DKIM that was switched on for Microsoft 365 but not for the invoicing system, and a DMARC record at p=none that sends reports nobody reads. Each piece looks done. None of it stops anyone spoofing the client’s domain. This free email authentication setup checklist takes one client domain from that state to an enforced DMARC policy. It builds a sender inventory, publishes a single SPF record within the 10-lookup limit, enables DKIM for Microsoft 365 or Google Workspace and every third-party sender, then uses DMARC reports to find what is still failing before the policy is tightened. The move to quarantine and then reject needs the client’s approval. A conditional phase covers the Gmail, Yahoo and Outlook.com bulk sender requirements when the client sends marketing email.
The most common surprise in a first DMARC report is a legitimate service that passes SPF and passes DKIM, and still fails DMARC. The marketing platform uses its own bounce domain and DKIM key, so both checks pass for the platform’s domain, not the client’s. DMARC only counts a pass when the domain that passed matches the domain in the From address the recipient sees. Microsoft 365 and Google Workspace behave the same way until custom DKIM is enabled: they sign with their own default domains, which never align with the client’s.
That is why the order of this checklist matters. A domain at p=none is monitoring, not protection. Moving it to p=quarantine or p=reject before every legitimate sender is aligned sends the client’s own invoices, payslips and helpdesk replies to junk, or bounces them. The reports show what is left to fix. The client decides when to enforce.
What it does: asks receivers to send reports, and to take no action on failures.
What it misses: spoofed mail from the client’s domain is still delivered.
Typical cause: nobody owns the reports, so nobody knows whether enforcement is safe.
What it does: asks receivers to quarantine or reject mail that fails DMARC.
What it needs: every legitimate sender passing SPF or DKIM for the client’s own domain.
Evidence: the sender inventory, the reports and the client’s recorded approval.
One checklist per client domain, from sender inventory to an enforced policy. Phase 6 appears only when the client sends bulk or marketing email.
The scoping answers here decide which DKIM task appears and whether the bulk sender phase is needed.
Leave the domain at p=none until the reports show every legitimate source passing. Weekly review is common practice while you are fixing senders.
Shown only when the client sends marketing or bulk email.
The largest consumer mailbox providers now set minimum rules for anyone sending to their users. Bulk senders need all three records, an aligned From domain and a working unsubscribe. The table summarises each provider’s published requirements as of October 2026. Check the providers’ own pages before relying on any detail, because they change.
| Requirement | Gmail | Yahoo | Outlook.com |
|---|---|---|---|
| Who counts as bulk | Close to 5,000 or more messages a day to personal Gmail accounts; the status is permanent | “A significant volume”, with no published threshold | 5,000 or more messages a day to Outlook.com, Hotmail, Live and MSN, from one From domain |
| All senders | SPF or DKIM | SPF or DKIM | Requirements apply to high-volume senders |
| Bulk senders | SPF, DKIM and DMARC (p=none is enough), From aligned with SPF or DKIM | SPF, DKIM and DMARC (p=none minimum), passing and aligned | SPF and DKIM pass; DMARC at least p=none, aligned with SPF or DKIM |
| Unsubscribe | One-click (RFC 8058) for marketing mail, plus a visible link; honour within 48 hours | One-click for marketing and subscribed mail, RFC 8058 recommended; honour within two days | A clear, easy unsubscribe mechanism |
| Spam complaint rate | Below 0.3%, ideally below 0.1% | Below 0.3% | No published rate |
| Enforcement | Since February 2024; stepped up from November 2025 with temporary and permanent rejections | Since February 2024; one-click unsubscribe from June 2024 | Since 5 May 2025; failing mail is rejected with error 550 5.7.515 |
In May 2026 the IETF published RFC 9989, with RFCs 9990 and 9991 for aggregate and failure reporting. Together they replace RFC 7489 and make DMARC a Proposed Standard. Records published under the old specification keep working, but three changes affect how MSPs roll out policy:
pct tag has been removed. Receivers ignore tags they don’t recognise, so pct=25 can no longer be relied on to apply a policy to a quarter of failing mail. Stage enforcement by subdomain instead, as this checklist does. A new t=y test flag asks receivers to apply one level less than the published policy.rf and ri tags have also been removed. Delete them when you next edit a record.np tag sets the policy for subdomains that don’t exist, which is useful for domains that are often spoofed with invented subdomains.Each client domain gets its own checklist, with the same inventory, SPF, DKIM and DMARC steps whichever engineer runs it. The scoping questions show only the DKIM task for the client’s mail platform, and the bulk sender phase only when it applies, through conditional logic.
The moves to quarantine and to reject are approval tasks assigned to the account manager, who attaches the client’s written go-ahead. The checklist stops until then, and the record shows who approved and when.
Once a domain is enforced, a recurring checklist brings the monthly report review back to the right engineer, so a new or failing sender is caught in the review, not when the client’s invoices stop arriving.
Cyber insurance applications and annual risk reviews commonly ask whether SPF, DKIM and DMARC are in place. The Cyber Insurance Readiness Checklist records the status as evidence, the Network Security Audit checks the records for every domain, and this checklist is the project that fixes what they find.
Resellers who send under their own brand need the same records on their sending domain. The White-Label Reseller Account Setup Checklist includes that step for each new account. See how MSPs run projects like this across every client on the MSP process management software page.
SPF lists the servers allowed to send mail for a domain, and is checked against the envelope sender. DKIM adds a cryptographic signature that a receiver verifies with a public key published in the domain’s DNS. DMARC ties the two to the From address the recipient actually sees. A message passes DMARC when SPF or DKIM passes for a domain that aligns with the From domain. DMARC also lets the domain owner ask receivers to quarantine or reject mail that fails, and to send reports.
Until the aggregate reports show every legitimate sender passing DMARC, and long enough to see mail that only goes out monthly or quarterly, such as invoices and statements. For a small client with a few senders that is often a few weeks. A client with many marketing, finance and line-of-business tools can take months. The risk is the opposite one: domains left at p=none for years because nobody owns the reports.
SPF returns a permanent error, and receivers treat the message as failing SPF. The limit counts the include, a, mx, exists and redirect terms, including those nested inside other services’ records, so fewer than ten includes doesn’t guarantee fewer than ten lookups. The usual fixes are to remove retired senders, move bulk services to a subdomain with its own record, or replace an include with the IP ranges of a service that publishes stable ones.
Gmail, Yahoo and Outlook.com only require DMARC from bulk or high-volume senders, and a p=none policy satisfies them. But p=none doesn’t stop anyone spoofing the domain. For a client whose customers act on emailed invoices and payment details, enforcement is the protection, whatever their volume. Treat the bulk sender rules as the minimum for deliverability and enforcement as the goal for security.
Not as your main control. RFC 9989, published in May 2026, removed pct from the DMARC standard, and some vendor examples have not caught up. Receivers ignore tags they don’t recognise, so you can’t rely on a percentage being applied. Phase enforcement by domain instead: lower-volume subdomains to quarantine first, then the main domain, then reject. Remove pct when you next edit a record.
Yes. A parked domain with no records is easy to spoof, because receivers have nothing to check against. Microsoft’s guidance for parked domains is an SPF record of v=spf1 -all, a DMARC record of v=DMARC1; p=reject; and no DKIM records. These take minutes to publish, so cover every domain the client owns, including old brand names and typo domains bought defensively.
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.
