What it is
Normal DNS turns a name into an address. Reverse DNS does the opposite: a PTR record under the special in-addr.arpa (or ip6.arpa) tree maps an IP address back to a hostname. For 203.0.113.7 the lookup is for 7.113.0.203.in-addr.arpa, and the answer is something like mail.example.com.
The record is controlled by whoever owns the IP block — your hosting provider or ISP — not by your domain's DNS. That is why it is set in the VPS control panel rather than alongside your MX records.
Forward-confirmed reverse DNS
Receivers do not stop at the PTR. They take the hostname it returns, resolve it forward with an A or AAAA lookup, and check that the answer includes the original IP. Both directions have to agree. A PTR that points to a name which resolves somewhere else is treated as no PTR at all.
Gmail states this explicitly: sending IPs must have a PTR record, and the forward lookup of that hostname must return the same IP. Fail it and the response is 550 5.7.25.
Why it matters for cold email
On Google Workspace and Microsoft 365 you never see this; the providers own the IPs and publish correct records. The moment a fleet moves to a dedicated SMTP relay, a VPS, or a cheap SMTP reseller, it becomes your problem, and it is invisible until the Gmail bounces start. Any setup that sends from an IP you control needs the PTR checked on day one, and ideally the hostname should be under the sending domain so that everything a receiver sees tells the same story.
How a PTR record is written
A PTR record lives in a reverse zone owned by whoever owns the IP block. For 203.0.113.25 the record's name is 25.113.0.203.in-addr.arpa — the octets reversed — and its value is a hostname such as mail.acme.com. IPv6 uses ip6.arpa with every nibble reversed, which nobody writes by hand. Because the zone belongs to the IP owner, you do not publish a PTR in your own DNS; you ask the hosting provider to set it, or set it in their control panel, and it appears in their zone.
The hostname should be a real name that resolves forward to the same address. mail.acme.com with an A record back to 203.0.113.25 is correct. A generic provider name like ip-203-0-113-25.host.example resolves forward, so it passes the technical check, but receivers score generic-looking PTRs as unmanaged infrastructure. Gmail's 5.7.25 bounce is what a missing or unmatched PTR looks like from the outside.
Setting it on common hosts
Every VPS and cloud provider has a field for it — on the network or IP settings page for the server, sometimes labelled reverse DNS, sometimes hostname. Set it to the mail hostname, then create the matching A record in your own zone, then wait an hour and check both directions with the PTR lookup. Shared hosting and most residential connections cannot set one at all, which is one of several reasons not to send mail from either.
If you run a mail server behind a static IP from a business ISP, the ISP owns the reverse zone and you request the PTR through support. This can take days. Do it before the server sends its first message, not after the first bounce.
What Gmail and Microsoft actually check
Gmail requires that every connecting IP has a PTR record, that the hostname it returns resolves forward to the same IP, and that the hostname is not generic. Mail failing any of those is rejected at the connection with 5.7.25, before it is even scored. Microsoft is less strict at the connection but folds a missing or generic PTR into its reputation model, and Outlook.com in particular junks mail from IPs that look unmanaged.
None of this applies to a Google Workspace or Microsoft 365 fleet. Those providers own the IPs and the PTRs are correct by construction; there is nothing to set and nothing to check. It applies the moment you run your own SMTP server, a relay, or a VPS-based sending tool — and it is the first thing to verify when mail from such a server is rejected by Gmail. The bulk sender checker includes the forward-confirmed reverse DNS test alongside the rest of Google's requirements.
Check yours
These run free in your browser. Nothing you type reaches a server.
Common questions
Who sets the PTR record?
The owner of the IP address block — your hosting provider, VPS host or ISP. It is usually a field in their control panel, sometimes a support ticket. It cannot be set in your domain's DNS zone.
Does the PTR hostname have to match my domain?
Not strictly; it has to resolve back to the IP. In practice a hostname under your sending domain is better because it aligns with everything else a receiver sees.
Do I need PTR on Google Workspace?
No. Google publishes reverse DNS for its own sending infrastructure. The requirement bites when you send from an IP you control.
Does my cold email domain need a PTR record?
Not if it sends through Google Workspace or Microsoft 365 — the PTR belongs to the sending IP, which the provider owns and has already configured. Your domain's own DNS has no PTR in it and does not need one. It only becomes your job when you send from an IP you control: a self-hosted mail server, a VPS relay, or a dedicated IP from an email service.
Can I set a PTR record on shared hosting?
Almost never. The IP is shared with hundreds of sites and the host sets one generic PTR for all of them. That is one reason shared hosting is unsuitable for sending mail at any volume: every message arrives from a generic-looking, shared IP that Gmail scores accordingly. Send from a mailbox provider, or from a VPS or dedicated IP where you can set the PTR yourself.
Related concepts
If this is the thing going wrong
The pages explain it. If you would rather it was simply fixed, that is the work I do.