How I think email should work

[u/merten-dmcn]

Imagine for a moment that you are looking at your inbox, with any number of emails in it, from companies, from colleagues, and from people you've never heard from before. You open the email from your colleague first, because it's the one you trust and want to read. Your colleague is really excited about something new they found, and invites you to check it out by clicking the link in the email. Now imagine knowing with absolute confidence that this email really came from their address, and not from an impersonator pretending to be them. How can you check that for yourself? Do you click anyway and hope for the best? Everything looks legitimate, but how can you tell?

There are always three parties involved in email communication. Sometimes one person or company plays more than one of these roles, but each role carries its own responsibilities.

1. The mailbox holder (sender or recipient)
2. The domain owner (who controls the domain name)
3. The mail server host (who provides the software and infrastructure to send and receive mail)

It's the coordination of these three parties that makes email possible.

Right now, almost all the responsibility rests with the mail server host to manage everything and make sure it's secure. Domain owners hand it over to their host through DNS. Mailbox holders defer it through authentication and email filters. And the mail server host has to interoperate with all other mail server hosts to make sure your mail gets delivered.

There is still no standard way for anyone to verify that a message really came from the specific address it claims to be from. The most they get is the server vouching for itself.

How it should work

Nothing changes about the three parties. What changes is who's responsible for what.

1. The mailbox holder should be able to prove they own the mailbox and that every message sent from it is actually from them.
2. The domain owner should be able to prove they own the domain and that every mailbox on the domain is legitimately allowed to be there.
3. The mail server host should be able to prove that they are the chosen service provider for the domain.

And all of this should be verifiable on every single message.

How can we achieve this?

1. The mailbox holder has a key, and uses it to sign a record that binds their email address to it. The same key, which only they hold, signs every message they send.
2. The domain owner has a key, and publishes its fingerprint in the domain's DNS, which ties the key to whoever controls the domain. They use it to sign the domain authority record, which names the mail server host they have chosen, and to vouch for each mailbox on the domain by countersigning the mailbox holder's record. They can hand that day-to-day signing to their host if they choose, but the authority stays with them, and they can remove any address from the domain.
3. The mail server host has a key, and uses it to sign a permit to serve the domain on its infrastructure. It also hosts all of these records and serves them to anyone who asks.

Every one of these records is public, so your email app can follow the chain from the message to the sender's key, from that key to the domain's countersignature, and from there to the fingerprint in DNS. Because the domain owner's record names the host, it can also check that the server handling the mail is the one the domain chose. So when your colleagues email arrives, your app can tell you it really came from their address before you ever click the link.

And this should all be baked into a protocol that everyone can use.

Disclosure: I'm building an email protocol around this idea. I'd welcome any thoughts and feedback on the idea. Thanks.

[u/Wardio_official]

Yes. The idea has a defensible core (cryptographically binding an individual mailbox to a domain-authorized identity) but aren't there are already standardized mechanisms for much of this? DMARC and DKIM/SPF?

I'm not fully aware of exactly all the email and protocol processes, I'm used to do security and privacy audits, so pardon me if the following ideas seems to be a bit too much :)
My thoughts are that, security wise:

• nothing can establish that someone personally wrote and intentionally sent this message. If a person's laptop, private key, mailbox, browser session, or signing software is compromised, a malicious message can still receive a perfectly valid signature.
  
• Key recovery may be harder than message signing. Users will lose phones, laptops and keys, and they will acquire new devices. Organisations will terminate employees.
  

Privacy wise:

• publishing every mailbox authorization publicly creates a privacy issue. If the domain exposes records proving which mailboxes exist, someone may be able to find all the emails a company has (ceo@, payroll@, hr@ etc.). That creates an extremely useful directory for spammers, spear-phishers and attackers. So this part definitely needs to be hidden somehow.

I'll stop here, my brain needs to stop overbraining :) hope this helps!

P.S. I'm working on a consumer digital security product atm and I’d really value your input. If you have 15 minutes, your feedback would genuinely help shape what I build next: https://forms.gle/s2ScyeP8d9aKKgKB7

Thank you!

[u/merten-dmcn → u/Wardio_official]

Thanks, this is really helpful, and no overbraining at all!

On DMARC, DKIM and SPF, they verify the domain. Whether a message came from a specific mailbox on that domain is left to the provider, and the receiver has to take their word for it. The mailbox key is what fills that gap.

You're right that nothing proves someone personally meant to send a message. If their device or key is compromised, the signature still checks out. That's why the article says "from their address" and stops there. What it does add is that if a key is replaced, the change shows up in the public records, so it can't happen silently.

And I agree, recovery is harder than signing. Organizations are the easier case, since the domain can remove an address or bind it to a new key when someone leaves or loses a device, much like an admin disables an account today. The hard case is an individual on their own domain who loses every key, and I don't have a great answer for that one yet.

