The Two Halves of an Email
An email message is split into two parts by design: a block of headers at the top, and the body underneath. They are separated by a single blank line. The standard that governs all of this is RFC 5322.
When your mail client opens an email, it reads both halves, but it only shows you one. The body, the subject, the sender's name, the inline images, the call-to-action button: all of that is the half you see. The headers, the routing chain, the authentication results, the cryptographic signatures, the originating IP: all of that is the half you don't see unless you ask for it. The mail client renders the friendly half and hides the engineering half because most users would never want to read a 60-line block of Received: stamps before getting to "Your package has shipped." But the engineering half is where every trustworthy answer lives.
A phisher's job, then, is straightforward: forge or manipulate enough of the visible half to look convincing, and hope you never look at the hidden half. A defender's job is the opposite: develop the habit of glancing at the hidden half whenever something feels off.
What the human reads
The polished message your mail client renders for you. Designed to be glanced at and acted on in a few seconds.
- The
Subject:line at the top - The display name (e.g. "Northgate IT")
- The body text, images, and formatting
- Links, buttons, and attachments
- The signature block at the bottom
The single empty line between the two halves is not decoration. It is the parser's signal that the header block has ended and the body has begun. Every mail server on the planet, every spam filter, every forensics tool, depends on that one blank line. Lose it and the body becomes part of the headers; lose it on purpose and you have a smuggling trick. The blank line is the protocol.
The Friendly From Lie
The From: field a phisher gives you and the one a server checks against are not always the same field. Display names are free-form text. Anyone can claim to be anyone.
An email address in the From: header is allowed to take two forms. The bare form is just an address: alex@northgate.edu. The friendly form pairs a display name with the address: "Alex Johnson" <alex@northgate.edu>. The display name is a courtesy for humans. The angle-bracket address is for servers and clients. Mail clients almost always show the display name and either truncate or hide the actual address, especially on mobile, which is exactly the surface an attacker wants to exploit.
Below is a perfectly valid mail message that arrives in your inbox looking like it's from your IT department. Hover the link in the body to see where it actually points; check the metadata in the right-hand panel to see who really sent it.
Dear Faculty Member,
Our records indicate that your Northgate email password is scheduled to expire today. To avoid losing access to your account, please verify your credentials within the next two hours.
Click here to verify your account
If you do not verify in time, your account will be disabled and you will need to contact your department administrator to restore access.
Thank you,
Northgate IT Security Team
The display name says Northgate IT Helpdesk. The address shown next to it says it-helpdesk@northgate.edu, which sounds right. But three independent things in this message do not line up: the link points to a domain that is not northgate.edu, the urgency window is artificially tight, and the headers (which we will look at on the Email Anatomy page) would show that the message did not actually originate from a Northgate mail server. Any one of these is suspicious. All three together is a phishing attempt.
Reply-To and Return-Path
There are three different "from" addresses on every email, and they are allowed to disagree.
The From: header is what your mail client shows you. The Reply-To: header is where your response gets sent when you click Reply. The Return-Path: header (set by the receiving server based on the SMTP envelope) is where bounces and delivery failures get sent. In a legitimate email, all three of these usually agree, or they at least belong to the same organization. In a phishing email, they often don't.
A common attacker pattern is to set From: to a spoofed corporate address that the user trusts, but set Reply-To: to a free-mail address the attacker controls. When the victim hits reply, the response goes to the attacker's Gmail account, not the legitimate corporate address. The attacker has spoofed identity in one direction (the message looks like it came from someone trusted) and inbox in the other (any reply goes to them). And the Reply-To trick is allowed by the standard, so no spam filter automatically rejects it.
The From: claims to be Northgate. The Reply-To: redirects every response to a Gmail account. The Return-Path: shows the message was actually sent through a generic bulk mailer. If any of the three disagrees with the others, treat it as a tell. If all three disagree, it's a phish.
The Anatomy of a Phishing Attempt
A phishing email almost always reaches for the same handful of psychological levers. Knowing the levers makes the levers easier to see.
Manufactured Urgency
A deadline measured in hours, not days. The goal is to short-circuit your normal habit of thinking before clicking.
Borrowed Authority
The message claims to come from a name that outranks you (IT, HR, the CEO, the IRS) so questioning it feels insubordinate.
Look-Alike Domains
A domain that is almost, but not quite, the real one. A swapped letter, a homoglyph, a different TLD, or a legitimate-looking subdomain on an attacker's parent domain.
Generic Salutation
A real message from a service you use will almost always know your name. "Dear Customer," "Dear Faculty Member," and "Dear User" are warning signs.
Mismatched Link
The clickable text says one thing; the underlying href points somewhere else. Always hover before you click. On mobile, long-press to reveal the destination.
Unexpected Attachment
An invoice you weren't expecting, a shared document from someone who has never shared one with you, or a ZIP / ISO / .lnk / .docm from anywhere. Modern malware loves macro-enabled Office files and disk images.
Out-of-Band Request
Asks you to take an action through an unusual channel: gift cards, wire transfer, password reset by replying with credentials, secrecy ("don't tell anyone yet").
Quiet Reply-To Swap
The From: looks corporate. The Reply-To: hidden in the headers points to a Gmail or ProtonMail address. You'll never notice unless you check.
A Personal Defense Posture
You will not catch every phish by gut feel. Build the habits that catch the ones your gut misses.
-
Hover before you click, always. On desktop, point at any link without clicking and read the URL your browser shows in the corner. On mobile, long-press the link to preview the destination. If the visible text says
accounts.google.comand the destination sayssignin-googl3.co, you have your answer. -
Verify out-of-band when stakes are high. If an email asks you to transfer money, change a payment method, share credentials, or take any irreversible action, confirm the request through a separate channel that you initiate. Call the person at a number you already have. Walk to their office. Reply through the company's official chat, not by replying to the email.
-
When something feels off, view source. Every mail client lets you see the raw message. In Gmail: the three-dot menu > Show original. In Outlook: File > Properties > Internet headers. In Apple Mail: View > Message > All Headers. Get familiar with where the button lives before you need it.
-
Trust the unseen half over the seen half. When the visible
From:and the underlyingReturn-Path:,Reply-To:, orReceived:chain disagree, the unseen half is almost always right. Phishers polish the visible half; they rarely have control over the entire envelope. -
Check the SPF, DKIM, and DMARC results. The receiving server has already done the math for you. Look for an
Authentication-Results:header. Apasson all three is a strong positive signal; afailon any of them when the message claims to be from a major institution is a strong negative one. The next page covers exactly how to read these. -
Report rather than delete. Deleting a phish helps you. Reporting it helps everyone behind you. Most institutions have a "report phishing" button or a dedicated address (at Northgate:
abuse@northgate.edu). One report can lead to a domain block that protects thousands of other users. -
When in doubt, do nothing. No legitimate organization will ever fault you for not acting on a suspicious email until you've verified it. Phishers depend on you doing something now. The safest action when you cannot tell is the action of not acting.
Where to Go Next
This page covered the concepts. The next two pages are the practice: opening a real headers block and reading what it tells you, then learning the three protocols that decide whether the headers can be trusted at all.