Can I add a PTR record in my domain's DNS zone?

No — or rather, you can create one and it will never be consulted. PTR lookups happen under `in-addr.arpa` and `ip6.arpa`, which are delegated by IP address ownership. The entry for your sending IP is created by whoever owns the address block: your VPS provider, colo, or ISP.

What hostname should the PTR point to?

A hostname you control that has a matching A or AAAA record back to the same IP, and that your mail server also uses as its HELO/EHLO name. `mail.example.com` is the conventional choice. Using a name whose forward record points elsewhere is worse than having no PTR at all.

Is a generic PTR from my provider good enough?

It satisfies the FCrDNS check, since providers create the matching forward record, so it will not get you rejected outright at most receivers. But names in obviously dynamic or generic pools carry their own reputation penalty, and they will not match your HELO name. If the provider lets you set a custom value, set one.

Do I need a PTR if I send through Google Workspace or SendGrid?

No. The connecting IP is the provider's and they maintain its reverse DNS. Your responsibilities are SPF, DKIM, DMARC alignment, unsubscribe handling, and complaint rates. PTR only becomes yours when your own server connects to receivers directly.

My IPv4 PTR is fine but mail to Gmail still fails authentication checks.

Check whether the connection is going out over IPv6. Providers apply the reverse-DNS requirement to the address that actually connects, and an IPv6 sender with no `ip6.arpa` entry fails even though the v4 address is perfect. Either publish the IPv6 PTR or configure the MTA to prefer IPv4 for outbound delivery.

How do I find which IP my mail actually leaves from?

Read the `Received:` headers of a message you sent to an external address — the last one added by your own infrastructure names the IP the receiver saw. Do not assume it matches your website A record or your MX record; outbound and inbound paths are frequently different hosts.

PTR Records Are Now Required by Yahoo and Microsoft

Reverse DNS is the oldest anti-abuse check still in daily use, and it is the one support engineers most often find missing. It costs a receiver nothing, it is trivially checkable at connection time before a single byte of message data is transferred, and a host that cannot be named in reverse has historically been a compromised machine. That is why it survived into the current bulk-sender requirements at every major mailbox provider.

What is a PTR record, and where does it actually live?

A PTR record maps an IP address back to a hostname — the opposite direction from an A record. It is stored in a special reverse zone: 203.0.113.25 becomes the name 25.113.0.203.in-addr.arpa, with the octets reversed so the hierarchy runs from least to most specific, exactly like a normal domain name. IPv6 uses ip6.arpa with each hex nibble reversed and dotted.

# The PTR query is a normal lookup at a reversed name.
# dig -x builds that name for you:
dig -x 8.8.8.8 +short
# dns.google.

# Which is exactly the same as asking for it by hand:
dig +short PTR 8.8.8.8.in-addr.arpa
# dns.google.

A reverse lookup is an ordinary PTR query at an in-addr.arpa name

That naming scheme is the whole reason you cannot publish your own PTR. The in-addr.arpa tree is delegated by address ownership, not by domain ownership: IANA delegates to the regional registries, the RIR delegates the block to the network operator, and the operator delegates or edits the individual entry. You control example.com, so you control its A records. You do not control 113.0.203.in-addr.arpa unless you were assigned that address block.

This is why adding a "PTR record" in your DNS provider's dashboard does nothing. Some panels will let you create one — it will sit in your zone, unreferenced, forever. PTR for a sending IP is set by the party that owns the IP: your VPS provider, your colo, or your ISP. See Set a PTR Record on Your VPS for where that control usually is.

What is forward-confirmed reverse DNS?

A PTR record alone proves nothing — the IP block owner can point it at any name they like, including one belonging to someone else. Receivers therefore run FCrDNS (forward-confirmed reverse DNS): take the PTR result, resolve *that* hostname forward, and require the answer to include the original IP. Only the owner of the address can create the PTR, and only the owner of the hostname can create the A record, so a matching pair proves both parties agreed.

# Step 1 — reverse: what does this IP call itself?
dig -x 203.0.113.25 +short
# mail.example.com.

# Step 2 — forward: does that name point back to the same IP?
dig +short A mail.example.com
# 203.0.113.25

# One-liner that does both:
dig +short -x 203.0.113.25 | xargs -I{} dig +short A {}

The FCrDNS check receivers perform at connection time

If step 1 returns nothing, you have no PTR. If step 2 returns a different address or nothing at all, you have a PTR that does not forward-confirm — which some receivers treat as worse than having none, because it looks like an attempt to impersonate a hostname.

