SPF failure on bitwarden.eu: no authorized sending IPs

gifbengif · November 24, 2025, 3:12pm

Hello everyone,

I am currently facing an SPF issue with emails sent from the bitwarden.eu domain.

Here are the current SPF records published in DNS:

bitwarden.eu
v=spf1 -all

bitwarden.com
v=spf1 include:spf.braintreegateway.com include:_spf.google.com include:amazonses.com include:_spf.freshsales.io include:22371289.spf07.hubspotemail.net ~all

Emails sent from bitwarden.com pass SPF checks correctly.
Emails sent from bitwarden.eu systematically fail because no IP address is authorized.

This clearly highlights a configuration difference between the two domains.

I contacted Bitwarden support, but they refuse to make any correction and consider their configuration to be correct.

For obvious security reasons, we cannot disable or relax SPF verification on our side, as this would create a vulnerability allowing domain spoofing.

At this stage, the issue is solely related to an incorrect (or incomplete) SPF configuration on bitwarden.eu.

If anyone has already experienced a similar situation, I would appreciate your feedback.

Thank you in advance.

Bonjour à tous,

Je rencontre actuellement un problème SPF avec les e-mails envoyés depuis le domaine bitwarden.eu.

Voici les enregistrements SPF actuellement présents dans les DNS :

**bitwarden.eu : **
v=spf1 -all

bitwarden.com :
v=spf1 include:spf.braintreegateway.com include:_spf.google.com include:amazonses.com include:_spf.freshsales.io include:22371289.spf07.hubspotemail.net ~all

Les e-mails envoyés depuis bitwarden.com passent correctement le contrôle SPF.
Les e-mails envoyés depuis bitwarden.eu échouent systématiquement, car aucune adresse IP n’y est autorisée.

Cela met clairement en évidence une différence de configuration entre les deux domaines.

J’ai contacté le support de Bitwarden, mais ils refusent d’effectuer une correction et considèrent que leur configuration est correcte.

Pour des raisons de sécurité évidentes, nous ne pouvons pas désactiver ou assouplir la vérification SPF de notre côté, car cela ouvrirait une faille permettant l’usurpation de domaine.

À ce stade, le problème vient uniquement d’une configuration SPF incorrecte (ou incomplète) sur bitwarden.eu.

Si quelqu’un a déjà rencontré un cas similaire, je suis preneur de vos retours.

Merci d’avance.

grb · November 24, 2025, 4:20pm

@gifbengif Welcome to the forum!

I would suggest raising an issue on Github.

DenBesten · November 24, 2025, 10:37pm

Do we know for sure that email is supposed to originate from bitwarden.eu? I am not in that domain, so I do not have any samples to check, but I do note that:

Bitwarden.eu has no MX records, indicating that it is incapable of receiving email.
Bitwarden.eu has a spf policy that strongly asserts that the domain does not originate any emails.
Bitwarden.eu has a dmarc policy to reject (as opposed to deliver or quarantine) email that is not dmarc signed.
All but one reference on their page refers to bitwarden.com; the one reference to bitwarden.eu does not make it clear that it will be used; just that it may be used.

Collectively, these appear to be a domain that does not participate in email.

Neuron5569 · November 24, 2025, 10:54pm

Yes, I just tried to register an account there. It’s an email sent from no-reply@bitwarden.eu that passed all DMARC, DKIM, SPF, and ARC, according to Google.

gifbengif · November 25, 2025, 9:03am

Hello DenBesten,

Thank you for your reply.

Yes, I can confirm that we are indeed receiving emails where the visible sending domain is bitwarden.eu (both in the From header and in the return-path / MAIL FROM).

For example:

Date: 18/11/2025 – 15:39:42
Subject: “New Device Logged In From Chrome Extension”
From: no-reply@bitwarden.eu (0107019a97683c5c-a9d0fd82-481d-4a60-95c5-b9ea9f1af240-000000@mailses.bitwarden.eu)
IP: 54.240.99.95

Result: SPF FAIL

For bitwarden.eu, the SPF record does not authorize any IP addresses:

