Sender authentication part 3: Checking the received headers

In my previous post on the basics of email headers, we saw the basic headers that are inserted by receiving mail agent.  In this post, we are going to look at some of the techniques that spammers use to hide themselves.

Recall a received header; it’s an envelope header that a machine inserts to log where it came from.  A good mail recipient will log the received IP.  From the example earlier:

Received: from ( []) by (8.8.5) for with EMSTP id 123456789-0AH for <>

In this example, the IP ( that sent the message has a reverse DNS of  When the transmitting machine sent the message, it said “Hello, my name is”  In other words, everything checked out.

However, what would happen if a spammer decided to forge the HELO?  What if they said “Hello, my name is”?

Received: from ( []) by (8.8.5) for with EMSTP id 545D2FE805C for <>

In this example, the machine claimed to be, but was sending from  Right off the bat we can see that there is a mismatch.  By looking up the IP address, it resolves to  In other words, it is completely different than  Thus, we have come across an example of a transmitting machine that claimed to be sending from one mail host but in actually was sending from another.

A smarter spammer will use a trick to bypass this.  Rather than sending from an IP address that has a reverse DNS lookup (ie, converting an IP to a domain name), they will send mail from an IP that has no reverse DNS.  In that case, the received line would look like the following:

Received: from (unknown []) by (8.8.5) for with EMSTP id 545D2FE805C for <>

I’ve inserted the “unknown” because the above IP address does not resolve to a DNS (and that’s the way our servers mark it in the headers).  Since the transmitting IP has no reverse DNS there’s no way to verify whether resolves to it.  Doing a DNS lookup on doesn’t match the IP address; this is suspicious and in itself doesn’t prove the domain is spammy but is definitely worth increasing the spam probability.

A smarter spammer still would obfuscate even more:

Received: from hofgado (unknown []) by (8.8.5) for with EMSTP id 545D2FE805C for <>

The transmitting machine called itself hofgado and sent from an IP with no reverse DNS.  In this case, there’s definitely no way to resolve this because the machine name won’t resolve via a DNS lookup (not in the proper format) and there is no reverse IP.  This is certainly suspicious and would definitely increase the spam probability.  On the other hand, there are a lot of misconfigured mail servers out there that are sending legitimate mail.

In the next post, I will go into how Forward-Confirmed Reverse DNS can help with email authentication.

Comments (2)

  1. Bart Schaefer says:

    It may be worth noting that sometimes spammers insert extra, completely fabricated Received: headers just to make it appear that a message followed a route which it really did not.  Often you can’t look at any one Received: in isolation, but instead must make sure that the whole chain of them makes sense.

  2. tzink says:


    That will be in my next post.