How can I identify the ESP used to send a spam email using the email headers?
Updated on 16 Oct 2026: We corrected the header example and added Gmail and Outlook steps, clearer attribution checks, and guidance for forwarded mail.
You can often identify the email service provider (ESP) used to send a spam email by reading the full email headers, starting with the Received line added at your mailbox provider's external trust boundary. Match the connecting IP, reverse DNS, HELO name, Return-Path, SPF domain, DKIM signing domain, Message-ID, and any platform-specific X headers. The answer is usually a confidence call, not a single field called ESP.
The visible From name is weak evidence for identifying an ESP. A spam message can say it came from a known brand while the actual transport path points to a shared ESP, a compromised mailbox, a cloud server, a reseller, or a private mail server. The headers show the handoff path. The body shows what the sender wanted you to believe.
Do not click links, open attachments, or reply to the message while investigating it. Work from the raw source or original headers. Keep an unmodified original privately. Redact personal addresses, tokens, and internal hostnames in any public copy; redaction can invalidate DKIM verification.
- Safe copy: Export the original message or copy the raw headers before forwarding.
- Bad evidence: Screenshots of the inbox rarely show the routing fields needed for attribution.
- Scope check: One message can identify a likely sender, but several samples give better proof.
Open the full email headers in Gmail or Outlook
Use the message source or internet headers, rather than the sender details displayed above the message body.
- In Gmail on the web, open the message, select More beside Reply, then Show original. Use Copy to clipboard for the headers or Download original to preserve the message.
- In new Outlook, Outlook.com or Outlook on the web, open More actions, then View > View message details. In classic Outlook for Windows, open the message in its own window, then select File > Properties and copy Internet headers.
Save an original .eml file when available. The full headers end at the first blank line; keep the complete message privately if signature verification is needed.
Start with the trusted Received chain
The most useful place to start is the Received line at your mail system's external trust boundary. Email servers prepend Received lines, so the top of the header is the most recent handoff, but the first few lines can describe internal processing by your mailbox provider. Start at the top, skip those trusted internal hops, and find the line where your provider recorded the external host and IP that connected to it.
Treat lower Received lines outside that trust boundary as unverified unless independent logs or another trusted system corroborate them. Lower Received lines were added earlier and can be forged by the sender before the message hit the first real server. Consistent-looking hostnames and timestamps do not make those lower lines trustworthy. The connecting IP is receiver-observed, but the HELO or EHLO name is supplied by the connecting server.
Header fields that mattertext
Authentication-Results: mx.receiver.example; spf=pass smtp.mailfrom=bounce.sender.example; dkim=pass header.d=sender.example; dmarc=fail header.from=brand.example Received: from mta-12.sender.example (mta-12.sender.example [203.0.113.25]) by mx.receiver.example with ESMTPS id abc123 for <you@receiver.example>; Thu, 14 May 2026 10:15:02 +0000 Return-Path: <bounce-123@bounce.sender.example> From: Example brand <offers@brand.example> Message-ID: <abc123@mta.sender.example>
These are illustrative headers using reserved example domains and a documentation IP address. SPF and DKIM pass for sender.example domains, but neither authenticated domain matches the visible From domain, brand.example, so DMARC fails. The example identifies a transport path, not a real ESP.
- Trusted boundary: Find the Received line where your receiving system accepted the message from an external host.
- Connecting IP: Identify who operates the IP range, then compare that with reverse DNS and HELO.
- Envelope sender: Use Return-Path and SPF mailfrom to see the bounce domain used during SMTP.
- Signing domain: Use a trusted dkim=pass result and header.d to identify the verified signing domain.
- Message IDs: Compare Message-ID and X headers with the hostnames in the Received chain.
Gmail Show original email headers with SPF, DKIM and DMARC results.
Read authentication clues together
Authentication-Results summarizes the checks, but it needs a trusted source. A message can contain several copies, including a forged one added before delivery. Use results known to have been added by your receiver or another trusted system. A matching authserv-id name alone is insufficient because that name can also be forged. SPF can pass for a bounce domain that belongs to a platform, DKIM can pass for a brand domain that was authorized to sign through a vendor, and DMARC requires at least one passing SPF or DKIM identity to match the visible From domain under its strict or relaxed domain-matching rules. Authentication does not establish consent or message safety.
|
|
|
|---|---|---|
Received connecting IP | High for SMTP peer | The external IP observed by your receiver; the HELO/EHLO hostname is a separate, sender-supplied claim. |
IP owner | High for network | The network operating the sending range, which can differ from the ESP. |
Return-Path | Medium | The envelope sender recorded at final delivery. Compare with trusted SPF smtp.mailfrom results because forwarding can rewrite it. |
Verified DKIM domain | Medium for ESP identity | A trusted dkim=pass result verifies the signing domain, which can belong to the brand or platform. |
X-Mailer and other X headers | Low alone | Optional markers that can name sending software or a platform, but are easy to copy or forge. |
List-Unsubscribe | Low alone | The hostname in an unsubscribe URL or mailto address can suggest a platform. Inspect the text without opening the link. |
Display From | Low | Branding in the message, often unrelated to transport. |
Header evidence to compare before naming an ESP.
Strong signals
- IP match: The connecting IP belongs to a sending network and matches reverse DNS.
- Matching evidence: The observed IP and independently verified links between the platform and authenticated domains support the same attribution.
- Repeat samples: Several messages use the same hostnames, IP ranges, and signature patterns.
Weak signals
- Brand name: A logo, display name, or subject line can be copied without using the brand's ESP.
- Old headers: Lower Received lines can be forged before the first legitimate handoff.
- One field: A single DKIM or Message-ID clue is useful, but rarely enough by itself.
If the suspicious message claims to be from a domain you manage, Suped's domain health check validates published authentication records. DNS configuration alone cannot prove which account sent a particular message or whether that message passed authentication.
A passing DKIM signature does not always name the ESP. If header.d matches the brand domain, the ESP can be behind delegated DKIM keys. If header.d matches a platform domain, it can indicate default signing rather than branded signing.
For a signature confirmed as passing, read d= (signing domain) and s= (selector) in DKIM-Signature. Query DNS at <selector>._domainkey.<signing-domain>; a CNAME target can provide another platform clue. A selector name alone is not proof, and current DNS does not necessarily show the configuration at delivery time.
Use IP and DNS evidence carefully
The connecting IP is usually the cleanest technical lead. Compare IP registration through RDAP or WHOIS with the ASN, PTR record, forward DNS, HELO name, and surrounding IP range. A PTR name that resolves forward to the same IP adds consistency, a pattern often called forward-confirmed reverse DNS. These checks support infrastructure attribution; they do not identify the sender's physical location or prove an ESP by themselves. If they conflict, the message might have come through a reseller, a compromised host, or a generic mail server.
Blocklist (blacklist) evidence is useful, but it is not identity proof. A blocklist or blacklist hit means the IP meets that list operator's listing criteria. It does not prove which ESP accepted the customer, which account sent the message, or whether the platform was abused. For ongoing listing visibility, Suped's blocklist monitoring tracks listing changes rather than establishing sender identity.
ESP confidence from headers
Judge the trustworthiness and independence of the evidence rather than counting matching fields.
High confidence
Corroborated platform
The receiver-observed IP is corroborated by independently verified platform domains or infrastructure records.
Medium confidence
Likely platform
The connecting network is known, but custom domains, shared infrastructure or forwarding leave the platform uncertain.
Low confidence
Unverified platform
Only sender-controlled names or headers suggest a platform, without independent corroboration.
Email header analysis workflow for finding the sending IP and likely ESP.
Name the ESP when trusted connection data and independently verified platform evidence support the attribution; custom domains do not need to share the ESP's name. If they do not agree, write the finding as a likely source and preserve the exact fields that support it.
Separate the ESP from the network operator
An IP registration or ASN identifies the organization responsible for the network range. That organization can be a cloud host, transit provider, parent company, reseller, or ESP. Reverse DNS can narrow the role, but a generic infrastructure hostname still proves only which network carried the SMTP connection.
Only the network is confirmed
The IP registration and PTR record identify the infrastructure operator, but the bounce domain, DKIM signer, Message-ID, and X headers do not identify a sending platform. Record that the message was delivered from infrastructure operated by the named organization. Do not label that organization as the ESP.
The ESP is supported
The network evidence is backed by a platform-linked bounce domain, DKIM pattern, Message-ID format, X header, or repeated samples. Record the platform as the likely ESP and retain each field used to reach that conclusion.
Headers rarely identify the individual customer or account behind the message. Shared IP pools and white-label domains can hide that layer. The ESP's abuse team can use the IP, envelope sender, Message-ID and available queue identifiers to search internal logs. Include the delivery timestamp and time zone from the trusted Received line, rather than relying on the sender-controlled Date field.
When headers are not enough
Some messages do not expose a clear ESP. That does not mean the analysis failed. It means the evidence points to a sender type rather than a named platform. A compromised mailbox can pass DKIM for the real mailbox provider. A reseller can hide the upstream ESP. A private MTA can look like a small business mail server. Forwarding can add extra hops and Authentication-Results fields that make the original path harder to read.
- Compromised account: The message can authenticate because the attacker used a real account.
- White label sender: The visible hostname can name a customer domain while the ESP runs the backend.
- Forwarded mail: Forwarding systems add their own Received lines and can break SPF at the final hop. With Sender Rewriting Scheme (SRS), Return-Path can identify the forwarder instead of the original sender.
- Forged chain: Older Received lines can be planted to make a message look like it used a brand.
If mail passed through a forwarder, the connecting IP identifies that forwarder. Authenticated Received Chain (ARC) can preserve earlier authentication assessments, but only use them when your receiver validates the chain and trusts the intermediary. ARC does not prove that a particular ESP originated the message.
For a domain you control, send a known legitimate message through the same sending service into Suped's email tester and compare its headers with the suspicious sample. This creates a baseline for that service's Return-Path, DKIM signer, and routing pattern.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A different route is a lead for further checks, not proof of spoofing: a domain can use several authorized platforms. Compare against your sender inventory and authentication results before drawing a conclusion.
Use Suped to investigate sources sending for your domain
Manual header analysis answers one message at a time. For domains you manage, Suped's DMARC monitoring groups aggregate reports by sending source so you can compare reported IPs and authentication results with your header findings.
Aggregate reports cover traffic reported by participating receivers for your domains. They are not a complete inbound spam feed or an account directory, and a passing result does not establish that your organization approved the sender. Use Suped's source and issue views to check a source against your authorized sender inventory and investigate failures.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
- Source mapping: Compare reported sending sources with the services your organization has authorized.
- Issue detection: Get practical fixes for SPF, DKIM, DMARC, and source matching problems.
- Policy staging: Move DMARC policy carefully while monitoring failures and real traffic.
- MSP workflow: Manage many domains, clients, alerts, and reports in one place.
Views from the trenches
Best practices
Use the Received line at your receiver's external trust boundary as the first reliable evidence.
Compare IP ownership, reverse DNS, DKIM signer, and Return-Path before naming an ESP.
Save the raw original message before forwarding, because clients often remove useful headers.
Common pitfalls
Do not trust display names or brand logos; they are content, not authentication evidence.
Do not assume a passing DKIM domain names the sending platform; it can name the brand.
Do not treat a blacklist or blocklist hit as proof of the ESP without header evidence.
Expert tips
Look for reseller or white-label patterns when the IP owner differs from the visible host.
Use multiple samples when available, because one message can hide a normal shared pool.
Record the specific header fields used for attribution so the finding can be checked.
Marketer view
Marketer from Email Geeks says the quickest first step is to open the original message and inspect the full header set, because the visible inbox view hides the routing evidence.
2022-02-17 - Email Geeks
Marketer view
Marketer from Email Geeks says IP-based lookups can help when headers are sparse, especially when several spamtrap samples point to the same sending range.
2022-02-18 - Email Geeks
Document and report the suspected sending source
Record the likely ESP or confirmed network, the exact fields supporting the finding, and any gaps in the evidence. Find the suspected provider's abuse contact independently through its official website or network registration, rather than using Reply-To or a contact supplied by the suspicious message.
Preserve the original privately and submit relevant evidence directly to the verified abuse channel, stating whether the ESP identification is confirmed or tentative. For a domain you own, do the bigger fix as well: monitor authorized senders, investigate unknown sources before changing permissions, and strengthen DMARC policy after checking legitimate traffic and forwarding paths.
- Open original: Get the raw headers, not a forwarded copy or inbox screenshot.
- Find the boundary: Use the Received line where your provider accepted the external connection.
- Compare fields: Match IP, DNS, SPF, DKIM, DMARC, and bounce domains.
- Separate roles: Record which evidence identifies the network and which evidence identifies the ESP.
- State confidence: Use clear wording if the ESP is likely rather than proven.
Frequently asked questions
No. The visible From address is easy to spoof. Use the Received chain, connecting IP, Return-Path, SPF, DKIM, and DMARC results instead.
The Received line at your mailbox provider's external trust boundary is usually the strongest starting point because it records the remote host and IP that delivered the message.
No. The IP owner can be a cloud network, parent company, reseller, or transit provider. Confirm the ESP with bounce domains, DKIM patterns, Message-ID formats, X headers, or repeated samples.
Yes. A sender can pass SPF or DKIM using its own domain, an authorized sending platform, or a compromised account. DMARC requires at least one passing identity to match the visible From domain under the applicable rules. Even DMARC-passing mail can be spam; authentication does not prove consent or safety.
The message might come through a reseller, a white-label setup, forwarding, a private mail server, or a compromised account. In those cases, record the likely source and the supporting evidence.
Report suspected abuse through the provider's independently verified abuse channel. Include the original headers, connecting IP, trusted delivery timestamp with its time zone, Message-ID, and the fields supporting the attribution. State any uncertainty rather than presenting a likely ESP as proven.
