Short answer: A PTR record maps an IP address back to a host name, the reverse of a normal DNS lookup. Receiving mail servers check that the IP address sending to them has a PTR record, and that the host name it returns resolves back to the same IP (forward-confirmed reverse DNS). Mail from IPs without it is often rejected or filtered. PTR records are set by whoever controls the IP address, usually your hosting or cloud provider, not in your domain’s DNS panel.
What reverse DNS is
Normal DNS answers “what is the IP address of mail.yourdomain.com?” with an A or AAAA record. Reverse DNS answers the opposite question: “which host name belongs to IP address 203.0.113.25?”. The answer lives in a PTR record under a special zone, in-addr.arpa for IPv4 and ip6.arpa for IPv6, where the IP address is written backwards: 25.113.0.203.in-addr.arpa.
Because the reverse zone follows the IP address, not the domain name, it is controlled by whoever was allocated that address block. That is your hosting company, cloud provider or internet service provider, unless your organisation has its own address allocation. You cannot create a PTR record in the same DNS panel where you manage your domain’s A, MX and TXT records, which surprises many administrators the first time.
Reverse DNS is used for many purposes, from making logs readable to network diagnostics. For e-mail, it has become a basic trust signal for sending servers.
Why receiving servers care
Legitimate mail servers are usually run by organisations that take the trouble to configure them properly. Machines that send spam are often infected home computers or cheaply rented servers where nobody has set a meaningful PTR record. Checking reverse DNS is therefore a cheap way for receivers to separate likely legitimate servers from likely abusive ones.
Receivers apply this in different ways:
- Some reject outright connections from IPs without a PTR record.
- Some require forward-confirmed reverse DNS (FCrDNS): the PTR name must resolve back to the same IP address.
- Some score generic names negatively, such as names that contain the IP address itself or words like “dynamic”, “dsl” or “pool”, which suggest home connections.
- Large mailbox providers list it as a requirement. Google’s sender guidelines require that sending IPs have valid forward and reverse DNS records for all senders, not only bulk senders.
Who needs to worry about PTR records
If your business mail is hosted by Google Workspace, Microsoft 365 or another major mail provider, their outgoing servers already have correct reverse DNS, and you have nothing to do. The same is true for established newsletter and transactional mail services.
You need to act if:
- You run your own mail server, on a virtual server, a dedicated server or in your office.
- Your website server sends mail directly, for example through PHP mail or a local mail agent, instead of relaying through a provider.
- You use a dedicated IP address at a mail service and are asked to configure its reverse DNS yourself.
- Devices on an office connection send mail directly to the internet, which is generally a bad idea for exactly this reason.
How to check reverse DNS
- Find the sending IP. Look at the headers of a message the server sent. The
Receivedheader added by the receiving server shows the connecting IP. - Look up the PTR record. Run
dig -x 203.0.113.25 +shorton macOS or Linux, ornslookup 203.0.113.25on Windows. You should get a host name such asmail.yourdomain.com. - Confirm the forward lookup. Run
dig A mail.yourdomain.com +shortand make sure it returns the same IP address. For IPv6, usedig AAAA. - Compare with the server’s greeting name. The name the server announces in the SMTP HELO or EHLO command should be a valid host name, ideally the same as the PTR name.
Receiving servers also record their own view. In received headers, you often see text like from mail.yourdomain.com (mail.yourdomain.com [203.0.113.25]); a mismatch or “unknown” there is a clue.
How to set a PTR record
The exact steps depend on your provider:
- Cloud and VPS providers usually offer a “reverse DNS” field in the control panel for each IP address. Some set it automatically to the server’s name, so naming the server
mail.yourdomain.comis enough. - Dedicated server hosts typically let you edit reverse DNS in their customer panel or through a support ticket.
- Business internet connections may allow a PTR change through the ISP’s support team, but many consumer connections do not.
- Organisations with their own IP allocation manage the reverse zone themselves, often with delegation from their regional registry.
Before setting the PTR, create the A (and AAAA) record for the chosen host name in your domain’s DNS, so the forward lookup succeeds as soon as the reverse record is in place. Many providers verify the forward record before they accept the change.
Choosing a good host name
| PTR name | Assessment |
|---|---|
mail.yourdomain.com | Good: clear, belongs to your domain, resolves back |
smtp1.yourdomain.com | Good: clear role, easy to extend with smtp2 |
server123.hostingcompany.example | Acceptable if it resolves back, but says nothing about you |
203-0-113-25.dynamic.isp.example | Poor: looks like a home connection, often filtered |
| No PTR at all | Poor: many receivers reject or heavily penalise it |
One PTR per IP address is the rule. Multiple PTR records for the same IP confuse some checks and are best avoided. If a server sends mail for several domains, a single neutral host name on your main domain is fine; the PTR does not need to match the From domain of every message. Alignment for domains is the job of SPF, DKIM and DMARC.
Reverse DNS for IPv6
Servers that have IPv6 connectivity may send mail over IPv6 to receivers that support it. Several large providers are stricter with IPv6 mail and expect both a PTR record and full authentication. A frequent problem: the IPv4 address was configured years ago, then IPv6 was enabled on the server, and mail suddenly starts failing at some receivers because the IPv6 address has no reverse DNS. Either configure PTR and SPF for the IPv6 address, or make the mail server send over IPv4 only.
Common reverse DNS mistakes
- Forgetting the forward record. The PTR points to
mail.yourdomain.com, but that name has no A record, or it points to the web server instead. The check fails in one direction. - Server migration without PTR. A mail server moved to a new IP keeps its name in DNS, but nobody asked the new provider to set reverse DNS for the new address.
- Default HELO names. The mail software greets receivers with a name like
localhostor an internal host name that does not exist publicly. Set it to the PTR name. - Several servers sharing one name inconsistently. Two servers both claim to be
mail.yourdomain.com, but the A record points to only one of them, so the other fails forward confirmation. Give each server its own name. - Assuming the problem is solved by the web host. Shared hosting servers usually have a PTR record, but it names the hosting company’s server, and the shared IP’s reputation is outside your control. Relaying through a mail provider is usually the better answer.
Each of these is quick to fix once found, which is why a short check after every server change is worth the minute it takes.
Where reverse DNS fits in the bigger picture
Correct reverse DNS is a hygiene factor. It removes a reason for rejection, but it does not make mail trusted on its own. The domain still needs SPF, DKIM and DMARC, and the server needs a good sending history. Think of PTR as the server’s identity card, and domain authentication as the signature on each letter.
Site AI Audit’s e-mail checks look at your domain’s published records, SPF with its lookup limit, DKIM, DMARC and MX, alongside the website’s SSL, security headers, speed and SEO. That covers the domain side; for a self-hosted mail server, add the PTR lookups above to your routine. A free check shows the domain’s state in a couple of minutes.
Related reading
- MX Records Explained: How Email Finds Your Mail Server
- Gmail and Yahoo Bulk Sender Requirements: A Practical Guide
- Email Blocklists: How to Check Your Domain and Get Delisted
The bottom line
Every IP address that sends mail should have a PTR record with a sensible host name, and that name should resolve back to the same IP. The record is set by the IP owner, not in your domain’s DNS. With hosted mail you are already covered; with your own server or direct sending from a web server, check IPv4 and IPv6 and fix gaps before they cost you deliveries.
FAQ
What is a PTR record?
A PTR record is a reverse DNS entry that maps an IP address to a host name. Mail servers use it to check that a sending IP belongs to a properly configured server.
Why can’t I add a PTR record in my domain’s DNS panel?
Reverse DNS belongs to the owner of the IP address block, not the domain. Your hosting, cloud or internet provider controls it, usually through their panel or support.
Does the PTR name have to match my From domain?
No. The PTR name should be a valid host name that resolves back to the same IP. Domain matching for messages is handled by SPF, DKIM and DMARC alignment.
Do I need a PTR record if I use Google Workspace or Microsoft 365?
No. Their sending servers already have correct reverse DNS. You only need to act for servers you run yourself or IPs you send from directly.
What is forward-confirmed reverse DNS?
It means the PTR record of an IP returns a host name, and that host name’s A or AAAA record returns the same IP. Many receivers check both directions.
Can missing IPv6 reverse DNS break e-mail?
Yes. If a server sends over IPv6 without a PTR record for its IPv6 address, some large providers reject or filter the mail. Configure IPv6 reverse DNS or send over IPv4 only.



