MX and DNS Record Lookup for Email: How to Check Your Setup Before It Breaks

Email is a DNS application. Mail routing, sender identity, bounce handling and policy enforcement are all published as DNS records, so a quiet typo in a TXT value can degrade delivery for weeks before anyone notices a pattern.

MX: where your mail arrives

dig +short MX yourdomain.com

You want one small set of hostnames from a single provider, each with a priority. Two things go wrong here regularly: leftover MX records from a previous provider that still accept and silently drop mail, and MX hostnames pointing at a CNAME, which the standard forbids and some senders reject outright.

If the lookup returns nothing, your domain cannot receive mail — which also means it cannot receive bounces or replies, and receivers notice.

SPF: who may send as you

dig +short TXT yourdomain.com | grep spf1

Exactly one record starting v=spf1 must exist. Two SPF records is a permanent error and most receivers treat it as a fail. Count your DNS lookups too: every include:, a, mx and redirect costs one, and the limit of ten is hard. End with ~all (softfail) or -all (fail); +all authorises the entire internet to send as you.

DKIM: the signature

dig +short TXT selector._domainkey.yourdomain.com

The selector is provider-specific — google for Workspace, selector1 and selector2 for Microsoft 365, something custom for most sending tools. There is no way to enumerate selectors from DNS, so keep a list of the ones you publish. A 1024-bit key still works but 2048 is the current norm.

DMARC: the policy

dig +short TXT _dmarc.yourdomain.com

Start at p=none with a rua= address so you receive aggregate reports, confirm your legitimate senders align, then move to quarantine and reject. Set sp= explicitly if subdomains send mail — an unset subdomain policy inherits the parent, which surprises people who warm a subdomain for outreach.

PTR: reverse DNS

dig +short -x 1.2.3.4

The sending IP's PTR record must resolve to a hostname that forward-resolves back to the same IP. Missing or generic reverse DNS (anything with the raw IP embedded in a hosting provider's domain) is one of the cheapest reasons to be filtered. If you send through Google, Microsoft or an ESP this is their problem; on your own SMTP server it is yours.

MTA-STS and TLS-RPT

dig +short TXT _mta-sts.yourdomain.com
curl -s https://mta-sts.yourdomain.com/.well-known/mta-sts.txt

Optional, increasingly expected on B2B domains. MTA-STS forces TLS for inbound mail; TLS-RPT asks receivers to report failures. Publishing both is a trust signal that costs an afternoon.

BIMI and the rest

BIMI (default._bimi.yourdomain.com) needs a verified mark certificate and only pays off once DMARC is at enforcement. Treat it as a later step, not part of the baseline.

Checklist before any sending change

Run it when you add a sending tool, migrate providers, change hosts, or start warming a new domain. DNS propagation means a mistake made on Monday can still be filtering mail on Thursday — MailPilot re-checks these records on a schedule and flags drift before your reply rate does.