According to a post in its official forum, Mailbox.org does not properly implement anti-spoofing measures (SPF/DKIM/DMARC) for custom domains, meaning anyone with a Mailbox.org account can send mail from another users email address.
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 in 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 account can send mail with domain configured on mailbox.org
E.G. Your account : toto@mailbox.org you can send an email as bidule@adomainname.com if a adomainname.com is configure by another mailbox.org user on 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.
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.ā
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.
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 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.
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.
According to the mxtoolbox dmarc lookup tool, they do implement DMARC for their mailservers. This article 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.
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 domain has p=reject set so that should mean it works for non-custom domains.
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.
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.
This is the test in which 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 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 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 came at last.
Would love to, but not public. Concerned about the possibility of a vulnerability in the custom domain. Donāt forget that we discuss
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.