Who really sent this? Senders, sending services, and content vs. context

Email was built in a more trusting era, and it shows: a lot of what looks like "proof" of who sent a message is actually trivial to fake. This guide covers what you can and can't trust about a sender — and ends with the single most useful habit, content vs. context.

The display name means nothing

The friendly name on an email — "PayPal Service", "IT Help Desk", "Karen Whitfield (CEO)" — is just a label the sender typed. Anyone can put any name there. I can send you an email right now with the display name "Bank of America" or "Your Boss." It proves nothing.

The only part that's harder to fake is the domain after the @. So train your eye to skip the friendly name and go straight to the actual address: PayPal Service <service@paypa1.com> → ignore "PayPal Service," read paypa1.com.

Anyone can register a domain and send "as" a company

There is no gatekeeper that stops someone from registering microsoft-support-team.com and sending email from it. Domains cost a few dollars. So an address can contain a brand name and still be controlled by a criminal. The brand name appearing in the address is not authentication — ownership of the real domain is (that's what VirusTotal/WHOIS confirm).

Sending services and "anonymous" email

Most companies don't run their own mail servers — they send through providers:

  • Email service providers (ESPs) for marketing/bulk mail: Mailchimp, SendGrid, Constant Contact, Klaviyo.
  • Mailbox providers anyone can sign up for: Gmail, Outlook.com, Zoho Mail, ProtonMail.
  • Business suites: Google Workspace and Microsoft 365 let any company (or scammer) send mail from their own domain through Google's or Microsoft's infrastructure.

Two consequences for you:

  1. "Sent via Google/Microsoft/SendGrid" is not a trust signal. Scammers buy these services too. A phishing email can be sent through Microsoft 365 or SendGrid and still be a scam — the infrastructure is legitimate, the sender isn't.
  2. Free mailboxes are a tell when the claim is corporate. A real bank or your real CEO does not email you from @gmail.com, @zohomail.com, or @outlook.com. A "Microsoft password reset" from a Gmail address is not from Microsoft, full stop.

(There's a deeper technical layer — SPF, DKIM, and DMARC — that lets mail systems check whether a message was really authorized by the domain it claims. It's worth knowing the names, but you don't need to read raw headers to be safe. The domain-plus-context habits below catch the large majority of attacks.)

Content vs. context — the universal test

This is the habit that ties everything together, and it works on email, texts, calls, and pop-ups alike.

  • Content = what the message says it is and what it's asking for — "Microsoft password reset," "your bank's fraud department," "an invoice from your vendor."
  • Context = everything around the message — who actually sent it (the real domain/number), the channel it came through, whether you were expecting it, and whether the ask makes sense.

Ask: does the content match the context? When they don't line up, it's almost always an attack.

Examples of a mismatch:

  • A Microsoft password-reset email — but the sender is a Gmail address. (Brand says Microsoft; context says some random person.)
  • Your bank's "fraud department" — but they called you and want you to read back a one-time code. (Banks never do that.)
  • An invoice from a vendor you use — but it's asking you to change the bank account payments go to. (Real, but the ask doesn't fit — verify out-of-band.)
  • A package delivery text — for a package you weren't expecting, with a link to a domain that isn't the carrier's.

The power of this test is that you don't need to be technical. You just need to notice when the story and the surroundings disagree. When they do: slow down, verify through a channel you trust (type the company's address yourself, call the number on your card), and don't act on the message in front of you.