Elena' s AI Blog

DNS Made Easy

30 Sep 2026 (updated: 16 Sep 2026) / 11 minutes to read

Elena Daehnhardt

 Generated by Midjourney. Prompt: Abstract cloud computing architecture illustration.


TL;DR:
  • Reliable DNS for web and mail depends on correct record design, propagation checks, and authentication policy maintenance.

📚 This post is part of the "MLOps & Deployment" series

Series: MLOps & Deployment (Part 9 of 7)

Previous: Part 8 — Configuring DNS for Email

Introduction

Every time I have broken a website, it has been DNS. Usually a typo in an A record, occasionally an MX record I “cleaned up” without checking what depended on it first. DNS (Domain Name System) translates the human-readable name you type into the numeric address a computer actually needs, and it looks simple right up until the moment you misconfigure it and nothing works for the next 24 hours while the old record slowly expires out of caches everywhere.

This guide covers the DNS record types you will actually touch when running a website and its email - A, CNAME, MX, TXT, and SPF - plus how to check a change actually did what you wanted before you find out the hard way. For the deeper end of email authentication, DKIM and DMARC, see my companion post on configuring DNS for email, which covers that ground specifically.

Understanding DNS

What is DNS?

DNS is a decentralized system that resolves domain names to IP addresses, enabling users to access websites using human-friendly names instead of numerical IP addresses.

How DNS Works

DNS operates through a hierarchical structure of servers, including authoritative name servers, recursive resolvers, and root servers. Understanding this structure is crucial for managing DNS effectively.

DNS Records for Websites

A Record

The A record (Address Record) maps a domain to an IPv4 address. It is essential for pointing your domain to the correct web server.

CNAME Record

The CNAME record (Canonical Name) allows you to alias one domain to another. This is useful for creating subdomains or redirecting traffic.

MX Record

MX records (Mail Exchange) specify mail servers responsible for receiving email on behalf of your domain.

TXT Record

TXT records are used to store text information associated with the domain. They are commonly used for verification and authentication purposes.

SPF Record

The Sender Policy Framework (SPF) record helps prevent email spoofing by listing the mail servers authorised to send email for a domain.

SPF grew out of a collaborative effort within the internet community, with Meng Weng Wong - a technology entrepreneur and co-founder of the pobox.com email service - a key figure behind the original 2003 proposal.

SPF was first formalised in RFC 4408 (2006), which is now obsolete: RFC 7208 (2014) is the current specification. One detail worth knowing if you read older guides: RFC 4408 allowed publishing SPF as either a TXT record or a dedicated SPF DNS record type. RFC 7208 dropped the dedicated record type entirely - SPF must be published as a TXT record, full stop. Any tutorial or DNS provider UI that still offers you a separate “SPF record type” as distinct from TXT is describing a mechanism that no longer exists in the spec, even if some panels still leave the option in the dropdown for legacy reasons.

Email Setup

Setting up Email Hosting

The choice of an email hosting provider depends on various factors such as your specific needs, budget, security requirements, and the features offered by each provider.

Selecting a reliable email hosting provider is crucial. Here are some well-known email hosting providers:

  1. Google Workspace (formerly G Suite):
    • Google Workspace now bundles Gemini for Workspace (Google rebranded Duet AI to Gemini in February 2024, so if you see “Duet AI” mentioned anywhere, it is the old name for the same thing)
  2. Microsoft 365 (formerly Office 365):
  3. Zoho Mail:
  4. Yahoo Mail for Business:
  5. ProtonMail:
  6. Bluehost:
  7. Rackspace Email:
  8. FastMail:
  9. HostGator Email Hosting:
    • Website: HostGator (email hosting is bundled with their domain/hosting plans)
  10. Mailchimp (for marketing emails):

Before making a decision, it’s advisable to check the latest reviews and updates on these services to ensure they align with your current requirements.

Configuring MX Records

Configuring MX records correctly is essential for directing emails to the right mail servers. Learn how to update MX records for your domain.

Here are examples of MX records:

| Priority | Mail Server         |
|----------|---------------------|
| 10       | mail.example.com    |
| 20       | backup-mail.example.com |
| 30       | another-mail-server.example.com |

