Where an Email Came From

Part of the Security Fundamentals section of Coddy's Cybersecurity journey. Lesson 29 of 43.

The sender name on an email is not enough to prove who sent it. Headers give you more information about how the email arrived and which sender checks passed. You can read them with:

seclab headers m7

You should see:

Received: from relay.outside.test [203.0.113.77] by mail.lumen.test
Authentication-Results: mail.lumen.test; spf=fail; dkim=fail

The Received line says Lumen got this message from an outside server. In Authentication-Results, spf=fail and dkim=fail mean that two checks on the sender failed. Together, these are warning signs for an email claiming to come from Lumen's IT team.

A real supplier may use a separate mailing service, so an unfamiliar server is not enough to call an email fake. Read the sender checks as well as the message. Even passing those checks does not prove that a request for money or private information should be trusted.

Challenge

Easy

Ticket from Sam, IT lead

A supplier payment message and a supplier newsletter arrived through unfamiliar mail servers. Check their headers to find which is fake and which uses a real mailing service. Quarantine the fake before Omar replies and mark it as phishing. Mark the newsletter safe, and leave the genuine supplier invoice available.

Try it yourself

Terminal

All lessons in Security Fundamentals

2Phishing

Phishing Look-Alike Domains Who Clicked The Second Wave

5Email Attacks

Reply-To Dangerous AttachmentsWhere an Email Came FromThe Invoice Queue Business Email Compromise Blocking a Sender Mailbox Rules The Phishing Reports

3Access Control

Groups Least Privilege Admin Rights The New Hire Leavers Shared Accounts Separation of Duties The Access Review

6Rules of the Job

Authorization No Hacking Back The Vendor's Call