SPF failure on bitwarden.eu: no authorized sending IPs

[gifbengif]

Steps To Reproduce

Steps To Reproduce

Monitor incoming emails sent from the domain bitwarden.eu (e.g. security notifications such as “New Device Logged In From Chrome Extension” sent from no-reply@bitwarden.eu).

Extract the sending IP address (example: 54.240.99.95) from the email headers.

Check the current SPF record of bitwarden.eu in public DNS.

Verify that the SPF record is:
v=spf1 -all

Perform an SPF validation against the sending IP (54.240.99.95) for the domain bitwarden.eu.

→ The verification will result in SPF FAIL because no IP is authorized for this domain.

Expected Result

If emails are sent from bitwarden.eu, then the SPF record of this domain should explicitly authorize the sending infrastructure (e.g. Amazon SES) and SPF validation should return PASS.

OR

If bitwarden.eu is not intended to send email, then no emails should ever be sent using @bitwarden.eu as a sender domain.

Actual Result

Emails are being sent from @bitwarden.eu, even though the SPF record for this domain is set to v=spf1 -all, which explicitly forbids any sender.

As a result, all these emails fail SPF validation and are rejected or quarantined by security-compliant mail systems.

Screenshots or Videos

No response

Additional Context

The same sending IP (54.240.99.95) is correctly authorized in the SPF record of bitwarden.com, and emails from that domain pass SPF validation.

This proves the sending infrastructure is valid but incorrectly declared for bitwarden.eu.

Build Version

bitwarden.eu (Saas)

Environment

Cloud (bitwarden.com)

Environment Details

No response

Issue Tracking Info

• I understand that work is tracked outside of Github. A PR will be linked to this issue should one be opened to address it, but Bitwarden doesn't use fields like "assigned", "milestone", or "project" to track progress.

[bitwarden-bot]

Thank you for reporting this issue! We've added this to our internal tracking system.
ID: PM-28806
Link (for internal use): https://bitwarden.atlassian.net/browse/PM-28806

[Krychaz]

Hi,

I have discussed this with our Cloud Engineering team. They have informed me that all SPF records are setup correctly, have been compliant and working without issues. Some configs might be different for you and you might need to allowlist specific email addresses. The records at bitwarden.com were setup for multiple purposes. We also have bitwarden.com setup for our own business emails aside from transactional emails. We have also validated with our multiple mail providers and confirmed numerous times that the configurations had been setup properly both for bitwarden.com and bitwarden.eu

This issue will be closed now. If you need further assistance, please get in touch with us via our contact form - https://bitwarden.com/contact/

Thank you.

[gifbengif]

Hello @Krychaz

Thank you for your reply. I would like to address your points individually.

“All SPF records are setup correctly, compliant and working without issues.”

From our side, emails sent from bitwarden.eu consistently fail SPF checks. The SPF record for bitwarden.eu is currently v=spf1 -all, which explicitly forbids any IPs from sending. This is not a matter of configuration preference — this record is inherently incompatible with the fact that emails are actually being sent from this domain. Do you understand how SPF works?

“Some configs might be different for you and you might need to allowlist specific email addresses.”

The issue is not with allowlisting on our side. We cannot globally bypass SPF checks without creating a security risk: an attacker could send emails using the bitwarden.eu domain from any IP. This is why relaxing SPF is not an option in professional email environments.

“The records at bitwarden.com were setup for multiple purposes. We also have bitwarden.com setup for our own business emails aside from transactional emails.”

We fully understand the multi-purpose setup for bitwarden.com. However, this explanation does not address the misalignment for bitwarden.eu, which is strictly transactional but has an SPF record that forbids sending.

“We have also validated with our multiple mail providers and confirmed numerous times that the configurations had been setup properly both for bitwarden.com and bitwarden.eu.”

I respect that internal validations were performed.

If you want to observe the SPF issue directly, you can try the following on MXToolbox :