Result	What it means	How receivers usually treat it
`dig -x` empty	No PTR delegated for the IP	Connection rejected or heavily penalised by Yahoo, Outlook.com, and Gmail
PTR exists, forward matches	Full FCrDNS	Passes the check — the baseline expectation
PTR exists, forward does not match	Broken FCrDNS	Treated as no PTR, sometimes worse
PTR is a generic ISP name	Valid but obviously dynamic-pool	Often accepted for FCrDNS, still penalised as residential/dynamic space
PTR differs from the HELO name	Inconsistent identity	Suspicious; several filters score on the mismatch

What do Yahoo, Microsoft, and Google actually require?

Yahoo and Google published a joint set of sender requirements, and Microsoft has since tightened its own rules for high-volume senders into Outlook.com and Hotmail. The specific enforcement thresholds and rollout schedules have moved more than once — check each provider's current sender documentation for those. The requirements themselves have been consistent:

Valid forward and reverse DNS for the sending IP. A PTR must exist and forward-confirm. This applies to the IP that opens the SMTP connection, which for IPv6 senders means the IPv6 address specifically — a v4-only PTR does not cover mail sent over v6.
SPF and DKIM published, and at least one of them aligned with the From: domain. Alignment, not merely a pass, is what DMARC evaluates.
A DMARC record on the From: domain, at minimum p=none. Bulk senders are expected to have one at all.
One-click unsubscribe on commercial and subscribed bulk mail, implemented with the List-Unsubscribe and List-Unsubscribe-Post headers, plus honouring the request promptly.
Spam complaint rates kept below the provider's threshold, measured in their postmaster tooling. Sustained complaints override every other signal — perfect DNS will not rescue a list people do not want.
A valid, resolvable HELO/EHLO hostname that matches the PTR. This is not always spelled out as a separate rule, but the checks that enforce it are widely deployed.

PTR is the item most likely to be missing because it is the only one not configurable from your DNS provider. Everything else on that list is a record you publish yourself — see the SPF Checker, the DKIM Checker, and the DMARC Checker, or run all of them at once with the Email Deliverability Test.

How do you verify your own sending IP?

First identify the IP that actually connects to receivers. It is not necessarily your website's A record and not necessarily your MX. The definitive source is a message header from mail you sent: the last Received: line added by your own infrastructure names the IP the receiver saw. Paste a full header set into the Email Header Analyzer if you are not sure which one it is.

Reverse DNS (PTR) Lookup

Hostname behind an IP — required for mail servers

Then run the FCrDNS pair on that IP, and check that it is not on a blocklist while you are there — a missing PTR and a listing on a dynamic-space blocklist frequently travel together, because both describe the same fact about the address. The Email Blacklist Check covers the second half.

What if you send through a provider?

If your mail leaves through Google Workspace, Microsoft 365, Amazon SES, Postmark, Mailgun, SendGrid, or any similar relay, the connecting IP belongs to them and so does the PTR. It is already correct and there is nothing for you to do — no receiver expects a PTR on your domain in that case. Your job is limited to SPF, DKIM, DMARC, and list hygiene.

PTR only becomes your problem when your own server talks to receivers directly: a self-hosted Postfix or Exim box, a cPanel or Plesk server, a marketing appliance on a dedicated IP, an application server that sends transactional mail from the same host it runs on. Those are the cases where the Reverse DNS Lookup comes back empty and the bounces start.

Common failure modes

PTR set, A record missing. Someone set mail.example.com as the PTR but never created the matching A record. FCrDNS fails. Fix it in your own zone — verify with the A Record Lookup.
IPv6 forgotten. The host has both v4 and v6, mail goes out over v6 because it is preferred, and only the v4 address has a PTR. Either set the ip6.arpa entry or stop the MTA from using IPv6 for outbound delivery.
Server moved, PTR left behind. The instance was rebuilt on a new IP and the old rDNS entry stayed on the old address. Re-check after every migration.
HELO name does not match. The MTA announces localhost.localdomain or the raw hostname while the PTR says mail.example.com. Fix the MTA's HELO setting to match the PTR exactly.
Shared IP you do not control. On shared hosting the PTR belongs to the host and names their server, not your domain. That is normal and usually fine for FCrDNS — but you cannot change it, and if it is missing entirely, only the host can fix it.

When bounces start after an infrastructure change, work the checks in order rather than guessing: Mail Bouncing After a DNS Change walks the sequence, and PTR record reference covers the record format itself.