E-mail: how it works, where it comes from, where it is going

More than 50 years old and still the most important tool in business: how an e-mail finds its way, why forgery used to be so easy and what is changing right now.

Architecture and roles

MUA → MSA (submission 587/465) → MTA → MX lookup in the DNS → recipient MTA (25, STARTTLS) → MDA → IMAP 993 to the MUA — MUA, MSA, MTA, MDA: the roles in the mail system.

Role	Task	Protocol / port
MUA (Mail User Agent)	mail program, webmail, app	submission 587 (STARTTLS) or 465 (implicit TLS, RFC 8314)
MSA / MTA	authenticated acceptance, relay between servers	SMTP 25, opportunistic STARTTLS (RFC 3207)
MDA	delivery to the mailbox, filters (e.g. Sieve)	local, LMTP
Access	reading and synchronising	IMAP 993 (IMAP4rev2, RFC 9051), POP3 995, JMAP (RFC 8620/8621)

Delivery: the sending MTA resolves the MX record of the recipient domain (falling back to A/AAAA if no MX exists; a "null MX" per RFC 7505 declares a domain as not receiving mail) and tries the servers in order of priority. Temporary errors (4xx) lead to retries over hours or days, permanent ones (5xx) to a non-delivery report.

Envelope and header: two senders

SMTP separates the envelope (MAIL FROM, also return path or RFC5321.MailFrom) from the header of the message (From:, RFC5322.From). Humans only see the header. Forgeries exploit exactly this gap, and this is exactly where DMARC applies alignment.

S: 220 mx.example.ch ESMTP
C: EHLO mail.eam.ch
S: 250-STARTTLS
C: STARTTLS
   … TLS handshake …
C: MAIL FROM:<bounce@eam.ch>
C: RCPT TO:<customer@example.ch>
C: DATA
   From: eam.ch <noreply@eam.ch>
   Subject: …

History and standards

1971 Ray Tomlinson, BBN: mail between computers on the ARPANET, separator @.
1982 RFC 821 (SMTP) and RFC 822 (message format).
1984/1988 POP (RFC 918), IMAP (Mark Crispin, 1986; IMAP2 RFC 1064, 1988).
1992/1996 MIME (RFC 1341, today RFC 2045–2049): attachments, character sets, multipart messages.
1995 ESMTP (RFC 1869): extensions such as SIZE, 8BITMIME, later AUTH.
1999/2002 STARTTLS for SMTP (RFC 2487, today RFC 3207).
2008 RFC 5321/5322 replace RFC 2821/2822 (current SMTP standard).
2006–2015 SPF (RFC 4408 → 7208, 2014), DKIM (RFC 4871 → 6376, 2011), DMARC (RFC 7489, 2015, informational).
2012 Internationalised addresses (SMTPUTF8, RFC 6531).
2015–2019 DANE for SMTP (RFC 7672), MTA-STS (RFC 8461) and TLS-RPT (RFC 8460, both 2018), ARC (RFC 8617, experimental).
2018 RFC 8314: implicit TLS recommended for submission and access (465, 993, 995).
2021 IMAP4rev2 (RFC 9051).
2024/2025 Google and Yahoo (from February 2024) and Microsoft for Outlook.com, Hotmail and Live (from 5 May 2025, more than 5,000 e-mails per day): SPF, DKIM and DMARC are mandatory, otherwise rejection.
2026 DMARCbis on the standards track: RFC 9989 (protocol), 9990 (aggregate reports), 9991 (failure reports); RFC 7489 replaced.

Authentication in detail

SPF checks the IP against the envelope sender, DKIM the signature with domain d= and selector s=, DMARC requires alignment with the From header — SPF and DKIM provide the result, DMARC links it to the visible sender.

SPF (RFC 7208)

TXT record on the envelope domain, e.g. v=spf1 mx include:spf.protection.outlook.com -all. Limits: at most 10 DNS lookups (include, a, mx, redirect …), forwarding breaks SPF, and SPF does not check the visible sender.

DKIM (RFC 6376)

