MSP Operations
Why "I Already Use a Free DMARC Tool" Is the Start of the Sales Conversation, Not the End of It
August 28, 2026
Ric Hall, CRO— AI-assisted and reviewed prior to publication.

A prospect says it almost like a shield: "We already use a free DMARC tool." For an MSP account manager, that line can feel like the end of the conversation. It should not. In most cases it means the prospect has installed a smoke detector and assumed the fire department is no longer needed. The sale that follows isn't about convincing them DMARC matters. It's about showing them the difference between seeing a problem and closing it.
Does a Free DMARC Tool Actually Protect the Domain?
Usually not, at least not on its own. Most free DMARC checkers parse aggregate reports and confirm a record exists, but the domain typically still sits at a monitoring-only policy that lets spoofed mail through untouched. A record with no enforcement is a smoke detector without a sprinkler system: useful for noticing the fire, useless for stopping it.
That gap is not a minority pattern. Analysis of DMARC records across roughly 73.3 million domains found that only 14.9% had any DMARC policy at all as of December 2025, and just 2.5% had reached the strictest enforcement level of p=reject, according to Red Sift's global DMARC adoption research. Put another way, the vast majority of domains that bother to publish a DMARC record never finish the job.
What a Free Tool Actually Shows, and What It Skips
Free DMARC checkers earn their keep by decoding the aggregate reports (RUA) that mailbox providers send back, the XML summaries defined in the DMARC standard that describe which sources tried to send mail on a domain's behalf. That is genuinely useful. It is also roughly a third of the work.
The standard itself has grown more demanding, not less. In 2025 and 2026, the IETF split and updated the original DMARC specification into three documents on the Internet Standards Track, with RFC 9990 covering aggregate reporting and a companion RFC handling failure reporting, formally obsoleting the 2015-era RFC 7489. A protocol that just graduated to full Internet Standard status is not one a client should be managing off a bookmarked free dashboard.
In practice, a basic free tool typically stops short of several things an MSP client actually needs:
- Translating aggregate report data into specific SPF and DKIM fixes for every third-party sending source, from marketing platforms to helpdesk software to the accounting system.
- Tracking the safe, staged move from a monitoring policy to quarantine and then reject, without breaking legitimate mail in the process.
- Managing DMARC, SPF, and DKIM across every domain and subdomain a client owns, including parked and legacy domains attackers love to spoof.
- Alerting a human when a new unauthorized sending source shows up, rather than waiting for someone to log in and read a report.
None of that is a knock on free tools existing. Standards bodies and mailbox providers want that first step to be frictionless. It just means "we have a free tool" answers the question "do you have visibility," not the question "are you protected."
Why Enforcement Is Now a Business Requirement, Not a Best Practice
Because the mailbox providers stopped treating it as optional. Google's official sender guidelines require any organization sending 5,000 or more messages a day to Gmail addresses to authenticate with SPF and DKIM, with alignment tracked under DMARC, and non-compliant mail faces delivery problems, not just a warning label, as Google's Workspace Admin Help documentation makes clear.
Microsoft followed the same path. Starting May 5, 2025, Outlook began routing messages from high-volume domains that fail SPF, DKIM, or DMARC checks straight to the junk folder, a change Microsoft's own security team detailed in a Microsoft Tech Community post on the new sender requirements. That closed the loop: the two largest consumer mailbox providers on earth now expect enforcement-grade authentication as a baseline, not a security upgrade.
Government has moved in the same direction for years. The Department of Homeland Security's Binding Operational Directive 18-01 required federal agencies to reach a DMARC policy of p=reject within one year of the directive, according to CISA's own directive page, and PCI DSS v4.0 has since pulled payment processors into similar territory. None of these mandates are satisfied by a dashboard that only reports what already happened.
How Should an MSP Reframe the "We Already Have a Tool" Objection?
By asking what policy the domain is actually publishing today, and who is responsible for moving it forward. A prospect who can answer "p=reject, and here's who manages our third-party senders" has genuinely solved the problem. A prospect who says "I think it's set to monitor, someone set it up a while back" has a visibility tool and an unmanaged risk, which is a service gap, not a sale that has already been lost.
The size of that gap tracks with company size, which matters for how an MSP should qualify the lead. Comparative analysis from the EasyDMARC 2026 DMARC Adoption Report found that Fortune 500 companies had reached roughly 95% DMARC adoption with more than 80% at enforcement-level policies, while EasyDMARC's own release on the report notes that smaller, high-growth organizations lag significantly on the transition to enforcement. Most MSP clients look far more like the second group than the first, which is exactly why the free-tool objection is a lead qualifier rather than a lost cause.
| Typical free DMARC checker | Managed DMARC service | |
|---|---|---|
| Confirms a DMARC record exists | Yes | Yes |
| Decodes aggregate (RUA) reports | Yes, manually reviewed | Yes, continuously parsed |
| Identifies every third-party sender | Rarely | Yes |
| Guides policy from none to reject | No | Yes, staged and monitored |
| Covers subdomains and parked domains | Rarely | Yes |
| Alerts on new unauthorized sources | No | Yes |
| Accountable if enforcement breaks mail flow | No | Yes |
Turning the Objection Into a Managed Services Engagement
The conversation that works starts with curiosity, not correction. Asking to see the actual DMARC record, the current policy tag, and who reviews the reports each month usually surfaces the gap faster than any pitch deck. From there, the pitch is not "replace your free tool," it's "let's finish what it started."
A practical next step for any MSP building this into a service line is running a live domain scan during the sales call itself, since showing a prospect their own unresolved SPF and alignment failures in real time is more persuasive than any case study. ActiScan's own getting-started guide walks through that first scan and the policy-graduation sequence that follows, which is the same sequence CISA and the mailbox providers now expect. For MSPs pricing this as a recurring line item rather than a one-time project, the pricing page breaks down how per-domain monitoring scales across a client base of five domains or five hundred.
None of this requires promising a client total immunity from phishing or spoofing, and no managed DMARC service should claim to replace a client's security team or compliance function. What it can promise is a documented, monitored path from "a record exists" to "the policy is enforced and someone is watching it." For MSPs ready to package that as a service rather than a favor, the sign-up page is the fastest way to get a client's domains into a live scan and start that conversation with data instead of guesswork.
The free tool was never the competition. It was the opening move.