Check a domain
How it works
Paste your fleet
One domain per line. Email addresses work too — the domain is extracted automatically.
Six lookups each
NS, MX, TXT, DKIM selectors and _dmarc are queried over DNS-over-HTTPS direct from your browser.
Read the failures
Every cell is graded. Red means mail is affected today, amber means it will be soon.
Fix in order
SPF first, then DKIM, then DMARC. Authentication is a sequence — each layer depends on the one before.
Why audit the whole fleet at once
Single-domain lookup tools are fine when you run one domain. They stop being useful the moment you run forty. Faults in a sending fleet are never evenly distributed — they cluster by batch. Domains registered in the same week, provisioned by the same script, on the same tenant, tend to break the same way.
The most expensive version of this is silent: authentication that was never completed on part of the fleet. When I ran a full audit across my own portfolio, every Microsoft 365 domain in it was missing proper DKIM configuration. Campaigns had been running on them for months. Nothing bounced, nothing errored — the mail simply landed in spam more often, and nobody could point at a cause because each domain looked individually fine.
That is the failure mode this tool exists for. Seeing forty domains side by side makes a pattern obvious in seconds that forty separate lookups would never reveal.
Reading the columns
NS tells you which DNS provider actually answers for the domain. Mixed providers across a fleet usually means a half-finished migration, and split DNS is a common cause of records that exist in a dashboard but never resolve in the wild.
Gateway is about the receiving side. If a domain sits behind Proofpoint, Mimecast or Barracuda, inbound mail is filtered far more aggressively than native Google or Microsoft filtering. Worth knowing before you judge reply rates on a prospect list.
ESP / MX shows where mailboxes live — Google Workspace, Microsoft 365, Zoho and so on. On a sending fleet this should match what you think you provisioned. It often does not.
SPF, DKIM and DMARC are the three that decide authentication. All three need to pass and align for DMARC to pass. A domain with valid SPF but no DKIM will authenticate right up until the first time someone forwards your email.
What each record does and what breaks without it
| Record | Purpose | Symptom when missing |
|---|---|---|
| NS | Names the DNS provider that answers for the domain. | Records edited in one dashboard never resolve because the domain answers from another. |
| MX | Routes inbound mail to a mailbox provider. | Replies and bounces are lost. Your list never gets cleaned. |
| SPF | Authorises which servers may send for the domain. | Mail from your provider is unauthenticated and filtered harder. |
| DKIM | Cryptographically signs each message. | Authentication dies the moment a message is forwarded. |
| DMARC | Tells receivers what to do with failures, and reports on them. | No policy, no visibility, and an unmaintained-looking domain. |
Reading a fleet audit
Scan the columns rather than the rows. A single domain failing one check is a task. A whole column failing across a batch is a provisioning step that was skipped, and fixing it in bulk takes about as long as fixing one.
- All DKIM missing on one provider. Signing was never enabled in the admin console. The DNS side may be perfect.
- NS split across providers. A migration that stopped halfway. Records may exist where nothing reads them.
- MX at the registrar's parking service. The domain was bought but never provisioned. It cannot receive replies.
- DMARC present on some domains only. Usually a template applied to one batch and not the next.
Fixing in the right order
Order matters, because each step depends on the one before it. Nameservers first — everything else is invisible until the domain answers from the right place. Then MX, so replies work. Then SPF. Then DKIM, and confirm signing is actually switched on rather than just published. DMARC last, starting at p=none.
Publishing DMARC at quarantine before DKIM signing is live is the classic self-inflicted wound: you have just asked receivers to enforce against mail that cannot authenticate. Layer-by-layer detail is in the authentication setup guide.
Frequently asked questions
How many domains can I check at once?
There is no hard cap, but each domain fires six DNS queries and public resolvers rate-limit heavily. Batches of 50 to 100 work comfortably. For a fleet of several hundred, split it and run the batches sequentially.
Does this send my domain list anywhere?
No. Every lookup goes directly from your browser to Cloudflare and Google public DNS resolvers over DNS-over-HTTPS. Nothing touches my server and no list is stored or logged.
Why does DKIM show as missing when I know it is configured?
The tool tries the selectors used by the provider it detected from your MX — google for Workspace, selector1 and selector2 for Microsoft 365, and a set of common ones otherwise. If you use a custom selector, check it directly with the DKIM checker, which accepts your own selector names.
What should I fix first if several domains fail?
SPF, then DKIM, then DMARC — in that order. SPF is a single TXT record and takes minutes. DKIM requires the provider to generate a key. DMARC only becomes meaningful once the first two pass and align, so tightening it first will block your own mail.
How do I check SPF, DKIM and DMARC for a domain at once?
Paste the domain into the box above and all three are looked up together, alongside NS, MX and any security gateway. One domain per line checks a whole list in a single pass, which is the only practical way to audit a sending fleet. For depth on any single layer, the SPF, DKIM and DMARC checkers explain each record in full.
What DNS records does a sending domain actually need?
Five. NS pointing at whichever provider you actually edit records in; MX so replies and bounces arrive; SPF authorising your sending provider; DKIM so messages are signed and survive forwarding; and DMARC so receivers know what to do with failures and you get reports. A tracking domain adds a CNAME, and redirects need their own records.
How can I tell whether a domain uses Google Workspace or Microsoft 365?
The MX hostnames give it away — Google Workspace resolves to aspmx.l.google.com and relatives, Microsoft 365 to a mail.protection.outlook.com host. This tool identifies the provider for you, along with any security gateway sitting in front of it. It is the fastest qualification signal available before you write any copy.
What does it mean when a domain has no MX record?
Inbound mail has nowhere to go, so replies and bounces are discarded. Some senders do this deliberately on pure-outbound domains, but for cold email it is close to self-defeating — replies are the goal, and without bounce processing your list quality degrades invisibly. A missing MX is also a mild negative signal to some receivers.
Is it safe to paste a client's domain list into this tool?
The lookups run from your browser using DNS-over-HTTPS, so the list is resolved client-side rather than being uploaded to a server for processing. Treat it as you would any browser-based tool — but nothing here requires you to hand over a client list to a third party in order to audit it.
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.