How Email Works: SMTP, MX Records, IMAP and Email Authentication
Sending an email feels instant and simple, but a message passes through several separate systems, each with its own job, before it reaches the recipient. This guide follows one message from Alice to Bob and explains each piece along the way: the address, DNS and MX records, SMTP, the mailbox protocols IMAP and POP3, and the authentication checks (SPF, DKIM and DMARC) that decide whether a message is trusted.
The parts of an email address
In alice@example.com, the part before the @ is the local part: it names a mailbox. The part after the @ is the domain: it tells the internet which organisation's mail servers are responsible for that mailbox. Mail servers route messages using only the domain. What happens to the local part is entirely up to the receiving domain, which is why some providers ignore dots in the local part, and why tricks like plus addressing work (see our comparison of aliases).
Step 1: Alice's app hands the message to her provider
Alice writes her message in an email app or webmail. When she clicks Send, the app submits it to her own provider's outgoing server. This first hop uses SMTP, the Simple Mail Transfer Protocol, on the submission port 587 (or 465 with encryption from the start). Alice's app must log in first, which stops strangers using her provider to send mail.
Behind the scenes, every message has two parts: the envelope (who the servers should deliver it to, and where bounces should go) and the content, which includes headers such as From, To, Subject and Date, followed by the body. The From line people see is part of the content and, on its own, proves nothing. That gap is what email authentication (below) exists to close.
Step 2: finding Bob's mail server with DNS
Bob's address is bob@example.org. Alice's server needs to know which machine accepts mail for example.org, so it asks the Domain Name System for the domain's MX (mail exchanger) records. A typical answer looks like this:
The numbers are priorities: lower is tried first. If mx1 is unreachable, the sender falls back to mx2. The 3600 is how many seconds other servers may cache the answer. If a domain has no MX record at all, senders fall back to the domain's ordinary address record.
Step 3: server-to-server delivery over SMTP
Alice's server connects to Bob's mail exchanger on port 25 and the two servers hold a short, plain-text conversation. Stripped down, it looks like this:
STARTTLS upgrades the connection to encryption when both sides support it, which today is the case for almost all large providers. If Bob's server is temporarily down, Alice's server keeps the message in a queue and retries for several days before giving up and sending Alice a bounce message.
Step 4: checks on arrival
Before accepting the message into Bob's mailbox, his provider runs checks. Three DNS-based standards do most of the work of spotting forged senders:
SPF (Sender Policy Framework)
The sending domain publishes a list of servers allowed to send its mail, as a TXT record such as v=spf1 include:_spf.example.com -all. The receiver checks whether the connecting server is on that list for the envelope sender's domain.
DKIM (DomainKeys Identified Mail)
The sending server signs parts of the message with a private key. The receiver fetches the matching public key from the sender's DNS and verifies the signature. A valid DKIM signature proves the message really passed through a server authorised by that domain and was not altered on the way.
DMARC (Domain-based Message Authentication, Reporting and Conformance)
SPF and DKIM each check a domain, but not necessarily the one in the visible From line. DMARC ties them to it: a message passes DMARC only if SPF or DKIM passes and the domain that passed matches the From address. The domain owner also publishes a policy saying what receivers should do with failures: nothing (p=none), send them to spam (p=quarantine) or refuse them (p=reject).
Providers then add their own spam filtering on top, looking at the sender's reputation, the content and the links.
Step 5: Bob reads his mail with IMAP or POP3
Once stored, the message waits in Bob's mailbox until his app collects it. Two protocols do that job:
| IMAP | POP3 | |
|---|---|---|
| Where mail lives | On the server; apps show a synchronised view | Downloaded to one device, usually removed from the server |
| Several devices | Yes, folders and read status stay in sync | Poorly; each device sees a different copy |
| Encrypted port | 993 | 995 |
| Best for | Almost everyone today | A single computer with limited server storage |
Webmail such as Gmail or Outlook.com skips these protocols for its own website and apps, but still offers IMAP so that other email programs can connect.
Where temporary email fits in
A temporary email service is a normal receiving domain with an unusual rule: it accepts mail for any local part and forgets it quickly. Steps 1 to 4 happen exactly as above; step 5 is replaced by a web page that shows the message for a few minutes. Our guide to how a temporary address works walks through that process for EmailVanish specifically.
Key terms
- MTA (mail transfer agent): server software that passes mail between domains, such as Postfix or Exim.
- MX record: the DNS entry naming a domain's incoming mail servers.
- Envelope sender / Return-Path: the address bounces go to; it can differ from the visible From.
- Bounce: an automatic message saying delivery failed, with a reason code.
- TLS: the encryption used between servers (via STARTTLS) and between your app and your provider.