How to tell if an email is spoofed, and what the headers can and cannot prove

An email arrives from your finance director asking for an urgent transfer, or from a supplier saying their bank details have changed. It looks right. Is it?

This kind of fraud, called business email compromise, is the most expensive crime reported to the FBI’s Internet Crime Complaint Center after investment fraud. Its 2025 report, published in April 2026, records 24,768 complaints and $3,046,598,558 in losses, up from 21,442 complaints and $2.77 billion in 2024. Phishing and spoofing was the most reported crime of all, with 191,561 complaints.

The email’s headers can answer one question well: did this message really come from the domain it shows? They cannot tell you whether the person behind it is who they claim. Knowing the difference is most of the skill.

Four ways an email can pretend to be someone

The checks the headers record (SPF, DKIM and DMARC) were designed for the second row only. The DMARC standard, RFC 9989, says so directly: DMARC “can only be used to combat specific forms of exact-domain spoofing directly”, and display name attacks “are out of scope for DMARC”. Microsoft’s anti-phishing documentation makes the same point about the third row: “Impersonation can pass email authentication checks (SPF, DKIM, and DMARC) if the attacker created a lookalike domain and published valid DNS records.”

Getting the headers

Every mail app hides them somewhere different: Show original in Gmail, File › Properties in classic Outlook, View › View message details in new Outlook and Outlook.com, View › Message › Raw Source in Apple Mail. The email header analyzer lists the steps for each app. Phone apps generally do not show full headers; open the message in a browser on a computer instead.

Headers contain email addresses, server names and IP addresses, so be careful about pasting them into online tools that upload what you give them. The Mailtria analyzer reads them in your browser and sends nothing anywhere.

What to read, in order

1. The verdict your own mail provider recorded

Near the top of the headers is a line called Authentication-Results, added by your mail provider when the message arrived. It records the three checks:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@supplier.com;
       spf=pass smtp.mailfrom=supplier.com;
       dmarc=pass (p=REJECT) header.from=supplier.com

The important result is dmarc, and the domain after header.from. A DMARC pass means the message was authenticated by SPF or DKIM for the same domain shown in the From line. A DMARC fail on a domain that publishes p=quarantine or p=reject means the domain’s owner says this message is not theirs.

Microsoft 365 and Outlook.com add their own summary, compauth (composite authentication), to the same line. compauth=pass means Microsoft judged the sender genuine for that domain; compauth=fail means it did not. Microsoft’s header reference lists the reason codes: 000 is an explicit DMARC failure on a domain with a quarantine or reject policy, 001 a failure Microsoft inferred itself.

Only trust the Authentication-Results line your own provider added: it names your provider’s server (mx.google.com, outlook.com, your company’s domain) at the start. Anyone can type a header that says dmarc=pass. The standard for this header, RFC 8601, requires receiving servers to delete copies that claim to be from them “to mitigate the impact of forged header fields”, but a line naming some other server is just text the sender may have written.

2. From, Reply-To and Return-Path

These three addresses should usually belong to the same organisation:

• From is what your mail app displays. The sender typed it.
• Reply-To, if present, is where your reply goes. A From at your supplier with a Reply-To at a free mailbox is the classic setup for invoice fraud: the fake looks right, and your answer goes to the attacker.
• Return-Path is where bounces go, the address SPF actually checks. Newsletter services and invoicing tools legitimately use their own domain here, so a difference alone is not suspicious. A difference combined with a failed DMARC check is.

Also read the display name itself. “Jane Smith <jane@yourcompany.com>” shown as a name can hide a different real address, and some attacks put a fake address inside the name: "jane@yourcompany.com" <x7@freemail.example>.

3. The Received lines, and where they stop being trustworthy

Each server that handles an email adds a Received line at the top. RFC 5321 requires each one to insert its record “at the beginning of the message content”, so reading from the bottom up gives the route.

But only the lines added by servers you trust are reliable: your own provider’s, at the top. Each server writes its own line and passes on whatever was below it untouched. A sender can start a message with any Received lines it likes, naming any servers and times, and every server after it will carry them along. Guides that tell you to find “the original sender” in the bottom Received line are telling you to trust the one line most easily faked.

