How to Set Up DNS Records: A, CNAME, MX and TXT Step-by-Step

Before you can add or edit DNS records, you need to find the DNS management panel at your registrar or DNS provider. The key question is: who is managing your DNS? If you have not changed your nameservers, your registrar handles DNS. If you pointed nameservers to Cloudflare or your hosting provider, you manage DNS there instead.

Namecheap:

1. Log in at namecheap.com.
2. Click "Domain List" in the left sidebar.
3. Find the domain you want to manage and click "Manage."
4. Click the "Advanced DNS" tab at the top of the page.
5. You are now in the DNS management panel. You will see a list of existing records (there may already be some default records) and buttons to add new ones.

Cloudflare:

1. Log in at dash.cloudflare.com.
2. Select the domain from your dashboard.
3. Click "DNS" in the left sidebar, then "Records."
4. You will see all current DNS records listed. Use the "Add record" button to create new ones.
5. Note: Cloudflare has a proxy toggle (orange cloud icon) on each record. When enabled, traffic goes through Cloudflare's CDN. For most web records (A and CNAME), leave the proxy on. For MX and TXT records, it is always off (you cannot proxy email).

GoDaddy:

1. Log in at godaddy.com.
2. Go to "My Products" and find your domain.
3. Click "DNS" next to the domain name (or click "Manage" and then navigate to the DNS tab).
4. You will see the DNS Management page with all current records.

Porkbun:

1. Log in at porkbun.com.
2. Go to "Domain Management."
3. Click the "DNS" link next to your domain.
4. Porkbun's interface is clean and straightforward — you will see existing records and a form to add new ones.

General tips before editing DNS:

• Take a screenshot of your current DNS records before making changes. If something breaks, you can restore the original configuration.
• Understand record fields. Every DNS record has at least these fields: Type (A, CNAME, MX, TXT, etc.), Host/Name (the subdomain or @ for root), Value/Points to (the IP address, hostname, or text value), and TTL (Time to Live, in seconds).
• The @ symbol means the root domain itself (e.g., mybakery.com). If you want to set a record for www.mybakery.com, the host would be www.
• Do not delete records you do not understand. Some records are essential for your site or email to function. If you are unsure what a record does, research it before removing it.

An A record (Address record) maps a domain name to an IPv4 address. This is the most fundamental DNS record — it tells browsers which server to contact when someone types your domain into the address bar.

When you need an A record:

• Pointing your root domain (mybakery.com) to a web server
• Pointing subdomains (shop.mybakery.com, blog.mybakery.com) to specific servers

How to set up an A record:

• Type: Select "A" from the dropdown.
• Host: Enter @ for the root domain, or a subdomain name (like blog for blog.mybakery.com).
• Value: Enter the IPv4 address of your server. This is provided by your hosting company.
• TTL: Leave at "Automatic" or the default (usually 1800 or 3600 seconds). Lower TTL means DNS changes propagate faster, but results in more DNS queries.

Common A record values by hosting provider:

For GitHub Pages, you need to add all four A records — they provide redundancy. Each record has the same Host (@) but a different IP address.

A record vs. CNAME record:

A CNAME (Canonical Name) record maps a domain to another domain name instead of an IP address. For example:

This tells DNS: "www.mybakery.com should resolve to whatever IP address mybakery.netlify.app resolves to."

Important rule: You cannot put a CNAME record on the root domain (@) if you have other records there (like MX records for email). This is a technical limitation of the DNS specification. Some providers (Cloudflare, for example) work around this with a feature called "CNAME flattening," but at most registrars, you must use an A record for the root domain.

Typical setup for a modern website:

This configuration points mybakery.com (root) directly to Vercel's IP, and points www.mybakery.com to Vercel via a CNAME. Most hosting providers will handle redirecting www to non-www (or vice versa) automatically.

AAAA records:

If your hosting provider gives you an IPv6 address (like 2606:4700:3030::6815:5678), you add it as an AAAA record instead of an A record. The setup is identical, just with "AAAA" as the type. Having both A and AAAA records is good practice — it ensures your site is accessible over both IPv4 and IPv6.

MX records (Mail Exchange records) tell the internet where to deliver email for your domain. Without MX records, nobody can send email to @yourdomain.com addresses.

How MX records work:

When someone sends an email to hello@mybakery.com, their email server looks up the MX records for mybakery.com to find out which mail server should receive the message. MX records have a priority value — the lower the number, the higher the priority. Email is delivered to the highest-priority server first, with lower-priority servers acting as backups.

Setting up Google Workspace MX records:

If you are using Google Workspace for email, add these exact MX records:

