Solved DA email forwarder causing ProtonMail "This email has failed its domain’s authentication requirements. It may be spoofed or improperly forwarded!"

wdc

Verified User
Joined
Dec 8, 2013
Messages
82
When I setup forwarder (in a DirectAdmin) to forward my Directadmin domain incoming mail to my ProtonMail alias email address and send a test email from my different third party mailbox (WHICH IS HOSTED ON SAME DA SERVER, ONLY UNDER DIFFERENT ACCOUNT), this email is forwarded and delivered to ProtonMail, but it is marked as a phishing attempt. Subject is prefixed "[Possible phishing attempt]" and a body shows message in title, claiming that the email was improperly forwarded:

When the email sender is some third party and sending from different server, then the issue does NOT happen.

Can this be fixed please?
 
Last edited:
Can this be fixed please?
That depends. Do you use DMARC? If yes, remove that (or temporary remove it) and see if the issue persists.

I would start to check the headers from the mail you received in Protonmail so you can investigate exactly at which point the issue occurs. My good guess is DMARC because of DKIM failing or something like that. But the headers should be more informative.
 
Arc-Authentication-Results: i=1; mail.protonmail.ch; dkim=fail (Bad 2048 bit
rsa-sha256 signature.) header.d=mysenderdomain.com header.a=rsa-sha256; dmarc=fail (p=none
dis=none) header.from=mysenderdomain.com; spf=pass smtp.mailfrom=myrecipientdomain.info; dkim=fail (2048-bit
key) header.d=mysenderdomain.com [email protected] header.b=stringhere reason="signature
verification failed"

_dmarc3600TXT"v=DMARC1;p=none"
https://lumo.proton.me says about it:
• v=DMARC1 – declares that this is a DMARC record (current version).
• p=none – tells receiving mail servers not to reject or quarantine messages that fail DMARC checks; they should only generate reports (if reporting tags are added). This is the “monitor‑only” mode, useful when you’re first deploying DMARC.

I have tried to remove these DMARC records, and re-send mail, but the issue persist. DKIM is:

x._domainkey3600TXT"v=DKIM1; k=rsa; p=longstringhere"

i have also tried to disable and then enable DKIM (in DirectAdmin, Email accounts section there is a button). It removed and added the DKIM txt DNS record with new public key. But the issue persist:

Arc-Authentication-Results: i=1; mail.protonmail.ch; dkim=fail (Bad 2048 bit
rsa-sha256 signature.) header.d=mysender.com header.a=rsa-sha256; dmarc=fail (p=none
dis=none) header.from=mysender.com; spf=pass smtp.mailfrom=myrecipient.info; dkim=fail (2048-bit
key) header.d=mysender.com [email protected] header.b=RLyWi8Jv reason="signature
verification failed"
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=passmail.net; s=dkim;
t=numberhere; h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding;
bh=/stringhere=;
b=stringhere=
Please what do you suggest to try as a reseller, not admin?
 
Automatic email forwarding (as you would set up in your DirectAdmin control panel) will always fail SPF.

If the directadmin.com domain sends an email to your example.tld email address and your example.tld email address forwards that message on to your protonmail.com email address (or any destination for that matter) then the SPF will fail.

directadmin.com lists the IPs it sends emails from in it's SPF record. When protonmail.com gets the message, it's getting it from your example.tld server. Chances are great that the IP address of the example.tld server is not listed in the directadmin.com SPF record. That causes the failed SPF record.

This is why forwarding mail off the server to a remote mail server is a bad idea. Either advertise your protonmail.com domain and have messages sent directly to it. Or set up an example.tld email account and check it with POP3 or IMAP.
 
Automatic email forwarding (as you would set up in your DirectAdmin control panel) will always fail SPF.
Normally yes unless you also have DKIM. Often then it will be seen that it was send by the original sender.
However if you than also have DMARC, it will fail again since SPF and DKIM won't match for example.

That causes the failed SPF record.
There is no SPF fail. He only shows a DMARC fail because of DKIM fail. SPF shows pass in his log parts.

In this case mail is send from a domain on his server, via a domain in his server so normally with the MX A in SPF or else adding hostname ip in there, this could be catched so it would not break on SPF. This is done correctly because SPF is passing.

But with DMARC it still breaks because the DKIM does not match. If either SPF -or- DKIM fail, then DMARC fails.
That is why I advised to remove the DMARC record and see what it does if he want's to keep working this way. DKIM would still failt but SPF would most likely pass and chances are mails will get through. But it's not really a good way to work.

So I fully agree that it's way better to not use forwarders and use the method described in your last alinea.
 
I figured out that sending fails only from one account on this server, but others works. Reason was that the DKIM failing sender domain is behind Cloudflare and its DNS records related to mail (MX, DKIM...) were outdated, I forgot the site is behind CF and I need to update it, I am sorry.

So the problem is solved. Thank you for your help, which is appreciated.
 
Back
Top