I contacted MailInBlack support regarding the SPF issue with emails from Bitwarden. Here’s a summary of the situation:
This message was blocked by MailInBlack due to an SPF failure.
However, the domain mailses.bitwarden.eu contains the correct SPF records and authorizes the sending IP 54.240.99.95.
You can check here: https://mxtoolbox.com/SuperTool.aspx?action=spf%3amailses.bitwarden.eu%3a54.240.99.95&run=toolpage
According to Bitwarden technical support and RFC 7208, SPF validation should be performed against the Envelope From / MAIL FROM field, which in this case is: 0107019a97683c5c-a9d0fd82-481d-4a60-95c5-b9ea9f1af240-000000@mailses.bitwarden.eu
On this domain (mailses.bitwarden.eu), SPF validation should not fail, and the email should be considered compliant.
I asked MailInBlack support why the message is considered SPF failing, even though the envelope domain has correct SPF records.
I’m waiting for their clarification and will share updates once I have more information.
Thank you all for your time, help, and valuable insights on this topic.
After further investigation with MailInBlack support, it turns out the issue was on our side and was related to a specific security setting in their platform called “Enhanced SPF verification”.
When this option is enabled, MailInBlack performs SPF validation on both the From header and the Envelope From / MAIL FROM address.
Since Bitwarden uses bitwarden.eu in the visible From header and mailses.bitwarden.eu in the Envelope From, this resulted in SPF failures on our side even though the envelope domain is correctly configured.
According to MailInBlack, to restore standard RFC 7208 behavior (SPF check only on the Envelope From), the following setting must be disabled:
“Enable enhanced SPF verification for emails”
So the root cause was a configuration difference on our side, but it was important for us to fully understand this subtle SPF behaviour in order to rule out any domain misconfiguration on Bitwarden’s side.
Thank you again to everyone who contributed to the analysis and discussion.
Thanks for the update, and I’m glad that you were able to resolve the issue for yourself. Just the same, I don’t think that features like “enhanced SPF verification” are a one-off unique to MailInBlack, and and as the spam/antispam arms-race escalates, I am afraid that such strategies will become more common, causing many Bitwarden users to miss important security notifications (or fail to get required verification codes), if the notifications continue to be sent with mismatching FROM and MAIL FROM domains.
I wonder if there is a reason why the spf record for bitwarden.eu cannot be modified to avoid such false positives (or better, why the FROM domain is not simply changed to mailses.bitwarden.eu, which should — if I’ve understood correctly — also fix this type of issue).
Exactly my thought. If the Envelope Sender and the From: header are identical, one no longer needs to worry about recipients pulling tricks like this. But, rather than making “mailses.bitwarden.eu” visible to users in the “From” header, I probably would pick something user-comprehensible, such as “no-reply@vault.bitwarden.eu” or “no-reply@alerts.bitwarden.eu”.
Also, I fully expect that having “~all” in the SPF, which means, “we are uncertain if our our SPF is correct” can also result in similar blockages. Better is to end with “-all”, which indicates confidence in the SPF values.
