[BUG] Wrong configuration for rDNS

[Oceanwatcher]

rDNS should be configured with the domain name used by the mailserver. This means that for each domain on a shared host, it should be different. Right now, it is picking up the hostname of the server. This can result in emails getting rejected as spam as it is one of the criterias that Spamassasin might be testing for.

It does not matter if you use Cloudflare as mail.domain.com can not be proxied. This means that the CyberPanel rDNS is used for mail. There is no way of setting it on Cloudflare.

To Reproduce Send an email from any domain on the server using this service:

https://www.mail-tester.com

Expected behavior The mail server should pass all tests here with flying colors

CyberPanel version:

Current Version :
2.3 Build :
2 Current Commit :
76d6284f4b143224737f137aae3ed1ed611b8f84

[lsthompson]

Reverse DNS has nothing to do with the VM nor Software. It must be set by the IP Address provider.

Some providers will let you make the PTR (rDNS) record change online without having to Ticket them.

So I think this needs to be Closed. You likely need to raise a Support Ticket with your VPS/etc provider.

[Oceanwatcher]

When you are running CyberPanel on a VPS, the CyberPanel is the only DNS on that VPS. And unless you have a way to set this outside of CyberPanel, this should be controlled from CyberPanel.

I think this should stay as a bug/feature and it should be supported in CyberPanel.

[lsthompson]

Negative. Unless there's a very unique situation in-place, having the CyberPanel GUI linked in any way to the VPS provider (beyond the Operating System, into the actual Company/Network behind it) doesn't make real sense.

When are you going to need frequent updates to your Reverse DNS record? It's not something that's really done.

You "set and forget", and this is done at your Virtual Server provider. They will likely have a Knowledgebase article for this very thing. Sometimes you will need to raise a Support Ticket, get it set, establish FCrDNS and you're sorted.

[Oceanwatcher]

Also, it can not be set by the IP provider as it has to follow the domains in CyberPanel. Right now it is set to the HOSTNAME of the VPS. This is not correct, and it triggers anti spam software. It needs to be equal to the domain.

[lsthompson]

@Oceanwatcher the requirement is Forwards-confirmed Reverse DNS (FCrDNS).

You need to have the Forwards record (A) configured properly, then request for the Reverse record (PTR) to be set.

To clarify, Forwards DNS (A/CNAME/etc) is on the VPS itself through CyberPanel. Reverse DNS is at the Provider.

[Oceanwatcher]

And how will the provider DNS handle 25 different domains on the VPS?

[lsthompson]

Does the VPS have 25 different IP addresses running on it?

PTR/rDNS records are per-IP, not per-Domain.

[Oceanwatcher]

I beg to differ. rDNS is per domain. It has been like that for all servers I have used via cPanel. Using a shared IP means you have to set it differently for each domain.

[lsthompson]

No. Please check the RFCs/Documentation/etc. Reverse DNS is per-IP.

In the case of a Shared Server, the Reverse DNS would equal the machine's hostname (typically).

dig -x will return the Reverse DNS record for the IP Resource queried. You can consult the dig manual for this.

Reverse lookups - mapping addresses to names - are simplified by the -x option. addr is an IPv4 address in dotted-decimal notation, or a colon-delimited IPv6 address. When this option is used, there is no need to provide the name, class and type arguments. dig automatically performs a lookup for a name like 11.12.13.10.in-addr.arpa and sets the query type and class to PTR and IN respectively. By default, IPv6 addresses are looked up using nibble format under the IP6.ARPA domain.

https://linux.die.net/man/1/dig

[Oceanwatcher]

Some kind of a beginning would be to at let us choose a FQDN for the rDNS record. Having a HOSTNAME make it fail. I have no idea what happens if the rDNS does not match any of the MX records on the domain. It would be worth trying to add an MX recorder with priority 99 so it should not come into play...

[Oceanwatcher]

Checking your dig manual, it is totally clear that it has to resolve to a domain, not a hostname.

[Oceanwatcher]

Does your corporate server host multiple domains? If it does, and it uses hostname in rDNS, please use an email address on that server and test it against the tool I mentioned in the first posting here.

[lsthompson]

CyberPanel does not and should not have any bearing over PTR/rDNS. In some cases, you could integrate if you wanted.

As above, please re-think how Reverse DNS functions and approach your provider to assist with setting your PTR record/s.

I have no idea what happens if the rDNS does not match any of the MX records on the domain.

With MX records, I think you are being overly strict in what you deem to be required for email deliverability. Your sending email server needs to have FCrDNS, but this does not have to mean your MX records need to as well. As your provider is likely to want the Forwards component set firstly, you need to ONLY create the Forwards/A record before ticketing them. From there, they will check that you've created the A record (the "hostname"), and will create/amend your PTR record/s.

Checking your dig manual, it is totally clear that it has to resolve to a domain, not a hostname.

You seem to be taking "domain" very literally. What dig returns depends on what is set in the PTR record. A hostname could arguably be the same length in domain parts as a regular domain name (ie. example.com rather than server.example.com). If you aren't willing to consider what I'm saying, I can't help you. Sorry.

If it does, and it uses hostname in rDNS, please use an email address on that server and test it against the tool

It does. Wants a list-unsubscribe which isn't relevant. Happy days. We send a lot of emails and all's well.

"Wow! Perfect, you can send"

[qtwrk]

You have misunderstood the rDNS

what you talk about is the SSL cert for SMTP and actual domain

I am not expert on mails, but if I understand it correctly and remember it correctly:

when you send mail , it is always using the server hostname , only when receive it , it goes to what MX record designated

so you just need to allow that hostname in your SPF

like I have 3 domains , imagine they are domain1.com , domain2.com , domain3.com on this server , and I name this server like server1.cyberpanel.net

then I just need to set SPF record on these domain1-3 domains to server1.cyberpanel.net , and make server IP rDNS to server1.cyberpanel.net

and as above @lsthompson mentioned , there is no way you can set (multiple) rDNS to 1 IP from panel side , most provider may not provide such API , and even there is , it's very pointless to do such integration , as this is most likely one-time operation

[Oceanwatcher]

So from what I can see, it should at least match the HELO hostname?

[Oceanwatcher]

Ok. So I have the rDNS part wrong. But I still get an error - the HELO address and the rDNS does not match.

[lsthompson]

Your hostname needs to be consistent. Operating System, Email Server/MTA & rDNS/PTR need to match.

So work through them. At an SSH prompt, what does cat /etc/hostname give you? That's your OS.

Then you need to make sure CyberPanel and the MTA (Email Server software) are set the same.

From there, you need to have your hostname DNS (A) record set, then ticket for your PTR.

It might then take a little while for tools to verify this, as DNS Propagation can take a while.

[Oceanwatcher]

I will talk to to the VPS owner about it :-) Thank you. And yes, this can be closed.

[Oceanwatcher]

Sorry for being so stubborn!

[lsthompson]

Not at all, glad we got there! :-)

[usmannasir]

Alright, I will close this now. thanks everyone for jumping in.