What Is a PTR Record? Reverse DNS and Why Email Needs It

What is a PTR record?

A PTR record (pointer record) is a DNS record that maps an IP address to a hostname. People also call it reverse DNS or rDNS. An A record turns a name into an IP, while a PTR record turns an IP back into a name. In short, mail servers use it to check who is connecting.

We are a digital marketing and web team, not a hosting company. So we built this guide on RFCs and on the official documentation from Google and Microsoft. Also, the commands are there for readers who run their own server. If you use shared hosting, your provider handles most of these steps for you.

A phone book is a handy comparison. A normal directory finds the number for a name. In a reverse directory, you find the name for a number instead. A PTR record is that reverse directory. When a server says "I am mail.example.com" during an email session, the receiver can look up the number and see whether the name really belongs to it.

Your website does not need a PTR record to load. Browsers turn a name into an IP, so they never ask the reverse question. However, the record matters most on servers that send email. Below, we explain how it works, who sets it, and how to check it.

What is the difference between a PTR record and an A record?

An A record maps a hostname to an IPv4 address, and an AAAA record does the same for IPv6. A PTR record runs in the opposite direction. In other words, the two records describe the same link from opposite ends. However, they live in different DNS zones and usually belong to different people.

First, the key difference is ownership. You manage the A record in the DNS panel of your domain. The PTR record sits in the zone of whoever owns the IP address. Therefore you will not find it in your domain registrar's panel. The table below also sums up the differences.

The two records complement each other. Neither is enough alone, because a receiving server often compares both.

How does reverse DNS work with in-addr.arpa?

IPv4 reverse lookups go to a special branch of the DNS tree called in-addr.arpa. RFC 1035 describes this design in section 3.5. First you write the four numbers of the address in reverse order. Then you add in-addr.arpa at the end.

For example, take 203.0.113.25 from the documentation range. Its reverse name is 25.113.0.203.in-addr.arpa. The order flips because DNS reads names from right to left, from general to specific. IP addresses, however, put the general part on the left. Reversing the numbers makes the two systems line up.

A resolver then asks for a PTR record at that name, and the answer is a hostname. In our example, then, it could be mail.example.com. Your computer or the receiving mail server sends this query through its own resolver.

In practice, the owner of the IP block controls the reverse zone. Address blocks pass from regional registries to providers, and from providers to customers. So reverse DNS authority follows the same chain.

How do you write the ip6.arpa name for an IPv6 address?

IPv6 reverse lookups use the ip6.arpa domain, which RFC 3596 defines. The unit here is a single hexadecimal digit, also called a nibble. First, you expand the address fully, separate every digit with a dot, and reverse the order.

For 2001:db8::25 from the documentation range, the reverse name looks like this:

5.2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

Writing this by hand invites mistakes. For that reason the dig -x command converts the address for you. Also, if your server sends email over IPv6, the IPv6 address needs its own PTR record. Many people fix only the IPv4 record, then wonder why some messages still bounce.

We cover the broader IPv6 picture in our guide on what IPv6 is. You can check your own site with our IPv6 test tool.

Who sets a PTR record, and why is your domain DNS panel not enough?

The owner of the IP address sets the PTR record. In most cases that is the hosting, VPS or cloud provider you rent the server from. The company where you bought your domain does not manage the in-addr.arpa zone. So trying to create a reverse record there will not work.

Providers hand out this control in two ways. Some offer a "reverse DNS" or "rDNS" field in the panel, where you type the hostname. Others, however, ask you to open a support ticket. Check your provider's documentation to see which applies to you.

Small blocks add one more detail. RFC 2317 explains how providers delegate reverse DNS for blocks smaller than a /24. The provider handles that part, so you do not need to. Usually you only tell them which hostname you want.

If you do not know who owns an IP, start with our IP lookup tool to see which network the address belongs to. Then the network owner points you to the right contact. To see how hosting companies run their networks, read our ASN and BGP guide.

What is forward-confirmed reverse DNS (FCrDNS)?

FCrDNS is a two-way check. First you take the hostname from the PTR record of an IP. Then you look up the A or AAAA record of that hostname. If the result is the same IP you started with, then the match is complete.

