Debug Email Routing with DNS Tools

Why Do Email Deliverability Issues Persist After Sending?

You sent a perfectly crafted email. The address was valid, the content was on-brand, and the timing was spot-on. But it didn’t land in the inbox. Instead, it vanished—no bounce, no error, just… silence.

You’re not imagining it. Even emails that meet all basic formatting rules can fail due to unresolved DNS-level routing issues. These are the invisible gatekeepers: MX records, SPF, DKIM, and DMARC. If any are misconfigured, your message gets blocked before it even reaches the inbox.

Third-party tools can help, but they don’t always show the root cause. That’s where command-line DNS tools come in. They give you direct, unfiltered access to your domain’s actual DNS state—no abstractions, no guesswork. You can debug email routing problems with command line DNS tools faster and more reliably than with web consoles or black-box validators.

Key takeaways

Even valid emails fail to deliver when underlying DNS records like MX, SPF, DKIM, or DMARC are misconfigured.
Command-line tools like dig, nslookup, and host provide immediate, verifiable insights into domain-level routing without relying on external services.
Understanding and testing DNS configurations locally reduces dependency on third-party tools and cuts troubleshooting time from hours to minutes.

What Is Email Routing, and How Does DNS Control It?

When you send an email, your server doesn’t just send it to the recipient’s inbox directly. It starts by querying DNS to locate the recipient’s mail server using MX records. That’s email routing: a path defined by DNS, not a physical network. The full process relies on three core DNS records—MX, SPF, and DKIM—and DMARC policies to verify legitimacy and prevent spoofing.

MX Records: The Map of Email Delivery

Every email starts with a DNS lookup for the recipient’s MX (Mail Exchange) record. This tells your server which mail server is responsible for accepting messages for that domain. For example, an email to [email protected] goes through a query for company.com’s MX record, which returns something like mail.company.com.

Without a valid MX record, your message fails before it even leaves your server. That’s why checking MX records with command-line tools like dig or nslookup is the first step in diagnosing delivery failures.

SPF, DKIM, and DMARC: Authentication Layer

Even if the MX record is correct, the receiving server checks if the sender is authorized. SPF (Sender Policy Framework) lists which IP addresses are allowed to send mail on behalf of a domain. If your server’s IP isn’t in that list, the message may be flagged or rejected.

DKIM (DomainKeys Identified Mail) adds a digital signature to each message. It’s like a seal proving the email hasn’t been altered in transit. The receiving server verifies this signature using a public key published in the sender’s DNS.

DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together. It tells receivers what to do if a message fails authentication—either quarantine it, reject it, or do nothing. It also enables reporting, so you can see which emails failed and why.

These records are not optional in modern email infrastructure. Major providers like Gmail and Outlook reject messages without proper SPF/DKIM/DMARC alignment. The RFC 7052 standard describes this process, and tools like DNSSEC validation help ensure these records are trustworthy. You can verify your own setup using tools like bulk email verification—a way to find invalid, risky, or inactive addresses that could otherwise trigger routing or authentication issues.

Let’s say you’re debugging a batch of rejected messages. A missing MX record, a misconfigured SPF, or a broken DKIM signature can all break delivery. These are all DNS-level problems, and catching them early prevents bounces and inbox placement issues.

How to Debug Email Routing Problems with Command Line DNS Tools

You can debug email routing issues by testing DNS records step by step with command line tools like dig or nslookup. Start with MX, TXT, and A records. Verify the mail server resolves correctly, SPF lists your sending IP, DKIM has a valid public key, and DMARC policies are enforced. Then simulate the SMTP handshake using telnet or openssl s_client to see where delivery breaks.

Use dig MX example.com or nslookup -type=mx example.com to find the mail exchange servers. This shows which servers accept email for the domain.
Check that the MX record resolves to an A record via dig A mail.example.com. If the A record is missing or invalid, the mail server isn’t reachable. A valid A record means the server exists and is on the internet.
Query the SPF record with dig TXT example.com and look for a v=spf1 entry. Ensure your sending IP address is included in the policy. If not, receiving servers may reject your email, even if the DNS is otherwise correct.
Locate the DKIM public key by querying dig TXT selector._domainkey.example.com. The returned TXT record must contain a pk= value and a valid public key. If missing or malformed, email authentication fails.
Check DMARC policy via dig TXT dmarc.example.com. This returns the policy, which tells receivers how to handle messages that fail SPF or DKIM. A policy like policy=reject means failing messages are blocked.
Test the full delivery path. Connect to the mail server using telnet mail.example.com 25 or openssl s_client -connect mail.example.com:587. Follow the SMTP handshake until you get a 220 or 250 response. If the connection fails, the server is not accepting mail from your IP.

