Run a lookup
How it works
Paste the hostnames
Use the full name, including the subdomain. A CNAME never exists on a bare domain that also has MX or NS records.
Query CNAME over DoH
The lookup runs client-side against public resolvers, so nothing is logged on my side.
Read the target
The target is shown exactly as published. Confirm it matches what your vendor's dashboard says it should be.
Check for dangling records
A CNAME whose target has been deleted is a live subdomain takeover risk, not just a broken link.
Where CNAMEs break on a sending setup
Two places, mostly. The first is tracking domains. Open and click tracking works by pointing a subdomain of yours at your sending platform, so links in your mail carry your domain rather than a shared one. When that CNAME is wrong, missing, or pointing at a platform you have since left, links either break outright or start resolving to somewhere you do not control. Both are worse for deliverability than having no tracking at all.
The second is hosted DKIM. Several providers publish your DKIM key on their own infrastructure and have you point a CNAME at it, so they can rotate the key without touching your DNS. That is a good design until the record is copied wrong, or until someone migrates providers and leaves the old CNAME in place. The signature then fails against a key that no longer exists, and because DKIM failures are usually silent, nobody notices until DMARC reports show alignment dropping.
Dangling CNAMEs are a security problem
A CNAME pointing at a hostname that has been deleted is not merely broken. On most cloud platforms, the target name can be claimed again by someone else — they register the same resource name, your CNAME starts resolving to their content, and they now serve pages from a subdomain of your domain. This is subdomain takeover, it is trivially automatable, and stale marketing and tracking subdomains are where it usually lives. If a lookup here returns a target you do not recognise or a target that fails to resolve, delete the record.
Why a CNAME cannot sit on your root domain
The rule is that a name with a CNAME may have no other records. Your root domain must carry NS and SOA records, and almost certainly MX records, so a CNAME there is invalid by definition. Providers that appear to offer it are using a non-standard flattening trick that resolves the target and publishes the result as an A record. That works, but it means the answer is now a snapshot rather than a live pointer — worth knowing when a change at the far end does not appear to take effect.
Frequently asked questions
Why does my CNAME not resolve?
Common causes, in order: the record was added at the wrong level so the name ended up duplicated, such as track.example.com.example.com; the target does not exist; or another record type exists on the same name, which makes the CNAME invalid. The lookup here shows what is actually published, which usually makes the first case obvious immediately.
Can I have a CNAME and an MX record on the same name?
No. A name with a CNAME cannot have any other record type. If you need MX on a name, use A or AAAA records rather than a CNAME. This is the constraint that stops you putting a CNAME on your root domain.
What is a dangling CNAME?
A CNAME whose target no longer exists. It is a security issue rather than a cosmetic one, because on many cloud platforms an attacker can register the abandoned target name and start serving their content from your subdomain. Delete stale CNAMEs rather than leaving them.
Does a tracking domain CNAME affect deliverability?
Yes. Links in your mail resolve through it, and receivers assess the reputation of the domain those links point to. A broken or misconfigured tracking CNAME means links that fail to load, which looks worse to a filter than plain unwrapped links. The tracking domain checker grades the whole setup rather than just resolving the name.
Should DKIM use a CNAME or a TXT record?
Either works. A CNAME lets your provider rotate keys without you touching DNS, which is genuinely useful at scale. A TXT record puts the key under your control. What matters is that only one of the two exists for a given selector, and that it matches whatever your provider is currently signing with.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace and Microsoft 365 inboxes
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.