▶Prefer to watch? This video runs the guide's main commands on a real Ubuntu 24.04 machine, with on-screen captions and no voiceover. Click to play, or watch it on YouTube. It is part of the Networking and Firewalls playlist.
dig [@server] [name] [type] [options]
dig +short example.com
dig (Domain Information Groper) asks DNS servers questions and shows you the raw answers. It is the sysadmin's standard tool for DNS: is a name resolving, to what, from which server, how long
will the answer be cached, why does mail fail, has a change propagated, is DNSSEC broken, are the name servers in sync. Unlike nslookup, dig shows the full response (flags, sections, TTLs) so you can
see exactly what the server said. This sheet covers the everyday queries, record types, output reading, tracing, mail and Active Directory records, DNSSEC, encrypted DNS, troubleshooting flows and one-liners.
Install: sudo apt install dnsutils (Debian/Ubuntu: newer releases call it bind9-dnsutils) sudo dnf install bind-utils (RHEL family) brew install bind (macOS has dig built in) dig -v version
The basics
dig example.com # ask your default resolver for the A record of example.com (the full output)
dig example.com A # the record TYPE is the second word (A is the default) dig example.com AAAA IPv6 dig example.com MX mail servers
dig +short example.com # ONLY the answer values (perfect for scripts)
dig @1.1.1.1 example.com # ask a SPECIFIC server (@server) instead of the one in /etc/resolv.conf
dig @ns1.example.com example.com # ask an authoritative name server directly (the source of truth, no cache)
dig -x 203.0.113.10 # REVERSE lookup: the PTR record for an IP address (dig -x builds the in-addr.arpa name for you)
dig -x 2001:db8::1 # reverse lookup for IPv6
dig +noall +answer example.com # print only the ANSWER section, with TTL and record type (the tidy default for reading)
dig +short example.com MX # short answer for a specific type dig example.com ANY (often refused or truncated now: see below)
dig -4 example.com dig -6 example.com # force IPv4 or IPv6 transport to the server dig -p 5353 @127.0.0.1 example.com a non-standard port
dig -f names.txt +short # look up every name in a file, one per line dig -f names.txt +noall +answer -t A
dig example.com +tcp # use TCP instead of UDP (large answers, or testing firewalls)
Syntax tips: options that begin with + are query options (+short, +trace), and options that begin with - are dig program options (-x, -p, -4). The order of name, type and @server does not matter.
Reading the full output
$ dig example.com
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41234
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;example.com. IN A
;; ANSWER SECTION:
example.com. 3600 IN A 93.184.216.34
;; Query time: 23 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Sat Sep 26 10:15:00 UTC 2026
;; MSG SIZE rcvd: 56
status: NOERROR (worked) NXDOMAIN (the name does not exist) SERVFAIL (the server could not get an answer: broken DNSSEC, dead upstream, lame delegation) REFUSED (the server will not answer you: ACL or recursion off) FORMERR (bad query) NOTIMP
Header flags: qr = this is a response aa = AUTHORITATIVE answer (from the zone's own server) tc = TRUNCATED (retry over TCP) rd = recursion desired (you asked) ra = recursion available (the server offers it)
ad = authenticated data (DNSSEC validated) cd = checking disabled
QUESTION What you asked. ANSWER The records that answer it. AUTHORITY Name servers responsible (shown with referrals, NXDOMAIN, or NODATA: it contains the SOA) ADDITIONAL Helpful extras (glue records, EDNS)
Record line: NAME TTL CLASS TYPE DATA. TTL = how many seconds a cache may keep it (with a caching resolver it counts DOWN, so you can see how old the answer is). IN = Internet class.
Query time: How long the answer took. 0 to a few msec = cached locally; tens of msec = a network lookup. SERVER: which server actually answered (127.0.0.53 means systemd-resolved).
NOERROR with an empty ANSWER = the name exists but has NO record of that type ("NODATA"). NXDOMAIN = the name does not exist at all. They are different problems.
Cut the noise: +noall +answer shows only answers, +nocmd hides the dig version header, +nostats hides the footer, +noauthority +noadditional +nocomments trim sections, +multiline formats big records (SOA, DNSKEY) readably.
Record types you will query
A IPv4 address AAAA IPv6 address CNAME An alias to another name (a canonical name)
MX Mail servers for a domain, with priority (lowest first) TXT Free text: SPF, DKIM, DMARC, domain verification NS The name servers that are authoritative for a zone
SOA Start of authority: the primary server, admin contact, SERIAL number and timers PTR Reverse lookup: IP to name SRV Service location (_service._proto.name): AD, SIP, XMPP
CAA Which CAs may issue certificates for the domain DNSKEY / DS / RRSIG / NSEC DNSSEC records TLSA DANE certificate data SSHFP SSH host key fingerprints
HTTPS / SVCB Service binding records (HTTP/3 and ECH hints) NAPTR Telephony name rewriting LOC Geographic location URI URLs ANY "Everything" (see the note)
dig example.com A dig example.com AAAA dig example.com MX +short dig example.com TXT +short dig example.com NS +short dig example.com SOA +multiline dig example.com CAA +short
Note on ANY: most servers now answer dig ANY with a minimal or refused reply (RFC 8482) and it may show only some records. Ask for each type you need.
List of types: dig -t TYPE or the word after the name. Numeric types work too: dig example.com TYPE257 (CAA).
Choosing WHO you ask (this decides what you learn)
Your normal resolver (default) dig example.com What your machine really uses: cached, possibly filtered, split-horizon, or hijacked
A public resolver dig @1.1.1.1 example.com @8.8.8.8 @9.9.9.9 @208.67.222.222 Compare: does the problem exist everywhere, or only on your network?
The authoritative server dig @ns1.example.com example.com The truth from the zone itself, with no cache in between. Look for the aa flag
The root or TLD servers dig @a.root-servers.net example.com dig @a.gtld-servers.net example.com Referrals: who is responsible for the next level?
Find the authoritative servers: dig +short NS example.com then ask each one directly (see "Are all my name servers in sync?")
Which resolver does this machine use? cat /etc/resolv.conf (127.0.0.53 = systemd-resolved: use resolvectl status to see the real upstream servers)
Recursive resolver vs authoritative server: a RESOLVER answers on behalf of clients by walking the tree and caching (needs the rd flag and offers ra ). An AUTHORITATIVE server only answers for its own zones (you get aa , and no recursion).
Trace: walk the DNS tree yourself
dig +trace example.com # start at the root servers and follow each referral down to the answer (like a resolver would)
dig +trace +nodnssec example.com # the same without DNSSEC noise dig +trace example.com MX trace a different record type
dig +trace +short example.com # a compact trace
What you see: the root servers (.), then the TLD servers (.com), then the domain's own name servers, and finally the answer. Every step shows WHICH server answered.
Use it to find: a wrong delegation (the registrar's NS records differ from the zone's), a lame delegation (a listed name server that does not answer), a dead name server, or where a change has not arrived.
+trace ignores your local resolver and its cache: it queries the internet directly. If it works but a normal query fails, the problem is your resolver.
Reverse DNS (PTR)
dig -x 203.0.113.10 +short # the PTR name of an IP (mail servers need this to match their hostname)
dig 10.113.0.203.in-addr.arpa PTR # what -x builds: the IP reversed, plus .in-addr.arpa (IPv6 uses .ip6.arpa with nibbles)
dig -x 203.0.113.10 +noall +answer +authority # the authority section shows who is responsible for the reverse zone (your ISP or cloud provider)
Forward-confirmed reverse DNS check (the PTR name must resolve back to the same IP):
ip=203.0.113.10 ; name=$(dig -x $ip +short) ; echo "$ip -> $name -> $(dig +short $name)"
Reverse zones are controlled by whoever owns the IP block: set PTR records at your ISP or cloud console, not in your own zone (unless you were delegated the block).
Mail records (email delivery and trust)
dig +short MX example.com # mail exchangers: "10 mail.example.com." lowest number = highest priority. Then check that each host has an A/AAAA record
dig +short TXT example.com | grep -i spf # the SPF record: v=spf1 mx include:_spf.example.net -all (only ONE SPF record is allowed)
dig +short TXT _dmarc.example.com # DMARC policy: v=DMARC1; p=quarantine; rua=mailto:...
dig +short TXT mail._domainkey.example.com # a DKIM public key for the selector "mail" (you must know the selector: it is in the message headers, in the DKIM-Signature: s=mail)
dig +short TXT _mta-sts.example.com # MTA-STS policy present? dig +short TXT _smtp._tls.example.com TLS reporting
dig +short CNAME autodiscover.example.com # Outlook autodiscover dig +short SRV _autodiscover._tcp.example.com
dig +short A mail.example.com ; dig +short -x $(dig +short A mail.example.com) # forward and reverse for the mail host (they should match its hostname)
dig +short TXT default._bimi.example.com # BIMI logo record (if used)
DNSBL (blocklist) check for an IP (reverse the octets and append the list's zone): dig +short 10.113.0.203.zen.spamhaus.org no answer = not listed; 127.0.0.x = listed (some lists refuse queries from big public resolvers)
Long TXT records are split into quoted 255-character pieces: "part1" "part2" (they join into one value).
See the Postfix guide for how these records are used.
Active Directory and service records (SRV)
dig +short SRV _ldap._tcp.dc._msdcs.corp.example.com # the domain controllers (priority weight port target)
dig +short SRV _kerberos._tcp.corp.example.com # Kerberos KDCs dig +short SRV _kpasswd._tcp.corp.example.com password changes dig +short SRV _gc._tcp.corp.example.com Global Catalogs
dig +short SRV _ldap._tcp.SITENAME._sites.dc._msdcs.corp.example.com # DCs of ONE AD site (does your client's site have a DC?)
dig +short SRV _sip._tcp.example.com dig +short SRV _xmpp-server._tcp.example.com dig +short SRV _submission._tcp.example.com # other services that use SRV
SRV format: _service._protocol.name -> priority weight port target. Lowest priority first, then weight decides among equals. A missing or stale SRV record is behind many "cannot find a domain controller" failures (see the AD troubleshooting guide).
TTL, caching and propagation
dig +noall +answer example.com # the TTL column: seconds a cache may keep the answer. Ask a caching resolver twice and watch it count down
dig +noall +answer +ttlunits example.com # show TTLs as 1h, 30m, 1d
dig @ns1.example.com +noall +answer example.com # the authoritative TTL is the FULL value; a resolver shows what is LEFT
DNS "propagation" is just caches expiring. When you change a record: lower the TTL BEFORE the change (a day ahead), make the change, verify on the authoritative servers, then wait one old TTL for every cache to refresh.
Check a change against many resolvers:
for r in 1.1.1.1 8.8.8.8 9.9.9.9 208.67.222.222 ; do printf '%-16s' $r ; dig @$r +short example.com | tr '\n' ' ' ; echo ; done
Negative answers are cached too (NXDOMAIN and NODATA use the SOA's minimum TTL): a name you just created may still "not exist" on resolvers that recently checked it.
To bypass local caches: dig @1.1.1.1 ... , dig +trace , or ask the authoritative server directly. Flush your own cache: sudo resolvectl flush-caches or sudo systemd-resolve --flush-caches (Linux), sudo dscacheutil -flushcache ; sudo killall -HUP mDNSResponder (macOS), ipconfig /flushdns (Windows).
Are all my name servers in sync? (SOA serial check)
dig +short SOA example.com # "ns1.example.com. hostmaster.example.com. 2026092601 7200 900 1209600 300" : the third number is the SERIAL (a change counter)
for ns in $(dig +short NS example.com); do printf '%-28s ' $ns; dig +short @$ns SOA example.com | awk '{print $3}'; done # the serial from EVERY authoritative server
dig +nssearch example.com # dig does the same for you: asks each NS for the SOA and prints the serial and the time
If the serials differ, the secondary servers have not received the latest zone (check zone transfer permissions, NOTIFY, firewall on TCP 53, and the primary's logs). Different answers from different name servers cause random failures for users.
Also compare the NS records at the parent (the registrar) with the ones in your zone: dig +short NS example.com @a.gtld-servers.net (the parent's view: use the TLD server for your suffix) versus dig +short NS example.com @ns1.example.com .
DNSSEC
dig +dnssec example.com A # ask for DNSSEC records: adds RRSIG signatures. Look for the "ad" flag from a validating resolver
dig +short DNSKEY example.com ; dig +short DS example.com @a.gtld-servers.net # the zone's public keys, and the DS hash held by the PARENT (they must match)
dig +multiline DNSKEY example.com # keys with readable formatting (flag 257 = KSK, 256 = ZSK)
dig example.com A +cd # +cd (checking disabled): ask the resolver to skip validation. If it works with +cd but gives SERVFAIL without, the problem is DNSSEC (expired signatures, wrong DS at the registrar)
dig dnssec-failed.org @1.1.1.1 # a deliberately broken test domain: a validating resolver returns SERVFAIL; +cd returns an answer
dig +trace +dnssec example.com # follow the chain of trust
delv example.com # BIND's validating lookup tool: prints "fully validated" or the exact reason it fails delv +vtrace example.com step by step
RRSIG has an expiry: expired signatures = SERVFAIL for validating users. After changing DNS providers, remember to update the DS record at the registrar (or remove it) or the whole domain can go dark.
Encrypted DNS: DNS over TLS and HTTPS
dig +tls @1.1.1.1 example.com # DNS over TLS (DoT) on port 853 (dig 9.18 or newer)
dig +https @dns.google example.com # DNS over HTTPS (DoH) dig +https=/dns-query @cloudflare-dns.com example.com
dig +tls-ca @dns.example.net example.com # verify the server certificate
dig +tcp @1.1.1.1 example.com # plain DNS over TCP (port 53)
Handy to test whether a network blocks 853 or 443 DNS, and whether an internal encrypted-DNS server works. Older dig versions lack these flags: check dig -v .
Zone transfers (AXFR and IXFR)
dig @ns1.example.com example.com AXFR # request the WHOLE zone (all records) over TCP. Only works if the server ALLOWS you: secondaries yes, the public no
dig @ns1.example.com example.com IXFR=2026092500 # an incremental transfer since a serial
dig @ns1.example.com example.com AXFR -y hmac-sha256:key-name:BASE64SECRET # with a TSIG key (the normal way between your own servers)
A zone transfer open to everyone leaks every host name in your zone. Restrict it (allow-transfer in BIND, or TSIG). Only try it against servers you administer, or that you are permitted to test.
Advanced options
+norecurse # do NOT ask for recursion (rd off): see only what the server has cached or is authoritative for (cache snooping tests, checking authoritative servers)
+recurse # (default) ask for recursion +nocookie no DNS cookie +noedns send a plain query without EDNS0 (old or broken firewalls, tiny UDP limits)
+bufsize=1232 # set the EDNS UDP size. 1232 avoids fragmentation problems. Big answers over UDP may be truncated: tc flag then retry with +tcp
+time=3 +tries=2 # query timeout in seconds and number of tries (default 5 seconds, 3 tries). Lower them in scripts so a dead server does not hang you
+subnet=203.0.113.0/24 # send an EDNS Client Subnet: see what a geo-DNS/CDN would answer for a client in that network
+nsid # ask the server to identify itself (anycast instance name) +identify show which server answered (when you list several @servers)
+ttlunits # show TTLs as 1h, 30m, 1d (for full control over the output use +noall +answer instead of +short)
+search # use the search domains from /etc/resolv.conf for short names (dig ignores them by default, unlike ping and curl)
+vc # use TCP (virtual circuit) = +tcp +ignore do not fall back to TCP when truncated
+trace +additional # show glue records during a trace
Query several things at once: dig example.com A example.org MX +noall +answer (each name with its own type, then shared options)
Local defaults in ~/.digrc (one line of options applied to every dig): +noall +answer then plain dig example.com prints just the answer. Use dig -r to ignore .digrc for one run.
CHAOS class queries (server information; many servers hide them): dig @ns1.example.com version.bind CH TXT dig @ns1.example.com hostname.bind CH TXT
Troubleshooting flow: "the name will not resolve"
1. What does MY resolver say? dig example.com (status, answer, and the SERVER that replied)
2. What does a public resolver say? dig @1.1.1.1 example.com ; dig @8.8.8.8 example.com If it works there, the problem is your local resolver, network or filter
3. What does the authoritative server say? dig +short NS example.com ; dig @ns1.example.com example.com +norecurse Does it have the record? Is the aa flag set?
4. Walk the tree: dig +trace example.com Is the delegation right? Does every listed name server answer?
5. Compare all name servers: dig +nssearch example.com Are the serials equal?
6. DNSSEC? dig example.com +cd works but plain fails Broken chain of trust
7. Network path? dig @ns1.example.com example.com +tcp ; nc -zv ns1.example.com 53 Is UDP or TCP 53 blocked? Does a big answer need TCP?
Symptom guide:
NXDOMAIN The name does not exist (a typo, a record missing, a wrong zone, a stale negative cache, or a delegation pointing at the wrong servers)
NOERROR with no answer (NODATA) The name exists, but not with that type (asking for AAAA on an IPv4-only host, or MX where there is none)
SERVFAIL The resolver failed: DNSSEC validation error, all name servers dead or lame, a broken CNAME loop. Test with +cd and +trace, and check the authoritative servers
REFUSED The server will not answer YOU: recursion disabled for your IP, an ACL, or you asked a resolver for a zone it does not serve. Try another server
"connection timed out; no servers could be reached" The server is unreachable or blocks you (firewall, wrong IP, UDP 53 dropped). Try +tcp , another server, and nc -zvu server 53 (or ping)
Truncated answer (tc flag), then works with +tcp Big response over UDP: check for firewalls that block TCP 53 or fragmentation (use +bufsize=1232)
Different answers from different resolvers Split-horizon DNS, geo/CDN answers, caches with different ages, a hijack, or an unsynced secondary
Correct answer from dig but the app fails Apps use the OS resolver (NSS, /etc/hosts, search domains, systemd-resolved, IPv6 preference), not dig. Compare with getent hosts name and resolvectl query name
Slow lookups Check the "Query time", a dead first server in /etc/resolv.conf (timeouts before the next), too many search domains, and reverse lookups
dig, nslookup, host and friends
dig The detailed tool: full output, every record type, trace, DNSSEC, precise control. The standard for troubleshooting and scripts (+short)
host A tiny friendly tool: host example.com host -t mx example.com host 203.0.113.10 (reverse). Good for quick answers, less detail
nslookup Older and available on Windows: nslookup example.com ; nslookup -type=MX example.com ; nslookup example.com 1.1.1.1. It is officially "deprecated" for Unix but still everywhere
drill From ldns: similar to dig with easy DNSSEC tracing (drill -T example.com)
delv BIND's DNSSEC-validating lookup: delv example.com
getent hosts Uses the SAME lookup path as applications (NSS: /etc/hosts, DNS, mDNS): getent hosts example.com
resolvectl systemd-resolved: resolvectl query example.com ; resolvectl status ; resolvectl statistics ; resolvectl flush-caches
whois Domain registration and IP ownership: whois example.com ; whois 203.0.113.10
Windows PowerShell: Resolve-DnsName example.com -Type MX -Server 1.1.1.1 (dig is available in WSL or as a download)
Practical one-liners
# What is my public IP address? (using DNS)
dig +short myip.opendns.com @resolver1.opendns.com ; dig +short TXT o-o.myaddr.l.google.com @ns1.google.com
# Who are the authoritative name servers, and are their SOA serials the same?
dig +nssearch example.com
# All the important records of a domain in one go
for t in A AAAA MX NS TXT SOA CAA; do echo "== $t"; dig +short example.com $t; done
# Email health check: MX, SPF, DMARC and reverse DNS of the first MX
d=example.com; dig +short MX $d; dig +short TXT $d | grep -i spf; dig +short TXT _dmarc.$d; mx=$(dig +short MX $d | sort -n | head -1 | awk '{print $2}'); dig +short A $mx; dig +short -x $(dig +short A $mx | head -1)
# Trace a name and show only the final answer plus which servers were used
dig +trace +nodnssec example.com | grep -E "^example.com|^;; Received"
# Compare the same name on several resolvers with timings
for r in 127.0.0.53 1.1.1.1 8.8.8.8 9.9.9.9; do printf '%-14s' $r; dig @$r example.com +noall +answer +stats | grep -E "IN A|Query time" | tr '\n' ' '; echo; done
# How long does a lookup take? (msec)
dig example.com | awk '/Query time/ {print $4 " ms"}'
# Where does a CNAME chain end?
dig +noall +answer example.com # shows each alias and the final A record in order
# Bulk reverse lookup of a list of IPs
while read -r ip; do printf '%s ' "$ip"; dig +short -x "$ip"; echo; done < ips.txt
# Find hosts in a zone you are allowed to transfer
dig @ns1.example.com example.com AXFR +noall +answer | awk '{print $1, $4, $5}'
# Is a domain using DNSSEC? (a DS record at the parent means yes)
dig +short DS example.com ; dig +short DNSKEY example.com | head -2
# Check certificate-related DNS: CAA, and the TLSA record for DANE
dig +short CAA example.com ; dig +short TLSA _443._tcp.example.com
# Test whether DNS over TLS to a resolver works
dig +tls @1.1.1.1 example.com +short
# Find which name servers a domain uses at its parent (the registrar's view)
dig +norecurse +noall +authority example.com @a.gtld-servers.net
# Watch a DNS change happen (poll every 10 seconds)
watch -n 10 'dig +short @ns1.example.com www.example.com ; dig +short @1.1.1.1 www.example.com'
# What version does an internal server report? (for your own servers)
dig @10.0.0.53 version.bind CH TXT +short
# What does the local resolver cache say vs the authoritative one, side by side
diff <(dig +short example.com) <(dig +short @ns1.example.com example.com)
Common problems
"connection timed out; no servers could be reached" UDP/TCP 53 is blocked or the server is down. Check the IP (dig @IP), the firewall, and /etc/resolv.conf
"dig: command not found" Install dnsutils (Debian/Ubuntu), bind-utils (RHEL family) or brew install bind
"couldn't get address for 'name': not found" / "no servers could be reached" with @name The @server you gave is a NAME that could not be resolved. Use its IP address
Output shows SERVER: 127.0.0.53 systemd-resolved is the local stub. Ask it (default) to see what apps see, or use @upstream to bypass it. resolvectl status shows the real upstream servers
+short prints nothing NXDOMAIN, NODATA, or a filtered answer. Remove +short and read the status and flags. Check the type and spelling
"Got answer" then "no servers" / different results each time Several name servers with different data (unsynced or load-balanced). Query each @ns and compare
";; Truncated, retrying in TCP mode." The UDP answer was too big. Normal, but if TCP fails, TCP 53 is blocked between you and the server
Works with dig but not in the browser or ping The application uses another path: /etc/hosts, mDNS, DoH inside the browser, a VPN resolver, or IPv6 preference. Compare with getent hosts and the browser's DNS settings
Old answer after I changed a record Caching: wait for the old TTL, query the authoritative server for the truth, and flush the resolver cache. Negative caching can hide a new record for a while
SERVFAIL from one resolver but fine from another DNSSEC validation differences, a lame or dead authoritative server that only some resolvers hit, or a resolver bug. Test with +cd, +trace and dig each NS
AXFR shows "Transfer failed" / REFUSED The zone transfer is not allowed from your IP (correct for public servers)
Names with underscores (_dmarc, _ldap._tcp) return nothing They are valid in DNS. Check the record TYPE (TXT for _dmarc and DKIM, SRV for _ldap._tcp) and the exact spelling
CNAME at the zone apex does not work A CNAME cannot coexist with other records (SOA, NS, MX) at the root of a zone. Use ALIAS/ANAME (provider feature) or A records
Reverse lookup returns a generic ISP name The PTR is owned by the IP's provider. Ask them to set it, or use a provider that lets you
Mail is rejected for missing or mismatched records Check PTR matches the mail hostname, the hostname has A/AAAA, SPF lists the sender, DKIM selector exists, and DMARC is syntactically valid (dig each)
Tips
Use +short for scripts and +noall +answer when you want to read the TTL and record type. Put +noall +answer in ~/.digrc for tidy output everywhere.
Ask the right server: your resolver shows what users see, a public resolver shows what the world sees, and the authoritative server (with +norecurse) shows the truth.
+trace ignores your resolver and its cache and walks from the root. If trace works and a normal query fails, the problem is your resolver.
Read the status and flags first: NXDOMAIN (no such name), NOERROR with no answer (no such type), SERVFAIL (a failure: try +cd for DNSSEC), REFUSED (not allowed).
Compare the SOA serial on every authoritative server (dig +nssearch) whenever answers differ between users.
For email problems, dig the MX, the SPF, DKIM and DMARC TXT records, and the PTR of the mail server's IP.
To change a record safely: lower the TTL a day earlier, change it, verify on the authoritative servers, and wait one old TTL. Flush your own caches when testing.
Use +tcp, +bufsize=1232 and +noedns to find firewall and fragmentation problems, and +tls or +https to test encrypted DNS.
dig shows what DNS says, not what an application does. If an app disagrees, compare with getent hosts, resolvectl query and /etc/hosts.
Only attempt AXFR zone transfers on servers you own or are authorized to test, and lock your own down.