The 6 steps described in “How to Debug Email Routing Problems with Command Line DNS T…”, in order.

Why This Matters

DNS configuration errors cause about 30% of email delivery failures. A single missing or misconfigured record can knock your message into spam or bounce it outright. The real-world impact is measurable — unverified DNS leads to higher bounces, lower inbox placement, and tarnished sender reputation.

When to Use Real Tools

While command line tools diagnose routing, they don’t catch everything. Role accounts, disposable domains, or greylisting won’t appear in DNS but can still block deliverability. For full list health, use a bulk verification service that runs deeper checks across protocols and IP reputation.

Use bulk verification to scan entire lists for invalid, risky, or non-existent email addresses before sending. It integrates with platforms like Mailchimp and SendGrid, helping you maintain high sender reputation and avoid blocklists.

How to Test MX Records in Real Time with dig

Run dig MX example.com to instantly retrieve the mail exchange servers for a domain. Check the priority values—lower numbers take precedence—and verify the primary server is reachable. Then confirm the mail server’s IP resolves with dig A mail.example.com, and use ping to test basic connectivity. This step-by-step process identifies routing issues before they disrupt email delivery.

Step-by-step MX and DNS validation

Run dig MX example.com to retrieve the domain’s MX records. This shows the list of mail servers responsible for accepting incoming email, along with their priority rankings. A missing or misconfigured MX record breaks inbound email flow.
Inspect priority values. Lower numbers are used first. If you see multiple MX entries, ensure the primary (lowest priority) server is online and not blocked by firewall rules or downtime. A misaligned priority can cause temporary delivery failures.
Verify the mail server’s IP address with dig A mail.example.com. Replace mail.example.com with the hostname listed in the MX record (you can extract it from the dig MX output). This confirms that the mail server has a valid A record.
Test network reachability with ping mail.example.com. While ping doesn’t guarantee SMTP functionality, it confirms the server is reachable at the network layer. If ICMP is blocked, a failed ping doesn’t necessarily indicate a problem—this is common for mail servers.
Use telnet or openssl to verify SMTP service availability. For example, run telnet mail.example.com 25. If the connection fails, the mail server may be down, misconfigured, or blocking connections.

Why this process works

MX records are the first hop in email routing. If they’re incorrect, delayed, or point to a dead server, messages never reach their destination. This real-time verification process gives you immediate visibility into whether the infrastructure is ready.

The 5 steps described in “Step-by-step MX and DNS validation”, in order.

According to RFC 5321, mail servers must respond to SMTP connections with properly formatted responses. Using dig and telnet together ensures you’re not just checking DNS but also confirming service availability at the transport layer.

If you’re managing a large list of domains, automating this process with a bulk verification tool helps catch routing misconfigurations at scale. For example, bulk verification can test multiple domains’ MX records and deliverability readiness in one run—great for audit trails and pre-send checks.

What Your SPF Record Should Look Like

Your SPF record must be published as a TXT record at the domain root with v=spf1 as the starting tag. Include mechanisms for each mail server you use—like ip4:192.0.2.1 for your own senders or include:spf.protection.outlook.com if using Microsoft 365. Use include:_spf.google.com if routing through Google Workspace. Never add -all or ~all without testing first: ~all soft-fails unauthorized sources, while -all blocks them outright. A missing or malformed SPF record causes delivery failures even for legitimate emails.

How to Structure Your SPF Record Correctly

Start every SPF record with v=spf1. This declares the version and tells receivers how to interpret the rest. Then add mechanisms that list authorized sending sources. Use ip4: or ip6: for static IP addresses. If you use a third-party provider like Mailgun, SendGrid, or Amazon SES, include their SPF domains via include:. You can have multiple includes, but keep the total length under 255 characters—SPF has a 10-lookup limit and a 1000-byte cap.

Each mechanism must be separated by a space. For example: v=spf1 ip4:192.0.2.1 include:spf.protection.outlook.com include:_spf.google.com -all. Avoid stacking multiple include statements or adding duplicate records—it causes validation errors. Some tools, like bulk email verification, can detect misconfigurations before they impact delivery.

Why You Should Test Before Locking Down With -all

