DNS and email checker

Type the domain into the box above. We ask two public resolvers, Cloudflare (1.1.1.1) and Google Public DNS (8.8.8.8), for its A, AAAA, CNAME, MX, NS, TXT, SOA and CAA records and show each answer with its TTL, the number of seconds resolvers may keep it before asking again. On your own computer, nslookup -type=MX example.com or dig example.com MX does the same for one record type.

The most common technical causes are a missing or broken SPF record, no DKIM signature, no DMARC record, or an SPF record that needs more than 10 DNS lookups. The checker above tests all four. If they all pass, the cause is usually reputation or content: a new domain or IP address, a sudden jump in volume, many complaints, links to domains with a bad reputation, or a list with old addresses that bounce.

SPF lists the servers that may send mail for your domain. DKIM adds a signature to each message that the receiver checks against a public key in your DNS, which proves the message was not changed and came from you. DMARC ties them together: it tells receivers what to do when a message fails both (nothing, spam folder or reject) and where to send reports. You need all three for reliable delivery to Gmail, Yahoo and Outlook.

Open an email you sent from the domain and view the original message or the full headers (Gmail: the three dots, then Show original). Find the DKIM-Signature header: the selector is the value after s=, and d= is the signing domain. Enter that selector in the optional box above. Google Workspace uses google by default and Microsoft 365 uses selector1 and selector2, which we always try.

An SPF check may make at most 10 DNS lookups. Every include:, a, mx, ptr, exists and redirect costs one, and so does every one of those inside the records you include. Go over 10 and receivers return a permanent error, which counts as an SPF failure. Remove services you no longer use, or replace a and mx with ip4: and ip6: ranges.

Both are fine with DMARC in place. ~all (soft fail) marks mail from unlisted servers as suspicious and -all (fail) asks for it to be rejected. Most providers recommend ~all, because DMARC then decides what happens. Never use +all: it allows anyone to send as your domain.

p=none meets the minimum that Gmail and Yahoo ask of bulk senders, and it is the right first step because you start receiving reports. It does not protect you: mail that spoofs your domain is still delivered. Once the reports show your real mail passing SPF or DKIM, move to p=quarantine and then p=reject.

There is no single propagation time. Each resolver keeps an old answer until its TTL runs out, so a record with a TTL of 3600 can take up to an hour to change everywhere, and a nameserver change at the registrar can take a day or two. Lower the TTL a day before a planned change to make it faster.

No. We compare two large public resolvers, Cloudflare and Google, which is enough to tell whether a change has reached them. Other resolvers, such as your internet provider's, may still hold an older answer until its TTL expires. We do not run servers in many countries, so we do not claim a worldwide view.

A CAA record lists the certificate authorities that may issue SSL certificates for the domain, such as letsencrypt.org or digicert.com. With no CAA record any authority may issue one, which is the default and works. If you add CAA, include every authority you use, or certificate renewals will fail.