As a fastmail user I'm glad there was no announcement. Every time a company starts telling me about some bright future, this usually means my user experience is about to sink.

That was how I felt. "The Future of Email", from Fastmail - I immediately assumed some big announcement.

It's basically "you need to pass DMARC now" which has been true for 2 years.

It also goes into how authentication helps stop spoofed domains which yes, is true. But in my opinion the biggest problem isn't spoofed domains at all.

Attackers will figure out how to make your payment platform (PayPal, Stripe, etc) send out emails. They'll figure out what pieces of info make it into the generated emails, so they'll do things like set their company name to "there's a problem call this phone number." So next thing you know you're getting an email from PayPal that sounds urgent because they'll put that company name in the subject or body of the email.

These emails will be legit, from-the-actual-company, passes-all-authentication emails. DMARC can't catch that, and that's what I've been observing attackers do. They'll find a ticketing system or payment processor and get them to generate "authentic" emails.

I was sincerely hoping that Fastmail had something to deal with that problem.

Because it's just inbound marketing. Write some random vaguely interesting blog article, post it everywhere, then watch as thousands of people see your brand name for the first time, connect it with being helpful. Maybe even see a search engine boost for your product.

The future of email is… the present of email!

Agree. I was waiting for the other foot to drop and then..."email's not going away."

Genuinely curious. Why is it posted and being upvoted here?

Yeah I had the same reaction. From the title I was expecting to find out what the "future of email" is. I'm still waiting.

"A crummy ad??"

Those "message centers" aren't just about security, they're also about compliance. For example, insurance companies need to be HIPAA-compliant which requires that they can only send health-related info to other HIPAA-compliant systems, which means signing a BAA (a contract) with those other systems. There's no way to do that with email (your insurance company can't sign a contract with every potential email host in the world, and they don't even know where the email will ultimately end up after they send it) so practically speaking, they're not legally allowed to send any health info via email.

