How to Trace, Report Spoofed/Phishing Emails (With Example)

Infopackets Reader 'Oadby' writes:

" Dear Dennis,

I recently received a spoofed phishing email from my own email address. But Outlook won't let me report it as it thinks it's from me! Is there a way to report them? I know it's probably useless but I try to do my bit. Also, why don't email programs and services provide a simple way to see where an email has originally come from in order to prevent spoofing? "

My response:

Thanks for your message - I'll explain how to report a spoofed or phishing email below - but first, let's understand what some of the terminology means for those who might not know.

Spoofed Email vs Phishing Email: What's the Difference?

Spoofed Email: A spoofed email is one where the sender's address has been forged to appear as if it came from someone else - often your own address or a trusted contact. The goal is to trick the recipient by faking the sender's identity.

Phishing Email: A phishing email is a type of scam designed to steal sensitive information (like passwords or credit card numbers). It often includes spoofed sender info, fake login pages, or urgent messages to provoke action.

In short: spoofing is the disguise - phishing is the scam.

How to Report a Spoofed or Phishing Email

One of the most reliable ways to report a spoofed or phishing email is to:

1. enable email headers using your email program
2. review the email with full email headers enabled
3. look at the received: headers to determine the email's origin
4. use WHOIS to look up the origin IP address
5. send an email to the abuse team associated with the IP's organization

I will explain in detail below.

How to View Email Headers

Enabling the view of full email headers depends on your email service or program (i.e., gmail or Thunderbird).

It is recommended to search Google to learn how to view full email headers for your specific instance, as it is typically not enabled by default. For example: in Thunderbird, you can view full email headers by clicking View -> Headers -> All, then you can forward the message and it will show the full email headers and original email all in one window. You can use the new composition to send your email complaint. I'll explain how to do that further down.

Note that you MUST include the full email headers when emailing your complaint, otherwise the report will not be complete because the origin IP address is missing, and therefore you would be wasting your time.

Email Header Example

Assuming you've enabled full email headers with your dedicated email program or service, it's time to review the received: headers.

In the below fake email example, the origin IP's received header (in blue) does not contain any information about the IP address's organization (i.e., it did not include reverse DNS information in the headers). Therefore, you will need to do a WHOIS lookup on the IP to determine which organization owns the IP, then send the abuse report there.

Return-Path: <security-alert@paypal.com>
Received: from mail-relay2.mailhost.net (mail-relay2.mailhost.net. [198.51.100.73])
        by mx.google.com with ESMTPS id x7si1234567qkb.123.2025.03.27.12.01.23
        for <you@example.com>;
        Wed, 27 Mar 2025 12:01:23 -0700 (PDT)
Received: from mail-outgoing1.fakeisp.com (mail-outgoing1.fakeisp.com. [192.0.2.44])
        by mail-relay2.mailhost.net with ESMTP id abc987654321
        for <you@example.com>;
        Wed, 27 Mar 2025 11:59:11 -0700
Received: from user-laptop.example (unknown [143.210.250.100])
        by mail-outgoing1.fakeisp.com with ESMTPA
        id m0123456;
        Wed, 27 Mar 2025 11:58:01 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=fakepaypal.com; s=selector1;
        h=from:to:subject:date:message-id;
        bh=FakeSignatureHashHere=;
        b=FakeSignatureBlockHere
Received-SPF: None (google.com: domain of security-alert@paypal.com does not designate permitted sender hosts)
Authentication-Results: mx.google.com;
        dkim=fail header.i=@fakepaypal.com;
        spf=fail (google.com: domain of security-alert@paypal.com does not designate 198.51.100.73 as permitted sender)
From: PayPal Security <security-alert@paypal.com>
To: you@example.com
Subject: Urgent: Your Account Has Been Suspended - Verify Now
Date: Wed, 27 Mar 2025 11:58:00 -0700
Message-ID: <fake-msg-id-123456@fakepaypal.com>
MIME-Version: 1.0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<html>
<body>
<p>Dear Customer,</p>
<p>We've noticed unusual activity in your account and have temporarily suspended it for your protection.</p>
<p><a href="http://fake-verification-link.example.com">Click here to verify your identity</a> and restore access.</p>
<p>Thank you for choosing PayPal.</p>
</body>
</html>

How to Read Email Headers to Determine Sender Origin

1. From the email example above, I've snipped only the received: headers:
   
   Return-Path: <security-alert[at]paypal.com>
   Received: from mail-relay2.mailhost.net (mail-relay2.mailhost.net. [198.51.100.73])
           by mx.google.com with ESMTPS id x7si1234567qkb.123.2025.03.27.12.01.23
           for <you[at]example.com>;
           Wed, 27 Mar 2025 12:01:23 -0700 (PDT)
   Received: from mail-outgoing1.fakeisp.com (mail-outgoing1.fakeisp.com. [192.0.2.44])
           by mail-relay2.mailhost.net with ESMTP id abc987654321
           for <you[at]example.com>;
           Wed, 27 Mar 2025 11:59:11 -0700
   Received: from user-laptop.example (unknown [143.210.250.100])
           by mail-outgoing1.fakeisp.com with ESMTPA
           id m0123456;
           Wed, 27 Mar 2025 11:58:01 -0700
   
   Note that email headers are read from bottom up as they hop their way through the Internet, per email header protocol standards.
    
