How to Report Email Abuse: Spam, Phishing, Spoofing

Reporting abuse is one of the few things an ordinary recipient can do that actually changes the math for a spammer or a phisher. A complaint that lands in the right inbox - the network that hosts the sender, the mailbox provider whose users were targeted, or the body that takes down phishing sites - costs the abuser money, reputation, and infrastructure. A complaint that lands in the wrong inbox, or that strips out the evidence, does nothing. This page is about getting it right: what counts as abuse, how to find the real source from the headers, and exactly where to send the report by case.

If you came here to report something about Egressif’s own network, skip to “Reporting abuse involving Egressif”.

The 60-second version

• Don’t reply, don’t click, don’t open attachments. Engaging confirms your address is live and can be all the “consent” a scammer needs.
• Use your mailbox provider’s “Report spam” / “Report phishing” button first. It is the single highest-leverage action - it trains your provider’s filters and, through feedback loops, signals the sending side.
• Keep the original message and its full headers. Forwarding inline destroys the evidence. Forward as an attachment, or use “Show original” / “View source” and copy the raw message.
• Trace the source from the Received headers and Authentication-Results, then look up the sending IP’s network to find its abuse contact. The standardized role mailbox is abuse@ the responsible domain (RFC 2142).
• Route by case: the sending network’s abuse@ for spam; your mailbox provider’s button for filter training; reportphishing@apwg.org and your national authority for phishing; the brand’s security team for impersonation; a blocklist or host for takedown.
• Never redact the headers. Hide your own address in the body if you must, but the headers are the whole point.

What counts as abuse, and why reporting helps

“Abuse” is a broad term. The categories below overlap - one message can be several at once - but they route to different places, so it helps to name what you are looking at.

Type	What it is	Primary signal it sends
Spam	Unsolicited bulk email (UBE) - mail sent in bulk to people who never consented. Spamhaus defines spam as UBE and judges the sending, not the content.	Sending network’s abuse desk; your provider’s filters
Phishing	Mail that impersonates a trusted party to steal credentials, money, or data.	APWG; national authority; the impersonated brand
Spoofing	Forging the visible From: (or envelope) to look like a domain that did not send it. This is what SPF, DKIM, and DMARC exist to catch.	The spoofed domain’s owner; the sending network
Malware	Mail carrying a malicious attachment or a link to one.	National authority; the hosting provider; the sending network
Compromised accounts	A real account (yours or someone else’s) hijacked to send abuse. The “sender” is a victim too.	That account’s provider, so they can lock it and clean up

Reporting helps because email defenses are largely reputation- and complaint-driven. Mailbox providers weigh how their own users react to mail; complaint volume from an IP is given significant weight by receivers. Networks that host abuse get listed on blocklists, and a blocklist with broad reach (such as the Spamhaus lists) can cut off a spammer’s delivery entirely. A single report is a data point; many reports about the same source are a signal that systems and humans both act on. The corollary: an unreported abusive message is invisible to every one of those systems.

How to find the real source

You cannot report abuse usefully until you know where the message actually came from. The visible From: address is trivially forged; the authoritative trace lives in the headers. For a full walk-through of the header fields and the SMTP envelope, see the email headers and envelope guide - this section is the abuse-investigation subset.

Read the trace from the bottom up

Every MTA that handles a message prepends a Received: trace field (RFC 5321, “Trace Information”). The newest hop is at the top; the oldest is at the bottom. To find the origin, read upward from the bottom until you reach the first hop you trust - typically the boundary MTA operated by your own mailbox provider. Everything that machine recorded about the connection it accepted is reliable; everything below that line was written by machines you do not control and can be entirely fabricated.

Received: from mx.your-provider.example (mx.your-provider.example [198.51.100.10])
        by imap.your-provider.example with ESMTPS id abc123
        for <you@your-provider.example>; Tue, 16 Jun 2026 09:14:02 +0000
Received: from suspicious.host.example ([203.0.113.45])
        by mx.your-provider.example with ESMTP id def456;
        Tue, 16 Jun 2026 09:14:01 +0000

In that example, your provider’s mx.your-provider.example accepted the message from the IP 203.0.113.45. That IP - the one your trusted boundary saw connecting - is the sending IP, and it is what you trace. The hostname next to it (suspicious.host.example) is supplied by the sender and is only a hint.

Confirm with Authentication-Results

Your provider records its own authentication checks in an Authentication-Results: header (RFC 8601). It summarizes SPF, DKIM, and DMARC outcomes and the identifiers they validated:

