DNS Records Explained: How to Configure, Test, and Troubleshoot Your Domain’s DNS

By Alaa

SMTPedia documents email infrastructure end to end: SMTP standards from the RFC archive, delivera...

18 min read Updated Aug 27, 2026 325 views Save

Introduction: Why DNS Is the Foundation of Email

Every email system you deploy, from simple mailbox hosting to complex cold‑outreach stacks, sits on top of DNS. DNS decides which servers receive your mail, which IPs are allowed to send on your behalf, and how receivers validate that messages are legitimate.

When DNS is misconfigured, you can have perfect content and infrastructure and still see bounces, missing messages, and deliverability issues. This guide focuses on DNS from an email‑engineer’s perspective so you can design and maintain a reliable, auditable, and migration‑friendly DNS layer for your domains.

What Is DNS? (Email‑Focused View)

DNS in One Minute for Email People

DNS is the system that answers questions like “Where is the mail server for this domain?” and “Which IPs are allowed to send email from here?”. When a remote MTA wants to deliver a message to user@example.com, it queries DNS to discover MX records, resolves hostnames via A/AAAA, and reads TXT records for SPF, DKIM, and DMARC policies.

From an email perspective, DNS is less about websites and more about mapping domains and subdomains to mail exchangers, outbound IPs, and authentication policies. If DNS answers are wrong, incomplete, or inconsistent, your email infrastructure will behave unpredictably.

DNS Zones, Nameservers, and Who Really Controls Your Email

A DNS zone is the authoritative database of records for your domain, hosted on one or more nameservers. Your registrar holds ownership of the domain, but the nameservers you configure there determine which provider actually answers DNS queries.

For email, the critical question is “Who controls the zone file where MX, SPF, DKIM, and DMARC live?”. During migrations or incident response, you must work in the authoritative DNS zone; updating records anywhere else has no effect on live traffic.

Core DNS Record Types Used in Email

A and AAAA Records (Where Your Mail Infrastructure Lives)

A records map hostnames to IPv4 addresses, and AAAA records map hostnames to IPv6 addresses. Any hostname used in MX, outbound SMTP hostnames, or DKIM selectors ultimately relies on A/AAAA to resolve to a real server.

A frequent failure pattern is an MX record that points to a hostname with no valid A/AAAA record or only an IPv6 address when many senders are effectively IPv4‑only. In practice, you should ensure every MX target hostname has stable, monitored A (and where relevant AAAA) records.

MX Records (Short Recap in DNS Context)

MX records tell the world which hosts receive email for a domain or subdomain. When a sender queries MX for example.com, DNS returns a list of mail exchangers with priorities, and the sender then resolves those hostnames via A/AAAA.

MX does not point directly to IPs; it always references hostnames, which separates routing information from addressing. Your MX pillar article can deep‑dive into priority, TTL, and troubleshooting, while this DNS guide keeps MX in context alongside other record types.

TXT Records (SPF, DKIM, DMARC and Other Policies)

TXT records are free‑form text containers, and email uses them heavily for authentication and verification. SPF is published as a TXT at the domain, DKIM public keys as TXT at selector hostnames, and DMARC policies as TXT at _dmarc.example.com.

Because TXT is multi‑purpose, zones often accumulate verification tokens for tools, CRMs, and ESPs. Without discipline, you can end up with conflicting SPF definitions or forgotten DKIM keys, so documenting TXT records is crucial in email‑heavy environments.

CNAME Records (Aliases and Email‑Specific Gotchas)

CNAME records create aliases, effectively saying “this hostname is just another name for that hostname.” They are commonly used for branded tracking domains and certain provider‑managed subdomains.

However, DNS rules forbid having a CNAME at a name that also has other record types such as MX or TXT, which is why a CNAME at the zone apex is incompatible with a typical email setup. For email, use CNAME only on dedicated subdomains that do not also host MX/SPF/DMARC records.

PTR / rDNS (Reverse DNS for Outbound Email IPs)

PTR, or reverse DNS, maps an IP address back to a hostname. For outbound email, major providers strongly prefer that the sending IP’s PTR matches the HELO/EHLO identity and aligns with SPF and overall branding.

You usually cannot edit PTR in your own zone; it is controlled by the owner of the IP space (your ISP, VPS provider, or cloud provider). A missing or generic PTR is a classic signal of low‑quality infrastructure, so setting correct rDNS on outbound mail IPs is a baseline deliverability requirement.

TTL and Propagation for Email‑Critical DNS Changes

TTL Explained for Email DNS

TTL (Time To Live) defines how long resolvers are allowed to cache a record before re‑querying the authoritative nameserver. High TTL values make your environment stable and reduce DNS load; low TTL values make changes propagate faster but increase query volume.

For email, long TTLs on MX and TXT are fine once the setup is stable, but they can slow down migrations or emergency fixes. A domain with a 14400‑second TTL may keep pointing to old MX or SPF information for several hours after a change.

What to Expect During Propagation

