What a PTR record is, and why mail servers check it

A PTR record (pointer record) answers the question "what hostname owns this IP address?" It is the reverse of an A record, which answers "what IP address does this hostname point to?" Mail servers check both directions and compare them - a practice usually called FCrDNS (forward-confirmed reverse DNS).

Forward vs reverse DNS

An A record lives in your domain's DNS zone and resolves a name to an IP:

mail.example.com.    A    203.0.113.45

A PTR record lives in the *reverse* DNS zone, which is managed by whoever owns the IP block - usually your hosting provider or ISP, not your DNS host. It resolves the IP back to a name:

45.113.0.203.in-addr.arpa.    PTR    mail.example.com.

Note the IP is reversed and suffixed with .in-addr.arpa. - that is how reverse DNS zones are structured for IPv4.

Why receiving servers check it

When a mail server connects to deliver a message, the receiving server does a reverse lookup on the connecting IP. If that lookup returns no hostname, or a hostname that does not match what the server identifies as in its SMTP HELO/EHLO greeting, the receiving server treats the connection as more likely to be a spam source or a misconfigured sender. Many receiving systems will reject the connection outright if there is no PTR record at all; others will accept it but score the message down.

The direction of travel in email authentication over the past several years has been toward treating a correct, matching PTR record as a baseline expectation for any server sending real volume, not an optional nice-to-have. Residential and dynamic IP ranges are judged even more harshly because few legitimate mail servers run on them.

How to check your PTR record

Use dig with the -x flag, which performs the reverse lookup automatically:

$ dig -x 203.0.113.45 +short
mail.example.com.

If that returns nothing, you have no PTR record. If it returns a hostname that is not yours, or not the hostname your server greets with, you have a mismatch.

Then confirm the forward side matches:

$ dig mail.example.com +short
203.0.113.45

Both lookups should land on the same IP/hostname pair. If they do not round-trip cleanly, that is the FCrDNS failure receiving servers are checking for.

Fixing a missing or wrong PTR record

You cannot set a PTR record in your own domain's DNS panel - it has to be set by whoever controls the IP's reverse zone.

1. Identify the IP owner. Run whois 203.0.113.45 to find the allocating ISP or hosting provider.
2. Request the PTR record through that provider. Most cloud providers (AWS, Google Cloud, Hetzner, DigitalOcean, etc.) expose a self-service field for this in their console - look for "reverse DNS" or "PTR record" on the instance or IP settings page. Smaller ISPs may require a support ticket.
3. Match the hostname to your HELO greeting. The PTR should resolve to the same hostname your mail server sends in its SMTP greeting, and that hostname should resolve back to the same IP (the forward A record).
4. Wait for propagation and re-check with the dig -x command above. Reverse DNS changes can take anywhere from minutes to a day depending on the provider.

What not to do

• Do not point your PTR record at a generic hostname like mail.yourhostingprovider.com if you are sending as yourdomain.com - the mismatch between what you claim and what resolves is the problem, not the mere presence of a record.
• Do not assume a shared IP's existing PTR record is fine for you. If you share sending infrastructure, the PTR belongs to the platform, and it is their reputation, not a per-customer fix.
• Do not skip this because SPF, DKIM, and DMARC are set up. PTR is checked independently and failing it can cause rejection before any header-based check is even evaluated.

PTR record quick reference

FAQ

Does every mail server need a PTR record? Any server sending real volume to external recipients should have one. A server that only relays through a third-party smarthost (which has its own PTR) is a partial exception, but the moment you send directly, the connecting IP is what gets checked.

Can I have more than one PTR record for an IP? Technically a zone can be configured with multiple PTR entries for one IP, but mail servers typically only check the first one returned, and it's best practice to keep exactly one authoritative hostname per IP to avoid ambiguity.

Does IPv6 work the same way? The mechanism is the same (reverse lookup via ip6.arpa zones instead of in-addr.arpa), but IPv6 PTR setup is less consistently supported across hosting providers - check your provider's documentation for IPv6-specific instructions before assuming parity with IPv4.

MailPilot doesn't set your PTR record for you - that step lives with your IP's network owner - but it does warm the mailboxes sending from that IP and tracks per-mailbox reputation daily, so a PTR mismatch shows up as a drop in inbox placement you can trace back rather than a mystery.