Skip to content
IPGet

Security Tools

Email DNS Checker

The four DNS records that decide whether your mail is delivered — and whether others can send as you.

Email DNS check

A domain name only. DKIM is checked only if you supply a selector — it cannot be discovered from DNS.

Try:

The four records, and what each one does

Email authentication is four DNS records that answer four different questions. They are frequently discussed as one thing, and the confusion is the source of most misconfiguration.

MX says where mail to your domain should be delivered. It has nothing to do with sending, and a domain can send mail with no MX record at all.

SPF is a TXT record listing which servers may send as your domain. It is checked against the envelope sender, not the From: header a recipient sees — which is why SPF alone does not stop display-name spoofing.

DKIM publishes a public key so receivers can verify a signature added by your sending server. The key lives at selector._domainkey.yourdomain, and the selector is an arbitrary label chosen by whoever sends your mail. There is no way to enumerate selectors from DNS, which is why this tool asks for one.

DMARC ties the first three together. It tells receivers what to do when SPF and DKIM fail, and where to send reports. Without it, SPF and DKIM failures are advisory and each receiver decides for itself.

The ten-lookup limit

The most common way a working SPF record breaks is growth. Every include:, a, mx, ptr and exists mechanism costs a DNS lookup, counted recursively through everything you include. RFC 7208 caps the total at ten.

Exceeding it does not weaken the record — it invalidates it. Receivers return a permanent error and treat the domain as having no SPF, which means mail that was passing yesterday can start failing today because a vendor added an include to their record. Nothing warns you, and the symptom appears at recipients rather than at you.

This is why the lookup count is shown as a number out of ten rather than buried in a pass or fail. A record at eight or nine is working and fragile, and that is worth knowing before it breaks.

What a grade can and cannot mean

The grade summarises what these records say. It is deliberately coarse — four bands, not a score out of a hundred — because a more precise-looking number would imply a precision this data does not support.

It cannot tell you whether mail actually delivers, whether your MX hosts accept connections, whether signatures verify, or whether any receiver enforces your policy. Those need SMTP connections, real messages and receiver cooperation. A domain can hold every record here and still have its mail rejected for reputation reasons that DNS knows nothing about.

Frequently asked questions

What does this tool actually check?

Four public DNS records: MX (where mail for the domain should be delivered), SPF (which servers may send as the domain), DKIM (the public key used to verify signatures, if you supply a selector) and DMARC (what receivers should do when the first two fail). It reads DNS and nothing else — it sends no email, opens no SMTP connection and stores no domain.

Why does the SPF lookup count matter so much?

RFC 7208 caps SPF evaluation at ten DNS-querying mechanisms, counted through every include. Past that, the record does not merely degrade — it becomes a permanent error, and receivers treat the domain as having no usable SPF at all. Records drift over the limit as services are added, and nothing warns you. This is the single most common way a working SPF setup quietly stops working.

Where do I find my DKIM selector?

In the DKIM settings of whoever sends your mail, or in the DKIM-Signature header of a message you have sent, as the s= value. There is no way to discover it from DNS: a selector is an arbitrary label, and querying without one tells you nothing. Common defaults are google, selector1 and selector2 for Microsoft 365, and k1 for several marketing platforms.

My DMARC policy is p=none. Is that bad?

It is a monitoring setting rather than a mistake. p=none asks receivers to take no action and, with a rua address, to send reports. That is the correct first step: you learn what is failing before you start rejecting mail. It becomes a problem when it stays that way for years, or when there is no rua address — then nobody is receiving the reports and the record accomplishes nothing at all.

Does a good grade mean my email is secure?

No, and the grade is deliberately not phrased that way. It describes what four DNS records say. It cannot know whether your mail actually delivers, whether the servers in your MX records accept connections, whether DKIM signatures verify, or whether receivers enforce your policy. A domain with a perfect DMARC record and a compromised mailbox is not secure, and this tool has no way to tell.

Why does the tool say "at least" a number of lookups?

Because counting SPF lookups means following include chains, and every request here shares one hard query budget so that a sprawling record cannot cost unbounded DNS traffic. When the budget runs out before the chain does, the count is reported as a floor rather than as a number that might be too low — under-counting would tell you a record is fine when it is over the limit.

Related tools