Sender authentication part 7: Shortcomings of SPF

SPF is a method of authenticating the envelope sender's domain with the IP that transmitted the message to the receiving mail server.  It is quite useful for preventing spoofing but it has its shortcomings:

1. SPF adoption has been slow.

As I alluded to in my previous post, not all domains have published SPF records.  In fact, only a minority have done so.  It's only effective when it's taken advantage of so slow adoption will diminish its usefulness.  Of course, if you don't lock the door of your car and somebody breaks into it, your probably should have locked your door.

2. Legitimate mail can have SPF Hard Fails.

Even though SPF fails are designed (in theory) to hit spammers that are spoofing legitimate domains, we routinely see legitimate mail failing SPF checks.  There are two common occurrences for these; the first is somebody logging in from a remote site and sending mail while attaching their email address as the envelope sender.  Because this remote site has an IP that is not authorized to send mail for the domain, SPF checks fail.  This generates a false positive.  I find it difficult to classify this as a legitimate false positive because it is SPF working as intended, on the other hand, it happens often enough that auto-quarantining messages that fail the SPF check probably is not your best course of action.

The second example is newsletters.  Many organizations outsource their mail campaigns to third party services.  These services send out mass mail to the organization's subscribers and attach their name as the envelope sender.  Of course, these organzations publish SPF records and when the mail servers do the check, the SPF check fails.  Again, this is SPF working as intended.  They could fix this by adding the third party mailer's IP to their SPF records.  The drawback would be that the third-party mailer could conceivably use this to send out spam.

3. Spammers can publish SPF records, too.

This one is especially evil.  Imagine is a spammer registers the domain and publishes its SPF records.  It then transmits emails from that domain which pass the SPF check.  This could really fool end users because the domain looks real enough and the sender is not being spoofed.  Of course, the sender is actually hostile, and openly so.

On the other hand, if a spammer were to do this, we in the spam fighting world could fall back onto one of our older tricks.  We could simply add the domain to a blacklist and reject all mail from that domain.  We could drop the mail after the HELO and SPF check.  So, while a spammer could get mail through, their window of opportunity would be narrow because eventually that domain would get blacklisted.

Comments (6)
  1. Norman Diamond says:

    > Of course, if you don’t lock the door of your car

    > and somebody breaks into it, your probably should

    > have locked your door.

    If somebody breaks into your car, it doesn’t matter if you locked the door, and it doesn’t matter if you will lock your door.

    If somebody opens the door and enters your car without breaking into it, you probably should have locked your door.

    The difference matters both for insurance purposes and for fighting spams  ^_^

  2. tzink says:

    Yeah, I guess my point was to not make it any easier for spammers.  It’s not a great analogy, but it will do.


  3. Terry, I thought the Microsoft-approved statistic was something like 80% of domains publish SPF/SIDF records?

    How does this square with your, "Only a minority have … published SPF records"? Am I missing something?

  4. tzink says:

    My statistic is based upon a quick search for SPF adoption.  I don’t know where MSFT gets their official stats, but wherever they come from I didn’t use them.

  5. T says:

    1. True, and worst is there are those that are not properly implemented… Not even microsoft (huge proponent of SPF) is yet properly configuring SPF records for their smtp servers and for instance has no SPF record.

    2. Not so true, that is only for Sender-ID with PRA, the more common and more widely used spf1 does not make such distinctions (restrictions) and with SRS is perfectly capable of relaying mail successfully.  

    SPF doesn’t have the shortcomings of "Sender ID".  It is probably rarely practical to ever implement Sender ID.

    For newsletters, other domains or subdomains can be used while it is entirely possible to use SPF to restrict all but a few addresses or allow a few addresses and individual users to use third party relays or be indifferent of the relay used.  

    Your examples of SPF are not proper working examples — the SPF records should be updated to account for whatever examples you want or they shouldn’t be allowed.  Messages should not be accepted just  because they are not spam (imagine a message with a .EXE attachment or perhaps a 50MB message), and it is perfectly acceptible to reject messages because the SPF is bad — it is infact what should be done so we can get back to my point about #1 — PROPER implementation.

    3. Not so much of a big deal, spammers still have strikes against them and this allows us to blacklist real addresses not bogus ones and forces them to use additional real resources (for hosting) which can be tracked down unlike trojan resources.

  6. Bob Van Zant says:

    Regarding number 2. You can use the include directive of an SPF record to include the SPF records of your third party mail sender. For example: if has outsourced newsletters to its SPF record might look like:    IN TXT "v=spf1 mx ~all"

Comments are closed.

Skip to main content