This is precisely the core of the problem: the bitwarden.eu domain is configured as a domain that should not send any emails (v=spf1 -all), and yet emails are being sent using this domain.

This is not an issue for emails sent from the bitwarden.com domain, as the SPF records for bitwarden.com are correctly configured:

v=spf1
include:spf.braintreegateway.com
include:_spf.google.com
include:amazonses.com
include:_spf.freshsales.io
include:22371289.spf07.hubspotemail.net ~all

Example:

Date: 23/11/2025 – 16:16:06
Subject: “Support”
From: support@bitwarden.com (0107019ab1495900-f1b5deb2-93c1-45d4-adc4-6bfcfcbf71f6-000000@mailses3.bitwarden.com)
IP: 54.240.99.95

Result: SPF PASS — IP address 54.240.99.95 is included in the amazonses.com SPF range (54.240.64.0/18).

I fully agree with your analysis: from a DNS and security policy standpoint, bitwarden.eu is clearly configured not to participate in email sending, which is exactly why these messages are being rejected on our side.

This means that either:

No emails should ever be sent from this domain, or
The SPF/DMARC configuration of bitwarden.eu is incorrect compared to its actual usage.

At this stage, Bitwarden support claims that their configuration is correct and refuses to make any changes, which is why I opened this discussion here.

Thank you again for your analysis, which fully confirms our security concerns.

Best regards,
Benjamin

gifbengif · November 25, 2025, 9:56am

Hi grb,
Thank you for your suggestion. I’ve opened an issue on GitHub to report the problem:

github.com/bitwarden/server

SPF failure on bitwarden.eu: no authorized sending IPs

opened 09:50AM - 25 Nov 25 UTC

closed 11:44AM - 25 Nov 25 UTC

gifbengif

bug

### Steps To Reproduce Steps To Reproduce Monitor incoming emails sent from th…e 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 - [x] 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.

gifbengif · November 25, 2025, 10:02am

Hi Neuron5569,

If you are successfully receiving emails from the bitwarden.eu domain, it likely means that your email provider (Google?) is not strictly enforcing SPF checks.
This is not always the case with public email services.

However, in professional / corporate environments, depending on the security context, we often cannot ignore SPF checks.
Not enforcing SPF means that an attacker could send an email using the bitwarden.eu domain even if the sending IP is not explicitly authorized in the domain’s DNS.

Neuron5569 · November 25, 2025, 10:35am

Thanks for the explanation.

I certainly did not and do not know how all these checks are supposed to be set up. I was commenting that Bitwarden uses the bitwarden.eu domain for emailing, and Google (and, due to the circuitous route of the email address I used, Microsoft) indicated no failure for all the checks that both services conducted.

I am neutral about yours and DenBesten’s analysis (due to ignorance). I still find it curious that email checker services like mxtoolbox.com and powerdmarc.com seem to indicate that the bitwarden.eu domain is set up okay as well.

gifbengif · November 25, 2025, 12:36pm

Here is Bitwarden’s response on GitHub :

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.

I’m lost, I don’t know what to do anymore.

gifbengif · November 25, 2025, 12:45pm

Hello Neuron5569,

Thank you, I understand and I appreciate the clarification you provide.

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.

DenBesten · November 25, 2025, 3:44pm

With email, validations can truly only occur when one has a sample message. Checkers like mxtoolbox mostly are validating syntax, not proper operational config.

That said @gifbengif has prima-fascia evidence that bitwarden.eu is misconfigured by providing an email (header) with a From: address @bitwarden.eu, in conflict with the SPF which states that the site definitely does not send any email (v=spf1 -all).

Email is one of those things that is easy to get “kinda working”, but is extremely difficult to get perfectly configured. And if imperfect, the symptoms tend to be email being lost after it has left the jurisdiction of the email admins, so they don’t even know there is a problem, much less have access to troubleshooting symptoms.

It appears that @gifbengif did not succeed in reaching the proper group within Bitwarden to configure email delivery management. If nothing else, suggesting “you might need to allowlist specific email addresses” is basically admitting that one’s own emails may not follow the rules being promulgated in the SPF/DMARC/DKIM config.

