The Next Generation of Encrypted Email

Introducing Mailnite’s DNS-based Public Key Discovery

Email is Broken — Here’s How We Can Fix It

It’s no secret that email, as we use it today, is fundamentally insecure and centralized. Messages are, by default, open to prying eyes, easily forged, and — worst of all — completely controlled by a handful of corporations. Your address, your digital identity, is only yours for as long as a big provider lets you have it.

Why does this matter? Because email is the passport to our digital lives: it’s how we recover accounts, sign up for services, and prove who we are. Yet, despite advances everywhere else, email lags behind — still reliant on 1970s architecture that never envisioned today’s privacy and autonomy needs.

The Problem: Email’s Privacy and Control Gaps

- Lack of encryption: Most email is still sent in plaintext. Anyone with access — providers, hackers, state actors — can read your mail.

- Centralized ownership: Lose your Gmail/Outlook/iCloud account? You lose your digital identity and your history.

- Weak sender authentication: Phishing is rampant. Anyone can pretend to be anyone.

- Difficult to upgrade: Attempts at secure email (like PGP) failed to go mainstream because of poor usability and discoverability.

A Simple Idea: Publish Public Keys in DNS

What if you could easily publish your public encryption key as part of your email identity, using the DNS — the same system that already routes your email? What if this information was always under your control, not your provider’s?

That’s the central idea behind the Mailnite Concept.

How Does It Work?

- You generate a public/private keypair (e.g., using the widely supported secp256k1 curve).

- Your public key is published in your domain’s DNS as a TXT record at a well-known location.

- Anyone who wants to send you a secure message looks up your key in DNS, encrypts the content, and sends it to you through any standard email system.

- You decrypt the message locally using your private key, never sharing it with your provider or anyone else.

No provider lock-in. No opaque login. No gatekeepers. Just math and open standards.

The Mailnite Protocol: Key Discovery via DNS

The protocol is designed for maximum simplicity and compatibility with existing infrastructure.

Each user’s key is published at a TXT record named:

_mailpubkey.<user>.<domain>

The content is a semicolon-delimited string, for example:

v=1;pk=BzowchszhjIBqUCDj4wrsysO6BKOJkJsG0-Lbox7u27J;alg=secp256k1;exp=2026–01–01;[email protected];pv=mailnite;

Field Breakdown

• v: Protocol version.
• pk: Public key, encoded in Base64 URL-safe format (no padding).
• alg: The algorithm (e.g., secp256k1).
• exp: Key expiry date (for rotation and management).
• usr: External user identifier (such as an email address).
• id: Optional external ID or mapping value.
• pv: Provider ID (e.g., mailnite)—this enables new features and commercial support.
• sig: Optional signature for attestation.
• enc: Optional preferred encryption algorithm.

How to Use It

1. User or admin generates a keypair.
2. The public key is published in DNS as a TXT record for their address.
3. Sender queries DNS for the recipient’s key, encrypts the email, and sends it as usual.
4. Receiver’s client/plugin decrypts the message using the private key.

Everything else stays the same — no need to change your email server, client, or workflow.

Trade-offs and Considerations

Let’s make a SWOT analysis.

Advantages:

• Decentralized: No single company owns your identity or data.
• Easy discovery: Public keys are always available at a predictable DNS location.
• Upgrade path: Compatible with existing email infrastructure and clients (with simple plugins or extensions).
• Extensible: Fields like pv allow for new commercial or open features.

Trade-offs:

• Doesn’t stop spam: Spammers can still send to your address. (But encrypted mail is less useful to them.)
• Key management: Users need to keep their private key safe (but this is true of all real cryptography).
• DNS privacy: DNS queries for your key can be observed by network operators. (Solutions: DNS-over-HTTPS, or storing only a hash/mapping.)

See the Full Protocol Documentation

The Mailnite Concept Repository includes a living specification, implementation notes, and example scripts. Here’s an example record:

_mailpubkey.alice.example.com. IN TXT "v=1;pk=BzowchszhjIBqUCDj4wrsysO6BKOJkJsG0-Lbox7u27J;alg=secp256k1;exp=2026-01-01;[email protected];pv=mailnite;"

Want to try it?

• Follow the step-by-step guide.
• Generate your keypair and publish your public key.
• Use or build a compatible client or plugin (coming soon).

Join the Conversation

Mailnite is an open protocol — your feedback, ideas, and pull requests are welcome!
We believe privacy and user control should be the default, not an add-on.

Mailnite PoC code is available here.

Read more, contribute, and follow the progress at github.com/mailnite/concept.