It's extremely difficult to accurately identify which emails have health info and which ones don't (even something like a person's name or IP address could count depending on the context) so they just default to sending everything through their message center. No amount of email security could change that.

To have secure email I think html /css should be dropped from email support and the inbox should work on an invite only basis. Basically you should pre-authorize the senders just like you add someone as friend on a social network.

I called my bank for some info recently. They can't email it to me, but they _can_ send it through postal mail. Should be arriving any time next week.

I'm sure there's a sum of compliance reasons why this is not allowed, but it doesn't make any sense at all.

Those secure messaging platforms make it damned near impossible to make a backup. I've seen medical clinics delete messages that would have bad for them in court.

As such, I tell anyone who sends me one to fuck off and send a real email.

My bank does a PUSH notification that is "Please log into the app to read an important message", which is usually just my monthly statement or whatever.

And then also sends an e-mail, which sometimes I confuse and think is ANOTHER message, and log in again....

It has a "Download this message as a PDF" button, which just takes you to a web-browser wrapper....

> I'm all for email being more secure, to the point that organizations (banks, governments, insurance companies) stop creating walled-email alternatives

This will literally never happen. Email doesn't support the features that those messaging platforms need to have, such as recalling messages.

The security layers are also only on the sender part, not on the receiver part, which banks care a lot more about.

I love hearing that I received a "secure message", with no further detail. Straight to trash -- I don't read "secure messages". My inbox is probably more secure.

The Fastmail desktop app is literally a wrapped version of their website but with the added feature of... get this... no back button (or equivalent shortcut).

My 30 years of muscle memory using webmail is made useless by this "app" because some web developer somewhere wants to cosplay as a desktop app developer now.

It's not an oversight either. It's an intentional choice to not have a go-back-to-previous-page keyboard shortcut. A customer support person said they would add it as a "feature request". Gee, thanks.

I'm using Fastmail for more than 9 years. Especially since they added offline support to their app, there's nothing left why I would even remotely consider leaving them.

What were the tradeoffs with Proton?

Preach. Exactly.

We will eventually be forced down this path though, be patient! Upfront key exchange in-person will be the only way left to prove comms are real. GPG is just one path but someone will come along and make it easy on organizational level.

> as long as the business model of the largest email vendors rely on us not having it

The model literally can't function if emails are encrypted. They have to be unencrypted for all the ML to run for the inbox to actually be useable.

None of the big providers want that. Otherwise Microsoft had more difficult to share the Outlook data for 1000 partners.

In 2026, pushing for encryption of emails is a sign that you care more about box-checking requirements rather than actual security practices. Encrypted email sounds good--it's encrypted, how can that be bad?--but when you actually work through various threats and see what encrypted email protects against, it's really not much compared to the status quo, and encrypted email also turns out to lose a lot of features.

Keep in mind that the baseline is that, when you send an email, it is encrypted from your computer to your email server, your email server to your recipients' email servers, and your recipients' email servers to their computers. The only people other than you and the recipients who can see it are the email servers involved in the middle, so the best you can get with encrypted emails is maybe cutting out some of the entities that have a critical role in the process (and which therefore can't entirely be cut out). In particular, encrypted email leaves all the email headers public, so it's not like the best case here is particularly private.

But encrypted email also breaks the ability to do any server-side processing of email, like server-side email filters (okay, not the hugest loss in the world). Or spam processing--no one's come up with a workable solution here, especially given the vast amount of spam that never hits an email folder (the things that get routed to your spam folder are the emails your spam filters aren't sure is spam). Users also expect the ability to log onto their email server's website and just read their email: such webmail is the dominant email client used, and even people like me who almost exclusively use email clients still end up using a webmail client from time-to-time. You can fix this by giving your email server your key... which puts them back on the list of people who can read your email again, oops, you've gained nothing over the status quo.

Worse still is the problem of key distribution. To send an email, you need to look up the recipients' keys... and the most practical approach to make that work at scale is probably to ask the mail server what its users' public keys are. The one entity that is guaranteed to be able to intercept literally every message to somebody, and thus is in prime position to offer its own key instead, strip the encryption, and re-encrypt it to the user without anybody else finding out. Alternative approaches like keyservers don't work: the PGP keyserver ecosystem collapsed several years ago when PGP encryption was of interest to fewer than a million users, far less scale than the billions of email users.

Encrypted email is a useless pipedream, and not because of the business models of email vendors, but because the architecture of email provides good-enough security today that makes improving on it very challenging without negating the supposed benefits of extra encryption.

The new email isn't email at all, it's something like Matrix, or Signal (if you don't mind the centralization). Excellent encryption with great UX.

My friends and I used to do this all the time in that same time period. It was all fun and games until one day I caught one of them spoofing a message from me to president@whitehouse.gov making vague threats. He seemed to think I overreacted when I dove under the desk and unplugged the machine.

I think there's several things going on at once in that space. This is just their vocalisation of it because it suits them.

The thing is Fastmail can't speak with absolute authority about email because Fastmail is not email. It's subordinate to it.

This was the post where I learned about SPF, DKIM, and DMARC which seems like a nice technical win. It isn't text encryption but it goes to show there is still room to improve on the basic email situation.

I didn't know what JMAP was but upon looking it up, I agree

How would you get someone's key?

I want to give my bank my public key (preferable at a branch), so that ANY comms coming from them I can prove it came from them as.

I would love for a proof of human work to exist, but how would you even do that? It would need to be monitoring the user activity in their email client, which isn't something that can be trusted by a server (and is pretty shady).

But that makes me think of Hashcash, that was developed to limit email spam via proof of work, but I don't think that has ever been used in practice: https://en.wikipedia.org/wiki/Hashcash (and of course wouldn't work for the proof of humanness you're talking about).

What about automated signup confirmation emails, just as one example?

Agreed. I had some vague hope that this article made it to the HN hope page because someone was saying what needs to be said: that the future of email should be protocols over platforms, as it was in the past. Mail servers and mail clients.

Same - I plugged it into ChatGPT to check if I'd missed something contentful. I hadn't really. Not news, more survey of things that matter a bit. If you know those things already then this is just fluff. Nothing about the future, more just here's some things I like.

Yeah, it's the same thing with self-hosting email. The technical side is documented and the tradeoffs are well known. It's the up front effort of migration, maintenance and mails landing in spam that gets people down and so on. Though once you get going it's supposed to become easier with time.

Also there's a spectrum from Gmail to Fastmail to AWS SES to Wireguard on a VPS that's tunneling to a server running at home. And when the people from both extremes of the spectrum interact they look at each other as if they're from other planets.

It's the same for Auth stuff I believe, almost a decade of generic advice like "don't roll your own auth" has lead some people to file it into a tidy corner of their mind labelled "DON'T TOUCH" so most people end up gawking and staring in awe when someone does so and lose all nuance along the way. To be clear I'm advocating for learning how stuff works and playing around with it (time permitting) instead of simply delegating it to the technical equivalent of Higher Powers in perpetuity.

> They're widely understood

I'll tell you right now, I've had multiple cases where I've had to quote parts of the RFCs to large companies because they were handling email authentication incorrectly.

They are wildly misunderstood. The moment I see "add this include: directive to your SPF record" in some marketing platform's integration documentation I know they're going to fuck something up.

To add-on, the really pro move is to not touch the client's SPF record at all. Use your own domain in the SMTP envelope and have SPF be valid for that. Just have the client establish DKIM records and use DKIM, and only DKIM, to pass DMARC.

If you insist on using the client domain in the envelope, make it a subdomain with MX records back to your infrastructure (so you can track bounces). That will pass relaxed alignment - or just use a subdomain in the from and now you're passing strict alignment as well.

Most companies have no idea how the envelope domain impacts bounces and frankly, doesn't care about tracking them.

A shockingly high number of companies have no idea of the concept of the envelope address.

I was going to say the same thing. I only saw two things that are sort of about the future and not the past:

- BIMI (I hadn't heard of that before) which seems like a very minor thing to be calling "the future of email"

- AI might be easier to trick that humans

On that second point, here's the exact text:

> A person reading a suspicious email might notice that the sender’s domain has an extra character, or that something about the request feels off. An AI assistant scanning your inbox for items that need action may not slow down to check those things.

That seems wrong (AI should be better at this than the average human), but let's assume that assertion is correct. It then says "authentication is the safeguard that should stop it before it ever reaches your mailbox". Except then, a few paragraphs down, it says "A scammer with a convincing look-alike domain and a properly configured DMARC record will still pass sender authentication checks." Ok, so authentication isn't a solution to the stated problem at all (it does solve a different problem). And unless I'm missing something, no solution is proposed. No statement is made about what the future actually looks like.

Like you said, what is the point of this article?

You can absolutely set up SPF, DKIM, and DMARC for yourself, it's really not that hard if your difficulty reference point is self hosting email. I did it like 10 years ago and I don't think it has changed.

Self hosting is hard (which is why I just use Fastmail now), but it's not because of that.

Sure, I do it, and many others. Some people say it's hard, but I think it's much easier than it used to be, technically. You have projects like https://stalw.art which make it quite easy. Single binary setup which covers all functionality you need. Setting up SPF, DKIM and DMARC is also easy. The only thing that remains is IP reputation, but even then, I haven't had major issues. People seem to receive the few emails that I send.

Tonnes? I don't like to say 'just search for it', but seriously you'll get more out of that than a response here. Personally I use SES for the 'hard' bit, but there's loads of OSS if you want to self-host the actual receiving too. (Sending probably requires more time looking into getting a trustworthy static IP than software. Again, I bypass that by using SES, but that's technically only self-hosting storage & client.)

I'd say "advertise Fastmail".

They have an MCP end-point, they want to market to both AI proponents and critics -- that's about what I learnt from scanning the article.

I feel like I just ate a sandwich made entirely of corporate air.

I've heard nothing but good things about Fastmail, but this article in particular is literally just pointless fluff.

As coming from fastmail I expected something more substantial, it seems to be low quality marketing

Yeah, it's just a simplified explanation of what SPF, DKIM and DMARC are. Nothing new.

So the natural extension of this would be plugins which have curated open source allow-lists? Similar to how I trust uBlock Origin's default ad filtering block-lists, I would similarly trust a curated open source allow-list for email domains, and then I would add my own from the "to screen" folder?

This is basically where I (and I imagine many others) have landed with the telephone. Anyone not in my contacts goes to voice mail. Made my phone usable again.

Disclaimer: I do some work for one of Gmail's competitors.

Of all the stuff Gmail imposes on the rest of the world, requiring proper sender authentication was a good thing and we've helped thousands of senders set up proper authentication because of it.

Forcing the issue finally got rid of the ridiculous practice of ignoring SPF/DKIM failures and just setting the DMARC record to p=none.

None of this changes the fact that Gmail is a problem for so many other reasons, but this specific imposed change was a net benefit for the entire email ecosystem.

Honestly requiring DMARC was overall a good thing.

I was an email admin for a university. In the past - each college ran their own email. Before DKIM, before SPF, you'd just have basically random servers on the internet sending email as (school).edu. Tons of random subdomains too. math.(school).edu and so on.

Email was eventually centralized but you'd have parts of the university still running their own things. Insisting they're special and can't be brought into the fold.

So, we had a lot of stuff out there just not passing authentication. A lot of spammers could just impersonate our domain.

We'd go to leadership and say "hey we should really get our act together" - but everything was working. Our emails were still getting out. Hard to justify spending the time, getting various higher-ups within departments to give up their things, and so on.

Unless you can get like, the president to back your initiative- universities are very decentralized and it becomes an issue of "do we have the political capital to spend here." The overall relationship between central IT and the various college-based IT departments was terrible, often bordering on combative.

Google and Yahoo made it so we could go to leadership and say "people will not get our emails if we don't get this straightened out" and it became a priority. When I left our DMARC reports were showing something like a 99% pass rate when it was previously like, 50.

So, I'm glad Google and Yahoo made that call, it gave us the kick in the pants we needed to get our own shit together. I am 100% certain we were not the only org like this.

Plus for a small host - where you're just running a single mail server or something - you just need a few things to pass DMARC.

A DMARC record, and an SPF record, and for your emails to pass SPF. You technically don't need to do DKIM signing (though I'd still recommend it because that survives automated forwarding).

I think it's more they simply don't register small tech and self-hosting.

In time there will be a reckoning though. The geopolitical instability at the moment will see the end of the US dominant services used outside of the US so they will have to work out how to make a not small but balkanised email provider model work again.

I was definitely expecting profound insights into the next decade of digital communication...

Have been paying for Fastmail for years. It’s actually fast and lets me use my own domain. (And doesn’t shove AI down my throat). Cash well spent.

Of course it is possible to have E2E encryption on emails. You can have E2E encryption on everything. Just use `age` and encrypt your message with sender public key. Easy.

> Is it possible to have E2E encryption on emails?

You literally have a proton email address on your profile.

my brother in christ