Reverse DNS for Your Own IP: Why Emails Land in Spam Without a PTR Record

In short

A PTR record translates an IP address back into a hostname — the counterpart to a normal A record.
Many mail servers reject deliveries from IPs without a PTR record or treat it as a strong spam signal.
The PTR record is set by whoever owns the IP block — on a rented server, that's the hosting provider, not something you enter in your own zone file.
What matters isn't just that a PTR exists, but that it matches the forward resolution (FCrDNS).

You send an email, no error message, but it never arrives at the recipient — and not in the spam folder, just nowhere. Usually that's not a problem with your mail server, but with the IP address it's sending from. More precisely: it's missing reverse resolution.

What a PTR record actually does

An A record answers the question "which IP belongs to this name?". The PTR record answers the reverse question: "which name belongs to this IP?". Technically it doesn't live in your normal zone, but in the in-addr.arpa zone that belongs to the IP address — and that's managed by whoever the IP block is assigned to.

For a mail server this matters because it introduces itself with a name during the HELO/EHLO handshake. The receiving server then checks: does the sending IP resolve to a name at all? And does that name resolve back to the same IP (Forward-Confirmed reverse DNS, or FCrDNS for short)? If either is missing or they don't match, that's a signal to spam filters — often enough for a rejection.

Situation	What many mail servers do	Typical result
No PTR record present	Connection is flagged as suspicious or rejected outright	Email never reaches the recipient, often without a clear error message
PTR points to a generic provider name (e.g. host-123-45.provider.example)	Not a hard rejection criterion, but poor reputation	Email frequently ends up in the spam folder
PTR matches the hostname and forward resolution confirms it (FCrDNS)	A baseline criterion for a trustworthy sender is met	Delivery passes cleanly on this criterion

Technically, the PTR record doesn't belong to your domain, it belongs to the IP address. If you rent a server, the reverse zone sits with the hosting provider — you can't add it yourself in your own zone file; you have to request the change from the provider, for example through the customer panel or a support ticket.

Step by step: setting a PTR record for your IP

Check the current PTR record. First find out what's actually set for your IP.
```
dig -x 203.0.113.10 +short
```
If nothing comes back, there's currently no PTR record.
Decide on a matching hostname. Pick a name you'll also resolve as an A record — commonly a subdomain like mail.yourdomain.com or the server name you already use for SSH and the like.
Set the forward record (A record) for that name, so the reverse direction can later be confirmed.
```
mail.yourdomain.com.  IN  A  203.0.113.10
```
Request the PTR change from your hosting provider. Since the reverse zone belongs to the provider, you only submit the desired hostname here — the record itself gets set server-side.
```
Subject: PTR record for 203.0.113.10
Please set PTR to mail.yourdomain.com.
```
Adjust the HELO/EHLO hostname on your mail server so it exactly matches the name now returned by the PTR and A records — otherwise the FCrDNS check stays inconsistent regardless.

The most common mistake: the PTR gets set, but the matching A record is missing — or the mail server introduces itself via HELO with yet a third, different name. For FCrDNS, the PTR, the A record, and the HELO name all have to match; otherwise the PTR record alone barely helps.

You don't have to use your main domain for the PTR hostname — a technical name like mail.yourdomain.com or server1.yourdomain.com works too. That separates "what the server is called" from "which website runs on it", and it stays easy to manage even with several domains on the same root server running its own mail server.

A PTR record is the ticket in, not a guarantee — it removes one hard exclusion criterion, but it doesn't replace SPF, DKIM, and DMARC.

Important: the PTR record is a necessary but not a sufficient condition. Even with a correct PTR, an email can still land in spam because of a missing SPF record, no DKIM signature, or poor IP reputation. If you run your own mail server on a rented root server, treat PTR, SPF, and DKIM as one package, not as separate boxes to tick.

How to verify it worked

Once the provider has made the change, you can check for yourself that everything lines up:

# 1. Query the PTR record
dig -x 203.0.113.10 +short
# expected: mail.yourdomain.com.

# 2. Check the forward resolution of the name
dig mail.yourdomain.com +short
# expected: 203.0.113.10

# 3. Test the mail server's HELO name against its own IP
telnet mail.yourdomain.com 25

If the PTR response and the A record response match, FCrDNS is satisfied. Reverse-zone DNS changes can take a little time to propagate everywhere — if the first query still shows the old state, a second check a few hours later is normal.

If you're more broadly interested in DNS servers and running them yourself — say because your own zone sits on a self-managed nameserver — there's related background in our article on security vulnerabilities in BIND DNS servers, relevant as soon as it's not just the mail server but your own DNS infrastructure that needs attention.

If your provider doesn't allow PTR changes

Not every hosting contract gives customers the right to set their own PTR record — some IP blocks are permanently tied to generic names. Before booking a server specifically for sending mail, it's worth asking whether individual PTR records are possible. That's relevant enough that it affects your later delivery rate more than almost any other setting on the mail server itself.

Frequently asked questions

Can I set the PTR record myself in my own DNS zone?

No. The PTR record lives in the reverse zone of the IP address, which belongs to whoever owns the IP block — on a rented server, that's the hosting provider. You can only request the hostname you want; it gets set server-side.

Is a correct PTR record enough to keep my emails out of spam?

No, it only removes one hard exclusion criterion. You typically also need a matching SPF record, a DKIM signature, and good IP reputation built up over time.

What exactly does FCrDNS mean?

Forward-Confirmed reverse DNS: the IP's PTR record returns a hostname, and querying the A record for that hostname returns the same IP again. Only if both directions match does the check pass.

How long does it take for a PTR change to take effect?

That depends on the provider and the TTL of the reverse zone. The change is often queryable via dig or host within a few hours; the first check right after the request may still show the old value.

Do I absolutely need a dedicated IP with its own PTR for my own mail server?

Yes, for reliable delivery. If the IP is shared among several senders or an individual PTR can't be set, your own delivery rate depends on the reputation of other senders on the same IP — something you can barely control.