# Remove Mailbox.org **URL:** https://discuss.privacyguides.net/t/remove-mailbox-org/20232 **Category:** Tool Suggestions **Created:** 2024-08-21T14:56:38Z **Posts:** 102 ## Post 1 by @plonkeyt — 2024-08-21T14:56:38Z According to a [post](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc) in its official forum, [Mailbox.org](http://Mailbox.org) does not properly implement anti-spoofing measures (SPF/DKIM/DMARC) for custom domains, meaning anyone with a [Mailbox.org](http://Mailbox.org) account can send mail from another users email address. [This issue](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-1450) was [confirmed by Mailbox.org](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-1524) four years ago, with [unfulfilled promises](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-2529) to fix it since. --- ## Post 2 by @plonkeyt — 2024-08-23T19:58:27Z I edited the initial post heavily as there were no initial responses, perhaps due to not being succinct enough. Original post is here: > Eight years ago a [post](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc) in [Mailbox.org](http://Mailbox.org) forum suggesting that the service does not provide proper support for SPF, DKIM & DMARC for custom domains (though some say its not working for non-custom domains as well). This is reportedly causing mail to frequently not deliver or be marked as spam. And it means that: > " it’s look like anyone with a valid [mailbox.org](http://mailbox.org) account can send mail with domain configured on [mailbox.org](http://mailbox.org) > E.G. Your account : [toto@mailbox.org](mailto:toto@mailbox.org) you can send an email as [bidule@adomainname.com](mailto:bidule@adomainname.com) if a [adomainname.com](http://adomainname.com) is configure by another [mailbox.org](http://mailbox.org) user on [mailbox.org](http://mailbox.org)," > To which Mailbox confirms this is the case, but that it should have a solution within a few weeks. That was 4 years ago. Their most recent, and seemingly substantial (though not substantial at all) comment, from one year ago, reads: > “Hi there and thanks for hanging in there with us. We totally get the challenges you and other users are facing with implementing anti-spoofing measures for custom domains on [mailbox.org](http://mailbox.org). > Just to let you know, it's definitely on our radar, but it needs careful planning and thorough checking of all security aspects. > Additionally, SPF settings are being honored and DMARC settings are a huge factor in our spam recognition. While we don’t honor DMARC at a 100% right now, we do take it into account. > Rest assured, we’re committed to this and grateful for your continued support and understanding.” --- ## Post 3 by @jonah — 2024-08-23T20:11:07Z We only recommend email providers for securing incoming messages. For outgoing communications we recommend instant messengers which are immune to problems with email like this. --- ## Post 4 by @plonkeyt — 2024-08-23T20:33:34Z I do not accept this. It’s akin to saying you do not recommend mobile phones. Except for the privacy-tech-community, practically every organization and person relies on email for privately communicating with anyone who is not already a friend/family member. Whatever its faults, email remains _the_ professional means of communication. Even if it is feasible to rely only on instant messaging for outgoing communication, it does not affect the issue at hand. If I have an email address for incoming communication, then others can use such email address without my permission to fake my identity. This could be used to access accounts with poor security and damage/sabotage relations by sending inappropriate mail in my name. Imagine a politician for example sought the advice of PrivacyGuides and used [Mailbox.org](http://Mailbox.org) for their public email address. Think of the damage that could be done if another (malicious) person sent bogus mail from that very same address. Recipients may doubt the validity initially, but upon checking the politicians website, they find the email address is indeed the official email of that politician. --- ## Post 5 by @ph00lt0 — 2024-08-23T23:31:00Z This is concering but according to my tests they actually did have SPF and dmarc in place so i am not really sure what is going on here. Besides that morre concerning is Mailbox still supports legacy TLS versions, I mean even microsoft stopped doing so… --- ## Post 6 by @Snowmanonahoe — 2024-08-24T00:50:14Z To add to plonkeyt, we _do_ already make recommendations to improve the privacy and security of products that we explicitly do not recommend because of their ubiquity, e.g. iOS and Windows. --- ## Post 7 by @jonah — 2024-08-24T02:59:08Z What is going on is that (allegedly) their SMTP server allows any authenticated user to send mail with any From address. --- ## Post 8 by @ph00lt0 — 2024-08-24T07:34:21Z I got thrown off by the OP mentioning SPF, DMARC , and DKIM but they do not do anything against that other than preventing using another domain. We should probably test this. If true thid is a relatovely serious security issue. --- ## Post 9 by @TrashPanda — 2024-08-24T08:56:10Z @dngray apologies for pinging you, if I recall correctly you’re using [Mailbox.org](http://Mailbox.org), right? Couls you test? --- ## Post 10 by @arandomduck — 2024-08-26T22:51:16Z According to the [mxtoolbox dmarc lookup tool](https://mxtoolbox.com/SuperTool.aspx?action=dmarc%3amailbox.org&run=toolpage), they do implement DMARC for their mailservers. [This article](https://kb.mailbox.org/en/private/custom-domains/spf-dkim-and-dmarc-how-to-improve-spam-reputation-and-avoid-bounces) also provides relevant information about adding DMARC rules for your custom domain with mailbox. I would also be interested in knowing if it’s fully implemented or not. --- ## Post 11 by @dngray — 2024-08-28T02:07:23Z > [@plonkeyt](#): > > does not properly implement anti-spoofing measures (SPF/DKIM/DMARC) for custom domains, meaning anyone with a [Mailbox.org](http://Mailbox.org) account can send mail from another users email address. With a custom domain you need to configure those records for yourself. I haven’t tried sending a spoofed email, but it should work if the correct policy is in the TXT record. The [mailbox.org](http://mailbox.org) domain has `p=reject` set so that should mean it works for non-custom domains. I’m not sure that thread is still valid. --- ## Post 12 by @anon35626300 — 2024-08-28T04:32:47Z DMARC policies don’t work or aren’t respected with custom domains. I had tried with p=reject and p=quarantine but yet, I was able to recieve emails with my own email address and the email wasn’t sent to spam (should have been with p=quarantine). So, my email address was successfully spoofed. I did the test using [emailspooftest.com](http://emailspooftest.com) --- ## Post 13 by @dngray — 2024-08-28T07:27:55Z > [@anon35626300](#): > > I did the test using [emailspooftest.com](http://emailspooftest.com) Ah that is quite a good test. I tried with: > `v=DMARC1;p=quarantine;rua=mailto:postmaster@example.com;ruf=mailto:hostmaster@example.com` Seems it failed on two tests: > **BEC fake insider protection - Vunerable:** > :Failed :system did not protect against BEC & reply-chain, fake insider attacks > > This vulnerability allows attackers to impersonate ANYONE FROM YOUR COMPANY. This is a highly attacked vulnerability. For me this one is unlikely to make too much of a difference as I’m the only user of the domain. > **Domain attack protection - Vulnerable:** > :Failed :Domain attacks delivered > > This should never get into your inbox. This vulnerability allows attackers to impersonate any email-restricted domain and is commonly used to trick users into clicking ransomware and malware. It did however pass on all other tests with A. - Deliverability test - Validated: Grade: A - Fake subdomain protection - Enforced: Grade: A - Look-a-like protection - Enforced: Grade: A - Subdomain attack protection - Enforced: Grade: A I wonder how other providers we recommend compare. --- ## Post 14 by @anon35626300 — 2024-08-28T08:52:00Z > [@dngray](#): > > **Domain attack protection - Vulnerable:** > :Failed :Domain attacks delivered > > This should never get into your inbox. This vulnerability allows attackers to impersonate any email-restricted domain and is commonly used to trick users into clicking ransomware and malware. This is the test in which [emailspooftest.com](http://emailspooftest.com) sends you an email with your own email address. Ideally it should be blocked and should not reach your inbox. But, for [Mailbox.org](http://Mailbox.org) it lands directly in the inbox and this should not be happening as the user has probably set up “p=quarantine” atleast. Although is not a big deal for a single user but might be harmful for an organisation or even in a family. But it certainly proves that [Mailbox.org](http://Mailbox.org) is not respecting DMARC rules. For Tuta and Proton, it goes to the spam folder with a warning stating that it’s probably a fake email. Also, as per my testings, Tuta performed the best. Then Proton and [Mailbox.org](http://Mailbox.org) came at last. --- ## Post 17 by @anon23293884 — 2024-08-28T09:39:41Z Would love to, but not public. Concerned about the possibility of a vulnerability in the custom domain. Don’t forget that we discuss > [@plonkeyt](#): > > anti-spoofing measures (SPF/DKIM/DMARC) for custom domains If the moderators of the forum or professionals will advise what may be the problem and ways to solve it using secured communication, I will be grateful, fully open to a joint solution. I need to clarify if it is related to hosting settings, I think from my side it is possible to exclude these weaknesses, just requires time. --- ## Post 22 by @Valynor — 2024-08-28T13:40:02Z [off-topic removed, this thread is only about [mailbox.org](http://mailbox.org), not protonmail] --- ## Post 23 by @anon23293884 — 2024-08-28T14:29:36Z > [@dngray](#): > > It did however pass on all other tests with A. > > - Deliverability test - Validated: Grade: A > - Fake subdomain protection - Enforced: Grade: A > - Look-a-like protection - Enforced: Grade: A > - Subdomain attack protection - Enforced: Grade: A > > **I wonder how other providers we recommend compare.** I literally responded with my testing to this comment in this thread… --- ## Post 24 by @pika — 2024-08-28T15:20:15Z yeah test results of other providers would be helpful in determining how [mailbox.org](http://mailbox.org) compared in security with others listed. --- ## Post 25 by @anon23293884 — 2024-08-28T15:23:50Z well, apparently not in this thread, I think we should take the leader’s decision with an open mind and create a separate thread --- ## Post 26 by @asanyan — 2024-08-29T23:06:41Z So, [mailbox.org](http://mailbox.org) is safe as long as you’re using their default domain? --- ## Post 27 by @anon35626300 — 2024-08-30T03:53:05Z Yes except they recycle their domain. --- ## Post 28 by @plonkeyt — 2024-08-31T16:50:39Z Further reason to remove [Mailbox.org](http://Mailbox.org) is its weird implementation of 2FA. It requires you to change your password to a four character pin, and then add the 2FA code to the end of the password when logging in. A couple months of ago they released a BETA version with normal [2FA](https://mailbox.org/en/post/beta-program-starts). But this was 5+ years of [demands](https://userforum-en.mailbox.org/topic/lets-talk-about-2fa-on-this-website-again#comment-1110) for change, during which, the CEO [responded](https://userforum-en.mailbox.org/topic/lets-talk-about-2fa-on-this-website-again#comment-1110) to users in a most dismissive, arrogant, and unprofessional way, saying > I’m sorry, but it’s not equal secure. It’s much much much more INsecure. It is. It is. It is insecure. It is. Totally. Really. Yes. It is. It seems Posteo is more trusted and respected in German [forums](https://www.reddit.com/r/de/comments/7ww496/posteo_vs_mailbox_erfahrungen/). Their communications are far more transparent and clear. There is no justification for the inclusion of [Mailbox.org](http://Mailbox.org) but not [Posteo](https://discuss.privacyguides.net/t/posteo-email-provider/13346/4). The only significant thing separating them is the custom domain feature. It [Mailbox.org](http://Mailbox.org) isn’t implementing it in a secure way, it needs to be removed. Posteo may be right in refusing to implement it to maintain their high privacy/security standards. Anyway, custom domain only provide agency to the user if they purchase a domain themselves, rather hire it from a proxy. This necessarily involves sacrificing anonymity. Privacy and anonymity are not the same, but much of the site is catered toward anonymous use of internet/services, and therefore readers of the guide should be aware of this limitation of custom domains, and providers which do not provide this feature should not, by default, be excluded. --- ## Post 29 by @plonkeyt — 2024-08-31T17:02:35Z All things considered, I think all anti-spoofing measures of all the privacyguides email recommendations need to be tested, for both generic and custom domains. If [Mailbox.org](http://Mailbox.org) fails, then it must be removed. If all fail, the recommendation to use custom domains must be adjusted, and the requirement must be waived (and equally private/secure providers included in recommendation). --- ## Post 30 by @anon37939261 — 2024-08-31T18:45:20Z I just want to point out, that according to the reddit link you shared, It was (at least until 2018, dont know if they fixed it) possible to gain access to the debuglog because of some broken sql-query. This is a claim that I cant verify, so make your own opinion about it. --- ## Post 31 by @plonkeyt — 2024-09-04T17:48:37Z > For me this one is unlikely to make too much of a difference as I’m the only user of the domain. So basically anyone who uses your custom domain can impersonate other users of the custom domain? This is far less significant than the claim made in the Mailbox forum, that users of a Mailbox can impersonate other users of Mailbox. But I don’t understand how this emailspoofing test is testing for this. It seems more like a test for detecting how a provider detects spoofed mail, rather than a providers capability in preventing its users from spoofing the identity of other users. > I wonder how other providers we recommend compare. I setup a separate thread to compare this (as comparisons in this thread were removed my moderator). > [@Email providers anti-spoofing comparison (Proton vs Tuta vs Mailbox.org)](https://discuss.privacyguides.net/t/email-providers-anti-spoofing-comparison-proton-vs-tuta-vs-mailbox-org/20579): > > In response to my [post](https://discuss.privacyguides.net/t/remove-mailbox-org/20232/23) about [Mailbox.org](http://Mailbox.org) potentially having issues in implementing anti-spoofing for custom domains, there is a [demand](https://discuss.privacyguides.net/t/remove-mailbox-org/20232/25) to know the anti-spoofing capabilities of all of the email providers recommended by privacyguides, including Proton, Tuta, and Mailbox. I don’t have a custom domain or understand the anti-spoofing technology, but I’m hoping those who do can do the tests and provide clarity on whether each of the providers protect users from having their email aliases, whether us… --- ## Post 32 by @arandomduck — 2024-09-04T18:37:07Z I have a custom domain with them. I have SPF, DKIM, and DMARC records set with DMARC p=quarantine. I also have DNSSEC enabled for my domain. Mail-tester gives me 10/10 so sending e-mails with my custom domain are highly unlikely to be considered spam. However, [emailspooftest.com](http://emailspooftest.com) gives me F in 2 vectors. It seems like [mailbox.org](http://mailbox.org) doesn’t respect SPF and DKIM failure and consequently, DMARC misalignments. It’s very easy for someone to impersonate my e-mail domain because of this. DMARC p=quarantine should flag the e-mails that have failed SPF or DKIM, and should put them in the junk folder. I also agree that [mailbox.org](http://mailbox.org) should immediately address this issue. These are the results of emailspooftest: |Deliverability test - Validated:|Grade: A| |Fake subdomain protection - Enforced:|Grade: A| |BEC fake insider protection - Vulnerable|Grade: F| |Look-a-like protection - Enforced:|Grade: A| |Domain attack protection - Vulnerable:|Grade: F| |Subdomain attack protection - Enforced:|Grade: A| --- ## Post 33 by @plonkeyt — 2024-09-05T14:17:34Z Thank you for this. So, to be exact but non-technical, which of the following does this mean: 1. Those with an account with mailbox can send mail from your (@example) domain, without permission? 2. Anyone can send mail from your (@example) domain, without your permission? 3. Those with an account with mailbox can send mail from your full email address (mymail@example) without your permission? 4. Anyone can send mail from your full email address (mymail@example) without your permission? 5. Those with an account with mailbox can send mail from your full email address (mymail@example), and those without an account can send mail from your (@example) domain, without your permission? I hope this is exact enough LOL. The various tests and technologies are a bit confusing so I want to spell things to out make things easier to understand. Additionally, does Mailbox generic domains suffer with any of the same problems? And finally, if somebody does any of 1-5, will the receiving email provider be more likely to mark it as spam than if you legitimately use your own account/domain? --- ## Post 34 by @d2d — 2024-09-06T09:05:24Z > [@plonkeyt](#): > > - Those with an account with mailbox can send mail from your (@example) domain, without permission? > - Anyone can send mail from your (@example) domain, without your permission? > - Those with an account with mailbox can send mail from your full email address (mymail@example) without your permission? > - Anyone can send mail from your full email address (mymail@example) without your permission? > - Those with an account with mailbox can send mail from your full email address (mymail@example), and those without an account can send mail from your (@example) domain, without your permission? No [Mailbox.org](http://Mailbox.org) user can send an email with a sender address of another [Mailbox.org](http://Mailbox.org) user (no matter if own domain or not). The mail server says: `Sender address rejected: not owned by user ...@example.com` --- ## Post 35 by @plonkeyt — 2024-09-06T15:45:41Z In this case I don’t know what the problem is, if any. --- ## Post 36 by @plonkeyt — 2024-09-06T18:20:31Z Whatever the specifics, Mailbox [is not transparent](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc) about its DMARC policy: > Additionally, SPF settings are being honored and DMARC settings are a huge factor in our spam recognition. While we don’t honor DMARC at a 100% right now, we do take it into account It also seems their [open PGP support is limited to the main account](https://kb.mailbox.org/en/private/security-privacy-article/activate-your-mailbox-org-guard/), not aliases and custom domains: > **Note:** The [mailbox.org](http://mailbox.org) Guard is designed to work with your main email address. It is not intended to be used in combination with aliases. And > Users need to hand over their private PGP keys to be stored on our servers. … > However, one might argue that encryption keys, which remain password-protected as they sit on our infrastructure, are probably stored more safely and securely with us than on a private PC or smartphone. > Security experts like M. Cardwell have explicitly warned users to not store or use their private OpenPGP keys on devices that are not secure (like smartphones). Who the f\*ck is M. Cardwell? It could be Edward Snowden for all I care, it is still an appeal to authority rather than actual reasoning. Their guide/FAQ is ridiculously long-winded and complicated, packed with pointless sentences like the above. According to their user forums, their support often does answer emails, or are very slow. As mentioned already, their CEO sometimes answers users in the forums, and in a way which absolutely does not give me a sense of trust and professionalism. This was his [response](https://userforum-en.mailbox.org/topic/lets-talk-about-2fa-on-this-website-again#comment-1110) to the unanimous call from his clientelle to use standardized 2FA instead of his confusing alternative: > I’m sorry, but it’s not equal secure. It’s much much much more INsecure. It is. It is. It is insecure. It is. Totally. Really. Yes. It is. --- ## Post 37 by @Finerdly — 2024-09-08T07:38:21Z “New users can only put 2 links in a post” - would’ve been great to know before I wrote all this. I just post the source then. Ban me or whatever if this is against the rules. After all this work I really don’t care :expressionless: **\** @d2d and others already said most of what I’m going to write, but just to try to summarize and clarify the situation in relation to the [initial post of this thread](https://discuss.privacyguides.net/t/remove-mailbox-org/20232): ### Outgoing mail of [mailbox.org](http://mailbox.org) users (the not existing problem) #### Sending via [mailbox.org](http://mailbox.org) mail server - It is not possible for a [mailbox.org](http://mailbox.org) user to send mails as another existing user via [mailbox.org](http://mailbox.org)’s mail servers. - ("_As another user" meaning FROM address being mail address of the other user)_ - It is not possible for a [mailbox.org](http://mailbox.org) user to send mails from another user’s custom domain via [mailbox.org](http://mailbox.org)’s mail servers. - _(“from another user’s custom domain” meaning FROM address being [xyz@another-users-custom-domain.com](mailto:xyz@another-users-custom-domain.com))_ Source: I have a [mailbox.org](http://mailbox.org) account with custom domains set up and created a second [mailbox.org](http://mailbox.org) account to test the two scenarios. _(Also other people in this thread stated this already)_ > **My SMTP logs (censored)** > > #### Sending mail via [mailbox.org](http://mailbox.org)’s mail server with FROM-address being another existing user’s mail address > > $ openssl s\_client -starttls smtp -connect [smtp.mailbox.org:587](http://smtp.mailbox.org:587) -crlf -quiet > Connecting to 185.97.174.196 > depth=2 C=US, O=DigiCert Inc, [OU=www.digicert.com](http://OU=www.digicert.com), CN=DigiCert Global Root G2 > verify return:1 > depth=1 C=US, O=DigiCert Inc, [OU=www.digicert.com](http://OU=www.digicert.com), CN=Thawte TLS RSA CA G1 > verify return:1 > depth=0 CN=\*.mailbox.org > verify return:1 > 250 CHUNKING > EHLO [mailbox.org](http://mailbox.org) > [250-smtp202.mailbox.org](http://250-smtp202.mailbox.org) > 250-PIPELINING > 250-SIZE 143699726 > 250-ETRN > 250-AUTH PLAIN LOGIN XOAUTH2 OAUTHBEARER > 250-AUTH=PLAIN LOGIN XOAUTH2 OAUTHBEARER > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-DSN > 250 CHUNKING > AUTH LOGIN > 334 VXNlcm5hbWU6 (== ‘Username:’ in base64) > [account2-user] (base64-encoded) > 334 UGFzc3dvcmQ6 (== ‘Password:’ in base64) > [account2-password] (base64-encoded) > 235 2.7.0 Authentication successful > MAIL FROM:[account1@mailbox.org](mailto:account1@mailbox.org) > 250 2.1.0 Ok > RCPT TO:[my-gmail-account@gmail.com](mailto:my-gmail-account@gmail.com) > 553 5.7.1 [account1@mailbox.org](mailto:account1@mailbox.org): Sender address rejected: not owned by user [account2-user@mailbox.org](mailto:account2-user@mailbox.org) > > #### Sending mail via [mailbox.org](http://mailbox.org)’s mail server with domain in FROM-address being another existing user’s custom domain > > $ openssl s\_client -starttls smtp -connect [smtp.mailbox.org:587](http://smtp.mailbox.org:587) -crlf -quiet > Connecting to 185.97.174.196 > depth=2 C=US, O=DigiCert Inc, [OU=www.digicert.com](http://OU=www.digicert.com), CN=DigiCert Global Root G2 > verify return:1 > depth=1 C=US, O=DigiCert Inc, [OU=www.digicert.com](http://OU=www.digicert.com), CN=Thawte TLS RSA CA G1 > verify return:1 > depth=0 CN=\*.mailbox.org > verify return:1 > 250 CHUNKING > EHLO [my-custom-domain-of-account1.com](http://my-custom-domain-of-account1.com) > [250-smtp102.mailbox.org](http://250-smtp102.mailbox.org) > 250-PIPELINING > 250-SIZE 143699726 > 250-ETRN > 250-AUTH PLAIN LOGIN XOAUTH2 OAUTHBEARER > 250-AUTH=PLAIN LOGIN XOAUTH2 OAUTHBEARER > 250-ENHANCEDSTATUSCODES > 250-8BITMIME > 250-DSN > 250 CHUNKING > AUTH LOGIN > 334 VXNlcm5hbWU6 (== ‘Username:’ in base64) > [account2-user] (base64-encoded) > 334 UGFzc3dvcmQ6 (== ‘Password:’ in base64) > [account2-password] (base64-encoded) > 235 2.7.0 Authentication successful > MAIL FROM:[mail@my-custom-domain-of-account1.com](mailto:mail@my-custom-domain-of-account1.com) > 250 2.1.0 Ok > RCPT TO:[my-gmail-account@gmail.com](mailto:my-gmail-account@gmail.com) > 553 5.7.1 [mail@my-custom-domain-of-account1.com](mailto:mail@my-custom-domain-of-account1.com): Sender address rejected: not owned by user [account2-user@mailbox.org](mailto:account2-user@mailbox.org) #### [Mailbox.org](http://Mailbox.org)’s support of SPF, DMARC and DKIM - **SPF, DMARC and DKIM for outgoing mail of [mailbox.org](http://mailbox.org) users are working as intended.** - If other people will receive emails spoofing/faking your email address depends on the mail server of the recipient. Source: SPF, DMARC/DKIM working for outgoing mail I verified a lot when setting it up maybe 1 or 2 years ago, I also verified a few times since then, and it’s been working as expected ever since. ### Incoming mail to [mailbox.org](http://mailbox.org) users (the actual problem) - It seems like [mailbox.org](http://mailbox.org) often does not respect dmarc policies like quarantine _(set by the sender or sender’s mail provider)_ and still delivers to [mailbox.org](http://mailbox.org) users’ inbox - as multiple other users here I can also confirm this. They say they do take it into account though: > Additionally, SPF settings are being honored and DMARC settings are a huge factor in our spam recognition. While we don’t honor DMARC at a 100% right now, we do take it into account. [[mailbox.org Support, 2023-06-28](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-2910)] - It seems to me they decided to not fully honor DMARC policies, but still take it into account when “calculating” if incoming mail is spam or not. - It seems like they err a bit too much on the “not spam”-side when SPF, DMARC/DKIM come into play. As far as I know that is not unique to [mailbox.org](http://mailbox.org) though? But I don’t have proof for that :wink: - I wonder why they say SPF settings are being honored (in comparison to dmarc being “not honored 100%”). The [emailspooftest.com](http://emailspooftest.com) results seem to indicate SPF fails also don’t lead to mails being delivered to junk folder. I dunno, the [linked post](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-2910) is not very clear on that. I think they should honor dmarc “more” (maybe even 100%, but let’s not get crazy here). While it obviously doesn’t affect outgoing mail, **it makes [mailbox.org](http://mailbox.org) users a lot more susceptible to phishing and similar attacks.** I hope this post helps people that are not that deep into this topic. To the other ones: feel free to correct me if I got something wrong :smile: --- ## Post 38 by @plonkeyt — 2024-09-08T13:56:27Z @d2d and @Finerdly make clear that initial problem I highlighted is not a problem. Do people think its safe to say that it is resolved? My only doubt is that both accounts seem to have been setup specifically to respond to this post. I think a reproduction of Finerdly’s tests by somebody equally knowledgeable and who is already a contributor to PG would put this issue to bed. (I mean no disrespect @Finerdly thanks for the contribution) In which case the anti-spoofing problem is merely the following: 1. [Mailbox.org](http://Mailbox.org) does not send some mail to spam which should be sent to spam 2. [Mailbox.org](http://Mailbox.org) are poor at communicating. As stated in OP, I didn’t make up this problem - somebody claimed it in their forum, [mailbox.org](http://mailbox.org) confirmed it, and never said it was fixed. > [This issue](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-1450) was [confirmed by Mailbox.org](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-1524) four years ago, with [unfulfilled promises](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-2529) to fix it since. --- ## Post 39 by @TeCer — 2024-09-08T16:22:54Z it’s not just a dmarc problem, [mailbox.org](http://mailbox.org) servers don’t verify either spf or dkim just try a tool like emkei.cz on my address @mailbox.org and on my adress @mycustomdomain.com (hosted on [mailbox.org](http://mailbox.org)) i can receive mail from any domain. --- ## Post 40 by @Snowmanonahoe — 2024-09-08T21:17:36Z > [mailbox.org](http://mailbox.org) does not only offer a webinterface (like other services!) where we can restrict access and we can forbid any login with password-only. We also offer different/many different services and protocols like SMTP, XMPP and much more (and much more will be added in the future) that must still be open for password-logins. For that, a stolen/sniffed password CAN be used to gain access to different services and accounts. then use fucking oauth oh my god --- ## Post 41 by @dngray — 2024-09-09T02:13:24Z > [@Snowmanonahoe](#): > > then use fucking oauth oh my god They are [rolling that out now](https://mailbox.org/en/post/beta-program-starts). --- ## Post 42 by @d2d — 2024-09-09T18:44:50Z > [@plonkeyt](#): > > My only doubt is that both accounts seem to have been setup specifically to respond to this post Good point. So far I’ve had no reason to create an account here. In another forum (where I’ve been active for a while) this topic was linked. And because information is missing here that is available in the other forum, I registered here. The message I mentioned from the outgoing mail server can be checked by anyone with an account, so it’s not a secret. > [@plonkeyt](#): > > [Mailbox.org](http://Mailbox.org) are poor at communicating Yes, the communication is not good. To be fair, it’s a forum by users for users (users helping other users) and not a classic support forum. I use [Mailbox.org](http://Mailbox.org), Posteo and tuta and haven’t had a bad experience with any of them. Good support (not much contact) and no problems with spam (none or very few and my emails have always arrived including from my own domain. I think all three are good enough to recommend. Of course there is always something to improve here and there, but where is that not the case? --- ## Post 43 by @plonkeyt — 2024-10-02T09:07:25Z I [suggest](https://discuss.privacyguides.net/t/are-bigger-projects-more-trustworthy/21194/8) Mailbox is an example of a poorly structured (and therefore less trustworthy) team. > Also, the size of a team may not matter if the leader doesn’t involve others in the decision making processes. I know [I’ve been quite critical](https://discuss.privacyguides.net/t/remove-mailbox-org/20232) of Mailbox, but I think they may be an example. Their guide seems written by one very well knowledgeable guy (Sir Mr expert Heinlein) but not proofread by the people who need the guide (causing A LOT of confusion). Their news lists his media appearances, but no sign of other staff. And he responds to people in the forums, often in quite a dismissive manner to reasonable criticism of the service. Unlike its competitors, their [website](https://mailbox.org/en/company#our-team) does not reveal the identity of any employees besides the leader. [Proton](https://proton.me/about/team) lists many many directors and managers. [Posteo](https://posteo.de/en/site/about_posteo) has three people (two of which a couple). [Tutanota](https://tuta.com/team) has a paragraph on the whole team, but the hierarchy is unclear. I mean to no harm to Mailbox or to Peer Heinlein, who I feel like I’m criticizing when I criticize Mailbox, which in itself I consider to be criticism of Mailbox (but I hope not Heinlein). But trust is too important in the case of email for me to ignore my doubts about Mailbox. --- ## Post 44 by @plonkeyt — 2024-10-04T19:52:08Z To be fair, it is good that Peer Heinlein is willing to respond to users, both in their community forums, and on Reddit (maybe he can join us here too one day). I said he “often” responds in “quite a dismissive manner” which I’m not sure is true. He did in relation to the 2FA issue - an issue on which he eventually his mind, though it took about 5 years. I’m very curious about how Mailbox is perceived in the German tech/privacy world. Can any non-Heinlein sources attest to Heinlein’s prestige? I mean, [did he really invent “the fully encrypted inbox”?](https://tarnkappe.info/artikel/interviews/mailbox-org-came-after-the-snowden-revelations-a-talk-with-peer-heinlein-94431.html) --- ## Post 45 by @crystalshower — 2025-03-18T15:28:03Z I don’t understand how email security works but is this relevant to this threads? > > > Be aware that Mailbox.org allows any user to send emails as ("from") any other user via SMTP and these emails will look legit since they pass SPF and DKIM checks. Many consider this a security issue.