In this example, replace “mail.example.com,” “backup-mail.example.com,” and “another-mail-server.example.com” with the actual mail servers you want to use.

The “Priority” column represents the priority of each mail server, with lower numbers indicating higher priority. MX records with lower priority values are attempted first.

SPF Record for Email

Enhance email security by setting up SPF records, specifying which servers are authorized to send emails on behalf of your domain.

Here are SPF record examples for email - published as TXT records, per the note above, not as a separate “SPF” record type:

| Record Type | Name | Value                                                  |
|-------------|------|---------------------------------------------------------|
| TXT         | @    | "v=spf1 mx include:_spf.example.com ~all"                |
| TXT         | @    | "v=spf1 ip4:192.168.1.1 include:otherdomain.com -all"    |

Both examples above live at the root (@) of the domain doing the sending - an SPF record only means something for the exact domain in the message’s MAIL FROM (or From, depending on alignment), so putting one on a made-up subdomain like _spf.yourdomain.com does nothing. If you need to authorise a different sending domain (a third-party mailer, for instance), that domain publishes its own SPF record, and you reference it with include: as in the first example. You can only have one SPF TXT record per domain - if you need to combine sources, merge them into a single record rather than publishing two.

The “Name” column indicates the domain or subdomain for which the record is specified, and the “Value” column contains the SPF string itself. Adjust it based on your specific needs and authorised mail servers.

DNS Record Examples

Record Type Name Value
A @ 192.168.1.1
CNAME www example.com
MX @ mail.example.com
TXT @ “v=spf1 include:_spf.example.com ~all”

Validating Changes and Recovering from Mistakes

DNS changes do not take effect the moment you save them. Every record has a TTL (time to live), and resolvers around the world keep serving the old answer from cache until it expires - which is exactly why “I fixed it, why is it still broken” is the most common DNS support question there is.

Before you assume a change failed, check what is actually being served:

dig example.com A +short
dig example.com MX +short
dig example.com TXT +short

dig queries DNS directly and shows you the live answer, bypassing your own machine’s resolver cache. If you want to see how a change is propagating globally rather than just from your own network, a tool like whatsmydns.net checks the record from resolvers in multiple regions at once.

The mistake I see most often - and have made myself - is lowering a TTL only after you need the fast propagation, rather than before. If you know a cutover is coming (switching mail providers, moving hosts), drop the TTL to a few minutes a day or two ahead of time, make the change, confirm it with dig, then raise the TTL back once it has settled. Also keep a written record of your previous values before you touch anything; the fastest way to “recover” from a bad DNS edit is pasting the old value straight back in, and you cannot do that from memory under pressure.

Conclusion

DNS is not complicated in the way that, say, distributed consensus is complicated. It is complicated the way a spreadsheet with hidden dependencies is complicated: a handful of record types, each one simple on its own, and a lot of quiet ways for them to interact badly. A, CNAME, and MX get your site and your mail pointed at the right servers. TXT and SPF start you on proving you are who you say you are, which matters more every year as spam filters get less forgiving.

Change one thing at a time, check it with dig before you move on, and keep the old values written down somewhere you can find them at 2am. That is most of what I know about DNS, learned the slow way so you do not have to.

If you are setting up SPF, DKIM, and DMARC together for email deliverability specifically, I go into that in more depth in Configuring DNS for Email.

Did you like this post? Please let me know if you have any comments or suggestions.

AI-generated art and music/sound posts that might be interesting for you




References

  1. RFC 1035 - Domain Names - Implementation and Specification
  2. MX Record lookup (MXToolbox)
  3. SPF - Sender Policy Framework
  4. RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1

DNS Operations Checklist

  1. Keep authoritative records documented and versioned.
  2. Validate record propagation before cutovers.
  3. Separate web and mail change windows.
  4. Audit SPF/DKIM/DMARC after provider updates.
  5. Monitor DNS resolution failures continuously.
desktop bg dark

About Elena

Elena, a PhD in Computer Science, simplifies AI concepts and helps you use machine learning.

Citation
Elena Daehnhardt. (2026) 'DNS Made Easy', daehnhardt.com, 30 September 2026. Available at: https://daehnhardt.com/blog/2026/09/30/dns-setup/
All Posts
Copyright © Elena Daehnhardt
Privacy and Terms