Using -all rejects all mail from sources not explicitly listed. That’s strict—but also dangerous if you forget a legitimate sender. ~all is more forgiving: it soft-fails, marking the message as suspicious but not outright rejecting it. Most email providers prefer soft-fail during early adoption. If you set -all too soon and miss a sender, your emails go to spam or bounce.

When in doubt, test with ~all. Use tools like inbox placement testing to simulate delivery in real-world inboxes. Monitor feedback loops and authentication logs to catch issues early. Misconfigured SPF is among the top reasons for low inbox placement rates—especially in transactional or high-volume campaigns. For reference, the RFC 7208 standard defines SPF behavior: see RFC 7208 for full details.

How to Validate DKIM and DMARC Policies from the Command Line

You can validate DKIM and DMARC policies from the command line using dig or host to query DNS records. DKIM is checked via a TXT record at selector._domainkey.domain.com (e.g., default._domainkey.example.com), which must contain a properly formatted public key. DMARC records are found at _dmarc.example.com and specify policies like p=none, p=quarantine, or p=reject, with p=reject blocking unauthenticated mail. Use tools like opendkim-tools to test DKIM signing and verify alignment. You can also validate DMARC policies by querying the record and checking for syntax errors or conflicting directives.

Verifying DKIM Records

DKIM uses a domain-specific TXT record published under selector._domainkey.yourdomain.com. For example, if your selector is default, run dig TXT default._domainkey.example.com to fetch the record. The value should be a public key in canonical form—no embedded newlines or formatting quirks. If the key is malformed or missing, mail from that domain won’t pass DKIM checks, even if SPF passes. Use Apache Directory Studio or opendkim-tools to generate and validate keys locally before deployment.

Checking DMARC Configuration

DMARC policies are published in a TXT record at _dmarc.example.com. Run dig TXT _dmarc.example.com to retrieve the full policy. Common policy values like p=reject mean unauthorized mail must be blocked. However, if a domain has no valid DKIM or SPF records, a p=reject policy will block all mail—good for security, bad for delivery. Always test DMARC policies in p=none mode first. The RFC 7483 defines DMARC structure, so ensure your record follows the standard format with correctly ordered tags.

If you're verifying a list of sending domains, consider using bulk email verification to identify domains with misconfigured or missing DKIM/DKIM records before mass sending. This helps prevent deliverability issues caused by unauthenticated mail.

