DNS Record Lookup
Query A, AAAA, CNAME, MX, NS, TXT, SOA, CAA and SRV records for any domain or subdomain: free, no signup, including the MX hosts that tell you which email provider a domain uses.
What is a DNS lookup?
A DNS lookup asks the domain name system what a name publishes: the addresses it resolves to, the mail hosts that receive its email, the name servers responsible for it, and the text records that carry things like SPF. It is the fastest way to confirm that a change you made in your DNS provider is actually visible to the rest of the internet, and the first place to look when mail or a website stops working.
How to read your result
| Result | What it means | What to do |
|---|---|---|
| Records found | The domain resolves, and every record type it publishes is listed in its own block. | Read each type against what you expect. A missing MX or SPF entry is the common email-affecting gap. |
| No records found | None of the nine types returned anything: usually an unregistered domain, a typo, or name servers that do not answer public queries. | Re-check the spelling, then confirm the domain's name servers respond. |
| Type present, others empty | The domain publishes some types and not others. An empty type is an intentional absence, not an error. | Nothing, unless a type you rely on is missing. Most domains legitimately publish no SRV or CAA records. |
| Some lookups could not be completed | A query returned a DNS error rather than an answer. The result names the record type and the error code. | Retry in a moment. A repeating error on one type usually points at the zone's configuration rather than the resolver. |
| No SPF record | The domain publishes no SPF policy, so receivers have no published list of who may send on its behalf. | Publish an SPF record covering every legitimate sending service, then verify it with the SPF checker. |
| No MX records | The domain publishes no mail host. Senders fall back to its A or AAAA record under RFC 5321's implicit MX rule, which is rarely a mail server. | Publish MX records for your mail provider, or a null MX if the domain is deliberately send-only. |
What this lookup can prove
The lookup proves what public DNS returns for the name you entered, read from a public resolver rather than your own network's. It reports records; it does not grade them. A record can resolve perfectly and still be wrong for your mail: an SPF policy that authorizes the wrong provider resolves exactly as cleanly as one that authorizes the right one.
Two limits are worth knowing. DMARC is not published on your domain, so it never appears here: it lives at _dmarc.yourdomain.com, and the DMARC checker reads and validates it. And a lookup shows the current published state only, so it cannot tell you what changed, when, or who changed it.
From reading records to keeping them right
A lookup is a snapshot. The records that decide whether your mail is trusted drift constantly: a team signs up for a new sending tool, a provider changes its SPF include, a DKIM key rotates. Palisade turns DMARC aggregate reports into a prioritized workflow so operators can identify every sender using the domain, investigate alignment failures, review proposed record changes, and move each domain toward enforcement with evidence.
For MSPs it's built multi-tenant: every client domain checked, remediated, and enforced from one console, with portfolio-based per-client-domain pricing whose rate improves as you scale, without metering client email volume.
Related checks and terms
DMARC software that does the work
Palisade organizes DMARC report evidence into prioritized sender and alignment work, helping operators review changes and move domains toward enforcement from one console.
1 domain free up to 1,000 emails/month
Email authentication knowledge base
Which DNS records does this lookup check?
Nine record types in one query: A and AAAA (the IPv4 and IPv6 addresses a name resolves to), CNAME (an alias pointing at another name), MX (the mail hosts that receive email for the domain), NS (the authoritative name servers), TXT (free-form text, which is where SPF and domain verification strings live), SOA (the zone's administrative record), CAA (which certificate authorities may issue for the domain), and SRV (service location records).
How do I find out which mail server a domain uses?
Look at the MX rows in the result. They name the hosts that accept mail for the domain, in preference order, which is how you identify whether a domain receives mail through Google Workspace, Microsoft 365, or another provider. If you only care about mail routing, the dedicated MX checker reports the same records with the null-MX and missing-record cases called out explicitly.
Does this tool check my DMARC record?
No, and this trips people up. A DMARC record is not published on your domain itself. It lives at the separate host _dmarc.yourdomain.com, so it does not appear in a lookup of the root domain. Use the DMARC checker for that, or enter _dmarc.yourdomain.com as the domain here to see the raw TXT record.
Which DNS resolvers does this lookup use?
Lookups resolve through Google's public resolver at 8.8.8.8, with Cloudflare's 1.1.1.1 as a fallback if that does not answer. Going through a well-known public resolver means you see roughly what an independent third party on the internet sees, rather than what your own network's resolver has cached or filtered.
What does it mean when no records are found?
Either the domain is not registered, its name servers are not answering public queries, or it genuinely publishes none of the nine types checked. Check the spelling first: a typo is by far the most common cause. If the spelling is right and the domain should exist, the problem is usually at the name servers rather than in the individual records.
Why do some record types come back empty while others work?
An empty result for one type means the domain publishes nothing of that type, which is normal. Most domains have no SRV or CAA records at all. That is reported separately from a lookup that actually failed: if a query errors, the result names the type and the DNS error code so you can tell a real failure from an intentional absence.
Why don't my recent DNS changes show up?
Resolvers cache answers for as long as the record's TTL allows, so a change is invisible to anyone holding an unexpired cached copy. Until those expire, some senders and visitors still act on the old value. Keep the previous configuration working until the change has fully rolled out.
Can I look up a subdomain?
Yes. Subdomains are accepted, so you can query mail.example.com or selector1._domainkey.example.com directly. That is the practical way to read a DKIM key, since DKIM records are always published under a selector rather than on the root domain.
Does a DNS lookup tell me whether my email will be delivered?
It tells you what your domain publishes, which is a precondition for delivery, not a prediction of it. A domain can have flawless DNS and still land in spam because of its sending reputation, its content, or an unauthenticated sender. Publishing correct records is the part you control from DNS; the rest is settled by authentication and reputation.
Every tag and mechanism across DMARC, SPF, and DKIM, explained in one place.
DMARC
- vVersion
- The Version tag is essential in a DMARC record and must strictly be set to ‘DMARC1’. If this value is not correctly specified or if the tag is absent, the DMARC record will not be considered valid and will be disregarded.
- pDMARC policy
- The DMARC policy setting is crucial and accepts three possible values: ‘none’, ‘quarantine’, or ‘reject’. By default, it is set to ‘none’, which means it doesn’t actively intervene with emails that fail authentication. This setting primarily serves to gather DMARC reports, aiding in understanding the existing email traffic and its authentication status. On the other hand, the ‘quarantine’ option flags unauthenticated emails as dubious, and ‘reject’ outright prevents their delivery.
- ruaAggregate report destination
- The destination for sending aggregate reports is specified using a ‘mailto:’ URI, which Email Service Providers (ESPs) utilize to dispatch failure reports. While this tag is not mandatory, omitting it means you will not receive any reports.
- rufForensic report destination
- The destination for Forensic (Failure) report transmission is designated by a ‘mailto:’ URI, which is employed by Email Service Providers (ESPs) for the delivery of failure reports. Although this tag is not obligatory, failing to include it will result in not receiving any reports.
- spSubdomain policy
- The policy for subdomains defaults to inheriting the main domain’s policy tag (p=), as previously described, unless explicitly stated otherwise. Similar to the domain policy, the permissible values for subdomains are ‘none’, ‘quarantine’, or ‘reject’. However, this option is not commonly employed in current practices.
- adkimDKIM alignment
- The alignment of the DKIM signature, indicated by this tag, refers to the congruence between the DKIM domain and the originating domain in the ‘Header From’. The acceptable values for this tag are ‘r’ for relaxed and ‘s’ for strict. The default setting, ‘r’, permits a partial match between these domains, whereas the ‘s’ setting demands an exact match of the domains.
- aspfSPF alignment
- This tag pertains to the SPF alignment, which concerns the compatibility between the SPF domain (the sender) and the domain in the ‘Header From’. It allows two settings: ‘r’ for relaxed and ‘s’ for strict. By default, it is set to ‘r’, which tolerates a partial match between the domains. In contrast, the ‘s’ setting necessitates an exact correspondence of the domains.
- foForensic reporting options
- The options for forensic reporting include ‘0’, ‘1’, ‘d’, and ‘s’. The default setting is ‘0’, which triggers a forensic report only when both SPF and DKIM alignments do not pass. Use ‘1’ if the outcome of either SPF or DKIM is anything other than a pass. The option ‘d’ is selected to generate a report specifically for DKIM validation failures, and ‘s’ is used for SPF-related issues. To actually receive these forensic reports, it’s necessary to specify the ‘ruf’ tag.
- rfFailure report format
- The format for failure report generation can be set to either ‘afrf’ or ‘iodef’, as these are the two permissible options.
- pctPercentage (historic)
- The legacy Percentage tag asked receivers to apply a quarantine or reject policy to only part of the mail that failed DMARC. RFC 9989 removed pct because receivers implemented partial enforcement inconsistently. New records should omit it and stage rollout with aggregate reports, whole-policy changes, and low-volume subdomains.
- riReporting interval
- The Reporting interval specifies how often XML reports are received, measured in seconds. The standard setting is 86400 seconds, which equates to daily reporting. However, it’s important to note that despite the specified interval, Internet Service Providers (ISPs) typically send these reports on their own schedules, which in most cases, is also once a day.
SPF
- v
- The version tag must exclusively be “spf1”. Incorrect or missing versions result in the SPF record being disregarded.
- ip4
- This tag lists IPv4 addresses authorized to send emails for the domain.
- ip6
- This tag specifies IPv6 addresses permitted to email on the domain’s behalf.
- a
- The A record tag permits sender validation via the domain’s IP address, defaulting to the current domain if unspecified.
- mx
- The MX record tag validates the mail server’s MX record, defaulting to the current domain if not specified.
- ptr
- The PTR tag initiates a PTR check for client IP hostnames, advised against in RFC 7208 due to excessive DNS lookups.
- exists
- The exists tag verifies the presence of an A record on the specified domain.
- include
- The include tag is crucial for accurate SPF records, confirming all listed domains/subdomains as legitimate sending sources to recipients.
- all
- The all tag is mandatory, positioned at the SPF record’s end, guiding recipients on handling emails from unauthorized sources based on its qualifiers (~, +, -, ?).
DKIM
- v
- The version tag specifies DKIM’s version, consistently required to be 1.
- p
- The public key tag, a character string created in DKIM setup, must not be left empty to remain valid.
- t
- This tag enumerates flags as a colon-separated sequence, with “y” and “s” as defined flags; any undefined flags should be disregarded.
- s
- This tag details service types relevant to the record. Absent or unrecognized service types must be overlooked by receiving servers.
- h
- This tag specifies permitted hash algorithms, defaulting to allow all. Receivers should ignore unknown algorithms, with the sender determining the list’s entries.
- n
- This tag serves as an optional note field for administrators, recommended for use only when needed.