How Email Works, Part Three: Anatomy of an Email

As we noted last time, when it comes to spam filtering there is a trove of information in the header of every received email. While much of it is quite technical, a good email marketer should understand the basics and know how to read the headers of an email.

The first generation of anti-spam systems mostly relied on single data points, such as the sending IP. This was when the Realtime BlockList (RBL) ruled. The second generation used multiple rules with individual weightings to make a determination. SpamAssassin was the best known of these systems.

Today’s anti-spam systems analyze a multitude of data points taken from all the header and body content, and use machine learning to compare this data over time, as with sender reputation. They also compare data between messages, as in Bayesian analysis, to continually adjust and refine weightings on a system-wide, as well as individual-recipient, basis. The result of this is that there is often no single cause of blocking or filtering. Knowing how to read the headers goes a long way in helping to identify contributory causes. Authentication failures, the sending IP being on a blocklist or having incorrect DNS can often be identified by looking at the headers.

Here’s an example. When an email geek asks you to forward a message “with full headers,” this is what they mean:

Starting at the top we find:

1. Delivered-To is what was contained in the SMTP “RCPT TO” section.
2. Return-Path is the SMTP “MAIL FROM.” You may hear this called the RFC822 From, which is a way to distinguish it from the From shown to the recipient. That is further down and can be very different.
3. “Received” indicates message reception by an MTA. Each MTA the message passes through will add a “Received” header. The exact content may vary but the header will contain which site received the message, who for and when.In this example the message was received from mta.sendingsite.com with an IP address of 192.168.1.10. This is the sending IP an ISP will ask about. It’s what would be checked against the Spamhaus Blocklist and is the basis of your IP reputation.
4. “Authentication-Results” was added by the receiving MTA showing the outcome of SPF, DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting, and Conformance) authentication tests and the DMARC policy. Not all servers add this, but when they do, it’s very helpful for forensic analysis.
5. “DKIM-Signature” was added by the sending MTA to authenticate the message. It contains data about the DKIM authentication, including which headers are being authenticated and the cryptographic signature that is used for validation.
6. Message-ID should be universally unique to this message. It’s generally added by the submission engine but can be by the first MTA.
7. From, Reply-to, To, Subject and Date are the familiar headers shown in most email clients.
8. X-Campaign is a custom header added by the sender. Any header starting “x-” is custom, and can be or contain anything the sender wishes.
9. List-Unsubscribe is an increasingly common header used for automated unsubscription processes. A number of ISP feedback loops utilize this header to send user unsubscriptions.
10. MIME-Version indicates that this message uses the Multipurpose Internet Mail Extensions. Email was originally a simple text-only medium. MIME is how things like attachments and HTML are handled.
11. Content-Type is a MIME header that indicates what content the message contains. In this case multipart/alternative.

Some additional things to note about the headers:

• They’re in reverse order. Each server puts its additions at the top, leaving what was already there intact. To trace a message’s path, you work upwards.
• I color coded the headers. Those we know are true are green, those we can verify are yellow, and those that we cannot tell are red. It’s worth noting that “true” doesn’t necessarily mean valid. For example, the Return-Path is what it is. Whether it’s valid is a different question.
• All the headers in yellow would be red if the email was not signed with DKIM. Thus, DKIM verification provides the ISP with a lot more reliable information to use in the spam filtering process. A valid DKIM signature also increases overall trust in the validity of the message. SPF only validates the Return-Path.
• The strings of numbers in many of the addresses (0123456789-9876543210) are used by the ESP to identify the campaign and recipient so that returned email – bounces, complaints, unsubscription requests – can be accurately processed, regardless of where they finally ended up or how they get sent back.

At this point you should have a clear idea of how your email gets from your ESP to your subscribers and the processes it goes through. You should also have a good understanding of the headers of an email, be able to determine who sent it and figure out whether or not it’s valid, all of which are essential knowledge and skills for the professional email marketer.