How to use domain health checks for MSP prospecting
Updated on 25 Oct 2026: We added a follow-up workflow and clarified how to verify domain health findings before using them in MSP outreach.
Domain health checks give MSP prospecting a concrete starting point for discussing risk. They show where a prospect's public DNS and email authentication setup has gaps that can affect spoofing protection, client trust, brand risk, and deliverability. The scan provides evidence for a clear account plan: what the public evidence shows, what needs verification, what should be fixed first, and which fixes belong in an ongoing managed service.
For MSP owners and operators, the best use of a domain health check is targeted prospecting. Start with a small list of companies that already fit your service profile. Run non-invasive checks against their public DNS and mail posture. Score the findings by client impact, not by technical trivia. Then use the result to open a practical conversation about email authentication, DMARC reporting, sender inventory, and domain reputation.
Suped supports this workflow with prospecting reports, multi-tenant organization management, authentication monitoring, and automated issue detection. Suped's hosted DMARC, hosted SPF, SPF flattening, MTA-STS, and blocklist monitoring then turn approved changes into repeatable support work after the sale.
What a domain health check should include
A useful prospecting check looks at the public signals that explain whether a domain is ready for managed email authentication. It should not rely on fear. It should show specific evidence. The first pass should tell you whether DMARC exists, whether the policy asks receivers to act on failures, whether SPF is valid, whether a DKIM key is published for a known selector, whether identified sending IPs have forward-confirmed reverse DNS, and whether the domain or identified sending IPs appear on a blocklist (blacklist). A DNS-only check cannot verify live DKIM signatures or DMARC alignment. Obtain a message sample or authorized platform access; an unknown selector is an unverified check, not evidence that DKIM is absent.
This sits within DMARC for MSPs: a packaged operating model where the MSP discovers senders, fixes authentication, stages enforcement, monitors failures, and reports progress. A one-time scan opens a conversation. A managed service creates recurring work with measurable outcomes.
|
|
|
|---|---|---|
DMARC | Published policy and aggregate reporting request | Identifies DMARC coverage to verify |
SPF | Sender authorization and record validity | Finds duplicate SPF records and lookup-limit risks |
DKIM key | Published key for a known selector | Flags signing to verify in discovery |
MX | Inbound mail routing | Identifies inbound platforms, not outbound sending IPs |
Blocklist (blacklist) | Reputation signals | Investigate relevant, current listings |
MTA-STS | Inbound TLS policy in DNS and HTTPS | Identifies transport policy work |
Core checks MSPs can use in prospect reports
Before reporting missing DMARC on a subdomain, check whether it inherits a policy. A rua address requests aggregate reports; public DNS does not prove reports arrive or anyone reviews them. DMARC addresses unauthorized use of a domain in the visible From address. It does not stop lookalike domains or mail sent through a compromised authorized account.
- Start narrow: Check the primary sending domain first, then add marketing, billing, recruiting, and support domains if the prospect has them.
- Score impact: A missing DMARC record matters more than a cosmetic DNS warning. Rank findings by business risk and delivery effort.
- Keep evidence: Save the exact DNS records and result dates. Prospects need to see current proof, not generic advice.
- Avoid assumptions: A visible DNS issue tells you where to start. It does not prove who owns the system or why it was configured that way.
Turn health checks into prospecting signals
The strongest prospecting signal is the gap between the prospect's current posture and the level of protection their business needs. A law firm, payroll company, insurance agency, ecommerce brand, and local manufacturer have different sender patterns, but each needs email authentication that a nontechnical owner can understand and a support team can maintain.
Weak prospecting use
- Generic claim: The outreach says the domain has DNS problems without showing exact evidence.
- Tool dump: The report lists every warning with no ranking or recommended order.
- No next step: The prospect sees issues but does not know what an MSP would do next.
Strong prospecting use
- Specific evidence: The outreach names the missing record, monitoring-only policy, SPF risk, or reputation issue.
- Clear priority: The report separates urgent fixes from routine hardening work.
- Managed path: The proposal explains monitoring, sender discovery, policy staging, and reporting.
MSP prospecting workflow with public DNS checks, risk scoring, reports, and managed services
Illustrative prospect priority bands
Example internal sales triage bands, not a breach probability or an industry standard. Define repeatable weights using verified findings and business impact.
Low priority
0-39
No confirmed material authentication issue; validate live mail and report coverage during discovery.
Serviceable gap
40-69
Reporting gaps, SPF cleanup, or an intentional p=none stage needing a review plan.
High priority
70-100
No applicable DMARC policy, a reproducible SPF error, or a relevant blocklist (blacklist) listing with confirmed impact.
Qualify the prospect before you quote
A technical risk score qualifies the problem, while commercial discovery qualifies the client. Before quoting, assess the account's fit with your operating model, because unclear ownership, unknown sender volume, limited DNS access, and rejected controls turn a neat assessment into unpriced service desk work.
|
|
|
|---|---|---|
Environment scope | Which domains, subdomains, mail platforms, and third-party senders are in use? | Sets discovery and remediation effort |
Control ownership | Who owns DNS, email, marketing systems, and change approval? | Exposes access and change dependencies |
Standard service fit | Will the client accept monitoring, sender cleanup, staged enforcement, and ongoing reporting? | Identifies exceptions and manual work |
Decision authority | Who approves controls and signs risk exceptions? | Prevents stalled remediation |
Success measure | Which policy state and reporting outcome must be reached? | Makes scope and renewal measurable |
Buying timeline | When does the current MSP contract renew, and when can changes be approved? | Sets follow-up timing and onboarding dates |
Commercial qualification questions for MSP prospects
Use a short discovery questionnaire before sending a fixed quote. Price known exceptions explicitly, document who can authorize DNS changes, and separate one-time remediation from the monthly monitoring scope. The public health check provides evidence for the conversation, but client discovery determines the workload.
Run a passive domain health check
A prospecting health check should use public, lightweight methods and respectful language. You do not need credentials to inspect public DNS records or basic reputation signals. Keep the initial check passive, without sending test messages or attempting logins. Do not imply you have seen private mail data. Do not claim a breach. Do not overstate a warning. Say what the public record shows and what should be verified during onboarding.
- Pick accounts: Use your ideal client profile, existing vertical knowledge, available service capacity, and companies where email trust matters.
- Check public records: Review DMARC, SPF, DKIM selectors when known, MX, MTA-STS, TLS-RPT, reverse DNS for identified sending IPs, and reputation signals. For SPF, count lookup-causing terms across nested includes against the limit of 10. Check MTA-STS over HTTPS as well as DNS.
- Rank findings: Give each finding a client-facing impact and a likely remediation path.
- Write the opener: Lead with one specific issue and one practical next step, not a long audit dump.
- Prepare delivery: Know how you will monitor, fix, report, and support the domain after the prospect says yes.
For bulk senders, add discovery checks for SPF and DKIM coverage, DMARC alignment, one-click unsubscribe on promotional mail, and spam-rate data. These checks depend on message headers or account data, so label them as discovery items rather than public DNS findings.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A quick public scan is enough to qualify a conversation. Suped's domain health checker pulls the main DNS and authentication checks into a single view. Do not send raw results without interpretation. The MSP's value is translating those results into evidence, risk, sequence, and service delivery.
Keep the outreach defensible
Use language like "your public DNS record currently shows" instead of "your email is insecure." The first statement is evidence-based. The second is too broad without a full assessment completed with the client.
- Document dates: DNS and blocklist results change. Include when the check ran.
- State limits: Public checks do not reveal every sender or every mail flow. A clean blacklist result does not guarantee inbox placement.
- Avoid blame: Frame the issue as normal technical debt that your team can manage.
Microsoft 365 admin center domain settings with DNS and MX record status
Build a prospect report that sells the service
A good prospect report gives the owner, operations lead, security lead, or IT contact enough evidence to accept that unmanaged email authentication has risk. It also gives your MSP enough structure to quote a managed outcome. The strongest reports separate the executive message, technical evidence, remediation plan, and ongoing service scope instead of teaching every protocol.
Create prospecting report dialog with MSP logo, prospect name, domains, prospect logo, and language fields
Suped's prospecting report workflow supports this step. You can create a branded report for a prospect, add the prospect name and domains, and use the output as a structured sales asset. Use the report as a concrete starting point for the discovery call, then verify the sender scope with the prospect.
|
|
|
|---|---|---|
Summary | Explain business impact | Sales |
Findings | Show exact records, scan time, and verified scope | Technical lead |
Priority | Set fix order | Service desk |
Roadmap | Define managed work | Account manager |
Proof | Support the proposal | MSP owner |
Report sections that help MSP sales and delivery teams
When the report finds missing DMARC, avoid jumping straight to an enforcement policy. Most clients need monitoring first. A good first managed phase is to collect DMARC reports, identify authorized senders, fix SPF and DKIM failures, and only then stage policy changes. RFC 9989 replaced RFC 7489 and makes pct historic, so base staging on observed reports and planned policy changes rather than percentage-based enforcement. It advises domains whose users post to mailing lists against p=reject. If such a domain still chooses it, compare at least a month of reports at p=none with an equally long period at p=quarantine before proceeding. A deeper DMARC audit can turn a prospecting scan into a fuller discovery project.
Translate findings into managed DMARC work
The handoff from prospecting to delivery is where many MSPs lose margin. A sales report says "DMARC missing." The service team then has to find every sender, identify who owns each platform, request DNS changes, fix SPF lookup limits, confirm DKIM signing and alignment, and explain policy staging to a client who thought this was a quick DNS edit. Build the delivery model before you scale the prospecting motion.
MSP organizations page showing client organizations, domain counts, email volume, and domain status columns
Suped's MSP and multi-tenancy dashboard supports this handoff by keeping each client's domain status, reported email volume, policy state, and source visibility in its own organization. After the sale, create the client's organization, add the approved domains, and configure report collection and alerts.
One-time audit
A one-time audit can help win trust, but it usually leaves the client with static findings. It works best when the MSP uses it as the first stage of a managed plan.
- Output: Snapshot report and prioritized fixes.
- Risk: Findings age quickly as senders change.
Managed service
A managed service keeps the domain under review. It covers monitoring, triage, policy staging, client reporting, and recurring authentication cleanup.
- Output: Ongoing health, alerts, and progress reports.
- Value: The client has a maintained authentication program.
The operational service normally starts with DMARC monitoring, then moves into sender cleanup, policy staging, and client reporting. If the client has limited DNS access or frequent changes, Hosted DMARC can reduce routine DNS edits and give the MSP tighter control over policy changes.
Keep one SPF record per name and preserve existing authorized senders when editing it. Replace the example reporting address and documentation IP with approved client values. Publish sender-issued DKIM records, including CNAME targets where required.
Illustrative records, replace example values before publishingdns
; Documentation examples only. Do not publish unchanged. _dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com" example.com. IN TXT "v=spf1 ip4:192.0.2.10 -all" ; Obtain the DKIM selector and exact record value from the authorized sender.
Use the findings in outreach
The best outreach is concise and specific. A prospect does not need a lecture on RFCs. They need to know what the current public setup shows, which gap needs verification, and how your MSP would manage the work. Keep the first email to one finding, its supporting evidence, the business impact, and one suggested call topic.
Example MSP opener
A public DNS check of [domain] on [scan date] found a DMARC policy of p=none with aggregate reports requested. That can be an intentional monitoring stage; it does not request quarantine or rejection for DMARC failures. We help clients review reports and verify legitimate senders before changing policy. Would a 15-minute review with your DNS or email owner help confirm the next step?
That message stays within the evidence. It is specific and calm, with a clear link to work your team can deliver. If the prospect responds, move to discovery: who sends mail for them, who controls DNS, what platforms send invoices or marketing, and what risk matters to their leadership.
- Use one issue: A single concrete finding gets more attention than a long technical list.
- Offer context: Explain that public DNS checks are a starting point and that onboarding confirms all senders.
- Tie to service: Position the fix as monitoring, triage, policy staging, and reporting. Record editing is only one task.
- Plan handoff: Use a consistent intake checklist so sales promises match delivery reality.
Once a prospect becomes a client, move quickly into client onboarding and document the repeatable steps in a DMARC runbook. This keeps prospecting, qualification, sales, and service desk work connected instead of creating one-off projects.
Follow up on changes and measure the pipeline
A prospect with an authentication gap still needs the right buying timeline. Record the domain, scan date, finding, contact owner, and agreed next action in your CRM. Use a fresh check or a prospect's stated renewal date to make follow-up specific.
|
|
|---|---|
DMARC or SPF record changes | Recheck the exact record and ask whether the prospect wants a review of the remaining findings. |
The original gap is fixed | Acknowledge the fix and offer ongoing monitoring only if there is still a relevant need. |
The finding is unchanged | At the agreed follow-up date, share fresh evidence and ask whether the planned review is still useful. |
An agreed review or contract renewal approaches | Confirm the decision owner and timing before preparing a proposal. |
Evidence-based follow-up triggers for MSP prospects
An unchanged record is not a new incident, and a DNS change does not prove a new sender is active. Keep follow-up within the prospect's preferences and stop when they decline.
Review the same prospect cohort each month. Track domains checked, positive replies, qualified meetings, and signed managed service clients. Calculate meeting rate as qualified meetings divided by prospects contacted, and close rate as signed clients divided by qualified meetings. Compare niches and opening findings using those definitions; scan volume alone does not measure MSP lead generation.
Start with a small prospecting pilot
Start with 10 companies in one niche that fit your service profile. Save a dated baseline, select one verified finding per account, and assign an outreach owner and next action. Use Suped's prospect reports for the discussion, then set up DMARC monitoring in a separate client organization after engagement.
Frequently asked questions
Yes. Public DNS, DMARC, SPF, MX, known DKIM selectors, and some reputation signals can be checked without credentials. Treat the results as a starting point, not a complete private assessment.
Use a verified finding with a clear business impact, such as no applicable DMARC policy or a reproducible SPF error. Treat missing aggregate reporting as a visibility gap and check whether a blocklist (blacklist) listing affects the actual sending source. A p=none policy alone does not prove neglect.
No. Start with monitoring and sender discovery unless the domain is already well understood. Enforcement should follow SPF and DKIM cleanup, verified sender ownership, analysis of representative report data, and a staged policy plan. RFC 9989 advises domains whose users post to mailing lists against p=reject; longer monitoring does not remove that interoperability risk.
Suped helps MSPs create prospecting reports, manage separate client organizations, monitor DMARC, detect issues, send alerts, manage hosted records, and report progress after the sale.
Recheck priority prospects before each new outreach sequence or sales call and after a known DNS change. Save the latest evidence alongside the original result. Use an agreed follow-up date when the prospect's buying timeline is longer.
