Questions

What do I actually need to implement?#

Four things: resolve an address, verify an identity, send mail, receive mail.

Start with proto/ in the repository — that's the real contract. Then read the spec for the parts the schema can't express: the signing convention, the resolution flow, and the challenge-response that authorises a fetch.

Onion routing and the SMTP bridge are optional. Skip them and you still interoperate.

How is this different from encrypting email?#

PGP and S/MIME encrypt the body of a message that still travels over SMTP. So they inherit SMTP's problem: the addressing layer is unauthenticated, metadata is in the clear, and whether a message is trustworthy gets decided after the fact by filters and reputation.

DMCNP moves the crypto down a layer. The address is a keypair, so authenticity is a property of the identity rather than a verdict about a message. There's no unauthenticated addressing layer left to spoof, and the header travels sealed alongside the body.

What about DKIM, SPF and DMARC?#

They're the best answer SMTP has, they genuinely help, and DMCNP is not pretending otherwise.

What they do: SPF says which servers may send for a domain. DKIM signs a message with a domain's key. DMARC ties the From address you actually see to one of those two, and tells receivers what to do when they don't line up.

Three things that leaves open.

They authenticate a domain, not a person. A valid DKIM signature says "a server authorised by example.com sent this". It doesn't say which account, and it can't — the signing key belongs to the provider, not to you. Anyone who can send through that provider inherits the same signature.

Enforcement is the receiver's choice. DMARC is a request, not a rule. A domain can publish p=reject and a receiver can deliver the mail anyway — plenty do, because strict enforcement breaks forwarding and mailing lists. The guess doesn't disappear; it moves.

They say nothing about the contents. These are authentication, not confidentiality. The message is still readable by every server that handles it, and sits in the clear at both ends.

DMCNP moves the key to the person. Your signature is made on your device, with a key your provider never holds, so who sent a message is settled by the message itself rather than by a policy the receiving side may or may not honour. The same key is what lets the mail be sealed so the servers in between can't read it either.

None of which makes the old three useless. DMCNP's SMTP bridge runs all of them for real on inbound legacy mail and passes the verdict on as a signed attestation inside the sealed envelope — for mail that starts in the old world, they're the best signal there is. (The daemon ships a stub auth mode for offline development that skips the checks; it is not the default, and it must never be used where real mail arrives.)

What doesn't a signature prove?#

A valid signature proves the message was signed with the key that belongs to the address it came from. That's all, and it's worth being clear about what it leaves out.

It doesn't prove the person meant to send it. If someone takes over your friend's device or key, anything they send will check out. What DMCNP adds is that a key can't be replaced quietly: a new key leaves a signed record anyone can look up.

It doesn't stop lookalike domains. paypa1.com can publish its own keys and sign its own mail perfectly. The signature tells you exactly which address sent it. Noticing that it's the wrong address is still up to you, or your mail app.

It doesn't make the content safe. A real company can still send you a message carrying text an attacker put there, such as a notification that repeats what someone typed into a form. It arrives correctly signed.

DMCNP settles one question: did this really come from the address it shows? Judging what's in the message is still your call.

How does mail reach ordinary email addresses?#

Through a bridge. A domain can run an SMTP bridge alongside its nodes. Mail you send to an ordinary address is sealed to the bridge rather than to the recipient. The bridge opens it and sends it on as ordinary email, signed with the domain's DKIM key. Mail coming the other way gets its SPF, DKIM and DMARC checks at the bridge, as described above, before it's sealed to you.

Either way the bridge reads the message, so that mail is not end-to-end encrypted. The quickstart covers setting one up.

Why switch if nobody I email uses it?#

You don't have to wait for them. A domain that runs a bridge can still send to and receive from every ordinary email address, so switching doesn't cut anyone off. Mail between two DMCNP addresses gets the full guarantee. Mail through the bridge gets the same checks email gets today and isn't end-to-end encrypted.

So it starts paying off inside one organisation, where mail between its own people is signed and sealed from day one, and it gets better with every domain that switches.

Getting everyone else on board is still the hardest part. SMTP wasn't everywhere on day one either.

Is there a blockchain, a DHT, or a global directory?#

No, and that's deliberate.

An earlier version did resolve identities through a Kademlia DHT. It came out because a big enough hostile majority in a shared overlay can quietly withhold records. For something meant to replace email, that's disqualifying.

Resolution is per-domain and DNS-seeded now: read _dmcn.<domain>, dial the nodes that record names, check what comes back against the fingerprint from DNS. A domain is served by the nodes it chooses — its own, or a host it delegates to — never by a shared pool it has no say in.

Does every mailbox need its own DNS record?#

No. DNS holds one TXT record per domain, at _dmcn.<domain>: the domain's key fingerprint and where to find the nodes that serve it. That stays the same however many mailboxes the domain has. Each mailbox's own record is served by those nodes, not by DNS.

The record goes in at whatever DNS provider the domain already uses, like a DKIM key. You don't need to run your own DNS server.

What if a domain's server lies about a record?#

A server that isn't your domain's authority can't, in the way that matters. Records sign themselves, and they chain to a domain authority anchored by a fingerprint in DNS. A hostile or just broken carrier can refuse to answer, or answer with something that fails verification. Both mean you don't get service. Neither means you get a forgery.

That's the whole reason the anchor lives in DNS and the records live with the domain: the dangerous failure isn't available.

The authority key itself is a different question, because it is what the fingerprint in DNS delegates to. It can't decrypt anything, and it can't produce a record your key signed — but it can tombstone a binding and let the address be bound again, which is the same mechanism that recovers a lost account. What it can't do is that silently: freeing an address leaves a signed, versioned, publicly resolvable record, and a client that pinned the old key sees the change.

