A crash course in email security

1. SMTP trusts what it is told

SMTP is the standard that moves mail between servers. It dates from 1981, and it takes the sending server at its word. A session is a short dialog:

Server: 220 smtp.example.com ESMTP Postfix
Client: HELO sender.example.org
Server: 250 Hello sender.example.org, I am glad to meet you
Client: MAIL FROM:<bob@receiver.example.org>
Server: 250 OK
Client: RCPT TO:<alice@receiver.example.com>
Server: 250 OK
Client: DATA
Server: 354 End data with <CR><LF>.<CR><LF>
Client: From: "Bob Example" <bob@sender.example.org>
Client: To: "Alice Example" <alice@receiver.example.com>
Client: Subject: Test message
Client:
Client: Hello Alice.
Client: .
Server: 250 OK: queued as 12345
Client: QUIT
Server: 221 Bye

The receiving server checks none of it. As long as the connection is open, it accepts whatever the sender says. A message has two From addresses: the envelope sender (MAIL FROM), where bounces go, and the From header that a reader sees. Neither is checked. Impersonation is built into mail; sometimes that is what you want, and sometimes it is an attack.

2. What a message looks like

To write: the headers and the body; where From, Return-Path, DKIM-Signature and Authentication-Results sit, with our own SES message as the example.

3. Impersonation you want

Not every message in your name comes from your own servers. A marketing tool sends the newsletter, a billing service sends the invoices, a help desk answers tickets. Each one sends as your domain, on purpose. Any rule that stops forgery has to let these through.

From the applications you use to DMARC pass or fail →

4. Who is hurt by impersonation

Forged mail reaches people outside your organization and inside it. A gateway that marks mail from outside does not stop a message that claims to be from your own domain.

To write: the phish-simulation anecdote: the employer was not at p=reject, and a training vendor could forge its domain convincingly. Marked as the author's own account.

5. SPF

SPF lists the servers allowed to use a domain in the envelope sender (MAIL FROM). A receiver looks up the record of that domain and checks the sending server against it. The record may defer to others with include:, and a receiver follows at most ten such lookups; past that, SPF fails.

Check a domain's SPF and DMARC →

6. DKIM

DKIM is a signature over parts of the message, made by the domain named in d=. The receiver reads the public key at the selector the signature names and checks that the message did not change. A message can carry several signatures. DKIM proves the signing domain, and nothing about the From address.

7. DMARC and alignment

SPF and DKIM can both pass for a domain that is not the one in the From address. DMARC closes that gap: it passes only when SPF or DKIM passed for a domain that matches the From address. It also says what to do with mail that fails, with a policy of none, quarantine or reject, and where to send reports.

To write: alignment, written out, with an example of a pass that does not align; relaxed and strict; p, sp and np; the current standard (RFC 9989) and what it changed: pct is gone, t= is the test flag.

To write: the Top 100 figure from the DMARC Report (/resources/dmarc-report): how many of the best-known domains do not refuse forged mail.

• What is a DMARC aggregate report? →
• DMARC forensic reports, with an example →

8. What DMARC does not stop

DMARC protects the exact domain. A name one letter away is somebody else's domain, with its own records, and no report of yours names it. Display names and borrowed accounts pass DMARC too.

• Who sends mail as you, and what DMARC does not stop →
• The lookalikes of the Top 100 →

9. ARC

A forwarder or a mailing list can change a message and break its DKIM signature. ARC lets each server on the way record the results it saw and sign them, so the last receiver can trust a result that the forwarding broke.

10. BIMI

BIMI shows a brand's logo beside mail that passes DMARC, for a domain at quarantine or reject. It is the reward for reaching enforcement.

11. MTA-STS

Mail travels between servers, and a server in the path can read it unless the connection is encrypted. An MTA-STS policy tells senders to deliver to your domain over encrypted connections only. It is a TXT record and a policy file served over HTTPS.

To write: the testing and enforce modes, the policy file, and how to roll it out.

12. TLS-RPT

To write: the daily JSON reports of failed encrypted delivery (RFC 8460), and why they pair with MTA-STS. In our own words.

13. How we set up alesiansecurity.com

To write: our records, as a worked example: SPF, the DKIM keys, the DMARC record at reject, MTA-STS and TLS-RPT.