PTR Records for Email: What They Are and Why They Matter (2026)

A PTR record is the DNS entry that maps an IP address back to a hostname, the reverse of what an A record does. When a mail server connects to deliver a message, the receiving server can look up the connecting IP’s PTR record to see what hostname claims it, then check that hostname’s own DNS to confirm the two point back at each other. This reverse-lookup step sits alongside SPF, DKIM, and DMARC as a trust signal, but it predates all three and works differently: it is checked at the connection level, before any header or signature is evaluated.

A PTR record is a DNS entry, stored under the special in-addr.arpa (or ip6.arpa) domain, that resolves an IP address to a hostname. Mail servers use it to run a reverse DNS lookup on every connecting IP. Major mailbox providers, including Gmail, require that lookup to resolve to a hostname whose own forward DNS record points back to the same IP, or they will not reliably accept the mail.

Reverse DNS and the in-addr.arpa Domain

Ordinary DNS answers “what IP does this hostname point to.” Reverse DNS answers the opposite question: “what hostname does this IP point to.” The two live in different parts of the DNS tree. An A record for mail.example.com sits in the example.com zone. The PTR record for that server’s IP sits in a special reverse zone under in-addr.arpa (IPv4) or ip6.arpa (IPv6), which is delegated to whoever was assigned that block of IP addresses, not to whoever owns the domain name.

RFC 1912, the long-standing operational guidance for DNS administrators, states the expectation plainly: “Make sure your PTR and A records match. For every IP address, there should be a matching PTR record in the in-addr.arpa domain.” The same section warns that a multi-homed host needs a PTR record for every IP it uses, not just the first one, and that failing to keep PTR and A records in sync “can cause loss of Internet services similar to not being registered in the DNS at all.”

You can check any IP’s PTR record yourself with dig -x:

$ dig -x 203.0.113.42 +short
mail.example.com.

The output is the hostname the IP’s reverse zone claims. On its own, that answer proves nothing: anyone who controls a reverse zone can point it at any hostname. The receiving server’s next step, described below, is what actually verifies the claim.

Forward-Confirmed Reverse DNS: The Check That Actually Runs

A raw PTR lookup only tells you what hostname an IP claims. To confirm the claim, receiving mail servers perform forward-confirmed reverse DNS (FCrDNS): they take the hostname returned by the PTR lookup and run a forward A (or AAAA) lookup on it, then check whether that forward lookup resolves back to the original IP. As the deliverability blog Word to the Wise explains, “receiving systems figured this out pretty quickly. They started doing FCrDNS checks to verify that the person managing DNS for that IP space also manages DNS for the domain space.”

Running the second half of the check yourself is one more dig command:

$ dig A mail.example.com +short
203.0.113.42

If that IP matches the one you started with, the record passes FCrDNS. If it does not resolve, times out, or returns a different IP, the two halves disagree and the check fails, regardless of how correct your SPF or DKIM setup is.

Why Receiving Servers Care About Your PTR Record

FCrDNS is not a formal internet standard the way SPF and DKIM are, but it is now table stakes with the largest mailbox providers. Gmail’s sender guidelines spell out the requirement directly: “The public IP address of a sending SMTP server must have a corresponding PTR record that resolves to a hostname. This is called a reverse DNS lookup. The same hostname must also have an A (for IPv4) or AAAA (for IPv6) record that resolves to the same public IP address used by the sending server.” Gmail flags the matching requirement as important enough to repeat: “The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.”

A missing or mismatched PTR record does not always bounce a message outright, but it removes one of the cheapest, oldest signals a receiving server has for distinguishing a legitimate mail host from a compromised residential machine or a throwaway VPS spinning up spam. Combined with a thin sending history, a bad PTR record is a fast way to end up in the spam folder rather than the inbox; see Sender Reputation for how reverse DNS fits into the broader set of signals that build or damage trust in your sending IP over time.

Who Controls the PTR Record for Your Sending IP

This is the detail that trips people up: your PTR record is not something you set in the same DNS zone as your A, MX, or TXT records. The reverse zone belongs to whoever was allocated that IP address block, which in practice means your hosting or cloud provider, not your domain registrar or DNS host.

Sending setup	Who sets the PTR record	How
AWS EC2 (Elastic IP)	You, via the AWS console or CLI	Request a reverse DNS update on the Elastic IP; AWS requires a matching forward A record first
DigitalOcean Droplet	DigitalOcean, automatically	Name the Droplet a valid FQDN in the control panel; there is no manual PTR field
Dedicated or colocated server	Your hosting provider, on request	Open a support ticket asking them to point the IP’s reverse zone at your mail hostname
Sending through an ESP or relay	The ESP, on their own IPs	Nothing to configure; the provider’s shared or dedicated IPs already carry a matching PTR record

AWS’s documentation on reverse DNS for Elastic IP addresses recommends the setup explicitly for anyone sending mail from an EC2 instance: “We recommend that you provision one or more Elastic IP addresses and assign static reverse DNS records to the Elastic IP addresses that you use to send email.” It also states the prerequisite plainly: “Before you create a reverse DNS record, you must set a corresponding forward DNS record (record type A) that resolves to an Elastic IP address in your account.” DigitalOcean’s DNS documentation takes a simpler approach: it creates PTR records automatically from the Droplet’s name, provided that name is a valid FQDN such as mail.example.com rather than a default label like ubuntu-s-4vcpu-8gb-fra1-01.

This is also why sending through a relay or ESP removes PTR from your to-do list entirely: the IPs belong to the provider, so the provider’s operations team keeps the reverse zone in sync with the forward zone. See What Is an SMTP Relay? for the full tradeoff between running your own sending infrastructure and handing IP reputation, including PTR management, to a relay. If you self-host, PTR is one line item among several in a working authentication setup; the Email Deliverability Best Practices guide covers where it fits alongside SPF, DKIM, and DMARC.

Setting Up a PTR Record

The steps are the same regardless of provider, only the interface changes:

1. Confirm the hostname you want the IP to resolve to, typically your sending domain’s mail subdomain (mail.yourdomain.com).
2. Create a forward A (or AAAA) record for that hostname pointing at your sending IP. Most providers require this to exist before they will accept a reverse DNS request.
3. Request the PTR update through your provider’s console, CLI, or support ticket, since you cannot create it in your own domain’s DNS zone.
4. Verify with dig -x <ip> that the PTR resolves to the hostname you requested, then dig A <hostname> to confirm the forward lookup resolves back to the same IP.

Frequently Asked Questions