Build a CLI Email Verifier with Public DNS

Why Build a CLI Email Verifier with Only Public DNS?

You run a bulk email campaign. Your list is clean on paper, but 15% bounce. Not just soft bounces—hard failures. You check your provider’s dashboard. It says “invalid”—but why? You’ve used third-party tools before. They’re fast, but inconsistent. One day they say an address is valid; the next, it’s not. No clear reason. The cost adds up. And you never really know what’s behind the result.

What if you could verify email addresses without trusting an API, paying per lookup, or relying on a service that changes its rules overnight? You don’t need to simulate an inbox. You don’t need to send test messages. Just check the actual digital infrastructure a domain exposes—its MX records, SPF, and A records—using only public DNS lookups. No external dependencies. No hidden fees. The same data that powers email delivery is your validation engine.

Building a CLI email verifier using public DNS only turns the process into a repeatable, transparent system. It runs the same whether you’re in Berlin or Bangkok. It’s free to scale. It’s auditable. You’re not guessing. You’re inspecting the foundation.

Key takeaways

Public DNS records (MX, SPF, A) reflect the actual email infrastructure of a domain, providing a reliable foundation for validation
Using only public DNS eliminates reliance on third-party APIs, reducing cost, latency, and variability across regions
A CLI verifier based solely on DNS lookups offers predictable, repeatable results without hidden logic or opaque scoring

What Can You Validate With Only Public DNS?

You can verify if an email address’s domain is active, accepts mail, and follows basic sending policies using only public DNS records—MX, A, SPF, DKIM, and DMARC. No actual messages are sent, no fees are charged. This approach checks technical validity at the domain level, filtering out obvious invalid addresses before sending.

What DNS Records Actually Tell You

MX records show the mail servers responsible for a domain. If a domain has no MX record, it doesn’t accept email—so any address on it is invalid. You can check this with a simple dig or nslookup command.

SPF (Sender Policy Framework) records list which IPs or domains are authorized to send mail on behalf of a domain. If an SPF record exists but doesn’t include your sending IP, the email might be rejected even if the address is syntactically correct.

A records confirm the domain resolves to a real server. A missing or unresolved A record strongly suggests the domain is inactive or misconfigured.

DNS TXT records store domain-wide policies. DMARC, for example, tells you how receiving mail systems should handle unauthenticated messages. DKIM records confirm if a domain uses cryptographic signatures for email authentication. These tell you if a domain supports modern security standards—and how rigorously it enforces them.

What You Can’t Detect With Public DNS Alone

Just because a domain has valid DNS records doesn’t mean a specific email address is active. You can’t know if a mailbox exists without sending an actual message (or using a real-time API to peek). Catch-all domains, role accounts (like admin@ or info@), and disposable inboxes can pass DNS checks but still bounce or end up in spam.

Greylisting, temporary bounces, or reputation-based filters also go undetected without actual delivery attempts or reputation data. Public DNS can’t tell you if a send is flagged by a blocklist or throttled by a provider like Gmail or Outlook.

For deeper insight—especially on inbox placement and real-world deliverability—using a service like inbox placement testing or bulk verification adds value beyond DNS alone.

That said, public DNS validation is fast, cheap, and effective for filtering out the obvious noise. It’s a foundational step. Think of it as checking if a door is locked before trying to open it. If it’s not there, you save time and bandwidth. You don’t need to build a full verification engine to start—just use the tools built into your OS or a reliable API like our verification API.

How to Build a Command Line Email Verifier Using Only Public DNS

You can verify an email address via DNS tools like dig, nslookup, or host by querying MX, SPF, A, and TXT records—checking if the domain accepts mail, has valid sender policy, resolves to a real IP, and supports authentication. If any required record is missing, the address fails validation. Use these tools natively in your shell—no API keys, no external services.

Step-by-step DNS Verification Process

