The Drawbacks List
You have read all about the benefits and freedoms hundreds of thousands of users get via Migadu. Now you are trying to figure out where is the catch.
We do not want you to use our services if they do not fit your requirements. It’s not a sales trick, but a transparency policy we would appreciate to see around ourselves.
Here is everything you need to know before you find out as a surprise.
Delayed configuration
Most of the email changes you make through our UI will take about 3 minutes to take effect. Even if you change mailbox password, it will be delayed. Surprisingly, it has never been a problem for any of our users so far.
This is an architectural limitation and we are working on lifting it.
Free TLDs are banned
We refuse hosting email for free domain names as they are by majority involved in fraud, spamming and phishing. If you want a reliable email, and we believe that is why you are here, it is pointless to get a domain name of poor reputation, penalized by each email provider on the planet.
No mailbox 2FA (yet!)
This is a common surprise.
IMAP protocol as well email clients do not support second factor authentication for the mailboxes. Even if they did, IMAP connections are made way too often which would make authentication unusable. Imagine needing to enter your TOTP token every few minutes.
We could enable 2FA on the webmail, but IMAP/POP/SMTP accesses remain unprotected which beats the purpose. We are working on solution here which will allow sand-boxing a username/password pair to a webmail use only.
We do offer so called App-specific passwords via mailbox identities though. These are commonly touted by email providers as 2FA. They are not.
Not encrypted
Email as we know it and encryption are incompatible. If someone is telling you otherwise, they are not to be trusted.
Email is built on top of plain text protocols and messages flow in plain text. If you encrypt, you cannot scan for spam or viruses, index messages for searching or recover messages when a password gets lost. Not to mention the usability issues of changing passwords / encryption keys.
This cannot be fixed, at least not any time soon without breaking the protocols on which email relies.
If we were to roll out encryption at rest, we would have to keep the encryption keys ourselves. That means we would be encrypting and decrypting messages on the fly using a key which is available on the same storage where your data is. That is not encryption but rather encoding, and we do not see the great benefit of it.
You may be thinking now, what if someone obtained the hard drives from the servers? Good one. We split data between disks and ensure individual disks are not sufficient to recover data. Our servers run in secure data centers that are internationally certified for their security and data privacy processes. In short, a Hollywood-like action would be needed to get physical access to the servers, and the data-center administrators do not just toss out faulty disks into the nearest garbage bin.
We know some email providers automatically encrypt messages as they arrive using users' public keys. That sounds exciting but in practice it does not really prevent the provider from accessing the mails. It only makes email less usable, less standard and more tied to that provider. What you gain in security you lose in portability and usability, and what we do not want for ourselves, we won’t be offering others either.
If you are interested in real encryption and absolute security for your Santa letters, please use end-to-end encryption tools such as GPG with your correspondents or pull locally all your messages periodically (e.g. via POP3) and encrypt them yourself on your local device.
Human email use only
You could try using Migadu to send transactional as well bulk mails, but you will quickly find out it will not work as expected. There are rate limits per mailbox, domain as well account which, if crossed, will block your mailbox, domain or even full account.
If we find out this limit crossing was intentional, you will be banned from using our services permanently and placed on a blacklist.
That said, an occasional transactional mail is completely fine such as those from contact forms. If you arrive to a point where you need to send a dozen messages per second, you will want another service anyway, as your sending requests will start being rejected.
The same rule applies for incoming messages. If you are blasting automated mails to your mailboxes, they will be rate-limited after which they might even be rejected.
Daily limits apply
Our subscription plans are divided by daily capacity requirements. We really do not care how many addresses you have but rather how you use them. As such, we limit daily traffic on the account.
Depending on how many users you have, you will need to select a plan. If you have hundreds of email addresses which are seldom used, even the lowest of our plans might suffice.
If you try blasting mails in or out, your limit will be quickly gone and you will not be able to receive and/or send more. This will also trigged a bunch of alerts on our end.
In most normal situations, you will be warned if you are reaching your limits so you have time to analyze the traffic and possibly upgrade your plan. This allows you to pay only what you really use.
If no upgrade is made, incoming messages will be deferred until the following day, and sending messages will be refused.
No bulk messaging
You cannot use Migadu to send mails fast. These attempts are monitored and will be quickly sanctioned.
We do not approve of or accept bulk mailing, even if it is not spam. Please use dedicated services for that.
Basic calendar
We make the basic CalDAV and CarDAV services available, but they are not our focus. We continue developing them but please do not expect we will ever compete with dedicated calendar services.
Spam filters are not perfect
That should not come as a surprise as there are no perfect spam filters.
While we do process a significant email traffic, we base our spam filtering on open source tools which we support and contribute to. We do not use proprietary data of blacklists for filtering.
For most of our users the spam filters work great, but each mailbox receives a unique messages stream. What works for others may not work well for you.
We offer all the tools for you to adjust your domain as well mailbox spam filtering, so you might need to flip a few switches. Unlike with BigCos, we give the spam filter control to you.
Messages might go to Junk
We give no guarantees your messages will reach recipient’s inbox. No one can, as message processing at the recipient’s side is outside of the sender’s control.
We care deeply about our reputation. We monitor and keep our IPs clean. However, the IPs may get on blacklists from time to time due to an occasional bad apple using our service. We are quick to react, both in banning users and cleaning or rotating our IPs.
Please understand though that blacklists are not sender’s problem but rather a recipient’s problem. A blacklist entry is only a signal, one of many in spam classification. Email providers which blindly rely on blacklists are just inconsiderate of their users and email interoperability. Ham is ham, even if sent from an IP address which is listed.
Running a blacklist is not even close to the task of running an email service. To add to the insult, some blacklist require a removal fee, making them really - blackmailers.
We refuse to use blacklists and encourage others to consider dropping the same.
Sending might get rejected
Sometimes your outgoing messages may get rejected by our spam filter. We have yet to see a false positive here. If it happens, it most likely means your DNS configuration is incorrect or your message is spammy.
Not cheapest
You might be out looking for cheap email hosting. We may fit your bill but there certainly are other possibilities which cost less. If all you need is one or two email addresses, you might want to stick to the BigCo providers.
We do not offer email at our domains
Our whole service was built around the premise of giving email liberties back to the users, not taking them away. We refuse to fence users and lock them in.
Domains are so cheap nowadays. Why jail yourself voluntarily? Email was always meant to be portable and independent.
We do not chase the cool factor
Unicorns, fairies and investors. None here. We do not have cash to burn. We do not talk about “scaling” but rather serving better. We are careful about the features we bring in or take out and stay very loyal to our users.
In Switzerland, but servers are not
This may come as a surprise, but we do not host our servers in Switzerland. Current data centers are located in France. We may in the near future add Swiss data centers too but this is not our priority.
We find EU privacy laws much more elaborate and restrictive than the Swiss ones. Switzerland used to be famous for banking secrecy, but that has nothing to do with digital data.
Only English interface
While we speak 8 languages, our interface for the moment remains in English. We plan on adding additional languages but it is not our highest priority.
No instant responses
Not every issue requires immediate attention. During office hours (CEST time), we are quite responsive. After hours we monitor the tickets of Standard and Maxi plan accounts, but respond and act only if the matter is urgent and cannot wait, as it rarely is.
No telephone support
When you submit a ticket to us, you will get an answer from a professional who is involved in building and maintaining Migadu. Most of the time issues we see require data from users, followed by log analysis and triage by us. These flows are by nature asynchronous. Phone calls do not fit.
No SLAs by default
In case of a significant outage, we might compensate users to what is fair without any agreement. Email is asynchronous and composed of many services that most of the time outages and maintenances are unnoticeable. Nevertheless, we cannot give service quality guarantees and do not offer service level agreements (SLA) in the default offer.
If you are interested in an SLA, we can offer you our enterprise pricing, starting from $5.000 monthly. Contact us for more information.
Downtimes
All email providers have occasional downtimes and outages, even the largest ones, without exceptions.
There will never be a finished on-line service. We work continuously at making our service better. That implies that bugs will happen and service may be affected at times.
We may be also be a subject of DDoS or spam attacks. Email providers are a common targets. While we do have DDoS measures in place, some delivery delays may happen.
Our data centers may also have connectivity issues and our hardware may manifest faults.
If you cannot accept a few hours of email downtime under any circumstances, Migadu is probably not for you.
That said, email was built to be very fault tolerant. In a case of a total outage where we are unable to accept messages for your domain(s), incoming messages will not get lost. They will be delayed until the service recovers. The senders’ systems will simply keep retrying periodically for up to 48 hours until the message finally goes through.
While periodical outages in incoming streams are not noticeable, accessing messages over webmail, IMAP or POP3, as well sending via SMTP are. We have redundant services in place that ensure fail overs, or in worst case, a short downtime.
No feature parity
We really do not care what service X offers and will not try to match them unless we believe it is a genuinely good thing.
We are however always interested in hearing suggestions from users. This is how we came so far. Roughly a half of our features were at some point user suggestions.
We did it our way
We are very opinionated and will refuse to follow trends or “best practices” if they do not make sense to us. This refers to business as well email policies.