You run the audit. The results come back. SPF: Fail. DMARC: Not configured. Blacklist status: Listed on 3 databases.

You stare at the screen. The tool has done its job. It found the problems. Now what?

There is no "what." The tool stops there. The next step is yours: figure out what the record should say, find the right panel in your DNS provider, format it correctly, and hope propagation confirms the fix worked. Most teams open a new tab and start Googling. Some open a support ticket and wait. Some close the browser and move on.

The audit found the problem. The problem stays unfixed.

This is not a small gap. It is the reason email deliverability issues persist for weeks at companies that have already run three separate audits. The diagnostic and the remedy are disconnected, and almost no tool in this space has tried to close that gap — until you understand why.

The Diagnostic Business Model

Most DNS and email security tools were built by network engineers for network engineers. The design assumption is that whoever runs the audit knows what to do with the results.

That assumption made sense in 2008. DNS was managed by sysadmins who had memorized RFC 7208 and could write a DKIM TXT record from scratch. The tool's job was to surface the data. The engineer's job was to interpret and fix it.

The market has changed substantially. Today, DNS is managed by:

• Founders at early-stage SaaS companies who registered the domain themselves
• Marketing managers who inherited the domain when the previous IT person left
• Office administrators at 40-person logistics companies who have DNS access because someone has to
• Developers who know their stack cold and DNS not at all
• MSPs managing 80 client domains across 12 different registrars

None of these people want a DNS audit result. They want to know what to type and where to type it.

The tool vendors didn't adapt because their core customers — enterprise security teams, MSSPs, large IT departments — didn't need them to. The diagnostic was sufficient. The rest of the market was either too small to matter or too fragmented to serve with a standardized fix.

What "Not Giving You the Fix" Actually Looks Like

Here is what a standard DNS audit result looks like across the tools most people use:

MXToolbox

SPF Record Published: YES
SPF Contains characters after ALL: ERROR
SPF Record Syntax Check: ERROR

Useful diagnostic. Clear that something is wrong. No indication of what the correct record should say.

Google Admin Toolbox (CheckMX)

✓ Domain has SPF records
✗ Domain's SPF record does not include all sending sources

Accurate. Clean output. Still no record to copy.

dig (command line)

$ dig TXT yourdomain.com +short
"v=spf1 include:sendgrid.net ~all"

Shows you the current record. Does not tell you what's missing or what to add.

Generic audit PDF from a compliance scanner

Finding: SPF record missing include for third-party ESP
Severity: High
Recommendation: Update SPF record to include authorized sending services

The recommendation is technically correct and operationally useless.

In every case, the tool has correctly identified that something is wrong. In no case does it tell you the specific string to add to your DNS provider's TXT record field.

Why the Fix Is Harder Than It Looks

Giving an actionable fix is not a UI decision. It requires solving several non-trivial problems simultaneously.

Problem 1: The fix depends on your sending stack

An SPF record is not a universal string. It is a list of the specific mail servers authorized to send on your behalf. If you use SendGrid, the correct include is include:sendgrid.net. If you use Google Workspace, it is include:_spf.google.com. If you use both, plus Mailchimp and a Salesforce marketing instance, the record has to cover all of them — and stay under the 10 DNS lookup limit.

A generic audit tool has no idea which ESPs you use. It can tell you your SPF is broken. It cannot tell you which services to add without knowing your sending infrastructure. The right approach is not to guess — it's to show you the email provider options and let you identify your own stack.

Problem 2: The fix depends on your DNS provider

Every DNS provider has a different interface. Adding a TXT record in Cloudflare is different from Route53. The field labels in GoDaddy are named differently. Namecheap's Advanced DNS tab splits host and value in a way that confuses first-time users. AWS Route53 requires TXT values wrapped in double quotes — a detail that breaks records silently when you get it wrong.

A fix that says "add this TXT record" without provider-specific steps leaves you to figure out the interface yourself. That step is exactly where non-technical users give up.

Problem 3: The fix has to account for what's already there

DNS records interact. Adding an SPF include without checking the current lookup count can push you over the 10-lookup limit and break SPF for every email you send. Adding a DMARC record without knowing your current DKIM alignment state can trigger quarantining of legitimate mail. The most common SPF mistake — creating a second TXT record starting with v=spf1 instead of editing the existing one — instantly invalidates both records and breaks all email delivery.

A correct fix requires reading the existing zone state, not just flagging a missing record.

Problem 4: Building the provider database has no clear ROI for most tools

Every DNS provider has its own UI patterns, field naming conventions, and record validation logic. Building and maintaining step-by-step instructions for Cloudflare, GoDaddy, Namecheap, Route53, DigitalOcean, Hostinger, and the rest — and keeping those instructions current as providers update their interfaces — requires ongoing investment.

