Are You Using SPF Records?

gravyface writes "I've been setting up proper Sender Policy Framework records for all my clients for past year or so, hoping to either maintain or improve their 'reputation' in the email universe. However, there's a lot of IT admins I speak with who either haven't heard of SPF records or haven't bothered setting them up. How many of you are using SPF records for your mail domains? Does it help? How many anti-spam vendors out there use SPF records as part of their 'scorecard'?"

Comments

yes

[zeldor]

it has cut down tremendously on the spam claiming to be from my domains.
any other benefit I am unaware of.

Re:yes

[MightyMartian]

If you're using a lack of SPF records as a determinant in whether or not a message is spam, then I can guarantee you that you're losing mail to false positives. Maybe that isn't a big deal to you, but for the organization I work for, it would be absolutely nuts. The chief reason I have SPF records for my domains is so that the big boys like hotmail.com and GMail don't reject my emails. I use greylisting as my chief anti-spam weapon, and it's far more reliable and far more effective than SPF.

Re:yes

[Snover]

Read again.

Spammers can’t use his domain to forge spam, because SPF-aware mail servers reject it. Hence, he doesn’t have to deal with tons of bounces, spam warnings, virus warnings, etc..

Re:yes

[jonadab]

> If you're using a lack of SPF records as a determinant
> in whether or not a message is spam, then I can guarantee
> you that you're losing mail to false positives.

Yeah, that's not how you're supposed to do it. No SPF record means "I don't know whether this is a valid sender for this domain or not", so you fall back to whatever other method you have for making the determination.

Traditionally, the "other method" generally meant accepting everything and letting the users sort it out in the inbox, but there are other things you can do, such as looking at stuff like whether the EHLO domain matches the sending IP, whether the envelope sender matches either of them, whether the From field matches any of the above, whether any of our users have sent mail to this domain in the last N days, and so on and so forth, each of which criteria can be assigned a weight, which can be used to determine whether to accept the message immediately, graylist it (and for how long), subject it to more rigorous (but computationally intensive) regex-based filtering, check for it on collaboratively-maintained blacklists, etc.

And if the domain *has* SPF records and the sending IP isn't in them, you have your choice of greylisting with a lengthy delay, going straight to teargrube mode, or just sending a 554 response immediately. And you can take note of the IP address for future reference.

> I use greylisting as my chief anti-spam weapon, and it's
> far more reliable and far more effective than SPF.

Greylisting has problems too. Not least, it causes delays, which can run into multiple minutes. (In some situations, even a thirty-second delay will make the natives restless.) Additionally, if too many mail exchangers do greylisting, the spammers will just implement retries (it's not like it's hard; normal mail servers have been doing it forever). All of this doesn't mean greylisting isn't useful, but it's one tool in the toolbox, not the be-all and end-all. There are a lot of things a mail server can do to try to determine whether a message is spam. None of them individually is very reliable, but you don't have to do just one thing.

Re:No, and I won't

[hedwards]

That's some nice FUD you've got there. There are some valid points, but the basis for the page is inaccurate. SPF is really meant to be used in conjunction with some other technology like DKIM. SPF is just meant to ensure that one aspect of the process, that the machine sending the email is allowed to do so. DKIM for instance is meant to verify the contents of the email hasn't been tampered with.

Unless something has changed in the last few years, DKID doesn't verify that the server is allowed to send email for that particular domain, just that the email itself wasn't tampered with which has its own issues. For instance, while it does verify that the message hasn't been tampered with, it does not help people that are sending legitimate cold emails to a server of say the sales rep for the company.

My point here being that any technology has issues when one tries to use it in a way for which it isn't designed, but saying that because it can be used improperly that it's therefore dangerous is an argument which lacks merit.

nope...

[stokessd]

It's winter so there isn't much sun or exposed flesh to worry about. My record for SPF is 50 when I'm bicycling in the noonday sun in the summer.

http://en.wikipedia.org/wiki/Sunscreen

Re:I use them, but mainly for deniability

[MightyMartian]

And yet none of these solutions will actually do very much good at all. This was all hashed over several years ago. SPF, DomainKeys and so forth are little more than feel-good half-measures. If the sole reason you're using any of them is so that Google doesn't reject your email, then I think that's pretty much demonstrated the worthlessness of them.

Got it on Google's advice

[cerberusss]

Four years ago, I got hit by a Joe-job, i.e. some spammer used my domain in the 'From' field. I deleted the thousands of resulting messages in the following days and then didn't think about it anymore.

Two years ago, I shut down my mail server and moved it to Google Apps. Basically it involves creating a Google Apps account which tells you to point your domain its MX (mail exchange) records to GMail. The second, optional, step was to add SPF records. I thought about the Joe-job. Since the GMail wizard is good and explains everything, I just executed that step. It's actually really simple.

Anyone else have this experience? I.e. creating SPF records was too easy to just skip it?

Re:Use DomainKeys..

[NormalVisual]

Yahoo, Gmail, MSN/Hotmail, and AOL pretty much require that you have DomainKeys implemented if you want to email their users

I don't have DomainKeys set up, and I've never had any difficulty getting mail to users of any of those services.

Anti-spam vendor's perspective

[gujo-odori]

I work for a major anti-spam vendor.

Yes, SPF records are part of the mix at many anti-spam vendors.

However, they aren't part of reputation. Reputation, to describe it simply and without giving away any secrets, is determined by the kind of mail a host or network emits. Whether it has SPF records and/or DKIM-signs its mail does not affect reputation; if you emit junk, your reputation will be junk.

