How Email Travels — and How Servers Check the Sender
Where you are: Unit II — How the Digital World Works · Lesson 2.2 · This lesson follows Chapter 4 of Dr. Al-Doori's Cyber Security Essentials.
Email feels like a direct line from you to the person you write to. It isn't. In this lesson you follow one message on its journey and meet the three checks that modern mail servers run to decide whether a sender is who they claim to be.
What you'll be able to do
Follow an email from sender to recipient and explain in plain terms what SPF, DKIM and DMARC check.
- Name the stops an email makes between your app and the recipient's inbox.
- Explain what the part after the @ really means and how a server finds where to deliver mail.
- Describe what the three sender checks (SPF, DKIM and DMARC) can confirm, and what they cannot.
The journey of one message
Dr. Al-Doori follows a single email from sender to recipient, and that is still the best way to understand it. Here is the same journey in today's terms.
- You write the message in an email app. The book calls this the user agent. Today it is usually the mail app on your phone, or webmail in a browser (Gmail, Outlook.com, Yahoo Mail, Apple Mail and so on).
- Your app hands the message to your provider's mail server. The connection between your app and your provider is normally encrypted, which protects the message from people snooping on your Wi-Fi.
- Your provider's server passes the message on to the recipient's mail server. Mail servers talk to each other using SMTP (Simple Mail Transfer Protocol), the standard that still governs email delivery (IETF RFC 5321). Along the way, each server reads enough of the message to know where to send it next.
- The recipient's server stores the message until their app asks for new mail, and the message appears in their inbox.
One consequence is easy to miss. The encryption between your app and your provider protects the message in transit, but it is not end-to-end encryption. Your provider and the recipient's provider both hold readable copies of ordinary email on their servers. As the book stresses, your message passes through servers you don't control, and that relay chain is where many email threats live.
The part after the @
Take the invented address sam@riverview.example. The part before the @ is the mailbox (Sam). The book describes the part after the @ as the name of a mail server. Today it is more precise to call it a domain: a name that an organisation registers and controls.
To deliver mail to that domain, the sending server looks it up in the Domain Name System (DNS), the Internet's directory. The domain's DNS entry lists which mail servers accept mail for it (RFC 5321). So "riverview.example" is not one particular machine. It is a name whose owner decides which servers handle its mail. Hold on to that idea, because the sender checks below are built on it.
Headers: the label on the envelope
Every email carries headers: lines of information above the message itself, such as From, To, Date and Subject. The book also mentions the MIME header, which lets a message carry attachments and pictures as well as plain text.
Two points matter for security:
- The From line is written by the sender. On its own, nothing stops a sender from typing any name or address there. That is why the book warns, in Chapter 7, that a familiar name is never proof.
- Servers add "Received" lines as the message travels, which record the path it took. Investigators read these, and you will practise reading them in Unit VI.
How servers check the sender: SPF, DKIM and DMARC
Because the From line can be faked, mail providers now run three complementary checks. Each one answers a different question. Think of them as a sender list, a signature and a policy.
- SPF (Sender Policy Framework): the sender list. The owner of a domain publishes a list of the servers allowed to send mail for it. The receiving server asks: did this message come from a server on that domain's list? (RFC 7208)
- DKIM (DomainKeys Identified Mail): the signature. The sending server adds a digital signature linked to the domain. The receiving server checks the signature to confirm that the domain really sent the message and that it wasn't altered on the way. (RFC 6376)
- DMARC (Domain-based Message Authentication, Reporting and Conformance): the policy. DMARC ties the checks to the domain you actually see in the From line. The domain owner also publishes what receivers should do with mail that fails, such as sending it to spam or rejecting it, and can ask for reports. DMARC is now an IETF standard, RFC 9989 (May 2026), which replaces the earlier RFC 7489.
None of the three replaces the others. SPF and DKIM each confirm something about the sending domain. DMARC connects them to the visible From address and tells receivers how strict to be. Used together, they make it much harder to forge mail that claims to come from a domain whose owner has set them up properly.
Large providers now expect senders to use them. Gmail requires SPF or DKIM from all senders, and SPF + DKIM + DMARC from bulk senders (over 5,000 messages a day). Other providers may set their own rules. Yahoo, for example, publishes its own sender requirements.
What these checks cannot tell you is whether the sender is honest. A criminal can register a look-alike domain and set up perfect SPF, DKIM and DMARC records for it. A real account that has been hacked also passes every check, because the mail genuinely comes from that domain. Lesson 3.2 shows how attackers exploit both gaps.
Real-World Example
Imagine: a criminal wants to send fake "payment due" emails that appear to come from quillmontbank.example, a bank that has set up SPF, DKIM and a strict DMARC policy.
- Attempt 1, forging the exact domain. The criminal's server is not on the bank's sender list (SPF fails) and cannot produce the bank's signature (DKIM fails). The bank's DMARC policy says "reject", so the receiving server refuses the message. Most recipients never see it.
- Attempt 2, a look-alike domain. The criminal registers quillmontbank-payments.example and sets up valid records for it. Every check passes, because the checks confirm the domain is genuine, and it genuinely is the criminal's domain. Only a careful reader notices the address is not the bank's.
Sender checks closed the first door. The second door depends on you reading the address, a skill you will build in the next lesson.
From the Book to 2026
What the book teaches. Email is relayed between mail servers using SMTP; the text after the @ names the destination mail server; each message carries headers, including a return address, and a MIME header for attachments.
Why it made sense. This is still exactly how mail moves, and the relay model explains why messages pass through servers you don't control.
What has changed. Security guidance has evolved since the original text. The part after the @ is best described as a domain whose mail servers are looked up in DNS. Most people now read mail in phone apps and webmail rather than mail stored on their own computer. Above all, mail providers now check senders with SPF, DKIM and DMARC (DMARC is now RFC 9989), and Gmail requires them as described above.
What to do now. Read a passed check as "this really came from that domain", never as "this message is safe". The book's caution about forged senders still applies, now aimed at look-alike domains and hacked accounts.
Watch: What is SMTP — Simple Mail Transfer Protocol (PowerCert Animated Videos)
This three-minute animation shows the sending half of the journey: how SMTP carries a message from your app to your server and on to the recipient's server.
As you watch, notice:
- That SMTP is used twice: from your email app to your own mail server, and from your server to the recipient's server.
- That collecting mail is a separate step: the recipient's message waits on their server until they download it to an app or read it in webmail.
- The closing comparison of SMTP to a postal worker who picks up your mail and finds the route to the destination mailbox. It echoes the postal analogy from Lesson 2.1.
The video uses desktop email settings as its example. You don't need to configure anything yourself. The video reinforces what you just read — the lesson is complete without it.
What Would You Do?
A message arrives from it-support@yourcollege.example, your college's real domain. It says your mailbox will be closed today unless you reply with your password. A classmate says: "It must be real. It passed all the security checks, so it came from the college's own domain." Do you agree?
Knowledge Check
You send an email from your phone's mail app to a friend who uses a different provider. Which description of its journey is most accurate?
An email passes SPF, DKIM and DMARC for the domain shown in its From line. What does that tell you?
Answers explained
- Question 1 — b is right. Email is relayed: your app hands it to your provider, servers pass it on using SMTP, and it waits on the recipient's server until their app collects it. a is not right: email never travels straight between phones, and the encryption to your provider is not a direct line to your friend. c is not right: email is handled by mail providers, not by phone companies. d is not right: delivery doesn't depend on devices being near each other; the recipient's server holds the message until it is collected.
- Question 2 — a is right. SPF, DKIM and DMARC confirm the message really came from the domain it shows and wasn't altered. They say nothing about honesty. b is not right: a hacked real account, or a criminal's own look-alike domain, passes too, so links still need care. c is not right: the checks confirm a domain, not a person, let alone one you know. d is not right: the checks have nothing to do with end-to-end encryption; providers can still read ordinary mail.
- The "college IT" message (What Would You Do?): don't agree. If the checks really passed, the message came from the college's domain, but that could mean someone has hacked a college account. Legitimate IT teams don't ask you to email your password. Don't reply. Contact the IT help desk using the phone number or web portal you already know. Lesson 3.1 turns this into a habit: verify through another channel.
Key Takeaways
- Email is relayed through several mail servers using SMTP, and providers hold readable copies of ordinary mail.
- The part after the @ is a domain. Its owner decides, through DNS, which servers handle its mail.
- SPF (sender list), DKIM (signature) and DMARC (policy) are complementary checks. Gmail requires SPF or DKIM from all senders and all three from bulk senders.
- A passed check means "from that domain", not "safe". Look-alike domains and hacked accounts still get through.
Sources
- IETF — RFC 5321: Simple Mail Transfer Protocol
- IETF — RFC 7208: Sender Policy Framework (SPF)
- IETF — RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- IETF — RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
- Google (Gmail Help) — Email sender guidelines
- Yahoo — Sender Best Practices
- IETF — RFC 5322: Internet Message Format
- PowerCert Animated Videos — What is SMTP: Simple Mail Transfer Protocol
- Dr. Tahseen Al-Doori — Cyber Security Essentials, Chapter 4: How Email Works