Mail Hostname Issue

Hey, I have a couple of issues I want to clarify. I want to clarify that I have created glue records on my Domain Registrar and managing DNS on Hestia.

My Server hostname is for accessing hestiacp. I have added as a website, DNS and Mail Domain. Hestia says my mail hostname will be

However, everything looks screwed in my settings. my mail helo and hostname is returning as instead of, SPF record shows it’s sending from and mx record points to

Thing is, I didn’t change the DNS settings or anything in the backend and this is a fresh installation with Dovecot and Exim4. What went wrong and how do I fix this mess and point everything back to

Also, How do I ensure that if I add more domains, such as etc. they configure their mail hostname properly?

Lastly, how do I configure server’s rDNS for multiple mail-domain?

I also wanna add that when I inspect the /etc/dovecot/dovecot.conf file I see that the hostname their is empty
listen = *, ::

/usr/sbin/exim4 -bP primary_hostname returns hostname as

sudo doveconf -n | grep ssl
returns certificate for

Hi @Ritzz,

Note: I will use instead of because the last one is an actual domain and was created to be used in doc, examples, etc…

Hestia doesn’t say your hostname will be, it says your MX will be

Where you see that your mail helo and hostname is returning as

Your SPF record should look like this:
v=spf1 a mx ip4: -all

  • a: Allows the domain’s current A record (IPv4 address) to send mail.
  • mx: Allows the domain’s current MX (Mail Exchange) servers to send mail.
  • ip4: Specifies a specific IPv4 address that is allowed to send mail on behalf of the domain.
  • -all: Indicates a “Fail” policy, meaning that if the sending server is not in the list of authorized servers (A record, MX servers, or the specified IP address), the email should be treated as unauthorized.

And yes, all your mails will be sent from your hostname ( and that is correct.

Nothing, there is no mess, all is working as expected.

You can’t. PTR record should be managed by your hosting provider and you can only have one domain per PTR record and that is the reason your PTR should point to your hostname (in this case or at least the hostname defined in exim that by default is your server’s hostname.

That means that dovecot will listen on all interfaces on your server, nothing else.

You could change it but it is correct, by default, exim will use your server’s hostname.

That conf is located here /etc/dovecot/conf.d/domains/

And you should have one entry:

local_name {

Or two if you are using a wildcard certificate:

local_name {

local_name {

I can’t see any issue with your conf, that’s how it should work.


  1. There are two places inside hestia cp that explicitly says that my mail hostname is one while creating mail accounts another in the mail domain SSL.

  2. I tested by sending a mail to also I tried using telnet to send HELO command but the this is what it returned Connection closed by foreign host.

  3. My spf also includes the hostname alongside what you mentioned v=spf1 a mx ip4: -all" The SPF by default included the` domain but I manually changed it.

  4. If everything is working as expected, why do you think I see a bunch of outputs of wrong hostnames?

  5. So what happens after I set as PTR? how does it connect with and’s mail account for example?

  6. How do I use and as the SMTP and IMAP hostname for the respective mailboxes if you suggest to leave exim4 primary hostname to

That is the domain you must use to connect via smtp/imap/pop3 not the hostname that you should define in exim.

What mail-tester says about the mail you sent?
Regarding telnet, what did you do?

If you tell me your domain I can test it.

My Hestia doesn’t include that include but two things:

1.- the mx part already includes
2.- the important part is the way your smtp server will identify itself when connecting to other smtp servers and it will be identified with the server hostname

If you show logs maybe I could try to guess what the issue is.

It doesn’t connect, as I said, is the hostname that your smtp server (Exim) will use to connect to other smtp server and viceversa so the PTR should point to the hostname that Exim will use.

The and are used during connection to select via SNI the right certificate for your domain. The important part (asides the SSL/TLS part) is that the server will authenticate your user via dovecot (yes, exim will use dovecot to authenticate your user) and it will use [email protected] or [email protected] to identify the right user with the right domain.

  1. So the problem lies when I try to add in mailspring, they say that the certificate is self-signed and not trusted. However, as you can see on the screenshot above, It says the mail domain has Let’s Encrypt certificate. I tried checking with SSLcerty as well which returned the proper Let’s Encrypt Certificate.

  2. mail-testers say’s everything is good however, SPF, MX, rDNS, everything is different as I mentioned before.

However, using telnet on mail/ on any smtp port and using Helo for any of the hostname returns the said error.

  1. So do you recommend to remove the from SPF?

Thanks for the clarification on the other aspects.

If you send to me (via private message) your actual domain I could test it.

That message usually is shown when trying to access via telnel (plain connection) to port 465 but if you say you have the same issue on port 25 and 587… is strange. Instead of helo, try extended helo ehlo just in case.

I don’t use it in any of my domains so I’ll remove it but it won’t hurt if you keep it.

I’m leaving now (family dinner) but if you send to me your domain I’ll check it later.

Just in case, show the output of this commands:

dig +short

If above command doesn’t show any output, it is good, if it shows then you have an issue wieh spamhaus dnsbl because you are using a public dns resolver.

Also, when you try to test the connection using telnet (telnet 25) check after the error the exim log /var/log/exim4/mainlog or /var/log/exim4/rejectlog. Also check whether there is a log /var/log/exim4/paniclog (if there is no paniclog file or it is empty, it is good).

Happy Holidays!

1 Like

Just for the records.

I’ve been talking with @Ritzz and we fixed the issue.

@Ritzz had to change the PTR record to the server’s hostname and create a Let’s Encrypt certificate for the server’s hostname (v-add-letsencrypt-host).


1 Like

Yep, @sahsanu has been a great help.



This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.