How to determine an email sending platform from email headers or server information?
Matthew Whittaker
Co-founder & CTO, Suped
Published 6 May 2025
Updated 14 May 2026
11 min read
The direct answer: you can often determine the email sending platform by combining full message headers, SMTP server banners, reverse DNS, SPF includes, DKIM selectors, List-Unsubscribe domains, bounce paths, and DMARC aggregate data. A single clue rarely proves it. A full header plus DNS evidence usually gets you to one of four outcomes: a named ESP, a named MTA, a cloud or hosting provider running a custom MTA, or an internal relay that hides the real sending stack.
The fastest workflow is simple: get the original message, read the full headers from bottom to top, identify the first public sending IP, inspect the authentication results, then compare the return-path, DKIM d= domain, SPF include, and visible SMTP banner. If the IP belongs to Rackspace, AWS, Azure, Google Cloud, or another host, that tells you where the server runs, not necessarily which sending software is behind it.
I treat email platform identification as evidence grading. A DKIM domain that belongs to a known ESP is strong evidence. An SMTP banner that says Postfix or PowerMTA is useful evidence. A List-Unsubscribe local part with random tokens is weak evidence, because most platforms let senders customize that format. A hosted IP range by itself is weak evidence, because many self-hosted MTAs sit on rented infrastructure.
Start with the full original headers
Partial headers are usually the reason people misidentify a sending platform. The useful clues are spread across multiple fields, and some mailbox apps hide the ones that matter. Ask for the original message source, not a screenshot, forwarded email, or copied top section. A forwarded email often replaces the transport evidence with the forwarder's own headers.
Full source: Use the complete raw message, including every Received line, Authentication-Results field, Return-Path, DKIM-Signature, Message-ID, and unsubscribe header.
First public hop: Read Received lines from bottom to top and find the first public IP that handed mail into the recipient's mail system.
Authentication chain: Compare SPF, DKIM, and DMARC results instead of trusting the visible From address.
Domain ownership: Separate customer-controlled domains from vendor-controlled domains in bounce, DKIM, tracking, and unsubscribe fields.
A hosting provider is not always the email platform
If the sending IP maps to Rackspace, that only proves Rackspace hosted the server or network path at that point. The actual software could still be Postfix, PowerMTA, GreenArrow, Haraka, Exim, a custom MTA, or a commercial ESP that used that infrastructure. Treat IP ownership as one clue, not the answer.
For a quick sanity check, send a fresh message into Suped's email tester. It gives you the message source, authentication result, and delivery clues in one place so you can avoid manually copying headers between tools.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
How to read the Received chain
The Received chain is the routing log. Each mail server adds a new Received header at the top as it accepts the message. That means the oldest useful hop is usually near the bottom, just above headers created by the sending application. The newest hops are near the top and usually belong to the recipient mailbox provider or filtering service.
Simplified Received chaintext
Received: from inbound-filter.example.net by mx.recipient.tld;
Received: from mta1.sender-host.tld (203.0.113.25) by inbound-filter;
Received: from app.internal by mta1.sender-host.tld;
DKIM-Signature: v=1; a=rsa-sha256; d=news.example.com; s=s1;
In that example, the useful public sending system is mta1.sender-host.tld at 203.0.113.25. The internal app line tells you there was an application or relay before the MTA, but it usually does not prove which platform sent the mail. The DKIM d= domain can help because vendors often use their own signing domain or require a delegated customer subdomain.
Field
What to inspect
Strength
Received
First public IP, HELO name, relay path
High
DKIM
Signing domain and selector
High
SPF
Return-path domain and includes
Medium
Message-ID
Domain, generator pattern
Medium
List-Unsub
Mailto or HTTPS domain
Low
Header fields that help identify the sending platform
A good header review also separates inbound and outbound evidence. Recipient-side filters add fields such as X-Microsoft-Antispam, ARC-Seal, spam scores, and internal routing IDs. Those tell you what happened after delivery into the receiving system. They do not identify the sender's email platform unless they reference the connecting IP, HELO, or authentication domain.
Flowchart showing the process for identifying a sender from raw headers.
Check the SMTP banner when it is safe
Many mail servers identify themselves when you connect to port 25 and issue an EHLO command. This is the traditional SMTP diagnostic method. It can reveal software names such as Postfix, Exim, Microsoft ESMTP MAIL Service, or a vendor-specific banner. It can also reveal nothing useful, because operators can hide or customize banners.
The banner line in that example gives a direct software clue: Postfix. The EHLO capability list adds supporting detail, but the feature set is not unique enough to identify a platform by itself. Many MTAs advertise STARTTLS, PIPELINING, SIZE, and 8BITMIME.
What banners can prove
Software clue: A banner can disclose Postfix, Exim, Microsoft, Sendmail, or another MTA.
Hostname clue: The greeting can expose a vendor, tenant, or internal naming pattern.
TLS clue: STARTTLS support and certificates can confirm server identity.
What banners cannot prove
Outbound access: The sending IP does not always accept inbound SMTP.
Exact ESP: A self-hosted MTA can sit behind an ESP-like application layer.
Truthfulness: Administrators can change, suppress, or genericize banners.
Do this only against systems you are allowed to test, and keep the session to a normal SMTP greeting. You do not need to send a message, test relay behavior, or probe recipient addresses. The goal is to read the greeting and capabilities, then disconnect cleanly.
Use SPF, DKIM, and DMARC evidence
Authentication data is often cleaner than server banners. SPF tells you which hosts are authorized to send for the return-path domain. DKIM tells you which domain signed the message. DMARC tells you whether the visible From domain matched SPF or DKIM. Together, they show whether the sender is using a recognizable service, a delegated subdomain, or a self-managed system.
If SPF passes through a vendor include and DKIM signs with a vendor-managed subdomain, the platform is usually clear. If SPF passes through a customer domain and DKIM signs with the customer's own domain, you need the DNS record behind the selector and the sending IP evidence to decide whether the sender is self-hosted or using a white-labeled service.
Where Suped fits in this workflow
Suped is useful when you need to move from one suspicious message to ongoing domain visibility. Suped's DMARC monitoring groups sending sources, highlights SPF and DKIM failures, and shows which services are sending mail for your domain. That makes platform identification less dependent on one header sample.
A focused DKIM checker helps when the selector is visible but you need to inspect the public key, tag values, and whether the DNS record is valid. For broader authentication health, use a domain health check to review DMARC, SPF, and DKIM together.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Decode common platform clues
Some clues carry more weight than others. I would not identify a platform from a single List-Unsubscribe value such as a long random local part at m1.example.com. That format means the sender has an unsubscribe mailbox or tokenized address. It does not prove which software generated it, because list management software, campaign tools, and custom code can all create similar addresses.
Clue
Likely meaning
Risk
Vendor DKIM
Known ESP or delegated signer
Low
Cloud IP
Hosted server or relay
High
MTA banner
Server software family
Medium
Custom Message-ID
App or MTA fingerprint
Medium
List-Unsub
Mailing system behavior
High
Common clues and what they usually mean
A strong match usually has at least two independent signals. For example, a Received line points to a vendor hostname, SPF includes the same vendor, and DKIM signs with a matching delegated domain. A weak match has only one cosmetic pattern, such as an unsubscribe address format or a tracking domain that resembles a vendor naming style.
Confidence bands for platform identification
Use evidence count and quality to decide how strongly to name the sending platform.
Low confidence
1 clue
One cosmetic clue, such as an unsubscribe token or tracking hostname.
Medium confidence
2 clues
A server banner or IP owner points to a likely MTA or hosting provider.
High confidence
3+ clues
Headers, DNS, and authentication domains point to the same platform.
This is also where blacklist and blocklist checks help. If the sending IP or domain has a reputation issue, that will not identify the sending software, but it explains why the message looks risky and whether the platform is harming delivery. Suped's blocklist monitoring ties those listings to the domains and sources you monitor, which is more useful than checking one IP once.
When headers point to self-hosted email
Self-hosted email sending usually has a few patterns: cloud or leased infrastructure, generic reverse DNS, customer-owned bounce domains, custom unsubscribe addresses, and MTA banners that expose a software package instead of a commercial ESP. That does not mean the system is bad. It means the sender owns more of the operational burden.
Managed sending platform
DNS pattern: Vendor includes, delegated DKIM, and branded bounce domains.
Headers: Vendor hostnames or consistent product-specific routing IDs.
Operations: Shared tooling for bounces, complaints, unsubscribe, and suppression.
Self-hosted MTA
DNS pattern: Customer SPF, customer DKIM, and manually managed return paths.
Headers: Postfix, Exim, PowerMTA, GreenArrow, or custom hostnames.
Operations: Sender manages warmup, bounces, queues, reputation, and compliance.
Self-hosting makes identification harder because the sender can mix components. The application can be custom, the MTA can be PowerMTA or Postfix, the IPs can sit at Rackspace, and the DNS can be fully branded under the sender's domain. In that case, the honest conclusion is "custom sending stack" unless a banner, record, or vendor-owned domain proves more.
The better operational question is often: "Which sources are authorized, which are authenticated, and which have reputation problems?" Suped answers that through DMARC reports, SPF and DKIM diagnostics, real-time alerts, hosted SPF, hosted DMARC, and blocklist or blacklist monitoring. That matters when the goal is fixing delivery rather than winning a header guessing game.
Do not overread List-Unsubscribe
List-Unsubscribe is valuable for compliance and mailbox provider handling, but it is a poor platform fingerprint by itself. A tokenized mailto address like rkiaa41hLyvquY.hLxku5hgkm.xb961.gcvhzd3.t16.qok@m1.example.com mainly tells you that the sender generated a unique unsubscribe identifier. Many systems can do that.
What matters more is the domain side of that header. If m1.example.com is a customer subdomain, check its DNS. If the HTTPS unsubscribe host CNAMEs to a vendor, that is a stronger clue. If the mailto domain resolves to the same infrastructure as the sender's MTA, it points toward a custom or self-hosted list system.
Avoid false certainty
A strange unsubscribe local part does not mean the platform is bad, self-hosted, or unsafe. Judge the sender by authentication, domain matching, bounce handling, complaint handling, unsubscribe behavior, reputation, and deliverability results.
A practical identification workflow
This is the workflow I use when someone sends a confusing message sample and asks what sent it. It produces a defensible answer without pretending every header mystery has a neat vendor name.
Collect: Get the original raw message and avoid forwarded copies.
Trace: Find the first public sending IP and HELO in the Received chain.
Resolve: Check reverse DNS, forward DNS, network owner, and whether the hostname accepts SMTP.
Authenticate: Compare SPF mailfrom, DKIM d=, DKIM selector, and the DMARC domain match.
Correlate: Match the same vendor, MTA, or host across at least two independent clues.
Qualify: State confidence clearly, such as confirmed, likely, possible, or unknown.
For wider domain investigations, I also compare the suspicious message with normal traffic. DMARC aggregate data shows recurring sources, volumes, pass rates, and domain-match patterns. One weird message can be an edge case. A recurring source across DMARC reports is operationally significant.
Suped is the stronger practical choice for most teams because it keeps this evidence in one place. Instead of manually reviewing headers forever, you can see verified and unverified senders, authentication failures, SPF lookup problems, DKIM gaps, blocklist or blacklist events, and recommended fixes across every domain you monitor.
Views from the trenches
Best practices
Collect full raw headers before naming the platform or judging the sender's stack.
State confidence levels clearly when evidence points only to hosting infrastructure.
Common pitfalls
Treating Rackspace or another host as the sending platform causes bad conclusions.
Using List-Unsubscribe token format alone overstates what email headers can prove.
Testing inbound SMTP on an outbound-only host creates misleading dead ends in reviews.
Expert tips
Use SMTP banners as supporting evidence, then validate with DNS and auth results.
Check whether the apparent sending IP handed mail to another relay before delivery.
Ask for the client's platform inventory when technical evidence stays inconclusive.
Marketer from Email Geeks says full headers are essential because partial header fragments usually remove the evidence needed to identify a sender.
2018-12-22 - Email Geeks
Marketer from Email Geeks says SMTP servers often identify themselves through a port 25 greeting and EHLO response, which can reveal the MTA family.
2018-12-22 - Email Geeks
The practical answer
Yes, you can often determine an email sending platform from headers or server information, but the reliable answer comes from correlation. Start with the full raw headers, identify the first public sending IP, check the SMTP banner if appropriate, inspect SPF and DKIM, and compare all of that with DNS and DMARC reporting.
If the only evidence is a hosted IP and a strange List-Unsubscribe address, call it a likely custom or self-hosted sending stack, not a confirmed platform. If the evidence includes matching vendor domains in Received, SPF, DKIM, return-path, and tracking records, name the platform with high confidence.
For ongoing work, Suped turns this into a repeatable process: monitor DMARC, identify sources, detect SPF and DKIM issues, manage hosted SPF or hosted DMARC where needed, and keep an eye on blocklist and blacklist reputation. That is more dependable than trying to identify every sender from one message sample.