Why Greylisting and Temporary Bounces Happen (And How to Confirm Them

Greylisting temporarily delays email delivery to filter spam by rejecting first-time connections. The receiving server asks for a retry after 15–30 minutes—common with new or infrequently used domains. A 4xx SMTP response (like 451 4.7.50) signals a temporary delay, not a permanent failure. You can confirm this using command-line tools like telnet to simulate the SMTP handshake and identify whether the issue is transient or permanent.

Understanding Greylisting in Practice

Greylisting works by treating each sender’s IP, envelope sender, and recipient as a unique triad. On first contact, the server replies with a temporary rejection (4xx), expecting a retry. Legitimate mail servers will retry, but many spam sources don’t. This filter reduces spam without blocking valid messages—though it does cause delays for new senders.

This is why outbound emails from a brand-new domain or an underused account often fail on first try. The rejection isn’t a sign of a broken setup; it’s a sign the recipient system is working as intended. If you see a 4xx response during verification or testing, that’s the system asking you to try again later.

Standard SMTP error codes help distinguish between temporary and permanent issues. A 4xx error means the server is asking you to retry. A 5xx error means the message is permanently rejected—usually due to a bad address, blocked domain, or configuration misstep. Knowing the difference is critical for debugging.

How to Verify with Command-Line Tools

Use telnet to connect directly to the destination mail server’s SMTP port (usually 25 or 587). Begin the handshake with HELO or EHLO, then send MAIL FROM: and RCPT TO:. If the server responds with a 451 4.7.50 Temporary lookup failure, greylisting is likely the cause.

For example, a valid response like 451 4.7.50 Temporary lookup failure confirms the issue is transient. If you later retry the same sequence and get acceptance, that's proof. RFC 6579 describes this behavior as an accepted antispam measure.

Some email verification tools, like our bulk verification platform, test deliverability automatically and flag temporary issues like greylisting during checks—helping you avoid manual telnet drills. You can catch routing problems early by simulating real-world delivery paths using tools that check both syntax and server-level responses.

When debugging, always check the server's response code. A 4xx is not a mistake—it’s a feature. The key is knowing when to retry versus when to investigate further. If the same server keeps replying 4xx consistently beyond 30 minutes, that’s a red flag worth deeper inspection.

How Catch-All, Role, and Disposable Emails Affect Deliverability

When your email list includes catch-all addresses, role accounts, or disposable domains, you risk damaging your sender reputation—even if those emails technically "exist." These types of addresses can inflate bounce rates, trigger spam filters, or create false success signals. The result? Lower inbox placement, higher bounce rates, and possible blacklisting. Clean your list before sending to avoid these pitfalls.

Catch-All Addresses: False Positives and Spam Traps

Catch-all email setups accept every message sent to them, regardless of whether the specific address is valid or not. That sounds harmless—until you realize it’s often abused by spammers or used as a spam trap. If you send to a catch-all, you’re not just hitting a valid inbox—you could be triggering a spam trap that monitors for high-volume sending patterns.

These traps are commonly found in old or inactive domains and are especially dangerous because they don’t bounce. You’ll get no feedback, but your sender reputation takes a hit. According to the Messaging, Malware, and Mobile Anti-Abuse Working Group (M3AAWG), sender reputation is one of the top factors in inbox placement decisions, and sending to non-deliverable traps undermines that reputation.

Role Accounts and Disposable Domains: Deliverability Risks You Can’t Ignore

Role accounts—like admin@, sales@, or support@—aren’t meant for individual users. Most major email providers monitor them closely. If you send to a role account, especially at scale, you risk being flagged as a potential spammer or being ignored entirely. They often end up in spam folders or are silently dropped.

Disposable domains (like mailinator.com or tempmail.org) are built to be temporary. They’re used by people creating fake accounts or bypassing verification. Most reputable sending platforms, including Gmail, Outlook, and Yahoo, block messages to these domains by default. Sending to them doesn’t deliver, and doing so repeatedly can hurt your standing with reputation systems.

These address types distort your deliverability metrics. A high volume of non-deliverable roles or catch-alls looks like poor list hygiene to providers. Even if the email technically "accepts" messages, it doesn’t mean it’s a real person—and that’s what really matters for engagement.

Prevention starts with verification. Use tools that filter out these types of addresses before you send. For example, bulk verification can identify catch-alls, role addresses, and disposable domains in your list before your campaign starts, saving you reputation risk and wasted sends.

How Email Verification Tools Like Emaillistchecker.io Complement DNS Checks

You can trace email routing with DNS tools like dig or nslookup, but they only confirm server-level reachability — not whether an address is actually deliverable. Tools like Emaillistchecker.io go beyond routing by validating if an email exists, is active, and won’t bounce. This saves time and prevents wasted sends on invalid or risky addresses.

DNS Checks vs. True Deliverability

DNS records like MX and SPF tell you where mail should go, but not if the mailbox accepts it. A valid MX record doesn’t mean the account is real — catch-all servers can accept any address, falsely suggesting deliverability. That’s where email verification adds real value.

With a 98.9% accuracy rate, Emaillistchecker.io checks full lists at scale. It identifies invalid emails, catch-all domains, role accounts like info@ or sales@, and disposable addresses — all of which hurt deliverability and hurt sender reputation. You can see exactly what’s wrong through detailed verdicts before sending.

Integration and Automation for Better List Hygiene

Let's say you're building a campaign in Mailchimp or SendGrid. Without cleaning, high bounce rates can get your IP flagged. Emaillistchecker.io integrates directly with Mailchimp, SendGrid, Klaviyo, and HubSpot to scrub lists on import. You’re not just checking routing — you’re improving inbox placement from day one.

Its real-time API lets you verify addresses live during sign-ups, preventing invalid data from ever entering your database. The in-app AI assistant helps you interpret results when something seems off — like why a domain has many “risky” addresses, or if a high bounce rate correlates with a specific segment.

For teams that send regularly, running your list through bulk verification before every campaign is a proven way to stay off blocklists. This isn’t about speed — it’s about ensuring every message lands where it’s meant to.

While tools like dig, mtr, or MxToolbox help diagnose routing failures, they don’t check if the email address is a real, active mailbox. The RFC 5321 specification defines how servers handle mail delivery, but it doesn’t define what makes an address valid — that’s what a service like Emaillistchecker.io fills.

Use DNS tools to verify infrastructure. Use email verification to verify human intent. Together, they cover both ends of the delivery chain. You’re not just diagnosing why mail fails — you’re preventing failure before it happens.

What to Do When DNS Checks Pass but Messages Still Fail

If your DNS records are correct but emails still bounce or land in spam, the issue often lies beyond DNS—like sender reputation, IP blocklists, or poor sending patterns. Even with flawless DNS, a misbehaving sending domain or IP can get rejected silently. Let’s debug what’s really blocking delivery.

Check Your Sender Reputation

High bounce rates or spam complaints hurt your domain’s trust score over time. Even if DNS is fine, ISPs block messages if they detect poor engagement.
Monitor your sending practices: avoid buying lists or sending to inactive addresses. Use bulk email verification to clean lists before sending.
Spam traps and invalid addresses in your list trigger red flags. They don’t cause DNS failures, but they do damage reputation.

Verify IP and Domain Status on Blocklists

Run your sending IP through tools like MxToolbox or Spamhaus to check if it’s blacklisted. A single hit can stop delivery.
Some blocklists act fast—like Spamhaus, which can list IPs within hours of detecting spam. Even if recent, they often require a removal request.
Don’t assume DNS checks cover this. A domain passes MX and SPF checks but still gets blocked if the IP is flagged.

Warm Up Your Domain and IPs

Domains with no sending history get marked as suspicious. New domains must start with small volumes—100-200 emails per day—and grow gradually over weeks.
Use consistent sending patterns: avoid spikes. ISPs track behavior, not just technical setup.
Even with valid DNS, a cold domain with sudden traffic is treated like spam. Warm-up is not optional—it’s required for deliverability.

Test Inbox Placement Early and Often

Final delivery isn’t guaranteed just because the message reaches the inbox queue. Many messages get filtered into spam folders.
Use inbox placement testing tools to see if your emails land in the primary inbox or get marked as spam. This reveals issues DNS checks can’t catch.
Test across multiple providers—Gmail, Outlook, Yahoo—because they use different filtering logic. Inbox placement tests help catch filters early.

Even perfect DNS means nothing if your sending behavior doesn't meet ISP expectations.

Conclusion: DNS Tools Are Your First Line of Defense

DNS misconfigurations are not just minor hiccups—they are a primary root cause of email routing failures. SPF, DKIM, and DMARC records must be correct, consistent, and properly published to avoid rejection or filtering.

Command-line tools like dig, nslookup, and telnet deliver immediate, accurate feedback on DNS records and SMTP connectivity without relying on third-party services. They give you full control over diagnosing problems at the infrastructure layer.

Complementing DNS debugging with systematic email verification—such as validating lists for invalid, role-based, or disposable addresses—protects your sender reputation and improves inbox placement. This dual approach ensures your email infrastructure is both technically sound and reputation-safe.

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

What does 'non-existent domain' mean in DNS lookup?

It means the domain has no MX or A records. The email server cannot be found, causing delivery failures. Check for typos or expired domains.

Can I test DMARC policies without sending mail?

Yes. Use `dig TXT dmarc.example.com` to check the policy. A missing record means no enforcement is in place. A `p=reject` policy blocks unauthenticated mail.

Why does telnet show '421' or '550' during SMTP testing?

'421' means the server is temporarily unavailable. '550' means the message was rejected, often due to policy, full inbox, or blacklisting.

Does SPF block all spam emails?

No. SPF only validates sender authorization. It prevents spoofing but does not detect malicious content. It must be combined with DKIM and DMARC.

How often should I check my DNS records?

At least once per month for maintained domains. Recheck after any configuration change, including new hosting or email provider setup.

What are the signs of a greylisted server?

A temporary rejection like `451 4.7.50` during the SMTP handshake. The message should be retried after 15–30 minutes.

Can a valid domain still have a spam trap?

Yes. If an old address is re-activated without notification, it can become a spam trap. Use tools like Emaillistchecker.io to identify such addresses.

Why is my mail going to spam despite having SPF and DKIM?

Because spam filters consider content, sender reputation, engagement, and list quality, not just technical authentication.

Can disposable email domains be verified as valid?

Yes, they resolve and accept mail, but they are not suitable for marketing. Emaillistchecker.io flags them as disposable.

How do I know if my DKIM key is correct?

Use `dig TXT default._domainkey.example.com` to check the published key. Then verify signature generation matches the public key.

Do I need DKIM if I have SPF?

Yes. SPF only verifies the sending server. DKIM ensures message integrity. Both are essential for strong deliverability.

What’s the easiest way to start debugging email routing?

Run `dig MX example.com` and `dig TXT example.com` to check basic DNS records. Then use `telnet` to test the SMTP handshake.