SPF, DKIM, and DMARC Checklist for MSPs Managing Multiple Client Domains

Before touching a single DNS record, list every domain the customer owns: the primary sending domain, regional variants, old brand names kept for redirects, and domains registered defensively that never send mail at all. For each one, note whether it currently sends mail, through which services, and whether SPF or DKIM already exists in any form.

This inventory is the step people skip, and it is the reason DMARC rollouts stall — a policy set on the main domain does nothing to stop an attacker from spoofing a parked lookalike domain the customer forgot they owned.

An SPF record lists the servers and services authorized to send for a domain. The common mistake is publishing an incomplete list — missing the marketing platform, the invoicing tool, or the CRM's outbound mail — and then discovering the gap only when that service's mail starts failing checks at the receiving end.

Enumerate every service that sends mail on the domain's behalf before publishing the record, and end the record with -all rather than ~all once you are confident the list is complete. A soft fail leaves the door open for exactly the spoofing SPF exists to prevent.

DKIM signs each outgoing message with a private key; the receiving server checks the signature against a public key published in DNS. Every sending service — the mail platform, the CRM, the invoicing tool — needs its own DKIM key configured to sign with the customer's domain, not the vendor's default signing domain.

That last part is the detail that gets missed: most services support signing with the customer's own domain under a setting usually called "custom DKIM" or "domain authentication," and it has to be turned on explicitly. Left on the vendor default, DKIM still passes on paper, but it authenticates the vendor's domain, not the customer's — which is the setup that fails DMARC alignment even though DKIM itself looks fine.

Publish a DMARC record at p=none first, with aggregate reports directed to an address you actually read. This does not change mail delivery; it starts collecting reports on which sources pass and fail alignment, which is the only reliable way to find a legitimate sender that is not yet correctly configured before enforcement can lock them out.

After two to four weeks of clean reports — every legitimate source aligning — move to p=quarantine, then p=reject. Skipping the monitoring period and jumping straight to reject is how a legitimate invoicing or marketing platform suddenly stops delivering mail with no warning beyond a report almost no one reads in real time.

DMARC does not simply check that SPF and DKIM pass somewhere. It requires alignment: the domain SPF or DKIM authenticated has to match the domain shown in the message's visible "From" header. A third-party service that signs its outgoing mail with its own domain — rather than the customer's, configured through custom DKIM — will pass its own DKIM check and still fail DMARC, because the signed domain and the From domain do not match.

This is why a rollout can look complete — SPF published, DKIM configured, DMARC at enforcement — and still silently drop mail from one marketing tool or invoicing platform that was never switched over to custom DKIM. Check alignment specifically for every sending service, not just whether SPF and DKIM exist.

Parked and defensively registered domains are the easiest oversight, because no one is actively using them and they rarely come up in a mail-delivery conversation. They are also the most attractive to a spoofing attacker, since the legitimate owner is the least likely to notice abuse.

A domain that sends no mail has no legitimate traffic to protect, so there is no ramp needed: publish v=spf1 -all and a DMARC record at p=reject immediately.

The initial rollout is finite work. Keeping it correct is not: a client switches marketing platforms, adds a new SPF include for a service that never gets custom DKIM configured, or someone weakens a DMARC policy back to p=none to troubleshoot a delivery issue and never restores it. None of that shows up unless something is comparing today's DNS against what it should be, per domain, on a schedule.

SecurityScore.me checks SPF, graded DMARC policy, and DKIM key presence as part of external domain monitoring for every registered customer domain, and raises a policy regression as a finding rather than something that has to be caught during the next manual audit. See domain and website monitoring for the full set of email-authentication checks, and security reporting for putting authentication status in front of the customer at the next review.