Can my provider move my mailbox without asking me?#

Yes, on purpose. The RelayHints that say which relays hold your mailbox sit outside your signature, in a credential the operator signs. So an operator can re-point them to rebalance load or drain a machine without touching your key.

A record can name more than one relay. Senders try them in turn, so mail still arrives when one is down, and a domain can ask senders to store to all of them instead.

Moving the mailbox doesn't move the identity, which is also why your address survives the move.

Changing who you are is a different power, and it needs a different key. Re-binding an address to a new keypair is only accepted with a tombstone for the current key signed by the domain's root — the offline key behind its authority record. An operator key that can re-point routing, or attest new addresses, cannot do it. That matters because those are the keys that live on a running server.

The root itself can. On a domain someone else runs, that is a trust you are extending to them; it is also what makes admin key recovery possible at all. Run the domain yourself and the root is yours.

Who can read my mail?#

All the crypto happens client-side. Relays only ever handle sealed envelopes: one AES-256-GCM key per message, wrapped to each recipient over X25519, with the header and body sealed separately so listing an inbox never touches a body.

Two honest limits. Mail crossing the SMTP bridge is TLS-in-transit on the legacy side, not end-to-end encrypted. And relays necessarily see routing metadata — which mailbox is getting something, and roughly when. Payloads are padded to fixed size classes to blunt traffic analysis, and onion routing is there for senders who need the path hidden too — though it is inherited transport that stays inert until a mesh has at least three relays, so a single self-hosted node gets the padding but not the path hiding.

What happens if I lose my key or my device?#

The protocol gives an address three ways to get a new key.

Rotation. If the domain allows it, an address can switch to a new key itself. The handover is signed by the old key, accepted by the new one and confirmed by one of the owner's enrolled devices, and it goes into the address's history, which only ever grows. A stolen key alone can't do it, because device keys never leave their device. A domain can also require a device to have been enrolled for a while first. Rotation is off unless the domain turns it on, because it's a trade-off: someone who steals both a key and a device could rotate first.

A recovery key. An address's record can name a recovery key, kept apart from the one used day to day. It can sign the handover in place of a key that's been lost.

The domain. The domain's root key can retire an address's key and free the address for a new one, the way an admin resets an account today. On your own domain, that root key is yours.

Removing a lost device from your account is up to your mail app. The protocol's part is the key. If you lose every key, including the domain's, there's nothing left to prove who you are, and nobody has a good answer to that yet.

What's core and what's an extension?#

Core is what you need to interoperate. Everything else — fleet administration, hosting permits, provisioning, entitlements, quotas — is an extension.

Extensions attach through surfaces the core designs for them: separate libp2p protocol IDs, operator-attached credentials, ext.-prefixed credential attributes. Never through new core fields.

The rule that makes the split mean anything: ignore every extension and you still interoperate. An extension can give an operator new powers. It can't add a requirement to the network.

Why are some field numbers reserved?#

Because they were used once. Retired field and arm numbers keep a reserved declaration and a comment saying what they were, and they never get reused — several belonged to operator surfaces that moved out when the core/extension line got drawn.

Reuse one and you'd silently mis-decode messages from an older peer, so the history is part of the schema.

Is it decentralised if domains still have operators?#

It's federated, and it's worth being precise about what that buys you.

Operators run relays, control routing, and can attest addresses on their domain. That's real power over whether you get service and where your mail sits.

What an operator's day-to-day keys never get is the ability to read your mail — the keys for that never leave your device — or to re-bind your address to a key of their choosing, which takes a root-signed tombstone they don't hold.

The domain's root key is the honest exception. It can free an address and let it be bound again, which is the same mechanism that recovers a lost or compromised account. It cannot read mail that was already sent to you — that is sealed to a key it never had — but it can take over what arrives next. So the operator you should think hard about is whoever holds the root for your domain, and if that is you, there isn't one.

That key is not supposed to be on the server, and on a live domain the reference daemon does not have it: the operator mints it on their own machine and the node only ever receives the signed record it produced. Which means breaching the server is not the same as holding the root — an attacker who owns the box can deny you service, but cannot mint or re-point addresses.

The goal isn't a world with no operators. It's that picking one hands them as little as possible, and leaving costs you a routing change and nothing else.

What isn't designed yet?#

Some things email does today don't have a DMCNP answer yet.

Third-party senders. Services that send as your domain, like a newsletter platform or a ticketing system, don't have a design yet. The likely shape is that each gets its own address and key, which the domain can revoke on its own. Until then, their mail reaches DMCNP users through a bridge, with the same domain-level checks it gets today.

Mailing lists. A signature covers who the message was addressed to, so a list can't pass the original on unchanged. It has to receive the message 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. Security gateways that add a footer or rewrite links have the same problem: they can't change a sealed message, so that checking has to move into the reader's app.

Mail kept after a domain lapses. Old messages still verify against the key that signed them, but the link back to the domain breaks once its DNS points somewhere else. The likely answer is for the mail app to record that everything checked out when the message arrived, and show it as verified at that time.

Is it production ready?#

No. The reference server is a proof of concept, and the spec is a snapshot that moves with it rather than a frozen standard. It's complete enough to interoperate against and to read as the executable half of the spec. It isn't something to put in front of real users yet.

What does the license allow?#

Apache-2.0, with an express patent grant and defensive termination: implement it without worrying about patent claims from its authors, and that protection goes away for anyone who starts patent litigation over it.

The license covers the code and the schema, not the names DMCN and DMCN Protocol. Build whatever you like under your own name — just don't call it DMCNP unless it really conforms.