Even this is imperfect in that “~all” (as opposed to “-all”), indicates they are not willing to commit to their config being accurate.

grb · November 25, 2025, 3:46pm

@dwbit Any chance you can convince somebody from the Cloud Engineering team to join this thread to address the serious concerns that have been raised?

dwbit · November 25, 2025, 7:47pm

Thanks all, we will continue to work with @gifbengif on the existing ticket to identify the cause of the issues.

grb · November 26, 2025, 4:07pm

Given the above claim, the response just provided in the Github issue does not make sense to me:

“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.”

@gifbengif @DenBesten can you comment? @gifbengif are you being told the same thing in your communications with Customer Support?

DenBesten · November 26, 2025, 4:45pm

I believe that comment to be a red-herring. Independent of its truthfulness, it does not address the issue at hand. Even if Mailinblack did not exist, the below contradiction would still exist.

Bitwarden.eu’s SPF record reports that nobody is allowed to originate email from @bitwarden.eu, contradicting @gifbengif’s observation “where the visible sending domain is bitwarden.eu (both in the From header and in the return-path / MAIL FROM).”

grb · November 26, 2025, 5:05pm

I think it would help if @gifbengif (or anybody else with an EU-hosted account) could post a copy of the MAIL FROM (Return-Path) header from an email sent by bitwarden.eu. The examples given above only show the FROM headers, unfortunately (even though @gifbengif has asserted that the bitwarden.eu domain also appears in the Return-Path header).

It seems that Greenderella’s response implies that Bitwarden always uses the bitwarden.com domain in the Return-Path header (even for emails that have bitwarden.eu in the FROM header), while @gifbengif’s comment has contradicted this.

Update:

@Nail1684 has provided the following evidence that Bitwarden does use bitwarden.eu as a MAIL FROM domain:

[Edit: Re-uploaded image with less redaction.]

DenBesten · November 26, 2025, 6:56pm

I would make them match as it makes delivery much more reliable (e.g. not ending up in junk). I do appreciate Greenderella’s philosophy of helping others comply with minimum standards, but at the same time, I also tend to look for ways where I can keep “their” misconfig from becoming “my” problem. So, I would not consider the two fixes mutually exclusive.

Although I trust @Nail1684 and @gifbengif’s claims, the image redacts just a bit too much of the ‘envelope-from’ to support the claim.

grb · November 26, 2025, 7:08pm

See edited post above.

At least in the email received by @Nail1684, the MAIL FROM domain is the subdomain mailses.bitwarden.eu, which evidently has a separate SPF record:

v=spf1 include:amazonses.com ~all

I’ll let others more knowledgeable than me dissect the ramifications of this in relation to @gifbengif’s claims.

Nail1684 · November 26, 2025, 9:02pm

As far as I can see, @gifbengif also mentioned this subdomain (in this post):

DenBesten · November 27, 2025, 6:14am

@Nail1684’s partially redacted screenshot confirms the envelope-from domain is indeed mailses.bitwarden.eu. Mailses has a SPF of “v=spf1 include:amazonses.com ~all”. This makes much more sense because it confirms that at least “someone” is allowed to send email from that domain.

The screenshot implies that the originating server is eu-central-1.amazonses.com, based on that name being tattooed into the message-id. If true, there may be an issue in that at least some of its IP addreses do not appear in the list of authorized senders in amazonses.com.

That said, I do suspect an error in my analysis because both Microsoft and Google are sticklers for SPF being correct, so if my interpretation is correct, I would expect much more uprising.

Going back to this comment, a mail recipient is not obliged to accept a message or put it into an inbox just because SPF passes. SPF is a more like a minimal baseline, than an interoperability standard. Mailinblack and its brethren are free to go above-and-beyond, such as declaring clearly machine-generated messages as spam, reducing their trust when one’s SPF is non-authoritative (e.g. contains ~all) or even declaring suspicious a mis-match between envelope-from and header-from.

Part of the trick for getting email through is to minimize the potential for a message to look suspicious.