In short, the logic is simple. If receivers trusted the PTR record alone, the IP owner could write any name, even someone else's domain. The A record, however, sits in the hands of that domain's owner. So when both records confirm each other, forgery gets much harder.

RFC 1912 section 2.1 points the same way. It advises that your PTR and A records match, and that a PTR record should point to a valid A record, not to a CNAME alias. The document is informational. Still, it lines up with what receivers expect.

Also, Google's sender guidelines ask for the same match. The sending IP needs a PTR record that resolves to a hostname, and that hostname needs an A or AAAA record with the same IP. So a one-way PTR record often falls short.

Why should your HELO or EHLO name match the PTR record?

A mail server introduces itself with the EHLO command (or the older HELO) as soon as it connects. RFC 5321 says the argument should hold the fully qualified domain name of the client. If no name exists, then the client should send an address literal. When this name agrees with the PTR name, your server looks consistent.

The standard strikes an interesting balance. A receiving server may check that the EHLO name corresponds to the client IP. However, if that check fails, the server must not refuse the message on that basis alone. Instead, the standard treats the result as information for logging and tracing.

In practice, receivers can be stricter than the standard. Microsoft's own support article says that some recipient servers require the HELO name to have a matching PTR record. So the safest path is to line up three values: the PTR name, the A record and the EHLO name.

If you run Postfix, the relevant settings are myhostname and smtp_helo_name. Then you can read the current values with this command:

postconf myhostname smtp_helo_name

Whatever MTA you use, confirm the setting name in its official documentation. We explain the MTA concept in our guide on what a mail transfer agent is.

Why does a PTR record matter so much for email?

It matters because the record is a cheap but useful clue that a sending server runs properly. Spammers often use throwaway or hijacked machines. Those machines usually have no reverse DNS, or they carry a generic name. So receivers use that gap as a filter.

Google's sender guidelines, for example, speak plainly. The public IP address of a sending SMTP server must have a PTR record that resolves to a hostname. That name must also resolve back to the same IP through an A or AAAA record. The guidelines also tell you to set up valid reverse DNS for your sending IPs.

Microsoft also shows a similar logic. According to Microsoft's support article, the sending IPs of Microsoft 365 have forward-confirmed reverse DNS. The article also notes that some recipients check the HELO name against PTR records, which can cause rejections.

We should be clear about one limit, though. A PTR record alone does not guarantee delivery. Receivers weigh content, reputation and authentication signals together. Even if everything else is perfect, a missing PTR record can still cause trouble.

Will a missing PTR record get your email rejected or sent to spam?

In practice, either can happen. Depending on the receiver's rules, a server may reject the message at connection time, accept it and file it as spam, or lower its score and weigh other signals. However, which one you get differs from receiver to receiver.

The symptoms usually look like this:

• Some recipients send back bounces that say the hostname does not match the IP or that no reverse DNS exists.
• Messages from the same server land in spam only at certain recipients.
• The first messages from a freshly built VPS bounce for no obvious reason.

The code and wording of a bounce differ between receivers. So instead of looking for one exact text, search the message for words like "reverse DNS", "PTR" or "hostname".

If you see such a sign, then diagnose in order. First check the PTR record, then the A record, then the EHLO name. If all three agree, you can assume the problem lies somewhere else.

How do you check a PTR record with dig -x?

The -x option of dig turns an IP address into its reverse name and sends the PTR query for you. Adding +short, for example, trims the output to the answer. Let us try it with an IP from the documentation range:

dig -x 203.0.113.25 +short

The output is a hostname that ends with a dot: mail.example.com. The trailing dot also shows that the name is fully qualified. If the output is empty, no PTR record exists for that IP.

In the second step you confirm the forward direction:

dig mail.example.com A +short

If the returned IP equals the one you started with, the match holds. The same approach works for IPv6, so you can run dig -x 2001:db8::25 +short. So if your server sends over both protocols, test both.

To see where the record comes from, add +trace to the dig -x command. That way you follow the query from the root servers down to the authoritative server. You can check the records on your domain side with our DNS lookup tool.

How do you query a PTR record with nslookup?

If you use Windows, or dig is not installed, nslookup does the job. You type the IP address and the tool runs the reverse query itself:

