I Built an Email Deliverability Tool Nobody Asked For
Introducing SendReady, my free tool for checking email deliverability attributes like SPF, DKIM, and DMARC records.
A few years ago, I was knee-deep in a marketing tech stack migration when someone from IT pinged me: “Hey, did you update the SPF record for that new tool?”
I… had not.
Cue the frantic DNS lookup, the realization that we were one include: statement away from hitting the 10-lookup limit, and the growing suspicion that nobody actually knew if our DMARC was configured correctly. We patched it together, moved on, and I made a mental note: someone should build a simple tool for this.
That someone turned out to be me. Several years later.
Meet SendReady
SendReady is a free email deliverability checker I built to validate the stuff that breaks email delivery: SPF, DKIM, DMARC records, and the one-click unsubscribe headers that Gmail and Yahoo now require.
Is it needed? Honestly, probably not. There are plenty of tools out there. But I built it anyway.
Why Build Something That Already Exists?
Three reasons:
1. I wanted to see if I could.
I started this project ages ago, got 60% of the way there, and abandoned it like every other side project in my graveyard of half-finished ideas. When Claude Code came along, I decided to dust it off and see what was possible. Turns out, a lot.
2. It would have been useful at a previous job.
At a past company, every time we added a new tool to the martech stack, someone had to manually check if we’d broken email authentication. Usually that “someone” was me, usually at 4pm on a Friday, usually after emails had already started bouncing. A simple spot-check tool would have saved some headaches.
3. Why not?
Yes, I know MXToolbox exists. And Mail-Tester. And Learndmarc. And dmarcian, EasyDMARC, DMARCLY, Google Postmaster Tools, and roughly forty-seven other options. But adding one more free tool to the internet felt like a reasonable use of my evenings. The journey was the destination, or whatever.
What SendReady Actually Does
It checks four things:
SPF – Is your Sender Policy Framework record valid? Are you approaching the 10-lookup limit?
DKIM – Is your DomainKeys Identified Mail signature set up correctly?
DMARC – Do you have a DMARC policy, and is it actually enforcing anything?
Email Headers – Are your one-click unsubscribe headers present and properly formatted?
You can punch in a domain to check the DNS records, paste in email headers to validate them, and copy the results to share with your team or save for documentation.
That’s it. Just a tool that does a thing.
What About My Data?
Nothing is stored.
When you check a domain, SendReady does a DNS lookup, parses the results, and shows them to you. When you close the tab, that’s it! There’s no database saving your queries, no history of what you checked, no profile being built.
Same with header validation. Paste in your email headers, get the results, and when you leave, the data goes with you. I’m not logging the domains you check or the headers you paste. There’s no backend collecting anything.
The only analytics running is Netlify Analytics, which is server-side and doesn’t use cookies or track individual users. I can see aggregate page views but not who you are or what you checked.
I built it this way on purpose. DNS records are public anyway (anyone can look them up). And I didn’t want to deal with the complexity (or responsibility) of storing user data. So I just… didn’t.
Why Does This Stuff Matter?
If you send marketing emails—or really any bulk email—authentication records are table stakes now.
In February 2024, Gmail and Yahoo dropped the hammer on bulk senders. The new rules:
DMARC required – If you send more than 5,000 emails per day, you need a published DMARC policy.
One-click unsubscribe – Your emails must include
List-UnsubscribeandList-Unsubscribe-Postheaders that work with a single action.Spam rate threshold – Keep your reported spam rate below 0.3%, or your emails start getting rejected.
Microsoft followed suit in May 2025, starting to outright reject (not just junk) non-compliant emails.
For most companies with a simple tech stack, this is a “set it once and forget it” situation. But if you’re managing multiple sending platforms (HubSpot, Salesforce, SendGrid, Mailchimp, that one-off transactional email service your engineering team spun up three years ago) things get complicated. Every new tool needs an include: in your SPF record. Every vendor change risks breaking DKIM. And DMARC? Most people set it to p=none and never look at it again.
SendReady won’t solve all your problems, but it’ll at least tell you if something’s broken.
How It Works Under the Hood
If you’re curious about the actual mechanics: it’s simpler than you might think.
SPF, DKIM, and DMARC are just DNS records. They’re TXT records sitting in public DNS that anyone can query. When you enter a domain, SendReady runs DNS lookups using Node.js’s built-in dns module:
SPF lives at the root domain. The tool looks up the TXT record and parses it—checking that it starts with
v=spf1, counting how many DNS lookups are chained together (you’re limited to 10), and flagging if you’re using a permissive+allinstead of-allor~all.DKIM lives at
selector._domainkey.yourdomain.com. The tricky part is that the “selector” varies by email provider—Google usesgoogle, HubSpot useshubspot, others uses1,selector1, etc. SendReady checks the common ones.DMARC lives at
_dmarc.yourdomain.com. The tool parses the policy (p=none,p=quarantine, orp=reject) and checks if you’ve set up a reporting address.
For header validation, it’s even simpler—just string parsing. You paste in raw email headers, and the tool looks for List-Unsubscribe and List-Unsubscribe-Post headers, then checks if they’re formatted correctly for one-click unsubscribe compliance.
No external APIs. No third-party services. Just querying the public DNS infrastructure that already exists and parsing text. The internet already has all this information—SendReady just makes it easier to read.
The Tech Stack
For anyone curious about how it’s built:
Framework: Next.js 16.1.1 with Turbopack
Language: TypeScript
UI: React 19.2.3 with Tailwind CSS 4
Components: Radix UI (Dialog, Tabs, Labels, etc.)
Icons: Lucide React
Forms: React Hook Form + Zod validation
Toasts: Sonner
Analytics: Netlify Analytics (server-side, no cookies)
DNS lookups: Node.js dns module
The DNS checking logic is custom—just standard TXT record lookups and parsing. Nothing fancy, but it works.
The Claude Code Factor
I over-engineered this thing when I first tried building it. The original version had features nobody needed, architectural decisions that made no sense, and enough technical debt to fund a small startup.
When I picked it back up with Claude Code, there wasn’t anything I would call a technical breakthrough. It was realizing I’d been building for some imaginary perfect use case instead of just… shipping something useful. Claude helped me strip out the complexity, add features that actually mattered (like the header validation), and push it way past the finish line I’d been staring at for years.
Is the code perfect? No. Does the tool solve a problem well enough to share? Yes. That’s the bar I was going for.
How to Use It
Pretty simple:
Domain Checker – Enter a domain to check SPF, DKIM, and DMARC records. You’ll get a pass/fail status with details on what’s configured (or misconfigured).
Header Validator – Paste raw email headers to check if your one-click unsubscribe setup is compliant.
Copy Results – Hit the copy button to grab the results for documentation, a Slack message, or a ticket to your IT team explaining why their DNS changes broke email again.
Use it when you need it. Hopefully that’s not often.
🥚?
There might be a few easter eggs in there.
Got thoughts? Complaints? Feature requests? I’d love to hear from you. Drop me a message! I’m always curious what other people are dealing with in the deliverability trenches.
And if you’re staring at a broken SPF record at 4pm on a Friday, I hope this tool saves you a few minutes.