For tools that charge per scan or sell to enterprise security teams, that investment has no direct revenue justification. The enterprise buyer doesn't need the step-by-step. The SMB buyer who does need it isn't the primary customer.

What a Real Fix Looks Like

Here is what the same SPF finding looks like when the tool gives you the actual remedy.

If you already have an SPF record, the fix shows your current record, modifies it correctly, and gives you the exact string to replace it with:

Your current record:
v=spf1 include:sendgrid.net ~all

Updated record (soft fail — recommended to start):
v=spf1 include:sendgrid.net ~all

Hard fail version (once you've confirmed all services pass):
v=spf1 include:sendgrid.net -all

If you don't have a record yet, the fix doesn't guess which email provider you use. Instead, it presents email provider tabs — Google Workspace, Microsoft 365, Zoho Mail, Fastmail, Protonmail, SendGrid, Amazon SES — each showing the exact include: value to add for that provider. You identify your own stack, pick the right tab, and copy the value.

Then, for adding the record to DNS, a second set of tabs covers each major DNS provider with numbered steps specific to that interface. For Cloudflare:

1. Log in at dash.cloudflare.com and select your domain.
2. Click DNS in the left sidebar.
3. Click Add record.
4. Set Type to TXT.
5. Set Name to @ (root domain).
6. Paste your complete SPF record into the Content field.
7. Leave Proxy status as DNS only (grey cloud). SPF records must never be proxied.
8. Click Save.

If a TXT record starting with 'v=spf1' already exists, click Edit on that
record instead of adding a new one — having two SPF records breaks all email delivery.

For Route53, the instructions include the detail that TXT values must be wrapped in double quotes in the Value field — a provider-specific requirement that isn't documented anywhere in the AWS console UI itself.

The person reading this does not need to know what SPF is, what RFC 7208 says, or how SMTP authentication works. They need to know what to copy and where to paste it. The fix guide is structured to make that possible.

The Provider Tab System, Across Every Check

This isn't limited to SPF. Every fix guide in ZeroHook's 30-point audit follows the same structure: a corrected record or configuration, email provider tabs where relevant, and DNS provider tabs with numbered steps for each interface.

The CAA guide is worth noting specifically: it reads your current SSL certificate to detect which certificate authority issued it, then pre-populates the CAA record with that CA's domain. If you're on Let's Encrypt, the record authorizes letsencrypt.org. If you're on DigiCert, it authorizes digicert.com. You're not choosing from a generic list — the fix is pre-filled from what your certificate already tells the system.

Why Continuous Monitoring Without Fixes Is a Treadmill

Most DNS monitoring tools alert you when something changes or breaks. That is genuinely useful. If your SPF record gets corrupted or someone removes your DMARC policy, you want to know immediately.

But alerting without fixing creates a loop:

Alert fires → Team acknowledges → Ticket opened → DNS person assigned
→ DNS person researches → Fix applied (maybe) → Next alert fires

At SMB scale, the "DNS person" is often whoever has the registrar login. The research step is where the fix dies. The ticket stays open until it gets closed as stale or until a deliverability problem becomes bad enough to force action.

Continuous monitoring solves the detection problem. Provider-specific fix guides solve the remediation problem. Without both, you have a very good early warning system for problems that don't get fixed.

The Economics of Staying Broken

Here is what a persistent DNS misconfiguration actually costs.

An e-commerce company sending 10,000 transactional emails per month with a 15% spam rate is losing roughly 1,500 emails to spam folders. If those emails contain order confirmations, shipping notifications, and password resets, the downstream effects are customer service contacts, abandoned carts, and churn from users who assume the product is broken.

Industry estimates put the revenue impact of a 1% deliverability improvement at $10,000–$100,000 per year depending on email volume and order value. A 15% spam rate is not a 1% problem.

The audit tool that tells you something is wrong but doesn't tell you how to fix it contributes nothing to that number. It identifies the cost without reducing it.

A fix takes five minutes with the right instructions. The fix is worth five minutes.

TL;DR

• Most DNS audit tools were built for engineers — the output assumes you already know how to fix what they find
• The fix is non-trivial to generate — it depends on your existing records, your email sending stack, and your DNS provider's specific interface conventions
• No major competitor builds the provider-specific fix database — it requires ongoing maintenance investment with no direct revenue justification for tools selling to enterprise teams
• The right approach is not to guess your stack — email provider tabs let you identify which include: values apply to your own setup; DNS provider tabs give you numbered steps for the interface you're actually looking at
• CAA and MX guides go one step further — they read your existing certificate and MX records to pre-fill the correct values before you touch anything
• Monitoring without remediation is a treadmill — alerts tell you something is broken; fix guides tell you what to type
• See it on your own domain, free: zerohook.org

*Part of an ongoing series on DNS security and email deliverability.