nslookup 203.0.113.25

The output includes a line in the form "name = mail.example.com". The name at the start of that line is the reverse form of the IP. If no record exists, then the tool prints an error such as "Non-existent domain".

If you prefer to set the type, you can write the reverse name yourself:

nslookup -type=PTR 25.113.0.203.in-addr.arpa

This form is a good exercise for learning how the reverse name is built. For daily use, the first command is more practical. On Linux and macOS, the host command does the same job, so host 203.0.113.25 is enough.

However, keep one point in mind. The resolver you query may cache answers. For example, if you just changed the record, you may still see the old answer. Then wait for the TTL to run out or try another resolver.

How do you add or change a PTR record?

The steps differ a little between providers, but the logic stays the same. The sequence below is a general roadmap for readers who run their own VPS.

1. Find the IP your email really leaves from. The outgoing IP of a server can differ from the one in your panel, so read the Received lines in the message headers.
2. Next, pick the hostname you will use, such as mail.example.com. A subdomain of your own domain keeps the identity consistent.
3. Then create an A record (and an AAAA record if you use IPv6) for that name in your domain DNS panel, and point it at the sending IP.
4. In your provider's panel or through a support ticket, ask for the PTR record of the IP to be set to that name.
5. Also set the EHLO name of your MTA to the same name.
6. Verify both directions with dig -x and dig A, because one direction alone proves little.
7. Finally, send a test message to your own address and read the results in the headers.

Keep your message to the provider short and clear: "Please set the PTR record of 203.0.113.25 to mail.example.com." That way both sides understand in one sentence. For domain setup, see our guide on business email with a custom domain.

How do you write a PTR request to your provider?

When you open a support ticket, complete information shortens the process. Providers, for example, tend to ask the same questions every time. So if you answer them up front, the exchange often ends in one message. Include these details:

• The IP address that needs the reverse record (IPv4, and IPv6 if you have it).
• The fully qualified hostname you want.
• A note that the A or AAAA record for that name is ready.
• The fact that the server sends email.
• Your current dig -x output.

A sample request could read like this:

Hello, could you set the reverse DNS record of 203.0.113.25 to mail.example.com? We already created the A record, and it points to the same IP. This server sends email from that address.

The provider may, however, suggest a different name. In that case, remember to add the A record for the suggested name. After all, the match depends on both sides being right.

How long until a PTR record change takes effect?

It depends on the TTL of the record and on the caches of receivers. TTL tells resolvers how many seconds they may keep an answer. Even after the provider updates the record, some resolvers can keep serving the old answer for a while.

We cannot give an exact time, because the value differs between providers. Instead, we suggest this: if possible, ask your provider for the current TTL before you change the record. Then, after the change, run dig -x against a few different resolvers.

Also, do not send the test message right away. First make sure the two-way lookup gives consistent output, then run the test. That way you will not misread the result of a half-finished change.

How does a PTR record differ on shared hosting and a VPS?

The difference comes from who owns the IP address. On shared hosting, the mail server and the IP belong to the provider's shared infrastructure. So you do not control the PTR record. The provider manages it to its own standards, and you simply use the right mail server.

On a VPS, the IP address is allocated to you. Most providers let you set reverse DNS in the panel or through support. However, the responsibility moves to you as well. Therefore you keep the MTA, the EHLO name and the records correct. We explain the difference between VPS types in our guide on VPS, cloud server and VDS.

It pays to ask about this when you pick a host. For general selection criteria, read our guide on how to choose web hosting.

What does a shared IP mean for PTR and reputation?

A shared IP means several customers send email from the same address. Receivers measure the reputation of an IP by the history of all mail from it. If a neighbor sends spam, your own messages can suffer even when they are clean.

The reverse record plays a double role here. The PTR record of a shared IP usually carries the provider's generic name. That is normal, so it rarely bothers a receiver. However, the name has no link to your domain, so you cannot build brand identity through PTR.

A dedicated IP, however, changes this. The IP belongs only to you, so the reputation does too. Moreover, you can point the PTR record to a subdomain of your own domain. Still, a new IP starts with no reputation, so ask your provider or email service how warm-up works.

