dig commands every email engineer should know

BIMI#

dig +short TXT default._bimi.example.com

Expect v=BIMI1 with an l= logo URL and an a= certificate URL (or a= empty).

Reading the status line#

+short hides one of the most useful pieces of information: the response status. Run the query without it, or with +noall +comments, and look at the header line that contains status:.

• NOERROR with an answer is the normal case.
• NOERROR with no answer means the name exists but has no record of the type you asked for. A _dmarc name with a CNAME but no TXT, or a domain with A records but no MX, looks like this.
• NXDOMAIN means the name does not exist at all. For DMARC under RFC 9989, a subdomain that returns NXDOMAIN for address and MX lookups is a non-existent domain, which is where the np tag applies.
• SERVFAIL means the resolver could not get a trustworthy answer. On a DNSSEC-signed zone it often points to a signing or delegation problem; try dig +cd (checking disabled) to see whether the data is there but failing validation.

Receivers react differently to each. An SPF lookup that times out or returns SERVFAIL produces temperror, and the sender usually retries; a missing record produces none. Knowing which one you are dealing with saves a lot of guessing.

Gotchas that waste time#

A handful of small things regularly mislead people:

• Search domains. A name typed without a trailing dot may have your local search domain appended by some tools. dig does not do this by default, but host and nslookup can, depending on configuration.
• Multiple strings. Long TXT records come back as several quoted strings separated by spaces. Receivers join them with no separator, so "v=spf1 include:a.example" " include:b.example ~all" is one record. Do not mistake that output for two records.
• Copying from the dashboard. Your DNS provider's interface shows what it intends to serve, which may differ from what it actually serves after a failed save or an import. Always confirm with dig against the authoritative server.
• Testing from a corporate network. Internal resolvers sometimes serve a split-horizon view with different records. Test against public resolvers too.

Bypassing caches when testing changes#

You changed a record five minutes ago and dig still shows the old value. That is usually your local resolver's cache, not a failed change. Options:

Ask the authoritative servers directly#

dig +short NS example.com
dig +short TXT example.com @ns1.dnshost.example

The authoritative server always returns the current value. If it shows the new record, the change is published and caches will catch up within the old TTL.

Trace from the root#

dig +trace TXT _dmarc.example.com

+trace walks the delegation chain from the root servers, querying each authoritative server directly. It also reveals delegation problems, such as a subdomain delegated to name servers that no longer answer.

Compare several public resolvers#

for r in 1.1.1.1 8.8.8.8 9.9.9.9; do echo "$r: $(dig +short TXT _dmarc.example.com @$r)"; done

Different answers across resolvers usually mean a change is still propagating.

Reading TTLs#

dig +noall +answer TXT _dmarc.example.com @8.8.8.8
# _dmarc.example.com. 1742 IN TXT "v=DMARC1; p=reject; ..."

From a caching resolver, the TTL counts down: 1742 means that resolver will keep this answer for about 29 more minutes. From the authoritative server, you see the full configured TTL.

A one-shot domain check#

Put the common queries together for a quick audit:

d=example.com
echo "MX:    $(dig +short MX $d | tr '\n' ' ')"
echo "SPF:   $(dig +short TXT $d | grep -i spf1)"
echo "DMARC: $(dig +short TXT _dmarc.$d)"
echo "STS:   $(dig +short TXT _mta-sts.$d)"
echo "TLSRPT:$(dig +short TXT _smtp._tls.$d)"
echo "BIMI:  $(dig +short TXT default._bimi.$d)"

DKIM is the only record you cannot discover this way, because selector names are arbitrary. Find them in the headers of real messages.

Key takeaways#

• +short answers quick questions; +noall +answer shows TTLs and CNAME chains.
• Each record lives at a predictable name except DKIM, whose selector comes from message headers.
• Query authoritative servers or use +trace to see current values without cache interference.
• Compare multiple public resolvers to confirm a change has propagated.