Reading the sender and headers

Module 3: Recognising phishing · Reading time: 13 minutes

Learning goal: After this lesson you can assess the sender of an email using the display name, the From address, Reply-To, Return-Path, the Received lines and the outcome of SPF, DKIM and DMARC in Authentication-Results.
Key terms: display name, From, Reply-To, Return-Path, Received, Authentication-Results, SPF/DKIM/DMARC result, alignment

What you see and what's really there

An email program usually shows you only a small part of the sender: a name, sometimes an address. Behind that sits a block of technical lines you don't see, the headers. These record who the email claims to be from, where it wants replies sent, which servers it passed through, and what your mail server checked.

You don't need to be a technician to read them. You need six:

A sender can write whatever they like for the first three. Only the last three involve any checking.

The display name says nothing

The display name is just text. Anyone can use "Mijnbank Customer Service" or your director's name as the display name. Many email programs, especially on phones, show only that name. A well-known trick is to put an address inside the name:

From: "info@mijnbank.example" <noreply@aanvaller.example>

You see info@mijnbank.example, but the real address is between the angle brackets. So always tap or click the name to see the full address.

The From address itself can also be forged: the mail protocol lets a server state any From address. Whether that succeeds without landing in the spam folder depends on the SPF, DKIM and DMARC of the domain being impersonated. That's what the rest of this lesson covers.

Reply-To: replies go to someone else

With Reply-To, an email says: "don't reply to me, reply to this address instead." Newsletters and web forms normally use this. Scammers use it to take over a conversation. The email comes from a real or real-looking address, but your reply, with the requested details or payment confirmation, goes to the attacker.

From: Flour Supplier <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>

Whenever money or details are requested, always check the address in the reply window before you press Send.

Return-Path, Received and the route

The Return-Path is the address error messages go to. It's also called the envelope sender: the address on the outside of the envelope, while From appears on the letter itself. SPF checks against that domain. For newsletters and invoices from accounting software, the Return-Path is often a domain belonging to the sending service. That's normal.

Every server that passes the email on adds a Received line on top. So you read them from bottom to top: the bottom line is the start of the route, the top line is the last stop (your own mail server). Note: you can only trust the top lines, the ones your own provider added. Below that, a sender can include made-up lines.

Authentication-Results: the outcome of the check

Your own mail server checks three things on arrival (more explanation in module 4 and the DNS course):

• SPF: was this server allowed to send mail for the domain in the Return-Path?
• DKIM: is the digital signature valid, and which domain does it belong to (d= or header.d=)?
• DMARC: does at least one of those two successful checks belong to the domain in From? This is called alignment. "Belongs to" means: the same registrable domain (lesson 3.2). mail.mijnbank.example is aligned with mijnbank.example (same registrable domain).

The result appears in Authentication-Results. Only trust the line with your own mail server's name at the front; a sender can include such a line themselves too.

The key lesson: dmarc=pass only means "this email really comes from the domain in From." It says nothing about whether that domain can be trusted. An attacker with their own lookalike domain can have everything neatly set to pass.

In practice: what it looks like

Three simulated header blocks, shortened to the lines that matter. The recipient is Bakkerij Example; its own mail server is called mx1.example.com.

Example 1: genuine.

Return-Path: <bounce-7731@mail.mijnbank.example>
Received: from out3.mail.mijnbank.example (out3.mail.mijnbank.example [198.51.100.40])
	by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 09:14:06 +0100
Authentication-Results: mx1.example.com;
	spf=pass smtp.mailfrom=mail.mijnbank.example;
	dkim=pass header.d=mijnbank.example header.s=sel2026;
	dmarc=pass (p=reject) header.from=mijnbank.example
From: Mijnbank <info@mijnbank.example>
To: info@example.com
Subject: Your 2026 annual overview is ready

The From domain is mijnbank.example and DKIM is signed by mijnbank.example, and the Return-Path falls under it: both aligned, DMARC passes. The email really is from that domain. Still, go to the bank via your own bookmark for the annual overview.

Example 2: forged sender.

Return-Path: <x7@mailer.aanvaller.example>
Received: from mailer.aanvaller.example (mailer.aanvaller.example [203.0.113.66])
	by mx1.example.com with ESMTP; Sun, 08 Nov 2026 10:02:41 +0100
Authentication-Results: mx1.example.com;
	spf=pass smtp.mailfrom=mailer.aanvaller.example;
	dkim=none;
	dmarc=fail (p=none) header.from=leverancier.example
From: Flour Supplier <administratie@leverancier.example>
Reply-To: <administratie@leverancier-betalingen.example>
Subject: New account number

SPF passes, but for aanvaller.example, not for the From domain. There's no signature. So DMARC fails. Because the supplier has p=none, the email was delivered anyway. With p=reject it would have been rejected. On top of that there's the Reply-To pointing to a different domain. Fake.

Example 3: lookalike with everything on pass.

Return-Path: <service@mijnbank-veilig.example>
Received: from smtp.mijnbank-veilig.example (smtp.mijnbank-veilig.example [192.0.2.77])
	by mx1.example.com with ESMTPS; Sun, 08 Nov 2026 11:20:13 +0100
Authentication-Results: mx1.example.com;
	spf=pass smtp.mailfrom=mijnbank-veilig.example;
	dkim=pass header.d=mijnbank-veilig.example header.s=k1;
	dmarc=pass (p=reject) header.from=mijnbank-veilig.example
From: Mijnbank Customer Service <service@mijnbank-veilig.example>
Subject: Confirm your details for the new payment card

Everything passes, because the attacker has set everything up properly for their own domain. But mijnbank-veilig.example is not mijnbank.example, the real bank. Fake.

Opening the headers yourself. In webmail based on Roundcube (as used by WebOké), open the message and choose More (the three dots) in the menu, then Show source. Other programs call it, for example, "Show original" or "Message source". Search the text for Authentication-Results. This often isn't possible on a phone; view the email in webmail on a computer instead.

Summary

• The display name, From and Reply-To are written by the sender. Always check the real address and the Reply-To before replying.
• Return-Path is the envelope address that SPF checks against. Read Received lines from bottom to top; only trust the ones from your own provider.
• Authentication-Results gives the outcome of SPF, DKIM and DMARC. DMARC checks whether SPF or DKIM is aligned with the From domain.
• dmarc=fail on a well-known domain is a strong sign of forgery.
• dmarc=pass only proves the email comes from the From domain. Always check whether that domain is the genuine one.

Quiz

Exercise

Exercise A3.3: Reading headers. You'll be given three header blocks. For each block, fill in: the domain in Return-Path, the domain of the DKIM signature (d=), the DMARC result, and whether the email is genuine or fake. The program checks your answers and, if wrong, points to the line where the answer can be found.

Further reading

The steps in the WebOké articles apply to the WebOké environment; with other providers it works in a similar way.

• What is DMARC? Explanation in plain language
• My email doesn't arrive or ends up in spam: here's how to figure it out
• Public email check (SPF, DMARC, MX) for a domain: https://www.weboke.de/en/email-check, and the mail test from internet.nl: https://internet.nl
• DNS course, lessons 4.3 SPF, 4.4 DKIM and 4.5 DMARC: https://www.weboke.de/en/dns-cursus
• RFC 8601, Authentication-Results: https://www.rfc-editor.org/rfc/rfc8601