E-Mail Headers: Where the Action Is

As email marketers, we spend a majority of our time creating email bodies. However, the most important part of a message may be something outside the creative process: the email header, those generally hidden lines of code at the top of each message.

Now that the email industry is using authentication, reputation, and accreditation, the email header plays a critical role in an ISP’s decision to block or deliver a message. Most of us, though, let our IT departments or email service providers (ESPs) worry about the header.

With our basic walkthrough, you can interpret what the header tells you about message delivery. We’ll also provide a couple reasons fiddling with some list software settings can actually hurt deliverability.

(If you’re reading this via email, you can follow along by viewing this message’s full header. In Outlook, open the message. In the drop-down menu, select “View,” then “Options.” In Gmail, select the “More Options” link, then the “Show original” link located below the subject line. Most email clients, especially Web clients, show shortened or even no headers unless you change the setting.)

Following is some key information included in most email headers:

  • Return-Path: test@yahoo.com

    At the very top is the return-path, also called the envelope sender. This address will receive any bounces that might result from the message. It must, therefore, point to a working mailbox. If you use an ESP, this address should point to the ESP’s bounce-processing mechanism. In this case, the address is usually different from the actual sender line a recipient sees in the inbox.

  • Received: from web32708.mail.mud.yahoo.com (web32708.mail.mud.yahoo.com [”) by zeta.testdomain.com (8.11.7p1+Sun/8.11.7) with SMTP id j9MLWRe16285 for ; Sat, 22 Oct 2005 14:32:27 -0700 (PDT)
    Received: (qmail 18241 invoked by uid 60001); 22 Oct 2005 21:32:27 -0000

    The return-path is followed by one or more received lines showing the message’s transmission path. Each transmission point adds a line detailing the message’s path. Read top to bottom, these lines trace the message’s origin to its destination.

    If you want to identify the server name and IP address that sent this message, look at the topmost received line. Here, the message was sent by “web32708.mail.mud.yahoo.com” from

  • DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com;
    KFItpskzRFTFVu1qFlCNY= ;

    Because this message was sent from Yahoo Mail, it contains a DomainKeys line. The line contains a cryptographic signature that, when checked, authenticates the message was sent from Yahoo This signature is written by your MTA (define) or your ESP’s DomainKeys-enabled software. SenderID, on the other hand, doesn’t require any addition to the headers.

  • Message-ID: <20051022213227.18239.qmail@web32708.mail.mud.yahoo.com>
    Date: Sat, 22 Oct 2005 14:32:27 -0700 (PDT)
    From: test
    Subject: Test message
    To: kirill@testdomain.com

    These lines show the message-ID assigned by the sender, the date it was created, the sender line visible to the reader, the subject, and the receiver information. These headers, with the exception of the message-ID, are displayed to users in their email clients.

    This is where a deliverability problem can crop up. Are you still using the old email hack that changes the current date and time to a phony future or past date to make the message show up at the top of the inbox? Better change it back to the current date and time now. Many anti-spam programs check the creation date when evaluating your message’s legitimacy and reject messages sent from dates too far in the future or past. You should also show the recipient’s actual email address in this line instead of a general message, such as “Newsletter Recipients.”

  • MIME-Version: 1.0
    Content-Type: text/plain; charset=iso-8859-1
    Content-Transfer-Encoding: 8bit

    Message format is defined for the recipient by the sending software. These tags refer to the MIME (define) format for sending messages in something other than plain text. Most email clients are MIME-compliant and decipher the encoding format. An HTML message, for example, would have a MIME content type of “multipart/html” or “multipart/alternative” instead of “text/plain.”

    Based on the content-type, you can see this message is in plain text format, written with the ISO-8859-1 character set, and encoded in 8bit. Messages sent in foreign languages would reflect the appropriate encoding format and character set.

  • X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on zeta.testdomain.com
    X-Spam-Status: No, hits=-4.0 required=6.0 tests=BAYES_00 autolearn=no version=2.64

    This is another section where anti-spam filters can use the reported data to block your message. X-headers are user-defined headers that can be attached either by the sender or the recipient. Spam filters commonly explain their spam reasoning within these headers.

    This message was scanned by SpamAssassin, version 2.64. It scored -4.0, meaning it’s unlikely to be spam or fraudulent. If the message had violated any spam tests or rules, those would be reported here.

This last bit of information can also help you test a message before you deliver it to your full list. (You do test, right?) Test your message in different browsers and email clients; they display email, especially HTML email, differently. The header data in the test messages will also tell you whether the email encounters any problems in transmission or delivery.

You still have to worry whether a particular word or line of HTML coding in the message body could trigger a spam filter. But knowing how to interpret the data in an email header will help make it easier to avoid future transmission.

And as always, keep on deliverin’.

Want more email marketing information? ClickZ E-Mail Reference is an archive of all our email columns, organized by topic.

Related reading

Flat business devices communication with cloud services isolated on the light blue background.