MAIL FROM vs From vs Sender – exploiting SPF

After 10 years of managing computer networks, I still learn something new almost every day. This week I inadvertently discovered that there were many more ways of “identifying” the sender of an e-mail that I had ever known (or in this case, of spoofing the sender an an e-mail).

Despite having multiple layers of SPAM protection, including strict SPF records and advanced content filtering, a particular set of SPAM was cleanly passing every layer of protection – this set of spam claimed, no less, to have originated internally (Clearly, this was not the case).

So, here’s how mail is identified:

A) MAIL FROM: (Also known as the envelope address)
B) Mail headers:
B1) From: (Generally what you see in your mail client)
B2) Sender:
B3) Reply-To: (Hitting “Reply” will usually go to this address)
B4) Resent-From:
B5) Resent-Sender:
B6) Resent-Reply-To:

The SPF specifications look explicitly at the envelope address; which is rarely ever seen by more than the e-mail relays. So, some clever spammer has been sending out a deluge of e-mail with forged mail headers that all match our own e-mail domain, but sending a different identity in the MAIL FROM – which conveniently passed SPF with flying colors. The e-mail client then looked at the forged headers, which contained our own (white listed) domain. The rest is history.

… or was, until I added a few lines of code to our mimedefang-filter. Any e-mails with headers claiming to be sent from our own domain are now cross-checked against the MAIL FROM:. If the domains don’t match; poof, the message is silently discarded.

4 responses to “MAIL FROM vs From vs Sender – exploiting SPF”

  1. You have raised a very interesting point, and something I would love to discuss further with you. I am having exactly this problem to figure out how to legitimately send emails from a webserver on behalf of someone else. Given someone who has put in restrictions such as you have, I can’t see any valid way.

    For example, I have a website that will send an email to an individual on your behalf ( when you click on a particular button.

    So if I simply put the From: as and specify the sender as being, by default the mail server will use the From: as the envelope address (MAIL FROM). This obviously will fail on SPF check as an SPF record for will show that they are not permitted from mailserver. So the next bet would be to modify the envelope address to be from

    So now we’re at the stage where you have the following that should pass SPF:

    However, based on your additional filtering, this type of email would be rejected.

    Any ideas, thoughts, and/or suggestions how to accomplish this “legally”?

    If you want, you can email me directly as well.



  2. Hi Eric,

    Thanks for the note. It did bring up some good points.

    In the context of my filtering solution, note that I discard messages
    only from the business domain where the MAIL FROM and From: header
    don’t match. As the sysadmin for the company, I can vouch for the
    fact that they use only the internal e-mail system. I can’t guarantee
    what other companies are doing, so messages from all other domains are
    filtered according to standard RFC4408. So, in your case, your message
    would get through just fine, unless you were sending mail To: using a From:, which simply should not
    be taking place.

    I think the first question that comes to mind is *why* you would need
    to send an e-mail on behalf of another user on another domain? If you
    consider that the administrator of a domain has put strict SPF records
    on a domain, then chances are good that implies that they don’t want
    servers sending e-mail for their domain other than the ones they have
    allowed in the SPF records.

    Using your example, I don’t understand why can’t simply
    send out an e-mail with something like the following:
    From: “Website on behalf of John Doe”

    The above example is perfectly conforming to RFC822, breaks no rules,
    and makes no presumptions to be someone it’s not.

    If, for some reason, the business purposes of John Doe absolutely
    required that he send e-mail via as,
    then it should be a trivial matter for John Doe to get his systems
    administrator to add’s mail relays his spf records.

    I’d love to continue this discussion if the above doesn’t help. Just
    let me know.


    -Mathew Eis

  3. Nice, and old article.
    Now we have DMARC does the exact same job for you. Only 7-8 years later 😀

  4. Note for people stumbling on this page still… in response to ZUL, the last comment, DMARC is just a combination of SPF and DKIM with another configurable policy. It works IN ADDITION to everything mentioned in this article, not as an alternative.

Leave a Reply

Your email address will not be published. Required fields are marked *