As i understand problem is not related to virtualmin, but i am sure most (if not all) of you had to configure mail, so you may know where is problem.
When i am checking for problems on mxtoolbox, i get one warning:
Category: smtp
Host: mail.domain.com
Result: Reverse DNS is not a valid Hostname
And here is what they say when i press More Info:
More Information About Smtp Valid Hostname
Your 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.
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.
Not really. The rdns should ideally be set to the hostname of Virtualmin and the hostname of Virtualmin 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.
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.
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.
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 Virtualmin 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.
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.
In my experience, it can cause incoming mail problems when using SNI if the PTR doesn’t point either to the hostname or mail.hostname.
I had one dude at a DC set rDNS to one of the domains on a server years ago, and that was the only domain that could receive mail. They could all send, but not receive. Maybe it was quirky to their setup, but it was the case nonetheless. Setting it to the hostname solved the problem.
I think sometimes in your case, and certainly in mine, we base our assumptions (and advice) on the way things were in the past.
The problem I described above happened shortly after I built a site that started getting overwhelmed with traffic – enough so that I had to upgrade the server. It took me by surprise because it was a niche site that I thought would get hardly any traffic at all. I decided to lease a new server and migrate all the sites to it.
The first site I migrated was the new one, and when I asked the DC to set up rDNS, that’s where they pointed it. Everything seemed okay; but when I moved the other sites over, they couldn’t receive mail. This was using SNI with Exim and Courier on cPanel.
I had the hosting company change rDNS to point to the hostname, and that fixed the problem.
But get this: I just glanced at that site to check an ad in the footer, and the original copyright was in 2003. So all this happened in 2003, or maybe 2004. I know it was a few months after I built the site. Either way, SNI was still brand-new.
Nonetheless, I adopted a habit, as you apparently did as well, of always specifying that PTR be set up for the hostname. Maybe it doesn’t matter anymore, 18 years later. But tempus fugit, and old habits die hard.
I think one of those habits has been allowing ourselves be intimidated by RFC jargon and online testing tools. For years I’ve used the server hostname for rDNS and SMTP greeting and if that’s all it takes to get MXToolbox to shut up, I don’t mind going along.
Sure, if you have control over your rDNS, go for it. It’s tidier to have it match the hostname you use for your server (and the SMTP greeting), but it doesn’t much matter from a technical perspective. Nobody treats it as a spammy characteristic, as far as I know, and if your other stuff (DKIM, etc.) is right, mail will work fine.
That was a virtual maps issue, not rDNS. The mail server didn’t know it was the destination for those domains. But, if you’re going to set it to one of the domains in the virtual map, I think you will have other issues you need to sort out (“mail loops back to itself”, possibly).
To be clear: There is no harm in making it match your server FQDN. It may even make you happier, if that sort of thing matters to you. But, it won’t impact mail delivery or sending in any way that I’m aware of (and I have several servers sending mail with PTR records that are unrelated to any domain sending or receiving mail on the server…because I simply do not care about PTR records, as long as they point to a name that points back to the IP).
Edit: I’m just saying, don’t make this complicated. No need to agonize over things that don’t matter, when there’s so much unavoidable complexity everywhere else.