DNS records that decide whether email gets delivered

Email delivery depends on several independent contracts published in DNS. An MX record tells a sending system where a domain accepts mail. SPF describes which hosts are allowed to send mail for a domain. DKIM attaches a cryptographic signature that a receiver can verify with a public key. DMARC tells receivers how to evaluate alignment between the visible From domain and authenticated signals, and where to send aggregate or forensic reports. None of these records alone guarantees inbox placement. Together they let a receiver decide whether a message is plausibly authorized and whether the domain owner has a policy for failures.

Start troubleshooting by separating identity from routing. A message can route correctly to an MX host and still fail SPF or DMARC. A DKIM signature can be valid while the signed domain is unrelated to the visible From address. Use a DNS inspection tool to capture the exact record name, record type, TTL, and returned values from more than one resolver. Copying a record from a dashboard without its host name or quoting rules often creates a second problem while trying to solve the first.

MX records are ordered by preference, with the lowest numeric value preferred. A domain may publish more than one host for redundancy, but the hosts should actually accept mail for that domain. An MX target must resolve to an address through A or AAAA records. Pointing an MX record at a web alias, a CNAME where the provider forbids it, or a hostname that does not resolve creates a delivery failure before authentication is evaluated. Check both IPv4 and IPv6 because a receiver may prefer IPv6 and expose a problem that IPv4-only testing misses.

Do not confuse the root domain with a subdomain used for a service. The MX records for example.com do not automatically control mail.example.com, and a provider's onboarding instructions may ask for records at a delegated subdomain. Confirm the exact domain in the envelope recipient and the exact domain being queried. When testing a change, consider resolver caching and the published TTL. One resolver returning an old record is not proof that the new record failed; it may still be within the expected cache window.

SPF is published as one TXT record beginning with v=spf1. It lists mechanisms such as ip4, ip6, a, mx, include, and all. Receivers evaluate those mechanisms from left to right and stop at the first match. The final all qualifier is important: a minus sign asks for fail, a tilde asks for softfail, and a question mark asks for neutral. SPF is evaluated against the envelope-from domain, which may differ from the address a user sees in the From header.

The ten-DNS-lookup limit is a common operational failure. Every include, a, mx, and redirect can consume lookups, and nested vendor records can push a domain over the limit. Flattening records manually is brittle because vendor IP ranges change. Prefer a small set of sending services, remove obsolete includes, and verify the resulting lookup count with a validator. Publish one SPF record per domain; multiple v=spf1 records cause a permanent error rather than combining cleanly.

DKIM signs selected headers and the body with a private key. The public key is published at a selector name such as selector1._domainkey.example.com. The selector lets a domain operate multiple keys during rotation or for different sending platforms. Receivers retrieve the public key, verify the signature, and check whether the signed content remained intact in transit. A valid DKIM result proves that the signing domain controlled the private key and that the signed parts were not altered; it does not by itself prove that the visible From address is trustworthy.

When DKIM fails, inspect the selector, key record formatting, and the sending service's canonicalization settings. Long public keys are often split into adjacent quoted TXT strings, which DNS combines without adding a space. Accidental spaces, smart quotes, or a truncated value break verification. A message can also fail if an intermediary modifies a signed header or body. Sign only headers that will survive normal transport, and rotate keys with an overlap period so old mail can still be evaluated while caches expire.

DMARC evaluates whether SPF or DKIM passes with an aligned domain. In relaxed alignment, organizational domains can match even when subdomains differ. In strict alignment, the domains must match exactly. The DMARC record is published at _dmarc.example.com and includes a policy such as p=none, quarantine, or reject, plus optional reporting addresses and an alignment mode. A message passes DMARC when at least one authenticated mechanism both passes and aligns with the visible From domain.

Start a new domain with p=none and collect aggregate reports so you can see every legitimate sender, including forgotten marketing tools and application servers. Move gradually toward quarantine and reject after fixing sources and confirming that reports are complete. Treat reports as operational data: they contain sending IPs, counts, and authentication results, but may also reveal customer or provider relationships. Use a reporting service or a controlled mailbox rather than forwarding raw reports to a personal inbox.

A sender dashboard can say delivered while a particular recipient rejects or files the message because receivers apply their own reputation and content rules. Capture the SMTP response when possible. Distinguish a DNS failure, an authentication failure, a policy rejection, a temporary deferral, and a mailbox-level bounce. Check the domain's records from the public internet, not only from a corporate resolver that may rewrite answers. Verify that the hostname used by the sending service has a forward and reverse DNS identity where the provider requires one.

Document every sending source and its expected authentication path. For a transactional service, that may be DKIM plus a custom return-path domain. For a local application, it may be SPF from a fixed egress address. If a message uses several services, test each separately. A DNS sandbox is useful for checking the current public state, but keep a change log with timestamps because DNS and provider configuration can drift independently.

Review MX targets, SPF lookup count, DKIM selector rotation, DMARC alignment, reporting volume, and bounce categories at least quarterly. Remove vendors that no longer send mail. Keep ownership of the domain and DNS provider clear so an emergency change does not depend on one person. Add automated checks that warn before a record disappears or exceeds a known limit, but do not automatically publish a risky authentication policy without human review.

The goal is not to collect every possible DNS record. It is to make the path from a message to an accountable sender easy to explain. When a delivery issue appears, inspect the records, compare them with the actual envelope and headers, and identify the first contract that is false. That evidence-based workflow is faster than repeatedly changing SPF or DMARC syntax and hoping an inbox result improves.

Document the intended mail flow before editing DNS: sending providers, envelope domain, visible From domain, DKIM selector, and reporting destination. Keep one owner for each record and distinguish a zone-file name from the fully qualified name shown by a DNS tool. Treat SPF, DKIM, and DMARC as aligned controls rather than independent checkboxes.

Query MX, TXT, and CNAME records from more than one resolver and inspect the final Authentication-Results header on a real message. Check SPF lookup count, DKIM selector publication, DMARC record syntax, alignment, TTL, and whether a provider rewrites the envelope domain. A record visible in one DNS console is not proof that receivers see the intended answer.

Track every sender, selector, SPF include, owner, expiry or rotation date, and last observed authentication result. Remove obsolete authorization only after a full business cycle confirms it is unused. If mail breaks, restore the last known-good record or lower DMARC enforcement in a controlled change while preserving reports; do not publish duplicate DMARC records or an unrestricted SPF record.

Use RFC 7208 for SPF, RFC 6376 for DKIM, RFC 7489 for DMARC, and the DNS provider's authoritative record-format documentation. Record provider-specific forwarding and alignment behavior in the sender inventory.