When you update DNS, some resolvers see the new data almost immediately while others continue serving cached answers until TTL expires. This creates a temporary period where different parts of the internet disagree about your MX/SPF/DKIM/DMARC values.

When diagnosing issues, always correlate what you see from multiple public resolvers and from inside your own network. If different tools report different MX or TXT values, you are in the propagation window and should be cautious with further changes.

How DNS Records Work Together for Email

A vs CNAME vs MX vs TXT: Interaction and Anti‑Patterns

In a healthy email DNS design, each record type has a clear role: MX defines where mail is received, A/AAAA resolve those hosts, TXT defines policies, and CNAME is used only for specific aliases. Problems appear when these roles are blurred or when records conflict.

• MX must point to hostnames that have valid A/AAAA records, not to IPs.
• SPF should be defined in a single TXT record per name; splitting SPF across multiple TXT records is undefined and can break evaluation.
• CNAME cannot coexist with other records at the same name; do not place CNAME at the apex if you also need MX/TXT there.

Example DNS Layouts for Typical Email Architectures

Small Business: Website + Mailbox Provider

SaaS / Agency: Marketing and Transactional Subdomains

DNS for Email Operations: Real‑World Workflows

Moving Email to a New Provider (DNS‑Centric Runbook)

Email migrations fail most often at the DNS layer: wrong MX, forgotten SPF updates, or missing DKIM keys. A structured runbook makes the process repeatable and auditable.

1. Inventory current DNS records related to email (MX, SPF, DKIM, DMARC, tracking subdomains, rDNS references).
2. Lower TTLs on MX and core TXT records 24 hours before cutover.
3. Add new provider’s MX, SPF mechanisms, DKIM selectors, and optional DMARC updates without removing the old entries yet.
4. Schedule cutover at a low‑traffic window; update MX to point primarily at the new provider.
5. Verify delivery inbound and outbound from multiple external accounts.
6. After a safe window, remove obsolete MX/SPF/DKIM entries and raise TTLs to steady‑state values.

Split Delivery and Dual Delivery

In split delivery, some recipients at a domain live on one system and others on another, often during staged migrations. Dual delivery sends copies of inbound mail to two systems (e.g., mailbox + archive or security appliance).

DNS usually still has a single set of MX records pointing at a smart host or primary system; routing decisions are then made inside that system based on address rules. Understanding that DNS is only the first hop is key to debugging complex split setups.

Using Email Subdomains (newsletter., transactional., support.)

Subdomains let you separate technical and reputation contexts: newsletter.example.com for marketing, transactional.example.com for system messages, support.example.com for ticketing. Each subdomain gets its own MX, SPF, DKIM, and DMARC, allowing independent tuning and warm‑up.

This approach reduces blast radius when one stream experiments with aggressive sending or new IPs. It also simplifies reporting because DMARC and provider dashboards can be filtered by subdomain.

DNS with Security Gateways and Filters

Security gateways sit in front of mailbox providers and are visible at the DNS/MX layer. MX records point to the gateway, which receives, filters, and then relays accepted messages to the final mailbox host.

When troubleshooting, you must account for both DNS and internal routing: an MX change might affect gateway reachability, while policy changes inside the gateway affect delivery beyond DNS.

Debugging “Cannot Receive Email” Using DNS

DNS‑First Troubleshooting Flow

When a domain cannot receive mail, start with DNS before diving into MTA logs. A simple, repeatable sequence avoids chasing symptoms.

1. Check that the domain resolves and that authoritative nameservers are reachable.
2. Query MX records from multiple locations; confirm at least one valid MX is present.
3. Resolve each MX target via A/AAAA; verify non‑NXDOMAIN and stable IPs.
4. Review SPF, DKIM, and DMARC TXT for obvious syntax errors or duplicates.
5. Only after DNS checks out, move on to server‑side mailbox or routing issues.

DNS Troubleshooting Table

DNS Best Practices for Email‑Heavy Domains

• Maintain a single source of truth for DNS; avoid shadow zones at old providers.
• Document all email‑related records (MX, SPF, DKIM, DMARC, tracking subdomains, PTR agreements).
• Use change windows and staged rollouts with lowered TTLs for significant changes.
• Monitor rDNS and IP ownership for outbound ranges used by your MTAs.
• Regularly audit DNS for conflicts (apex CNAME, duplicate SPF, stale MX).

Running DNS Lookups Yourself

Every online DNS lookup tool is a web front end over two commands that are already on your machine. Learning them takes ten minutes and removes a dependency: you can check a zone from inside a client’s network, from a server, or from a script, without pasting a customer domain into a third party form.

It also removes an ambiguity that the web tools introduce. When a hosted checker disagrees with what you configured, you cannot tell whether you are seeing a stale cache, a different resolver, or a real error. Running the query yourself, against a resolver you name, answers that.

Domain Names, Hostnames and FQDNs