Important: Before adding Google's MX records, delete any existing MX records for the root domain. Having conflicting MX records will cause email delivery issues.

Setting up Microsoft 365 MX records:

Replace "mybakery-com" with your actual domain name, using hyphens instead of dots. Microsoft 365 admin center will show you the exact value during setup.

Setting up Zoho Mail MX records:

How to add MX records on Namecheap:

1. Go to Domain List > Manage > Advanced DNS.
2. In the Mail Settings section, select "Custom MX" from the dropdown (instead of "No Email" or "Email Forwarding").
3. Add each MX record with the correct hostname and priority.
4. Save changes.

On Cloudflare, simply go to DNS > Records, click "Add record," select MX, and fill in the fields. Cloudflare also has a handy "Email Routing" feature if you just want to forward email to an existing address without setting up a full email hosting service.

Testing your MX records:

After adding MX records, wait at least 15-30 minutes for propagation, then test:

1. Use MXToolbox (mxtoolbox.com) — enter your domain and click "MX Lookup" to see if your MX records are resolving correctly.
2. Send a test email from a different email account (like a personal Gmail) to an address at your domain.
3. Use mail-tester.com — send an email to the address shown on the site. It will analyze your email setup and give you a score out of 10, checking MX records, SPF, DKIM, and more. Aim for a 9 or 10.

TXT records store text information in your DNS. They are used for two main purposes: domain verification (proving you own the domain) and email authentication (preventing spam and spoofing).

Domain Verification

Many services ask you to verify domain ownership by adding a TXT record. Here are common examples:

Google Search Console verification:

Google gives you the exact value during setup. Copy and paste it precisely — even a missing character will cause verification to fail.

Microsoft 365 verification:

Facebook domain verification:

You can have multiple TXT records on the same host (@). They do not conflict with each other, unlike some other record types.

---

Email Authentication: SPF

SPF (Sender Policy Framework) tells receiving email servers which servers are authorized to send email on behalf of your domain. Without SPF, spammers can send emails pretending to be from your domain (spoofing), and your legitimate emails are more likely to land in spam.

SPF for Google Workspace:

SPF for Microsoft 365:

SPF if you use multiple senders (e.g., Google Workspace for email and Mailchimp for newsletters):

Important: You can only have one SPF record per domain. If you need to authorize multiple services, combine them into a single record using multiple `include:` statements, as shown above. Having two separate SPF TXT records will break email delivery.

---

Email Authentication: DKIM

DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails, allowing receiving servers to verify the email was actually sent by your domain and was not tampered with in transit.

DKIM setup varies by provider. Google Workspace, for example, generates a unique DKIM key in the Admin Console:

1. Go to Google Admin > Apps > Google Workspace > Gmail > Authenticate email.
2. Click "Generate new record."
3. Google will give you a TXT record to add:

1. Add this TXT record in your DNS, then go back to Google Admin and click "Start authentication."

---

Email Authentication: DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties SPF and DKIM together and tells receiving servers what to do when an email fails authentication — deliver it anyway, quarantine it (spam folder), or reject it entirely.

Basic DMARC record (recommended starting point):

• p=none means "do not take action on failing emails, just send me reports." Start with this to monitor before enforcing.
• p=quarantine means "send failing emails to spam."
• p=reject means "reject failing emails entirely." This is the strictest and most protective setting, but only enable it after you have confirmed all legitimate email sources pass SPF and DKIM.
• rua=mailto: specifies where aggregate DMARC reports should be sent. These reports show you who is sending email using your domain.

Recommended progression: 1. Start with `p=none` for 2-4 weeks while monitoring reports. 2. Move to `p=quarantine` once you are confident your legitimate emails pass. 3. Move to `p=reject` for maximum protection.

Services like Postmark DMARC (dmarc.postmarkapp.com) offer free weekly DMARC report digests that are much easier to read than the raw XML reports.

DNS issues can be frustrating because changes are not instant and error messages are often unhelpful. Here are the most common problems and how to solve them.

Problem: "DNS changes are not working"

Cause: DNS propagation takes time. When you change a record, the old value is cached by DNS servers around the world. Until the cache expires (based on TTL), some users will see the old value.

Solution: - Wait at least 30 minutes for most changes. Full global propagation can take up to 48 hours, though it rarely takes that long in practice. - Use dnschecker.org to see which regions have picked up the new records and which are still serving the old ones. - Clear your local DNS cache. On Windows, open Command Prompt and run `ipconfig /flushdns`. On macOS, run `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder`. - Try accessing your site in an incognito/private browser window or from a mobile device on cellular data (not Wi-Fi) to rule out local caching.

Problem: "CNAME record at the root domain is not working"

