Email DNS Checker – MX, SPF, DKIM & DMARC

How the Email DNS & Reputation Checker Works

The Utiliverse Email DNS & Reputation Checker combines several DNS-based diagnostics that are normally investigated separately when troubleshooting business email. Enter a domain and the tool checks its Mail Exchanger (MX) records, Sender Policy Framework (SPF) record, Domain-based Message Authentication, Reporting and Conformance (DMARC) policy, likely DomainKeys Identified Mail (DKIM) public-key selectors, and the public IP addresses associated with the domain's MX hosts. Those mail-server IPs are then prepared for reputation and blocklist verification through established external services.

The results describe published DNS configuration rather than certifying that every message from the domain will be delivered. Modern filtering combines authentication with IP and domain reputation, complaint history, content, sending behavior, recipient engagement, connection quality, local policy, and other signals. A domain can have technically correct SPF, DKIM, and DMARC records and still experience delivery problems.

MX records and inbound mail routing

SMTP normally uses DNS MX records to discover the servers responsible for accepting mail for a domain. Each MX record contains a preference number and a mail exchanger hostname; lower values are preferred. Multiple records can provide resilience or distribute traffic. The checker sorts visible MX records and resolves their A and AAAA addresses so you can see which public IPs are associated with the mail infrastructure.

A domain without an explicit MX record is not automatically equivalent to broken mail. SMTP defines an implicit MX fallback to the domain's address records when no MX exists. Modern deployments normally use explicit MX records, so Utiliverse reports an implicit fallback as a warning. A null MX, represented by preference zero and a dot target, has a different meaning: it explicitly indicates that the domain does not accept email.

SPF and the 10-DNS-lookup limit

SPF is published in a DNS TXT record beginning with v=spf1. It describes which hosts are authorized to use a domain for SMTP identities such as MAIL FROM. The specification permits only one applicable SPF record at a given owner name; multiple SPF records produce a permanent error. The checker therefore distinguishes a single record from missing or duplicate policies.

The tool also estimates DNS-query-causing SPF terms. SPF evaluation is limited to ten DNS lookups for mechanisms and modifiers including include, a, mx, exists, ptr, and redirect. Where ordinary include or redirect targets can be followed, Utiliverse recursively queries their SPF records and adds them to the estimate. Complex macros can make a browser-side estimate incomplete, so the number is a diagnostic aid rather than a replacement for a receiving mail server's complete SPF evaluator.

The ending qualifier matters as well. -all expresses hard fail for otherwise unauthorized senders, while ~all is softfail. ?all is neutral, and +all authorizes every sender and therefore defeats the normal authorization purpose of SPF.

DKIM public keys and selectors

DKIM allows a sending system to attach a cryptographic signature to an email. The public key used by receivers is stored in DNS under a selector. If a signature uses d=example.com and s=selector1, a receiver looks for a TXT record at selector1._domainkey.example.com. Some providers publish a CNAME at the selector and host the final public key elsewhere, so this checker follows a visible CNAME before looking for the TXT key.

There is no universal DNS query that lists every DKIM selector a domain has published. Selectors are chosen by the sender and are normally learned from a DKIM-Signature header or the provider's configuration. Utiliverse tests several common names and lets you enter selectors you know. If no key is found and no known selector is provided, the result is marked incomplete rather than falsely claiming that the domain does not use DKIM.

DMARC policy and alignment

DMARC policy is published under _dmarc. A record begins with v=DMARC1 and normally contains a p policy. p=none is primarily a monitoring posture; it requests reporting without asking receivers to quarantine or reject a message simply because it fails DMARC. p=quarantine asks participating receivers to treat failing mail as suspicious, while p=reject requests rejection.

DMARC also depends on identifier alignment. It is not enough that SPF or DKIM passes in isolation; an authenticated identifier must align with the visible From domain according to the policy. Tags such as adkim and aspf control strict or relaxed alignment, and rua identifies destinations for aggregate reports. This tool displays those fields when present but does not send messages or generate DMARC reports.

Blacklist posture without misleading results

Email blocklists are difficult to test responsibly from a static browser application. Many DNS-based blocklists deliberately restrict queries through public recursive resolvers. Spamhaus documents restricted behavior and special error codes for public/open resolvers, while other reputation services can require resolver registration or API credentials. A browser application that treats a blocked lookup as “clean” can produce a dangerous false result.

Utiliverse therefore takes a conservative approach. It discovers the IP addresses behind MX hosts and creates direct links to Spamhaus Reputation Checker, Cisco Talos Reputation Center, and MXToolbox for each address. Those services can return their current reputation view under their own access rules. Blacklist posture is intentionally separated from the DNS configuration score.

Practical Use Cases

Troubleshooting mail that is rejected or going to spam

When legitimate mail begins bouncing or being filtered, start by confirming that the sending domain's authentication records are present and coherent. The combined view can expose a missing SPF record, duplicate SPF policies, DMARC still set to monitoring, or a DKIM selector that is not publishing a public key. Reputation links can then be used to investigate the mail-server IPs separately.

Reviewing Microsoft 365, Google Workspace, or hosted-email migrations

Moving email platforms often changes MX records, SPF includes, and DKIM selectors. Administrators can run the checker after DNS changes to confirm what a public resolver currently sees. Because DNS records are cached according to TTL, different resolvers can temporarily see different versions during a migration; a successful lookup here confirms the Google Public DNS view at that moment, not universal propagation.

Preparing for stronger DMARC enforcement

A domain moving from p=none toward quarantine or reject should first identify legitimate sending sources and verify that they authenticate and align correctly. This tool can confirm the published policy and basic DNS posture, while aggregate DMARC reports remain essential for understanding real-world traffic before tightening enforcement.

Auditing third-party senders

Organizations frequently send through corporate mail, CRMs, ticketing platforms, payroll systems, marketing services, and transactional applications. SPF include chains can become long, and different providers may use different DKIM selectors. The checker helps inventory the public DNS side of that setup and highlights when an SPF lookup estimate approaches the protocol limit.

Frequently Asked Questions