{"id":4028,"date":"2026-01-02T21:28:05","date_gmt":"2026-01-02T18:28:05","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/dns-ttl-best-practices-for-a-mx-cname-and-txt-records\/"},"modified":"2026-01-02T21:28:05","modified_gmt":"2026-01-02T18:28:05","slug":"dns-ttl-best-practices-for-a-mx-cname-and-txt-records","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/dns-ttl-best-practices-for-a-mx-cname-and-txt-records\/","title":{"rendered":"DNS TTL Best Practices for A, MX, CNAME and TXT Records"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>DNS TTL looks like a tiny detail in your zone file, but it quietly decides how fast changes take effect, how resilient your services are to DNS outages, and even how predictable your migrations will be. At dchost.com we constantly see two extremes: zones where everything is stuck at 86400 seconds \u2018because that\u2019s the default\u2019, and zones where every record is set to 60 seconds \u2018just in case\u2019. Both approaches cause real problems in production. In this guide we will walk through practical, battle-tested TTL strategies for A, MX, CNAME and TXT records, with concrete numbers and scenarios you can apply immediately. Whether you are running a single WordPress site on shared hosting or a multi-region setup on VPS and <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a>s, a sane TTL policy will save you downtime, stress and debugging time.<\/p>\n<div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#What_DNS_TTL_Really_Does_In_Plain_Language\"><span class=\"toc_number toc_depth_1\">1<\/span> What DNS TTL Really Does (In Plain Language)<\/a><ul><li><a href=\"#Where_TTL_Is_Honored\"><span class=\"toc_number toc_depth_2\">1.1<\/span> Where TTL Is Honored<\/a><\/li><li><a href=\"#Why_TTL_Choices_Matter\"><span class=\"toc_number toc_depth_2\">1.2<\/span> Why TTL Choices Matter<\/a><\/li><\/ul><\/li><li><a href=\"#Low_vs_High_TTL_The_Real-World_Trade-Offs\"><span class=\"toc_number toc_depth_1\">2<\/span> Low vs High TTL: The Real-World Trade-Offs<\/a><ul><li><a href=\"#Benefits_of_Low_TTL_Values\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Benefits of Low TTL Values<\/a><\/li><li><a href=\"#Benefits_of_High_TTL_Values\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Benefits of High TTL Values<\/a><\/li><li><a href=\"#Common_TTL_Mistakes_We_See\"><span class=\"toc_number toc_depth_2\">2.3<\/span> Common TTL Mistakes We See<\/a><\/li><\/ul><\/li><li><a href=\"#A_and_AAAA_Records_Web_API_and_Critical_App_TTL_Strategy\"><span class=\"toc_number toc_depth_1\">3<\/span> A and AAAA Records: Web, API and Critical App TTL Strategy<\/a><ul><li><a href=\"#Good_Default_TTL_Ranges_for_A_AAAA\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Good Default TTL Ranges for A \/ AAAA<\/a><\/li><li><a href=\"#TTL_Strategy_for_Migrations_and_Cutovers\"><span class=\"toc_number toc_depth_2\">3.2<\/span> TTL Strategy for Migrations and Cutovers<\/a><\/li><li><a href=\"#Special_Cases_Multi-Region_Failover_and_CDNs\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Special Cases: Multi-Region, Failover and CDNs<\/a><\/li><\/ul><\/li><li><a href=\"#MX_Records_Email_Must_Be_Boring_and_Predictable\"><span class=\"toc_number toc_depth_1\">4<\/span> MX Records: Email Must Be Boring and Predictable<\/a><ul><li><a href=\"#Recommended_TTLs_for_MX_Records\"><span class=\"toc_number toc_depth_2\">4.1<\/span> Recommended TTLs for MX Records<\/a><\/li><li><a href=\"#MX_TTL_During_Email_Provider_Migration\"><span class=\"toc_number toc_depth_2\">4.2<\/span> MX TTL During Email Provider Migration<\/a><\/li><\/ul><\/li><li><a href=\"#TXT_Records_SPF_DKIM_DMARC_and_Verification\"><span class=\"toc_number toc_depth_1\">5<\/span> TXT Records: SPF, DKIM, DMARC and Verification<\/a><ul><li><a href=\"#TTL_Strategy_for_SPF_TXT_Records\"><span class=\"toc_number toc_depth_2\">5.1<\/span> TTL Strategy for SPF TXT Records<\/a><\/li><li><a href=\"#TTL_for_DKIM_and_DMARC_TXT_Records\"><span class=\"toc_number toc_depth_2\">5.2<\/span> TTL for DKIM and DMARC TXT Records<\/a><\/li><li><a href=\"#Other_TXT_Records_Verification_and_Service_Config\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Other TXT Records: Verification and Service Config<\/a><\/li><\/ul><\/li><li><a href=\"#CNAME_Records_Flexibility_With_Careful_TTLs\"><span class=\"toc_number toc_depth_1\">6<\/span> CNAME Records: Flexibility With Careful TTLs<\/a><ul><li><a href=\"#Default_TTL_Ranges_for_CNAMEs\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Default TTL Ranges for CNAMEs<\/a><\/li><li><a href=\"#CNAME_at_the_Apex_and_ALIASANAME\"><span class=\"toc_number toc_depth_2\">6.2<\/span> CNAME at the Apex and ALIAS\/ANAME<\/a><\/li><\/ul><\/li><li><a href=\"#Designing_a_DNS_TTL_Policy_That_Actually_Works\"><span class=\"toc_number toc_depth_1\">7<\/span> Designing a DNS TTL Policy That Actually Works<\/a><ul><li><a href=\"#A_Simple_Baseline_Policy_by_Record_Type\"><span class=\"toc_number toc_depth_2\">7.1<\/span> A Simple Baseline Policy by Record Type<\/a><\/li><li><a href=\"#TTL_Change_Management_A_Mini_Runbook\"><span class=\"toc_number toc_depth_2\">7.2<\/span> TTL Change Management: A Mini Runbook<\/a><\/li><li><a href=\"#Monitoring_and_Troubleshooting_TTL-Related_Issues\"><span class=\"toc_number toc_depth_2\">7.3<\/span> Monitoring and Troubleshooting TTL-Related Issues<\/a><\/li><\/ul><\/li><li><a href=\"#How_dchostcom_Fits_Into_Your_DNS_and_TTL_Strategy\"><span class=\"toc_number toc_depth_1\">8<\/span> How dchost.com Fits Into Your DNS and TTL Strategy<\/a><\/li><li><a href=\"#Conclusion_Turn_TTL_From_a_Guess_Into_a_Policy\"><span class=\"toc_number toc_depth_1\">9<\/span> Conclusion: Turn TTL From a Guess Into a Policy<\/a><\/li><\/ul><\/div>\n<h2><span id=\"What_DNS_TTL_Really_Does_In_Plain_Language\">What DNS TTL Really Does (In Plain Language)<\/span><\/h2>\n<p><strong>TTL (Time To Live)<\/strong> is a value in seconds that tells DNS resolvers how long they are allowed to cache a record before asking again from the authoritative DNS server. The higher the TTL, the longer that answer can be reused.<\/p>\n<h3><span id=\"Where_TTL_Is_Honored\">Where TTL Is Honored<\/span><\/h3>\n<p>When a user types your domain into the browser, the lookup passes through several layers that may cache DNS responses:<\/p>\n<ul>\n<li><strong>Recursive resolver (ISP or public DNS)<\/strong> \u2013 the main cache that respects your TTL.<\/li>\n<li><strong>OS cache<\/strong> \u2013 Windows, macOS, Linux maintain their own DNS cache.<\/li>\n<li><strong>Browser cache<\/strong> \u2013 modern browsers may cache DNS results for a short period.<\/li>\n<\/ul>\n<p>Your <strong>TTL only directly controls how long the recursive resolver can cache your record<\/strong>. The rest usually cache for shorter periods or obey the resolver\u2019s answer.<\/p>\n<h3><span id=\"Why_TTL_Choices_Matter\">Why TTL Choices Matter<\/span><\/h3>\n<p>TTL is not just a performance knob. It affects:<\/p>\n<ul>\n<li><strong>Change speed<\/strong> \u2013 how quickly a new IP, mail server or SPF record becomes visible worldwide.<\/li>\n<li><strong>Stability during outages<\/strong> \u2013 higher TTLs keep cached answers available if your DNS provider or nameserver has a brief problem.<\/li>\n<li><strong>Load on DNS infrastructure<\/strong> \u2013 lower TTLs mean more frequent queries to your authoritative servers.<\/li>\n<li><strong>Predictability of migrations<\/strong> \u2013 smart TTL planning can make DNS cutovers feel almost instant.<\/li>\n<\/ul>\n<p>If you need a refresher on record types themselves (A, AAAA, CNAME, MX, TXT, SRV, CAA), we recommend reading our article <a href='https:\/\/www.dchost.com\/blog\/en\/dns-kayitlari-adan-zye-a-aaaa-cname-mx-txt-srv-caa-ve-sizi-yakan-o-kucuk-hatalar\/'>DNS records explained like a friend<\/a> before you fine-tune TTL values.<\/p>\n<h2><span id=\"Low_vs_High_TTL_The_Real-World_Trade-Offs\">Low vs High TTL: The Real-World Trade-Offs<\/span><\/h2>\n<h3><span id=\"Benefits_of_Low_TTL_Values\">Benefits of Low TTL Values<\/span><\/h3>\n<p>Low TTL usually means 60\u2013600 seconds (1\u201310 minutes). The advantages:<\/p>\n<ul>\n<li><strong>Fast changes<\/strong> \u2013 move an A record to a new server and most users follow within minutes.<\/li>\n<li><strong>More flexible failover<\/strong> \u2013 if you update records as part of a manual failover plan, a low TTL keeps recovery times short.<\/li>\n<li><strong>Safer experimentation<\/strong> \u2013 easier to roll back a misconfiguration if the world forgets it in five minutes.<\/li>\n<\/ul>\n<p>Costs and risks:<\/p>\n<ul>\n<li><strong>More DNS queries<\/strong> \u2013 could slightly increase DNS costs or load at large scale.<\/li>\n<li><strong>Less protection from DNS outages<\/strong> \u2013 if the nameserver has a brief hiccup, caches expire quickly and users may notice.<\/li>\n<\/ul>\n<h3><span id=\"Benefits_of_High_TTL_Values\">Benefits of High TTL Values<\/span><\/h3>\n<p>High TTL typically means 14400\u201386400 seconds (4\u201324 hours).<\/p>\n<ul>\n<li><strong>Stable answers<\/strong> \u2013 resolvers rarely need to ask again, leading to fewer timeouts and more consistent performance.<\/li>\n<li><strong>Resilience to DNS hiccups<\/strong> \u2013 if authoritative DNS has a short outage, users can continue using cached records for hours.<\/li>\n<li><strong>Lower query volume<\/strong> \u2013 useful for very busy zones or complex enterprise DNS topologies.<\/li>\n<\/ul>\n<p>Downsides:<\/p>\n<ul>\n<li><strong>Slow propagation<\/strong> \u2013 a bad change can persist for many hours.<\/li>\n<li><strong>Migrations become tricky<\/strong> \u2013 switching hosting, MX providers or IP ranges becomes a multi-day project if you do not plan TTL ahead.<\/li>\n<\/ul>\n<h3><span id=\"Common_TTL_Mistakes_We_See\">Common TTL Mistakes We See<\/span><\/h3>\n<p>On the dchost.com support side, we frequently run into patterns like:<\/p>\n<ul>\n<li><strong>Everything at 86400<\/strong> \u2013 website IPs, MX, TXT, CNAME, all hard to change quickly.<\/li>\n<li><strong>Everything at 300<\/strong> \u2013 including DNSSEC-related records or zone NS records, causing unnecessary query load.<\/li>\n<li><strong>TTL never adjusted before big moves<\/strong> \u2013 leading to \u2018stuck\u2019 users on old servers even when cutover was planned.<\/li>\n<\/ul>\n<p>A smarter approach is to decide <strong>per record type and per use case<\/strong>. Let\u2019s break down practical TTL ranges for A, MX, CNAME and TXT.<\/p>\n<h2><span id=\"A_and_AAAA_Records_Web_API_and_Critical_App_TTL_Strategy\">A and AAAA Records: Web, API and Critical App TTL Strategy<\/span><\/h2>\n<p><strong>A<\/strong> and <strong>AAAA<\/strong> records point your domain to IPv4 and IPv6 addresses. They affect websites, APIs, admin panels and any service reached by hostname.<\/p>\n<h3><span id=\"Good_Default_TTL_Ranges_for_A_AAAA\">Good Default TTL Ranges for A \/ AAAA<\/span><\/h3>\n<p>In most real setups we manage, these are workable baselines:<\/p>\n<ul>\n<li><strong>Standard websites and APIs:<\/strong> 900\u20133600 seconds (15\u201360 minutes)<\/li>\n<li><strong>Highly stable, rarely changing IPs:<\/strong> 7200\u201314400 seconds (2\u20134 hours)<\/li>\n<li><strong>Actively evolving or under migration:<\/strong> 300\u2013600 seconds (5\u201310 minutes)<\/li>\n<\/ul>\n<p>How to think about it:<\/p>\n<ul>\n<li>If you move your site between hosting environments once every few years, a 1-hour TTL is a comfortable balance.<\/li>\n<li>If you are frequently changing infrastructure (e.g., moving microservices across VPS or dedicated servers), 300\u2013600 seconds is more realistic.<\/li>\n<li>Going lower than 300 seconds rarely brings benefits for public websites, but it does amplify DNS dependency and overhead.<\/li>\n<\/ul>\n<h3><span id=\"TTL_Strategy_for_Migrations_and_Cutovers\">TTL Strategy for Migrations and Cutovers<\/span><\/h3>\n<p>For moving a site between servers or providers, a structured TTL playbook is worth gold. The pattern we use internally and describe in detail in <a href='https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/'>our TTL playbook for zero-downtime migrations<\/a> looks like this:<\/p>\n<ol>\n<li><strong>1\u20133 days before migration<\/strong> \u2013 lower the A\/AAAA TTL from, say, 14400 to 300\u2013600 seconds.<\/li>\n<li><strong>Wait at least one full previous TTL<\/strong> \u2013 so that old caches expire and everyone starts honoring the new low TTL.<\/li>\n<li><strong>Perform the cutover<\/strong> \u2013 update A\/AAAA to the new server IP. Most traffic will move within minutes.<\/li>\n<li><strong>Monitor<\/strong> \u2013 track logs, error rates and performance metrics on both old and new servers.<\/li>\n<li><strong>Raise TTL again<\/strong> \u2013 once you are confident, increase back to your long-term value (e.g., 1800\u20133600 seconds).<\/li>\n<\/ol>\n<p>If you skip step 1, you are at the mercy of your previous high TTL. That is why DNS changes are sometimes perceived as \u2018taking 24 hours\u2019. For a deeper explanation of this behavior, see our article <a href='https:\/\/www.dchost.com\/blog\/en\/dns-yayilim-suresi-nedir-neden-24-saat-surer-ve-nasil-hizlandirilir\/'>what DNS propagation is and why it can seem so slow<\/a>.<\/p>\n<h3><span id=\"Special_Cases_Multi-Region_Failover_and_CDNs\">Special Cases: Multi-Region, Failover and CDNs<\/span><\/h3>\n<p>Some architectures rely on DNS-based traffic steering:<\/p>\n<ul>\n<li><strong>Multi-region hosting<\/strong> with GeoDNS or weighted records<\/li>\n<li><strong>DNS failover<\/strong> pointing to backup servers when health checks fail<\/li>\n<li><strong>Direct A\/AAAA records behind a CDN<\/strong> for origin reachability<\/li>\n<\/ul>\n<p>For these, we generally recommend:<\/p>\n<ul>\n<li><strong>TTL around 60\u2013300 seconds<\/strong> on the DNS-controlled \u2018decision\u2019 records so changes propagate quickly.<\/li>\n<li><strong>More stable TTLs<\/strong> on deeper, internal hostnames (e.g., between app and database servers) that rarely change.<\/li>\n<\/ul>\n<p>If you are interested in more complex designs, our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/kucuk-isletme-siteleri-icin-multi-region-dns-ve-cdn-failover-mimarisi\/'>multi-region DNS and CDN failover for small business websites<\/a> is a good next step.<\/p>\n<h2><span id=\"MX_Records_Email_Must_Be_Boring_and_Predictable\">MX Records: Email Must Be Boring and Predictable<\/span><\/h2>\n<p><strong>MX (Mail Exchanger)<\/strong> records tell the world which mail servers are responsible for accepting email for your domain. Unlike web traffic, where moving an IP is relatively common, changing MX records and email providers is something you should do rarely and carefully.<\/p>\n<h3><span id=\"Recommended_TTLs_for_MX_Records\">Recommended TTLs for MX Records<\/span><\/h3>\n<p>Our general rule at dchost.com:<\/p>\n<ul>\n<li><strong>MX TTL for stable, production domains:<\/strong> 3600\u201314400 seconds (1\u20134 hours)<\/li>\n<li><strong>MX TTL during planned migration:<\/strong> 600\u20131800 seconds (10\u201330 minutes)<\/li>\n<\/ul>\n<p>Why higher than web records?<\/p>\n<ul>\n<li><strong>Email is delay-tolerant by design<\/strong> \u2013 if a mail server is unreachable, senders queue and retry later.<\/li>\n<li><strong>Frequent MX changes are rare<\/strong> \u2013 so caching them for a bit longer does not hurt.<\/li>\n<li><strong>Stability is more important than ultra-fast cutovers<\/strong> \u2013 a few hours of dual delivery configuration is normal in email moves.<\/li>\n<\/ul>\n<h3><span id=\"MX_TTL_During_Email_Provider_Migration\">MX TTL During Email Provider Migration<\/span><\/h3>\n<p>When moving email from one provider to another (or from shared hosting to a dedicated mail server or VPS), combine TTL strategy with a dual delivery or staged migration plan:<\/p>\n<ol>\n<li><strong>Lower MX TTL to 600\u2013900 seconds<\/strong> 24\u201348 hours before cutover.<\/li>\n<li><strong>Configure new MX records with correct priorities<\/strong> while old ones are still present (if you plan a staged move).<\/li>\n<li><strong>Perform mailbox data migration<\/strong> (IMAP sync, exports\/imports, etc.).<\/li>\n<li><strong>Switch MX priorities<\/strong> so the new platform becomes primary.<\/li>\n<li><strong>Monitor bounces and logs<\/strong> on both sides, then raise TTL back to a more comfortable long-term value.<\/li>\n<\/ol>\n<p>For a detailed domain and email move playbook, see our guide on <a href='https:\/\/www.dchost.com\/blog\/en\/alan-adi-tasirken-e%e2%80%91posta-kesintisini-onlemek\/'>why domain transfers often break email and how to avoid it<\/a> and our article on <a href='https:\/\/www.dchost.com\/blog\/en\/e-posta-altyapisinda-yedeklilik-birden-fazla-mx-kaydi-backup-mx-ve-split-delivery-kurulumu\/'>email redundancy with multiple MX and backup MX<\/a>.<\/p>\n<h2><span id=\"TXT_Records_SPF_DKIM_DMARC_and_Verification\">TXT Records: SPF, DKIM, DMARC and Verification<\/span><\/h2>\n<p><strong>TXT records<\/strong> are used for many things: SPF, DKIM and DMARC for email authentication, service verifications, ownership checks and various application-specific configurations.<\/p>\n<h3><span id=\"TTL_Strategy_for_SPF_TXT_Records\">TTL Strategy for SPF TXT Records<\/span><\/h3>\n<p>SPF defines which servers are allowed to send email for your domain. It also has a <strong>10 DNS lookup limit<\/strong>, which makes SPF records sensitive to small changes and provider additions.<\/p>\n<p>Our recommendations:<\/p>\n<ul>\n<li><strong>Stable production SPF:<\/strong> 3600\u20137200 seconds (1\u20132 hours)<\/li>\n<li><strong>When experimenting or adding new mail providers:<\/strong> 300\u2013900 seconds (5\u201315 minutes)<\/li>\n<\/ul>\n<p>Typical workflow:<\/p>\n<ul>\n<li>Lower TTL, deploy SPF changes, send test mail to major providers (Gmail, Outlook, etc.).<\/li>\n<li>Check DMARC reports and delivery behavior for a day or two.<\/li>\n<li>Raise TTL once you are happy with the configuration.<\/li>\n<\/ul>\n<p>To dig deeper into SPF complexity and the 10-lookup limit, we recommend our article on <a href='https:\/\/www.dchost.com\/blog\/en\/gelismis-spf-yonetimi-10-dns-lookup-limitine-takilmadan-coklu-e-posta-servisi-kullanmak\/'>advanced SPF management for multiple email providers<\/a> and the broader deliverability guide <a href='https:\/\/www.dchost.com\/blog\/en\/spf-dkim-dmarc-ve-rdns-ile-e-posta-teslim-edilebilirligini-nasil-adim-adim-yukseltirsin\/'>Inbox or spam? A step-by-step guide to SPF, DKIM, DMARC and rDNS<\/a>.<\/p>\n<h3><span id=\"TTL_for_DKIM_and_DMARC_TXT_Records\">TTL for DKIM and DMARC TXT Records<\/span><\/h3>\n<p>DKIM records (usually under selectors like <code>selector._domainkey.example.com<\/code>) and DMARC (e.g., <code>_dmarc.example.com<\/code>) change much less frequently than SPF.<\/p>\n<ul>\n<li><strong>DKIM TXT TTL:<\/strong> 3600\u201314400 seconds (1\u20134 hours)<\/li>\n<li><strong>DMARC TXT TTL:<\/strong> 7200\u201328800 seconds (2\u20138 hours)<\/li>\n<\/ul>\n<p>We still recommend temporarily lowering DMARC TTL if you are changing policy from <code>p=none<\/code> to <code>p=quarantine<\/code> or <code>p=reject<\/code>, just to make rollback easier if you discover misconfigured senders via reports.<\/p>\n<h3><span id=\"Other_TXT_Records_Verification_and_Service_Config\">Other TXT Records: Verification and Service Config<\/span><\/h3>\n<p>Many third-party services ask you to add a TXT record to verify domain ownership (for example, analytics tools, SaaS apps, or email marketing platforms). Once verification is complete, the record often becomes irrelevant, but some providers periodically re-check it.<\/p>\n<ul>\n<li><strong>Default TTL for such TXT records:<\/strong> 3600 seconds (1 hour) is usually fine.<\/li>\n<li>If the verification is time-sensitive, you can temporarily set 300 seconds, then increase once done.<\/li>\n<\/ul>\n<p>Keep your zone tidy: periodically review and remove expired verification TXT records you no longer need.<\/p>\n<h2><span id=\"CNAME_Records_Flexibility_With_Careful_TTLs\">CNAME Records: Flexibility With Careful TTLs<\/span><\/h2>\n<p><strong>CNAME records<\/strong> alias one hostname to another. They are heavily used for CDNs, third-party services, subdomains pointing to external platforms and internal abstractions between services.<\/p>\n<h3><span id=\"Default_TTL_Ranges_for_CNAMEs\">Default TTL Ranges for CNAMEs<\/span><\/h3>\n<p>Because CNAME chains introduce additional lookups, TTL for CNAMEs should be chosen with both performance and flexibility in mind:<\/p>\n<ul>\n<li><strong>Subdomains pointing to external services (CDNs, SaaS, etc.):<\/strong> 600\u20133600 seconds (10\u201360 minutes)<\/li>\n<li><strong>Internal abstraction CNAMEs (inside your own infrastructure):<\/strong> 900\u20133600 seconds<\/li>\n<li><strong>Frequently changing dev or staging aliases:<\/strong> 300\u2013600 seconds<\/li>\n<\/ul>\n<p>For external providers that may change their target IPs regularly behind a fixed hostname, you usually only control the CNAME pointing to them. Keeping this TTL in the 600\u20131800 range offers a practical balance: changes on your side propagate fast, while their internal A\/AAAA records usually have their own TTLs managed by the provider.<\/p>\n<h3><span id=\"CNAME_at_the_Apex_and_ALIASANAME\">CNAME at the Apex and ALIAS\/ANAME<\/span><\/h3>\n<p>You cannot normally create a CNAME at the zone apex (for example, using <code>example.com<\/code> as a pure CNAME) because it conflicts with other mandatory records like SOA and NS. Many modern DNS providers emulate this via <strong>ALIAS<\/strong>, <strong>ANAME<\/strong> or <strong>CNAME flattening<\/strong>, resolving the target for you and returning an A\/AAAA to clients.<\/p>\n<p>TTL strategy in that case:<\/p>\n<ul>\n<li><strong>Set ALIAS\/ANAME TTL around 300\u2013900 seconds<\/strong> if you expect frequent changes or want quick CDN switches.<\/li>\n<li>Use <strong>higher TTL<\/strong> for NS and SOA records; they are independent of the ALIAS behavior.<\/li>\n<\/ul>\n<p>For a deeper dive into apex CNAME issues and modern workarounds, we have a separate article on this exact topic: <a href='https:\/\/www.dchost.com\/blog\/en\/bir-domain-bir-kahve-ve-kokte-cname-dilegi\/'>CNAME at the apex? A friendly guide to ALIAS\/ANAME and CNAME flattening<\/a>.<\/p>\n<h2><span id=\"Designing_a_DNS_TTL_Policy_That_Actually_Works\">Designing a DNS TTL Policy That Actually Works<\/span><\/h2>\n<p>Instead of manually picking TTLs for each record every time, it is much easier to define a <strong>simple, written TTL policy<\/strong> and stick to it. This also helps agencies and teams who manage dozens of zones stay consistent.<\/p>\n<h3><span id=\"A_Simple_Baseline_Policy_by_Record_Type\">A Simple Baseline Policy by Record Type<\/span><\/h3>\n<p>Here is a starting template you can adapt to your environment:<\/p>\n<ul>\n<li><strong>A\/AAAA (web, API, admin):<\/strong> 1800\u20133600 seconds by default; 300\u2013600 during migrations or active experiments.<\/li>\n<li><strong>MX:<\/strong> 3600\u201314400 seconds; 600\u20131800 during email provider changes.<\/li>\n<li><strong>TXT (SPF):<\/strong> 3600\u20137200 seconds stable; 300\u2013900 while tuning.<\/li>\n<li><strong>TXT (DKIM):<\/strong> 3600\u201314400 seconds.<\/li>\n<li><strong>TXT (DMARC):<\/strong> 7200\u201328800 seconds; temporarily lower if drastically changing policy.<\/li>\n<li><strong>CNAME (external services \/ CDN):<\/strong> 600\u20131800 seconds.<\/li>\n<li><strong>NS \/ SOA:<\/strong> set according to registrar\/provider defaults (often 86400) unless you have advanced reasons to change.<\/li>\n<\/ul>\n<p>Document this in your internal wiki, or even in a comment field in your DNS management tool. The key is that everyone on the team knows what \u2018normal\u2019 looks like and when it is acceptable to deviate.<\/p>\n<h3><span id=\"TTL_Change_Management_A_Mini_Runbook\">TTL Change Management: A Mini Runbook<\/span><\/h3>\n<p>When planning any significant change \u2013 moving hosting, changing MX, swapping CDNs \u2013 treat TTL as part of your change process, not an afterthought.<\/p>\n<ol>\n<li><strong>Identify affected records<\/strong> \u2013 A\/AAAA, MX, CNAME, TXT, sometimes SRV.<\/li>\n<li><strong>Lower TTL to a temporary value<\/strong> \u2013 usually 300\u2013900 seconds.<\/li>\n<li><strong>Wait at least the previous TTL duration<\/strong> \u2013 so old caches expire.<\/li>\n<li><strong>Apply the main change<\/strong> \u2013 IP, hostnames, priorities, policies.<\/li>\n<li><strong>Monitor<\/strong> \u2013 logs, error rates, bounce messages, uptime checks.<\/li>\n<li><strong>Raise TTL back to baseline<\/strong> \u2013 once things are stable.<\/li>\n<\/ol>\n<p>This simple runbook eliminates 90% of the \u2018DNS propagation is taking forever\u2019 headaches. For more structured migration ideas beyond TTL alone, see our checklist on <a href='https:\/\/www.dchost.com\/blog\/en\/hosting-firmasi-degistirirken-dns-ve-domain-tasima-kontrol-listesi\/'>domain and DNS migration when changing hosting provider<\/a>.<\/p>\n<h3><span id=\"Monitoring_and_Troubleshooting_TTL-Related_Issues\">Monitoring and Troubleshooting TTL-Related Issues<\/span><\/h3>\n<p>TTL problems usually show up as inconsistent behavior: some users see the old site, others see the new one; some can send email, others get bounces. To diagnose:<\/p>\n<ul>\n<li><strong>Query different public resolvers<\/strong> (for example, your ISP DNS and one or two well-known public resolvers) and compare answers and reported TTLs.<\/li>\n<li><strong>Use <code>dig<\/code> or <code>nslookup<\/code> with <code>+trace<\/code><\/strong> to follow delegation and confirm authoritative answers.<\/li>\n<li><strong>Check for typos or missing records<\/strong> \u2013 NXDOMAIN or SERVFAIL often show up when a record was removed too early.<\/li>\n<\/ul>\n<p>If your website is suddenly not resolving at all, tools and steps in our guide <a href='https:\/\/www.dchost.com\/blog\/en\/dns-hatalari-yuzunden-site-acilmiyor-dns_probe_finished_nxdomain-teshis-rehberi\/'>fix DNS_PROBE_FINISHED_NXDOMAIN and common DNS errors<\/a> are very helpful.<\/p>\n<h2><span id=\"How_dchostcom_Fits_Into_Your_DNS_and_TTL_Strategy\">How dchost.com Fits Into Your DNS and TTL Strategy<\/span><\/h2>\n<p>Whether you host a small business site on shared hosting, or run complex stacks on VPS, dedicated servers or colocation, TTL management matters just as much as CPU and RAM sizing. At dchost.com we see the full picture every day: <a href=\"https:\/\/www.dchost.com\/domain\/register\">domain registration<\/a>, DNS zones, <a href=\"https:\/\/www.dchost.com\/web-hosting\">web hosting<\/a>, email delivery and server infrastructure all meeting in one place.<\/p>\n<p>In practice this means:<\/p>\n<ul>\n<li><strong>During migrations to our VPS or dedicated servers<\/strong>, we help customers plan A\/AAAA and MX TTL adjustments so that cutovers finish smoothly and quickly.<\/li>\n<li><strong>For agencies managing many clients<\/strong>, a well-documented TTL policy reduces support noise and surprises when sites or email platforms change.<\/li>\n<li><strong>For growing projects<\/strong>, we can design DNS and hosting architectures \u2013 including GeoDNS, failover and regional setups \u2013 where TTL values are part of the reliability story, not an afterthought.<\/li>\n<\/ul>\n<p>The DNS layer often feels abstract compared to a control panel or SSH session, but small decisions there can make the difference between a calm upgrade and a stressful evening chasing \u2018propagation issues\u2019.<\/p>\n<h2><span id=\"Conclusion_Turn_TTL_From_a_Guess_Into_a_Policy\">Conclusion: Turn TTL From a Guess Into a Policy<\/span><\/h2>\n<p>TTL is one of those parameters that looks innocent until you try to move a site, change email providers or roll out a new SPF policy in production. High TTLs can lock you into bad decisions for a whole day; ultra-low TTLs can make your entire infrastructure more fragile and noisy than it needs to be. The sweet spot is a clear, written TTL policy that treats A, MX, CNAME and TXT records differently based on how often they change and how sensitive they are.<\/p>\n<p>If you take just a few actions after reading this, make them these: define baseline TTL ranges per record type, practice a simple \u2018lower \u2192 change \u2192 monitor \u2192 raise\u2019 runbook for migrations, and review your existing zones for obviously wrong extremes. Combine that with the detailed techniques in our <a href='https:\/\/www.dchost.com\/blog\/en\/zero-downtime-tasima-icin-ttl-stratejileri-dns-yayilimini-gercekten-nasil-hizlandirirsin\/'>TTL strategy guide for zero-downtime migrations<\/a> and our articles on DNS and email reliability, and you will be far ahead of most setups we audit. When you are ready to pair solid DNS hygiene with fast, reliable hosting, our team at dchost.com is here to help you plan the full stack \u2013 from domain and DNS to hosting, VPS, dedicated servers and colocation.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>DNS TTL looks like a tiny detail in your zone file, but it quietly decides how fast changes take effect, how resilient your services are to DNS outages, and even how predictable your migrations will be. At dchost.com we constantly see two extremes: zones where everything is stuck at 86400 seconds \u2018because that\u2019s the default\u2019, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4029,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4028","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-teknoloji"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4028","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=4028"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4028\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4029"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4028"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4028"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4028"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}