Verify the domain accepts mail with MX records. Run dig MX example.com or host -t MX example.com. A missing MX record means the domain doesn’t accept mail. This is a hard fail.
Confirm the domain has a valid SPF record. Use dig TXT example.com and look for a record starting with v=spf1. If it’s missing or malformed, the sender policy isn’t defined, which increases risk of deliverability issues.
Check that the domain resolves via A records. Run dig A example.com. If no A record exists, the domain isn’t reachable. Public DNS systems require this to route mail correctly.
Test if the mail server’s IP is live. Extract the MX target (e.g., mail.example.com), then resolve it with dig A mail.example.com. Ping the resulting IP using ping or nc -zv to verify responsiveness. No response means the server is unreachable.
Look for DMARC or DKIM authentication records. Run dig TXT _dmarc.example.com or dig TXT default._domainkey.example.com. These records show domain owners have set up authentication—important for sender reputation. Their absence doesn’t fail the check but reduces confidence.
Fail if any required record is missing. If MX, SPF, or A records are missing, reject the email outright. These are foundational checks. No exceptions.

Why This Works & Where It Falls Short

These checks align with standard email delivery practices. A valid MX is mandatory. SPF defines who can send on behalf of the domain. A records ensure the server exists. DMARC and DKIM are optional but add signal. This method leverages public DNS—no proprietary data, no API costs.

The 6 steps described in “Step-by-step DNS Verification Process”, in order.

However, this approach cannot detect catch-all accounts, disposable emails, or role addresses (like admin@ or support@). It also can’t verify if a mailbox actually exists—only the domain’s configuration. For real-world list hygiene, combining DNS checks with bulk verification tools is essential.

For teams scaling email campaigns, automating DNS checks is a solid first step, but full list validation requires deeper checks. Tools like bulk email verification or the real-time verification API use multiple layers—including SMTP, reputation scoring, and known disposable domains—delivering 98.9% accuracy.

What Each DNS Record Tells You About an Email Address

You can verify an email address using only public DNS records by checking MX, SPF, A, and TXT records. MX confirms the domain accepts mail. A missing MX means the address is invalid. A records show if the domain resolves — no resolution means the domain doesn’t exist. SPF records define authorized senders; their absence isn’t a fail, but lack of policy can signal weak security. TXT records often contain DMARC and DKIM policies, which validate legitimacy. A wildcard catch-all with no SPF or overly broad policies is a red flag for spam abuse.

MX Records: The Domain’s Mail Gateway

MX records tell you whether the domain is set up to receive email. If they’re missing, the address is almost certainly invalid. The absence of an MX record is a hard fail in email verification — no mail can be delivered to a domain without one.

SPF and A Records: Sender Authorization and Domain Reachability

SPF records define which servers are allowed to send email on behalf of the domain. A missing SPF doesn’t always mean the address is bad, but it reduces trust. It also suggests the domain may not enforce sender authentication — common in low-quality or throwaway domains.

The A record confirms the domain exists and resolves to an IP. If it doesn’t, the email address is invalid. This is a basic, non-negotiable check: no A record means no actual domain backing the email.

TXT Records: DMARC, DKIM, and Policy Signals

TXT records often contain DMARC (Domain-based Message Authentication, Reporting & Conformance) or DKIM (DomainKeys Identified Mail) policies. DMARC, in particular, tells you how receiving servers should handle emails that fail SPF or DKIM checks — this directly impacts deliverability.

DMARC isn’t required for all domains, but its presence is a strong signal of legitimacy. Domains with DMARC policies are less likely to be exploited by spammers. That said, absence isn’t a failure — it just means there’s no policy in place.

Wildcard Catch-Alls: When Too Much Is a Warning Sign

Wildcard catch-alls accept any email to a domain, regardless of the local part. While convenient, they’re heavily abused by spammers and marketers. If a domain has a catch-all and lacks a precise SPF policy (or has a broadly defined one), it’s a red flag — it implies the domain doesn’t validate addresses.

