Free, no sign-up

A DNS Record Check plus email health

You get the A, AAAA, CNAME, NS, MX, TXT and SOA records with their TTLs, and above them a standalone check on the three records that decide whether your email reaches the inbox or the spam folder.

  • No sign-up
  • SPF and DMARC check
  • TTL shown per record

Run the tool right here on the page

Every DNS record of the domain, together with the SPF and DMARC checks that decide whether your email ends up in the spam folder.

  • What it costs Free
  • Data source Our own server
  • Access No sign-up

This tool executes on our own infrastructure with no purchased data behind it, so it costs nothing and stays that way. Its only limit is a daily cap that stops one bot from taking the whole capacity. The daily cap is measured per visitor. If you need more, a free account lifts your limit.

The short answer

DNS records set which server your domain name resolves to and where your email may be sent from. If your site's emails land in spam, the cause is almost always a missing or badly written SPF or DMARC record.

SPF states which servers are entitled to send mail under your domain name. With no such record, the destination server cannot judge whether a message posing as info@ your domain is genuine, so it acts cautiously and files it under spam. DMARC is the next layer: it instructs the destination server on what to do with a message that fails this check.

The TTL value is also worth a look, usually noticed only once the moment has passed. TTL is the number of seconds DNS servers worldwide hold the previous answer in memory. Before a host migration, lower the A-record TTL a day in advance; without that step, some users may keep hitting the old server for hours after the switch.

The NS record carries its own point: the place your domain's DNS is administered is not always the place the site is hosted. On projects that several people have worked on, the two have almost always separated. If you changed a setting in the hosting panel and saw no effect, the right question is where this domain's DNS is actually managed.

The data source and method

A direct DNS query from our server. Keep in mind the answer can differ from what you see inside Iran, because some services reply differently to different IPs. DKIM is not checked here, because its selector hangs on your mail service and without the selector we cannot honestly state whether it is present.

The situations where it helps

After a host migration, to verify the records carried over correctly. Or when your site's emails go to spam, which nearly always means SPF or DMARC is absent.

Where it falls short

DKIM is not checked here, and that is deliberate. DKIM is read through a selector that depends on your email service, and without knowing that selector nobody can honestly say whether the record exists. Your own email service panel is where to look. The second limitation is technical: the lookup runs from our server, and some DNS services answer different IPs differently, so what you see here may not match what a visitor inside Iran gets.

A lesson from working with it

The most common SPF mistake is having two SPF records, not having none. A client adds a new email service, drops the new record next to the old one, and the standard says a domain with more than one SPF record fails the test. That is worse than before the setup. If you see two lines starting with v=spf1, they must be merged into one.

What it costs

This tool executes on our own infrastructure with no purchased data behind it, so it costs nothing and stays that way. Its only limit is a daily cap that stops one bot from taking the whole capacity.

The daily cap is measured per visitor. If you need more, a free account lifts your limit.

Common questions about this tool

How long does a DNS change take to apply?

There is no fixed number; it is tied to that record's TTL. Until that window closes, servers that cached the earlier answer keep handing it out. Which is why the right order is to lower the TTL first and change the record afterwards, ahead of any planned change.

What is the minimum correct setup so site email does not land in spam?

Three records: a correct MX aimed at your real email service, an SPF that declares that service authorised, and a DMARC, even at a policy of none. The third only reports and blocks nothing, and it is enough to begin with.

Where is my domain DNS?

The NS records in this output answer that. Those names show which DNS service holds the domain; that is where you sign in to change a record.