As i understand problem is not related to, but i am sure most (if not all) of you had to configure mail, so you may know where is problem.

You are watching: Reverse dns is not a valid hostname

When i am checking for problems on mxtoolbox, i get one warning:Category: smtp Host: Result: Reverse DNS is not a valid Hostname

And here is what they say when i press More Info:

More Information About Smtp Valid HostnameYour Reverse DNS Record (PTR) is not a valid host name. According to email sending best practices, a PTR Record should be a valid host name. If the PTR Record is not a valid hostname, there is a likelihood that you will experience email delivery issues with anti-spam services.

Any ideas how to fix this warning?

jurgis January 9, 2021, 12:28pm #2

Problem solved.In Reverse DNS Management must be not simply

ramin January 9, 2021, 8:00pm #3

You should be good to go if the reverse DNS lookup matches the SMTP greeting. The way I do it is fairly typical: a mail sending domain on the server’s IP is also used for the server hostname, and the hostname is used for rDNS and SMTP greeting.

calport January 9, 2021, 8:49pm #4

In Reverse DNS Management must be not simply

Not really. The rdns should ideally be set to the hostname of and the hostname of should (must!) be a subdomain - e.g. vps.domain.tld

I fear
jurgis that something is amiss with your configuration if reverse DNS must be set to mail.domain.tld for it to work on your system.

1 Like
jurgis January 9, 2021, 11:16pm #5

I did all tests on mxtoolbox and i have no errors, or warnings = everything passed.if reverse DNS is not configured correctly, then something shouldn’t work, right?what shouldn’t work? how can i test?

P.S. and ignore “must be”. Maybe it shouldn’t be like that (ideally), but this change fixed warning on mxtoolbox and for now i don’t see any negative effect.

RJM_Web_Design January 11, 2021, 12:19am #6

mxtoolbox tends to focus on problems that will affect mail delivery; and most mail admins merely require that rDNS be valid, meaning that the IP resolves to some valid and verifiable FQDN on the server.

But “valid” isn’t the same thing as “correct.” The preferred way to do it is for rDNS to point to the hostname.

Strictly speaking, the only times you’d want rDNS to point to mail.domain.tld would be either if that’s also the hostname, for example, a dedicated mail server; or if the mail server runs on its own IP, even if it’s hosted on the same phsyical server as Web, etc.


Joe January 11, 2021, 1:07am #7

A lot of incorrect info here, though all with good intentions.

So, you need a PTR that resolves to a name that works.

The PTR does not need to resolve to the name you use for your server (the FQDN that you set to make install happy). It does not need to resolve to a domain you own/control. It does need to resolve back to the right IP address when its A record is looked up.

Here’s the most important thing: You probably don’t have any control over your PTR unless you explicitly request it from your hosting provider/colo/ISP/whatever. And, that does not matter, as long as the previous paragraph is true.

See more: Coconut Bowls And Wooden Bowl And Spoon Sets, Coconut Bowls And Wooden Spoon Set

In short: Lookup your IP address with the host command. Does it have a fully qualified domain name? It absolutely does not matter what that name is, it just needs to resolve to an FQDN. And, does that FQDN resolve back to the IP address? That’s it. That’s all you need. If your host gets that right, don’t fuck with it. If your host gets it wrong, or there is nothing returned, ask them to delegate to you so you can create a PTR for it (or give them a name to use for the PTR, whatever makes them happiest). You don’t care about PTRs except to know that you have one for your IP and that it resolves back to the right IP in the other direction. Don’t make it more difficult or complicated than it needs to be.