If you send from mail.yourcompany.com or email.yourcompany.com, most deliverability checkers are not testing the name you send from. They are testing the name you own. Those are different records, and on a correctly configured sending subdomain they can disagree completely.
We know because we shipped that bug ourselves, and the first domains it broke on were our own. This post is what we found and how to check yours.
What an in-zone subdomain actually looks like
Here is what DNS returns for two of our own names, queried today:
audit.humerly.com SOA no answer
audit.humerly.com NS no answer
audit.humerly.com A 2 records
mail.humerly.com SOA no answer
mail.humerly.com NS no answer
mail.humerly.com MX 1 record (10 mail.humerly.com.)Both names resolve. One serves a web app, one publishes a mail exchanger. Neither has an SOA or an NS record, and nothing is wrong with either — this is the ordinary shape of a name that lives inside its parent's zone. The parent, humerly.com, holds the SOA and the NS. The children hold their own records.
Now compare a subdomain that is delegated:
mail.protection.outlook.com NS 2 records
s3.amazonaws.com SOA 1 record, NS 4 recordsDelegated names carry their own NS. In-zone names do not. Both are valid, both are common, and the difference is invisible unless you look for it.
Where checkers go wrong
A lot of tooling establishes "does this domain exist" by asking for SOA or NS at the exact label. It is a reasonable-sounding test and it is the wrong question. SOA-or-NS does not ask does this name exist. It asks is this name a zone apex or a delegation point.
An in-zone sending subdomain is neither. So a checker built that way concludes the name does not exist, and then reports something that is not true about your DNS — that you have no records, or that the domain is unregistered, on a name that is publishing MX perfectly well.
The failure is quiet in the worst way. It does not error. It returns a confident negative about a domain that is configured correctly.
The obvious fix is a trap
The tempting correction is "accept any name that has any DNS record." That is worse, and it is worth understanding why before you trust any tool that claims to have fixed this.
Plenty of zones run a wildcard. Under a wildcard, every label answers — including labels nobody registered. Query a name you invented three seconds ago in such a zone and it will hand you a full set of records, MX and SPF included. A checker that accepts "has any record" will grade that invented name as a real sending domain.
The signal that separates them is that a wildcard answers identically for every unregistered label, while a real name's records are its own. In a wildcard zone the comparison looks like this:
mail.example.com MX → the zone's real mail records
<random-label>.example.com MX → an identical answer, for a name that does not existWhereas a genuinely configured subdomain returns records that differ from whatever the wildcard hands out. That difference is the whole test: query a random sibling label, compare, and if the answers match byte for byte, the records were synthesized rather than configured.
There is one more piece of DNS behaviour that makes this cheap. A wildcard cannot synthesize an SOA, and it cannot synthesize the NS records at a delegation point (RFC 4592 §4.2). So either of those settles a name outright, and the extra lookup only runs for the in-zone case — which is exactly the case that was broken.
We got this wrong, and fixed it
Our own audit tool used the SOA-or-NS test. It returned an error for every in-zone sending subdomain, including two of our own, and told them they had no DNS records configured. That was false, and it was false about the exact class of domain our customers send from.
It is fixed. The check now asks whether the name exists: an absent name is still rejected, a name with records of its own passes, and a name whose only records come from a wildcard is rejected with the reason stated. Apex domains cost the same single lookup they always did.
We are writing it up rather than quietly patching it because the same mistake is easy to make and hard to notice from the outside — the tool does not crash, it just tells you something untrue with confidence.
How to check yours
If you send from a subdomain, the fast manual version is three queries:
dig +short MX mail.yourcompany.com
dig +short TXT mail.yourcompany.com
dig +short MX $(openssl rand -hex 6).yourcompany.comIf the first two return records and the third returns nothing, you have a real in-zone sending subdomain. If the third returns the same records as the first, your zone has a wildcard and any checker that does not account for it is guessing.
Or run the whole thing, including SPF, DKIM, DMARC, TLS, PTR and MTA-STS, against the subdomain you actually send from:
Every record shown in this post was queried on 2026-08-13 from our own resolver, and the numbers are ours and only ours. Yours will differ — that is the point of checking them.