Authentication
How a stranger's mail server decides your message is really from you
Five mechanisms, what each one actually does, and which of them are live today. Two are live. The rest are built and waiting on a step that is not a code change.
Sender authentication is the least glamorous part of running mail and the part that decides whether anything else works. None of it makes a message good. All of it makes a message checkable, which is a different and more modest claim than the one usually made for it.
The honest framing for the whole page: these mechanisms let a receiving server verify a claim. They do not oblige it to accept the message. Anyone who tells you otherwise is describing a system they do not run.
The mechanisms
6 pieces, each with the module that implements it
DKIM
Built, latched off
Signs the message with a private key so a receiving server can check it was not altered on the way and really came from this domain.
The signer is built and the canonicalizer it depends on is built. What is missing is a key. The keystore ships as a frozen empty object, and the resolver built from it returns null for every message, which the transport reads as 'send unsigned'. So the honest state today is: the signing path exists, runs, and produces no signature, and the message is flagged unsigned rather than dressed up as signed.
packages/notifications/src/mitto-dkim-signer.ts:123 (makeMittoDkimSigner)
Header and body canonicalization
Built
Normalises whitespace and folding before signing, so a harmless reformat in transit does not invalidate an otherwise valid signature.
This is the part of DKIM that people underestimate. A signature over raw bytes breaks the first time a relay rewraps a long header line. The relaxed form lowercases header names, collapses runs of whitespace, and trims trailing empty lines from the body, so the signature survives the ordinary handling a message gets between two servers.
packages/notifications/src/mitto-dkim-canonicalize.ts:42 and :67
SPF
Built, latched off
Publishes which servers may send for the domain, so a stranger's server cannot claim to be you.
The builder that computes the desired records for a sending domain exists and is named here. Publishing them in DNS for a particular domain is an operator step, and nothing on this page claims it has been done for yours.
apps/api/src/services/desired-dns-records.ts:34 (sendingDomainDnsRecords)
DMARC
Built, latched off
Tells a receiving server what to do when the two checks above fail, and asks it to report when that happens.
DMARC is the policy on top of the mechanisms, and it is the one that turns a pair of technical checks into something a receiving server acts on. Same status as SPF: computed, not published for you.
apps/api/src/services/desired-dns-records.ts:34 (sendingDomainDnsRecords)
Return-path
Built
Routes a bounce to a per-message envelope address so a failure is attributable to one send rather than smeared across the domain.
This one is live and needs no operator step. The envelope sender is constructed per message from the queue-row id, with the token sanitised so nothing user-supplied can shape an address. It is deliberately different from the from-line a human reads.
packages/notifications/src/mitto-smtp-transport.ts:176 (buildVerpEnvelopeFrom)
BIMI
Built, latched off
Shows a verified brand mark beside the message in the inboxes that support it.
Readiness is reported in tiers rather than as a yes or no, because the honest answer usually is 'the mark is valid but not certified'. A mark is never described as certified when it is not, which is the failure mode that makes this feature embarrassing rather than useful.
packages/notifications/src/bimi.ts:129 (bimiReady)
The signing chain
Three steps, and the one that is empty on purpose
Signing a message is not one operation. It is a chain, and it is worth seeing where ours stops.
First, canonicalize. The headers and the body are normalised so that harmless handling in transit does not break the signature: header names lowercased, runs of whitespace collapsed, trailing empty lines trimmed. Without this step a signature survives roughly until the first relay that rewraps a long subject line. This part is built and runs.
Second, sign. The signer takes the canonical form and a key and produces the header that travels with the message. It is built and it runs, and it is written to return nothing rather than something when it cannot do its job properly.
Third, find the key. This is where it stops today. The keystore ships as a frozen empty object and the resolver built from it returns null for every message. The transport reads that as an instruction to send unsigned, and the send is recorded as unsigned.
That last paragraph is the whole honest position on DKIM here, and it is deliberately not softened. The alternative — a page that says "DKIM signing" in a feature list and lets you assume it is signing your mail — is technically defensible and practically a lie. When a key is provisioned, the same path signs for real and this page will say so in the same plain words.
mitto-dkim-canonicalize.ts:42 and :67 · mitto-dkim-signer.ts:123 · mitto-dkim-keystore.ts:38 (EMPTY_MITTO_DKIM_KEYSTORE) and :96
The part almost nobody explains
There are two senders on every email, and only one of them is visible
The address a person reads at the top of a message is a header. The address a receiving server sends failure notices to is the envelope sender, and it is stated separately at the start of the session. They are allowed to differ, and here they deliberately do.
The envelope sender is generated per message and carries the identifier of the queue row for that exact send, on a dedicated bounce subdomain. When something comes back — a rejection, a mailbox-full notice, a complaint report — it arrives already tied to the message that caused it.
The alternative is one shared bounce mailbox holding ten thousand notices with no way to attribute any of them, which is the normal state of affairs and the reason most senders cannot answer the question "which message caused this".
One honest caveat, because this is exactly the sort of detail a page like this glosses: making the envelope sender a per-message address means it does not match the visible from-line. Alignment for policy purposes is carried by the signature's domain rather than by the envelope, which is why the signing chain above matters more here than it would in a simpler setup.
packages/notifications/src/mitto-smtp-transport.ts:176 (buildVerpEnvelopeFrom) · :162 (sanitizeVerpToken)
The limit of all of it
None of this promises your message reaches an inbox
Correct records and a real signature let a receiving server check a claim. What it then does with the message is its decision, made by systems nobody outside that company can see, using signals that change without notice.
So there is no inbox-placement promise on this site and there will not be one. What we can be held to is narrower and checkable: whether the records the builder computes are right, whether a signature is real or absent, and whether a failure is reported honestly rather than rounded up to a success.
The full list of things this product refuses to claim is on what we do not claim.
Elsewhere on this site
The rest of it
Overview
What a sending address is, and why the from-line is the whole product.
Read it →The wire
The eight-step SMTP session our own transport runs, and what each reply lets us conclude.
Read it →What we do not claim
The promises this page refuses to make, and the reason each one is refusable.
Read it →Pricing
Catalog figures for planning a budget. Checkout is not open and nothing here bills.
Read it →