A DNS lookup is the cheapest diagnostic in deliverability and the one people skip, because it feels like infrastructure trivia rather than a sending problem. It is a sending problem: a domain with no MX record looks like a domain that cannot receive mail, and a sender who cannot receive mail looks disposable.
What each record tells you
| Record | What it does | Why it matters when sending |
|---|---|---|
| MX | Where mail for the domain is delivered | No MX means replies and bounces go nowhere, and receivers treat the domain as suspect |
| TXT | Holds SPF, DKIM and DMARC | The one place to confirm all three are actually published |
| A | Points the domain at a web server | A sending domain with no website looks purpose-built for outbound |
| NS | Which nameservers are authoritative | Editing DNS at the wrong provider is why a “published” record does not resolve |
| CNAME | Aliases, including tracking domains | A broken tracking CNAME breaks link tracking and can flag messages |
The misconfigurations a lookup catches
No MX on a sending domain. Common on freshly registered lookalike domains where someone set up sending and never set up receiving. It guarantees you never see replies or bounces, and it is a negative signal in its own right.
Records edited at the wrong nameserver. If the domain’s NS records point to a registrar you are not editing, everything you publish resolves to nothing. Check NS first when a record you are certain about does not appear.
A missing A record. A sending domain that resolves to no website at all is a pattern receivers recognise. Point it at a simple redirect to your main site.
A broken tracking CNAME. Custom tracking domains need a CNAME that resolves; when it does not, links break and the message carries a dead host. Setting one up properly.
Propagation confusion. A record can be correct and not yet visible. Check the TTL before assuming something is wrong, and re-check rather than republishing. Republishing during propagation is how duplicate SPF records get created.
When to run one
- Before a new domain sends anything. MX, SPF, DKIM, DMARC, A. Five checks, two minutes.
- When one domain in an estate underperforms. A per-domain difference in reply rate is a DNS or reputation difference far more often than a copy difference.
- After any DNS change, once TTL has elapsed.
- When a placement problem has no obvious cause. Confirm the records resolve before rewriting copy. Then test placement.
At scale this is exactly the kind of check that stops getting done: nobody manually verifies five records across forty domains every month, which is why managing DNS in bulk matters more than any individual lookup.
Next: grade all four records at once, check SPF, or MX records across many domains.
Frequently asked questions
Do I need an MX record on a cold email sending domain?
Yes. Without one, replies and bounces have nowhere to go, and receivers treat a domain that cannot accept mail as suspect.
Why does my DNS record not show up in a lookup?
Either you edited it at a provider that is not authoritative, check the NS records, or the TTL has not elapsed. Re-check rather than republishing, because republishing during propagation is how duplicate SPF records appear.
Does a sending domain need a website?
It needs an A record that resolves. A domain with no website at all is a recognisable outbound-only pattern; a simple redirect to your main site is enough.
Which records should I check before a new domain sends?
MX, the TXT records holding SPF, DKIM and DMARC, and an A record. Five checks and about two minutes.
What breaks a custom tracking domain?
A CNAME that does not resolve. Links break and the message carries a dead host, which is worse than not using a custom tracking domain at all.