SPF and (moreso) DKIM have value in assessing whether a given mail is a forgery or not (think phishing and related scams). They are not weighted overly much, since people do foolish things like put their work email address into their webmail account all the time, and it causes FPs, for some value of false positive. That is, it's not an FP per se, but the mail is technically legit, so dropping it on the floor isn't the desired action.

In short, don't expect having SPF and DKIM to improve your deliverability much, if at all. That's not where the value-add is. The value-add is helping to separate the sheep from the goats among mail that purports to be from your domain. If you want recipients to be able to (theoretically, since most of them don't/won't check) have greater confidence that a mail that claims to have come from your organization really did so, then yes, implement both SPF and DKIM.

If you're an organization whose customers might be phishing targets, definitely do both. Orgs I've seen targeted for phishing include financial institutions of any size (even a single branch!), various government agencies, educational institutions (not just universities, either), BBB, auto clubs, World of Warcraft accounts, Vonage, Craig's List, all the free webmail providers. If it has a login, and anything a phisher could find to be of value (for practically any value of "value"), there will be phishing attempts.

If your company is one of those - or even if it's not, really - I recommend both SPF and DKIM.

Better for Sent Items then Received

[Krondor]

I use them, and what I've found is that they have a very marginal effect (if any) on spam catch rates on your inbound mail. However, they do have a great side benefit. They significantly reduce backscatter, keep yourself off of blacklists, and provide some control of you, your employer, or your client's identity on the web. SPF records provide a mechanism to limit who can spoof as you (as long as recipient servers adhere to them). If you have a risk to yourself or interested parties that someone might spoof your domain (banks!), then SPF provides a means to insure the chain of custody (to an extent).

I do think overall SPF has helped to prevent forged domain letters, but those are less and less common (for those that publish spf). The spammers now either rely on forged domains without DKIM or SPF (why not use both!!) or they send from their own controlled botnet domains and publish legit SPF for themselves as well.

Nope

[menelaus]

I don't use them personally and we have very few customers at my current job that will request them.

I used to work for an anti-spam company and the request would come in from time to time to have SPF checking built into our appliances. As developers, we did see the benefit of it. But at the time, there was the SPF vs SenderID vs Domain Keys battle going on. Who would win out?

As it appears years later, no one really did.

The problem with the technology is adoption rates. Unfortunately, many of these technologies are not being adopted by the masses. I'm not saying its hurting you by having these in place, but it also might not be doing as much good as you think that it is.

Re:No, and I won't

[martok]

Actually, DKIM can be used to guarantee a sender. We're using DKIM here with ADSP. That is:
_adsp._domainkey TXT "DKIM=ALL"
tells a receiver that all emails from our domains should be signed. Since the keys themselves are published in our DNS, a machine not under our control should not be able to send an email purporting to be from our domain.

I'm not sure but I would think that mechanism would make SPF irrelavent. Assuming antispam software actually checked the adsp dkim records.

Re:Yes.

[oatworm]

Pretty much the same here - SPF records aren't particularly hard to implement, after all. On the receiving side, I just check for SPF failure (i.e. somebody e-mailing from somewhere other than the domain's SPF-registered mail server), and even those just get sent to users' junk mail folders. I'm certainly not bouncing anything because of them. Based on my mail server reports, it looks like the low SPF filtering is catching about 0.5% of the mail volume that flows my direction, which isn't much, but it's 0.5% less than I would be dealing with otherwise and was implemented "for free", so I'm not complaining.

Re:No, and I won't

[Krondor]

How would that work with trusted partners who may send mail on your behalf? With SPF I can use an include:xxx to define relationships with other systems. With DKIM it seems I would need the partnered system to stamp the sent mail or relay off of our originating servers for DKIM attribute addition (something that might not always be possible). Is there an elegant workaround?

Re:I use them

[digitalchinky]

Not just to add a 'me too' but I recently removed SPF completely - mostly because other people couldn't get their entries correct, or just completely failed to update it when they add in extra servers. Legitimate messages were hitting our spam folders. Since I can't train our fine worker drones to actually look in their spam, I opted just to remove it. With greylisting and spamassassin its removal hasn't made any noticeable difference aside from the false positives now being delivered properly.

Re:No, and I won't

[sprior]

While I can see the reason for your points, I don't agree with the conclusion.

The fact is that implementing SPF comes with a bigger responsibility to account for every machine your email might be sent from. No doubt this can be a big pain and imply compromise.

I have implemented SPF and for me the big downside is that OTHERS don't check it and pay attention to what I've implemented. I still get bounced email which the receiver SHOULD have ignored as forged because it failed SPF checks, but they didn't and bounced it to me anyway.

So my complaint is that being responsible hasn't bought me as much as it should have.

You ARE asking people to throw away your own email

[CritterNYC]

The thing is that due to forwarding and vanity servers, you ARE asking people down the wire (which you can't predict and have NO control over) to throw away mail you sent. When you send to a buddy's vanity domain (that you don't know is a vanity domain) and it forwards your email to their ISP or work account that does check SPF records, your mail gets ditched. And you usually won't get any notice, so your email just disappears.

Using SPF increases the likelihood of your email getting sent into the ether to not return.

The SPF folks themselves acknowledge this as an issue and recommend using SRS to combat it. Of course, since no one uses SRS, it's still an issue.