Reverse DNS & PTR records for email

Reverse DNS is the sending server's identity card. When your mail server opens a connection, the receiver's first instinct is to ask a simple question: does this IP address resolve to a real, expected hostname? That answer comes from a PTR record, and on a self-hosted setup it is entirely your responsibility — there is no ESP quietly setting it for you. It is also one of the most common quiet gaps: the 2026 bulk sender requirements treat valid reverse DNS as a baseline expectation, yet a missing or generic PTR is a frequent reason mail lands in spam without any obvious error. This guide explains what a PTR is, how the forward-confirmed check works, where to set it, and how to verify it.

What a PTR record is

DNS usually works forwards: you ask for a hostname and get an IP address. An A record answers "what IP does mail.example.com use?" A PTR record — a pointer record — answers the reverse: "what hostname does 192.0.2.10 belong to?" It lives in a special reverse zone keyed on the IP address rather than on your domain, which is why it is managed by whoever owns the IP. For a mail server, the PTR should resolve your sending IP to the hostname your server identifies as, for example 192.0.2.10 pointing back to mail.example.com.

On its own, a reverse lookup proves little — anyone could point an IP they control at any name. Its value comes when a receiver pairs it with a forward lookup, which is where forward-confirmed reverse DNS comes in.

FCrDNS: the two-way check that builds trust

Forward-confirmed reverse DNS is a two-step verification a receiving server performs on the connecting IP. First the reverse step: it looks up the PTR for your IP and gets a hostname. Then the forward step: it looks up the A or AAAA record for that hostname and checks whether it resolves back to the same IP that connected. If both directions agree, the receiver has reasonable confidence that whoever controls the IP also controls the hostname — a meaningful signal, because spammers and compromised machines rarely have it. FCrDNS is not mandated by an RFC, but major providers including Gmail and Microsoft use it as a trust input, and since the February 2024 tightening it is effectively expected of any serious sender.

Use the helper below to generate the exact lookups for your own IP and hostname, and to see what a passing result looks like. It builds the commands locally in your browser; it does not perform any lookup itself.

Why receivers care

Reverse DNS is used as an early trust filter, before a receiver even weighs your message authentication. Many providers will not accept mail from an IP with no valid reverse DNS at all, and almost all of them treat a generic provider hostname as a weak signal. The failure has two shapes. Sometimes it is loud: a connection-time rejection with a message about reverse DNS, phrased as something like the IP not being in DNS. More often it is silent — the message is accepted but quietly filed to spam or throttled, because the missing or mismatched PTR lowered your reputation with no bounce to tell you why. That silence is exactly why a reverse DNS problem can sit unnoticed while delivery slowly erodes.

This is also a quiet argument for a dedicated sending IP. On a shared IP you generally cannot set your own reverse record — the provider owns the PTR, and it reflects their hostname, not yours — so you inherit whatever reputation and naming the shared address carries. A dedicated IP you control end to end lets the PTR, the forward record and the HELO all carry your own domain, which is part of why senders at volume move to dedicated addresses. The dedicated versus shared IP guide weighs that trade-off in full.

Setting it up correctly

The order matters. Start with the forward record: create an A record (and an AAAA record if you send over IPv6) for your chosen mail hostname pointing at the sending IP. Then set the PTR for that IP to the same hostname, at your hosting provider. Finally, configure your MTA so its HELO/EHLO banner announces that identical hostname, so the name your server says, the name the IP resolves to, and the name that resolves back to the IP are all one and the same. PowerMTA sets its HELO per virtual MTA, and KumoMTA sets it in its egress configuration; either way the goal is a single consistent FQDN per sending IP.

The step that surprises people is where the PTR goes. It is not at your domain registrar, where your A, MX and TXT records live. The PTR belongs to the reverse zone for the IP, and that zone is controlled by whoever owns the IP — your VPS or cloud provider. So you set it in their control panel or by opening a request with them, never in the DNS panel where you manage your domain.

Where to set the PTR, by provider

The mechanism differs from host to host, but it is always on the provider side. These are the common patterns in 2026.

Provider	Where the PTR is set
DigitalOcean	Derived from the Droplet name — name the Droplet as the FQDN (e.g. mail.example.com) and the PTR follows.
Vultr	Reverse DNS field per IP in the instance's settings.
Linode / Akamai	"Edit RDNS" on the IP in the Linode dashboard (forward record must exist first).
Hetzner	Reverse DNS entry per IP in the Cloud or Robot console.
OVH / OVHcloud	Reverse DNS field on the IP in the control panel.
AWS EC2	Submit the reverse DNS / sending-limit request form; rDNS is set by AWS for the Elastic IP.
Google Cloud	Set via the API/CLI on the external IP (requires matching forward DNS).

In every case the rule is the same: a forward record for the hostname must usually exist before the reverse record will validate, and the PTR must point at a hostname you control, not a leftover default.

PTR for multiple IPs and sending pools

