reading email headers exposes a phishing attempt
grep -iE '^(from|return-path|reply-to)' phish.emlthe email said "IT Helpdesk" but the internet disagreed
the from name on an email is basically a sticky note. anyone can write anything on it. "IT Helpdesk," "CEO," "Payroll Team," none of that costs an attacker anything because email was never designed with identity verification baked in from the start. what actually tells you who sent something is buried underneath the pretty display name, in the headers. that's the part attackers hope you never scroll down to see.
pulling the headers that matter
every email you get has a raw source view, usually under something like "show original" or "view source." save that as a .eml file and you can grep it like any other text.
grep -iE '^(from|return-path|reply-to)' phish.emlthis pulls three specific header lines because they're the ones attackers can't fully align without effort:
from is the display name and address the mail client shows you. this is the easiest one to fake.
return-path is where bounce messages go. it's often the real sending domain, and it doesn't have to match the from address at all.
reply-to is where your reply actually lands. legit companies rarely set this differently than their from address. phishing kits set it to a totally different mailbox they control.
in the example, "From" says company.com but "Return-Path" says company-shop.com. that mismatch alone is enough to slow down and look closer.
checking authentication results
domains can publish rules that say "only these servers are allowed to send mail as me." you can check whether the email actually followed those rules.
grep -i 'authentication-results' phish.emlthis shows three checks:
spf confirms the sending server was on the domain's approved list. a fail means the server that sent this had no business claiming to be that domain.
dkim checks a cryptographic signature attached to the email that proves the content wasn't altered in transit and came from a server holding the domain's private key. "none" means there wasn't even an attempt.
dmarc is the policy that ties spf and dkim together and tells receiving servers what to do when checks fail, like reject or quarantine. "p=reject" failing means this message should have been blocked before it ever hit an inbox, which tells you something about the gaps in whatever filter let it through.
checking how old the domain actually is
lookalike domains are cheap and disposable. attackers register them, run one campaign, and abandon them. a whois lookup tells you how long a domain has existed.
whois company-shop.com | grep -i 'creation date'a domain registered two days ago claiming to be your longtime vendor or internal IT department is about as suspicious as a brand new employee badge with yesterday's date on it. real companies don't spin up new domains to send routine IT emails.
the pattern that gives it away
none of these checks alone proves phishing. spf can fail for boring reasons like a misconfigured forwarder. what matters is when they stack: a from address that doesn't match the return-path, auth checks failing across the board, a reply-to going somewhere unrelated, and a domain that's only existed for 48 hours. that combination is the signature of a spoofed sender, not a coincidence.
the takeaway
you don't need to be a mail server admin to read your own headers. the "view original" option is sitting in every major email client, and the commands above take seconds once you've saved the file. if you run a small business or manage your own domain, go set up spf, dkim, and dmarc with a reject policy now, because those three records are what let inboxes catch this stuff automatically instead of relying on a human squinting at return-path lines. check your own domain's posture with a free dmarc checker, fix the gaps, and the next lookalike email spoofing your name won't even make it to someone's inbox to fool them.