{"id":4953,"date":"2026-02-11T14:41:09","date_gmt":"2026-02-11T11:41:09","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/dns-record-types-explained-practical-guide-to-a-aaaa-mx-cname-txt-srv-and-caa\/"},"modified":"2026-02-11T14:41:09","modified_gmt":"2026-02-11T11:41:09","slug":"dns-record-types-explained-practical-guide-to-a-aaaa-mx-cname-txt-srv-and-caa","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/dns-record-types-explained-practical-guide-to-a-aaaa-mx-cname-txt-srv-and-caa\/","title":{"rendered":"DNS Record Types Explained: Practical Guide to A, AAAA, MX, CNAME, TXT, SRV and CAA"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><p>When you change hosting, launch a new site or move email to a new provider, almost everything comes down to one thing: getting your DNS records right. A single typo in an A record or MX record can make your website disappear or bounce every email your customers send. The good news is that once you understand what A, AAAA, MX, CNAME, TXT, SRV and CAA records actually do, DNS stops feeling like black magic and becomes a predictable, repeatable part of your workflow.<\/p>\n<p>In this guide, we\u2019ll walk through each of these DNS record types with practical, real\u2011world examples from the kinds of setups we see every day at dchost.com: small business websites, online stores, SaaS projects and agency stacks. You\u2019ll see how the records fit together, what can safely be changed, and which mistakes you really want to avoid. By the end, you\u2019ll be able to read any DNS zone and say, \u201cI know what every one of these records is doing \u2013 and I know how to fix it if something breaks.\u201d<\/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=\"#Why_DNS_Records_Matter_for_Your_Website_and_Email\"><span class=\"toc_number toc_depth_1\">1<\/span> Why DNS Records Matter for Your Website and Email<\/a><\/li><li><a href=\"#Core_DNS_Concepts_Before_You_Edit_Anything\"><span class=\"toc_number toc_depth_1\">2<\/span> Core DNS Concepts Before You Edit Anything<\/a><ul><li><a href=\"#Zone_vs_Record\"><span class=\"toc_number toc_depth_2\">2.1<\/span> Zone vs. Record<\/a><\/li><li><a href=\"#Root_vs_Subdomain\"><span class=\"toc_number toc_depth_2\">2.2<\/span> Root (@) vs. Subdomain<\/a><\/li><li><a href=\"#TTL_Time_To_Live\"><span class=\"toc_number toc_depth_2\">2.3<\/span> TTL (Time To Live)<\/a><\/li><li><a href=\"#Propagation_and_Caching\"><span class=\"toc_number toc_depth_2\">2.4<\/span> Propagation and Caching<\/a><\/li><\/ul><\/li><li><a href=\"#A_and_AAAA_Records_Pointing_Your_Domain_to_a_Server\"><span class=\"toc_number toc_depth_1\">3<\/span> A and AAAA Records: Pointing Your Domain to a Server<\/a><ul><li><a href=\"#Typical_AAAAA_Record_Examples\"><span class=\"toc_number toc_depth_2\">3.1<\/span> Typical A\/AAAA Record Examples<\/a><\/li><li><a href=\"#DualStack_Using_A_and_AAAA_Together\"><span class=\"toc_number toc_depth_2\">3.2<\/span> Dual\u2011Stack: Using A and AAAA Together<\/a><\/li><li><a href=\"#Common_AAAAA_Mistakes\"><span class=\"toc_number toc_depth_2\">3.3<\/span> Common A\/AAAA Mistakes<\/a><\/li><\/ul><\/li><li><a href=\"#MX_Records_Making_Email_Deliver_to_the_Right_Server\"><span class=\"toc_number toc_depth_1\">4<\/span> MX Records: Making Email Deliver to the Right Server<\/a><ul><li><a href=\"#How_MX_Records_Work\"><span class=\"toc_number toc_depth_2\">4.1<\/span> How MX Records Work<\/a><\/li><li><a href=\"#Multiple_MX_Records_for_Redundancy\"><span class=\"toc_number toc_depth_2\">4.2<\/span> Multiple MX Records for Redundancy<\/a><\/li><li><a href=\"#MX_Record_Pitfalls\"><span class=\"toc_number toc_depth_2\">4.3<\/span> MX Record Pitfalls<\/a><\/li><\/ul><\/li><li><a href=\"#CNAME_Records_Creating_Aliases_for_Hostnames\"><span class=\"toc_number toc_depth_1\">5<\/span> CNAME Records: Creating Aliases for Hostnames<\/a><ul><li><a href=\"#Typical_CNAME_Uses\"><span class=\"toc_number toc_depth_2\">5.1<\/span> Typical CNAME Uses<\/a><\/li><li><a href=\"#Rules_and_Limitations_of_CNAME\"><span class=\"toc_number toc_depth_2\">5.2<\/span> Rules and Limitations of CNAME<\/a><\/li><li><a href=\"#Security_Note_Orphaned_CNAMEs_and_Subdomain_Takeover\"><span class=\"toc_number toc_depth_2\">5.3<\/span> Security Note: Orphaned CNAMEs and Subdomain Takeover<\/a><\/li><\/ul><\/li><li><a href=\"#TXT_Records_Verification_SPF_DKIM_DMARC_and_More\"><span class=\"toc_number toc_depth_1\">6<\/span> TXT Records: Verification, SPF, DKIM, DMARC and More<\/a><ul><li><a href=\"#Common_TXT_Record_Uses\"><span class=\"toc_number toc_depth_2\">6.1<\/span> Common TXT Record Uses<\/a><\/li><li><a href=\"#TXT_Record_Best_Practices\"><span class=\"toc_number toc_depth_2\">6.2<\/span> TXT Record Best Practices<\/a><\/li><\/ul><\/li><li><a href=\"#SRV_Records_Directing_Services_to_the_Right_Port\"><span class=\"toc_number toc_depth_1\">7<\/span> SRV Records: Directing Services to the Right Port<\/a><ul><li><a href=\"#SRV_Record_Structure\"><span class=\"toc_number toc_depth_2\">7.1<\/span> SRV Record Structure<\/a><\/li><li><a href=\"#Example_SRV_Use_Cases\"><span class=\"toc_number toc_depth_2\">7.2<\/span> Example SRV Use Cases<\/a><\/li><\/ul><\/li><li><a href=\"#CAA_Records_Controlling_Which_CAs_Can_Issue_SSL_Certificates\"><span class=\"toc_number toc_depth_1\">8<\/span> CAA Records: Controlling Which CAs Can Issue SSL Certificates<\/a><ul><li><a href=\"#Why_CAA_Records_Matter\"><span class=\"toc_number toc_depth_2\">8.1<\/span> Why CAA Records Matter<\/a><\/li><li><a href=\"#Simple_CAA_Examples\"><span class=\"toc_number toc_depth_2\">8.2<\/span> Simple CAA Examples<\/a><\/li><\/ul><\/li><li><a href=\"#Putting_It_All_Together_Example_DNS_Setups\"><span class=\"toc_number toc_depth_1\">9<\/span> Putting It All Together: Example DNS Setups<\/a><ul><li><a href=\"#Scenario_1_Simple_Business_Website_with_Hosted_Email\"><span class=\"toc_number toc_depth_2\">9.1<\/span> Scenario 1: Simple Business Website with Hosted Email<\/a><\/li><li><a href=\"#Scenario_2_SaaS_App_with_Multiple_Subdomains\"><span class=\"toc_number toc_depth_2\">9.2<\/span> Scenario 2: SaaS App with Multiple Subdomains<\/a><\/li><\/ul><\/li><li><a href=\"#Practical_Workflow_for_Editing_DNS_Safely\"><span class=\"toc_number toc_depth_1\">10<\/span> Practical Workflow for Editing DNS Safely<\/a><ul><li><a href=\"#1_Take_an_Inventory_Before_You_Touch_Anything\"><span class=\"toc_number toc_depth_2\">10.1<\/span> 1. Take an Inventory Before You Touch Anything<\/a><\/li><li><a href=\"#2_Lower_TTLs_Before_Big_Changes\"><span class=\"toc_number toc_depth_2\">10.2<\/span> 2. Lower TTLs Before Big Changes<\/a><\/li><li><a href=\"#3_Change_One_Record_Group_at_a_Time\"><span class=\"toc_number toc_depth_2\">10.3<\/span> 3. Change One Record Group at a Time<\/a><\/li><li><a href=\"#4_Test_from_Multiple_Networks\"><span class=\"toc_number toc_depth_2\">10.4<\/span> 4. Test from Multiple Networks<\/a><\/li><li><a href=\"#5_Clean_Up_Old_and_Unused_Records\"><span class=\"toc_number toc_depth_2\">10.5<\/span> 5. Clean Up Old and Unused Records<\/a><\/li><\/ul><\/li><li><a href=\"#Summary_and_Next_Steps_with_Your_DNS\"><span class=\"toc_number toc_depth_1\">11<\/span> Summary and Next Steps with Your DNS<\/a><\/li><\/ul><\/div>\n<h2><span id=\"Why_DNS_Records_Matter_for_Your_Website_and_Email\">Why DNS Records Matter for Your Website and Email<\/span><\/h2>\n<p>DNS (Domain Name System) is the address book of the internet. Every time someone visits your domain or sends you an email, their device asks DNS questions like \u201cWhat IP address is example.com?\u201d or \u201cWhich mail server handles email for this domain?\u201d The answers come from the DNS records you (or your hosting team) configure.<\/p>\n<p>From a hosting perspective, DNS is the glue that connects four main pieces: your domain name, your web server, your email platform and your <a href=\"https:\/\/www.dchost.com\/ssl\">SSL certificate<\/a>s. If you\u2019re not fully clear on how those pieces fit together, it\u2019s worth reading our article <a href=\"https:\/\/www.dchost.com\/blog\/en\/web-hosting-nedir-domain-dns-sunucu-ve-ssl-nasil-birlikte-calisir\/\">about how domain, DNS, server and SSL work together in a typical hosting setup<\/a>. Once you see the big picture, individual DNS records make much more sense.<\/p>\n<p>In this article, we\u2019ll focus on the seven record types you\u2019ll touch most often when you run websites and email: A, AAAA, MX, CNAME, TXT, SRV and CAA. We\u2019ll also highlight how to change them safely and how to plan your DNS so migrations and rebuilds are much less stressful.<\/p>\n<h2><span id=\"Core_DNS_Concepts_Before_You_Edit_Anything\">Core DNS Concepts Before You Edit Anything<\/span><\/h2>\n<p>Before diving into individual record types, a few core DNS concepts will save you a lot of headaches.<\/p>\n<h3><span id=\"Zone_vs_Record\">Zone vs. Record<\/span><\/h3>\n<p>A <strong>DNS zone<\/strong> is the configuration for a domain (for example, <code>example.com<\/code>) stored on one DNS provider or nameserver set. Inside that zone live multiple <strong>records<\/strong> like A, MX, CNAME, TXT, etc. When you edit DNS in a hosting panel or registrar interface, you\u2019re editing records in that zone.<\/p>\n<h3><span id=\"Root_vs_Subdomain\">Root (@) vs. Subdomain<\/span><\/h3>\n<ul>\n<li><strong>@<\/strong> usually means \u201cthe root of the domain\u201d, e.g. <code>example.com<\/code>.<\/li>\n<li>Anything like <code>www<\/code>, <code>shop<\/code> or <code>api<\/code> is a <strong>subdomain<\/strong>, e.g. <code>www.example.com<\/code>, <code>shop.example.com<\/code>.<\/li>\n<\/ul>\n<p>Many DNS mistakes come from mixing up whether a record should be set on the root (@) or on a subdomain (like <code>www<\/code>).<\/p>\n<h3><span id=\"TTL_Time_To_Live\">TTL (Time To Live)<\/span><\/h3>\n<p>Every DNS record has a <strong>TTL<\/strong>, which tells other DNS resolvers how long they can cache the answer. A high TTL (e.g. 4 hours) means changes propagate more slowly but reduce DNS traffic. A low TTL (e.g. 5\u201315 minutes) means faster changes but more lookups.<\/p>\n<p>We recommend learning how to use TTL strategically \u2013 for example, lowering TTL before a migration and raising it afterwards. Our detailed guide <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-ttl-degerlerini-dogru-ayarlamak-a-mx-cname-ve-txt-kayitlari-icin-stratejik-rehber\/\">on DNS TTL best practices for A, MX, CNAME and TXT records<\/a> covers concrete values and scenarios.<\/p>\n<h3><span id=\"Propagation_and_Caching\">Propagation and Caching<\/span><\/h3>\n<p>When you change a DNS record, it doesn\u2019t update instantly everywhere. Resolvers that previously cached the old record may keep using it until its TTL expires. That\u2019s why you often hear \u201cDNS changes can take up to 24 hours\u201d. In practice, many changes are visible much sooner, but you must expect some overlap.<\/p>\n<p>If DNS propagation still feels fuzzy, you\u2019ll find it useful to read our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-yayilim-suresi-nedir-neden-24-saat-surer-ve-nasil-hizlandirilir\/\">what DNS propagation is, why it can take hours and how to speed it up using TTL<\/a>.<\/p>\n<h2><span id=\"A_and_AAAA_Records_Pointing_Your_Domain_to_a_Server\">A and AAAA Records: Pointing Your Domain to a Server<\/span><\/h2>\n<p><strong>A<\/strong> and <strong>AAAA<\/strong> records are the most fundamental DNS records for a website. They map a hostname (like <code>example.com<\/code> or <code>www.example.com<\/code>) to an IP address.<\/p>\n<ul>\n<li><strong>A record<\/strong>: points to an IPv4 address, e.g. <code>203.0.113.10<\/code>.<\/li>\n<li><strong>AAAA record<\/strong>: points to an IPv6 address, e.g. <code>2001:db8::1234<\/code>.<\/li>\n<\/ul>\n<h3><span id=\"Typical_AAAAA_Record_Examples\">Typical A\/AAAA Record Examples<\/span><\/h3>\n<ul>\n<li><code>@  A    203.0.113.10<\/code> \u2013 <code>example.com<\/code> opens the website on your server.<\/li>\n<li><code>www  A    203.0.113.10<\/code> \u2013 <code>www.example.com<\/code> goes to the same site.<\/li>\n<li><code>@  AAAA 2001:db8::1234<\/code> \u2013 dual\u2011stack: your root domain also works over IPv6.<\/li>\n<\/ul>\n<p>On shared hosting, your A record usually points to the IP of the hosting server. On a <a href=\"https:\/\/www.dchost.com\/vps\">VPS<\/a>, <a href=\"https:\/\/www.dchost.com\/dedicated-server\">dedicated server<\/a> or colocated server at dchost.com, it points directly to your own server\u2019s public IP.<\/p>\n<h3><span id=\"DualStack_Using_A_and_AAAA_Together\">Dual\u2011Stack: Using A and AAAA Together<\/span><\/h3>\n<p>Modern setups increasingly use both A (IPv4) and AAAA (IPv6) for the same hostname. Clients that support IPv6 will prefer it, others will fall back to IPv4. Dual\u2011stack improves reach and future\u2011proofs your domain, especially as IPv6 adoption keeps rising globally.<\/p>\n<p>If you\u2019re planning to add IPv6 to your infrastructure, our articles on <a href=\"https:\/\/www.dchost.com\/blog\/en\/ipv6-benimseme-oranlari-hizla-artiyor-agin-hazir-mi\/\">rising IPv6 adoption and its impact on hosting<\/a> and our <a href=\"https:\/\/www.dchost.com\/blog\/en\/vps-sunucunuzda-ipv6-kurulum-ve-yapilandirma-rehberi\/\">practical IPv6 setup guide for VPS servers<\/a> will help you design a clean dual\u2011stack DNS plan.<\/p>\n<h3><span id=\"Common_AAAAA_Mistakes\">Common A\/AAAA Mistakes<\/span><\/h3>\n<ul>\n<li><strong>Forgetting <code>www<\/code><\/strong>: You update <code>example.com<\/code> but leave <code>www.example.com<\/code> pointing to the old server, so some visitors hit the wrong site.<\/li>\n<li><strong>Wrong IP address<\/strong>: One digit off in an A record can point your domain at someone else\u2019s server (or a dead IP).<\/li>\n<li><strong>Mixing A and CNAME on the same name<\/strong>: Many DNS providers won\u2019t let you do this; even if they do, it leads to undefined behaviour. Pick one type per hostname.<\/li>\n<li><strong>Adding AAAA without testing IPv6<\/strong>: If your server\u2019s IPv6 isn\u2019t configured correctly (firewall, web server, reverse proxy), some users may see timeouts while IPv4 users are fine.<\/li>\n<\/ul>\n<h2><span id=\"MX_Records_Making_Email_Deliver_to_the_Right_Server\">MX Records: Making Email Deliver to the Right Server<\/span><\/h2>\n<p><strong>MX (Mail Exchanger)<\/strong> records tell the world which server(s) accept email for your domain. Whenever someone sends an email to <code>you@example.com<\/code>, their mail server looks up MX records for <code>example.com<\/code> and delivers the message according to the priorities you set.<\/p>\n<h3><span id=\"How_MX_Records_Work\">How MX Records Work<\/span><\/h3>\n<ul>\n<li>Each MX record has a <strong>priority<\/strong> (a number) and a <strong>target hostname<\/strong> (not an IP address).<\/li>\n<li>Lower numbers = higher priority. A server will try <code>priority 10<\/code> first, then <code>20<\/code>, then <code>30<\/code>, etc.<\/li>\n<\/ul>\n<p>Example basic MX setup:<\/p>\n<ul>\n<li><code>@  MX  10  mail.example.com.<\/code><\/li>\n<li><code>mail  A      203.0.113.20<\/code><\/li>\n<\/ul>\n<p>Here, email for <code>@example.com<\/code> goes to <code>mail.example.com<\/code>, which then resolves via an A record to your mail server IP.<\/p>\n<h3><span id=\"Multiple_MX_Records_for_Redundancy\">Multiple MX Records for Redundancy<\/span><\/h3>\n<p>For higher availability, you can add backup MX servers with higher priority values:<\/p>\n<ul>\n<li><code>@  MX  10  mail1.example.com.<\/code> (primary)<\/li>\n<li><code>@  MX  20  mail2.example.com.<\/code> (secondary)<\/li>\n<\/ul>\n<p>If <code>mail1<\/code> is down, senders will try <code>mail2<\/code>. This is especially valuable for larger organisations or when you self\u2011host email on a VPS or dedicated server.<\/p>\n<h3><span id=\"MX_Record_Pitfalls\">MX Record Pitfalls<\/span><\/h3>\n<ul>\n<li><strong>Pointing MX directly to an IP<\/strong>: MX targets must be hostnames with A\/AAAA records, not raw IPs.<\/li>\n<li><strong>Forgetting to update MX during migrations<\/strong>: You move mailboxes to a new platform but leave MX pointing to the old server, so users think &#8220;email is lost&#8221;.<\/li>\n<li><strong>No reverse DNS or SPF\/DKIM\/DMARC<\/strong>: Even if MX is correct, missing authentication records will hurt deliverability.<\/li>\n<\/ul>\n<p>If you\u2019re managing your own email (on shared hosting or a VPS), you\u2019ll want to combine correct MX records with email authentication. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/temel-spf-dkim-ve-dmarc-ayarlari-kucuk-isletmeler-icin-adim-adim-e-posta-dogrulama\/\">SPF, DKIM and DMARC basics for small businesses<\/a> explains how the TXT records for these standards work alongside MX.<\/p>\n<h2><span id=\"CNAME_Records_Creating_Aliases_for_Hostnames\">CNAME Records: Creating Aliases for Hostnames<\/span><\/h2>\n<p><strong>CNAME (Canonical Name)<\/strong> records let you create an alias: \u201cthis hostname is really that other hostname\u201d. DNS resolvers then follow the alias and resolve the target\u2019s A\/AAAA records.<\/p>\n<h3><span id=\"Typical_CNAME_Uses\">Typical CNAME Uses<\/span><\/h3>\n<ul>\n<li><strong>Pointing <code>www<\/code> to the root<\/strong>: <code>www.example.com<\/code> \u2192 <code>example.com<\/code>.<\/li>\n<li><strong>CDN or external service<\/strong>: <code>static.example.com<\/code> \u2192 <code>mycdn.example-cdn.net<\/code>.<\/li>\n<li><strong>Third\u2011party tools<\/strong>: <code>news.example.com<\/code> \u2192 <code>pages.email-provider.com<\/code>, <code>status.example.com<\/code> \u2192 <code>statuspage.vendor.net<\/code>.<\/li>\n<\/ul>\n<p>Example:<\/p>\n<ul>\n<li><code>www   CNAME  example.com.<\/code><\/li>\n<li><code>blog  CNAME  blogs.hosted-platform.net.<\/code><\/li>\n<\/ul>\n<h3><span id=\"Rules_and_Limitations_of_CNAME\">Rules and Limitations of CNAME<\/span><\/h3>\n<ul>\n<li><strong>No other records on the same name<\/strong>: If <code>www<\/code> has a CNAME, it can\u2019t also have A, AAAA, MX, TXT or SRV records.<\/li>\n<li><strong>Usually not at the root<\/strong>: Most DNS providers don\u2019t allow a CNAME at <code>@<\/code> (the zone apex), because the root often needs NS, SOA and other records.<\/li>\n<li><strong>CNAME is an alias, not a redirect<\/strong>: Browsers still show the original hostname in the URL bar. HTTP redirects (301\/302) are handled by your web server, not DNS.<\/li>\n<\/ul>\n<h3><span id=\"Security_Note_Orphaned_CNAMEs_and_Subdomain_Takeover\">Security Note: Orphaned CNAMEs and Subdomain Takeover<\/span><\/h3>\n<p>If you point a CNAME to a third\u2011party platform and later cancel that service without deleting the DNS record, an attacker may be able to register that target and hijack the subdomain \u2013 a \u201csubdomain takeover\u201d.<\/p>\n<p>If you use many external services, it\u2019s worth reading our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/subdomain-takeover-ve-bosta-kalan-dns-kayitlari-alan-adi-guvenligi-marka-ve-seo-riskleri\/\">subdomain takeover and orphaned DNS records and the hidden risks for your brand and SEO<\/a>. We also recommend periodic DNS audits, especially for agencies managing many client domains.<\/p>\n<h2><span id=\"TXT_Records_Verification_SPF_DKIM_DMARC_and_More\">TXT Records: Verification, SPF, DKIM, DMARC and More<\/span><\/h2>\n<p><strong>TXT records<\/strong> are free\u2011form text blobs attached to a hostname. Originally intended for \u201cany text\u201d, they\u2019ve become the standard home for all sorts of policies and verifications, especially for email and web services.<\/p>\n<h3><span id=\"Common_TXT_Record_Uses\">Common TXT Record Uses<\/span><\/h3>\n<ul>\n<li><strong>SPF<\/strong> (email sender policy): defines which servers are allowed to send email for your domain.<\/li>\n<li><strong>DKIM<\/strong> (email signatures): stores public keys used to verify that emails weren\u2019t tampered with.<\/li>\n<li><strong>DMARC<\/strong>: tells receivers how to treat messages that fail SPF\/DKIM and where to send reports.<\/li>\n<li><strong>Service verification<\/strong>: search engines, analytics tools and SaaS platforms often ask you to add a TXT record like <code>google-site-verification=...<\/code> or <code>service=12345abcd<\/code>.<\/li>\n<\/ul>\n<p>Example SPF record:<\/p>\n<ul>\n<li><code>@  TXT  \"v=spf1 a mx include:mail-provider.net -all\"<\/code><\/li>\n<\/ul>\n<p>Email providers read this to decide whether a given sending IP is authorised to send as <code>@example.com<\/code>.<\/p>\n<h3><span id=\"TXT_Record_Best_Practices\">TXT Record Best Practices<\/span><\/h3>\n<ul>\n<li><strong>Multiple TXT records are allowed<\/strong>: You can have separate TXT records for SPF, verification and other uses on the same hostname.<\/li>\n<li><strong>Watch SPF DNS lookup limits<\/strong>: Overly complex SPF records with many <code>include:<\/code> mechanisms can hit the 10\u2011lookup limit and break SPF entirely.<\/li>\n<li><strong>Keep a documentation file<\/strong>: For each TXT record, note which service requested it and when. This makes cleanup easier when you stop using a tool.<\/li>\n<\/ul>\n<p>For a step\u2011by\u2011step walkthrough of SPF, DKIM and DMARC and how they live inside your TXT records, see our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/spf-dkim-ve-dmarc-nedir-ozel-alan-adi-ile-e-posta-dogrulamasini-cpanel-ve-vpste-sifirdan-kurmak\/\">SPF, DKIM and DMARC for cPanel and VPS email<\/a> or, if you prefer a business\u2011level view, the article we mentioned earlier about email authentication for small businesses.<\/p>\n<h2><span id=\"SRV_Records_Directing_Services_to_the_Right_Port\">SRV Records: Directing Services to the Right Port<\/span><\/h2>\n<p><strong>SRV (Service)<\/strong> records are less common for basic sites, but essential in some application stacks. They answer the question: \u201cFor this service, on this domain, which host and port should I use?\u201d<\/p>\n<h3><span id=\"SRV_Record_Structure\">SRV Record Structure<\/span><\/h3>\n<p>An SRV record has this structure:<\/p>\n<pre>_service._proto.name.  TTL  priority  weight  port  target<\/pre>\n<ul>\n<li><strong>_service<\/strong>: the service name (e.g. <code>_sip<\/code>, <code>_xmpp<\/code>).<\/li>\n<li><strong>_proto<\/strong>: <code>_tcp<\/code> or <code>_udp<\/code>.<\/li>\n<li><strong>name<\/strong>: the domain name the record applies to (e.g. <code>example.com<\/code>).<\/li>\n<li><strong>priority<\/strong> and <strong>weight<\/strong>: similar to MX; used for load balancing and failover between multiple targets.<\/li>\n<li><strong>port<\/strong>: the TCP\/UDP port number (e.g. 5060 for SIP).<\/li>\n<li><strong>target<\/strong>: the hostname of the server providing the service; that hostname must have A\/AAAA records.<\/li>\n<\/ul>\n<h3><span id=\"Example_SRV_Use_Cases\">Example SRV Use Cases<\/span><\/h3>\n<ul>\n<li><strong>VoIP \/ SIP services<\/strong>: Clients discover the SIP server and port for a given domain.<\/li>\n<li><strong>Chat protocols (XMPP)<\/strong>: SRV points clients to the correct host and port for messaging servers.<\/li>\n<li><strong>Some Microsoft services<\/strong>: Autodiscover and other protocols rely on SRV for service discovery.<\/li>\n<\/ul>\n<p>A simplified SRV example for a SIP service might look like:<\/p>\n<ul>\n<li><code>_sip._tcp.example.com.  3600  10  60  5060  sip1.example.com.<\/code><\/li>\n<li><code>_sip._tcp.example.com.  3600  20  20  5060  sip2.example.com.<\/code><\/li>\n<\/ul>\n<p>Here, <code>sip1<\/code> is preferred, but <code>sip2<\/code> acts as backup or load\u2011sharing depending on your client configuration.<\/p>\n<h2><span id=\"CAA_Records_Controlling_Which_CAs_Can_Issue_SSL_Certificates\">CAA Records: Controlling Which CAs Can Issue SSL Certificates<\/span><\/h2>\n<p><strong>CAA (Certification Authority Authorization)<\/strong> records are a security control for your SSL\/TLS certificates. They tell certificate authorities (CAs) which providers are allowed to issue certificates for your domain.<\/p>\n<h3><span id=\"Why_CAA_Records_Matter\">Why CAA Records Matter<\/span><\/h3>\n<p>Without CAA, in theory any publicly trusted CA could issue a certificate for your domain (subject to normal validation). If an attacker tricks or compromises a CA, they could obtain a certificate you never asked for. A well\u2011designed CAA policy drastically reduces that risk by saying \u201conly these specific CAs may issue for this domain\u201d.<\/p>\n<h3><span id=\"Simple_CAA_Examples\">Simple CAA Examples<\/span><\/h3>\n<ul>\n<li><code>@  CAA  0 issue \"letsencrypt.org\"<\/code> \u2013 only Let\u2019s Encrypt can issue certificates for your domain.<\/li>\n<li><code>@  CAA  0 issue \"zerossl.com\"<\/code> \u2013 only ZeroSSL can issue.<\/li>\n<li><code>@  CAA  0 iodef \"mailto:security@example.com\"<\/code> \u2013 tell CAs where to report policy violations.<\/li>\n<\/ul>\n<p>Many organisations combine free CAs for routine certificates and commercial CAs for EV\/OV or specialised use. In that case, you list all allowed CAs with multiple CAA records.<\/p>\n<p>If you\u2019re running a corporate or B2B site where trust and compliance matter, CAA fits into a larger picture of TLS and brand assurance. We cover this in our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/b2b-kurumsal-siteler-icin-ssl-ve-guven-mimarisi\/\">SSL and trust architecture for B2B corporate websites, including HSTS preload and CAA<\/a>. For a deeper technical dive specifically on CAA syntax and multi\u2011CA strategies, see <a href=\"https:\/\/www.dchost.com\/blog\/en\/caa-kayitlari-derinlemesine-neden-nasil-ve-ne-zaman-coklu%e2%80%91caya-gecmelisin\/\">our in\u2011depth CAA records guide<\/a>.<\/p>\n<h2><span id=\"Putting_It_All_Together_Example_DNS_Setups\">Putting It All Together: Example DNS Setups<\/span><\/h2>\n<h3><span id=\"Scenario_1_Simple_Business_Website_with_Hosted_Email\">Scenario 1: Simple Business Website with Hosted Email<\/span><\/h3>\n<p>Let\u2019s say you host your website on a shared hosting or VPS plan at dchost.com and use a separate, specialised email service.<\/p>\n<ul>\n<li><strong>Website<\/strong>\n<ul>\n<li><code>@    A      203.0.113.50<\/code> (your dchost.com web server)<\/li>\n<li><code>www  CNAME  example.com.<\/code> (alias www \u2192 root)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Email<\/strong>\n<ul>\n<li><code>@   MX   10  mx1.mailservice.net.<\/code><\/li>\n<li><code>@   MX   20  mx2.mailservice.net.<\/code><\/li>\n<li><code>@   TXT  \"v=spf1 include:spf.mailservice.net -all\"<\/code><\/li>\n<li><code>_dmarc  TXT  \"v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com\"<\/code><\/li>\n<li><code>selector1._domainkey  TXT  \"v=DKIM1; k=rsa; p=...\"<\/code><\/li>\n<\/ul>\n<\/li>\n<li><strong>Verification &amp; SSL<\/strong>\n<ul>\n<li><code>@       CAA  0 issue \"letsencrypt.org\"<\/code><\/li>\n<li><code>@       TXT  \"google-site-verification=...\"<\/code> (if needed)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>Here, the web and email are cleanly separated: web traffic hits your hosting server, while email goes to the external mail provider. If you later move the website to a different dchost.com server, you only change the A record; email keeps working untouched.<\/p>\n<h3><span id=\"Scenario_2_SaaS_App_with_Multiple_Subdomains\">Scenario 2: SaaS App with Multiple Subdomains<\/span><\/h3>\n<p>Now imagine a SaaS app where you host your main marketing site on one server, the app on another, and a status page on a third\u2011party provider:<\/p>\n<ul>\n<li><strong>Main site<\/strong>\n<ul>\n<li><code>@     A      203.0.113.100<\/code><\/li>\n<li><code>www   CNAME  example.com.<\/code><\/li>\n<\/ul>\n<\/li>\n<li><strong>App<\/strong>\n<ul>\n<li><code>app   A      203.0.113.200<\/code> (separate VPS cluster)<\/li>\n<li><code>api   A      203.0.113.201<\/code> (API node)<\/li>\n<\/ul>\n<\/li>\n<li><strong>Status page<\/strong>\n<ul>\n<li><code>status  CNAME  status.vendor-status.com.<\/code><\/li>\n<\/ul>\n<\/li>\n<li><strong>Email &amp; security<\/strong>\n<ul>\n<li><code>@        MX   10  mx1.mailservice.net.<\/code><\/li>\n<li><code>@        TXT  \"v=spf1 include:spf.mailservice.net -all\"<\/code><\/li>\n<li><code>@        CAA  0 issue \"letsencrypt.org\"<\/code><\/li>\n<li><code>@        CAA  0 issue \"zerossl.com\"<\/code> (multi\u2011CA strategy for automation)<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p>This layout separates concerns clearly: each subdomain can be migrated or scaled independently. If you ever move <code>api<\/code> to a dedicated cluster or containerised setup, you only update its A\/AAAA records.<\/p>\n<h2><span id=\"Practical_Workflow_for_Editing_DNS_Safely\">Practical Workflow for Editing DNS Safely<\/span><\/h2>\n<p>Knowing what each record does is step one. Step two is having a safe process whenever you change DNS. Here\u2019s a workflow we use and recommend to our customers at dchost.com.<\/p>\n<h3><span id=\"1_Take_an_Inventory_Before_You_Touch_Anything\">1. Take an Inventory Before You Touch Anything<\/span><\/h3>\n<ul>\n<li>Export your current DNS zone if your provider allows it.<\/li>\n<li>Screenshot or copy all existing A, AAAA, MX, CNAME, TXT, SRV and CAA records into a document.<\/li>\n<li>Note which systems depend on which records (website, email, third\u2011party tools).<\/li>\n<\/ul>\n<p>This gives you a quick rollback path if something goes wrong.<\/p>\n<h3><span id=\"2_Lower_TTLs_Before_Big_Changes\">2. Lower TTLs Before Big Changes<\/span><\/h3>\n<p>Before moving a website or email service, lower the TTL on the relevant records (often to 300 seconds \/ 5 minutes) 24 hours ahead of time if possible. This ensures caches expire quickly when you make the cutover. Our article on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-ttl-degerlerini-dogru-ayarlamak-a-mx-cname-ve-txt-kayitlari-icin-stratejik-rehber\/\">DNS TTL strategy for zero\u2011downtime migrations<\/a> walks through this step in detail.<\/p>\n<h3><span id=\"3_Change_One_Record_Group_at_a_Time\">3. Change One Record Group at a Time<\/span><\/h3>\n<ul>\n<li>For a web migration, change A\/AAAA (and related CNAMEs) first.<\/li>\n<li>For an email migration, update MX, SPF (TXT), DKIM and DMARC together.<\/li>\n<li>For SSL changes, review CAA and any DNS\u201101 challenge TXT records.<\/li>\n<\/ul>\n<p>Avoid \u201cbig\u2011bang\u201d edits where you modify many unrelated records at once; troubleshooting becomes much harder.<\/p>\n<h3><span id=\"4_Test_from_Multiple_Networks\">4. Test from Multiple Networks<\/span><\/h3>\n<p>After changes, test:<\/p>\n<ul>\n<li>Using <code>dig<\/code> or <code>nslookup<\/code> against your authoritative nameservers.<\/li>\n<li>From your own connection and from a different network (mobile data, VPN).<\/li>\n<li>Using online DNS checkers to see what remote resolvers are seeing.<\/li>\n<\/ul>\n<p>This helps you distinguish between \u201cauthoritative DNS is wrong\u201d and \u201csome resolvers still have old cache\u201d. Our guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dns-yayilim-suresi-nedir-neden-24-saat-surer-ve-nasil-hizlandirilir\/\">DNS propagation and how to interpret mixed results<\/a> can be handy here.<\/p>\n<h3><span id=\"5_Clean_Up_Old_and_Unused_Records\">5. Clean Up Old and Unused Records<\/span><\/h3>\n<p>Over time, zones accumulate stale CNAMEs, TXT verifications for long\u2011gone services, old A records and forgotten SRV entries. These aren\u2019t just messy \u2013 they can become security risks (e.g. subdomain takeover) or cause confusion during incident response.<\/p>\n<ul>\n<li>Delete records for services you no longer use.<\/li>\n<li>Document what each remaining record does.<\/li>\n<li>Consider enabling DNSSEC on your domains to protect against tampering; our practical guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/dnssec-nedir-ne-ise-yarar-alan-adiniz-ve-hostinginiz-icin-adim-adim-dnssec-kurulum-rehberi\/\">what DNSSEC is and when you should enable it<\/a> explains the trade\u2011offs.<\/li>\n<\/ul>\n<h2><span id=\"Summary_and_Next_Steps_with_Your_DNS\">Summary and Next Steps with Your DNS<\/span><\/h2>\n<p>A handful of DNS record types do most of the heavy lifting for real\u2011world websites and email. A and AAAA connect your domain to your hosting servers. MX, SPF, DKIM and DMARC (in TXT records) keep email flowing and authenticated. CNAME makes it easy to integrate third\u2011party services and CDNs. SRV quietly directs specialised applications to the right host and port. CAA adds a final, important layer of control over who can issue SSL certificates for your domain.<\/p>\n<p>Once you understand how these records work together, DNS stops being something you fear breaking and becomes another tool you can design and reason about. Whether your sites run on shared hosting, managed WordPress, VPS, dedicated servers or colocated hardware with us at dchost.com, a clean DNS architecture will make every future migration, upgrade and security improvement easier.<\/p>\n<p>If you\u2019re planning a move to a new server, splitting web and email, or consolidating many client domains, now is a great moment to audit your DNS zones and fix old mistakes. And if you\u2019d like help mapping records to the right dchost.com hosting, VPS, dedicated or colocation setup, our team can review your current DNS, suggest safer TTL strategies and design a migration plan that keeps your website and email online while everything changes under the hood.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>When you change hosting, launch a new site or move email to a new provider, almost everything comes down to one thing: getting your DNS records right. A single typo in an A record or MX record can make your website disappear or bounce every email your customers send. The good news is that once [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":4954,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26],"tags":[],"class_list":["post-4953","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\/4953","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=4953"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/4953\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/4954"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=4953"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=4953"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=4953"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}