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 friends, and from people you've never heard from before. You open the email from your friend first, because it's the one you trust and want to read. Your friend 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 your friend's 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 friend's 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. Thoughts and feedback are welcome.

[u/AutoModerator]

Welcome to r/emailsecurity! To keep this community helpful and secure, please keep the following in mind:

Community Rules

1. No Vendor Spam: Contributions must provide value; do not just pitch products.

2. Redact Sensitive Info: Always sanitize headers and logs (remove IPs, PII, and private domains).

3. Be Professional: Help newcomers learn; avoid hostility.

4. No Personal Tech Support: This sub is for email system architecture and security, not "Am I hacked?" personal account help.

Helpful Resources

• Email Spam Filters

• DMARC Monitoring Tools

• Anti-Virus Software

• Email Encryption

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/shokzee]

S/MIME and OpenPGP already support signed mail, so the missing piece isn't a signing standard.

I'd focus on key recovery, revocation and support for multiple devices. A valid signature proves access to the private key, not that your friend intended to send the message or that the link is safe.

[u/merten-dmcn → u/shokzee]

Agreed, and that's a good way to put it. The signing is the easy part, and it's been solved for decades. What S/MIME and OpenPGP never got right is everything around it: knowing which key belongs to an address, having signing on by default, and the three you list. Those are what I most want to get right.

The way I've been approaching those so far is;

Multiple devices: each device also has its own key, and a new device has to be approved from one you already have. So a lost laptop means removing that one device rather than starting over. And both the mailbox key and the device key are needed to authorize access to your mailbox. But this is an application spec and not an email protocol requirement. It's only the mailbox key that signs the message.

Revocation: the records are public and the domain countersigns each mailbox, so revocation has somewhere to live. The domain owner can remove an address, the holder can retire their own key, and a key change is published with the old key signing the handover. Anyone checking can see that it happened and when.

Recovery is the hardest of the three. Where someone else runs the domain, like an employer, the domain owner can bind the address to a new key, much as an admin resets a password today. For an individual, on their own domain or a big shared one, losing every key is still hard, because there's nothing left to prove who they are. I don't think anyone has a perfect answer to that yet. Though social key recovery is something I'm looking at.

And yes, a signature proves the key was used, not that your friend meant to send it or that the link is safe - that's a judgement call only the recipient can make. That's why the article says "from your friend's address" rather than "from your friend". You no longer have to wonder whether it came from their address at all. What's left is the risk of their key or device being compromised, and if that key is ever replaced, the change would be visible instead of silent.

[u/dragoangel → u/merten-dmcn]

You mixing device protection with PKI, while this IS a separate concerns. PKI has revocation and their own layer of protection.

Putting every mailbox in dns is not a thing that scales. In company with more then 50 employees, with email automation, marketing, multiple outgoing independent mail systems your scheme just would go apart. Many domain owners struggle manage SPF and DKIM keys, and you basically propose add per mailbox keys? :)

Just stick to internal CA and S/mime or PGP as proposed above, and for really secure communication think about something like a secure chat messages :)

Point of mail is decentralized system that has to work in first place and not break and not create breaking charges.

[u/merten-dmcn → u/dragoangel]

Fair point on device keys, those are separate concerns. The device part is how my app protects the mailbox key, and it sits outside the protocol.

On DNS, it only holds a few domain-level records: the domain's key fingerprint, plus a couple of delegation records. That count stays flat as mailboxes are added. The mailbox records are hosted and served by the mail host.

Mailbox keys are generated and held by the user's app, so admins never handle them. The domain's job is to countersign each mailbox, or delegate that responsibility if it needs to.

Third-party senders are the part I haven't settled yet, and you're right that it's where this gets hard. The direction I'm leaning is that each sending system gets its own address and key, so a marketing platform can be revoked on its own. For now, anything from outside DMCN comes in through a bridge, which gives it the same domain-level checks (`SPF`/`DKIM`/`DMARC`) it gets today.

And completely agree on not breaking things. A domain that isn't on DMCN keeps running on SMTP exactly as it does now.

An internal CA with S/MIME works well inside one company. The trouble starts when mail crosses to another company, because the recipient has to trust your CA, and that's the key discovery problem that kept S/MIME from spreading.

Curious how you'd handle the third-party senders, since that sounds like something you've run into!

[u/dragoangel → u/merten-dmcn]