Some public tools like MXToolbox or RFC 7505 can help spot wildcard domains. These are often used in disposable email services or automated systems, making them poor candidates for reliable contact.

While public DNS checks are foundational, they’re not foolproof. You can’t catch all invalid addresses this way — for example, role accounts, temporary addresses, or domains with no public records still slip through.

For production use, automate deeper validation with services like bulk email verification, real-time API checks, or inbox placement testing. These cover more edge cases and integrate with your existing stack.

Limitations of DNS-Only Verification: What It Can’t Detect

Verifying emails using only public DNS records gives you a basic pass/fail on syntax and server reachability—but it won’t tell you if an inbox is full, blocked, or if the account is even active. You can validate that an email’s domain exists and accepts mail, but you can’t confirm whether the user actually receives messages. This means you might send to an address that’s technically valid but practically unreachable.

Why DNS Checks Fall Short

Let’s be clear: DNS-only checks can’t detect if an email account is full. A mailbox might be at 99% capacity, but the MTA still accepts incoming mail—it just bounces later. This is why you see delayed delivery failures even after a clean DNS validation.

You also can’t verify if the account is a role address (like [email protected]) or a real person. Many companies use shared addresses for inbound mail, but sending to them doesn’t guarantee a real person will see it. The domain may accept mail, but the mailbox may be monitored only by a team, not an individual.

Temporary and Invisible Failures

DNS checks miss temporary issues. Greylisting, for example, is a common anti-spam technique where the server temporarily rejects a first-time send. The same email sent minutes later may succeed. DNS-only systems don’t know the difference between a temporary delay and a permanent failure.

Similarly, temporary MX outages or DNS propagation delays don’t show up in DNS validation. The record resolves today, but could fail tomorrow. This is why some lists appear clean today but start bouncing weeks later.

Disposable email domains are a major blind spot. These domains (like tempmail.org or 10minutemail.com) often have real, responsive MX records. A DNS-only tool will pass them as valid, even though they're designed to expire quickly and usually aren't used by real users.

Catch-all domains are another hidden risk. These accept any email address at the domain (e.g., [email protected]), meaning even invalid addresses will get a “valid” response from the server. This creates false confidence—your send may “succeed” but nobody receives it.

For a real-world example, a 2020 study by Return Path found that inbox placement drops significantly when a send includes invalid or role-based addresses—despite them passing DNS checks.

Tools like bulk email verification and inbox placement testing go beyond DNS by simulating real delivery and measuring actual inbox delivery rates. They catch what DNS alone cannot.

How to Improve Accuracy: Combine DNS with Real-World Signals

You can't rely solely on DNS checks for email validity — they only tell you if an address is syntactically possible. To catch real-world issues like blocklists, disposable domains, or role-based addresses, you need to layer in live data from APIs, reputation databases, and pattern recognition. A DNS-only approach misses 30% of invalid addresses in practice, especially those that are active but unsendable.

Strengthen your verifier with live data

Use a real-time verification API like Emaillistchecker.io’s API to validate emails against current server responses, not just DNS records.
Check if the domain appears on public blocklists, such as those maintained by Spamhaus, which track known spam sources and malicious domains.
Compare against curated lists of known disposable or temporary email domains to flag addresses from services like Mailinator or GuerrillaMail.

Filter for real user intent

Apply heuristics to detect role-based addresses like admin@, support@, or sales@ — these often have low deliverability and high bounce rates.
Prefer human-like formats (e.g., [email protected]) over generic or sequential patterns, which are more likely to be automated or non-responsive.
Use domain reputation metrics and historical bounce data, when available, to score confidence levels beyond pure syntax or DNS lookup.

Building a command line email verifier with public DNS only gets you partway there. But true accuracy comes from combining DNS checks with signals that reflect real-world delivery behavior. Without this, your list may pass DNS validation but fail in production.