2. Where you see the part Received: from user-laptop.example (unknown [143.210.250.100]) - this is the sender's IP address - typically their home or office connection. This IP was not resolved because the sending IP did not contain a reverse DNS record and was not included in the header.
    
3. The middle hop Received: from mail-outgoing1.fakeisp.com (mail-outgoing1.fakeisp.com. [192.0.2.44]) is the sender's outgoing SMTP server and the organization's name is fakeisp.com.
    
4. The final hop Received: from mail-relay2.mailhost.net (mail-relay2.mailhost.net. [198.51.100.73]) is a relay or spam filtering service that handed the message off to the recipient's mail server (mx.google.com in this case).

Putting it all together: the email was sent from 143.210.250.100 (most likely a PC), then received by an email server associated with that IP address's organization (in this case, mail-outgoing1.fakeisp.com), then delivered to the destination at mail-relay2.mailhost.net.

How to Use WHOIS to Determine Organization of Sending IP

Now that we know where the email originated from (143.210.250.100 per the example), it's time to use a WHOIS Lookup service to find out more information about its organization so that we can make a formal complaint.

To lookup the IP address, use ARIN for North American based IPs, RIPE for Europe, Middle East, Central Asia, APNIC for Asia Pacific, and LACNIC for Latin America and parts of Caribbean, and AFRINIC for Africa. You can also search google for another generic WHOIS lookup which may combine any of the major registries I just mentioned.

Note that depending on the origin of the IP, the WHOIS lookup service may not be complete. For example, I used ARIN to lookup 143.210.250.100 and it gave me the following:

Address:             143.210.250.100
NetRange:            143.210.0.0 - 143.210.255.255
CIDR:                143.210.0.0/16
NetName:             RIPE-ERX-143-210-0-0
NetHandle:           NET-143-210-0-0-1
Parent:              NET143 (NET-143-0-0-0-0)
NetType:             Early Registrations, Transferred to RIPE NCC
Organization:        RIPE Network Coordination Centre (RIPE)
RegDate:             2003-11-12
Updated:             2025-02-10

Where it says: NetType: Early Registrations, Transferred to RIPE NCC - this means you need to use RIPE WHOIS to do the proper lookup, which yields:

NetRange:       143.210.0.0 - 143.210.255.255
CIDR:           143.210.0.0/16
NetName:        LEICESTER-NET
Organization:   University of Leicester (UNILEI)
RegDate:        1990-06-20
Updated:        2010-06-15
Ref:            https://rdap.arin.net/registry/ip/143.210.250.100

OrgName:        University of Leicester
OrgId:          UNILEI
Address:        IT Services
                University Road
City:           Leicester
StateProv:      Leicestershire
PostalCode:     LE1 7RH
Country:        GB
Phone:          +44 116 252 2415
Email:          abuse [at] le.ac.uk
Updated:        2023-05-04
Ref:            https://rdap.arin.net/registry/entity/UNILEI

Based on the WHOIS lookup above and the IP 143.210.250.100, we can see that it is registered to the University of Leicester. Looking further into the WHOIS information, we see an abuse contact: abuse [at] le.ac.uk. In this case, forward the email with full email headers to that email address with subject "ATTN ADMIN - SPAMMER ON YOUR NETWORK" to complete the complaint report.

Why Does the Email Say It's From Me When It's Not?

In spoofing cases, the email can appear to come 'from you' because your address was forged (faked) in the 'From' field. The real sender can only be identified through header analysis as I suggested above.

This is allowed to happen because in the very early days of the Internet, spam and spoofing wasn't a concern when email protocols were established. That's why DKIM, SPF, and reverse DNS are now used in the majority of email headers on modern day email servers, so that you can identify the true origin, and so that the final receiving MTA (mail transport agent) can determine how to handle it (i.e.: mark it as spam, greylist it, accept, or deny it).

Why Don't They Make It Easier to Report a Spoofed or Phishing Email?

Based on the number of steps I've outlined, you can see that making a formal complaint requires some effort and understanding. This is why reporting spoofed emails or phishing emails is generally not automated in this manner and also why most people don't do it.

Furthermore, most organizations online don't care about spoofing / spam complaints unless the email came from a hosted server or hosted site, which are rented services. In this case, if enough spam complaints were levied, word would get out that the hosting service is not reliable and customers wouldn't rent their services. As such, the hosting company would take action.

Also, as I've already mentioned: almost all modern email servers today use DKIM (domain keys), SPF (sender policy framework) and reverse DNS to authenticate emails. ChatGPT (artificial intelligence) estimates that 80 to 95% of spam is rejected using these methods.

I hope that helps.

Got More Tech Questions? Ask Dennis!

I can fix most problems remotely using my remote desktop support. Or, if you have a simple tech question you'd like me to answer like the one above, send me an email through the contact page and I'll consider writing an article about it.

About the author: Dennis Faas is the CEO and owner of Infopackets.com. Since 2001, Dennis has dedicated his entire professional career helping others with technology-related issues with his unique style of writing in the form of questions-and-answers; click here to read all 2,000+ of Dennis' articles online this site. In 2014, Dennis shifted his focus to cyber crime mitigation, including technical support fraud and in 2019, online blackmail. Dennis has received many accolades during his tenure: click here to view Dennis' credentials online DennisFaas.com; click here to see Dennis' Bachelor's Degree in Computer Science (1999); click here to read an article written about Dennis by Alan Gardyne of Associate Programs (2003). And finally, click here to view a recommendation for Dennis' services from the University of Florida (dated 2006).