DNS for Email Marketers

DNS (Domain Name System) is the internet's address book. It translates human-readable domain names like tidalmail.com into machine-readable IP addresses like 192.0.2.1.

Without DNS, you would need to remember numeric addresses for every website and email server. DNS makes the internet usable.

For email, DNS does more than just translation. It stores critical records that tell other servers where to deliver mail, how to authenticate senders, and what policies apply to your domain.

Think of DNS as the harbor master's registry. It tells every ship where to find each dock and what rules apply at each berth.

A DNS lookup follows a hierarchical path:

Query initiation: Your computer asks a recursive resolver (often your ISP or a public resolver like 8.8.8.8) for a record.

Cache check: The resolver checks if it has a recent cached answer.

Recursive lookup: If not cached, the resolver queries root servers, then TLD servers, then authoritative nameservers for the domain.

Response: The authoritative server returns the record. The resolver caches it and passes it back to you.

The entire process typically takes milliseconds but can be affected by caching, propagation delays, and server availability.

Like asking a harbor agent who consults port records and regional authorities to find where your ship should dock.

An MX record (Mail Exchanger record) tells the internet which servers should receive email for your domain. It's the DNS entry that routes incoming mail.

How it works: When someone sends email to yourname@yourdomain.com, their mail server asks DNS: "Where should I deliver mail for yourdomain.com?" The MX record answers with the address of your mail server.

MX record structure:

Priority: A number indicating preference. Lower numbers are tried first. This enables backup servers.

Host: The mail server address (like mail.yourdomain.com or aspmx.l.google.com for Google Workspace).

Example:
yourdomain.com MX 10 mail.yourdomain.com
yourdomain.com MX 20 backup.yourdomain.com

For email deliverability:

MX records matter for receiving email, not sending
But receiving servers check if your domain can receive (no MX = suspicious)
Mismatch between sending and receiving infrastructure can raise flags

Common setups: Google Workspace, Microsoft 365, or your hosting provider's mail servers. Each has specific MX record requirements.

Think of MX records as your postal address. Without them, letters addressed to your domain have nowhere to go. The mail carrier (sending server) looks up your address (MX record) to make the delivery.

Missing MX records cause delivery problems:

Fallback behavior: Some senders try the A record as a last resort (RFC 5321 allows this). But many do not.

Likely outcome: Most mail bounces with errors about no mail exchanger found.

Delayed discovery: You might not notice for hours or days until someone reports missing mail.

Authentication interaction: Even if A record delivery works, authentication may fail if SPF does not account for this path.

Always have properly configured MX records. Do not rely on A record fallback.

A port with no docking assignments leaves ships circling the harbor or returning to origin.

Testing MX resolution:

Command line:

dig MX tidalmail.com

nslookup -type=MX tidalmail.com

Online tools: MXToolbox, DNSChecker, Google Admin Toolbox

What to verify:

Correct mail servers listed

Appropriate priority values

Servers are reachable (no connection timeouts)

Servers accept SMTP connections

From multiple locations: Test from different networks to verify consistent results. Propagation may vary.

Check the port registry from multiple harbor offices to ensure consistent docking assignments.

Reverse DNS (rDNS) maps an IP address to a hostname. It is the opposite of forward DNS (which maps hostname to IP).

Forward: mail.tidalmail.com → 192.0.2.1

Reverse: 192.0.2.1 → mail.tidalmail.com

How it works: PTR records in special reverse DNS zones (in-addr.arpa for IPv4) store the mapping.

Email importance:

Receivers check if sending IP has valid reverse DNS

Missing or mismatched rDNS is a spam signal

Legitimate mail servers always have proper rDNS

Reverse DNS proves the IP owner has configured it properly. It is a basic trust indicator.

Verifying a ship's registration by looking up its hull number rather than its name.

A PTR record (Pointer record) provides reverse DNS lookup:

Structure: IP address (in reverse format) → hostname

1.2.0.192.in-addr.arpa PTR mail.tidalmail.com

Who controls PTR records: The IP address owner (usually your hosting provider or ISP) manages PTR records, not your domain registrar.

Setting up: Contact your IP provider to create or modify PTR records for your sending IPs.

Email requirements:

PTR should exist for every sending IP

Hostname should be meaningful (not generic)

Forward lookup of that hostname should return the same IP (FCrDNS)

The reverse registry lookup. Given a hull number, return the ship's registered name.

PTR validity directly affects deliverability:

Receiver behavior:

Many receivers check PTR before accepting mail

No PTR = often rejected or deferred

Generic PTR = strong spam indicator

Reputation signals: Professional mail servers have professional rDNS. Spammers often use IPs without proper PTR.

Authentication complement: PTR does not replace SPF/DKIM/DMARC but adds another layer of legitimacy verification.

What qualifies as valid:

Exists (not NXDOMAIN)

Meaningful hostname (not IP-based or generic)

Forward-confirmed (A record matches)

Proper ship documentation is expected in every legitimate harbor. Missing papers invite inspection or rejection.

Key DNS limitations for email:

SPF lookup limit: Maximum 10 DNS lookups (include, a, mx, redirect, exists mechanisms). Exceeding causes permerror.

TXT string limit: 255 characters per string. Longer content must be split into multiple strings.

Total record size: Practical limits around 4096 characters for entire TXT record.

UDP response limit: Traditional 512 bytes. Larger responses may require TCP fallback.

Provider limits: Some providers restrict record count, length, or characters allowed.

These limits affect complex email setups. Plan authentication architecture to stay within limits.

Registry forms have size limits and section counts. Fit your documentation within the allowed structure.