When an inexperienced administrator sets up their own mail server for the first time, everything usually seems almost suspiciously simple. They set up SMTP, opened port 25, configured the DNS, and the emails went out. It seems like the system is working.
But then some oddities start to appear.
Sometimes Gmail sends messages to spam without explanation. Sometimes Outlook just drops the connection. And some servers respond with the message “550 5.7.1 Client host rejected: cannot find your reverse hostname”.
At this point, many people encounter the concept of reverse DNS for the first time. This concept is so old that talking about it might seem like something from the era of dial-up modems. But the problem is that mail servers still operate according to fairly conservative rules, one of which is the nearly mandatory reverse DNS check. Without it, modern email works poorly, inconsistently, or not at all. Sometimes emails get through, and sometimes they don’t. Another inconvenience is that many services don’t even directly mention that the problem lies specifically with the PTR record.
A particular irony is that the absence of reverse DNS not only directly affects email delivery but can also ruin the reputation of the IP address assigned to the mail server in literally a matter of hours, even if the server is new, clean, and hasn’t sent a single mass mailing yet.
In this article, let’s break down what reverse DNS is, how and where it’s configured, and how to work with it in general.
What is reverse DNS in simple terms
Understanding what reverse DNS is in practice is quite simple. To do this, let’s first refresh our memory on what regular DNS is.
DNS is a system that links domain names to IP addresses. It’s easy for a person to remember example.com, but servers on the network work with IP addresses. Therefore, you can think of DNS in simple terms as a large table, with all domains listed in one column and their corresponding IP addresses in the second column.
In other words, when you enter a website address into your browser’s search bar, the browser doesn’t know in advance where that site is located. It needs the server’s IP address, so the system sends a DNS query asking: “What is the IP address for the domain example.com?”
As a result, after a brief series of checks, a record is found on a particular DNS server (we’ll skip the details) that looks something like this:
example.com → 203.0.113.10
Your browser receives the IP address and then connects to the appropriate server.
Now, with reverse DNS (rDNS), everything happens in reverse. You have an IP address, and you need to find out which domain name is associated with it. And that’s what so-called PTR records are for.
Again, by analogy, you can think of the entire DNS system as a phone book. In one case, you know a person’s name and are looking for their number; in the other, you have a phone number and are trying to find out who it belongs to. That’s roughly how the difference between regular DNS and rDNS works.
Here’s what a standard DNS record looks like when an IP address is found based on the hostname:
mail.example.com → 203.0.113.10
And here’s the reverse lookup, where the server name is determined based on the IP address:
203.0.113.10 → mail.example.com
You can quickly check for a PTR record for a given IP address using the command:
dig -x 203.0.113.10
or the command:
host 203.0.113.10
And if everything is configured correctly, you’ll see the domain name in the response.
But it’s too early to stop the check here, since mail systems prefer it when forward and reverse lookups match. Therefore, after checking the PTR record, it’s useful to also check the standard (forward) DNS record:
dig mail.example.com
Ideally, this forms a closed loop where the IP points to the domain, and the domain resolves back to the same IP. This is precisely the configuration expected by many email services and anti-spam systems. Sometimes, the lack of this correspondence causes more problems than a completely missing PTR record.
Why SMTP Relies So Heavily on PTR
To understand the importance of reverse DNS, it’s worth taking a brief look at the history of email.
The first email systems appeared long before modern anti-spam filters. The Internet was much smaller, and most servers belonged to universities, research centers, and large organizations. Mail servers communicated with each other almost entirely on the basis of trust. And if a server identified itself correctly and was able to establish an SMTP connection, its emails were usually accepted without further verification.
Then the Internet grew very quickly. Botnets, mass spam campaigns, hacked servers, malware, and entire networks of infected devices emerged, sending millions of emails around the clock. Under these new conditions, email services had to find ways to quickly distinguish legitimate servers from suspicious ones.
Thus, a set of criteria gradually emerged for evaluating an email server’s reputation, and Reverse DNS turned out to be one of the simplest yet most effective criteria.
The logic here is quite straightforward. For example, if a server belongs to a company, an organization, or a regular system administrator, it is usually configured properly, following all the rules. That is, it has a domain name, the hostname is set up, DNS records are configured, SPF is working, and DKIM is enabled. A PTR record is also present because it is part of the basic set of email infrastructure.
A typical, correctly configured mail server looks something like this:
- has its own domain;
- uses a meaningful hostname like
mail.example.com; - contains a PTR record for the IP address;
- sends HELO/EHLO with a name matching the hostname;
- publishes SPF, DKIM, and DMARC.
Let’s get acquainted with these definitions right away; they’ll come in handy.
SPF (Sender Policy Framework) - a DNS record that specifies which servers are authorized to send email on behalf of your domain. It allows the receiving server to verify that the sender’s address is not forged.
DKIM (DomainKeys Identified Mail) is a mechanism for digitally signing emails. The mail server signs the message with a special key, and the recipient verifies the signature to ensure the email hasn’t been altered in transit.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email verification policy that combines SPF and DKIM. It allows the domain owner to specify what to do with emails that fail verification: accept, send to spam, or reject.
Now let’s continue.
With suspicious servers, the picture is often quite different. This is especially true for infected machines, accidentally launched SMTP services, or VPS instances used exclusively for mass mailings.
They are characterized by the following signs:
- no PTR record;
- the hostname looks like a random string of characters;
- no SPF or DKIM;
- large volumes of SMTP traffic;
- the server presents itself with strange HELO names that do not match the DNS records.
For anti-spam systems, this is a set of highly indicative signs of an illegitimate or malicious email service.
Of course, the presence of a PTR record alone does not guarantee a good reputation, since a spammer can also configure reverse DNS. But the absence of a PTR record almost always looks suspicious. That is precisely why many email services start their server checks with the simplest things: does a reverse DNS record exist, does it match the hostname, and are there any inconsistencies between forward and reverse address resolution. It is at this stage that a huge amount of junk traffic is filtered out.
What Happens Without a PTR
Most often, the problem doesn’t manifest immediately. The mail server sends messages without errors, SMTP sessions complete successfully, and the usual status=sent appears in the logs. But for some reason, the emails don’t reach the recipients.
Some emails end up in the “Spam” folder, while others receive a low trust rating. Some email services may reject the connection entirely at the message reception stage and return an error:
550 5.7.1 Client host rejected: cannot find your reverse hostname
Global email services such as Gmail, Outlook, and Yahoo, as well as corporate email gateways and popular anti-spam systems.
The most frustrating situation arises when there are no obvious errors. The email is accepted for sending, the server reports successful delivery, but actual delivery becomes unpredictable, with some messages arriving without issues while others get caught in filters.
For a typical website, this can mean losing emails from contact forms, CRM notifications, or user registration messages. In practical terms, for example for an online store, this means lost orders and customer inquiries - and thus lost revenue.
What the correct PTR configuration looks like
PTR records have one feature that often confuses beginners. They are managed not by the domain owner, but by the IP address owner.
For this reason, you won’t be able to add a PTR record through your domain’s standard DNS control panel. If you rent a server from a hosting provider or have your own server in a data center, reverse DNS configuration is done through that provider’s or data center’s control panel, as a separate service, or most often by requesting it from support.
The process itself is quite simple.
First, a standard A record is created for the mail server:
mail.example.com → 203.0.113.10
After that, a reverse record is configured for the IP address:
203.0.113.10 → mail.example.com
It is recommended to use the same name as the hostname on the server:
hostnamectl set-hostname mail.example.com
The result is a closed loop of lookups, where the domain resolves to an IP address, and the IP address returns the same domain via the PTR record.
This configuration is usually called Forward-Confirmed Reverse DNS (FCrDNS). This is exactly what many email services expect to see when verifying SMTP connections. The fewer discrepancies between the hostname, PTR record, and the domain’s DNS records, the higher the level of trust in the mail server.
How PTR is typically configured with different providers
The mechanism for configuring reverse DNS may vary among different hosting providers.
In some cases, you can change the PTR record yourself via the control panel in your account dashboard, while in others - including at 3v-Hosting - the configuration is performed upon the client’s request to customer support.
To do this, you usually need to specify:
- The server’s IP address;
- the domain name for the PTR;
- and, in some special cases, confirmation of the existence of an A record. But this is more of an exception.
After updating the DNS, the changes usually take effect within a few minutes or hours.
It is also important to understand that a PTR record is almost always linked to only one domain, meaning one IP address corresponds to one primary reverse DNS hostname.
Features of Email on a VPS
On standard virtual hosting, email-related issues are usually already handled by the provider. Mail servers are configured, PTR records are set up, and IP address reputation is managed centrally.
However, the situation is different with VPS servers. The administrator gains virtually full control over their server, and with it, the responsibility for configuring the email infrastructure.
Therefore, it’s not uncommon for a scenario to arise where Postfix or Exim seem to be working, emails are being sent, but no one even thought about the PTR record. In such cases, the problem may not be detected right away. It’s just that one day, for example, notifications from WordPress stop coming in, messages from the CRM start ending up in spam, and some recipients don’t see the sent emails at all.
There’s another point that often raises questions. Even if the PTR is configured correctly, outgoing mail may still not work. And this isn’t necessarily a mistake or oversight on the provider’s part.
Moreover, this practice has long been an industry standard.
Many VPS and cloud providers limit outgoing SMTP connections, especially on new servers and new accounts. The reason is quite simple: most of the world’s spam is sent from hacked servers and virtual machines. If any new VPS were allowed to send email to the entire internet without restrictions, the IP subnet would very quickly end up on blacklists.
For this reason, providers implement additional checks, temporary restrictions, or require a separate request to unblock mail ports. This policy protects not only the provider’s infrastructure but also regular customers who use it for legitimate purposes.
Therefore, for a mail server to function properly, several conditions are usually required: a valid PTR record, configured SPF, DKIM, and DMARC, as well as no restrictions on outgoing SMTP connections from the platform where the VPS is hosted. If any of these elements are missing, email delivery issues are quite possible even with an outwardly correct server configuration.
PTR and Mass IP Blocking
But PTR records are needed not only to verify individual mail servers. They have long been one of the tools for combating spam at the level of data centers, hosting providers, and major email services.
The problem is that a significant portion of spam on the internet is sent not from some special servers operated by malicious actors, but from ordinary VPS servers. A server is rented in a matter of minutes, email software is installed on it, and then mass mailings begin. Sometimes these servers don’t even belong directly to spammers - they can be hacked virtual machines or compromised websites.
Email systems have long been able to detect telltale signs of such nodes, and one of them is precisely the absence of a PTR record or its poor quality.
If a server attempts to send thousands of emails without a valid reverse DNS, this looks suspicious even before the message content is analyzed. In some cases, just a few such red flags are enough for the IP address of the server sending the emails to develop a negative reputation.
From there, the mechanism kicks in quite harshly.
First, emails from this server start ending up in spam more frequently. Then the IP may end up in one of the reputation databases or DNSBL lists, such as the Spamhaus SBL. After that, other email systems begin automatically checking this address and lowering their trust level for messages. In severe cases, new connections from this IP may be rejected even before the email is transmitted.
Special attention is paid to the hostnames themselves. For example, PTR records like:
ip-203-0-113-10.provider.local
or
vps123.hosting.internal
are usually created automatically during server setup and reveal little about its owner.
For email systems, names associated with a real domain look much more credible:
mail.example.com
smtp.example.com
mx1.example.com
Such a hostname indicates that the server didn’t just receive an IP address and start sending email, but was configured by an administrator as part of a full-fledged email infrastructure.
Of course, a PTR record alone won’t save you from being blacklisted, since if spam is coming from the server, it will still be blocked sooner or later. And rightly so. But the absence of a PTR record or a random hostname often serves as the first red flag, causing trust in the IP address to decline even before actual complaints about mailings surface. In such cases, the provider may again restrict outgoing mail traffic or even refuse service altogether if your server’s IP address is constantly ending up on spam lists.
A similar situation arises after obtaining a new VPS. The administrator configures PTR, SPF, DKIM, and other records, but emails still have poor delivery. The reason may lie in the history of the IP address itself. IPv4 addresses have long been a scarce resource, so providers constantly reallocate them among clients. If the previous owner used the server for spam campaigns or its IP was added to reputation databases, the consequences can persist long after the address is transferred to a new client. In such cases, you must not only configure the email infrastructure but also work on restoring the IP’s reputation or request a replacement from the provider. Sometimes the problem turns out to be broader and affects an entire range of addresses or even the entire data center network. Therefore, the presence of a PTR record should be considered a prerequisite for email operation, but by no means the only check that modern email services undergo.
PTR is only part of the email infrastructure
Back when anti-spam filters were much simpler, having a PTR record was already considered a good sign of a properly configured server. But now, that’s clearly not enough.
Modern email systems evaluate not just a single parameter, but the entire infrastructure as a whole. They check the domain, IP address, sending history, DNS records, SMTP settings, and a host of indirect indicators that reveal how trustworthy the server is. Essentially, PTR today is in roughly the same position as HTTPS is for a website. Its presence surprises no one, because it’s a basic requirement. But its absence almost immediately raises questions.
The minimum configuration for a mail server typically includes a valid PTR record, hostname, SPF, DKIM, DMARC, valid MX records, TLS for SMTP, and a clean IP address reputation. All of these elements work together as a unified system, and if even one is missing, the likelihood of email delivery issues increases.
For this reason, when diagnosing email issues, it’s always helpful to look at the big picture. For example, a server might have a perfect PTR record but be on blacklists. Or conversely, it might have a flawless IP reputation but use an incorrect hostname.
By the way, the hostname is often the source of problems for novice administrators.
So you’ve set up the server, launched the website, installed SSL, configured Postfix or any other email service, published SPF records in DNS, and so on. At first glance, you’ve done everything right. But then it turns out that the server is still using a name like:
ubuntu
localhost
vps123
or doesn’t have a PTR record at all.
At the same time, email might work partially. Messages reach one address, end up in spam on another, and a third mail server completely rejects the connection. This situation can go unnoticed for weeks because test emails sent to your own Gmail account often go through successfully.
Checking the basic settings is quite simple. To check the PTR record, simply run the following command in the console:
dig -x YOUR_IP
or:
nslookup YOUR_IP
After that, it’s helpful to check the domain’s direct DNS record and ensure it points to the same IP address. Then, check the server’s hostname:
hostname -f
In an ideal configuration, the hostname, PTR record, and domain DNS records should refer to each other without any conflicts - we’ve already discussed this in more detail above.
Email remains one of the most conservative technologies on the internet. Many verification mechanisms were devised decades ago and are still used today under the “if it works, don’t fix it” philosophy. And Reverse DNS is precisely one of those mechanisms. Of course, it has long ceased to be the sole criterion for trusting a mail server, but without it, a fully-fledged email infrastructure still looks incomplete and raises doubts.
FAQ
Is it possible to send email without a PTR record?
Technically, yes. But in practice, many email services treat such messages with suspicion, so they often end up in spam or receive a low trust rating.
Are PTR and reverse DNS the same thing?
Almost. Reverse DNS is a mechanism for looking up a domain name by IP address, while PTR is a specific record that enables it to work. Although in everyday practice, these terms are often used as synonyms.
How long does it take for a PTR record to update?
Usually anywhere from a few minutes to a few hours. Sometimes changes take longer to propagate due to various DNS caches at ISPs and email service providers.
Is a PTR record necessary for a regular website?
For a website to function, it’s usually not necessary. However, for a mail server, it’s almost always required if you want normal email deliverability.
Why does Gmail send emails to spam even when a PTR record is present?
Because, as we’ve discovered, PTR is just one of many checks. Gmail also evaluates SPF, DKIM, DMARC, IP address reputation, and email sending history.
Can you configure PTR yourself?
It depends on the provider. In some cases, you can change the PTR record via the control panel, while in others, you’ll need to contact support.
Conclusions
So, the PTR record is one of those settings that people usually only remember after email problems arise. It doesn’t affect server performance, doesn’t make the site faster, and doesn’t change how applications work in any way. Yet it is precisely these small details that email systems use to assess how trustworthy a server is.
Today, reverse DNS is among the basic requirements for any email infrastructure. The absence of a PTR record won’t necessarily lead to immediate delivery failure, but it will almost certainly create unnecessary problems and reduce trust in the messages being sent.
If the server is used for corporate email, sending notifications, running CRM, WordPress, or any other software that sends emails, then checking the PTR record should be as standard a procedure as configuring SPF, DKIM, or a TLS certificate.
The Internet’s email system is still built on reputation and trust. And very often, this trust depends on settings that users will never see, and that administrators only remember when emails stop reaching their recipients.
