Reverse DNS answers a simple question: given an IP address, what name does it claim? Mail servers use the answer as a basic identity check on whoever is connecting. A sending IP that has no reverse name, a generic name, or a name that does not point back to the same address looks like a compromised computer or a careless setup, and many receivers treat it with suspicion. This guide explains PTR records, forward-confirmed reverse DNS and the HELO name, shows how to check them and clarifies who is responsible in each kind of setup.
Forward and reverse DNS
Most DNS use is forward: you give a name such as mail.example.com and get an address back through an A or AAAA record. Reverse DNS goes the other way. You give an address and get a name back through a PTR record. For IPv4 the lookup uses a special name built from the address with its numbers reversed, under the in-addr.arpa zone. For IPv6 it uses ip6.arpa.
| Direction | Question | Record | Who controls it |
|---|---|---|---|
| Forward | What IP does this name use? | A or AAAA | The owner of the domain |
| Reverse | What name does this IP claim? | PTR | The owner or lessor of the IP block |
The last column is the cause of most confusion. You can edit your domain DNS yourself, but the reverse zone for an address belongs to whoever received that address block. For a server at a hosting company, that is the host. For a dedicated address on a sending platform, it is the platform or its network provider. You usually request a change from them.
Forward-confirmed reverse DNS
Anyone who controls a reverse zone can put any name in a PTR record, including a name that belongs to someone else. To make the check meaningful, receivers do a second lookup. They take the name from the PTR record, look it up in forward DNS and confirm that it returns the connecting IP address. When it does, the owner of the IP and the owner of the name have both agreed to the link. This is called forward-confirmed reverse DNS, often shortened to FCrDNS.
| Result | What it looks like | How receivers may react |
|---|---|---|
| Confirmed | IP 203.0.113.10 has PTR mail.example.com, and mail.example.com resolves to 203.0.113.10 | Positive or neutral signal |
| No PTR | The IP has no reverse record at all | Often rejected or scored down |
| Mismatch | PTR says mail.example.com, but that name resolves to a different IP | Treated as untrustworthy |
| Generic name | PTR looks like 203-0-113-10.provider.example | Often treated as a consumer or unmanaged line |
The addresses above come from a range reserved for documentation, and the names are placeholders.
The HELO or EHLO name
When a sending server connects, its first SMTP command is EHLO, followed by a host name. RFC 5321 expects this to be the fully qualified domain name of the sending host. Receivers compare this name with the connecting IP. A good setup has three things in agreement: the HELO name, the PTR record for the IP and the A record for that name.
Connecting IP: 203.0.113.10
PTR record: mail1.example.com
A record: mail1.example.com -> 203.0.113.10
EHLO command: EHLO mail1.example.com- Use a fully qualified name that resolves, not a bare word like localhost or a private name.
- Do not use an IP address in brackets when you can use a real name.
- Use a name under a domain you control, so you can manage its records.
- If you send from several IP addresses, give each its own name, such as mail1 and mail2.
Who is responsible in your setup
| Setup | Who sets PTR and HELO | What you do |
|---|---|---|
| Shared IP addresses on a sending platform | The platform | Nothing about reverse DNS; focus on authenticating your domain |
| Dedicated IP on a sending platform | Usually the platform, possibly with a name you choose | Ask your provider how it is set and whether you can pick the name |
| Your own mail server at a hosting company | You choose the name; the host sets the PTR | Request the PTR from the host and set the HELO yourself |
| Your own server on an office or home line | The internet provider | Usually unsuitable for sending; use a relay with proper infrastructure |
If you are unsure which row applies, ask your provider. For background on the choice between shared and dedicated addresses, read dedicated IP versus shared IP.
How to check your records
Step 1: Find the sending IP
Send a test message to an inbox you control and open the full headers. The Received lines show the IP address that connected to the receiving server. Our guide to reading email headers shows how to find it.
Step 2: Look up the PTR record
# Reverse lookup of an IP address
dig -x 203.0.113.10 +short
# Same with the host command
host 203.0.113.10Step 3: Confirm the forward record
# Forward lookup of the name returned above
dig mail1.example.com A +short
# For IPv6
dig mail1.example.com AAAA +shortThe forward answer must include the IP address you started with. If it does not, either the PTR or the A record is wrong.
Step 4: Compare with the HELO name
In the test message headers, the receiving server often records the HELO name it was given in the Received line. Check that it matches the PTR name or at least resolves to the same address.
Common problems and fixes
| Problem | Cause | Fix |
|---|---|---|
| No PTR record | Reverse zone never set | Ask the IP owner to create it |
| Generic provider name | Automatic naming by the host | Ask for a custom name under your domain |
| PTR and A records disagree | One was changed without the other | Update the A record or ask for a new PTR so that they match |
| HELO is localhost or a private name | Mail software left on defaults | Set the host name in the mail software configuration |
| Several domains on one IP, one PTR | An IP can have only one sensible PTR name | Use one neutral host name for the IP; authenticate each domain with SPF and DKIM |
| IPv6 forgotten | Only IPv4 was set up | Create the reverse zone and records for IPv6, or send over IPv4 only |
Reverse DNS is not a substitute for authentication. PTR and HELO checks identify the sending machine. SPF, DKIM and DMARC identify who is allowed to send for your domain. You need both layers. See authenticating your sending domain.
A worked example: a new server with a generic name
A company moves its application to a new cloud server and sends order mail directly from it. The first messages to a large provider are deferred, and some are rejected with a note about the connecting host. Checking the headers, the team finds the IP address and runs a reverse lookup. The result is an automatic name made from the address, under the cloud provider domain. The mail software also announces a short internal host name as its HELO.
The administrator creates an A record for mail1.example.com pointing to the server address and asks the cloud provider, through its control panel, to set the reverse name to mail1.example.com. They set the same name in the mail software as the HELO. After waiting for caches, the forward and reverse lookups agree, and the test headers show the new HELO name. SPF and DKIM were already in place. Deferrals stop, although reputation for a fresh address still has to be built with a careful ramp, as in the warm-up guide. The example is illustrative.
Related checks
- Make sure the IP is not listed on a blocklist. See blocklist removal.
- Confirm that your sending domain passes SPF, DKIM and DMARC.
- If connections fail before any mail is sent, see SMTP connection and TLS troubleshooting.
- Use an encrypted connection on submission, as described in SMTP settings, ports and TLS.
Not sure who sets reverse DNS on your IP? Tell us your setup and we will explain what applies to you.
Further reading and sources
Frequently asked questions
What is a PTR record?
A PTR record maps an IP address back to a host name, the reverse of an A record. It lives in a special reverse zone, and it is normally controlled by the organisation that owns or leases the IP address, not by the owner of your domain.
What is forward-confirmed reverse DNS?
It is a check where the receiver looks up the PTR name of the sending IP, then looks up that name in forward DNS and confirms that it returns the same IP. When both match, the IP and name vouch for each other.
Do I need reverse DNS if I use a sending platform?
The platform manages it for its own shared IP addresses. You need to care about it when you run your own mail server, or have a dedicated IP address where the setup may be shared between you and the provider. Ask your provider who sets the PTR record in your case.
Why is my PTR record a generic name?
Internet and hosting providers often assign automatic names built from the IP address. Many receivers treat those as a sign of a consumer line or a poorly managed host. Ask the provider to set a name under your own domain.
What is the HELO or EHLO name?
It is the host name a sending server announces at the start of an SMTP conversation. It should be a fully qualified name that resolves in DNS, and ideally it matches the PTR name of the sending IP.
Does Gmail require reverse DNS?
Google sender guidelines ask that sending IP addresses have forward and reverse DNS records that point to each other. Missing or mismatched records can lead to rejections or spam placement.
Can I set a PTR record in my domain DNS panel?
Usually not. Reverse zones are delegated to the IP owner, so you ask your hosting or network provider to set it, often through their control panel or a support request.
How long do changes take?
It depends on the time-to-live of the old record and on caching at receivers. Often a few hours, and sometimes up to a day. Re-test after waiting, instead of changing it repeatedly.
What about IPv6?
IPv6 addresses have PTR records in a different reverse zone and need the same forward and reverse match. Some receivers are stricter with IPv6, so check both address families if you send over both.