How to build a DMARC prospecting report for a cold lead
Published 23 Jun 2026
Updated 25 Oct 2026
13 min read
Summarize with
Updated on 25 Oct 2026: We added a sample prospecting report and tightened the DNS evidence checks and follow-up priorities.
A DMARC prospecting report for a cold lead should show the lead what is already visible about their domain, what that means for spoofing and delivery risk, and what the first paid service step should be. Keep it short, evidence-led, and written for an operator who has not asked for a security audit yet.
For an MSP, the report has one job: create a credible business reason to talk. It should not scare the prospect with raw XML, vague breach language, or a wall of DNS output. It should connect public findings to a concrete service path, especially when your DMARC for MSPs offer includes monitoring, sender cleanup, enforcement planning, and ongoing reporting.
The report should make one decision easier
A cold lead should be able to decide whether a 15-minute DMARC review is worth taking. If the report cannot support that decision in two minutes, it is too long or too technical.
- Show DNS records, visible policy state, authentication gaps, and collection time.
- Explain how the finding affects spoofing control, reporting, sender trust, or enforcement planning.
- State the next step your MSP can deliver without overpromising.
- Include exact query output, screenshots, timestamps, and plain record values where useful.
Build the report around evidence, not fear
A prospecting report works when it feels verifiable. Start with facts anyone can check: the applicable DMARC policy, whether aggregate reporting is requested, whether SPF is too broad or close to lookup limits, whether DKIM keys are visible at tested selectors, and whether confirmed outbound mail infrastructure has a blocklist (blacklist) listing. Record the list name and lookup time; a listing alone does not prove that mail is blocked.
The report should avoid guessing about private mail flow. Public DNS cannot identify every legitimate sender or prove that a visible DKIM key signs production mail. Label those areas as "unknown until monitored or confirmed" instead of presenting assumptions as findings.
Weak prospecting report
- It claims the prospect's email security is broken.
- It shows no visible record values or timestamps.
- It asks for a call with no clear agenda.
- The prospect treats it like generic cold outreach.
Useful prospecting report
- It states that DMARC exists but aggregate reporting is not requested.
- It shows the exact TXT value and lookup time.
- It recommends reporting, sender identification, and staged policy changes based on evidence.
- The lead sees a specific reason to talk.
This is also where the report connects to outreach. A finding is useful only when it can become a specific message, meeting agenda, CRM status, and first service task. Keep a separate path for sales outreach so the technical work does not turn into a generic pitch.
A DMARC prospecting report broken into domain, DNS, senders, risk, and next step.
What the report should include
Use the same report structure for almost every cold lead because repeatability matters in MSP delivery. The details change by domain, but the sections stay consistent. That makes QA easier, keeps sales from improvising, and helps the service desk understand what was promised if the lead becomes a client.
|
|
|
|---|---|---|
Summary | Follow-up priority, evidence confidence, and top findings | Creates the meeting reason |
DMARC | Applicable policy, reporting URI, alignment modes, and subdomain or test-mode tags | Shows reporting and enforcement state |
SPF | SPF record count, lookup-term count, and syntax errors | Finds fragility and sender sprawl |
DKIM | Tested selectors, lookup results, and visible keys | Documents what public DNS can confirm |
Reputation | Domain and confirmed outbound IP listings, with list names | Adds delivery context |
Plan | Next service step and verification owner | Turns findings into accountable work |
Keep each section short enough for a non-technical owner to scan.
Use qualitative priority bands unless your MSP has documented numerical scoring weights. The band helps a sales or account team prioritize follow-up; it does not measure breach likelihood or inbox placement. Assess reporting visibility separately from enforcement: p=none with rua requests monitoring, but does not request quarantine or rejection. Pair each finding with an evidence-confidence label. Treat an untested DKIM selector or an undiscovered sender as unknown, not failed.
Prospecting priority bands
Apply the highest confirmed condition. These bands prioritize public configuration reviews; they are not a security rating. Leave unresolved DNS results unscored until retested.
Low
Routine review
An effective quarantine or reject policy and aggregate reporting request exist, with no confirmed DNS error. Sender authorization remains unverified.
Medium
Planned follow-up
Monitoring-only policy, missing reporting, or SPF close to its lookup limit warrants review, with no high-priority condition confirmed.
High
Priority follow-up
No applicable DMARC policy, a confirmed policy error, or a confirmed SPF error or +all condition warrants prompt review.
Do not overstate what public DNS proves
A public lookup can show configuration risk. It cannot prove every legitimate sender, message-level alignment, failure volume, or abuse attempt. Mark unknowns clearly and make monitoring the next step.
Do not use the historic pct tag as a rollout control. Stage enforcement through documented policy changes after reviewing representative report data, then retest each change. RFC 9989 also cautions against p=reject for general-purpose mail, especially users of Internet mailing lists. Confirm forwarding and mailing-list behavior before recommending a policy; receiver decisions and inbox placement are not guaranteed.
How to collect the evidence
Start with the domain, not the company story. Run a public health check, capture the exact DNS state, then add a short note about what the result means. Suped's domain health checker gives the MSP a consistent starting point for DMARC, SPF, and tested DKIM selectors. Keep untested selectors marked unknown.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
For each domain, capture the exact query name, UTC collection time, returned record values, TTL, and DNS response status. Treat timeouts and SERVFAIL as unresolved, not missing records. Retest before the review call and show both snapshots if DNS changed after outreach. This avoids presenting an old lookup as the current state and makes remediation easier to verify.
For SPF, check for multiple SPF records, +all, and the 10 DNS-query-term limit, including nested include and redirect evaluation. This is a limit on evaluated lookup-causing terms, not the number of visible includes or individual DNS packets. Exceeding it returns permerror. Check the actual envelope sender domain when message evidence becomes available. See RFC 7208.
For DKIM, record every tested selector and follow any CNAME to the key. A miss at a guessed selector does not establish missing DKIM. With a delivered message, use its DKIM-Signature s= and d= values to query selector._domainkey.signing-domain and confirm the signature. See RFC 6376.
For DMARC reporting, a rua address shows a request, not successful delivery or review. If the destination uses a different organizational domain, verify the external reporting authorization required by RFC 9990. Ask the client to confirm receipt and review ownership after engagement.
Illustrative monitoring record, not a live lookup resulttext
Host: _dmarc.example.com Type: TXT Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com
If no applicable policy is found, show a sample monitoring-stage record and explain that reporting comes before an enforcement decision. Replace the sample address with a confirmed reporting destination before any approved DNS change. If the prospect already has a quarantine or reject policy, review reporting and sender coverage before recommending a change.
- Pick the primary domain and known mail subdomains. Check the applicable inherited policy before labeling a subdomain as missing DMARC.
- Check DMARC, SPF, tested DKIM selectors, MX, and visible reputation signals. MX identifies inbound routing; it does not establish outbound sending IPs.
- Save exact record values, query names, screenshots, UTC collection time, TTL, and response status.
- Group each finding by reporting, authentication, enforcement, or reputation.
- Write the next MSP service step in plain language.
A HubSpot CRM company record with DMARC prospecting fields for a cold lead.
Separate observations from authorization
A public scan records published DNS state. It does not confirm sender authorization, production DKIM signing, message-level alignment, or ownership of a listed IP. Confirm those points with DMARC aggregate data, delivered-message headers, the prospect's sender inventory, and a named client owner after engagement.
|
|
|
|---|---|---|
Publicly confirmed | Exact DNS result observed at a recorded time | Cite the query and retain the result |
Needs message evidence | SPF or DKIM alignment and production signing | Review aggregate data or message headers |
Needs client confirmation | Sender owner, business purpose, expected volume, and retirement state | Assign an owner and record the decision |
Approved change | A specific remediation has client authorization | Record approval, change window, and retest result |
Use a status field so every claim shows its evidence boundary.
When the lead becomes a client, retain the prospecting snapshot as the baseline. Add a finding owner, approval status, implementation date, and retest evidence to each open item. A public observation can justify a review, but it does not authorize a DNS change.
How to write findings a prospect will trust
The strongest findings are specific and modest, with a clear service action. Write each one as a small operational note: what was observed, why it matters, what should happen next, and what access is needed to confirm it.
For cold leads, avoid language that assumes compromise. Also avoid hiding behind acronyms. The owner of a small business does not need a lecture on RFC mechanics. They need to know whether anyone is reviewing authentication results and whether their domain can move toward enforcement without breaking legitimate mail.
|
|
|
|---|---|---|
No applicable DMARC policy | No usable policy found after discovery | Confirm scope, then propose a monitoring record |
p=none | Monitoring-only policy; reporting requires rua | Map senders before an enforcement decision |
No rua | This policy requests no aggregate reports | Confirm current monitoring, then propose reporting |
SPF near or over limit | Near 10 lookup-causing terms, or permerror on a tested path | Document the count and review nested senders |
DKIM unknown | Production signing not confirmed | Obtain a message or confirmed selector |
Blocklist (blacklist) listing | A named list reports the domain or confirmed outbound IP | Verify sending use and investigate the listing |
Use this as a finding library for first-pass prospecting reports.
A six-step flow for creating a DMARC prospecting report.
A good finding sounds like service delivery
Write: "The DMARC policy found during this lookup does not request aggregate reports. That leaves a gap in DMARC reporting visibility, but does not tell us what your team already monitors. The first step is to confirm existing monitoring, route reports to an agreed destination if needed, identify legitimate senders, and then decide whether a policy change is appropriate."
A one-page DMARC prospecting report example
Use this illustrative template for a monitoring-only domain. The values below are examples, not a live assessment. Replace every placeholder and retain supporting DNS output in the evidence appendix.
Example report summary and findingtext
DMARC prospecting report: {{company}} Domain: example.com Scope: Public DNS snapshot; no mail or admin access Checked: {{checked_at_utc}} DMARC query: _dmarc.example.com TXT Observed value: v=DMARC1; p=none Priority: Medium, planned follow-up Confidence: High for this DNS observation only Finding: The policy requests no enforcement and no aggregate reports. Business relevance: It provides no DMARC report feed for sender review. Unknown: Legitimate senders, message authentication, existing monitoring. Proposed service: Confirm monitoring, enable reporting if approved, and review senders across a representative business sending cycle. Deliverable: Sender inventory, authentication issues, policy recommendation. Prospect input: Named mail owner; DNS approval if a change is agreed. Next step: 15-minute review to confirm scope and service fit. MSP owner: {{owner}} Review date: {{review_date}}
Keep each finding tied to its own evidence. High confidence in a DNS observation does not establish compromise or complete sender coverage. Keep optional SPF or reputation findings out of the summary unless they change the recommended next step.
Where Suped fits in the workflow
Suped's product supports this MSP workflow across prospecting, onboarding, monitoring, and client reporting. Teams can use Suped to create prospect reports, move accepted leads into DMARC monitoring, manage hosted records and SPF, review blocklist (blacklist) monitoring, configure alerts, and manage clients in a multi-tenant workspace.
Create prospecting report dialog with MSP logo, prospect name, domains, prospect logo, and language fields
MSPs need repeatable output. A technician or sales operator can enter a prospect name, domains, logos, and language preferences, then produce a consistent report. Retain the public assessment as the baseline when the lead moves into onboarding.
- Create a clean report before the lead has provided access.
- Move accepted leads into ongoing domain monitoring and sender review.
- Use hosted SPF, SPF flattening, hosted MTA-STS, and Hosted DMARC when the client needs simpler DNS operations.
- Turn findings, alerts, policy status, and progress into client-ready updates.
Keep the sales promise close to the service work
If the report says the next step is sender discovery, your delivery team needs a runbook for sender discovery. If it says the next step is policy staging, your team needs the monitoring data and change controls to support that move.
Turn the report into outreach
The report should feed a specific sales motion. Tag each prospect with the highest-value finding, evidence status, service action, and follow-up owner. That lets a business development person send a concise note without inventing the technical reason.
For example, no applicable DMARC policy maps to a monitoring setup offer. A domain at p=none with no clear sender inventory maps to sender discovery. A confirmed SPF lookup issue maps to sender review and DNS simplification. For a broader prospecting process, keep your domain checks tied to a repeatable CRM status and next step.
Cold outreach outlinetext
Subject: Quick DMARC check for {{company}} I checked the public DNS for {{domain}} at {{checked_at_utc}}. The applicable DMARC policy did not include a rua reporting address. That policy does not request aggregate authentication reports. I put together a short report with the record and lookup time. Could we spend 15 minutes confirming your current monitoring and whether a reporting setup would be useful?
The report is stronger than a generic email because it gives the prospect a reason to respond. The outreach should mention one finding, one consequence, one review agenda, and one next step. Do not attach a twenty-page PDF unless your sales process has proven that format works for your audience.
- Name the domain or finding, not a generic security phrase.
- Say what you checked and when you checked it.
- Use one finding and one operational consequence.
- Request a short review, not a vague discovery call.
Use the report as the onboarding checklist
Once the prospect agrees to the review, the report becomes the opening checklist for service delivery. Confirm the records, agree on the monitoring window and reporting owner, identify senders, and fix authentication gaps. Include infrequent business mail, such as monthly invoicing, before deciding whether policy changes are appropriate. Record client approval and a rollback plan before changing DNS.
Frequently asked questions
One to three pages is enough for most cold leads. Include a summary, the main findings, visible DNS evidence, and the recommended next step. Keep deeper technical notes for the review call or onboarding.
Yes. A prospecting report can use public DNS and reputation evidence. Mark sender authorization, production DKIM signing, message-level alignment, and failure volume as unknown until monitoring or delivered-message evidence is available.
First confirm that no inherited policy applies. For a domain used to send mail, propose a monitoring-stage DMARC record with aggregate reporting, then review a reporting window that covers its sending cycle before deciding on enforcement. Publish only after the client approves the change.
Yes. A message passes DMARC when SPF or DKIM passes with the required domain match to the visible From address. Record visible SPF risks and scoped DKIM selector checks, but use message evidence to confirm production behavior. Configure both authentication methods for legitimate senders; SPF alone is not a suitable basis for a reject policy.
Use Suped's prospecting report workflow to create a consistent report for the lead, then move accepted prospects into monitoring, hosted record management, alerts, and client reporting as part of ongoing service delivery.