Real-time feedback is the difference between a theoretical match and a functional inbox.

For scalable, accurate validation, pair your CLI tool with a service like Emaillistchecker.io’s bulk verification or inbox placement testing. These tools include all the real-world layers we’ve covered — and they deliver results at the scale you need.

The Real-World Trade-Off: Control vs. Confidence

Building a command-line email verifier using only public DNS gives you complete control—you don’t send data to third parties, you don’t rely on API keys, and you can run checks offline. But that control comes at a cost: DNS alone can’t tell you if an inbox is active, human-owned, or willing to receive mail. You’ll catch obvious invalid formats, but miss the rest. For campaigns where deliverability matters, this means higher bounce rates and damaged sender reputation. The best outcome isn’t either/or—it’s using DNS as a first pass, then layering in a trusted SaaS for final validation.

What DNS Can (and Can’t) Tell You

When you query DNS records like MX, SPF, or A-records, you’re checking whether a domain exists and has mail-routing infrastructure. That’s useful for filtering out obviously fake or mistyped addresses. But the presence of an MX record doesn’t mean someone is listening—some domains accept mail and just drop it, others have catch-all setups that accept every address without verification.

Let’s be clear: a valid MX record isn’t proof the address is active. It’s just proof the domain knows how to receive email. That’s why tools like Spamhaus and MxToolbox are great for diagnostics but insufficient for list hygiene. They don’t tell you if the user cares, if the mailbox is full, or if it's a bot trap.

Why You Need More Than DNS for High-Stakes Campaigns

Using DNS-only validation means accepting a higher false-positive rate—valid addresses flagged as bad because of greylisting, temporary failures, or role-based accounts. It also misses disposable email domains, which often have valid MX records but are never used for real communication.

Here’s where the real-world strategy kicks in: start with your command-line DNS checks to remove grossly invalid entries and reduce noise. Then send the remaining list through a service that does deeper verification—like checking inbox placement, detecting disposable domains, and confirming if an address is still active. This two-step approach balances your need for control with the certainty that only a few real-world systems can deliver.

Services like EmailListChecker’s bulk verification integrate that depth, combining DNS checks with real-time SMTP probing and pattern analysis. It’s not just faster—it’s more accurate. For teams running targeted campaigns or transactional flows where every bounce harms reputation, that extra layer isn’t optional. It’s necessary.

How Emaillistchecker.io Handles Verifications Accurately and Transparently

You can build a command line email verifier using only public DNS, but it won't catch most real-world delivery issues. Emaillistchecker.io goes beyond DNS by combining real delivery behavior with DNS checks, achieving 98.9% accuracy through over 50 million actual delivery attempts. This means we don't just check whether a domain exists—we test whether an email actually reaches an inbox, with measurable results.

Why DNS Alone Isn't Enough

DNS records like MX and SPF tell you a domain accepts mail, but not whether a specific address is active or deliverable. A catch-all domain may accept all emails, but that doesn't mean they'll land in real inboxes. Role accounts like admin@ or sales@ often aren’t monitored. Disposable domains are created solely for temporary use. These signals aren’t detectable through DNS alone.

We go beyond lookup by simulating real delivery attempts. For each email, we verify the domain’s MX records, check for known disposable domains, assess role account patterns, and cross-reference against real-world sender behavior. This hybrid method gives us the accuracy that pure DNS tools can’t match.

What Your Verdicts Actually Mean

Our system gives four clear verdicts: valid, invalid, catch-all, or risky. A valid email is one that has reached an inbox in a recent test. An invalid address fails DNS, is a role account, or is blocked by a known disposable provider. Catch-all means the domain accepts all emails—even unregistered ones—making it unreliable for outreach. Risky means the email is technically valid but shows signs of poor deliverability, like low engagement history or high bounce rates.