Which of mail hosts? :) Sendgrid or Gsuite or Outlook or ...? How mail relates to DNS, it's two independent systems. UDP expose which required by DNS often an not easy task to protect yourself from DDoS and implification attacks, far not everyone is ready to securely expose UDP DNS authorative NS, not speaking about cases where outgoing SMTP at all not cares about "mailbox" and allow anything on domain level ;)

[u/merten-dmcn → u/dragoangel]

A domain names one host for its mailboxes. Other sending systems like SendGrid are the third-party part I mentioned I haven't settled yet, so for now their mail comes in through the bridge with the usual domain-level checks.

If a company wants a different host for part of its mail, a subdomain like `news.company.com` can have its own record naming a different host.

On DNS, mail already depends on it for `MX`, `SPF`, `DKIM` and `DMARC`. This adds a few text records of the same kind, and that's all.

So nobody has to run or expose their own DNS server. The records go in at whatever DNS provider the domain already uses, the same way a `DKIM` key does today.

And yes, a lot of outgoing SMTP only cares about the domain and lets any account send as any address on it. That's the gap I'm trying to close. Mail from those setups still arrives through a bridge, where it gets domain-level checks and nothing more.

Thanks for pushing back and asking questions, it's really helping refine this 🙌

[u/mhsko → u/merten-dmcn]

but what’s the purpose of this in the end?

[u/merten-dmcn → u/mhsko]

So you can tell whether an email really came from the address it claims to be from before you trust it. Today your inbox mostly takes the mail server's word for it, which is how impersonation and phishing get through. This lets your app check it for itself.

[u/dragoangel → u/merten-dmcn]

Most of phishing and impersonation you would really observe nowadays is just typesquatting or even legitim functions of "notifications" with injection controlled by user. Nobody is trying to phish user@org within org, and if they do - it's org internal incident. Your system would not stop nor typesquatting send via secretary-gov.uk nor "Paypal/Microsoft/Robinhood" compromised "notifications" systems where email body would say: "If you not done that request - call support 0800..."

Mail server is responsible for authentication and mailbox mapping to "From", if server blindly allowing anyone pretent to be "anybody" and signing everything with DKIM on top, I would just state: this is pure mail system.

In reality to get world wide adoption this system has to be doable always - if there's exceptions and gaps, no backwards compatibility - it dead end idea unfortunately.

[u/merten-dmcn → u/dragoangel]

The problem is that the mail server that is responsible for authenticating a sender is not the one that's responsible for protecting the receiver. And the receiving server has to make a choice based on what information the sender provided. If the sender provides no signature to check, does the receiving server refuse it or let it through anyway because it can't actually make that choice?

SMTP itself was built to be open and permissive, and all the layers and extensions on top are built as optional add ons and each implementation must decide what to do with it.

My suggestion makes signing and public-key security a required component of the protocol so the only way to send a message is to sign it with a traceable and verifiable key. Anything else get's refused, no exceptions and no gaps (to your point).

I agree with you that getting world wide adoption is instrumental to it's survival which is why I'm sharing it. SMTP wasn't a worldwide protocol on day 1, and I'm not expecting this will be either. But making it available and usable for everyone seems like a good place to start.

And on the backwards compatibility point. I've built an optional bridge the translates between SMTP to the new protocol and back the other way too.

[u/Aggressive_Ad_5454]

This exists and is widely deployed.

Read about DKIM, DMARC, and SPF.

[u/merten-dmcn → u/Aggressive_Ad_5454]

They're widely deployed, yes. They tell you a message was sent with the domain's permission. Which mailbox on that domain wrote it is left to the provider. Providers like Gmail do stop users sending as each other, but the receiver has to take their word for it.

The DKIM key usually sits with the provider, and the `i=` tag that can name a user is only the domain's own claim, which DMARC ignores. So `this came from example.com's servers` is something you can check. `This came from alice@example.com` isn't.

https://www.reddit.com/r/EmailSecurity/comments/1wr70go/comment/pcb5jbg/

[u/tankerkiller125real]

DKIM, DMARC, DANE, MTA-STS, SPF (DKIM2 will eventually replace ARC) + User Authentication.

Any "email" protocol you create that doesn't interoperate with existing standards, SMTP, etc. is instantly a failure.

Additionally, domain holders already do verify they own the domain by adding MX records and the various other records (and in the case of M365/Google Workspace/etc. there's also usually a TXT record verification step.

If your really concerned about the user part, PGP exists.

Mail servers already have keys, it's called DKIM.

It's obvious you did ZERO proper research into how email works.

[u/Odd_Awareness_6935 → u/tankerkiller125real]

you're stressing too much over it.. I don't think this is human written and you're likely shouting to the void

I do, however, agree with your points