For certain scenarios, we may ask you to send us the full message headers of an email for troubleshooting purposes. You can read further about how to see and download message headers here.

But what is a message header, and why are we asking for it?

An email has three parts. An envelope, a body, and a header.

The envelope is a part of the message to be used only by servers during the message's transit, and won't arrive to the final user. However, this particular part is quite complex and is not relevant for this topic.

The header fields contain information about the message, such as the sender, the recipient, and the subject. If a message body is included (which is technically optional), it is separated from the header fields by an empty line.

In this example, we can see three header lines, and the message's body.

The full message headers will contain all of these message's header lines that had been printed during the message's transit through several email servers. They provide useful information about what happened to the message in the past,  and are meant to be read from the bottom to the top, to follow their chronological order. 

Not only the sender's server will print header lines. Every time an email server (MTA) sends or receives a message, it will print a new header line with it's own sending/receiving timestamps. This is most useful when investigating delays, or when emails went missing at some point during the delivery.

This part looks like this (sanitized version for illustration purposes only):

When investigating an issue, we may ask you to retrieve the message header's from the recipient's mailbox (when that's possible), because as these lines are printed during the transit, the final recipient's version of the message will be the only one containing all of the header lines that had been printed on the message.  That's why this version is called "full" message headers.

Quite often you may see header lines starting with a "X-". These are custom, optional lines that email providers can decide to  include to provide further information.

As they're not standard and can be designed freely, they're normally more difficult to understand for 3rd parties, and may not always be useful for everyone.

An example of these lines within a message header, printed by different servers/email providers:

These are some of the most relevant, good to know ones, printed on our side:

"X-antispameurope-sender"

This will refer to the real sender of the message at connection level, A.K.A the envelope-from.

This is necessary to know for example, when creating Content Compliance Rules that needs to trigger based on the sender but most important, it's one of the key field when evaluating the message's authenticity.

Using the "from" field (A.K.A header-from) on these type of rules will not work, if the header-from and the envelope-from aren't the same. This is common for automated emails, emails sent from distribution lists, web forms, delegated accounts, alias accounts, and for messages lacking envelope.from.

"X-antispameurope-recipient"

This line specifies the address we've delivered the message to.

Normally will be the same as the "TO" field of the message header, but sometimes it's not, like when there's a rule in place to forward all or certain messages to a different recipient. Or messages sent to distribution groups, where the message has been sent "TO" info@, for example, we actually deliver just one email to the recipient server NOT one copy of the message to each of it's members. The recipient server is responsible for distributing the message to the group or list members. However, these final recipients are are sometimes specified under "FOR" fields.

"x-hornetsecurity-delivered"

We will only print this line if a message has been blocked by our filters, and released afterwards from a Quarantine Report or from the Control Panel's Email Live Tracking. Depending on who did the action, the value could be "user:api:all", "admin:api:all", or "support:api:all" depending on who released the message.

"X-antispameurope-orig-ip"

This is the IP we've received the email from, and the IP we'll use to perform SPF checks, for example. Nowadays, specially in cloud platforms, the server who creates the message isn't the same one who sends it to the internet, due to infrastructure complexity.

For example, if a message is sent from a local Exchange directly to the recipient domain's MX records, the Exchange public IP will be considered as the original or source IP. If the exchange uses a relay instead of sending the message directly to the internet, the first server who receives the message in the recipient side of the transmission, will consider the relay's IP as the original or source IP, and will know nothing about the existence of the Exchange.

X-antispameurope-orig-host

The public hostname of the server who delivered to message to us.

"X-antispameurope-orig-MSGID"

This will specify the the message ID which is the unique and public identifier for a message, 

"X-antispameurope-MSGID"

This is an additional ID we assign to each message. This is useful for us when investigating what happened to a message within our platform. It's a good example of a header line that may only be useful for the provider/server who printed it, us in this case.

"X-antispameurope-SPFRESULT:"

"X-antispameurope-orig-Spamstatus:"

This line shows our original classification of the message when it reaches our filters, and it's printed before considering admin or user level policies. For example an email showing "SPAM" here, could had been delivered to the recipient because the sender was on a allow list, or because the user or an admin decided to release the message afterwards. 

Further readings:

RFC 5322 3.6. Field Definitions

RFC 5322 2.2: Header fields

RFC 5321 Section C: The SMTP Procedures: An Overview