All verdicts are based on measurable data, not guesswork. We don’t call something “valid” just because the DNS says so. We verify through delivery patterns, reputation scores, and behavioral signals. This is how we maintain the 98.9% accuracy we report.

Whether you’re using our real-time API or bulk verification, the same logic applies. You can integrate it into your scripts, workflows, or systems. We support Mailchimp, HubSpot, Klaviyo, SendGrid, and others via native integrations. If you're building a CLI tool, start with our API, and test deliverability with inbox placement testing. The results are transparent and repeatable.

For more on how we test deliverability, see the SMTP specification (RFC 5321) and Spamhaus DNSBL documentation, which underpin the standards we follow.

Example: Validating an Email Address Using Only Linux Tools

You can validate an email domain using only Linux’s built-in DNS tools: check for MX records first. If absent, the domain can’t receive mail. If MX exists, verify the domain has an A record. Then confirm SPF and DMARC records exist. If both are present and DMARC is strict, the domain is trustworthy. Finally, test basic IP reachability. Only if all checks pass is the domain valid.

Step-by-step: From DNS to Connectivity

Run dig MX example.com to check if the domain has an MX record. No MX means the domain doesn’t accept email—invalid by definition. This is standard practice in email routing, as outlined in RFC 5321.
If an MX record exists, run dig A example.com to verify the domain resolves to an IP. No A record means the mail server can’t be reached—invalid.
Check for SPF: dig TXT example.com | grep "v=spf". SPF helps prevent spoofing. If missing, the domain lacks a published policy—low-confidence for deliverability.
Check DMARC: dig TXT _dmarc.example.com | grep "v=DMARC". If the record exists and has p=reject or p=quarantine, the domain enforces strict email authentication—increases trust.
Test reachability of the MX server’s IP: ping [MX_IP] (if permitted). A failed ping indicates network issues or blocked traffic—potential red flag.
Finalize: only pass if MX, A, SPF, and DMARC records exist, and the MX server IP is reachable. This aligns with industry best practices for domain-level validation.

Why This Matters

DNS-only validation catches many invalid domains early—before any SMTP attempts. It avoids wasted sends and protects sender reputation. While it doesn’t confirm if an individual email address is active, it validates the underlying domain.

The 6 steps described in “Step-by-step: From DNS to Connectivity”, in order.

Real-world systems like Spamhaus and RFC 5321 rely on similar checks for spam filtering and routing decisions. The approach is reliable, lightweight, and runs entirely in user space.

For bulk validation at scale, this method can be scripted—but it’s not immune to edge cases like greylisting, catch-all servers, or temporary network issues. You’ll still need deeper SMTP checks for inbox placement accuracy.

For faster, more accurate results with full deliverability feedback—without managing scripts—try bulk email verification with Emaillistchecker.io. It uses real-time SMTP checks, AI, and public data to surface issues your DNS-only method might miss.

Why Use a SaaS Tool Instead of Scripting It Yourself?

Building a command-line email verifier using only public DNS is technically possible, but it misses critical real-world signals. DNS checks alone can’t catch greylisting, temporary delivery delays, or role-based accounts. A SaaS tool like Emaillistchecker.io adds historical feedback and sender reputation data that no script can replicate. You get consistent, scalable results without managing infrastructure.

What Your Script Will Miss

You’ll miss greylisting: some servers delay delivery for minutes or hours, even if the domain is valid. DNS-only checks won’t capture this failure mode.
Temporary DNS failures can falsely mark valid domains as invalid. A SaaS tool compensates with retry logic and historical context.
Catch-all domains respond positively to every email, regardless of validity. A pure DNS check treats these as "valid," inflating your list accuracy.
Role accounts (like admin@, sales@) are often ignored by mail servers and don’t receive messages. Only a real delivery test or reputation database can flag these.
Disposable domains and high-risk zones (like certain top-level domains) aren’t detectable via DNS alone—only a SaaS with behavioral analytics can identify them reliably.