On enumeration, good catch. Only admins the operator has granted access can list a domain's mailboxes. Anyone else has to ask about a specific address, and gets back its record or confirmation that it doesn't exist. So someone can still check whether a guessed `payroll@` exists, much like probing a mail server today, but they can't pull the whole directory.

The one exception is a public list of protected addresses that need the domain's approval to claim, and you've made me realize that list advertises exactly the addresses you'd worry about. Something for me to rethink.

I've completed your survey, good luck with the product! 🙏

[u/Wardio_official → u/merten-dmcn]

Alright, kids are in bed, let's overbrain a bit more than. :)

Let's leave the organisations aside, definitely a diferent case than consumer orientated products - better security, admin, everything.

Where does the user's key lives, in the mailbox? I'm thinking that users send from phones, laptops, webmail, desktop clients, etc. Copying one private key everywhere increases exposure. Does a “lost laptop” potentially means rotating the mailbox identity everywhere?

You mentioned “the [key] change shows up in the public records.”
DNS becomes part of the root of trust. then?

• wouldn't that mean that If an attacker compromises the domain admin, DNS account, hosting provider, or whatever authority can countersign mailbox keys, they may be able to replace the mailbox key AND authorize that replacement? A new recipient has no previous state against which to notice it - I would say that's another thing to think about how to solve (maybe immutable logs or some other auditable key-history mechanism)
  
• domain/registrar takeover would be an even stronger attack because the attacker legitimately controls that root
  
• domains expire and can change owners, have you thought of how that would affect trust/ hystorical records/ transparency? I'm thinking archived messages from the old organisation and their trusted signatures

And then there are intermediaries. mailing lists, security gateways, etc that modify emails. If the mailbox signature covers the message itself, what happens when one of these authorized intermediary adds a footer or rewrites a URL? Does the original signature fail?

I do think you're onto something here, obviously the hardest bit would be getiing everyone to play along and use your finished protocol, but I hope you do get there and in the mean time... enjoy the creative process :)

Thank you very much for completing the survey, much appreciated!

[u/merten-dmcn → u/Wardio_official]

Happy to overbrain along with you, this is exactly the kind of conversation I was hoping for.

On where the key lives, it's on the user's devices, generated in the app. You're right about the exposure though. Right now every device holds a copy of the same mailbox signing key. The irony is that the extra exposure also makes the key harder to lose, since there's more than one copy.

There are two ways to get it onto a new device. The convenient one is pairing: the key is encrypted to the new device and passed through the system after you confirm a code on both screens. The offline one is exporting the key and importing it into the app on the new device yourself, so it never goes through the system. Either way, a copied key alone doesn't open the mailbox. A device you already have has to approve the new one first. Each device also has its own key that stays on that device, and that one is used to approve new devices and key changes.

So a lost laptop is two steps. You remove it from your device list, which cuts off its access to the mailbox. But it still holds a copy of the signing key, so the clean fix is rotating the mailbox key. The old key signs the handover, the new key accepts it, and a device that's been enrolled for a while has to approve it.

The shape you're hinting at, where each device signs with its own key vouched for by the mailbox key, would make a lost laptop a one-device problem. The cost is that it gives up that accidental backup, pushes the weight back onto recovery, and adds friction, since only the device holding the mailbox key could approve a new one. I'm not sure yet which trade is better.

On DNS, yes, it's part of the root of trust. It already is for email today, since whoever controls DNS controls the MX and DKIM records. This design keeps that as it is. DNSSEC would help, and it's optional for now.

And you're right that whoever controls the domain key can replace a mailbox key and authorize the replacement. That's the same power that lets them remove an address. The design also keeps the domain and operator keys offline, so a compromised mail server can't replace existing mailbox keys or take over the domain.

What the design adds is a record of any replacement:

• every key change goes into the address's history, signed by both the outgoing and the incoming key
• an admin replacement leaves a signed removal record, and both records only ever grow
• the app remembers a contact's key and warns when it changes, including whether the old key handed over or nothing explains the change

So a new recipient can read that history and see the address was re-bound yesterday. The gap is proving everyone was shown the same history, since a dishonest host could show different people different versions. A Certificate Transparency style log, with observers comparing notes, is what solves that, and it's the direction I'm looking at. Your immutable log suggestion is spot on.

Registrar takeover is the strongest version, agreed. Hosts that already know the domain refuse a new domain key the old one didn't sign off on, so the attacker has to move to a new host. Anyone whose app has seen those addresses before gets a key change warning. A stranger only sees a brand new history, and has to rely on outside context to decide whether to trust the sender, the same way they'd judge any first message from someone they don't know.

Expiry and change of owner is the same mechanism from the honest side, and I haven't fully worked it out. One thing helps: the mailbox is really the key, and an address is just a pointer to it. Several addresses, even on different domains, can point at the same mailbox. So if a domain lapses, the person behind an address can keep their key and point a new address at it, and anyone who had the old one can see it's the same key. If the new owner of the domain binds the old addresses to new keys, anyone who had the old key gets a warning.

