Skip to main content
We Built TamingDNS.com Because Our Clients Were Too Polite
field note · Email Security · Tools

We Built TamingDNS.com Because Our Clients Were Too Polite

OSH built TamingDNS.com because existing DNS tools explain nothing to a non-engineer. Here is why we made it and what it changed for our clients.

Paul Ogier · founder 18 May 2026 4 min read

There is a specific face clients make when you show them a raw DNS lookup result. Mouth slightly open, eyes tracking left to right across a wall of text, a slow nod that says “yes, I see the problem” while communicating nothing of the sort. I have watched that face across hundreds of support calls. For an embarrassingly long stretch of my career, I took it as confirmation that I had explained the situation well.

I had not.

DNS tools are built for people who already know the answer

Every standard DNS diagnostic tool assumes you arrived with a working hypothesis. You type a domain, you get output, and if you know what you are looking at, it is useful. If you don’t, you are reading an airport departures board in a language you have never studied.

MXToolbox is excellent if you are the kind of person who enjoys reading MXToolbox. Most clients are not that person, and that is not a criticism of them.

OSH has been untangling email delivery problems since before DMARC was a word most IT managers could spell. SPF records with too many lookups. DKIM keys rotated once, then abandoned. DMARC policies set to none three years ago, still sitting at none like a security measure that lost the will to live. These are not exotic problems. They are Tuesday.

Finding the issue was never the challenge. Explaining it to someone who needed to act on it, without turning them into a DNS engineer in the process, was.

A confession about tabs

Open MXToolbox for the MX records. Open a DKIM validator. Open a DMARC analyser. Open a separate SPF lookup counter because the first three do not cover that. Open one more tab because it turns out four is not enough. Spend fifteen minutes assembling a complete picture from five sources, each with its own colour scheme and its own threshold for what counts as a warning. Then present the assembled findings to a client using the calm, unhurried tone of someone who had absolutely not just done all of that.

I counted the tabs one afternoon and sat with the number for a while.

What we built instead

TamingDNS.com takes a domain and runs it against the full set of email deliverability checks in one pass: SPF, DKIM, DMARC, blacklist status, reputation, reverse DNS, MTA-STS, DNSSEC, and Google and Yahoo’s 2024 bulk sender requirements. It returns a compliance score out of 100, broken down by category, plus inbox placement predictions showing where your mail is likely landing at Gmail, Outlook, and Yahoo right now.

The score is the part clients actually respond to. Sixty-three out of a hundred is information a person can act on. “Your SPF record has a syntax error and your DMARC policy is set to none” is information that requires a translator.

There are twenty-six tools on the site in total, covering everything from DMARC report analysis to bounce code lookup to a Microsoft 365 audit. We use most of them. The homepage checker is where almost every client conversation starts.

We built it for ourselves first, which is usually a sign you have identified a real problem rather than an imaginary one.

What it changed for our clients

A client came to us after six weeks of chasing their previous IT provider about email landing in spam. Not sometimes. Consistently. The provider’s response, repeated with impressive confidence across four separate emails, was that everything looked fine on their end.

We ran the domain on TamingDNS. Forty-one out of a hundred. Their SPF record had an include pointing to a mail platform they had stopped using in 2022. Their DMARC policy had been sitting at none since the record was created, which meant it was doing absolutely nothing except existing. Their IP had a soft blacklist entry that had been sitting there for four months.

All of it was publicly visible, for anyone who ran a lookup. The client watched us find it in about ninety seconds and had a specific, understandable question: why had nobody looked?

We fixed the SPF record, pushed the DMARC policy to quarantine, and submitted the blacklist removal request. The email that had been bouncing for six weeks stopped bouncing the next morning. If you want to understand the DMARC side of that fix in more detail, we cover a lot of your questions on the DMARC page.


Run your domain at TamingDNS.com. It is free and takes about half a minute. If everything comes back clean, good. If it does not, at least you will know what you are looking at, and so will we, without needing five tabs to show you.

Ready to migrate?

Whether you need a full M365 migration plan or a security audit, our team is ready to architect your cloud future.

Email us directly support@osh.co.za