Understanding an email header of an message can help you determine where it originated, what mail servers and relays it passed through.

How do I see the route of an email in the headers?

The routing of the email section is reasonably straightforward if you keep in mind that they are backwards.

  1. Look for lines in the headers that say "Received: from".
  2. Look for the last "Received: from" line and read upwards.

For instance, let’s assume we’re tracing an email with the following headers:

Received: from unknown (HELO outbound.spamstopshere.com) (9.10.11.12) by mail.MyDomain.com with SMTP; 13 Feb 2009 23:23:29 +0200 
Received: from inbound.spamstopshere.com (inbound.spamstopshere.com [5.6.7.8]) by outbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNSS7000915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Feb 2009 16:23:28 -0500 
Received: from mail.sendingdomain.com (mail.sendingdomain.com [1.2.3.4]) by inbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNQgX009122 for ; Fri, 13 Feb 2009 16:23:26 -0500 
Received: from 10.0.0.100 ([10.0.0.100]) by mail.sendingdomain.com ([10.0.0.1]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Feb 2009 21:23:21 +0000 

When read from bottom to top says it went from 10.0.0.100 to mail.sendingdomain.com in the first line: “Received: from 10.0.0.100 ([10.0.0.100]) by mail.sendingdomain.com ([10.0.0.1])”

  1. From mail.sendingdomain.com to inbound.spamstopshere.com in the second line: “Received: from mail.sendingdomain.com (mail.sendingdomain.com [1.2.3.4]) by inbound.spamstopshere.com “
  2. From inbound.spamstopshere.com to outbound.spamstopshere.com in the third line: “Received: from inbound.spamstopshere.com (inbound.spamstopshere.com [5.6.7.8]) by outbound.spamstopshere.com”
  3. And finally it's delivered from outbound.spamstopshere.com to mail.MyDomain.com in the last (topmost) line: “Received: from unknown (HELO outbound.spamstopshere.com) (9.10.11.12) by mail.MyDomain.com”

Please see the supplemental FAQ How do I determine delays in my email via the message headers for additional information.

How do I determine delays in my email via the message headers?

If we understand reading the route of the email in the headers it's easy to see where any delays might have occurred.

Each “Received: from” line will have a corresponding timestamp. Since email (and the internet in general) is global, the timestamps will frequently include GMT values to indicate what time zone the server is in. The timestamps are added by the recipient server, so if it says “Received: from some.server.com by my.mailserver.com 13 Feb 2009 24:53:29 +0200”, the timestamp is my.mailserver.com’s time.

In the below headers I have included a delay. Can you see which line has the delay? Hint: when the time zones are different, often you can simply check the minute field to look for a discrepancy instead of adding/subtracting the GMT values for each one.

Received: from outbound.spamstopshere.com (HELO outbound.spamstopshere.com) (9.10.11.12) by mail.MyDomain.com with SMTP; 13 Feb 2009 24:53:29 +0200 
Received: from inbound.spamstopshere.com (inbound.spamstopshere.com [5.6.7.8]) by outbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNSS7000915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 13 Feb 2009 16:23:28 -0500 
Received: from mail.sendingdomain.com (mail.sendingdomain.com [1.2.3.4]) by inbound.spamstopshere.com (8.14.1/8.14.1) with ESMTP id n1DLNQgX009122 for ; Fri, 13 Feb 2009 16:23:26 -0500 
Received: from 10.0.0.100 ([10.0.0.100]) by mail.sendingdomain.com ([10.0.0.1]) with Microsoft Exchange Server HTTP-DAV ; Fri, 13 Feb 2009 21:23:21 +0000 

It’s the top line, or last “hop” in the email. Now, how do I troubleshoot the issue?

You might have noticed that each intermediary server is listed twice in the headers. When the server receives the message it says “by some.server.com” and then when it sends it on it says “Received: from some.server.com” in the next line. Often this is enough to tell where the delay occurred. If a server accepted the message and didn’t deliver it for many minutes, hours, days, etc. it frequently indicates that the recipient’s mail server was unavailable, deferring connections or “greylisting” the sending server. In that case, the logs you’ll want to read are on the recipient’s mail server (or possibly their firewall especially if it’s a connection issue or if it has a MTA built in). If this server does not have pertinent log files, then contact the sending server’s administrator to see if their logs show any additional information.

Sometimes the sending server may have issues sending an email that are outside of the recipient mail server’s control. A few examples would be retrieving the DNS information of the domain or recipient server, issues with connectivity or specific routing due to ISP issues, or any number of other issues. In these situations you’ll have to contact the sending server to determine the issue. Because the message never left the sending server, there will not be any logs on the recipient mail server. This is often the best place to start when troubleshooting home built or custom email applications such as bulk mailing software/vendors, website forms etc.

Why do some messages say that they're to/from "invalid" or someone at one of Greenview Data's domains?

Our software requires "To:" and "From:" headers in email messages to be processed properly. Because some messages sent to lists or via carbon copy won't have this header, our software will add one containing the server's name (for instance youremail@server.spamh.com). This is normal and just means that the email message was missing a header when we processed it. This is to satisfy SMTP requirements outlined in RFC 2821, as described below:

    '''3.8.4 Other Header Fields in Gatewaying'''<br /><br />
    The gateway MUST ensure that all header fields of a message that it
    forwards into the Internet mail environment meet the requirements
    for Internet mail.  In particular, all addresses in "From:", "To:",
    "Cc:", etc., fields MUST be transformed (if necessary) to satisfy
    RFC 822 syntax, MUST reference only fully-qualified domain names,
    and MUST be effective and useful for sending replies.  The
    translation algorithm used to convert mail from the Internet
    protocols to another environment's protocol SHOULD ensure that error
    messages from the foreign mail environment are delivered to the
    return path from the SMTP envelope, not to the sender listed in the
    "From:" field (or other fields) of the RFC 822 message.

Other Resources