Skip to content
Clinic open · free diagnosis, no appointment needed2,000+ domains monitored

Reverse DNS check

Checks the PTR records of the mail servers you publish, and confirms they resolve back again, which is what receivers actually test.

Judged against RFC 1912 section 2.1

Free, instant, no signup. This test reads your live DNS the way a receiving server does.

Symptoms

Mail from your own server gets rejected outright with a message about reverse DNS, or lands in spam no matter how clean your SPF and DKIM are. The rejections often name it explicitly, Gmail returns a 550 that says so, which makes this one of the few email faults that tells you exactly what is wrong.

Diagnosis

When your server connects to deliver mail, the receiver sees an IP address before it sees anything else. The first thing it does is ask what that address is called, and then check that the name agrees.

  • No PTR at all, the address has no name. Many receivers stop there.
  • PTR that does not round-trip, the name exists but points somewhere else, which reads as misconfiguration or forgery.
  • A generic provider name. It resolves correctly, and it signals an unmanaged machine.

We only judge addresses you publish as your own: MX hosts inside your zone, and your apex address when your SPF names it with an a mechanism. If you send through a provider, their IPs are their business and we say so rather than inventing a problem.

Cure

  1. Find who controls the IP. Usually your cloud or hosting provider, in a panel labelled reverse DNS or PTR.
  2. Set it to a hostname you own, such as mail.yourdomain.com.
  3. Publish an A record for that hostname pointing back at the same IP. Both halves, or the check still fails.
  4. Use the same name your server introduces itself as in its SMTP greeting, so everything agrees.

Questions people actually ask

What is forward-confirmed reverse DNS?

The IP has a PTR record naming a host, and that host has an A record pointing back to the same IP. Both directions must agree. Strict receivers treat a reverse record that does not round-trip as no reverse record at all.

Who sets a PTR record?

Whoever controls the IP address, your hosting or cloud provider, not your DNS registrar. It is the one email record you usually cannot set yourself.

Why does this test say there is nothing to check?

Because every server you publish belongs to someone else. If your MX points at a provider, their reverse DNS is their responsibility and they get it right. We only judge machines inside your own zone.

Does a generic PTR hurt deliverability?

Mildly, and consistently. A hostname like ec2-203-0-113-10.compute.amazonaws.com resolves fine and tells filters that nobody configured this machine deliberately. Naming it after your own domain costs nothing.

Related tests

Every fix on this site is yours to implement. If you would rather someone did it, I take this work directly.