Check MX Record TTL & Expiration via CLI

Why MX record TTL and expiration matter for email deliverability

You’re sending a time-sensitive campaign, and half the messages never arrive. No bouncebacks. No errors. Just silence. It’s frustrating — and often, the fault lies not in your email content, but in a misconfigured MX record TTL.

MX records tell the internet where to deliver incoming email. Their TTL (Time to Live) determines how long DNS resolvers cache the record. If TTLs are too long during a change, routing can remain outdated for hours or days. If too short, you risk excessive DNS queries and performance issues. Incorrect or expired TTLs are silently responsible for intermittent delivery failures — especially during migrations or server updates.

Understanding how to check MX record TTL and expiration using command line tools isn’t just a technical curiosity. It’s a practical step in ensuring mail flow remains consistent, predictable, and resilient.

Key takeaways

MX record TTL controls how long resolvers cache DNS responses — too long, and changes lag; too short, and DNS load increases.
Expired or misconfigured TTLs during domain migration or mail server changes can cause delayed or failed email delivery.
Using command-line tools like dig or nslookup to check MX record TTL and expiration helps diagnose and resolve inconsistent email routing issues.

What does 'MX record TTL and expiration' actually mean?

MX record TTL (Time to Live) is the number of seconds a DNS resolver holds a copy of your MX record in its cache before checking for updates. When TTL expires, the resolver queries the authoritative DNS server again. If the record is outdated—say, due to a failed email provider switch—mail servers might still send to the old, unreachable address, causing delivery failures. You can check this using command-line tools like dig or nslookup to see how long a record remains active.

TTL isn't about expiration—it's about caching behavior

TTL doesn't mean the record "expires" in the traditional sense. Instead, it controls how long resolvers trust cached data. A low TTL (like 300 seconds) means resolvers check more often, reducing the risk of sending mail to stale addresses. But it also increases DNS query volume. A high TTL (like 86,400 seconds) reduces load but delays updates—meaning a misconfigured MX record can remain active for a full day.

For example, if you change your email provider on Monday but your MX record still has a 24-hour TTL, any resolver that cached it before the change will keep using the old server until the cache expires. That's why setting a short TTL before making DNS changes is standard practice. According to RFC 1035, DNS resolvers are free to respect or ignore TTL values—but they typically do.

Why outdated MX records break email delivery

When a DNS resolver serves a stale MX record, mail servers attempt delivery to a non-functional destination. The result? Hard bounces, failed delivery reports, and lower sender reputation. This is especially problematic if the old server is no longer active or has strict spam filters.

Let’s say your company migrates from oldmail.com to newmail.com. If the old MX record with a 48-hour TTL isn't updated properly, mail from a week later might still go to the old server—leading to dropped emails and poor inbox placement. Tools like bulk verification can help catch these issues early by confirming that email addresses have valid, up-to-date MX records before sending.

Use dig MX yourdomain.com or similar commands to inspect currently cached MX records and their TTL values. This visibility helps you verify that changes are propagating and that your email delivery system isn’t relying on outdated data. It’s a small but critical detail in maintaining reliable email delivery.

How to check MX record TTL and expiration using DNS command-line tools

You can check MX record TTL and expiration using the dig command with the +qr flag to focus on the DNS response. Run dig MX example.com +qr to retrieve the record, where TTL appears in the response line—typically in seconds. This tells you how long the record is cached and helps diagnose delivery timing issues. For deeper DNS insight, consult the authoritative RFC 1035 for DNS specification details.

Step-by-step: Query MX records with precise output

Open your terminal or command-line interface. Ensure dig is installed—most Linux and macOS systems include it by default. You can confirm with which dig.
Run dig MX example.com +qr. The +qr flag strips away extra debugging headers, showing only the query and response. This keeps output clean and focused.
Look for the TTL (Time to Live) value in the response. It appears just after the domain name and record type, like 3600 IN MX 10 mail.example.com. The 3600 is the TTL in seconds—how long resolvers cache the record.
Check the SOA record separately with dig SOA example.com +qr. The SOA's minimum TTL (also in seconds) sets the default cache duration for all records if not overridden.
Use dig +time=5 MX example.com to test response speed. If it takes longer than 5 seconds, the DNS server may be slow or unreachable—indicating potential delivery latency.

