Mail works only internally

My YunoHost server

Hardware: Rackserver - VM
YunoHost version: (stable).
I have access to my server : Through SSH | through the webadmin | direct access via keyboard / screen | …
All of the above
Are you in a special context or did you perform some particular tweaking on your YunoHost instance ? : no
If yes, please explain:

Description of my issue

Email doesn’t seem to send externally only internal i.e. from my wp site to an server internal email adres works fine, but from my site to any other domain or from any mail application like round cube to some other domain nope…

Things I did, changing the mx rule to the CORRECT values (for some reason YunoHost keeps nagging about that). Also I did de reverse DNS :wink:


Hmmmmokay, does the diagnosis complains about anything in particular that would sound related to email …?

Naively I would investigate by :

  • starting the command tail -f /var/log/mail.{info,warn,err} … this command will display the last line in corresponding files AND (most importantly) hang and display new incoming line … keep this running in one terminal (don’t Ctrl+C until you’re done with next steps)
  • try to send an email like you would usually do
  • wait for stuff to show up in the terminal from step 1
  • … and then we need to analyze what’s going on in that log …

Well it complains about the DNS records which are set correctly.

Just stupid right?!

Also when trying to send an e-mail using Roundcube, the postmaster gives a;
smtp; 550 Bad HELO - Host impersonating domain name!

The current values and the expected values are note the same, there is " " in the middle of your DKIM key in your DNS record that shouldn’t be here and that should explain why your mails are refused. Correcting that should correct your issue.

1 Like

could you point it out I don’t seem to see it…

1 Like

How the heck, this does not compute in my brains, look at the dns record below. there is no extra "…
it’s not a bug, it’s a feature… or is it a bug?

Hmpf idk, indeed there’s no space in your screenshot but who knows maybe that’s your registrar doing some funky stuff…

Hmm yeah, soon we will be our own registrar… For now I’ve send them a link to this topic so they can answer it eventually.

(To be clear I can confirm the issue using a dig +short TXT mail._domainkey.thedomain.tld)

The response form the registrar,

Hi Shaady,

It’s correct in your DNS that I’ve been able to confirm, you can also do your DKIM check via this check (Tools - and that matches 1/1 of what you entered in DirectAdmin with your TXT record:
“v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4W3rV2RHY9Ad8/3r5AXkdXf77HklXU4 LxjoVgKp+XL5r/2LuUFra7rrtLB79iSbV78Hhu1mDPnxK66Zu0QhX8xSaonVAWFSJ+cmZBEx3MlKw2ulmgVoy6hLpvdYwEZNQo6wIDAQAB”

With us in the DNS:
“v=DKIM1; h=sha256; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4W3rV2RHY9Ad8/3r5AXkdXf77HklXU4 LxjoVgKp+XL5r/2LuUFra7rrtLB79iSbV78Hhu1mDPnxK66Zu0QhX8xSaonVAWFSJ+cmZBEx3MlKw2ulmgVoy6hLpvdYwEZNQo6wIDAQAB”

Because many TXT records are very long they are sometimes automatically broken down by the clients who read out the characters that are named in that topic, but the output MUST always be the same with such lookups otherwise the soup does indeed run. Whatever the case now, at least I see that in your screenshots but that’s totally contradictory what I see in back as our dns and look at that check.


Sjoerd Klein Meulekamp

Zblerg wokay … supposedly the code already handle the fact that records might be in several pieces … but wokay lemme double check that …

Not sure when I will have the time for this so don’t hesitate to re-poke me if i forget about it

i POKE you

Cheers for the poke

So indeed I guess we don’t handle that case … On the other hand it doesn’t seem to affect many people

Anyway … this commit should fix it : Handle case where DKIM record is split into several pieces · YunoHost/yunohost@c8a23f2 · GitHub

I’m a bit lazy to release a hotfix in 4.1 for this because meh, but maybe if there are other hotfixes coming I can release it quickly at some point …

Otherwise you can try to apply the fix manually on your server with

nano /usr/share/yunohost/hooks/diagnosis/

(and after you edited the file, run systemctl restart yunohost-api to propagate it to the webadmin)

(Alternatively you could just ignore this warning in the diagnosis screen, until the next version, considering it’s a false-negative)

I did it myself

Hope it worked :wink:

That’s more like IT!


The mail system

<[]>: host[] refused to
talk to me: 550 Bad HELO - Host impersonating domain name []

Reporting-MTA: dns;
X-Postfix-Queue-ID: 10A0434138D
X-Postfix-Sender: rfc822; []
Arrival-Date: Wed, 27 Jan 2021 12:31:18 +0100 (CET)

Final-Recipient: rfc822; []
Original-Recipient: rfc822;[]
Action: failed
Status: 5.0.0
Remote-MTA: dns;
Diagnostic-Code: smtp; 550 Bad HELO - Host impersonating domain name

Any chance there’s more than one NIC in your server, and traffic exiting on another NIC than you expect, with a different IP and a different domain? sounds close enough to to be part of the same server location.

Response from my current domain provider;
Like as if you were trying to use our mail server while you connect from your own mail server which I think is now handling the mail. So I find it weird why then our mail server comes along in the error message (or you must have set us up as SMTP server).

Your own mail server seems to be the one that handles the mail and according to the SPF record is also the only one allowed to handle the mail.


“v=spf1 a mx -all”