Almost everything that goes wrong with email authentication goes wrong because someone applied a control at the wrong point in the path. So before any protocol, it is worth being precise about what the path actually is — and, more usefully, which parts of it you control and which you are merely hoping about.
Four roles, not four servers
A message passes through four kinds of software. They are roles, not machines: one server often plays several, and a large provider splits each across many hosts. The roles are what matter, because each one can only see certain things and can only make certain promises.
| Role | What it is | What it can check |
|---|---|---|
| MUA | The mail client. Outlook, Apple Mail, a webmail tab. | Nothing about authenticity. It displays what it is given. |
| MSA | The submission server your client logs in to, usually on port 587. | That you are you — it required a password. This is the only point in the whole path where a human is authenticated. |
| MTA | A relay. Hands the message to the next server toward the recipient. | Who connected to it, from which IP, and what that connection claimed. |
| MDA | Delivery into the mailbox, plus filtering and foldering. | Whatever the receiving MTA recorded before it. |
Read the right-hand column again. The only place a person proves who they are is at submission, inside their own organisation. Every hop after that is one server telling another server a name, and the receiving server deciding whether to believe it.
The path
For a message from alice@example.com to bob@recipient.org:
- Alice’s client submits the message to her organisation’s MSA, authenticating with her credentials.
- That server looks up where mail for
recipient.orgshould go, by querying DNS for its MX records. - It opens an SMTP connection to the best-preference MX host and offers the message. This is the hop where authentication checks happen.
- The receiving MTA accepts or rejects it, stamping what it observed into the message headers.
- Filtering runs, and the message lands in a folder — or does not.
Where your control ends
You control submission, your outbound servers, and the DNS records for your domain. You do not control the receiving side, and no protocol in this course changes that. SPF, DKIM and DMARC are all instructions to a receiver, published in DNS. Whether a receiver follows them is its decision, and the large providers mostly do.
Where the gap opens
The critical hop is the third one: an MTA you do not own connecting to an MTA you do not own, carrying a message that claims to be from your domain. Nothing in that connection is derived from Alice’s password. The receiving server has an IP address, whatever names the sending server chose to state, and no other evidence at all.
That is not a bug that was introduced later. RFC 5321 describes a protocol designed for a network where hosts were few and mutually trusting, and it was never revised to add sender authentication, because doing so would have broken every existing deployment. Everything in this course is an attempt to bolt authentication onto the outside of that protocol using DNS, which is why the mechanisms feel indirect. They are indirect.