Email deliverability problems follow a consistent pattern. Messages bounce, land in spam, or disappear entirely. The sending server appears healthy, the message content looks fine, but something is failing upstream at the DNS layer before a single message gets routed.
That failure is almost always one of four things: an MX record pointing at the wrong server, an SPF record that does not include all your sending sources, a DKIM key that does not match what the mail server is signing with, or a DMARC policy set to reject but pointing at a reporting address nobody monitors.
A DNS Lookup surfaces all of these records before you send anything. It is the diagnostic step that most email troubleshooting skips until messages are already failing.
What DNS Records Control Email Delivery
The domain name system handles more than website routing. For email, four record types determine whether messages reach inboxes or get refused entirely.
MX records tell receiving mail servers where to deliver messages addressed to your domain. Each MX record contains a priority value and a mail server hostname. Lower priority numbers are preferred. If MX records are missing or point at a decommissioned server, inbound delivery fails completely.
TXT records carry text-based configuration that mail receivers use to verify senders. SPF, DKIM public keys, and DMARC policies all live in TXT records. This means a single DNS lookup on a domain can surface all three email authentication layers at once, making it the fastest single check you can run before troubleshooting an email issue.
CNAME records appear in DKIM setups when the signing key is hosted by a third-party provider. The CNAME at selector._domainkey.yourdomain.com points at the provider's infrastructure. A broken CNAME chain means DKIM validation fails silently on every outgoing message.
CAA records do not directly affect delivery but matter for mail servers using STARTTLS. A CAA record restricts which certificate authorities can issue TLS certificates for the domain. An incorrect CAA entry can block certificate issuance for the mail server's hostname, which breaks encrypted delivery from servers that require it.
Photo by Oktay Köseoğlu on Pexels
How to Read MX Records
A healthy MX record set for a domain looks like this:
- Priority 10:
mail.yourdomain.com - Priority 20:
mail-backup.yourdomain.com
Multiple entries with different priorities provide redundancy. If the primary server is unreachable, other sending mail servers will attempt delivery to the lower-priority backup. This fallback behavior is part of the SMTP specification -- a sending server that receives a temporary failure from the primary MX will retry delivery to lower-priority hosts before giving up.
Two configurations cause consistent deliverability problems:
MX pointing at a CNAME. The DNS specification prohibits this. Some resolvers accept it, others reject it unpredictably. Mail that routes through non-conforming resolvers may bounce with confusing error messages that point at the delivery server rather than the DNS configuration.
MX pointing at an IP address directly. MX values must be hostnames, not IP addresses. Some receiving servers will refuse to accept connections from domains with this configuration, citing RFC non-compliance in their rejection messages.
Running a DNS lookup before configuring a new mail provider verifies that the MX records were added correctly and that no stale entries from a previous provider remain in the zone.
Checking SPF Records
SPF (Sender Policy Framework) is a TXT record that lists which mail servers are authorized to send email on behalf of your domain. The format is:
v=spf1 include:_spf.mailprovider.com ~all
The include: mechanism points at the SPF record of another domain, typically your email provider. The final qualifier determines what receiving servers do with messages that fail SPF:
~allis a soft fail: deliver the message but mark it as suspicious-allis a hard fail: reject the message outright?allis neutral: apply no action
SPF has a hard limit of 10 DNS lookups during evaluation. If your SPF record uses include: statements that recursively reference more than 10 domains, validation fails with a permerror. This is a common and invisible problem on domains that use multiple email services simultaneously -- a transactional provider, a marketing platform, and a shared company mail server each adding their own include: statements without anyone counting the total.
Photo by Nic Wood on Pexels
When running a DNS lookup on a domain, locate the TXT record starting with v=spf1 and trace each include: to count the total lookup depth. The SPF standard is defined in RFC 7208. The syntax section explains how lookups are counted and what counts against the limit. An SPF flattening tool can resolve all the include: chains into a single flat record that stays within the limit, which eliminates the permerror without changing the authorized sender list.
Checking DKIM Records
DKIM (DomainKeys Identified Mail) works differently from SPF. Rather than a policy record, DKIM publishes public keys that receiving mail servers use to verify a cryptographic signature embedded in each outgoing message header.
The public key lives at selector._domainkey.yourdomain.com as a TXT record. The selector is chosen by the signing service and is visible in the DKIM-Signature header of any outgoing message. Common selectors are google, s1, or k1.
To check DKIM with a DNS lookup:
1. Identify the selector your sending service uses (check your email provider's setup documentation, or inspect the DKIM-Signature header of an outgoing message)
2. Look up selector._domainkey.yourdomain.com as a TXT record
3. Verify the record contains v=DKIM1 and a non-empty p= field containing the public key
An empty p= field signals a revoked key. Some providers set this deliberately to indicate a rotated key. If the replacement key has not been published under a new selector, DKIM validation fails on all outgoing messages without any bounce or error at the sending stage.
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB...
The p= value is a Base64-encoded RSA or Ed25519 public key. The DKIM standard is defined in RFC 6376.
Photo by "Most email deliverability problems we see trace back to a DNS misconfiguration that nobody checked until messages started bouncing. Running a DNS lookup on a domain before adding any new sending service takes five minutes and prevents the kind of cascading SPF failures that take days to untangle." - Dennis Traina, founder of 137Foundry
Checking DMARC Records
DMARC (Domain-based Message Authentication, Reporting and Conformance) sits on top of SPF and DKIM. It tells receiving mail servers what to do when a message passes or fails authentication, and where to send reports.
The DMARC record lives at _dmarc.yourdomain.com as a TXT record:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com; pct=100
The policy (p=) has three values:
none: monitor only, no action on failuresquarantine: send failing messages to spamreject: refuse failing messages outright
For a domain actively sending email, p=none with aggregate reporting enabled (rua=) is the right starting point. It lets you observe authentication failures for all sending sources without risking legitimate mail delivery. Once SPF and DKIM are verified clean across all sending services, moving to quarantine is safe.
Problems to look for in a DMARC record:
- The
rua=reporting address points at an inbox nobody reads. Reports accumulate unread while authentication failures go unnoticed. - Policy is
rejecton a domain where not all sending sources have been authenticated. Legitimate transactional or marketing mail gets refused. - Multiple DMARC records exist. There should be exactly one per domain.
- No DMARC record exists at all. Many large mail providers now apply stricter default handling to unauthenticated senders.
The DMARC standard is defined in RFC 7489.
Running a Full Email DNS Audit
When you run a DNS lookup on a domain, a systematic email health check covers the following steps in order:
- Verify MX records exist, point at valid hostnames (not CNAMEs or IP addresses), and have appropriate priority ordering.
- Find the TXT record beginning with
v=spf1. Trace allinclude:references and count the total DNS lookups. Verify the final qualifier is appropriate for your use case. - Fetch
selector._domainkey.yourdomain.comfor each active sending selector. Confirm the public key is present, correctly formatted, and not revoked. - Fetch
_dmarc.yourdomain.com. Check the policy, confirm therua=address is actively monitored, and verifypct=100if you intend to apply the policy to all messages. - Check NS records to confirm the authoritative nameservers match what your registrar shows. Mismatched NS records indicate a zone delegation problem that can affect every DNS query for the domain.
- Note any CAA records that might conflict with TLS certificate issuance for the mail server hostname.
This audit takes under ten minutes and should run before adding a new email service, before any domain migration, and immediately after a provider change. Most deliverability problems that take days to diagnose come down to a stale include: in an SPF record, a rotated DKIM key where the new selector was never published in DNS, or a DMARC policy nobody realized was set to reject.
Photo by panumas nikhomkhai on Pexels
The DNS Lookup tool on EvvyTools returns A, AAAA, CNAME, MX, TXT, NS, SOA, and CAA records with plain-English annotations. The tools directory includes related network and developer utilities. The EvvyTools blog has additional guides on DNS, web diagnostics, and developer tools.
For additional email diagnostics, MXToolbox runs blacklist checks alongside DNS lookups. The IANA root zone database provides authoritative delegation records when you need to verify the registrar chain for a domain.
DNS changes propagate on a schedule determined by each record's TTL. After updating MX, SPF, DKIM, or DMARC records, run a DNS lookup every 30 minutes until the new record appears consistently across multiple resolvers. Most email-related records are published with TTLs of one hour or less, so propagation usually completes within that window. Checking from multiple vantage points -- not just your own network -- catches cases where local resolver caches are serving stale answers.