There was a quite lengthy discussion about this in their forum but they deleted it since. They refused to fix it. Archive.org still has it. Content is in German (sorry):

Whenever an e-mail has been flagged as spam by our systems, it will be rejected. That means our server will deny accepting the e-mail message and the system at the other end (the client) will issue a delivery failure notice to the sender (the message „bounces“). [Source](https://kb.mailbox.org/en/private/e-mail-article/customizing-your-mailbox-org-spam-filter-settings/) I understand their point about false positives but that’s why the spam folder exists… Or at least display a warning in the interface. --- ## Post 53 by @anon11657877 — 2025-08-19T21:20:52Z > [@plonkeyt](#): > > [Mailbox.org](http://Mailbox.org) does not properly implement anti-spoofing measures (SPF/DKIM/DMARC) for custom domains, meaning anyone with a [Mailbox.org](http://Mailbox.org) account can send mail from another users email address. > > [This issue](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-1450) was [confirmed by Mailbox.org](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-1524) four years ago, with [unfulfilled promises](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-2529) to fix it since. Do these issues still apply? Without proper anti-spoofing, nothing else matters. --- ## Post 54 by @carbonated — 2025-08-19T22:38:28Z No, this is not possible (anymore), see here: > [@Remove Mailbox.org](https://discuss.privacyguides.net/t/remove-mailbox-org/20232/37): > > “New users can only put 2 links in a post” - would’ve been great to know before I wrote all this. I just post the source then. Ban me or whatever if this is against the rules. After all this work I really don’t care expressionless \ @d2d and others already said most of what I’m going to write, but just to try to summarize and clarify the situation in relation to the [initial post of this thread](https://discuss.privacyguides.net/t/remove-mailbox-org/20232): Outgoing mail of [mailbox.org](http://mailbox.org) users (the not existing probl… The only issue is them not respecting DMARC and SPF fully, but as I was never hit with spam mails in all these years it seems to me neglectable. --- ## Post 55 by @dngray — 2025-08-20T04:29:06Z also the stuff about their 2FA implementation is no longer relevant. > **[The official mailbox.org beta program starts! | mailbox.org](https://mailbox.org/en/post/beta-program-starts)** > > Our official beta program for all private customers starts today. Be the first to test our latest functions. > **[The new and improved Login 2.0 | mailbox.org](https://mailbox.org/en/post/the-new-login)** > > What was previously only available as a beta version for selected testers is now being activated for all customers: the new Login 2.0. --- ## Post 56 by @SwampTrainer — 2025-08-20T05:15:53Z I was looking at them to De-Google a year ago and their lack of real 2FA and questionable custom domain issues were a dealbreaker. I just can’t believe it took them SO long to implement normal 2FA. April of 2025? It was “in testing and almost roll out” last summer IIRC. --- ## Post 57 by @dngray — 2025-08-20T05:31:11Z It was a whole SSO solution, and tbh it’s not unsurprising that they wanted to test that thoroughly before making it generally available. I didn’t have any issues during beta, so yeah. I’m hoping the next bunch of tests will be something like google’s XOAuth, allowing for FIDO2/TOTP auth on IMAP. A proper SSO solution was needed first though no doubt. --- ## Post 58 by @CarefulMouse — 2025-08-22T14:47:25Z This blog post caught my eye because it seems contrary to much of the security concerns shared in this post. It is hard for me to understand the scope of impact of the concerns shared here. > **[BSI gold status for mailbox.org | mailbox.org](https://mailbox.org/en/post/bsi-awards-mailbox-org-gold-status)** > > mailbox.org receives BSI gold status for email security. Find out what this means for you in our blog! --- ## Post 59 by @anon11657877 — 2025-08-22T16:06:16Z They only seem to check if there’s a valid DMARC policy but not if it’s enabled, because Posteo also got gold status and it doesn’t even have a strict DMARC. Unless the policy is set to `reject` or `quarantine` it’s useless. --- ## Post 61 by @Vadim — 2025-11-12T00:31:06Z ### Why should this tool be removed? [Mailbox.org](http://Mailbox.org) has several security issues and should be considered for removal as it is advertised to be a secure mailbox solution. Issues: - Mailbox announced that the user now has the option to deactivate the password reset (and 2FA reset) via IMAP. However, the default setting is that a reset via IMAP is enabled and will reset the password and 2FA. Based on the Support it will stay that way - They don‘t have any security notification or dashboard where you can see sessions, failed logins, recent actions like password changes. No notification when 2FA was activated, when password was changed, when IMAP password has been created etc. unlike Tuta, Fastmail, Proton, etc. - No OAuth or YubiKey support for 2FA - No recovery codes possible for 2FA TOTP - No SPAM/Rejection-Log - Increase of vulnerabilities and minimal response provided by Mailbox team - No roadmap or timeline to implement anti-spoofing for custom domains Related Thread: [https://discuss.privacyguides.net/t/mailbox-org-with-severe-authentication-vulnerability-through-password-reset/31846/16](https://discuss.privacyguides.net/t/mailbox-org-with-severe-authentication-vulnerability-through-password-reset/31846/16) --- ## Post 62 by @mika — 2025-11-12T03:36:08Z Refreshing this post I made in the other thread: > I’ve also been dissatisfied with Mailbox for the reasons you’ve listed but I’m still on Mailbox because I’m not aware of any other privacy-friendly email provider that: > > - Is reputable / not brand new > > - Supports IMAP in some form > > - Supports CardDAV (or otherwise syncs with phone contacts) > > - Supports custom domains > > Tuta, Proton, and Posteo all fail at least one of the above. Mailfence made a topic a few months ago but then disappeared when asked for specifics on their privacy claims. IMAP is the only one I could possibly flex on, but Proton and Tuta don’t support CardDAV so it’s a moot point anyways. If we remove Mailbox (which I’d be okay with) we need to figure out what the next best option is. Proton, Tuta, and Posteo are great but are not ‘plug and play’ for many general use cases due to missing at least one of the common, widely used, often necessary features listed above. --- ## Post 63 by @LogicBrawler — 2025-11-12T09:54:27Z > ``` > Mailbox announced that the user now has the option to deactivate the password reset (and 2FA reset) via IMAP. However, the default setting is that a reset via IMAP is enabled and will reset the password and 2FA. Based on the Support it will stay that way > ``` So the user can still use 2FA if they want. > ``` > Far behind competitors regarding features > ``` Cry about it. Not a good reason to remove mailbox. > They don‘t have any security notification or dashboard where you can see sessions, failed logins, recent actions like password changes. No notification when 2FA was activated, when password was changed, when IMAP password has been created etc. unlike Tuta, Fastmail, Proton, etc. You can view which devices are logged in in the dashboard settings. > ``` > No OAuth or YubiKey support for 2FA > No recovery codes possible for 2FA > ``` Not really anti-privacy features. > ``` > No SPAM/Rejection-Log > ``` Not really an anti-privacy feature so moot point. > ``` > Increase of vulnerabilities and minimal response provided by Mailbox team > No roadmap or timeline to implement anti-spoofing for custom domains > ``` I believe the anti-spoofing is handled by the domain host with dmarc records. There are a series of records one needs to add and if you don’t know the process, then one shouldn’t be messing with a custom domain. Also, a custom domain is not private at all. I thought this was a privacy forum? So far you’ve just whined about their security measures. What about Proton requiring a backup email which has been used in one instance by the authorities to break into a user’s mailbox (user used a gmail)? Mailbox is still the best email provider that supports third party email clients. Proton still doesn’t have a linux app. No carddav or caldav. For all these reasons, Mailbox is the best in its class. If one wants to commit crimes, then yeah use Proton. But how many people in your inner circle use Proton? Its like the same debate on whether to use Signal. If you’re sending emails to other gmail users you’re not getting much benefit from Proton. If you’re not emailing other proton users, you’re not getting that e2ee anyways. Still, Mailbox is the best for the average user. --- ## Post 64 by @Vadim — 2025-11-12T14:39:15Z I would like to remind folks of PrivacyGuides’ goal to find a “balance of privacy, security, and convenience” when it comes to recommended tools. [Mailbox.org](http://Mailbox.org) and services like Proton Mail serve two different types of users. I agree with you on how my concerns are security related (although the “whining” is a bit immature to assume) rather than privacy related. I believe an argument could be made either way based on the facts. 1. **Prioritizing Open Standards & Privacy:** As person looking for a private, non-advertising email provider and with open standards, [Mailbox.org](http://Mailbox.org) is one of the best in this specific class. 2. **Prioritizing Maximum Security:** A person looking for end-to-end encryption (E2EE) and the most robust, phishing-resistant security, and is willing to sacrifice convenience and open protocols to get it, should choose a service like Proton. I myself fall into the later group and prefer to have stronger security over privacy. Ideally it is not an either or, but a both focused on security. Finding the sweet spot has been an enduring effort for me and I have been a [Mailbox.org](http://Mailbox.org) user for a couple of years now. I continue to strive to find that sweet spot product and it is one of the reasons I moved away from Proton and over to Mailbox. I believe we could do better or lobby the providers more to achieve these goals. At a minimum the PrivacyGuides listing for [Mailbox.org](http://Mailbox.org) should be updated to clearly feature these caveats so the user could make their own educated decision: - **Security Weakness:** “Lacks support for hardware-based 2FA (U2F/YubiKey). Only TOTP (authenticator apps) is supported.” - **Security Weakness:** “Enables password reset via IMAP by default. Users must manually disable this feature in their security settings for proper account protection.” References: > **[Home](https://www.privacyguides.org/en/#what-should-i-do)** > > Established in 2021, Privacy Guides is the most popular & trustworthy non-profit resource to find privacy tools and learn about protecting your digital life. --- ## Post 65 by @Regime6045 — 2025-11-12T16:23:23Z > [@Vadim](#): > > Far behind competitors regarding features The other two PG-recommended email providers (Proton & Tuta) don’t even have IMAP, so if anything it’s the opposite. --- ## Post 66 by @Shampoo — 2025-11-12T16:33:13Z > **[IMAP, SMTP, and POP3 setup | Proton](https://proton.me/support/imap-smtp-and-pop3-setup)** > > Proton Mail Bridge allows you to integrate your inbox with most mail clients that support IMAP and SMTP protocols. Proton does --- ## Post 67 by @tibetfuchs — 2025-11-12T16:37:52Z > [@Regime6045](#): > > if anything it’s the opposite. Great, then lets hear what features they offer despite the ONE point you made. No Apps, No Push notifications, No Spam logs, No Yubikey Support, No Recovery Codes, and the list goes on… --- ## Post 68 by @Regime6045 — 2025-11-12T16:55:47Z \>No Apps, No Push notifications, Usecase? Just use any email client \>No Spam logs, Not sure what you mean but it seems that you can change a setting so that it doesn’t reject spam mails but puts them in a spam folder instead \>No Yubikey Support, No Recovery Codes, TOTP is good enough for most people --- ## Post 69 by @tibetfuchs — 2025-11-12T16:56:46Z Curious if you belong to mailbox or if you are just an ultra-fanboy that doesn‘t allow any critisism of his favorite service. But alright lets go into detail: > „So the user can still use 2FA if they want“ Yes, but the big problem is that they only backpaddled after some users made posts and critized this feature heavily. It was not by mistake, instead the mailbox team decided on purpose that its ok to bypass 2FA with an IMAP Application password. > „Cry about it. Not a good reason to remove mailbox“ Lol what an attitude. The fact that they are far behind the other competitors is of course not the only reason to remove the service but instead the cherry on top why it should be removed. If they would offer any meaningful advantage over the competitors or even be on-par with them would make this vulnerability (and the other security issues) maybe more tolerable, but they have worse security while also being behind with other topics → a dealbreaker > „You can view which devices are logged in in the dashboard settings.“ Great, so they now fullfill 1 out of 6 points I mentioned. Not really a good argument. They still don‘t have failed logins, recent actions like password changes. No notification when 2FA was activated, when password was changed, when IMAP password has been created. > „Not really anti-privacy features.“ > > „Not really an anti-privacy feature so moot point.“ Looks like somebody does not understand that security and privacy are often depended on each other. But ok, if you want to hear how bad they can be regarding privacy: A few months back for about 9 hours emails from a catch all accounts were displayed in other mailboxes withing the same domain. Very private to have your emails visible in another accounts… > „Mailbox is still the best email provider that supports third party email clients“ > „Mailbox is the best in its class“ > > „Still, Mailbox is the best for the average user.“ How can you seriously still claim something like that after all those arguments? --- ## Post 70 by @tibetfuchs — 2025-11-12T17:02:24Z > usecase? Just use any email client -\> Its an absolute basic feature of an mail provider. I would rather have a solid app from my mail provider than let another party read my mails. > Not sure what you mean but it seems that you can change a setting so that it doesn’t reject spam mails but puts them in a spam folder instead -\> nope, this does not fix the issue. Even when setting the Spam filter as weak as possible Mailbox will still reject emails without notifying the user (lots of reports in the userforum) > TOTP is good enough for most people -\> Probably yes, but we are talking about privacy and security oriented people and yubikey is often considered as the best 2FA method. Also do you now any other service that does not offer recovery codes when using TOTP? I dont --- ## Post 71 by @tibetfuchs — 2025-11-12T17:13:21Z And another point: Although to be fair this was 8 years ago and is no longer the case but I want to mention it anyway to prove my point that mailbox has serious issues regarding security and privacy. A reddit user investigated ( [Reddit - The heart of the internet](https://www.reddit.com/r/de/comments/7ww496/posteo_vs_mailbox_erfahrungen/) ) and found: 1. mailbox offered to store your private key on their server 2. Frontpage of mailbox is wordpress 3. Roughly translated: I’ve got all the user sessions from 2016 in front of me right now — and not because I’m doing any shady hacker stuff, but because the debug log is publicly readable on the server and it’s outputting a broken SQL query --- ## Post 72 by @LogicBrawler — 2025-11-12T18:33:11Z > „Mailbox is still the best email provider that supports third party email clients“ > „Mailbox is the best in its class“ > > „Still, Mailbox is the best for the average user.“ > How can you seriously still claim something like that after all those arguments? I stand by what I said. As in IMAP, privacy-focused providers, yes Mailbox is the best in its class. I am not putting Proton in the same class. They are fundamentally different. If you intend to commit crimes and circumvent governments, then yes go with Proton. It all depends on your threat model. For the average user, Mailbox is one of the best. --- ## Post 73 by @LogicBrawler — 2025-11-12T18:36:30Z > [@Shampoo](#): > > [IMAP, SMTP, and POP3 setup | Proton](https://proton.me/support/imap-smtp-and-pop3-setup) > > Proton does Not on mobile. The bridge thing is a pretty lame bandaid for the lack of support. This is where Mailbox does well because you can also have e2ee with openpgp but also supports caldav, carddav, and webdav (use with Cryptomator). --- ## Post 74 by @plus-subzero — 2025-11-12T21:18:26Z > [@Vadim](#): > > No notification when 2FA was activated, when password was changed, when IMAP password has been created It’s not widely supported. Outside of Gmail, Outlook, and Zoho I don’t know of other providers that do this (not sure about Tuta/Proton). App-passwords and similar notifications are also less useful than they sound unless they’re sent to a recovery address you actively monitor (not a given for a service that doesn’t require an email address to sign up). Nevertheless, they could do a lot better. The more you use it, the more it feels borderline insecure email service, with privacy gimmicks piled on top. Yes, they allow you to upload your public key, but they don’t properly implement anti-spoofing measures. It’s crazy that people are ditching Gmail for this, if you think about it. I wouldn’t go so far as to call it an irresponsible recommendation, but the trade-offs versus the status quo are substantial, and people are typically not aware of them. --- ## Post 75 by @LogicBrawler — 2025-11-13T16:59:51Z > It’s crazy that people are ditching Gmail for this Not at all. Its a choice you have to make. Give up your rights for a false sense of security, and have all of your emails read by algorithms, ai and any engineers at Google to sell you junk online, or use Mailbox. Its becoming clear that there are different segments of this privacy forum. There are individuals who just want a relatively secure email (gmail), people who want privacy from governments (proton), and a middle-ground group that wants the convenience of what they’re used to but with privacy from big tech (mailbox). --- ## Post 76 by @tibetfuchs — 2025-11-13T17:22:13Z Ok, do you also want to respond to all the other points I made? --- ## Post 77 by @LogicBrawler — 2025-11-13T17:48:34Z Not particularly --- ## Post 78 by @plus-subzero — 2025-11-13T20:44:09Z > [@LogicBrawler](#): > > Not at all. Its a choice you have to make. Give up your rights for a false sense of security, and have all of your emails read by algorithms, ai and any engineers at Google to sell you junk online, or use Mailbox. I don’t mean to defend Google, but I’ll go out on a limb and say your email contents are likely safer with Google than with an outfit like mailbox and can be accessed by far fewer people, too. They don’t profile you on Gmail content anymore (same for Outlook), and the privacy settings they expose seem sufficient to limit much of the other nonsense they shove at you. Proton would have been a better example as it’s zero-knowledge out of the box. I’d love a good, standards-compliant, no-nonsense email provider that covers the basics and more, the middle ground, as you call it, but this isn’t it. --- ## Post 79 by @LogicBrawler — 2025-11-14T15:28:55Z If you’re willing to go on a limb, I also have a bridge to sell. I shouldn’t have to bring up the fact that Google has had lawsuits filed against them and found guilty of collecting user data even in incognito mode. So yeah, I am sure that ai bot summarizing my emails is not collecting any information :wink: --- ## Post 80 by @crossroads — 2025-11-14T16:02:56Z > [@plus-subzero](#): > > your email contents are likely safer with Google than with an outfit like mailbox and can be accessed by far fewer people If you mean probability that random employee will take a look at my emails - yes, it’s higher with smaller providers who have actual people working there. If you mean access to gathered, sorted and analyzed content of my emails, which is that shared with their 1253 partners who care about my privacy - than chances google (microsoft, yahoo, yandex…) will do that are way higher. When it comes to security, I also assume Google (MS and others) is always on high alert, but it is also bigger target. Also smaller, but trustworthy providers are for sure capable of keeping their services safe. Better than I would do, if I were selfhosting it. Regarding Mailbox,org, I agree IMAP password reset is possible vulnerability, but if user can deactivate it, than it is OK. Should it be off by default - I’m not sure, and for me, it’s not a big deal. --- ## Post 81 by @plus-subzero — 2025-11-14T17:14:04Z I meant employees at Google having access to Gmail contents of individual users. I don’t doubt their capacity for duplicity or for misconfiguration issues whereby the data you think isn’t being collected actually is (Many such cases!). I still think you’re better off with them than with mailbox, or at least with a proper middle‑ground provider such as Fastmail (jurisdiction questions aside) that can clearly explain their technological (and other) choices. I’ve been a mailbox customer long enough to remember they gaslighted people who pointed out their 2FA was silly, only to eventually cave and provide a standard implementation as if nothing had happened. Suddenly, 2FA “offers a way to reliably secure access to your mailbox account” instead of the insane shared‑computer scenario they previously cocked up to justify their weak 2FA choices before their knowledge base was redone. This makes them look ideological, which implies incompetence, and I’m tired of people recommending them with a straight face. I’m not, by the way, a Gmail user, and I don’t use Google services, except for maintaining a Google account to access Play Store apps on my GrapheneOS device and for watching some YouTube. --- ## Post 82 by @Lando — 2025-11-25T20:33:34Z Mailbox straight up ignores SPF and DMARC Records of incoming mails is a serious threat in my opinion, this also contradicts with their own claims. Further up, there are already some people who have shared their observations on this, and I was able to replicate these results. I **received every email from every domain I spoofed** and sent with [https://emkei.cz/](https://emkei.cz/) and others. In [this press realease](https://mailbox.org/de/presse/mailbox-erreicht-goldstatus-im-bsi-e-mail-sicherheitsjahr-2025/) they claim that they are implementing DMARC [..] SPF as defined in [TR-03182](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03182/TR-03182_node.html) „E-Mail-Authentifizierung". To comply a M(ail)H(andling)S(ervice) has to comply with: > **4.1.2 SPF Verification** > […] If it is not authorized and the sending domain’s SPF policy requires Fail, the MHS SHOULD implement the instruction according to the sending domain’s SPF policy. […] > **4.1.7 Verifying DMARC** > […] If a DMARC policy already exists, the MHS MUST check the policy. If there is a DMARC policy violation, the MHS SHOULD handle the message according to the DMARC policy of the sending domain. If the MHS deviates from the processing specifications, e.g., using local-overrides, the operator MUST justify and document this […] And what exactly does [mailbox.org](http://mailbox.org)’s spam filter do, other than sit back and watch emails land in the inbox as if everything were perfectly normal? However, the criteria of privacy guides do not help resolving this issue: > **Minimum to Qualify:** > > - Valid [DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) records. > - Valid [SPF](https://en.wikipedia.org/wiki/Sender_Policy_Framework) and [DKIM](https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail) records. > - Must have a proper [DMARC](https://en.wikipedia.org/wiki/DMARC) record and policy or use [ARC](https://en.wikipedia.org/wiki/Authenticated_Received_Chain) for authentication. What about verify for incoming mails? > Must support viewing of [message headers](https://en.wikipedia.org/wiki/Email#Message_header), as it is a crucial forensic feature to determine if an email is a phishing attempt. Who checks the headers of every email for SPF and DMARC compliance because their (by privacyguides recommended) receiving mail service is not honoring SPF and DMARC? --- ## Post 83 by @paulrudy — 2025-11-25T20:48:06Z > [@ **Lando**](#): > > And what exactly does [mailbox.org](http://mailbox.org)’s spam filter do, other than sit back and watch emails land in the inbox as if everything were perfectly normal? Definitely agree. The spam filter is worthless --- ## Post 84 by @tibetfuchs — 2025-11-25T21:00:50Z How and when will a decision be made? There are a lot of reasons in this (and in other threads) for removing the service from the recommendations (at least until the drasticly improve and fix their problems). Some members of Privacy Guide already shared their frustration, but how do you proceed? --- ## Post 85 by @lyricism — 2025-11-25T22:59:01Z I’ll be honest, I don’t _really_ care if it’s removed or not, but it seems like they are addressing all the significant\* concerns, no? Or is the standard that any mistakes at any time will result in removing a recommendation? I also see it as a really good alternative to Proton and Tuta because it allows you to bring your own keys and integrates very well with standard IMAP clients when using as such so it would be at least a little bit of a shame to remove it. \*I personally don’t think strict DMARC adherence is a significant concern for a privacy-based recommendation --- ## Post 86 by @tibetfuchs — 2025-11-26T06:33:05Z > [@lyricism](#): > > Or is the standard that any mistakes at any time will result in removing a recommendation? No that would be ridicolous. But removing a service that makes dozens of mistakes without providing any advantages over competitors (or even be on the same level) is valid. --- ## Post 87 by @lyricism — 2025-11-26T11:13:02Z > [@tibetfuchs](#): > > dozens of mistakes What are the “dozens” of mistakes Mailbox has made? I’ve seen like 3 at most. > [@tibetfuchs](#): > > without providing any advantages over competitors See this just feels dishonest. I literally just explained a fairly important one in the post you’re replying to. --- ## Post 88 by @Enjudger — 2025-11-30T08:19:56Z Unless there is some aspect I am missing this seems to be at least partially mitigable using the sieve filter feature they provide. An “Authentication-Results” header seems to be getting added on the incoming mail, which identifies bad spf/dkim/dmarc results, and that be checked in a sieve filter like so: ![Untitled](https://forum-uploads.privacyguidesusercontent.com/original/3X/d/b/dbe22c1b8d96914762b9c2875015f17adcf9c3c7.png) It’s not great that they aren’t handling it by default, but it seems to be possible to do something yourself. My naive filters just stick anything marked spf=fail, spf=softfail, dkim=fail, or dmarc=fail into spam, a more complex set of filters may be able to handle it more appropriately. --- ## Post 89 by @tibetfuchs — 2025-12-08T21:19:15Z > „See this just feels dishonest. I literally just explained a fairly important one in the post you’re replying to“ Yes you are right, they have the option to use a custom domain and they offer IMAP and other standards. Those are fair advantages. But those do not make them stand out since e.g. Fastmail offers them as well but has more and better features, while not having any major security problems. > „What are the “dozens” of mistakes Mailbox has made? I’ve seen like 3 at most.“ I feel like this is a good moment to summarize again and outline why this service NEEDS to be removed: 1. Enabling a password reset via IMAP that fully resets strong passwords AND 2FA. Not by Mistake but instead with full intention and also only giving the option to deactivate this feature after many angry users complained. This vulnerability is still enabled by default! 2. Emails from catch-all accounts belonging to other mailboxes of the same domain were visible in other users’ inboxes 3. Having a debuglog publicy available that exposed user sessions 4. Offering to store private key on mailbox servers 5. Even after the 2FA-Beta AND after configuring the Application Passwords the main password was still valid to use for applications 6. Citation from today: „In summary, as of today December 8th, 2025, the challenge with [Mailbox.Org](http://Mailbox.Org) Business email services is that it is still VERY WEAK SECURITY. Why? Because there is NO 2FA on the Business ADMINISTRATOR account. The activated 2FA is only for the Business USER accounts. This is a major security risk. Why? Because the ADMINISTRATOR account controls both the domain DNS records, and all USER accounts usernames and passwords. In turn, this ADMINISTRATOR account has access to all USER accounts and their other data. In other words, someone with Evil behaviors could hack or abuse the ADMINISTRATOR account, then access all USER accounts data. I do appreciated [Mailbox.Org](http://Mailbox.Org) team efforts to improve their security for Business accounts. While at the same time, in comparison to other Business email hosting suppliers, for the past 6 years, [Mailbox.Org](http://Mailbox.Org) Business services are still VERY WEAK security“ [https://userforum-en.mailbox.org/topic/lets-talk-about-2fa-on-this-website-again](https://userforum-en.mailbox.org/topic/lets-talk-about-2fa-on-this-website-again) 7. All of those security issues while being behind almost all other competitors regarding helpful Features: no App, no Push notification, no Spam Log, no detailed privacy or security dashboard, no notifcation when having a new login etc, no yubikey support, no dark mode, no recovery codes for 2FA, etc. 8. Absolutely no transparency: they dont offer any roadmap with upcoming feature and never state (not even roughly) when a feature will come or when a problem be fixed. Just take a look at the mailbox userforum. 9. Still providers that completely reject mailbox emails (e.g. twitch, soundcloud) 10. No anti spoofing for Custom domains despite the topic being open since over 9 years. 11. Extremely slow developing time e.g. previous point or even the 2FA that took until 2025. All other competitors had this for YEARS. 12. Horrendous performance: post from the userforum, open since 4 weeks. [https://userforum.mailbox.org/topic/1-mailbox-performance-der-web-anwendung](https://userforum.mailbox.org/topic/12476-mailbox-performance-der-web-anwendung) 13. Overall attitude issue: the CEO gaslit users that critized the absolute unusable previous implementation of 2FA. Support often dismisses fair critique points and comes of as arrogant (lots of reports about this, I can add some sources if needed.) And the list would go on but this is enough to outline the current state of mailbox, why its disadvantages far outweigh its few advantages and why this provider should not be recommended anymore. --- ## Post 90 by @lyricism — 2025-12-08T23:56:14Z > [@tibetfuchs](#): > > Yes you are right, they have the option to use a custom domain and they offer IMAP and other standards. Those are fair advantages. But those do not make them stand out since e.g. Fastmail offers them as well Does Fastmail offer automatic PGP encryption with bring-you-own keys? That’s the benefit I am referencing, not **just** IMAP, and I never referenced custom domains. > [@tibetfuchs](#): > > Enabling a password reset via IMAP that fully resets strong passwords AND 2FA. Not by Mistake but instead with full intention and also only giving the option to deactivate this feature after many angry users complained. This vulnerability is still enabled by default! I’m sorry but IMAP app passwords by design are a 2FA bypass. This doesn’t seem that insane of a default and certainly not a vulnerability. If someone has access to an app password they already have access to all your emails. Sure they get a little more by resetting 2FA, I would personally disable it, and it is a less secure configuration, but it’s not a vulnerability. > [@tibetfuchs](#): > > - Emails from catch-all accounts belonging to other mailboxes of the same domain were visible in other users’ inboxes When? Demonstrate this. > [@tibetfuchs](#): > > Having a debuglog publicy available that exposed user sessions Again, when? > [@tibetfuchs](#): > > Offering to store private key on mailbox servers Private key for what? In plain text or encrypted with passphrase? What does this mean? > [@tibetfuchs](#): > > - Even after the 2FA-Beta AND after configuring the Application Passwords the main password was still valid to use for applications OK? I would be surprised if they by default made it so you couldn’t log into IMAP with your main password just because you used an app password elsewhere. > [@tibetfuchs](#): > > In summary, as of today December 8th, 2025, the challenge with [Mailbox.Org](http://Mailbox.Org) Business email services Let me stop you there, Privacy Guides doesn’t make recommendations for business use last I checked. > [@tibetfuchs](#): > > All of those security issues while being behind almost all other competitors regarding helpful Features You’re getting off track, this was supposed to be a list of their countless security and privacy mistakes, remember? > [@tibetfuchs](#): > > Absolutely no transparency: they dont offer any roadmap with upcoming feature That is not a security or privacy issue > [@tibetfuchs](#): > > - Still providers that completely reject mailbox emails (e.g. twitch, soundcloud) That is not mailbox’s fault in any way, and usually this is a blanket ban on uncommon email providers, I doubt they specifically banned mailbox, they probably have an allow list. > [@tibetfuchs](#): > > No anti spoofing for Custom domains despite the topic being open since over 9 years. This is proven false by testing on this very forum. Mailbox will reject your use of another users’ custom domain. > [@tibetfuchs](#): > > Extremely slow developing time e.g. previous point or even the 2FA that took until 2025. Again, this is not a security of privacy issue > [@tibetfuchs](#): > > Horrendous performance Not a security or privacy issue…. > [@tibetfuchs](#): > > Overall attitude issue: the CEO gaslit users that critized the absolute unusable previous implementation of 2FA. Support often dismisses fair critique points and comes of as arrogant I don’t think the privacy community can afford to disregard every product with an arrogant lead developer, even if it’s not ideal. --- ## Post 91 by @tibetfuchs — 2025-12-09T07:19:42Z > I’m sorry but IMAP app passwords by design are a 2FA bypass. This doesn’t seem that insane of a default and certainly not a vulnerability. If someone has access to an app password they already have access to all your emails. Sure they get a little more by resetting 2FA, I would personally disable it, and it is a less secure configuration, but it’s not a vulnerability. It definitely is a vulnerability. A IMAP app password should NEVER be able to reset the whole authentication chain and gain complete access. By definition it is ONLY there to read E-Mails, not to write e-mails and certainly not to bypass all authentication measures, lock the user out and gain complete control over an account. And I definitely see a big difference between snooping in my mailbox and gaining complete access and locking me out. > When? Demonstrate this. > **[E-Mails fremder Domain-User im Postfach](https://userforum.mailbox.org/topic/10721-e-mails-fremder-domain-user-im-postfach)** > > Seit ca. 17 Uhr CEST kommen auf meinem Account mit Catch-all für domain.tld E-Mails für fremde mailbox.org-User an, die einen alias@domain.tld registriert > Again, when? > **[Reddit - The heart of the internet](https://www.reddit.com/r/de/comments/7ww496/comment/du48cto/)** > Private key for what? In plain text or encrypted with passphrase? What does this mean? Your pgpkey [Reddit - The heart of the internet](https://www.reddit.com/r/de/comments/7ww496/comment/du48cto/) > OK? I would be surprised if they by default made it so you couldn’t log into IMAP with your main password just because you used an app password elsewhere. It defeats the entire purpose of having app passwords which is isolation. > Let me stop you there, Privacy Guides doesn’t make recommendations for business use last I checked. Agree, but nevertheless, this point again shows that mailbox does not understand security. This is not a problem regarding the specific problem for business users, it is a problem about mailboxes underlying understanding about such topics. They again and again show such major problems, why should you be able to trust them in other topics.. > You’re getting off track, this was supposed to be a list of their countless security and privacy mistakes, remember? > That is not a security or privacy issue > Again, this is not a security of privacy issue > Not a security or privacy issue…. You should not ONLY consider security and privacy without also considering features that make a huge impact on how you can use the service day-to-day. **It comes down to this:** If privacy guides dismisses the proposal to remove mailbox then there is nothing I can do about it and I will stop populating this thread. **But I really don’t understand this at all:** How can anyone read this thread with all its arguments and sources that prove that mailbox in its current state is a mess, that it had multiple vulnerabilities that showed they don’t understand security, that it lacks so many features and still say “_Yep, this is the service I trust as the central access point to almost all of my online accounts and the central way of my online communication_“ --- ## Post 92 by @lyricism — 2025-12-09T14:19:42Z > [@tibetfuchs](#): > > It definitely is a vulnerability Objectively, no, it is not. > [@tibetfuchs](#): > > By definition it is ONLY there to read E-Mails Uh, no? I know for shortness we’ve been calling them IMAP app passwords but they’re obviously also used for SMTP to send from the same email client, also you are obviously intended to be able to use them to organize mail. You have a fundamental misunderstanding if you think app passwords anywhere have ever been exclusively read-only. > [@tibetfuchs](#): > > Your pgpkey They don’t store you PGP key in plain text on their servers. You are lying. I don’t read German but even if I take you at your word that your link says exactly what you claim it does, it is almost a decade old and predates Privacy Guides’ very existence and is clearly no longer relevant. > [@tibetfuchs](#): > > It defeats the entire purpose of having app passwords which is isolation. No? You can still use isolated app passwords, obviously. Having the option to continue using your normal password to gain access to your email in the event you are not willing or able to generate a new app password doesn’t hurt your use of app passwords elsewhere. > [@tibetfuchs](#): > > You should not ONLY consider security and privacy without also considering features that make a huge impact on how you can use the service day-to-day. Why? Everyone has preferences, if the service works and otherwise meets the criteria I don’t see why it should be removed because someone wants a feature it doesn’t have. Not everyone needs or wants those features. > [@tibetfuchs](#): > > How can anyone read this thread with all its arguments and sources that prove that mailbox in its current state is a mess, that it had multiple vulnerabilities that showed they don’t understand security, that it lacks so many features and still say “_Yep, this is the service I trust as the central access point to almost all of my online accounts and the central way of my online communication_“ Probably because they are not you and have a different threat model where any concerns you raised are not an issue to them. Shockingly, people have different requirements of an email service, and mailbox still meets the criteria to be recommended by PG AFAIK so I am at a loss for why it would be removed because a few decided they don’t like it. Here are the concerns you raised and hypothetical cases where it wouldn’t matter to someone, for explanatory purposes. 1. Inbound spam not flagged because of not strictly following a DMARC policy → You can just add your own sieve filter to move emails to junk when they don’t pass DKIM or SPF. This is probably the best thing to do even if DMARC was followed strictly as it doesn’t really help the issue of spoofed emails being received because you have no control over the DMARC policy of the spoofed sender and they might have it set to p=none, in which case you’d receive the email anyway if DMARC is being followed strictly. 2. Lock out via password reset from app password → If you only use custom domains and have an email backup system setup you don’t really need to care about losing access to your account because you can just point your domains to a new one. The only things to be concerned about are things that would already be possible with just the app password itself (reading emails, impersonation). If you don’t want to risk being locked out anyway, turn this off. Also, how is someone getting your app password before your normal password anyway? It’s also interesting your concern is getting locked out of your account, considering that’s what this feature prevents. This seems like a reasonable default for most people who would probably be more likely to be locked out by losing access to their second factor or primary password than by having an app password compromised. I would turn it off, personally, but I understand the trade offs they are contending with and why they ended up where they did. I don’t see any other outstanding issues. I’m not really a huge fan of mailbox, I really only like that they can do automatic encryption with a bring your own keys setup, but I think the arguments for removing it are really arbitrary and don’t seem to be for lack of meeting a minimum requirement or anything. My arguments in their defense are more about the precedent we set if we remove it for the reasons given, which again seem pretty arbitrary, even if I sympathize to some extent with default settings they have being undesirable to me personally (which I do, I just also understand why they set them that way and I don’t think their decision is entirely unreasonable). If we want go change the minimum requirements, that seems more reasonable, but I don’t know that I would agree with what they would need to be to remove mailbox and I also still don’t love the idea of changing minimum requirements specifically so that a recommended service no longer meets them. Still, it would make more sense than removing them without those changes, IMO. --- ## Post 93 by @tibetfuchs — 2025-12-09T14:55:02Z > [@lyricism](#): > > Objectively, no, it is not. It is. 2FA is used to secure access using two factors. In this case knowledge and possession. Having only one of them is not sufficient to gain access. Mailboxes IMAP reset bypasses this by allowing to gain access only with knowledge. This is a flaw that could be exploited by attacker so a vulnerability. > Uh, no? I know for shortness we’ve been calling them IMAP app passwords but they’re obviously also used for SMTP to send from the same email client, also you are obviously intended to be able to use them to organize mail. You have a fundamental misunderstanding if you think app passwords anywhere have ever been exclusively read-only. Yes I’ll give you that point. Technically speaking sending is done via SMTP and not IMAP but since in most cases its the same application password, you are correct that my sentence “ONLY there to read E-mails” is wrong. So let me correct myself by saying “By definition it is not there to change account settings that allow gaining full control through bypassing enabled 2FA”. > [@lyricism](#): > > They don’t store you PGP key in plain text on their servers. You are lying. I don’t read German but even if I take you at your word that your link says exactly what you claim it does, it is almost a decade old and predates Privacy Guides’ very existence and is clearly no longer relevant. it is relevant because it adds to the argument that they are careless regarding security. And BTW: I did not lie. You asked me “What are the ‘dozens’ of mistakes Mailbox has made?” and I answered with a list of mistakes the made. This point above may be old, but its still one of the mistakes mailbox has made. > [@lyricism](#): > > Shockingly, people have different requirements of an email service, and mailbox still meets the criteria to be recommended by PG AFAIK so I am at a loss for why it would be removed because a few decided they don’t like it. crazy to say its because some don’t like them. Like there isn’t a whole list of objective and proven arguments and its all just personal opinion… And again: if privacyguides keeps recommending the service I can deal with it. I have nothing to gain by having mailbox removed. I just give my opinion and provide sources, because a recommendation should not be made/removed by personal opinions but based on facts. And IMHO the disadvantages of the service are bigger than its advantages. --- ## Post 94 by @lyricism — 2025-12-09T15:17:51Z Well, I disagree with a lot of what you said even in this post but in the interest of not spamming the thread and because it seems we’re both in the position where we disagree on some principles but don’t actually care too much about the outcome, I will leave it be so others can give their thoughts. Happy to discuss more in DMs and summarize here after if you want to just out of interest in the conversation, though. --- ## Post 95 by @Cyber-Typhoon — 2025-12-09T15:44:06Z It was a nice ride. Very compelling arguments and civilized (to a certain degree) discussion between two great thinkers and their opinions about a single email provider impression when both are, to some extension, detached from deep feelings about the tool in question. I’m honest impressed and appreciate this engagement. Thanks for your inputs. --- ## Post 96 by @tibetfuchs — 2025-12-15T10:28:19Z Its in German and rather long but worth a read: > **[Account seit über einer Woche defekt Keine Kommunikation vom Support](https://userforum.mailbox.org/topic/12996-account-seit-uber-einer-woche-defekt-keine-kommunikation-vom-support)** > > Hallo zusammen, ich möchte hier einmal meine aktuelle Support-Erfahrung schildern, da ich inzwischen ziemlich frustriert bin und nicht mehr weiß, wie ich In a nutshell: A backend issue left a paid mailbox account unusable for over a week. Support reacted too slowly, communicated poorly, and ultimately caused permanent data loss due to expired backups. Attempts to resolve the issue created further errors and erased support history. --- ## Post 97 by @Wings — 2026-01-07T13:27:39Z Add this to the growing list of concerns: [Mailbox users, consider this your canary in the coal mine](https://discuss.privacyguides.net/t/mailbox-users-consider-this-your-canary-in-the-coal-mine/34472) --- ## Post 98 by @tibetfuchs — 2026-01-07T17:13:31Z When do we get more feedback from the privacy guides team? The list of reasons to remove the service gets longer and longer. Its just a matter of time (and in the last months it happened quite a lot) until mailbox shows yet again that they have so many problems behind the curtain. --- ## Post 99 by @tibetfuchs — 2026-01-15T12:58:31Z No Rotation of DKIM Keys yet (every 6 months would be recommended) No option to whitelist No application passwords for xmpp --- ## Post 100 by @plus-subzero — 2026-01-16T23:37:43Z > [@tibetfuchs](#): > > No option to whitelist And [not coming](https://userforum.mailbox.org/topic/7196-keine-whitelist#comment-74211). --- ## Post 101 by @AnotherBloodyUsername — 2026-02-02T18:24:31Z According to one user, ``` It looks like this issue has been fixed now (the problem discussed here: https://news.ycombinator.com/item?id=30224906). I was not able to send from my own domain on an account that is not part of a family or does not have an assigned email address in that domain. SPF, DKIM, and DMARC can help, but the receiving server also needs to be configured correctly. Most servers will just mark emails as spam, but some (or if you self-host one) can reject spoofed emails. For example, DMARC tells the recipient server what to do with emails when SPF or DKIM fail validation. (The test at dmarcian.com can guide you to set it to “reject” if you want full protection.) But this is only half the picture. For instance, Stalwart allows relaxed, strict, or disabled DMARC policies. A relaxed policy will only enforce rules if an email fails or passes, otherwise it just marks it as spam. A strict policy will reject anything that doesn’t pass verification. So yes, you can tell the recipient server what to do with emails from your domain, but ultimately it depends on how that server is configured. ``` This is on Mailboxes own forum [Anti-spoofing for Custom Domains (SPF, DKIM & DMARC) | mailbox user forum](https://userforum-en.mailbox.org/topic/anti-spoofing-for-custom-domains-spf-dkim-dmarc#comment-11566), but this is only just one person. Not sure if Mailbox have quietly fixed the issue and if others may be able to confirm. In which case this proposal should be marked as rejected. --- ## Post 102 by @joygrit — 2026-02-03T10:18:24Z As far as I know they’re working on it - and also DKIM issues.