Patchkit

Free tool

PTR Checker

Check the reverse DNS of the IP your mail goes out from: its PTR name, and whether that name resolves back to the same IP, as Gmail requires.

For a domain we check its MX servers, which receive its mail. The servers that send it are often different, especially with a hosted mailbox or a sending service. To check your sending IP, enter it directly: the Email header analyzer shows the delivery path of a message you sent, and the sending server's IP is in the first hop outside your own network. The sending domain is optional; with it we also compare the PTR name with that domain.

By Ahmet Karaca · Updated · Checked against Google's email sender guidelines, RFC 1912 (common DNS errors), RFC 5321 (SMTP) and RFC 7505 (null MX) on

What reverse DNS is

Ordinary DNS turns a name into an address. Reverse DNS goes the other way: a PTR record, published in a special zone for the address, turns an IP into a name. When a mail server connects, the receiving server can look up the connecting IP's PTR record to learn which host claims it. Receivers use that answer as one of the signals about who is sending, and some refuse mail from an address without one.

Forward-confirmed reverse DNS

Anyone who controls an address can write any name into its PTR record, including a name they don't own. The check that means something is the round trip: look up the PTR name, then look up that name's A record (AAAA for IPv6) and see whether it includes the original IP. When it does, the reverse DNS is forward-confirmed, often called FCrDNS. When it doesn't, we report a mismatch.

What Gmail requires

Google's sender guidelines apply to everyone who sends to Gmail, not only to bulk senders. They require the public IP of a sending server to have a PTR record that resolves to a hostname, and that hostname to have an A or AAAA record that resolves to the same IP. A missing PTR record or a name that doesn't resolve back is reported as a problem for an IP you enter.

IP or domain: what to enter

Gmail's requirement is about the IP your mail goes out from, so that is the address to check. Enter it if you know it; the Email header analyzer shows the delivery path of a message you sent, and the sending server's IP is in the first hop outside your own network.

For a domain we check its MX servers, the servers that receive its mail. A domain's MX servers often aren't its sending servers, especially when you use a hosted mailbox or a separate sending service, so a problem there is reported as a warning about the receiving server rather than as a sending problem. When a domain has no MX record we check the address of the domain itself, as RFC 5321 describes, and when it publishes a null MX (RFC 7505) we say so and check nothing. At most 8 IPv4 and 8 IPv6 addresses are checked per domain, in MX priority order.

Generic-looking names

Home and mobile connections usually get automatic PTR names built from the address, like 203-0-113-7.dsl.example.net. We flag a name as generic when it contains the IP address itself (its numbers in order or reversed, or for IPv6 its hexadecimal form, written out or with dashes in place of colons), or one of these words as a separate part of the name: dynamic, dyn, pool, dsl, dhcp, cable, ppp, broadband, residential, client. The registered domain itself is left out, so a provider whose name happens to contain one of the words isn't flagged. This is a heuristic, not a rule, and the result says so: it is a note, not an error.

Alignment with your sending domain

If you enter the domain you send from, we compare each forward-confirmed PTR name with it, using the public suffix list to find the organizational domain of both. A name under your own domain is good practice, but not a requirement: shared sending services use their own names, and that is fine as long as the name resolves back to the IP. A name that isn't forward-confirmed is never compared, because its owner could have written anything into it.

What this tool checks

  • The PTR record of a public IPv4 or IPv6 address you enter, or of a domain's MX servers.
  • Whether each PTR name resolves back to the same IP. We show and check up to 2 names per address, and report any address with more than one PTR record, because receivers usually look at only one.
  • Whether a name looks generic, and, when you enter a sending domain, whether it is under that domain.

To keep a check quick, we confirm at most 16 PTR names per check; an address past that limit shows no forward-confirmation result and the report says why. A DNS answer that doesn't arrive in time is shown as couldn't check, never as a pass or a fail.

What it doesn't check

  • The HELO or EHLO name your server announces, which needs an SMTP connection on port 25.
  • Private and reserved addresses, which have no public reverse DNS.
  • The servers a domain sends from, unless you enter their IP: a domain check covers its MX servers only.
  • Blocklists: the Blacklist checker looks the same address up in public DNS blocklists.

Wondering what else the big providers expect? Gmail, Yahoo and Outlook sender requirements lists what each one checks.

Related tools and guides

Frequently asked questions

+Should I enter an IP address or a domain?

Enter the IP address your mail goes out from: that is the address receivers look up. For a domain we check its MX servers, which receive its mail. They are often not the servers that send it, especially with a hosted mailbox or a separate sending service. The sending IP is in the Received headers of a message you sent: the email header analyzer shows the delivery path, and the sending server's IP is in the first hop outside your own network.

+Does Gmail require a PTR record?

Yes. Google's sender guidelines ask every sender to have valid forward and reverse DNS for its sending IPs: the IP's PTR record must name a host, and that host's A record (AAAA for IPv6) must resolve back to the same IP. A PTR record that points to a name without that address doesn't meet the requirement.

+Does the PTR name have to be under my own domain?

No. Matching your sending domain is good practice, not a requirement. Many providers send from their own names, which is fine as long as the name resolves back to the IP. If you enter a sending domain, we compare it with each forward-confirmed PTR name and report the result as a note.

+Why is my PTR name flagged as generic?

The name contains the IP address itself or a word that consumer connections often use, such as dsl, pool or dynamic. This is a heuristic, not a rule: some receivers treat names like this more harshly, and a generic name isn't an error. A name under your own domain, like mail.yourdomain.com, avoids the question.

+Why isn't the HELO name checked?

Reading the name a server announces in HELO or EHLO needs an SMTP connection to that server, and outgoing connections on port 25 aren't reliable from where this tool runs. The result lists HELO under Not checked instead of guessing.

+How do I set or fix a PTR record?

A PTR record lives in the reverse DNS zone of the IP address, which belongs to whoever owns the address: your hosting provider, cloud provider or ISP. You can't add it in your domain's DNS. Most providers let you set it in their control panel or through a support request; set it to a name whose A or AAAA record points back to the same IP.

We use Google Analytics cookies only if you accept. Privacy policy