Authentication-Results: mx.your-provider.example;
        spf=fail smtp.mailfrom=bounce.spammer.example;
        dkim=none;
        dmarc=fail (p=reject) header.from=yourbank.example

A dmarc=fail with header.from of a brand you recognize, alongside spf=fail and dkim=none, is the fingerprint of spoofing: someone sent mail claiming to be yourbank.example from infrastructure that domain never authorized. That tells you both who was impersonated (report to that brand) and that the envelope/connecting IP is the real lead.

Identify the network and its abuse contact

Once you have the sending IP, find the network responsible for it:

1. Look up the IP’s registration via WHOIS or its modern successor RDAP at the relevant Regional Internet Registry (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC). The record names the network, its Autonomous System Number (ASN), and a registered abuse contact (often an abuse-c or abuse-mailbox entry).
2. Use the abuse@ role mailbox. RFC 2142 standardizes abuse@ the organization’s domain for “inappropriate public behaviour,” and requires it to be valid for the top-level domain even when the offending customer uses a more specific hostname. So if the network’s domain is provider.example, abuse@provider.example is the standards-mandated destination - even if the spam came from shell1.provider.example.
3. Or let a clearinghouse find it for you. abuse.net (the Network Abuse Clearinghouse) is a contact-lookup service: give it a domain and it returns the abuse-reporting address others have researched for it. It is explicitly not a spam-reporting service or feedback loop - it just routes you to the right desk.

A caution: distinguish the sending network (who connected to deliver the mail) from the hosting network (where a link in the body points). Spam often comes from one network while advertising a site on another. Report each to its own responsible party.

Where to report, by case

Match the report to the party that can actually act. Most messages warrant more than one of these.

Case	Report to	Why it works
Spam from an identifiable source	The sending network’s abuse@ (RFC 2142), found via RDAP/WHOIS or abuse.net	The network can suspend the customer or close the relay.
Any spam/phishing you received	Your mailbox provider’s “Report spam” / “Report phishing” button	Trains your provider’s filters; via feedback loops (ARF) the report can reach the sending side.
Phishing	reportphishing@apwg.org (APWG), plus your national authority	APWG aggregates reports into the eCrime eXchange used by members to trace and take down phishing.
Phishing (UK)	NCSC Suspicious Email Reporting Service: forward to report@phishing.gov.uk	NCSC can investigate and remove scam addresses and websites; it acts on every message received.
Phishing / fraud (US)	The FTC at reportfraud.ftc.gov	The US consumer-protection reporting portal for scams and fraud.
Brand impersonation	The impersonated brand’s security/abuse team (often security@ or a published “report phishing” page)	Only the brand can issue takedowns for its own name and coordinate with registrars.
Spam source / abusive infrastructure	A blocklist operator such as Spamhaus	Broad-reach listings cut off the sender’s delivery across many receivers.
Malicious URL or host	The hosting provider’s abuse@, or a national takedown channel (e.g. NCSC’s suspicious-website report)	The host can remove the page; takedown kills the campaign’s payload.

Your mailbox provider’s button matters most

The “Report spam”/“Report phishing” control in Gmail, Outlook, Yahoo, Apple Mail, and others is not cosmetic. It feeds your provider’s own filtering, and many providers operate feedback loops (FBLs): when a user marks a message as spam, the provider sends a machine-readable complaint back to the sending operator in ARF format (RFC 5965). Legitimate senders use those reports to suppress complainers immediately - that is why honoring complaints is a reputation discipline, covered in suppression and consent. The point: clicking that button does more than file a personal complaint; it participates in the loop that disciplines the sending side.

Phishing gets escalated

Phishing is treated more seriously than ordinary spam because it causes direct loss. Forward phishing to APWG at reportphishing@apwg.org - APWG asks that you use “Forward as attachment” so the original headers and links survive for their members to trace. In parallel, report to your national authority: in the UK, forward to the NCSC’s Suspicious Email Reporting Service at report@phishing.gov.uk; in the US, file at the FTC’s reportfraud.ftc.gov. If you have actually lost money or been hacked, that is a crime to report to the relevant police/fraud body, not just an abuse desk.

Blocklists work differently than you may expect

You generally do not email a spam sample to a blocklist the way you email a network’s abuse desk. Operators like Spamhaus build listings primarily from spam traps and threat intelligence rather than ad-hoc public submissions. Spamhaus’s public-facing channels are its IP & Domain Reputation Checker and a contact form for queries and removals (with a separate Threat Intel Community submission path); see our Spamhaus blocklists reference for what each list catches. For the individual recipient, the higher-leverage move is your provider’s button and the sending network’s abuse desk; the blocklists pick up persistent sources on their own.

