How do MSPs run a client email security assessment?

Run a new client's email security assessment as a repeatable sequence: inventory every domain and legitimate sending source, audit the authentication records (SPF, DKIM, DMARC) and their enforcement level, check inbound protection and domain reputation, then score the gaps and turn them into a prioritized remediation plan. Treating it as a fixed checklist rather than an ad-hoc poke-around is what makes the assessment fast to deliver, easy to price, and defensible when the client asks why a finding matters.

Quick Takeaways

• An email security assessment has one job at onboarding: produce an evidence-backed picture of how spoofable and how deliverable the client's domains are today.
• Start with an inventory — you cannot assess authentication until you know every domain the client owns and every service that sends as them.
• Audit SPF, DKIM, and DMARC together; a domain can publish all three and still be wide open if DMARC sits at p=none.
• Check inbound posture and domain reputation too, not just outbound authentication — deliverability and blocklisting are part of the risk picture.
• Score the result so the client sees a single number and a ranked list, not a wall of DNS output.
• The assessment is also your scoping document: the gaps you find define the remediation project and the recurring service that follows.

What is the goal of an email security assessment?

The goal is a clear, evidence-backed answer to two questions: can someone impersonate this client's domain, and is the client's legitimate mail reliably reaching inboxes? Everything you check maps back to one of those. Impersonation risk lives in the authentication stack — whether SPF, DKIM, and DMARC are present, correct, and enforced. Deliverability risk lives in reputation and configuration — whether the client is on blocklists, whether their DNS is clean, and whether their real senders are aligned.

Framed that way, the assessment is not a vanity scan. It is the artifact that justifies the engagement: it shows the client concrete exposure, and it hands you a scoped list of fixes to quote. If you are still deciding whether to build this into your offering at all, why MSPs should offer email security services makes the demand-side case, and why MSPs should prioritize email security covers the risk side you will be quantifying here.

Step 1: Inventory domains and sending sources

You cannot assess what you have not enumerated, so the first pass is discovery. List every domain the client owns — primary domains, marketing variants, acquired brands, and parked domains, because an unprotected parked domain is a favorite spoofing target. For each domain, catalog every legitimate service that sends mail as it: the mailbox platform (Microsoft 365, Google Workspace), plus ESPs, CRMs, help desks, billing systems, and any dev or alerting tools.

This inventory is the backbone of the whole assessment. A domain with two senders is a very different job from one with a dozen shadow-IT platforms, and that difference drives both your findings and your eventual price — the same complexity lever behind how MSPs should price DMARC management. Build the sender list from DMARC aggregate reports where they already exist, from the client's own admissions, and from the SPF record's existing include statements.

Step 2: Audit SPF, DKIM, and DMARC

With the inventory in hand, audit the authentication records for each domain and, critically, judge them together rather than in isolation. A green checkmark on each individual record does not mean the domain is protected.

• SPF — Confirm a single, valid SPF record that authorizes every legitimate source and stays within the 10-DNS-lookup limit. Flag missing senders (which will fail) and a ~all or ?all that should be -all once you trust the source list. Validate with an SPF check.
• DKIM — Confirm each active sending service signs with a published selector and a healthy key. Note any provider sending unsigned, and validate published selectors with a DKIM check.
• DMARC — This is where most assessments find the real gap. A domain can publish SPF and DKIM and still be trivially spoofable if its DMARC policy is p=none, which only monitors. Record the exact policy (none, quarantine, or reject), the alignment mode, and whether reports are being collected. Validate the record with the DMARC checker.

The finding that matters most is usually not "no DMARC" but "DMARC stuck at p=none" — monitoring without enforcement. That is the gap your remediation project closes.

Step 3: Check inbound protection and reputation

Outbound authentication is half the picture. A complete assessment also documents how well the client is protected from inbound threats and whether their own mail is trusted.

Check the domain's reputation against major blocklists with a blocklist checker — an actively listed domain or IP explains deliverability complaints and is an urgent finding. Review the inbound configuration: is there filtering beyond the mailbox provider's default, and are the MX records pointing where they should? Note whether transport security is enforced with MTA-STS, which prevents downgrade attacks on inbound mail. Finally, confirm the supporting DNS is sane — no dangling records, no stale entries pointing at decommissioned services — using a DNS lookup tool. These items round out the risk picture that a purely outbound audit would miss, and they overlap with the broader cyber risk assessment many MSPs already run at onboarding.

Step 4: Score, report, and scope the work

Raw DNS output does not sell a remediation project; a score and a ranked list do. Convert your findings into a single posture score plus a prioritized set of gaps — ordered by exposure, not by how easy each is to fix. The fastest way to produce a client-ready baseline is to run each domain through the free Email Security Score tool, which returns an instant gap report you can attach to the assessment and revisit after remediation to show measurable improvement.

Then turn the report into scope. Each gap becomes a line in the remediation project — the labor-heavy work of moving DMARC to enforcement and aligning every sender — and the ongoing monitoring becomes the recurring service. If you are weighing whether to deliver that yourself or lean on automation, should you DIY DMARC or use an automated service breaks down the trade-off. Palisade runs this whole assessment motion for MSPs: it discovers every sending source, evaluates SPF, DKIM, and DMARC against enforcement, and produces the plain-language gap report you hand the client — so the baseline that used to take an afternoon of dig commands is a few minutes per domain.

Common issues when running the assessment

The client cannot list their own sending services

This is the norm, not the exception, so do not rely on the client's memory. Reconstruct the real sender list from DMARC aggregate reports (publish a monitoring record first if none exists), the current SPF include set, and mailbox logs. Assume the list is incomplete until reports confirm it.

Everything looks green but the domain is still spoofable

Individual records passing does not equal enforcement. The usual culprit is DMARC at p=none, which authenticates nothing — it only reports. Always record the enforcement level explicitly and treat monitoring-only as an open gap, not a pass.

The SPF record fails the 10-lookup limit

Domains that have accumulated many senders often blow past SPF's 10-DNS-lookup cap, causing a permerror that silently breaks authentication. Flag it as a finding and plan to consolidate or flatten the record during remediation rather than bolting on yet another include.

Findings without business context get ignored

A list of DNS defects means nothing to a non-technical buyer. Translate each finding into impact — "anyone can send email as your CEO," "your invoices are landing in spam" — so the client understands why the remediation project is worth funding.

Related reading

• How should MSPs price DMARC management services?
• How should MSPs build an effective disaster recovery plan?
• How can MSPs run results-driven QBRs?