Free Domain Validator: Check MX, SPF and DMARC Records
To validate a domain, check its live DNS records. Paste a domain above and Cleanlist queries its authoritative nameservers for NS records (is the domain actively managed), MX records (can it receive email), an SPF record at the root, and a DMARC record at _dmarc.yourdomain.com. You get a verdict, a 0-100 score and the raw records in about two seconds. Free for 25 domains a day, no signup. Those four records decide whether mail to and from the domain reaches an inbox.
Last updated August 2, 2026
What this validator checks
Five live checks on any domain (for example example.com): domain syntax, NS records, MX records, SPF, and DMARC with its policy value surfaced. Cleanlist does not check DKIM, because the lookup needs a selector name chosen by whoever configured the mail service and it cannot be guessed from the domain. Cleanlist also does not check domain blocklists, which require a paid reputation API. Skipping a check is better than faking one.
25 of 25 free checks remaining today
Join 2,000+ GTM teams
Who uses the free domain validator?
Teams across go-to-market rely on clean, authenticated domains. Here is where this tool fits.
Sales teams
Spot dead or risky prospect domains before reps waste a sequence on them.
Marketers
Confirm sending domains have SPF and DMARC before a campaign goes live.
Deliverability
Audit DNS records that decide whether mail lands in the inbox or spam.
Founders
Check your own domain is authenticated before emailing partners or investors.
RevOps
Keep prospect domain data accurate so routing and outreach hold up.
Agencies
Validate client and prospect domains before they ever touch a live campaign.
How does Cleanlist validate a domain?
Cleanlist validates a domain in four DNS lookups, run live against the domain's authoritative nameservers rather than a cached copy, and returns the raw records so you can read them yourself.
- 1
Domain syntax check
Cleanlist validates the input against DNS naming rules: label characters, label and total length limits, and a real top-level domain.
- 2
NS lookup
Cleanlist resolves the domain's nameservers. A domain with no NS records is not actively delegated and will not resolve for anyone.
- 3
MX lookup
Cleanlist queries the authoritative nameservers for mail exchange records and returns them sorted by priority, lowest first. No MX record means the domain cannot receive email at all.
- 4
SPF and DMARC TXT lookup
Cleanlist fetches the TXT records at the domain root and at _dmarc.<domain>, then reports the SPF string and the DMARC policy value (p=none, p=quarantine or p=reject) rather than a pass/fail badge.
Not checked: DKIM (the lookup needs a selector name that cannot be guessed from the domain), WHOIS and registrar metadata (external API), and domain blocklist reputation (paid API). Cleanlist would rather skip a check than fake one.
Background reading: domain verification, email deliverability, and the free email verifier for the recipient side of the same problem.
What DNS records does a domain need to send and receive email?
A domain needs four DNS records to send and receive email reliably: NS, MX, SPF and DMARC, with DKIM as the fifth. NS records prove the domain is actively managed and point at the nameservers that answer for it. MX records name the mail servers that accept incoming mail. An SPF record, a TXT record at the domain root starting with v=spf1, lists which servers are allowed to send as that domain. A DMARC record, a TXT record at _dmarc.yourdomain.com, tells receivers what to do when authentication fails. Cleanlist's free domain validator queries all four live, against the domain's authoritative nameservers, and returns the raw records alongside a 0-100 score.
What is an MX record?
An MX record is a DNS entry that names a mail server responsible for accepting email on behalf of a domain, together with a priority number where lower means preferred. A domain with no MX record cannot receive email at all, which makes a missing MX the most decisive signal a domain validator can return. Multiple MX records give a domain failover: if the priority 10 host is unreachable, the sending server tries the priority 20 host. Cleanlist's free domain validator returns the full set sorted by priority, so you can see whether a prospect runs Google Workspace, Microsoft 365, or a self-hosted server, which in turn tells you how likely that domain is to be configured as a catch-all.
What is an SPF record?
An SPF record is a TXT record published at a domain's root that lists the servers permitted to send email using that domain, and it always begins with v=spf1. A receiving server reads it, compares it to the IP the message arrived from, and decides whether the sender is authorised. The record ends with a policy: -all means reject anything not listed, ~all means treat it as suspicious, and +all effectively disables the check. Google's sender guidelines require every sender to set up SPF or DKIM for its sending domains, so a domain with neither is not meeting the published bar. Cleanlist's free domain validator returns the raw SPF string so you can read the policy for yourself.
What is DKIM?
DKIM is a cryptographic signature added to outgoing mail that lets a receiving server confirm the message really came from the domain it claims and was not altered in transit. The sending server signs each message with a private key; the receiver fetches the matching public key from a DNS TXT record at selector._domainkey.yourdomain.com and checks the signature. Yahoo's Sender Hub specifies a DKIM key length of 1024 bits or greater, and recommends 2048 bits. Cleanlist's free domain validator does not check DKIM, and says so rather than faking it: the lookup needs the selector name, which is chosen by whoever configured the mail service and cannot be guessed from the domain alone.
What is DMARC?
DMARC is a TXT record at _dmarc.yourdomain.com that tells receiving servers what to do with mail claiming to be from that domain when SPF and DKIM fail, and where to send reports about it. The policy is set by the p= tag and has three values: p=none monitors and takes no action, p=quarantine sends failures to spam, and p=reject refuses them outright. Google requires senders of 5,000 or more messages a day to Gmail to publish a DMARC policy, and Yahoo urges every sending domain to publish one. Cleanlist's free domain validator fetches the record and surfaces the policy value, so you can tell a domain that is genuinely protected from one that merely has a record on file.
What does a failing DMARC record mean for cold email?
It means two different things depending on whose domain is failing. If your own sending domain has no DMARC record, or has p=none, you are below the bar Google publishes for senders of 5,000 or more messages a day to Gmail, and Yahoo urges a published policy for every sending domain. Expect throttling and spam placement as volume rises. If a prospect's domain has no DMARC, the risk is different: that domain is spoofable, replies you receive from it are harder to trust, and its mail infrastructure is likely unmanaged, which correlates with stale contact records. Cleanlist's free domain validator flags a missing DMARC as a warning rather than an error, because internal-only and parked domains legitimately do without one.
What are Google's and Yahoo's requirements for bulk senders?
Google requires all senders to set up SPF or DKIM authentication for their sending domains, transmit over TLS, publish valid forward and reverse DNS records, and keep the spam rate reported in Postmaster Tools below 0.3%, with a recommended target below 0.10%. Senders of 5,000 or more messages a day to Gmail accounts must additionally set up both SPF and DKIM, publish a DMARC policy, and support one-click unsubscribe on marketing mail. Yahoo requires one-click unsubscribe under RFC 8058 for promotional messages, enforced since June 2024, specifies a DKIM key of 1024 bits or greater with 2048 recommended, urges a published DMARC policy on every sending domain, and states that it will not specify a volume threshold for what counts as a bulk sender.
How does a domain's setup affect email deliverability?
A domain's DNS setup decides whether mail is authenticated before a receiving server ever looks at the content. SPF and DKIM establish that the message came from a server allowed to send as that domain; DMARC tells the receiver what to do when they fail and lets the domain owner see who is sending on its behalf. Without them a message arrives unauthenticated, which is the same posture a spoofer has, and filters treat it accordingly. Domain setup is only half the picture: Google measures spam complaint rate independently of authentication, so a fully authenticated domain sending to a stale list still gets throttled. Cleanlist's free email verifier handles the other half, checking whether the recipient address can receive mail at all.
Sources
Every sender requirement quoted on this page comes from the mailbox provider that publishes it, read on August 2, 2026.
- 1.Google: Email sender guidelines. SPF or DKIM for every sender, TLS transmission, valid forward and reverse DNS, and a Postmaster Tools spam rate below 0.3% (recommended below 0.10%). Senders of 5,000 or more messages a day to Gmail must also publish a DMARC policy and support one-click unsubscribe.
- 2.Yahoo: Sender Hub FAQs. One-click unsubscribe under RFC 8058 for promotional mail, enforced since June 2024. DKIM keys of 1024 bits or greater, 2048 recommended. A published DMARC policy urged on every sending domain. Yahoo states it will not specify a bulk-sender volume threshold.
- 3.RFC 7208: Sender Policy Framework (SPF). The specification for the v=spf1 TXT record this tool reads.
- 4.RFC 6376: DomainKeys Identified Mail (DKIM). The signing scheme and the selector._domainkey record layout that makes DKIM un-guessable without the selector.
- 5.RFC 7489: DMARC. The policy framework behind the p=none, p=quarantine and p=reject values this tool surfaces.
“Plenty of outbound campaigns fail at the DNS layer before a single email is sent. Google asks every sender for SPF or DKIM and a spam rate under 0.3%, and most teams have never looked at their own records. We built this validator so any GTM team can read them in two seconds, with no API and no signup.”
You checked one domain. Do the other 4,999.
This page reads DNS for a single domain. Upload a CSV to Cleanlist and every row comes back with a verified email, a direct dial and the company behind the domain, across a waterfall of 25+ providers. 1 credit per verified email. Start with 30 credits a month free, no card.
Free
Try Cleanlist with no credit card. Great for testing the platform.
Free forever
Starter
For founders and small teams getting started with outbound.
billed annually · +$15/extra seat
Everything in Free, plus:
Pro
For sales teams scaling outbound campaigns and pipeline.
billed annually · +$15/extra seat
Everything in Starter, plus:
Scale
For growth teams running heavy enrichment at scale.
billed annually · +$15/extra seat
Everything in Pro, plus:
Compare every plan
| Feature | Free | Starter | Pro | Scale |
|---|---|---|---|---|
Data Enrichment | ||||
| Enrichment | ||||
| AI Search | ||||
| Chrome Extension | ||||
| CSV Upload | ||||
| Credit Rollover | ||||
Prospecting | ||||
| Find People | ||||
| Sales Navigator | ||||
| Manual Entry | ||||
| Export CSV | ||||
| Leads per List | 100 | 2,500 | 2,500 | Unlimited |
| Seats included | 1 | 2 | 5 | 10 |
| Additional seats | — | $20/seat | $20/seat | $20/seat |
Automation & AI | ||||
| AI Agents (Basic) | ||||
| AI Agents (Advanced) | ||||
| Playbooks | ||||
Integrations | ||||
| CRM Import | ||||
| CRM Integrations | ||||
| API Access | ||||
| Custom Integrations | ||||
| SSO / SAML | ||||
Support & Analytics | ||||
| Priority Support | ||||
| Analytics Dashboard | ||||
| Dedicated Success Manager | ||||
| Custom SLAs | ||||
Frequently Asked Questions
What does the Cleanlist domain validator check?
+
Five live DNS checks: domain syntax, NS records (whether the domain has authoritative nameservers), MX records (which mail servers accept its email), SPF (a TXT record at the root starting with v=spf1) and DMARC (a TXT record at _dmarc.<domain>, with the policy value surfaced). Cleanlist does not check DKIM, because the lookup requires a selector name that cannot be guessed, and does not check domain blocklists, which need a paid reputation API.
Is this the same as a WHOIS lookup?
+
No. WHOIS returns registrar metadata and ownership history. Cleanlist's domain validator inspects the live DNS configuration that decides email deliverability. For B2B sales and marketing work the DNS picture is the one that changes your decision: a domain can have immaculate registrar records and still be unable to receive a single message.
Is there a usage limit?
+
Yes. Cleanlist allows 25 free domain checks per IP per day on this page, with no account and no card. A free Cleanlist account adds 30 credits a month for enriching and verifying whole lists.
How accurate is this tool?
+
DNS responses are deterministic: if the records exist on the authoritative nameservers, Cleanlist returns them. The interpretation is deliberately conservative. A missing SPF or DMARC is reported as a warning rather than an error, because internal-only, parked and no-mail domains legitimately publish neither.
Can this detect malicious or phishing domains?
+
Only as triage. A recently registered domain with no DMARC, no SPF and a single MX record on free hosting is a recognisable phishing shape, and Cleanlist surfaces each of those signals. It is not threat intelligence, and a definitive verdict needs a dedicated reputation service. Treat the output as a fast first pass, not a ruling.