Reverse DNS (PTR) Record Setup: Step-by-Step Guide

What Is a PTR (Reverse DNS) Record?

A PTR record is the reverse of an A record. Where an A record says mail.yourdomain.com resolves to 192.0.2.10, the PTR record says 192.0.2.10 resolves back to mail.yourdomain.com. The two records together form a round-trip: a forward lookup from name to IP, and a reverse lookup from IP back to name. Most receivers check that round-trip on every inbound message.

A PTR record is stored in a special reverse zone in DNS — for an IPv4 address like 192.0.2.10, the PTR lives at 10.2.0.192.in-addr.arpa. For IPv6, the equivalent zone is the ip6.arpa tree. You do not need to publish these manually — they are managed by whoever owns your IP allocation (see step 1 below).

For background on how PTR fits alongside SPF, DKIM, and DMARC, read the SPF, DKIM, and DMARC Explained → guide for the full authentication stack.

Why PTR Matters for Email Deliverability

PTR is one of the lowest-cost, highest-leverage wins in email authentication. Three signals to keep in mind:

• Microsoft SNDS scores PTR explicitly. The Outlook.com filter result (green / yellow / red) and the JMRP complaint feed both treat a missing or unmatched PTR as a downgrading signal. An IP with no forward-confirmed reverse DNS will be flagged even when SPF and DKIM pass.
• Google and Yahoo treat PTR as a baseline. While neither publishes a strict "PTR required" rule, both fold PTR into the reputation signal for the sending IP. A PTR that resolves to a plausible hostname is the cheap floor; a missing PTR is treated as anonymous.
• PTR is what makes the IP look like a real server. Blocklists, anti-spam gateways, and enterprise MTA filters all use FCrDNS as a quick yes/no check on whether a sender is a legitimate mail server or a rented box with no identity. The PTR record is what turns "some IP I have never heard of" into "ah, that's mail.yourdomain.com — I have heard of them."

The right time to set up PTR is the day you provision a dedicated sending IP — before the first warm-up message goes out. Trying to add PTR retroactively after a reputation incident is harder than setting it up front.

Step 1: Confirm You Control PTR for the IP

PTR records for a public IP can only be edited by the organisation that holds the IP allocation. For most senders, that is one of:

• VPS / dedicated server host — Linode, DigitalOcean, Vultr, Hetzner, OVH, and similar providers let you set PTR from the control panel for every IP they lease you. Time to set: a few minutes.
• Cloud platform — AWS (EC2 / Lightsail), Google Cloud, Azure, and Oracle Cloud all expose a PTR-edit endpoint on the compute console. The PTR hostname can be a subdomain you publish to your own DNS.
• ISP / colocation — many business ISPs and colocation providers let you file a PTR request via a ticket or a self-service portal. Expect 1–3 business days for an enterprise ISP.
• Shared ESP pools — if you send from your provider's pooled IPs (Mailgun, SendGrid, Postmark shared pool, Amazon SES shared), the provider already publishes PTR for those IPs and you do not need to set anything.
• Residential or shared hosting — most residential ISPs and shared web hosting plans do not let you set PTR. If your sending IP is on consumer broadband or a shared host, PTR is out of your hands.

Once you know who controls the IP, the rest of the steps are identical across providers.

Step 2: Choose a Hostname for the PTR

The PTR hostname is what the IP will resolve back to. Receivers cross-check this name against the visible From: header and against your SPF record, so the hostname should match what you actually send as. Four good patterns:

• mail.yourdomain.com — the cleanest choice if your From: uses the apex domain and your SMTP relay sends from a single shared IP. Pair with an SPF record that includes the same hostname.
• mx1.yourdomain.com / mx2.yourdomain.com — useful when you have multiple IPs and want each named explicitly.
• ptr.outreach.yourdomain.com / ptr.transactions.yourdomain.com — descriptive subdomains that name the sending stream.
• outbound1.provider.net — what the provider already publishes for their shared pool. No action needed if you send from a shared pool.

Whatever name you pick, you need to publish a forward A record on it so receivers can verify FCrDNS — see step 4.

Step 3: Ask Your Provider to Publish the PTR

Once you know the hostname, submit the PTR request. The exact path depends on the provider:

• VPS providers — usually a single field in the control panel (Linode: "RDNS"; DigitalOcean: "Reverse DNS"). Fill it in, click save, and propagation is typically 5–15 minutes.
• AWS — the EC2 console on the Elastic IP detail screen has a "Reverse DNS" field; the same screen lives under Lightsail for Lightsail instances. AWS submits an internal request that usually clears within an hour.
• Google Cloud — open the external IP address detail in the GCP console and click "Edit PTR"; the change propagates once Google's internal team confirms it, usually within an hour.
• Azure — Azure exposes PTR for select public IPs through the portal or PowerShell; for Cloud Services and classic deployments, file a support ticket.
• ISP / colocation — open a ticket and ask for a PTR record on the IP, naming the desired hostname. Include the IP, the hostname, and a brief justification (e.g. "we are setting up sending mail from this IP").

If your provider publishes PTR via API rather than UI, the operation is documented per provider; the result is the same — wait for propagation before testing.