In short, our advice is simple. For low-volume transactional email, the infrastructure of your provider or a trusted email service is often enough. As your volume and your need for control grow, you can consider a dedicated IP.

What are the most common PTR record mistakes?

Most mistakes fall into a few patterns. The table below lists them with their symptoms. Nearly every fix comes down to one idea: line up the three values.

The last row needs care. If you use a CDN or proxy service, the A record of your mail name must resolve straight to the server IP, not through the proxy. Otherwise the A record will not show the sending IP.

How does a PTR record work when one IP serves several domains?

One PTR record per IP is the healthiest setup. The name describes the server, not your domains. If the same server sends mail for example.com and for other domains, the PTR record still carries the name of the server, such as mail.example.com.

Receivers verify the identity of each domain elsewhere. Every domain carries its own SPF, DKIM and DMARC records, and the receiver uses them to match a message to its sending domain. In short, PTR answers "who is this server?", while the other records answer "on whose behalf is this message?".

Several PTR records on one IP are sometimes technically possible. Yet some receivers treat that as ambiguous and use the first record they see. So keeping a single record for each sending IP is safer.

Also remember this when you move a server or change an IP. The new IP does not inherit the PTR record of the old one, so plan for it. Add "PTR and A record for the new IP" to your migration checklist.

Where else is reverse DNS useful?

Reverse DNS is not only about email. For instance, many network tools, such as traceroute, run reverse lookups to show readable names for the hops on a path. Server logs are also easier to read with names than with strings of numbers.

Another well-known use is verifying crawlers. Google Search Central describes how to confirm that a visitor claiming to be Googlebot really comes from Google. You run a reverse DNS lookup first and a forward lookup after it. The logic matches the FCrDNS check in this guide.

On the other hand, search rankings do not need a PTR record. Everyone who visits your website resolves a name to an IP and never asks the reverse. So if you only publish a website, you do not have to worry about reverse DNS.

When should you not set up a PTR record yourself?

Let us be honest. In many cases the best decision is to leave the job to your hosting provider. Do not tinker on your own in these situations:

• You use shared hosting. The PTR record and the mail server sit under the provider's management.
• You do not know who owns the IP address. Find the owner first.
• You plan to migrate a production mail server alone. One wrong setting, for instance, can hit all company email.
• You do not know how to connect over SSH or read DNS records.
• Your provider does not let you manage reverse DNS. In that case, open a support ticket.

If a developer or system administrator works with you, hand them the checks in this guide as a list of questions. When your website, store and email integrations need joint planning, we cover these topics within our web design service.

If you run a small business and email delivery is critical, consider an external email service as well. Such services, for example, manage details like reverse DNS for you.

Does a PTR record replace SPF, DKIM and DMARC?

No, it does not. The PTR record proves the IP identity of the server. SPF lists which IPs may send for a domain, DKIM signs the message, and DMARC tells the receiver what to do when those checks fail. The four parts work together.

Google's sender guidelines also reflect this. Reverse DNS is one item, and email authentication is a separate one. In short, if one is missing, another cannot fill the gap.

We do not repeat the SPF, DKIM and DMARC details here. You can test your records with our SPF, DKIM and DMARC checker. If your site sends email from WordPress, our WP Mail SMTP guide is a practical start.

In practice, our suggested order is this. First line up reverse DNS and the A record. Then set up SPF and DKIM. Finally, tighten the DMARC policy. Do not move to the next step before you verify the current one.

What is the final PTR record checklist?

Run through the list below before you go live. You can confirm each item with one command or one panel screen.

• You identified the sending IP and confirmed it with the message headers.
• The dig -x result gives the fully qualified hostname you chose.
• That name's A or AAAA record points to the same IP.
• Your PTR record points to a name with an A record, not to a CNAME.
• The EHLO name of the MTA uses the same name.
• If you send over IPv6, you ran the same check for IPv6.
• The mail name does not sit behind a proxy.
• You tested the SPF and DKIM records too.

The list looks short, but in practice it prevents a large share of email delivery problems. If you still get stuck, send your provider's support team the query output above. With that output, then, you can often settle the issue in two messages.

This guide gives general information, and your hosting provider's rules take priority. For provider-specific settings, use the values your provider gives you.