What you can rely on is the line where your provider received the message: it records the IP address of the server that handed the message over. That server is real. It may belong to a big email provider, a hacked website or a rented server, which is useful to know but not an identity.

4. Location claims

Microsoft adds a spam report header with a CTRY value. Microsoft describes it as “the source country/region as determined by the connecting IP address, which might not be the same as the originating sending IP address.” For mail sent through Gmail, Outlook.com or any large provider, that is the provider’s data centre, not the sender’s location. Headers almost never reveal where a person is.

Labels your mail app adds

You do not always need the raw headers; mail apps surface some of this:

• Gmail “via”. Gmail shows “via” and a website name when “the domain it was sent from doesn’t match the domain in the ‘From:’ address”, which is normal for mail sent through newsletter and booking services, and a warning sign on mail from someone who should be emailing you directly.
• Outlook’s question mark. In Microsoft 365 and Outlook.com, a ? on the sender’s picture means the message did not pass SPF or DKIM, and did not pass DMARC or composite authentication. Outlook can also show “via” when the From domain differs from the DKIM or Return-Path domain. Administrators can turn both off, so their absence proves nothing.
• “You don’t often get email from…” Microsoft 365’s first contact safety tip, when your organisation has it turned on, appears the first time you get mail from an address or when you don’t often get mail from it. On an email from your “CEO”, it means the address is not the one your CEO normally uses.

When every check passes

A message from a lookalike domain or a hacked mailbox passes SPF, DKIM and DMARC, and its headers look normal. RFC 9989 is careful about what that means: “a DMARC pass by itself does not guarantee that delivery to the recipient’s inbox would be safe or desirable.” A pass proves the message came from the domain in the From line. It does not prove the domain is the one you think, or that the person typing is its owner.

So for lookalikes, read the domain letter by letter (rn for m, a digit 1 for a letter l, an extra word such as -invoices, a different ending such as .co instead of .com) and compare it with an older email you know is genuine. For hacked accounts, the headers will not help at all; the request itself is the clue.

The reverse also happens: genuine mail can fail. Forwarding and mailing lists often change messages in ways that break SPF or DKIM. ARC (RFC 8617) lets forwarding services vouch for what they received, but RFC 9989 notes that none of the fixes for mailing lists “have become widely used”. A DMARC failure on mail from a mailing list you joined is less alarming than one on a direct email from your bank.

If the email is about money

Any request to pay, change bank details, buy gift cards or send login details should be checked by a different route than the email, however clean the headers look. The FBI’s business email compromise notice advises: “Use secondary channels and/or two-factor authentication to verify requests for changes in account information.”

In practice: call the person on a number you already have, not one from the email or its signature; do not reply to the email to ask whether it is real; and if money has already been sent, contact your bank immediately and report it (in the US, to ic3.gov; elsewhere, to your national fraud reporting service).

Checking an email with Mailtria

Paste the headers into the email header analyzer, or drop a saved .eml file on it. It shows the SPF, DKIM, DMARC and Microsoft compauth results, points out a Reply-To or Return-Path that does not match the From line and a display name hiding a different address, lists every server on the route with the delay at each, and reads the spam scores Microsoft 365 and SpamAssassin add. It runs in your browser and does not upload what you paste.

It cannot tell you whether links or attachments are safe, and like any header tool it cannot catch a lookalike domain or a hacked account that passes every check. For those, the domain spelling and a phone call do the work. To check a domain’s own protection (whether it publishes a DMARC policy that lets receivers reject forgeries), use the SPF, DKIM and DMARC checker.

Sources

• FBI Internet Crime Complaint Center: 2025 IC3 Report, Business Email Compromise: The $55 Billion Scam (11 September 2024).
• IETF: RFC 9989 (DMARC), RFC 8601 (Authentication-Results), RFC 5321 (SMTP), RFC 8617 (ARC).
• Microsoft Learn: Anti-phishing policies, Anti-spam message headers.
• Google Gmail Help: Extra info next to sender’s name.