Why TTL matters for deliverability

A low or improperly set TTL can cause delays in DNS propagation after changes. For example, if you switch email providers, a 3600-second (1-hour) TTL means old MX records stay cached for up to an hour—possibly causing email delivery failures. Setting a higher TTL (e.g., 86400 seconds) before changes reduces this risk.

The 5 steps described in “Step-by-step: Query MX records with precise output”, in order.

RFC 1035 defines the DNS protocol, including TTL behavior. Understanding this enables better email infrastructure design. Tools like Bulk Email Verification can help identify misconfigured domains in your list before sending.

Understanding the DNS response: decoding TTL and expiration

When you check an MX record using the command line, the TTL (Time to Live) value tells you how long the record should be cached—3600 seconds means one hour, and a higher value like 86400 means up to 24 hours before changes take effect. If your TTL is set high, updates to your MX record may not propagate for days, which can delay email delivery. Low TTLs, like 300 seconds, speed up propagation but increase query load on the authoritative DNS server.

What TTL means in practice

Every DNS response includes a TTL value in seconds. For example, an MX record with a TTL of 3600 should be cached for one hour by resolvers and other servers. If you change your MX settings and the TTL is set to 86400 (24 hours), clients may continue using the old record for up to that full period, even after the change is made.

During DNS propagation, this delay can cause inconsistent email delivery. You've likely seen this when setting up a new email provider—your inbox doesn’t update right away because older caches still hold the old records.

Striking the right balance

Using a low TTL (e.g., 300 seconds) before making changes lets you update MX records quickly, which is essential during server migrations or domain changes. But setting it too low all the time increases DNS traffic, putting more load on your authoritative server.

It’s standard practice to lower the TTL a few days before making changes and raise it again afterward. This approach minimizes downtime while keeping query load manageable. The DNS protocol itself, defined in RFC 1035, allows for flexible TTL values—there’s no one-size-fits-all approach.

For email verification on bulk lists, checking DNS records is part of validating deliverability. Tools like bulk email verification can automatically detect issues like invalid MX records or misconfigured DNS, saving time and improving sender reputation.

How often should you check MX record TTL and expiration?

You should check MX record TTL and expiration before launching new campaigns, after switching email providers, and at least quarterly if you send at scale. Delayed propagation or expired TTLs can disrupt delivery, especially during critical send windows. Use command-line tools like dig or host to verify TTLs in real time.

When to act—specific triggers

Before launching a new email campaign: Validate MX TTLs to ensure your message reaches inboxes without delay. A low TTL (e.g., 300 seconds) helps you react quickly if changes fail.
After switching mail server providers: Confirm that new MX records have propagated fully across the internet. Use RFC 1035 as a reference for DNS propagation expectations.
Quarterly for high-volume senders: Even with stable systems, DNS changes can occur unexpectedly. Regular verification helps catch issues before they hurt deliverability.
Post-migration from legacy systems: Verify that old MX records are no longer active and new ones resolve correctly across global networks.

Why frequent checks matter

MX TTLs determine how quickly changes take effect across DNS caches. A high TTL (like 86,400 seconds) means changes can take days to propagate. If you’re migrating or troubleshooting, waiting days for DNS updates isn’t an option. Checking TTLs and expiration ensures you’re not blind to delivery risks.

Monitoring these metrics is part of maintaining sender reputation. ISPs track consistent, well-formed DNS records. A misconfigured or outdated MX record can signal unreliable sending practices, increasing the chance of filtering. For teams using multiple ESPs or managing many domains, this isn’t optional—it’s operational hygiene.

Even a single delayed email campaign can cost revenue. Knowing your DNS is ready is as important as knowing your list is clean.

If you’re validating entire email lists for deliverability, ensure your verification tools also analyze MX and DNS health. Bulk email verification through Emaillistchecker.io includes DNS-level checks, helping identify invalid or misrouted addresses early in the process.

What happens if MX TTL is too high or expired?