A domain name is the registered label you own, such as example.com. A hostname is a name that resolves to a machine, such as mail.example.com. A fully qualified domain name, or FQDN, is the complete name read from the leaf up to the root, which is why DNS tools sometimes append a trailing dot: mail.example.com. is the FQDN, and the final dot is the root zone.

The distinction matters when you enter records. Most DNS panels treat a value without a trailing dot as relative to the zone, so pasting mx1.provider.com into a field that expects an FQDN can silently produce mx1.provider.com.example.com. That is one of the most common causes of an MX record that resolves to nothing.

dig: the Command That Shows the Whole Answer

dig ships with most Linux distributions and with macOS, and it is the reference tool for email DNS work because it shows you the full response rather than a summary.

The @resolver form is the one worth remembering. Asking the same question of two different resolvers, and getting two different answers, is the definitive test for the propagation window described above: it means one of them is still serving a cached record whose TTL has not expired.

nslookup on Windows

Windows ships nslookup rather than dig. It answers the same questions with a different syntax, and it is available in any Command Prompt or PowerShell session without installing anything.

One caveat specific to nslookup: it reports answers without distinguishing clearly between an authoritative response and a cached one, and it prints a non authoritative answer notice for almost everything. That notice is normal and is not an error. If you need certainty about what the zone actually contains, query the authoritative nameserver directly rather than reading into that line.

Reverse DNS Lookups

A reverse lookup goes the other way: you have an IP address and you want the hostname it claims. It is not a mirror of the forward lookup and it does not read your zone. Reverse data lives in a separate namespace, in-addr.arpa for IPv4 and ip6.arpa for IPv6, delegated to whoever owns the IP address rather than to whoever owns the domain.

For outbound mail this is the check that matters most, because receiving servers use it to judge whether the sending IP looks legitimate. The test they apply is forward confirmed reverse DNS: the IP resolves to a hostname, and that hostname resolves back to the same IP. A reverse check that returns nothing, or that returns a generic name assigned by a hosting provider, is a recognised low quality signal. Setting and verifying PTR records on sending IPs covers the configuration side, which you request from your IP provider rather than edit in your own zone.

Clearing a Stale Resolver Cache

After a DNS change, your own machine can keep answering with the old value long after the authoritative zone was updated, because the operating system caches lookups locally. Flushing that cache forces the next query out to your resolver.

The important limit, and the reason this step disappoints people during migrations: flushing your cache only affects your machine. It does nothing to the resolver your internet provider runs, nothing to the recipient’s network, and nothing to the caches of the mail servers that will deliver to you. Those all hold the record until the TTL you published expires, which is why lowering TTL before a cutover matters and clearing your own cache afterwards does not.

The practical use of a flush is narrower and still worth knowing: it lets you confirm that a change is live from a machine that had already cached the old answer, without waiting or switching networks. If your local check still shows the old value after a flush, the cache is upstream, not on your desk.

FAQ

Do I need to understand all DNS record types to manage email?

You do not need to be a DNS engineer, but you must understand A/AAAA, MX, TXT, CNAME, and PTR at a basic operational level. These records directly control where mail flows and how it is authenticated.

Can I keep DNS at my registrar if my email is hosted elsewhere?

Yes, as long as you can create and manage the required records (MX, SPF, DKIM, DMARC, and any subdomains). Many teams later move DNS to specialized providers for better tooling, performance, and automation.

Why did email break right after moving only the website?

Website migrations often involve changing nameservers or A records for the apex, and DNS changes can accidentally overwrite or remove email‑related records. If MX and TXT were not carefully carried over, email may stop working even though the site loads.

Is free DNS enough for high‑volume or mission‑critical email?

Free DNS can be technically sufficient, but you should evaluate SLAs, query limits, and support responsiveness. For revenue‑critical mail, many organizations prefer providers with strong uptime guarantees, better monitoring, and change‑control features.

How often should I review email‑related DNS records?

A quarterly review is a good baseline, plus a review after every infrastructure or provider change. This helps catch stale MX records, forgotten SPF includes, or deprecated DKIM selectors before they cause issues.

Is it safe to let multiple tools auto‑edit my DNS?

Allowing several ESPs, CRMs, and security tools to write directly to DNS increases the risk of conflicting or duplicate records. Ideally, one team owns DNS and applies changes via a controlled process, even if values originate from external tools.

When should I move DNS to a more advanced provider like Cloudflare or Route 53?

Signals that it is time to move include complex multi‑domain email setups, frequent migrations, the need for APIs/automation, and requirements for advanced features like DNSSEC or geo‑redundancy. Moving DNS is itself a project, so plan it with the same care as an email provider migration.

Stay connected via Google News

Follow us for the latest updates and guides.

About the Author

Alaa · LinkedIn

Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.

About SMTPedia

SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.

We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.

Previous

MX Records Explained: How to Configure, Test, and Troubleshoot Your Domain’s DNS

Next

PTR / rDNS Records for Email Delivery: How to Configure, Test, and Troubleshoot Your Sending IPs