Free email accounts, in one screen
Every comparison of email accounts ranks them on storage. Storage is the number most likely to change and least likely to matter. The question that decides whether you can actually live in an account is whether you can get your mail out of it.
| Works with any mail app | Gmail, Outlook.com, Yahoo, iCloud, AOL, Zoho, GMX, Yandex, Mail.ru, Fastmail |
| Needs a paid desktop bridge | Proton Mail |
| No IMAP, POP3 or SMTP at all | Tuta Mail |
| Almost universal friction | An app password, generated in the webmail, instead of your login password |
| The question nobody asks first | Can you leave, and take fifteen years of mail with you |
Most guides to email accounts line up the same providers and compare free storage. That number is real, and it is also the least useful axis available: it changes without notice, it is generous almost everywhere, and nobody has ever regretted a choice of mailbox because of it.
What people regret is discovering, three years in, that the account they picked will not connect to the mail app they want to use, or that exporting a decade of archives means clicking through a web interface. So this comparison ranks free email accounts on protocol access: whether the provider lets a standard client speak to your mailbox, and what it costs you to make that happen.
Why protocol access is the axis that matters
Three protocols do the work. IMAP and POP3 read mail from a server, SMTP sends it, and together they are what lets any mail application on any device open your mailbox. A provider that supports all three is a provider you can leave. Our reference on how the three protocols divide the work, with their ports and TLS requirements covers the mechanics.
The practical consequences are concrete. With protocol access you can read your mail in Thunderbird, Apple Mail or classic Outlook rather than only in a browser tab. You can keep several accounts in one application. You can run a local backup. And when you want to move to another provider, the migration is a supported operation rather than a manual export.
Without it, the account is only as portable as its vendor decides to make it. That is a defensible trade in exchange for real end-to-end encryption, as two providers below demonstrate. It is not a trade you want to make by accident.
The accounts, by what they let a mail client do
Every entry links to its own settings page, where the hostnames, ports and authentication requirements are listed in full. This guide covers the consumer accounts most people actually choose between; the full inventory, including regional and legacy providers, is in the directory of email providers across 30+ countries.
The mainstream accounts
The independents
The two encrypted accounts, which behave differently
These are the entries that make the protocol axis worth using, because on a storage table they look like ordinary competitors and in practice they are a different category of product.
Tuta Mail: no IMAP, no POP3, no SMTP
Tuta does not support the standard protocols on any of its domains. There is no bridge application and no paid tier that unlocks external clients: the supported access methods are Tuta’s own apps and its webmail. This follows from its encryption model rather than being an omission, and it is the single most important fact to know before adopting it. The full position is in the Tuta Mail settings page.
Proton Mail: protocols only through a paid bridge
Proton addresses do not accept IMAP, POP3 or SMTP connections directly, because Proton’s servers hold ciphertext and a client authenticating normally would receive unreadable messages. The workaround is Proton Mail Bridge, a desktop application that runs a local IMAP and SMTP server and decrypts in between. The free plan does not include it, so on a free Proton account there is no third-party client access at all. See the Proton Mail settings and the Bridge requirement.
Neither of these is a criticism. Both are honest consequences of end-to-end encryption, and a provider that could hand your mail to any client in plain text would not be offering the guarantee they advertise. The mistake is choosing one of them from a storage comparison and finding out afterwards.
The app password, the friction almost everyone shares
Nearly every provider in this list requires an app password rather than your account password when a third-party client connects. It is generated in the provider’s web interface, it is usually shown once, and it is tied to that one client.
The reason is that account passwords now sit behind two-factor authentication, and a mail client speaking plain IMAP has no way to complete a second factor. The app password is the escape hatch: a long random credential that grants mail access only, and that can be revoked on its own if a device is lost.
If a client refuses to connect
The overwhelmingly common cause is your normal password typed where an app password is expected, and the error rarely says so. Generate one in the webmail, paste it into the client, and check the hostname and port against the provider’s own settings page before assuming anything is broken.
Free account or business hosting
A free account gives you an address at someone else’s domain. That is fine for personal mail and it is a liability for anything commercial: you cannot take the address with you, you cannot create addresses for colleagues, and a message from a free consumer domain reads differently to a recipient than one from your own.
The moment you want mail at a domain you own, the comparison changes completely, because the axis becomes what each plan permits rather than what it stores. That comparison is a separate page: what each business email hosting plan actually lets you do, covering the same providers on their paid tiers plus the protocol restrictions that arrive with them.
There is also a middle case worth naming. Several providers here let a paid tier attach your own domain to what is otherwise the same mailbox, which is often cheaper than a full business plan and enough for one person.
Aliases, forwarding, and the address you actually hand out
An account and an address are not the same thing, and the providers here differ more on that point than on anything in a feature table. Most of them let one mailbox hold several addresses, either as aliases that deliver into the same inbox or as extra domains attached to the account. Mail.ru, for instance, attaches several domain aliases to a single account, and GMX and Yandex both operate country variants that behave as separate hostnames.
This matters for a practical reason. An alias you can create and destroy lets you give a different address to each service you sign up for, which turns an unwanted sender into a one line fix rather than a filtering problem. It also means the address you publish never has to be the address you log in with, and separating the two removes a credential from public view.
Forwarding is the other half. An account that can forward to another account lets you migrate gradually rather than in one evening, and it is what makes an old address survivable after you have moved on.
Account recovery, the feature nobody evaluates until it is too late
Every account here is protected by two-factor authentication, and that is the right default. The consequence people meet later is that a mailbox is usually the recovery route for every other account they own, which makes it the single point of failure in a personal security setup.
Two questions are worth answering before you commit. What happens if you lose the second factor, and does the provider have a human recovery path or only an automated one. And on the encrypted providers specifically, what happens to the contents if you lose the password: with zero-access encryption the honest answer is often that the mail is unrecoverable, because the provider genuinely cannot read it. That is the guarantee working as designed, and it is worth understanding before you rely on it.
Choosing, in the order that matters
One habit worth keeping regardless of the choice: use a real account for anything you need to keep, and something else for signup forms you do not trust. The category of disposable and temporary addresses, and how services detect them exists for that, with the caveat that many sites now reject them.
If you are choosing an application rather than an account, the two decisions are separate, and the directory of desktop, web and mobile mail clients covers that side.
Frequently asked questions
What is the best free email account?
There is no single answer, but there is a useful default: Gmail or Outlook.com if you want full access from any mail application, Proton or Tuta if you want end-to-end encryption and accept the client restrictions that come with it. Decide whether you need a desktop mail app first, because that question eliminates more options than any other and it is the one people answer last.
What are the top 5 email accounts?
By usage, Gmail, Outlook.com and Hotmail, Yahoo Mail, iCloud Mail and AOL Mail. All five support IMAP, POP3 or both plus SMTP, so all five work with a standard mail client, and all five require an app password to do it. The interesting differences between them are not on that list: they are in what happens when you want to leave.
How do I find email accounts?
If you are looking for accounts you already own, start from the recovery addresses and phone numbers on the accounts you can still reach, then search your main mailbox for signup confirmations from other providers. If you are looking for a new account, the providers in this guide all offer direct signup. If you are trying to find somebody else’s address, that is a different problem and this is not the page for it.
What is replacing Gmail?
Nothing is replacing it at scale. The migration that does happen is driven by privacy rather than features, mostly toward Proton, Tuta and Fastmail. Before moving, check the protocol column: Tuta supports no standard mail protocols at all, and Proton requires a paid desktop bridge, so both change how you read mail rather than just where it lives.
Which email account providers work with Outlook or Apple Mail?
Gmail, Outlook.com, Yahoo, iCloud, AOL, Zoho, GMX, Yandex, Mail.ru and Fastmail all expose IMAP or POP3 and SMTP, so any standard client can connect. Proton needs its paid Bridge application running locally, and Tuta cannot connect to an external client at all. In every case where it works, expect to generate an app password rather than using your login password.
What is the difference between an email account and an email address?
The account is the mailbox and the credentials that open it. The address is a label that routes mail into it. One account can hold several addresses, which is how aliases work, and one address can be forwarded into an account you log into somewhere else entirely. It matters when you migrate: you are moving the account, and whether the address comes with you depends on who owns the domain it sits at.
Are free email accounts good enough for business use?
For a sole trader who only receives mail, sometimes. For anything else, no, and the reason is ownership rather than quality: an address at someone else’s domain cannot follow you, cannot be issued to a colleague, and cannot be recovered by your organisation if you lose the account. Mail at a domain you control solves all three, and the plans that offer it compare on quite different terms.
How do I move an email account to another provider?
The supported route is IMAP to IMAP: connect both mailboxes in one client, or use the destination provider’s import tool, and copy the folders across. That works between any two providers on this page that expose IMAP. Where a provider does not, migration falls back to whatever export it offers. Keep the old account alive and forwarding for several months afterwards, because the addresses you forgot are the ones that surface later.
About this guide
This comparison ranks consumer email accounts on protocol access rather than on storage, because storage figures change frequently and are rarely the constraint people meet in practice. Every protocol claim links to the individual settings page for that provider, where the hostnames, ports and authentication requirements are documented in full. No pricing or storage figures are quoted, because they could not be sourced reliably at the time of writing. Reviewed by the SMTPedia editorial team.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
