Inboxlogy Free Tools
DNS Record Checker
See every DNS record for any domain in one click — A, AAAA, MX, TXT, NS and CNAME, straight from live public DNS.
How it works
Enter any domain
Type the domain or subdomain you want to inspect. Records are name-specific, so example.com and mail.example.com can return completely different answers. Use the exact name your mail or sending platform points at.
Every type queried at once
We query A, AAAA, MX, TXT, NS and CNAME in one pass against live public resolvers, so you get the whole picture without running six separate lookups or trusting a stale snapshot from somewhere else.
Review values and TTLs
Results show each record's value and its TTL in seconds, which tells you how long resolvers will keep serving the answer after you change it. The TXT output is where SPF, DMARC and DKIM strings appear for review.
Which DNS records matter for email
Four record types carry almost all email configuration. MX names the hosts that accept your inbound mail, in preference order. TXT holds your SPF record, your DMARC policy at _dmarc.yourdomain.com, and your DKIM public keys at selector._domainkey.yourdomain.com. A and AAAA map hostnames to IPv4 and IPv6 addresses, which matters because an MX target must resolve to one of them. CNAME aliases one name to another, and providers use it to host DKIM keys for you.
TTL is the part people misread. There is no propagation, only caching. A record's TTL tells every resolver how many seconds it may reuse the answer, so a change becomes visible as caches expire, up to that TTL. Drop the TTL to 300 a day before a migration, make the change, then raise it again. Negative answers cache too, governed by the SOA minimum, so one early failed lookup can linger after you fix the record.
Common mistakes
Putting a CNAME at the domain root
A CNAME cannot coexist with other records on the same name, and the root already has NS and SOA records. Doing it anyway breaks MX and TXT resolution, which kills mail and authentication. Use your provider's ALIAS or a flattened A record instead.
Editing DNS at the wrong provider
A domain's live records come from the nameservers in its NS records, which may not be the registrar you logged into. Changes made in an unused panel look saved and do nothing. Check the NS records first, then edit the zone they point to.
Splitting one value across two records
Long values must be split into multiple strings inside a single TXT record, not into two separate records on the same name. Two records means two independent values, which produces a duplicate SPF permerror or an unparseable DKIM key.
Changing records with a long TTL
A record cached at 86400 seconds can keep serving the old value for a full day after you edit it, including an MX pointing at a provider you just left. Lower TTLs before planned changes, not after you notice mail going missing.
Frequently asked questions
How long do DNS changes take to go live?
Up to the old record's TTL. Authoritative nameservers serve the new value immediately, but resolvers that already cached the old one keep using it until their copy expires. With a TTL of 3600 that is an hour; with 86400 it is a day. To verify without waiting, query the domain's authoritative nameserver directly instead of a public resolver.
Which DNS records do I need to send cold email?
An SPF TXT record, a DKIM TXT record at your selector, a DMARC TXT record at _dmarc, and an MX record so the domain can receive replies and bounces. An A record for any tracking or redirect subdomain is worth adding too. Google and Microsoft both tightened requirements on bulk senders, and a missing DMARC record is the most common gap.
Why do two DNS checkers show different results?
Because they are reading different caches. Public resolvers hold records independently and expire them at different moments, so one may still serve a value you deleted ten minutes ago. When answers disagree, query the authoritative nameservers listed in the domain's NS records. That is the source of truth; everything else is a copy with a countdown on it.
Can I have two TXT records on the same name?
Yes, and often you must. A single name can hold many TXT records, which is how a domain carries verification strings from several vendors at once. The exception is SPF: only one record on a name may start with v=spf1, because two make the check a permanent error. Keep unrelated TXT records separate rather than merging them.
What is the difference between a CNAME and an A record?
An A record maps a name straight to an IPv4 address. A CNAME maps a name to another name, which the resolver then looks up in turn. CNAMEs are useful when a provider changes IPs, since you never have to update anything yourself. They cannot be used at the domain root and cannot sit alongside other records on the same name.