If your MX record has a very high TTL—like 86400 seconds (24 hours)—a change to your mail server configuration won’t propagate quickly. During a migration or outage, this delay can cause emails to be routed to the wrong server or fail entirely. If the record is expired or removed, mail servers may return a permanent failure or pause delivery indefinitely. An expired record also leaves your domain vulnerable to spoofing if DMARC isn’t properly enforced, as there’s no valid mail server listed to validate authenticity.

High TTL slows down emergency changes

Let’s say you’re switching email providers. With a TTL of 86400, the old MX record may stay cached in DNS resolvers for up to a full day. That means users might still try to send to the old server even after you’ve updated it. Delivery fails, users get errors, and your sender reputation can take a hit. If a system needs a fix in hours—not days—high TTLs become a real bottleneck.

Expired MX records break mail delivery

When an MX record is unregistered or deleted, DNS returns a 'no MX record' response. Mail servers then treat this as a permanent failure and may stop trying to deliver. Unlike transient issues (like temporary server load), there’s no retry logic for a missing MX. The message is gone—silently, without bounceback. This is especially dangerous if your domain is supposed to receive support emails or transactions.

DMARC helps prevent spoofing by requiring valid SPF and DKIM alignment, but it relies on correct DNS records. If your domain has no MX record, DMARC can’t enforce proper sender authentication. Attackers may exploit this gap to send phishing emails that appear to come from your domain. According to RFC 5321, the SMTP protocol depends on valid MX records to route messages correctly—removing one without updating policies risks both delivery and security.

You can test your domain’s current MX records and their TTL values in seconds using command-line tools like dig or nslookup. But checking one domain at a time doesn’t scale for large lists. For teams managing bulk email, it’s better to verify entire lists for valid and active records. That includes not just MX, but also SPF, DKIM, and DMARC. Our bulk verification tool checks DNS records—including MX TTL and validity—across thousands of addresses in minutes.

How command-line verification helps prevent email delivery failures

Using dig or nslookup to check MX record TTL and expiration gives you real-time proof of how your DNS setup is behaving today—no guesswork. If your TTL is too long, changes take hours to propagate; if it's too short, you’re flooding resolvers. Proactively verifying these settings ensures your mail routing stays accurate and responsive, directly reducing delivery failures.

Real-time DNS checks eliminate uncertainty

You don’t need to wait for symptoms to appear. With dig or nslookup, you can check the current state of an MX record right now—no reliance on caches or third-party tools. This is critical when verifying SPF, DKIM, or DMARC setups, as even a single mismatched record can trigger filtering.

For example, running dig MX example.com shows the exact TTL and IP addresses currently in use. You can see if the record is still pointing to an old server or if a recent change hasn’t propagated. This level of transparency is unavailable in most web-based tools that rely on cached data.

Optimizing TTL for reliability and speed

TTL (Time to Live) controls how long a DNS result is cached. A TTL of 300 seconds (5 minutes) is standard for fast failover; 86400 (24 hours) is common but risky when making frequent changes. You can test your current TTL by querying the same record multiple times in quick succession and noting how often the result changes.

According to RFC 1035, DNS caching is designed to reduce load, but it also delays the impact of updates. If you’re rolling out a new email server or troubleshooting a blackhole, a long TTL can delay recovery. Command-line tools let you verify whether TTL is aligned with your operational rhythm—whether you deploy weekly or daily.

When a record expires too soon or doesn’t propagate, inboxes fail to receive emails, or messages go to spam. Regular checks with dig prevent this. This isn’t about guessing—it’s about proof.

For teams using email lists at scale, verifying DNS settings in bulk is a necessity. While command-line tools give you granular visibility, automated systems can scale this across thousands of domains. Bulk verification tools can validate DNS health across entire lists, ensuring every address has properly configured records before sending.

Using Emaillistchecker.io to supplement DNS checks

Checking MX record TTL and expiration via command line confirms DNS record presence and timing, but it doesn’t tell you if emails to those domains actually get delivered. Emaillistchecker.io goes beyond DNS by testing real SMTP sessions with providers like Gmail and Yahoo to verify whether messages land in the inbox or get filtered—something DNS alone cannot show. Even if MX records appear valid, a domain might still reject legitimate mail due to catch-all settings, greylisting, or sender reputation issues.