How SaaS Tools Deliver Real Results

Providers like Emaillistchecker.io don’t just validate email syntax or check MX records—they use real-world data: past deliverability patterns, sender reputation scores, and feedback loop reports. These signals are hard-won and not available through public DNS queries alone.

For example, a study by Return Path found that as many as 20% of emails fail to reach the inbox due to issues beyond basic syntax—many of which are caught only by continuous monitoring. A SaaS tool learns from millions of real sends, while a script can only verify the static DNS state of a moment in time.

You get consistent results across time and edge cases. If a domain temporarily fails DNS (common with overloaded or misconfigured mail servers), a well-designed SaaS tool won’t drop it — it’ll apply fallbacks and historical insight to maintain accuracy. That’s not built into a basic script.

And it’s easy to scale. With Emaillistchecker.io, you get 100 free verifications to start, and your purchased credits never expire. Integrations with tools like Python, Bash, or workflow platforms (via the API or integrations) mean you can plug in without managing infrastructure.

You don’t need to reinvent the wheel. The cost of building and maintaining a reliable, high-accuracy validator is far higher than using a tool designed for it. The outcome? Fewer bounces, better deliverability, and more trust in your list.

Conclusion: Use DNS as a Foundation, Not the Final Answer

You can build a command-line email verifier using public DNS records alone. It checks domain existence, MX records, and SPF policies—fast, cheap, and with full transparency.

But DNS alone cannot verify if an email address is active, if it’s a role account, or whether it will actually reach an inbox. It lacks the ability to detect catch-all domains, disposable addresses, or greylisted senders.

For production use, pair DNS-level filtering with a high-accuracy service like Emaillistchecker.io. This hybrid approach reduces bounces, avoids spam traps and blocklists, and improves deliverability without compromise.

Sources

Only 39.3% of email senders said they were fully aware of Gmail and Yahoo's bulk sender requirements, and 23% reported real deliverability problems after enforcement began. — Mailgun State of Email Deliverability (2024)

Keep reading

Ready to put this into practice? Emaillistchecker.io verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Can DNS-only verification catch disposable email addresses?

No. Disposable domains often resolve to real MX and A records. They pass DNS checks even if the service is designed to reject messages.

Does a missing SPF record mean the email is invalid?

Not necessarily. A missing SPF record is a weakness, not a failure. It means the domain doesn’t restrict sending—but not that it’s invalid.

How do catch-all domains affect DNS verification?

Catch-all domains always pass DNS checks because they accept mail for all addresses. This makes them high-risk for deliverability and list hygiene.

Can you build a reliable verifier without an internet connection?

No. DNS lookups require internet access. Offline verification is not possible with public DNS.

What’s the difference between a DNS check and a full email verification?

A DNS check confirms infrastructure validity. Full verification confirms inbox acceptance, user existence, and engagement potential.

How accurate is Emaillistchecker.io's verification?

Our verification accuracy is 98.9%, based on real-world delivery tests across multiple email providers.

Do you offer API access to verify emails programmatically?

Yes. Our real-time verification API works with scripts and integrations like Mailchimp, SendGrid, HubSpot, and Klaviyo.

Are Emaillistchecker’s credits permanent?

Yes. Purchased credits never expire, so you can use them at any time without urgency.

Can I test email deliverability with Emaillistchecker.io?

Yes. We offer inbox-placement testing to check how likely your emails are to land in the inbox across major providers.

What types of email addresses does the tool detect as risky?

We flag role accounts (e.g., admin@, sales@), disposable domains, catch-all domains, and domains with weak or missing security policies.

Why should I use a third-party tool instead of writing my own DNS script?

You’ll miss real-time feedback, deliverability data, and edge-case handling. SaaS tools combine DNS with live sender feedback for higher accuracy.

Does Emaillistchecker.io store my email list?

No. We process your data on the fly and do not retain your lists unless you explicitly request storage.