Go to https://mxtoolbox.com/spf.aspx
Enter the domain bitwarden.eu
Enter the IP address 54.240.99.95 (an example IP that has sent an email from bitwarden.eu)

https://mxtoolbox.com/SuperTool.aspx?action=spf%3abitwarden.eu%3a54.240.99.95&run=toolpage#
You will see that MXToolbox reports an SPF error for this combination.

For comparison, if you enter bitwarden.com with the same IP, MXToolbox does not indicate any error.
https://mxtoolbox.com/SuperTool.aspx?action=spf%3abitwarden.com%3a54.240.99.95&run=toolpage#

This demonstrates the difference in SPF configuration between the two domains.

The issue is not with our mail system or allowlisting.

The bitwarden.eu SPF record (v=spf1 -all) is fundamentally incompatible with the fact that emails are sent from this domain, which leads to failed SPF checks in professional email systems.

This is a real-world operational issue that affects deliverability and security.

I hope this clarifies why closing the GitHub issue without addressing the SPF mismatch does not resolve the underlying problem.

Thank you,
Benjamin

[bwbug]

We have also validated with our multiple mail providers and confirmed numerous times that the configurations had been setup properly both for bitwarden.com and bitwarden.eu

@Krychaz It would be helpful if you could show evidence of this for the bitwarden.eu domain, given the analysis provided above, and within the following thread on the Bitwarden Community Forum:

https://community.bitwarden.com/t/spf-failure-on-bitwarden-eu-no-authorized-sending-ips/91171/

 

What would be even more helpful would be if one of your Cloud Engineering team members could take a few minutes to engage with the community forum thread linked above. DKIM failures by Bitwarden notification emails is another known issue — see here and here, for example.

[Greenderella]

Hi there,

After reviewing this with the SRE team, it has been verified again that some providers like Mailinblack, are not adhering to the official specifications for SPF record checks (see RFC 7208), and they are validating against the FROM domain, instead of the MAIL FROM domain.

If anyone has a contact at Mailinblack or would like to open a support case with them, we’d be happy to provide guidance on the proper configuration.

[bwbug]

@Greenderella According to @gifbengif's post on the Community Forum, they are "receiving emails where the visible sending domain is bitwarden.eu (both in the From header and in the return-path / MAIL FROM)" (emphasis added).

On the other hand, the SRE team's response that you paraphrased seems to imply that Bitwarden notifications only use the bitwarden.eu domain in the FROM header, and not in the MAIL FROM header.

So, from my perspective, there still seems to be a disconnect here.

[bwbug]

Here is direct evidence that Bitwarden does use bitwarden.eu as a MAIL FROM (Return-Path) domain, thus violating the assurances provided in the SPF record for bitwarden.eu (which is v=spf1 -all, indicating that no sources are authorized to send email as bitwarden.eu):

 

Noncompliant validation by providers such as Mailinblack is an unrelated issue, as even RFC7208-compliant providers should reject (fail) all emails sent with a Return-Path in the bitwarden.eu domain.

@Greenderella Please notify the SRE team of these inconsistencies in their previous response, and ask them to take a closer look at the issue.

[gifbengif]

Hello everyone,

Following @Greenderella 's recent comment regarding MailInBlack not adhering to RFC 7208 and validating SPF against the From header instead of the MAIL FROM / Envelope From, I have reached out to MailInBlack support to clarify the issue. I will provide updates as soon as I receive their response.

For context, here is an example of the message headers from one of the emails in question:

sender_header: Bitwarden no-reply@bitwarden.eu
sender_used: no-reply@bitwarden.eu
sender_envelope: 0107019a97683c5c-a9d0fd82-481d-4a60-95c5-b9ea9f1af240-000000@mailses.bitwarden.eu
smtp_client_ip: 54.240.99.95
recipient_header: benjamin.legallou@savoirsplus.fr

Best regards,
Benjamin

[gifbengif]

Hello everyone,

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.

Best regards,
Benjamin