Cause: The DNS specification does not allow a CNAME record to coexist with other record types on the same host. Since the root domain (@) typically has MX records (for email), TXT records (for SPF, verification), and possibly other records, adding a CNAME at the root conflicts with all of them.

Solution: - Use an A record at the root domain instead of CNAME. Get the IP address from your hosting provider. - If your hosting provider only gives you a hostname (not an IP), switch your DNS to Cloudflare. Cloudflare supports CNAME flattening, which resolves the CNAME to an IP address automatically at the DNS level, avoiding the technical conflict. - Some registrars (like Namecheap) offer an ALIAS record that works similarly to CNAME flattening.

Problem: "Email is going to spam / not being delivered"

Cause: Missing or misconfigured SPF, DKIM, or DMARC records.

Solution: 1. Go to mail-tester.com, send an email to the provided address, and check your score. It will tell you exactly what is wrong. 2. Verify your SPF record exists and is correct (only one SPF record per domain). 3. Verify DKIM is set up and active in your email provider's admin console. 4. Add a DMARC record if you do not have one. 5. Make sure you do not have conflicting MX records — there should only be records for your current email provider, not leftover records from a previous provider.

Problem: "Website works on mybakery.com but not www.mybakery.com (or vice versa)"

Cause: Missing DNS record for one of the two versions.

Solution: You need records for both: - An A record with host @ pointing to your server IP (for mybakery.com) - A CNAME record with host www pointing to your hosting provider's hostname (for www.mybakery.com)

Also configure a redirect in your hosting provider so that one version redirects to the other. Most providers handle this automatically.

Problem: "I changed nameservers but my records disappeared"

Cause: When you change nameservers (e.g., from Namecheap to Cloudflare), DNS management moves to the new provider. Records you set up at Namecheap no longer apply because DNS queries are no longer going to Namecheap's servers.

Solution: Before changing nameservers, document all existing DNS records. After switching, recreate them at the new DNS provider. Cloudflare usually auto-imports existing records during setup, but always double-check that nothing was missed.

Problem: "My DNS record has the wrong value but I already updated it"

Cause: TTL caching. The old record is still cached.

Solution: This is a waiting game. The old record will expire based on the previous TTL value. If the old TTL was 86400 seconds (24 hours), it could take up to 24 hours for the change to propagate everywhere. This is why lowering TTL before making changes is important (covered in the next chapter).

TTL (Time to Live) is a value on every DNS record that tells DNS resolvers how long to cache the record before checking for updates. It is measured in seconds. A TTL of 3600 means "cache this record for 1 hour before asking for a fresh copy."

Why TTL matters when making changes:

If your A record has a TTL of 86400 (24 hours) and you change the IP address, DNS servers around the world will continue serving the old IP address for up to 24 hours because they cached it. During that time, some visitors will reach your old server and some will reach the new one.

The TTL lowering strategy:

Before making any significant DNS change (switching hosting providers, changing IP addresses, migrating email), follow this process:

Step 1: Lower the TTL (24-48 hours before the change)

Change the TTL on the records you plan to modify to a low value — 300 seconds (5 minutes) is a good choice.

For example, if your current A record is:

Change it to:

Do not change the IP address yet — only change the TTL. You need to wait for the old TTL to expire so that all DNS servers worldwide have the new, lower TTL. If the old TTL was 86400 (24 hours), wait 24 hours before proceeding.

Step 2: Make your DNS change

Now change the value (e.g., the IP address) while keeping the low TTL:

Because the TTL is now 300 seconds, the old cached value will expire within 5 minutes across most DNS servers. Your change propagates to the vast majority of users within minutes instead of hours.

Step 3: Raise the TTL back (24-48 hours after the change)

Once you have confirmed everything is working correctly with the new DNS values, raise the TTL back to a normal value:

A TTL of 3600 (1 hour) is a good general-purpose value. It balances performance (fewer DNS lookups) with flexibility (changes propagate within an hour). For records that rarely change, 86400 (24 hours) is fine and reduces DNS query load.

When to use low TTL permanently:

• During initial setup — Keep TTL low (300-600) while you are actively configuring and testing DNS. Raise it once everything is stable.
• Failover scenarios — If you have a backup server and might need to switch quickly, a low TTL ensures fast failover.
• Load-balanced or dynamic services — Some CDNs and load balancers require low TTLs to function properly.

Common TTL values and what they mean:

Note: Some DNS providers do not let you set an exact TTL and instead offer presets like "Automatic" (Cloudflare defaults to 300 seconds when proxied) or limited options like 1800 / 3600 / 86400. In those cases, choose the lowest available option before making changes.