Step 4: Publish the Matching Forward A Record

Forward-confirmed reverse DNS (FCrDNS) is the property that your PTR hostname resolves back to the same IP via a forward A record. Most receivers (Microsoft SNDS in particular) check FCrDNS — not just the PTR — so you need both:

• Reverse — dig -x 192.0.2.10 returns mail.yourdomain.com.
• Forward — dig A mail.yourdomain.com +short returns 192.0.2.10.

The forward A record lives in your normal DNS zone — wherever you manage yourdomain.com. Add an A record for the PTR hostname pointing at the sending IP, with a low TTL (300–600 seconds) during the bring-up, and a normal TTL (3600–14400) once you confirm FCrDNS resolves.

Forward-confirmed reverse DNS is what makes Microsoft SNDS happy, what keeps your Postmaster Tools reputation from drifting, and what gives enterprise gateways a valid hostname to match against. A PTR without the matching forward A record is half-set and gets filtered as anonymous anyway.

Step 5: Verify PTR with `dig` or `nslookup`

After the provider confirms the PTR is published and the forward A record has propagated, run two sanity checks from any external resolver.

Reverse lookup:

dig -x 192.0.2.10 +short

The answer section should contain a single hostname on your domain — the same hostname you asked the provider to publish. Anything else means the PTR is wrong or not yet propagated. Try nslookup 192.0.2.10 on Windows for the equivalent.

Forward lookup on the PTR hostname:

dig A mail.yourdomain.com +short

The answer should be the IP you just set PTR for. If the forward lookup is missing, the A record has not propagated yet, or your DNS provider has not published it — publish it before going live.

Run the free DNS validator below to confirm PTR, A, MX, SPF, DKIM, and DMARC all resolve from a clean external resolver at once.

For deeper walkthroughs of how a published PTR ties into MX setup and your broader SPF record, read the MX Record Setup → and SPF Record Setup → guides.

Common PTR Errors and Fixes

The four patterns below cover the vast majority of PTR problems senders run into. Each has a deterministic fix.

No PTR record resolves for the IP

Your sending IP has not been registered with your hosting provider, your provider does not offer PTR control, or the PTR record has not yet propagated. Fix: confirm with the provider that the IP is yours to PTR, ask them to publish the record, and re-check after propagation (typically 15–60 minutes for VPS providers; up to a few hours for enterprise ISPs).

PTR resolves but the hostname does not match your domain

The provider pre-set PTR to a generic hostname they manage (for example li192-10.provider.net) before you sent your first message. The hostname is technical but anonymous, which Microsoft SNDS treats as a downgrading signal. Fix: ask the provider to change the PTR to a hostname on your own domain (e.g. mail.yourdomain.com).

PTR resolves to a hostname, but the hostname has no forward A record

Half-set FCrDNS — the PTR exists but forward DNS has nothing for it. Most receivers reject this state as anonymous. Fix: publish an A record for the hostname in your DNS zone pointing at the same IP, and wait 5–30 minutes for propagation before retesting.

PTR hostname does not match the visible From: header

A common mistake — PTR is set to mail.yourdomain.com but messages go out with a different subdomain in the From: header. The mismatch does not break SPF/DKIM directly, but it leaves the PTR hostname looking unrelated to the sending identity and weakens the overall match. Fix: tie the PTR hostname to the subdomain you actually send as, or add a matching A record under the From: subdomain.

PTR Best Practices for High-Volume Senders

• Set PTR on day one of a new dedicated IP. Warm-up is cheaper, faster, and less likely to attract filtering negatives when FCrDNS is correct from the first message. A PTR that appears after reputation is built does not retroactively repair a filtered early history.
• Use a hostname that names the sending stream. A PTR like ptr.outreach.yourdomain.com reads more honestly than mail.yourdomain.com when the outreach subdomain is the only sender. Receivers comparing PTR to From: see a match.
• Cross-check with MX. If your sending IP and your receiving IP are the same box (a low-volume self-hosted mail server), PTR and MX will both point at the same hostname. If they are on different IPs, publish both — reception is the MX → story, sending identity is the PTR story.
• Watch for stale PTR on cloud VMs. When you release a public IP back to the cloud platform (terminate an instance, release an Elastic IP), the PTR is no longer yours and may resolve to a generic hostname for the next tenant. Do not let a returned IP carry your hostname into someone else's sender footprint — clear or reassign PTR before releasing.
• Document PTR per IP. At high volume you probably run several dedicated IPs (transactional, marketing, outreach). Maintain a one-page PTR map — every IP, its PTR hostname, the forward A record matching it, and the sending stream that uses it. When a deliverability incident hits, you can confirm at a glance which IP to investigate.
• Pair PTR with monitor-side visibility. A correct PTR record still does not guarantee inbox placement — IP reputation and authentication alignment can both still drop. Enroll in Microsoft SNDS → for the Outlook.com filter result and Gmail Postmaster Tools → for Gmail-side reputation.

Once PTR is correct, the next step is usually MX record setup → so inbound mail delivery to your domain actually resolves, then SPF record setup → so authentication on outbound mail closes the loop.