Real-world delivery testing beats theoretical DNS checks

DNS tools tell you what’s configured. Emaillistchecker.io tells you what actually happens when you send. It simulates real mail delivery by initiating actual SMTP connections with major providers, which helps catch issues that aren’t visible in the DNS layer—like temporary delivery delays from greylisting or automatic filtering due to poor sender reputation.

For example, a domain may have a correct MX record with a 3600-second TTL, but still fail to receive mail because the mail server temporarily blocks connections from certain IP ranges. Tools like MXToolbox or Dig can confirm the record is there, but only real SMTP testing—using a service like inbox placement testing—can confirm whether a message gets through.

Why DNS validation isn’t enough for email deliverability

TTL and expiration settings help with DNS propagation timing, but they don’t reflect whether a domain accepts incoming mail. A domain may have a functional MX record, but still block messages if it’s configured as a catch-all with spam filters, or if the sender’s IP is on a blocklist. These are delivery problems, not DNS problems.

That’s where Emaillistchecker.io adds value. It verifies email validity not just by checking DNS records, but by actually attempting inbox placement across real provider infrastructure. This includes testing for bounce types, spam filtering behavior, and whether a message reaches a live inbox. The result is a clear, actionable verdict: valid, risky, or invalid.

Beyond delivery verification, it supports bulk checking via bulk verification, API integration for automated flows, or even email finder tools to build lists from known domains. You’re not just checking records—you’re testing whether your emails will land where they need to.

Best practices for managing MX record TTL

You should set MX record TTL to 300–600 seconds when making frequent changes to your mail server configuration, reduce it to 86400 seconds (24 hours) for stable setups to minimize DNS queries, and lower it to 300 seconds at least 24 hours before any planned DNS update to prevent propagation delays. This approach balances responsiveness with DNS efficiency across varying operational needs.

Adjust TTL based on change frequency

Use a low TTL of 300–600 seconds for domains where you frequently update MX records or switch mail servers. This ensures changes propagate quickly worldwide.
For stable configurations with no planned changes, set TTL to 86400 seconds (24 hours) to reduce query load on DNS resolvers, which improves overall DNS performance and reduces network overhead.
Reduce TTL to 300 seconds at least 24 hours before any DNS change you're planning. This prevents long wait times during propagation and avoids periods where some users receive old or incorrect routing.

Practical execution and monitoring

Use command-line tools like dig or nslookup to check the current TTL value on MX records in real time. This helps verify your settings before and after changes.
Monitor DNS propagation using public tools like MXToolbox or DNSChecker.org to verify global consistency after updates.
Always test your email delivery setup with inbox placement tools—even with correct TTLs, deliverability depends on authentication (SPF, DKIM, DMARC), sender reputation, and message content.
When managing large email lists, use a reliable email verification service to ensure your outbound mail isn't sent to invalid or risky addresses, which can hurt your sender reputation.

Let’s say you’re moving your mail server. Setting a low TTL ahead of time gives you control; failing to do so can leave parts of your user base unable to receive mail for days. For teams building or managing email campaigns, this proactive setup reduces the risk of deliverability issues.

For ongoing list hygiene and high deliverability, consider running bulk verification on your email lists to remove outdated or invalid addresses. You can test your full email workflow from address validation to inbox placement with bulk email verification or integrate directly via our real-time verification API.

Common mistakes when handling MX records and their impact

You risk email delivery failure when you overlook MX record TTLs during migration, assume DNS changes propagate instantly across all networks, or treat a correctly configured MX as a guarantee of inbox delivery—even if the target server is offline or unreachable. These errors are common, technically avoidable, and frequently lead to bounces, delayed messages, or lost communications.

Ignoring TTL during migration leads to inconsistent routing

When you change an MX record, the TTL (Time to Live) determines how long DNS resolvers cache the old value. If TTL is set too high before the change, some users may still send mail to the old server for days. Even if you adjust the TTL in advance, the window of inconsistency remains—and during that time, mail gets routed incorrectly. It’s a silent failure: the DNS is correct, but the routing isn’t.