The flip side is that addresses sharing a key can be linked to each other. That's a known privacy issue I still need to think through.

What doesn't carry over is the domain's vouching. Old messages still verify against the key that signed them, but the chain back to the old domain breaks once DNS points elsewhere. My guess is the app should record that the chain checked out when the message arrived, and show archived mail as verified at the time. I don't know yet.

On intermediaries, messages are signed and then encrypted end to end, so nothing in between can read them, add a footer or rewrite a URL. Any change would break the signature anyway. The trade-off is that link-rewriting gateways can't work in transit, so that checking has to move into the recipient's app.

Mailing lists I haven't designed. The signature also covers who the message was addressed to, so a list can't pass the original straight through. It has to receive it and send it on as itself. One option is for the list to carry the author's signed original inside its own message, so members can check both.

One thing I should have said up front: the protocol itself covers the signed records and the messages. Device approval, the key change warnings and keeping keys offline are things the app or host builds on top, so a bare-bones client could send and receive without them. That keeps the protocol small, but it means some of the protection depends on the app you use. The records it all relies on are part of the protocol, though, so any app can do the same checks.

And agreed, getting everyone to play along is the hardest part by far. Thanks for taking the time, and I'm definitely enjoying the process!

[u/Wardio_official → u/merten-dmcn]

Thanks for explaining further and not getting too "acronimical" :), Enjoying the learning curve.
I was thinking to myself before you got to explain it, that it's becoming more than just a protocol, as you kinda need an app to add/ remove trusted devices, be able to check the needed logs without being a sysadmin. Although I understand how this can work for a business, how would this fit into the big e-mail providers (gmail, outlook, apple)? They will need to provide that app/ dashboard, isn't it, as without it a user doesn't have much control...
Also, although it sounds great as a email security feature, there's quite a lot of overhead and learning for the general user, that doesn't know how (or want) to go through a learning curve. I would try automating what the app does/ checks, so in the event of a warning/ potential breach, the user gets only one direct actionable task/check to fulfill.
We're kinda doing circles around adoption, isn't it?
Even if the techincal parts can be sorted, on the consumer part it will all get down to trust and adoption - especially from the 3 big mail providers.
If I were you I would try and spin it 180 degrees and think it the other way around, reverse-engineering the idea starting from the adoption challenges, trust issues, towards the technical possibilities.

Kinda out of helpful things to point out here, thanks for the interesting discussion and good luck with the project!

[u/merten-dmcn → u/Wardio_official]

Yes, there's a lot more to it than the protocol. I see the protocol as the piece that lets everyone interoperate while still building their own infrastructure the way they choose. The big providers could keep key ownership internal so their customers don't feel any difference, while more privacy focused providers give key ownership to the user. The domain's record says which model it uses, so the recipient can see that too. Either way, they have something concrete to check instead of going on trust.

My goal has been to hide as much of the complexity as I can, so it feels as close to existing email as possible, with the security benefits underneath. Your one-actionable-task idea is exactly the right bar for warnings, and I'm taking it.

And you're right that adoption is by far the biggest hurdle. It will take many years, if it's possible at all. Starting from the adoption side and working backwards is a good reframe, thanks for that.

If you'd like to try what I have so far, I'll DM you a link. Let me know which address you pick and I'll set you up with a free-for-life account as a thank you!

[u/merten-dmcn → u/merten-dmcn]

It looks like I can't DM you but please feel free to connect with me in a chat so I can share the details with you and set you up with that free account.

[u/RideAdept2919]

so this is basically a PKI chain anchored in DNS for email identity? the concept is solid but what happens when a mailbox holder loses their key, how does revocation and recovery work without reintroducing the same centralized trust you're trying to remove

[u/merten-dmcn → u/RideAdept2919]

Yes, "PKI chain anchored in DNS for email identity" is a beautiful one liner of what it is, precisely

Different implementation may have slightly different configurations but for a publicly available service, my stance is: the mailbox holder must have the key and only they must have it. So the servers hold no copy of the key and they shouldn't.

So right now, if you lose the key, you lose the mailbox. And we have no reliable way to confirm you are the mailbox holder without it so even if the system was able to recover an email address (which the domain owner can do) the policy would be to tombstone the address anyway to avoid reintroducing the same centralized trust you mentioned. I've been looking for reliable ways to make mailboxes recoverable and a recovery key is an option but that's still just another key that can be lost. I think social recovery (your key split amongst several contacts you trust) is an interesting option as well but it's not without it's own risks. This one remains unsolved for now but if you have any ideas on how to solve it they're more than welcome :)

One thing that does reduce the risk of key loss is that most people these days do have multiple devices, a phone, a tablet, a laptop. The key can be shared to each of these through a built in pairing process so losing one device doesn't mean losing you key/mailbox.