If you send from more than one IP — a warmed pool, or separate streams for marketing and transactional mail — each IP needs its own single PTR. There is no shortcut where one record covers a range; reverse DNS is per address. A practical convention is to name them predictably, such as mta1.example.com, mta2.example.com and so on, each with its own A record pointing back, so the whole pool passes FCrDNS individually. This dovetails with how a serious sender already separates traffic across virtual MTAs and IP pools: the routing identity and the DNS identity should line up, one hostname per IP, consistent from the HELO down to the reverse record. Mixing a clean PTR on one pool IP with a forgotten default on another is a common and avoidable inconsistency.

IPv6 and reverse DNS

Sending over IPv6 raises the stakes on reverse DNS rather than lowering them. Google has been explicit that IPv6 senders need a valid PTR with matching forward DNS — the same FCrDNS logic, applied to the AAAA record. The practical consequence is blunt: an IPv6 address with no reverse DNS is worse than not using IPv6 at all, because the missing PTR is treated as a strong negative signal. If you cannot set reliable reverse DNS on your IPv6 space, send over IPv4 only until you can. The IPv6 sending guide covers the rest of the IPv6 considerations alongside this one.

How PTR fits with SPF, DKIM and DMARC

Reverse DNS and message authentication answer different questions, and you need both. FCrDNS asks an infrastructure question — does this IP belong to a properly named mail server? SPF, DKIM and DMARC ask message questions — is this mail authorised for the domain, was it altered, does it align? A perfect PTR does nothing to rescue mail that fails authentication, and flawless DKIM does not make up for an IP with no reverse DNS. They sit at different layers of the same identity story: the connection identifies itself through reverse DNS and HELO, then the message proves itself through signatures. The authentication guide covers the message side; this page covers the connection side, and a clean setup gets both consistent — ideally the same base domain runs through your hostname, your envelope and your signing.

Verifying your reverse DNS

Two commands confirm the whole picture. A reverse lookup, dig -x 192.0.2.10 +short, should return your mail hostname. A forward lookup on that result, dig mail.example.com +short, should return the same IP you started with. If the two agree, you have FCrDNS; if the reverse returns nothing, the PTR is missing; if it returns a different or generic name, the PTR is wrong; and if the forward step lands on a different IP, your A record and PTR are out of sync. External checkers such as MXToolbox run the same two-way test from outside your network, which is worth doing when a local resolver might be serving a cached answer. Re-run these checks whenever you add a sending IP or migrate hosts, because a new IP starts life with either no PTR or the provider's default.

Give changes time to take effect. Reverse DNS updates are not always instant: the provider has to publish the new record in the reverse zone, and resolvers along the way cache the old answer for the length of its TTL, so a freshly set PTR can take anywhere from minutes to a few hours to be visible everywhere. If dig -x still shows the old value shortly after a change, query an authoritative or public resolver directly rather than your local cache, and confirm with your provider that the record was actually saved. Avoid starting a large send in the window right after a PTR change — verify it has propagated first, then ramp.

Common reverse DNS mistakes

Reverse DNS is easy to get almost right, and almost right still fails. These are the recurring errors on self-hosted setups.

• Setting the "PTR" at the registrar. The reverse zone belongs to the IP owner, so a record added in your domain's DNS panel does nothing. Set it with your hosting provider.
• Leaving the provider's default in place. A name like 192-0-2-10.static.provider.net exists but advertises a generic hosting IP rather than a configured mail server. Replace it with your own hostname.
• A missing or mismatched A record. If the hostname in your PTR has no forward record, or one that points at a different IP, FCrDNS fails even though the PTR itself looks fine. Both directions have to agree.
• Publishing more than one PTR for an IP. Mail software expects a single canonical name; multiple records leave the receiver to pick one arbitrarily.
• Sending from a dynamic or residential IP. Those addresses change and rarely allow custom reverse DNS, so a stable PTR is impossible. They are not for sending mail.
• Forgetting new pool IPs. When you add an IP to a warmed pool or migrate hosts, it arrives with no PTR or a default one. New mail flows immediately while reputation quietly suffers.
• An IPv6 address with no PTR. If your server prefers IPv6 for outbound and that address lacks reverse DNS, the missing record is a strong negative signal — worse than sending over IPv4 only.
• A HELO that disagrees with the PTR. The name your MTA announces on connection should match the reverse record. A mismatch weakens the consistency receivers reward.

The bottom line

A PTR record is small, but receivers lean on it heavily. Receivers use forward-confirmed reverse DNS as an early trust check, so your sending IP needs a reverse record pointing at a real hostname, that hostname needs a forward record pointing back, and your MTA should announce the same name in its HELO. Set the PTR at the provider that owns the IP, not your registrar; give every sending IP its own single, non-generic record; cover IPv6 if you use it; and verify both directions with dig after any change. Get this right and it disappears into the background, exactly as it should. Leave it wrong and it becomes the unexplained reason good mail keeps landing in spam.