About TamingDNS
Who builds it, why it exists, and what we stand behind.
Last updated: July 2026
Who runs this site
Paul Ogier, Technical Director at Outsource House (OSH.co.za) in Cape Town.
I've been running Google Workspace for SMB clients since 2008, Microsoft 365 since 2011, and deploying DMARC and SPF flattening for clients since 2013. Deliverability has been the recurring pain the whole time. TamingDNS is the toolkit I kept wishing existed: somewhere to throw a domain at SPF, DKIM and DMARC and get a straight answer instead of a marketing funnel.
The tools here are free and stay that way. If you've run the checks, found the problem, and now need someone to actually deploy DMARC, align SPF and DKIM, or unbreak a domain that isn't reaching the inbox, that's what OSH does day-to-day. Mail us at [email protected] with the domain and a sentence about what's going wrong.
Find me: LinkedIn · LinkedIn (OSH) · GitHub
Why it exists
The big commercial deliverability suites are good. They also assume you have a budget and a procurement cycle. Most of the people who land here don't. They're usually an IT manager whose CEO just had a payroll mail bounce off Microsoft 365 at 4pm, and they need an answer before close of business.
That's who this site is for. One click, an honest diagnosis, and somewhere obvious to click next.
Who this is for, and who it isn't
It's for the accidental admin: the IT generalist who picked up email because nobody else wanted to. The MSP technician halfway through a deliverability ticket with the client's CEO breathing down their neck. Or the consultant who needs to sanity-check an SPF chain before billing for the fix.
It's not for an enterprise security team with a SIEM, a dedicated mail engineer and a six-figure deliverability contract. Those teams already run Proofpoint, Valimail, Red Sift or MXToolbox. Those products are excellent and TamingDNS isn't trying to replace them.
If you've ever Googled "why is my Gmail bouncing" at 4pm on a Friday, you're who I built this for.
A few rules I try to hold to
- Every recommendation traces back to an RFC, a provider's published rule, or something I've reproduced in a real client environment. If I can't show you the source, I won't claim it.
- DKIM, DMARC, MX, DNSSEC and BIMI checks run client-side in your browser over DNS-over-HTTPS. The server-side tools (email headers, bounce decoder) throw your input away the moment they've parsed it. Specifics are in the Privacy Policy.
- No paid tier, no premium PDF behind an email gate, no "upgrade to see the rest of the result". What you see is what's there.
- The same DNS and email-auth checks also run over a free MCP server, so an AI agent (Claude, Cursor, even a cron job) can call them directly and get the same grade the website does, without a key.
- If a check is wrong, tell me at [email protected]. Every correction you send makes the tool better for the next person who runs the same check.
What you won't find here
- No signup wall. No newsletter capture between you and your result.
- No "register to download the full PDF". The full result is the page you're already looking at.
- No upsell to a paid tier with the real features hidden behind it. There's one tier. It's the free one.
- No tracking pixels chasing you around the web. GA4 for aggregate visit counts, and that's the end of it.
How the tools are tested
Every checker has a corpus of known-good and known-broken domains I run against it before pushing changes. SPF goes against domains with deliberate permerrors (multiple records, +all, 11+ DNS lookups). DKIM goes against domains with revoked keys, RSA-1024 weakness, and senders that simply don't sign. MX goes against domains running M365, Workspace, Proofpoint, Mimecast, and a few legacy on-prem Exchange holdouts.
The DNS layer queries three independent DoH resolvers (Google, Cloudflare, Quad9) in parallel. If they disagree, the page shows a consensus banner rather than picking a side. The commercial monitoring suites do the same thing internally. The difference is they don't tell you when it happens.
When a provider announces a policy shift (Gmail and Yahoo's Feb 2024 bulk-sender rules, Microsoft's PTR enforcement in May 2025, the rolling DMARC enforcement at the inbox providers), the affected checker gets a regression test that locks in the new behaviour before the change ships.
How recommendations are kept current
The major providers (Google, Microsoft, Yahoo, Apple) change their inbound rules faster than the RFCs do. I re-check the rules on each tool page whenever one of them announces a change, and I sweep through all of them every quarter regardless. Anything that's drifted gets corrected.
The DKIM selector dictionary, now over 100 providers, grows from live observation. When I spot a new selector belonging to a legitimate sender, it goes in.
Legal & contact
Operator: Outsource House, Cape Town, South Africa.
Email: [email protected]
Parent: OSH.co.za, the email deliverability and DMARC consultancy this all came out of.
Data: see the Privacy Policy for what each tool sends, where it goes, and how long it lives. (Short version: it doesn't.)