How to write a useful report

A good abuse report is judged on one thing: can the recipient act on it without writing back for more? Maximize that.

• Include the full, unmodified headers. This is the entire value of the report. The receiving abuse desk reconstructs the trace from your Received and Authentication-Results lines - so do not redact them. (You may redact your own address in the body if you wish; leave the headers intact.)
• Forward as an attachment, not inline. Inline forwarding rewrites headers and strips the envelope. Use “Forward as attachment,” or “Show original”/“View source” and paste the complete raw message (headers and body source).
• State the timestamp and time zone of receipt, and the recipient address that was targeted. The Received dates already carry this, but stating it removes ambiguity.
• Identify the specific evidence: the sending IP you traced, the malicious URL, and the impersonated brand or domain, if any.
• Use ARF where the destination supports it. The Abuse Reporting Format (RFC 5965) is the standardized, machine-readable complaint structure that feedback loops use. An ARF report is a multipart/report message with three required parts: a human-readable note, a message/feedback-report block of metadata, and the original message (or at least its headers). RFC 6650 recommends Feedback-Type: abuse for spam complaints and that, when known, you include Original-Mail-From, Arrival-Date, Source-IP, and Original-Rcpt-To. The metadata block looks like this:

Feedback-Type: abuse
User-Agent: SomeGenerator/1.0
Version: 1
Original-Mail-From: <somespammer@example.net>
Original-Rcpt-To: <user@example.com>
Arrival-Date: Thu, 8 Mar 2005 14:00:00 EDT
Reporting-MTA: dns; mail.example.com
Source-IP: 192.0.2.1
Authentication-Results: mail.example.com;
               spf=fail smtp.mail=somespammer@example.com
Reported-Domain: example.net
Reported-Uri: http://example.net/earn_money.html

Most individuals will never hand-assemble ARF - your provider’s “report spam” button generates it for you. The takeaway is what a useful report contains: the source IP, the envelope sender, the arrival time, the authentication results, and the original message. Provide those and any abuse desk can act.

What NOT to do

• Do not reply. A reply confirms a live, attentive human reads the address - the most valuable thing you can hand a spammer.
• Do not click links or open attachments, including “unsubscribe” links in mail you never subscribed to. On genuine, consented mail an unsubscribe is fine; on spam it is just another way to confirm your address (and may load malware).
• Do not engage with the sender, “scam-bait,” or try to investigate by visiting the linked site in a normal browser. Leave takedown to the host and the authorities.
• Do not forward inline or strip the headers. A report without intact headers is usually unactionable.
• Do not report to the wrong party. A blocklist is not a takedown service; abuse.net is not a complaint inbox. Match the report to who can act (the table above).

Reporting abuse involving Egressif

Egressif operates its own network and holds every sender on it to strict anti-abuse standards. If you have received email you believe violates our policies - spam, phishing, malware, or any other abuse - traced to our infrastructure, report it to us directly.

• Use the report-abuse form. It asks for exactly what makes a report actionable: the type of abuse, the offending sender and/or sending IP, the date and time received, and the full message headers. Provide the headers unredacted.
• Or email abuse@egressif.io and forward the offending message as an attachment with its headers intact (this is the RFC 2142 role mailbox for our domain).

What we do with reports: we investigate every one. Where a sender on our network has violated our acceptable-use policy, we take operational action - throttling, suspension, or termination - and confirmed abuse is suspended. We may forward reports to the responsible client as described in our Privacy Policy. We do not offer inbox-placement excuses for abuse: the standards on this page exist because the whole system depends on abuse being reported and acted on, and we hold our own network to that.

Common confusion

• “The From: address tells me who sent it.” No - it is trivially forged. The connecting IP recorded by your trusted boundary MTA in Received, confirmed by Authentication-Results, is the real lead.
• “I should reply and tell them to stop.” Never. Silence plus a report is the correct response; a reply just validates your address.
• “Reporting to a blocklist is how I report spam.” Mostly not. Blocklists build from traps and intelligence. Your provider’s button and the sending network’s abuse@ are the channels that take individual reports.
• “abuse@ won’t exist.” For any organization that exchanges mail with the Internet, RFC 2142 requires abuse@ its domain to be valid - even when the offending host has a more specific name.
• “I should clean up the headers before sending.” The opposite. Headers are the evidence; redact only your own address in the body if you must, never the trace.