Let’s say you lower the TTL to 300 seconds (5 minutes) 48 hours before migrating. If the change takes 10 minutes to propagate, you’re still in a race with cached records. Most email systems don’t check DNS more frequently than once per TTL period. This lag means real-world delivery isn’t guaranteed just because the record looks right in a tool.

Use RFC 1035 as a reference for how DNS caching works—this foundation explains why propagation isn’t instant, no matter how confident you are.

Propagation is not universal, and cache behavior varies

Just because your local machine resolves the new MX record doesn’t mean it’s resolved everywhere. Providers like Cloudflare, AWS Route 53, and ISP-level DNS services maintain different cache policies. A change might appear on one network’s DNS query but not on another. This means your test results can be misleading.

Don’t assume confirmation via a single tool, even one that checks global DNS, implies universal propagation. You need to test from multiple vantage points—ideally from different geographic regions and ISP networks—to avoid false confidence.

And here’s the real trap: a perfectly valid MX record doesn’t mean the mail server is accepting connections. The server might be offline, behind a firewall, or misconfigured. You can have correct DNS, yet still see delivery failures. This is why you must validate both DNS and server reachability—tools like inbox placement testing simulate real delivery by checking actual server behavior, not just DNS metadata.

In short: correct MX records are necessary but not sufficient. Propagation delays, caching differences, and server availability are the real culprits behind failed deliveries—and checking only DNS gives you a false sense of security.

Conclusion: proactively verify MX record TTL and expiration

MX record TTL tells you how long DNS resolvers cache your record. Using tools like `dig` gives you direct, real-time insight into that value and helps you detect changes before they impact delivery.

Persistent TTL checks, combined with inbox placement tests, confirm that your email infrastructure remains stable through migrations, outages, or reputation audits.

Keeping track of TTL and expiration ensures your deliverability isn't disrupted by stale DNS data.

Sources

Catch-all addresses made up 9% of all emails checked in 2025 — over 1 billion addresses that can look valid but still bounce and damage sender reputation. — ZeroBounce Email List Decay Report (2025)
Validity's analysis of 22+ million domains found 84% of domains used in email From addresses have no published DMARC record at all. — Validity (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

How do I check MX record TTL using the command line?

Use the `dig MX example.com +qr` command. Look for the TTL value in the output — it appears in seconds and shows how long resolvers cache the record.

What happens if an MX record has an expired TTL?

If an MX record is expired, mail servers may still use the cached version, possibly sending to a dead or unreachable destination. This causes delivery failures.

Why should I check MX record expiration before sending email campaigns?

An expired or stale MX record can result in messages being lost or delayed. Validating TTL ensures mail is routed correctly to your current mail server.

Can I set MX record TTL to zero?

No — TTL cannot be zero. Minimum values are typically 300 seconds. Setting a very low TTL improves update speed but increases DNS load.

How often do MX records update in DNS?

Records update when their TTL expires and resolvers re-poll the authoritative server. This depends on the TTL value, ranging from minutes to days.

What's the difference between MX TTL and DNS expiration?

TTL is the cache duration in seconds. DNS expiration refers to the record no longer existing or being invalidated. TTL governs when expiration is checked.

Can I use Emaillistchecker.io to test if my MX record is working?

Yes. It performs inbox-placement tests using real SMTP sessions. It verifies if your domain’s MX configuration leads to successful delivery in actual inboxes.

Is checking MX TTL via command line sufficient for deliverability?

It’s necessary but not sufficient. You must also test actual delivery to ensure the mail server is responsive and not blocked by spam filters.

Why does my email fail when the MX record looks correct in dig?

A correct MX record doesn’t guarantee delivery. Issues like server downtime, lack of SPF/DKIM, or spam filter blocking can still prevent inbox placement.

What TTL value is best for email servers?

For stable setups, 86400 seconds (24 hours). For systems with frequent changes, 300–600 seconds. Avoid values above 86400 unless stable.

Can a catch-all email server affect MX record TTL validity?

Catch-all servers don’t affect TTL directly. But misconfigured catch-alls can cause delivery issues even if MX records are correct.

Do I need to check MX record TTL for every domain I’m sending to?

Only for domains you manage. For external domains, check TTL to understand their configuration, but focus on sender-side settings like SPF, DKIM, and reputation.