Signature over selected header fields and the body; the public key is published at <selector>._domainkey.<domain>. Recommended: RSA 2048 bits (or additionally Ed25519, RFC 8463), regular key rotation, sign From more than once (oversigning).

DMARC (RFC 7489 and RFC 9989)

_dmarc.example.ch. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.ch; adkim=s; aspf=s"

DMARC passes if SPF or DKIM passes and matches the domain in From: (alignment, relaxed or strict).
Policy p=none (reports only), quarantine, reject; sp= for subdomains.
DMARCbis (RFC 9989): pct, rf and ri are historic; new are t=y (test mode, one level lower), np= for non-existent subdomains and psd= for public suffix domains; the organisational domain is determined by a DNS "tree walk" (at most eight queries) instead of the Public Suffix List.
Aggregate reports (rua) show who sends in the name of the domain – the basis for the path to p=reject.

ARC and forwarding

Mailing lists and forwarding change messages or the envelope. ARC (RFC 8617) records the authentication results along the way so that trusted intermediaries can explain DMARC failures.

Transport encryption

Method	Effect	Requirement
STARTTLS (opportunistic)	encrypted if both sides support it; an attacker on the network can suppress it (downgrade)	certificate on the MX
MTA-STS (RFC 8461)	senders require a valid certificate and TLS; policy via HTTPS at `mta-sts.<domain>`	TXT `_mta-sts`, policy file, valid certificates
DANE (RFC 7672)	certificate pinned via TLSA record in the DNS	DNSSEC for domain and MX
TLS-RPT (RFC 8460)	daily reports on failed encrypted deliveries	TXT `_smtp._tls`

State of play (2026)

The large mailbox providers enforce SPF, DKIM, DMARC (at least p=none, alignment), valid PTR records, TLS and – for bulk mail – one-click unsubscribe (RFC 8058) as well as low spam complaint rates.
The share of domains with p=reject is growing, but is still low, especially among SMEs and public administrations.
Submission via port 465 (implicit TLS) is gaining ground; port 25 is blocked for end devices by many providers.
End-to-end encryption (S/MIME, OpenPGP) remains a niche; confidential content often goes through portals.
Business e-mail compromise (BEC) and phishing remain among the most frequent attack vectors in many situation reports; forged senders and similar domains (typosquatting) play a central role.

Developments

DMARCbis in practice: tree walk, np=, t=; reporting and tools must catch up.
Post-quantum cryptography: hybrid key agreements (e.g. X25519MLKEM768) have arrived in TLS libraries and will also find their way between mail servers; quantum-safe signatures for DKIM are under discussion.
Enforced transport encryption with MTA-STS or DANE instead of opportunistic STARTTLS.
BIMI (brand logo for verified senders, with VMC/CMC certificate) as an incentive for p=quarantine/reject.
JMAP as a modern, JSON-based access protocol alongside IMAP.
AI on both sides: better filters, but also deceptively genuine phishing mails without language errors – technical authentication becomes a must, not an option.

What eam.ch checks

SPF (present, too permissive, errors), DMARC (present, policy, report address), DKIM (common selectors).
MX: STARTTLS and certificate; MTA-STS and TLS-RPT; domains without mail lacking protection against forgery.
Similar domains that can send e-mail (lookalike domains) and mail servers on blocklists (reputation).

Sources: RFC 821, 822, 1341, 2045, 3207, 5321, 5322, 6376, 6531, 7208, 7489, 7505, 7672, 8058, 8314, 8460, 8461, 8463, 8617, 8620, 8621, 9051, 9989–9991 (rfc-editor.org); Microsoft Tech Community, "Strengthening Email Security: Outlook's New Requirements for High-Volume Senders" (2025); Google, "Email sender guidelines" (2024).

In short

E-mail travels in three stages: sending (SMTP), passing on between servers (SMTP via the MX record) and collecting (IMAP).
Senders can be forged because SMTP does not check them.
SPF, DKIM and DMARC make e-mails verifiable; only p=reject protects effectively.
Since 2024/2025, Google, Yahoo and Microsoft require these records; in 2026 DMARCbis is published as the new standard.
MTA-STS and DANE enforce encrypted delivery.