Slashdot Mirror
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'?"
SPF is harmful.
Yes, I use an SPF for my domain. No I don't have any idea how effective it is, because my SPF record is used by other people. I haven't had any complaints about people not getting my mails.
There is nothing interesting going on at my blog
I use them for all of my domains, but I can't really see that it makes the first bit of difference.
Please stand clear of the doors, por favor mantenganse alejado de las puertas
If you maintain your own public DNS server you have no reason not to include SPF records, however many of the public DNS providers support little more than A CNAME and MX.
it has cut down tremendously on the spam claiming to be from my domains.
any other benefit I am unaware of.
If I could walk that way I wouldnt need cologne.
I publish spf records. But I don't check them for any incoming mail. I have seen some email rejected by spf checking. Last time was a internal contractor that had our domain's emails forwarded to godaddy hosted email. I would never reject mail based on an spf but I do publish if others if their dumb enough to reject mail.
Yes, and it's not very effective in the places that matter. My school has recently transitioned to Zimbra, which has been automatically sending anything from any of my domains into the Spam folder. (I also have DKIM set up, but that didn't help. As far as I know my IP isn't on any blacklists, so it should be getting through fine.... )
My UID is prime... is yours?
SPF records are easy to implement, but also easy to subvert (as one of the other posters already mentioned in his comment's link).
You should really look into implementing DomainKeys instead, which (while a little more difficult to set up) are almost required if you do any kind of significant email volume.
Yahoo, Gmail, MSN/Hotmail, and AOL pretty much require that you have DomainKeys implemented if you want to email their users, otherwise you'll find yourself on the wrong end of a blacklist someday.
Postfix can easily be set up with DomainKeys support using dkimproxy, check it here: http://dkimproxy.sourceforge.net/
Good luck!
"We'll need 2000 crickets, 4 cans of Easy Cheese, and the fluid from 18 glowsticks for this plan to work...." - ph0n1c
My SPF records have gotten me un-blacklisted a few times, after I've pointed out that those machines in Brazil weren't authorized to send email from my domains. But I think DomainKeys, DKIM, etc. will make eventually make SPF unnecessary.
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
Yes, I used SPF records on all the domains that I host that have email accounts. SPF records I believe have cut way down on backscatter. Before SPF, accounts would get dozens to hundreds of bounces when their email address was forged as the reply-to address in spam. Now the backscatter is almost completely gone.
But I can tell that Hotmail still ignores SPF since almost all the backscatter that still comes through is from Hotmail. They should know better.
Having valid SPF records also helps outgoing mail get through. I would frequently have to deal with large ISPs that would flag my mail or my domain as a spam source, based on their misinterpretation of forged headers. But since I have SPF records in place, this has not happened. I also check incoming SPF. If the SPF check fails, the mail is dumped. If SPF passes or there's no SPF, it goes through. Works great as one step in spam control.
SPF has been around for at least a couple of years, but at least one very large hosting provider - hostgator.com - hasn't made it any easier to implement. They still require that you email them and request that they set it up for you.
http://forums.hostgator.com/custom-mx-and-spf-records-t58820.html
When information is power, privacy is freedom.
and spamhaus put me on the pbl as well. (I don't send spam)
-- Programming with boost is like building a house with lego. It's a cool but I wouldn't want to live in it
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?
8 of 13 people found this answer helpful. Did you?
Some spam filters score on SPF. So not having SPF increases chance of false positives for your legitimate mail when you don't have SPF. And since SPF is free and painless to implement (just few DNS records) I don't see any reason not to use it. Also not like it is something that much significant either.
It's been, umm, a very long time since I've been to confession.
It's true, I don't use SPF. I've at least got the TXT line in my DNS hosts file.
But I'm using exim, which only has experimental support, and I'm too afraid to use something experimental like that.
What should I do, server?
// file: mice.h
#include "frickin_lasers.h"
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.
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.
DKIM (formerly known as Domain Keys) is more sophisticated and worth looking into in addition to SPF. I'm using an implementation called DKIMproxy, which runs as a daemon and is specifically designed to work with postfix. I've been fairly happy with it. What's helpful about it is that if I get mail from someone who implements DKIM, I can be sure that it's really from them, and likewise if I get joe-jobbed, I can convince the recipient that the spam wasn't actually from me. The biggest and best known users of DKIM are gmail and yahoo, but I'm seeing it used elsewhere as well. For example, I recently got spam from lulu.com, and the good news was that it was DKIM-signed, so I could be sure it wasn't a joe job.
I understand what you mean about establishing a good reputation in terms of the email you send. Actually many of the big email providers have a policy of blacklisting all domains by default these days, and waiting for the domain operators to contact them and ask to be allowed to send mail to them. Both AOL and yahoo seem to do this. With yahoo, you can fill out a form to convince them you're not evil, and if the info on the form satisfies them, they stop blacklisting you. One of their criteria is that they're more likely to approve you if you implement DKIM. If you tell them you're using DKIM, then they won't accept mail from your domain that isn't DKIM-signed; this is to your advantage, because then their users won't be clicking on the spam button on mail that claims to be from you but isn't.
Find free books.
Its not helpful in reducing SPAM unless or until every uses it. Why because you can't toss out mail from domains without SPF records you'd loose to much HAM. You can only uses it to detect and reject spoofs from domains with SPF.
Its not good as an anti spoofing technique in general because there are lots of ways you could make it look like you were sending from the correct host. Possibly in conjunction with DNSSEC (something only being slowly adopted) and some enhancements to BGP you could get there buy SPF alone does not do it.
A public private key scheme on the message bodies would, be much much more secure, and reliable for the anti spoof use.
Sometimes you want to temporarily run your mail out a different IP or relay from another domain, and if you used SPF and your recipients have the dns record cached you are kinda screwed if you need to do anything in a hurry.
SPF is an infective solution at best and really amounts to needless complexity which can only cause problems at worst.
The SPAM and tamper issues are both better solved with message signing.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
I use it on all my domains, and check it on all inbound mail. I especially make sure i define no servers are valid for several domains I have that are web pages only, or use for throwaway e-mail addresses (i receive e-mail at that domain, never send from that domain.)
I do support a domain hosted on google apps and setting it up for that ends up with a less firm ~all option that allows bogus senders to slip through.
I can see SPF fails in my logs so it looks like many other domains are using it as well.
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.
i use spf and DKIM. works fine :) well it is a low traffic domain :)
the bigger issue will be ppl that forward all their shit to other mailboxes... it is always "great" to see lots of it being rejected due "spam"
disable forward - enable pop3 fetch.
If you aren't using SPF, you aren't doing your job. I've become merciless in my dealings with other sites who don't use SPF, or even worse publish incorrect SPF.
I publish SPF records for my company and I check them, if SPF FAILS or SOFTFAILS it gets an SCL that will filter it into Junk. If SPF is OK or there is no SPF it continues through the process.
SPF is the way to go. Most public email out there (GMail, Hotmail, Yahoo) will mark email as spam if an email is sent from a server that isn't listed on the SPF record.
Obviously this isn't the only technique to fight spam (You validate that the sender really belongs to X.com, not that X.com isn't a spammer), but it helps.
As for the link to "SPF is harmful", that's about the biggest load of bull I've ever seen. It's inaccurate, and is an uncommon case (how often does mail forwarding happen these days with everyone using non-ISP-bound free email services?). It's like saying we should shutdown the internet because it's not completely accessible to devices with black&white screens.
As I said before, all the major free email service providers take SPF into account (test it out yourself - setup your domain with SPF, and send an email to your gmail/hotmail from an unauthorized IP).
That said, SPF is pretty easy to setup. Just a quick little txt in your domain and you're good to go. This site will help you with generating your SPF:
http://www.openspf.org/Tools
Before implementing an SPF record, my mail server IP was getting put on all sorts of blacklists. People were sending mail claiming to be from my domain and it was causing me to get on the BLs; all the major ones like CBL, Barracuda, Spamhaus, etc. Anytime anyone would try and send mail to me it would be rejected. I don't use SPF for checking incoming mail, I have the mail checked against a few RBLs and anti-spam software.
This is actually a very interesting subject, and it comes with interesting examples.
Lets take Denmark, we have a few banks here (like any country)
some month ago none of the banks had spf records, i checked up on this because i got hired at a bank myself.
So, of course it happened, one of the banks was hit by a phishing attack, which is between fairly easy and laughable easy if you don't bother with SPF records.
The bank hit was this one:
danskebank.dk text = "v=spf1 a:n50422.danskebank.com a:n50423.danskebank.com a:n70422.danskebank.com a:n70423.danskebank.com -all"
Afterwards it was still the only bank with an spf record, can see now new ones have joined
nykredit.dk text = "v=spf1 +include:jndata.dk +include:bounce.peytz.dk ?all"
but not all of them
*** Can't find brfkredit.dk: No answer
*** Can't find eikbank.dk: No answer
*** Can't find jyskebank.dk: No answer
*** Can't find sparnord.dk: No answer
the list goes on.
anyways, the funny part is checking who is actually sending from their domains (sorry, account required to see the sender ips)
https://www.senderscore.org/lookup.php?lookup=danskebank.dk&ipLookup.x=0&ipLookup.y=0
https://www.senderscore.org/lookup.php?lookup=jyskebank.dk&ipLookup.x=0&ipLookup.y=0
https://www.senderscore.org/lookup.php?lookup=nykredit.dk&ipLookup.x=0&ipLookup.y=0
ect.
the interesting thing is that spammers seem to have a better reputation than the actual banks sending.
To sum it up
DON'T BE A FUCKING IDIOT, GET THOSE SPF RECORDS UP OR I CAN, WITHOUT ANYONE PROVING OTHERWISE, SEND LEGITIMATE MAILS FROM YOUR DOMAINS.
don't be a bank
I also use SPF records for all my domains, most are simply: "v=spf1 a mx -all". "-all" as in hard fail. I don't know why there is a soft fail "~all" option, if it's not from a known host / IP, it should fail. What's the point in returning an unknown response? Like as if there was no SPF record in the first place? It's amazing how many domains actually use soft fail. Anyone know why? They only help stop backscatter and other IPs from sending emails from @youdomain.com as long as the other mail server does a SPF lookup. We have become dependant on the email protocol and the way it works, pitty it's in such a mess :( Damn you SPAMBOTS!!!
In the summer I like to use SPF-15 or higher. In the winter it's pretty cloudy around here, so I don't bother.
#DeleteChrome
I do use it on the handful of domains I admin.
My ISP (satisfied customer for 20 years!) uses a very effective anti-spam device (http://www.escom.com) that includes SPF checking. (No business connection, just a very satisfied customer. I get less than 1 spam/quarter that isn't trapped in quarantine or flat rejected...)
I'm appalled at the "professional" electronic contact service companies that fail to set up SPF records, e.g. Bronto.com that sends emails on behalf of the IEEE Computer Society. If this is your business, you have every obligation to make sure your services on behalf of -paying customers- are properly configured, even if some anti-spam devices do not use SPF as part of their spam detection approach.
Failure to include SPF records usually causes an email to get trapped in quarantine on my ISP. That's not "catastrophic" but it is most certainly annoying for something that can be very easily prevented, particularly by companies/organizations that actively invest in email.
SPF is great. It's one of the technical means of making sure that the IP address that is trying to send you a message is authorized to use the sender that it claims to be from. That means you can automatically reject spam that claims to be from any of the big mailers.
One common problem right now, is misconfigured mail servers. An e-mail admin configures the SPF entry in DNS, and then forgets about it. Then they change their IP address, or they outsource their e-mail to a third party, and suddenly, SPF is saying that all of their legit mail is not legit. The other problem is when a company has (for example) an order fulfillment system that generates its own e-mails, instead of routing them through the proper mail server. If that system isn't identified in the SPF entry, those messages can be rejected.
Another "problem" is when organizations send messages on behalf of other individuals or organizations (like the legit message that avon.com tried to send me this morning that was being generated by filltek.com, but without the permission of avon.com's SPF entry). I put "problem" in quotes, because really, third party messaging services should not forge the From line of the message.
On the other hand, it's great, in that it blocks all those stupid e-cards, because they claim to be from your.friend@gmail.com, when really they're being sent by stupid-e-card.com.
The biggest problem is dealing with "forwarding" services, like your @acm.org e-mail address. On my server, I have to keep a list of domains that "bypass" SPF checks, because any message sent to a forwarded address is going to arrive at your mail server from the forwarded (i.e. mail.acm.org), but it's going to have the header information associated with the original message. OpenSPF.org talks about some ways to deal with this, but I haven't look at it in a while.
Since SPF is still not universally accepted, it has a "soft fail" option that you can use for testing, until you're sure that it works the way you want it to. It's not the be-all-and-end-all, but it is a useful piece of the puzzle.
I was recently appointed a IT Manager and was told to stop the spam, as management was getting atleast 300 spam a day, each.
:(
Our current email provider would NOT implement DKIM, but I did have control to my domain records.
SPF is too easy to implement; see http://www.openspf.org/
DKIM on the other hand took a while, i tried DKIMproxy but couldn't get it to sign messages outside the local network so i moved to amavis, see; http://www.faqforge.com/linux/how-to-enable-dkim-email-signatures-in-amavisd-new-and-ispconfig-3/
There is plenty of manuals and support on how to implement SPF and DKIM i do not see why (for the benefit of the provider) its not being implemented.
I have seen so many web hosts provide hosting and disable this feature its inexcusable.
SPF: proves an email should only be legitimised if the sender server matches the record; as many assume its not an anti-spam mesure but to ensure that the server you send from doesnt send spam through your domain.
DKIM: proves that the email sent WAS from your server by referencing the key generated in the email to the one on your public DNS record.
combining both ensures people receiving your email that you are the one sending it and that you sent it from your server.
By implementing SPF, DKIM and DNSBL (you should see the amount of spam that gets denied now) my boss' spam has reached to probably 5 a day with is a protection rate on 98.4% only issue i have is with china, since we communicate with manufacturers in china and they have a huge spam rate it can get complicated.
there are two methods, stop spam from sending to you (DNSBL) and stop spam from sending from you (SPF and DKIM) the latter ensures people will get your email, the former still blocks legitimate email from blocked IP's which is still a worry
It's not a typo if you understood the meaning!
I have strict "-all" SPF records on all my web sites. But I still get mail bounces from joe-jobs that the recipient host should have rejected during the SMTP session from the spammer.
Last time I looked, forwarding was a show-stopper. Sender rewriting was complicated, and user's mail client configs would be broken if they used a local SMTP server at home or while travelling.
I've been running a few emails domains of my own for years. Adding SPF checking on the receive end provided me with a few decent benefits:
1. Adding SPF record got rid of backscatter almost completely (a benefit mentioned by another poster already)
2. Adding SPF checking on the receive end got rid of "addressed to self" spam 100% - that was 2-15 emails a day for different mailboxes
3. Rejecting emails per SPF record actually manages to reject over 50% of what would have ended up in my junkmail folder anyways, makes it much easier to scan through junk
4. I setup my server to actually reject the emails with an informative message. This means that if a valid email gets rejected, the sending server (not my server) should send a delivery failure to the sender. Without this that email would have likely ended up in an overcrowded junkmail folder anyways, which means I may have just deleted it - better that the sender knows
5. The SPF result on the receive end is also factored-in by the Intelligent Message Filtering of the Exchange, which assigns a spam likelyhood for spam. I setup a threshold for the spam likelyhood which also rejects the email during the receive, leaving the burden of sending non delivery message to the sender server (so valid servers do it, spam bots don't).
6. Tarpitting also helped a bit for spam rejection, though unrelated to the SPF record.
PS> This is about usefulness of SPF, not about my choice of servers, but if you really want to know I use both Exchange and Postfix to route my mails to appropriate mailboxes. Both have features the other doesn't (e.g. Postfix wildcarding, unlimitted mailboxes, etc | Exchange Blackberry Enterprise Server integration, calendar, contacts, SPF integrated with IMF, OWA, etc).
I work for an organisation that has a private email system (private as in hardware, network lines). SPF works fine on that, though is also redundant. However, the network is accessible to other networks (ie the internet, as in, people can send mail to regular mail addresses, and vice versa), and SPF breaks here.
Due to the jump to the network, the "sender" is always the provider who handles said connectivity, where our area of the private network touches the internet. Thus we've had to completely disable SPF as it always comes back with negative results.
A good idea in principle, but fails when the two mail servers cannot immediately talk to one another. You'd need something like a validation chain to allow that scenario to work.
Yes, I use SPF to identify the MX's of three domains I own, and Yes I use SPF as one of the things SpamAssassin uses for identifying spam. Granted these domains are tiny in the grand scheme of things (one is for family, one for some shareware I wrote, and one for a non-profit my brother is involved in), but it definitely helps. I wrote a script that sends me monthly stats of spam, and here are the results for the last month:
sa score : 1 messages :299 :194 :235 :299 :477 :597
sa score : 2 messages
sa score : 3 messages
sa score : 4 messages
sa score : 5 messages
sa score : 6 messages
sa score > 10 messages : 31678
highest sa score = 57
total probable spam (sa score of 5 or more) : 32752
total spam blocked outright by sa : 37110
e-mail blocked via SPF : 3007
Unique IP's that passed SPF check : 1389
We only block spam if the SpamAssassin score is above 10, but we tag anything above 5 as spam so the end users can decide what to do with it. As far as SPF goes, in the last month over 3000 bogus e-mails were dropped due to SPF failures, and 1389 other e-mails that were accepted were approved in part because the domains had SPF records that passed the check.
...in conjunction with my DynDNS vanity domain. When I first set it up, there was a rush of backscatter, then it tapered off and went away, never to return.
More recently I've started having problems of a different sort. I've been on a certain mailing list for over a year, though not posting very often. Last week I posted to a thread, and got an SPF violation notice from what looks like AOL in Australia, on behalf of someone with 2 apparent domains, neither of which is AOL. The violation notices seem to think that MY mail is originating from an AOL server, so the AOL server is generating an SPF fail. These notices are being generated for only one list subscriber, for every time I post to the list. It looks like a misconfigured AOL server (Would you expect anything else?) to me. Still, that's one aspect of SPF and presumably DKIM - other peoples' misconfigured machines.
The living have better things to do than to continue hating the dead.
I set it up and regret it. First, it broke things for one of my correspondents (at least this one — who bothered to tell me about it), who forwards all e-mails to his cell-phone. Because the messages are forwarded by his e-mail provider, but appear as if from me, his cell-phone service rejects them — because his e-mail provider is not listed in my SPF-record. So, he finds my messages in his mailbox, but is not alerted about them (as he is used to) by his phone...
Then, it turned out, my SPF-record is set slightly incorrectly, which — bizarrely enough — causes outright rejection by many servers. In this respect, people with buggy SPF-records are treated worse, than people without it... This is partially my fault, so this second item is just here for general interest.
And lastly, I am still a victim of "Joe jobs" every once in a while, as spammers send spam with the "From" set to my domain — my having an SPF record is not much of a deterrent, evidently.
Overall, the broken forwarding is, probably, responsible for slow adoption, which, in turn, makes it ineffective for the adopters...
In Soviet Washington the swamp drains you.
If you're in business, or if you care about your domain's reputation, you should be implementing SPF to prevent others from sending mail (aka joe-jobbing) as your domain.
Even if you DON'T care about your reputation, your life will be easier if you don't have to deal with the back-scatter (complaints, threats, invalid postmaster replies, out of office messages, etc) from a massive joe-job/spamming effort which is spoofing your domain.
You CAN make a substantial dent in these types of attacks with SPF. There are levels of SPF "certainty". In order to be most effective, you need to list all your sending servers with a dash "-all" for example, a major financial uses:
text ="v=spf1 ip4:207.162.228.0/24 [shortened] -all"
On the receiving side, most SPF implementations will (and should) respect the certainty of the senders SPF record. In the above example the financial implemented the "-all" qualifier, so if mail comes in from a place not on that list, based on their assertion I can safely drop it as spam. If they used a "?all" or other, I might only increment the spam probability or tag it [maybe spam].
When implementing your DNS SPF record, it can take time to make sure you've identified all the legit sender's of mail with your domain name if you're a large company. Keep at it and come back here and let me know, I'll give you a pat on the virtual back for doing THE RIGHT THING.
http://www.openspf.org/
A few people are inconvenienced because they have to connect to a different port then the default due to ISP firewalling.
I would really really like it if more ISPs were checking them and silently discard anything that is flagged as spam _AND_ fails SPF instead of bouncing it back.
We get thousands of bounces addressed to non-existant users, which in turn makes into a double bounce. Of course now I've set our system to silently delete them instead. Else it's just a colossal waste of resources.
A very restricted SPF TXT record that specifies _precisely_ which IP addresses an incoming SMTP for a given domain an email _must_ come from cannot hurt. At best, your IT admins have wasted a half hour, at best they have significantly improved the chance of your outgoing email being not treated as suspicious by bulk email handlers such as yahoo, gmail and hotmail (especially hotmail).
You want proof? Check your shit. http://postmaster.live.com/Services.aspx . And no, I don't work for MS, but damn they provide the best postmaster tools on the interweb for monitoring shit like email deliverability. Don't even talk to me about the pestilence that is Yahoo!, those pricks remind me of my evil DM who used to make up pointless forms just to pass the time.
I use them because you can't send to some domains without an SFP record. Mainly Asian email providers, but our business has alost of agents in Asia so the mail has to flow.
SPF serves multiple purposes for me.
Why I add SPF records to our DNS servers:
First and formost, it tells everyone who my mail senders are and that they should only accept mail from my users from those servers. Thats really all it does, but that results in the following things for me:
My remote users always configure their outbound mail server as our gateway, rather than their own ISP or something like that, which means that all that mail piping through me means I can do all sorts of sanity checking on the server for my users. It doesn't force them to use our mail server, but if they do, they'll end up sending to someone at Google or Yahoo who'll reject the message, at which point my user will generally have the problem fixed.
More important however is that it cuts down tremendously on backscatter spam I get.
Why I look for it when receiving mail:
Helps stop our auto-response mail addresses from producing a bunch of backscatter when they get spammed.
Stops scammers who use email addresses from large well known businesses in an attempt to make their messages look more legitimate. Pretty much every major company worth its weight in air publishes SPF records.
Problems:
It seems that services which host frontend stores for things like hotel rooms and travel seem to not understand that the server sending all their confirmation emails should probably be included in the SPF list.
Thats the only thing I've run into, on hotels and ticket purchasing web sites that are managed by 3rd parties, and send messages as if they were actual company. Universal Studios has had this problem with their ticket ordering system for at least the last 3 Halloween Horror nights :( Seen it with a couple hotel sites as well.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I would use domain keys and SPF but... i use google apps. So i could use SPF records... but personally i prefer domain keys and don't want to use one without the other. Having pointed out to my computer faculty that they had an SPF which allowed only one host(/32) (it wasn't the mail server! ) and the admin thought that softfail was soft pass .... i personally recommend against using SPF unless you do it correctly.
I didn't used to use SPF records for my domains. I always felt that it was a pretty half-assed way to prevent forged spam from my domain since it required the admins of other mail servers to enable SPF checking in the first place.
Then I started getting a ton of backscatter in my inbox. Just out of the blue, some spammer had decided to start using my domain name for cialis spam and next thing I know, my inbox is flooded with rejected messages bouncing back to me. I set up SPF as kind of a desperation play more than anything else and the backscatter disappeared almost overnight. I'm sure someone out there is still receiving spam which appears to be sent from my domain, but the volume of backscatter I'm getting isn't even a tenth of what it once was. SPF is good for something.
We both publish and use SPF records. We publish them in an attempt to limit backscatter from joe-jobs, but that's not very successful. Nevertheless, I like the idea of being able to declare which machines are legitimately allowed to send mail for my domain.
We also use SPF records, but in a careful way. We add lots of points for SPF "fail" results from certain domains like paypal.com, ebay.com, etc. We add a moderate number of points for SPF "fails" from domains not in that list. We subtract points for SPF "pass" results from certain trusted domains.
We certainly do not subtract points for SPF "pass" from some random domain; we have no reason to trust it. In fact, for a while, an SPF "pass" result was a mild indicator of spam, as spammers registered throwaway domains and published SPF records.
I am one of the admins for the free email service Lavabit. We have a graph on the net showing adoption, built from about 150k messages a day. (We don't include messages for users who have disabled this inbound check, or for messages which are blocked for some reason other than SPF.)
http://lauren.lavabit.com/export/graph_162.html
I use them for all the domains I manage (maybe about 200+ domains) and forged spam has disappeared since. It doesn't take that much time to set it up, so why not do it?
We use Postini, and postini handles the delivery of our mail. We have yet to have any organization block our mail while it is delivered by postini. It seems that most mail admins implicitly trust that postini's servers aren't spewing spam.
As far as postini's position on using SPF to identify spam:
Postini has investigated SPF and has decided not to implement it as a
feature for inbound mail processing. Implementing SPF would add
significant processing overhead without adding any appreciable
effectiveness to the spam filtering. Almost all mail that would be
blocked by SPF are also identified as spam by our spam filters.
In addition, Postini tracks the IP addresses of Fortune 500
corporations and the most popular internet sites such as Yahoo,
Hotmail, eBay, etc. Adding these domains to the Approved Senders list,
particularly at the organization level, is not usually needed and can
result in spam appearing to be sent from those domains inadvertently
getting to users' mailboxes. For this reason, Postini recommends
against using the Approved Senders list in this way; rather, it should
be used only for mail from senders that has previously been falsely
quarantined as spam.
The other reason I have not published and SPF record: Verizon is hosting our DNS services, and when I asked their business services about adding SPF records to my domain the guy on the other end of the telephone had NO idea what I was talking about.
After 3 or 4 call transfers I just gave up.
-ted
... in my last job, we had a lot of clients using Microsofts mail services. M$ gave you basically two choices: Implement SPF or have your mails delivered to the spam folder or refused. So, we made our DNS provider add SPF records and the problem was gone.
Tux2000
Denken hilft.
I'm "kinda" using it, in that yes, I setup an SPF record for my domain at work, but I'm not actively checking the SPF records of any incoming mail. I kinda question whether it's of any use at all. I set up our record because it seemed the wise thing to do, but honestly given how many domains don't have SPF records setup I'm not sure ANYONE is actively checking them for incoming mail. Without more usage the system is kinda useless.
"People who think they know everything are very annoying to those of us who do."-Mark Twain
If you use SPF, you only succeed in getting your own email deleted.
When you send email to your buddy, let's call him Jim, with his own vanity domain, it gets forwarded to his ISP email account. Since his ISP is checking SPF records, it'll check your domain's, see that your email isn't coming from your own server (it's coming from Jim's vanity domain host) and block it. Like most vanity domain hosts, no message will be sent back to you to let you know your mail was blocked.
Congratulations, you just got your own legitimate email blocked and disappeared with no way for you or your friend Jim to know.
SPF makes incorrect assumptions about the way everyone uses email. It then attempts to make up for these incorrect assumptions by suggesting that everyone use SRS... which, of course, no one uses.
If you use SPF, you get your own email deleted. Don't use SPF.
Portable versions of Firefox, GIMP, LibreOffice, etc
...No, we do not use or publish SPF records in any way. Spamassassin assigns a score of zero to the SPF_PASS rule for incoming email.
Every 6-12 months or so, someone asks why. The reasons have not changed in the several years that I've been here:
* For a large, non-centralized research institution like ours, any SPF record we could conceivably come up with would have to be permissive to the point of rendering it useless. We have countless departments, nearly a hundred thousand users, and they all have their clients (both on and off campus) configured about a hundred different ways. Some relay through our servers, some through their ISPs (either by choice or due to a heavy-handed ISP filtering policy that restricts outbound SMTP on TCP/25 and/or TCP/587), some through departmental servers, some through sendmail running on their own workstations (damn you, CS faculty). The work necessary to construct, publish, and maintain an SPF record for our purposes has been deemed not worth the effort.
* SPF has been embraced widely by spammers, perhaps more so than legitimate institutions. This alone keeps us from assigning any stock to SPF records when making delivery decisions on our own incoming mail.
We have yet to encounter any notable issues getting our mail delivered to the "big boys" like Hotmail, Google, Yahoo, etc. based on our lack of SPF kool-aid consumption.
The only times I've come across SPF servers it's been an employee at my company asking why they got an email from a foreign server 'warning' them that because _we_ don't use SPF there's something wrong with _our_ email system.
1. If everyone isn't using it, it's not a standard.
2. Soft-warnings to uneducated people result in busy-work for IT people. Worse yet, try explaining to a marketing person that no, in fact, OUR email system works fine, it's the remote guy's server that's got the issue.
SPF is a good idea in theory and if everyone used it (and it worked properly) it'd be great. But we don't and I won't be switching until a real solution is available that gets adopted by everyone. Sorry folks, email isn't going to be changing drastically any time soon.
If we were smart we'd set everyone to be white-list email only, if an email bounces the sender is told to call you on the phone and get a whitelist one-time-code to get added to your list. Everything else is just going to be statistical attempts at solving this problem which will never be 100% correct. Either spam gets through or important email gets lost.
I've just today been reading up on SPF records. My problem is that mail coming from a new server we've set up is being spammed by Big Mail (Gmail, Hotmail, etc.).
The server has a primary domain (domain.com) but many other domains are hosted on it too (eg. mine.com). When I try to send mail with the from field set to me@mine.com (as opposed to me@domain.com) it gets spammed.
We're not on any blacklists, the A records for mine.com point to domain.com as do the MX records, domain.com has PTR records, and I've just put in a SPF record for mine.com.
So far no luck. Sigh.
"Katrina"
Remember that huricane? Nocked lots of companies offline for more then 4 hours and people couldn't change an SPF record if they wanted to due to the evacuations. Another was Loma Prieta in 1991 during the World Series Game. San Francisco, CA 6.9 Earthquake with lots of damage. Another was the St. Helens Eruption in Washington. I could go on but I think you've got the message, which is Natural Disasters. These could affect large areas and result in SPF being absolutely useless because people simply can't transfer their Email service even temporarilly and I'm not talking the Mom and Pop shops, I'm talking places like RacSpace and other Hosts like them. Get a major disaster in a location where some major hosting providers are and you're talking an email meltdown because of SPF only but if combined with DKIM, you might have a chance.
Mod me up/Mod me down: I wont frown as I've no crown
for incoming mail to a college campus with 3,000 students, and I presume outgoing. Nobody complains. (I did have one complaint, and it was weird. Not at all related I don't think, but it was "My mail's not getting through.")
--Sam
I publish SPF records.
I administer SurgeMail mail software.
Senders that don't publish SPF records are dodgy sources, and they get an automatic penalty, unless the source IP matches the MX record and listens on port 25.
Automatic +5.0 to spam score. Basically assures the sender will be hit by graylisting, and the message may ultimately be classified spam.
Fail to publish proper SPF records at you and your users' peril.
I use greylisting to reduce spam volume, and I whitelist outgoing mail servers for domains that a) have trouble with greylisting and b) publish SPF records. In other words, I use SPF given existing trust for a particular domain, but only if not relying on SPF causes problems. I thought I hadn't set up SPF records for my own (vanity) domains, but apparently I have... not that I particularly notice. It's just not a big deal.
--Matthew
I've used this on various servers. A couple had high rates of forged email before and it was reduced after. Mind I also put a lot of other email security in place so it could have been that too. We had hard requirements for validity internally and soft for external - which helped a lot more in tracing down some internal computers that had been compromised.
I run a server farm somewhere between a /14 and a /17.
All authorized mail servers have SPF records. Ranges that clearly have no legitimate business sending email are clearly identified with XXX-XXX-XXX-XXX.dynamic.TLD and listed with SpamHaus's PBL.
No servers have DKIM/DK. The software to do so is opaque, testing is difficult to impossible, and the benefits over SPF are unclear at best, dubious at worst.
On about 1/3 of the servers, all Yahoo email is blocked out of hand due to the disgust and irritation of the server owner over Yahoo!'s blocking/delaying/spam problems. One server owner told me, "My mail TO them is blocked or delayed. But unless I use DKIM/DK, they won't tell me what the problem *is*. Since my own spam load is roughly 40% FROM yahoo!, screw 'em."
Yahoo!'s insistence on DKIM/DK is highly suspect in the cases, like mine, where a responsive, active abuse desk that will address a spam issue if it's from our clearly identifiable ARIN allocation is available.
For those customers that choose not to accept Yahoo email, we return an error message generally worded like so:
"We're sorry, but due to Yahoo! polices we strongly disagree with, we will not accept your email. Please use another email service that doesn't have it's head up it's ass."
It isn't phrased quite so bluntly, but the flavor is still there.
When I get complaints that Yahoo! won't take a customer's email, I tell them, "Yahoo! is a free service. Their customers are getting all they pay for. I'd like to help you, but frankly, I can't get them on the phone or to give a reasonable response via e-mail. Your best bet is to require a contact method that refuses or bypasses Yahoo!. They aren't in the business of giving their customers reliable email service."
Do I have problems? I'm sure I do. But since Yahoo! won't discuss them without jumping through their useless DKIM/DK hoops, I'll just ignore it and move on.
Necessity is the plea for every infringement of human freedom. It is the argument of tyrants; it is the creed of slaves.
SPF is not an anti-spam measure, it's about preventing hijacking of domains. People often seem to say "but spammers publish SPF records", and that is true, but it doesn't mean that SPF is not effective.
SPF allows me to publish information about what systems will legitimately send e-mail using that domain. It also allows me to act on that information published by other third parties.
What this means is that I have to deal with dramatically less backscatter spam. Since implementing SPF, I have not woken up to find 100,000 messages in my box that were bounces or outraged replies to spam sent by someone else. Back in 1995 that exact issue happened to me, and to a lesser degree it happened regularly until SPF.
There are, of course, some difficulties with SPF, but despite those I have chosen to use and advocate SPF.
You do have to deal with legitimate third-parties sending mail from your domain. We use an outsourced accounting package and have had to include their servers in our SPF records. No big deal.
As a recipient, if you have one account forwarding to another, and the destination account implements SPF, then you either need to white-list the forwarding machine(s), or you need to implement SRS there.
DKIM and it's variants is, IMHO, useless because it only allows you to prove that e-mail came from an authorized sender for a domain, it does *NOT* allow you to tell if e-mail came from an UNAUTHORIZED system for a domain. You cannot use DKIM to tell if a sender address is forging the domain.
So DKIM is *NOT* a "better SPF". They *ARE* compatible though. If you get a message claiming to be from a specific domain which fails the SPF check, you probably still want to allow it if it passes DKIM. I don't know of any mail programs that do that though. The unfortunate thing about this is that SPF-only can be implemented entirely at SMTP time (RECV FROM) where SPF+DKIM would have to be implemented after receiving the message (after DATA).
Sean
Yahoo absolutely uses SPF in conjunction with other methods to authenticate senders with high volumes
I currently use SPF, and am thinking about dropping it. It causes me a massive pain in my ass every time some dumbass with a misconfigured forwarder doesn't understand SPF or SRS, and tries to blame me for the fact that they can't receive email from me. There just aren't enough large sites sending SPF-enabled mail for misconfigured receiving sites to realize they're doin' it wrong.
All my clients in australia are configured with SPF - I consider it essential at guarding against spoofing.
and sign their emails with public keys. That way you can store their public keys on your system to verify it is a valid email.
I really am not sure why PGP or GPG isn't added to Email servers to verify email. Most email clients work with them and if email clients and servers are modified to use PGP or GPG encryption to connect and send out messages and automatically sign them then the servers can verify the sender via the private key and passphrase and lock out the spammers and scammers. Anyone who does send scams or spams can be identified by their signature key which would be required to send an email.
Most scammers and spammers use Botnets that have built in SMTP servers that they can use via remote control to send email and fake the headers and SPF and fake being from a domain that isn't black listed. Not only would you have to change how email clients and servers work, but you'd have to find a way for millions of Microsoft Windows clients to avoid being infected with trojans to be part of a Botnet that fakes SMTP messages.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
I have Dreamhost. They provide a copy and paste line for a DNS entry. See http://wiki.dreamhost.com/SPF
It's one of those things that won't be useful until just about everybody has implemented it. The way it works is by defining which IPs can send email purporting to be from a domain; if you receive an email "from" a yahoo address but coming from some cable modem, you can block it. And as long as not everyone has SPF, you can't just block emails that fail a SPF check...
So yes - I do use it. But it's mostly altruistic, as it really has no effect on incoming email unless you just block no/invalid SPF.
I don't understand why everybody doesn't just enable it - it's a few minutes' worth of a TXT field.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
8 Billion web pages, which one, exactly, are you looking for?
8 Billion. And that's a very conservative number. How do you find what you don't know what you are looking for? I'll describe my setup to cut through the information overload of today's world.
Most of these functions are built into my browser, Chrome, through extensions but other browsers are more than capable of doing them as well: especially Firefox. Internet Explorer is the most limited here but even it can access most of these functions through straight web-interfaces - although clunky.
The basis of all the following systems is the RSS Feed. It is a method of condensing a website into a synopsis of stories which are then linked to. The place to begin with RSS feeds is to get yourself a Gmail account. This single log-on will allow you to access the whole range of Google Web-Services. After you do that you sign up for Google Reader with your gmail login. You can then begin to add feeds from your favorite web-sites to that. You can, in Chrome, use an extension called: RSS Subscription to easily add feeds from your favorite web-sites to Reader. Once you have a good amount of feeds subscribed, the next step is to set up a Feedly account. Feedly integrates completely with Google Reader so you don't need reader other than a place to store your subscriptions. Feedly provides a magazine like summary of all of your favorite web-sites in one easy to use place through the magic of RSS Feeds. Now, on your second monitor you set up another web-site called Lazyfeed. I like to have this browser set to full-screen. Lazyfeed is organized by topics instead of web-sites and constantly updates as new stories appear on the web. Be specific in the topics you are interested with. Going beyond all of this, and all these services integrate seamlessly with this as well, is to use the micro-blogging service Twitter as a method to find the latest sites. Twitter can be clunky as a web-page, but again, if you integrate it into Chrome using an extension such as Chromed Bird then it actually operates in a very fluid manner. Twitter is another means of aggregation, you follow people who are interesting and if they find you interesting they follow you: providing links the entire time. The whole of these systems allows you to cut straight through all the fluff and find what interests you - even if you don't know what that is!
ProTip: When viewing items in Lazyfeed they all have an RSS button so you can subscribe to the complete feed in Reader and by extension Feedly!
Another, but less related system - especially if you download lots of books - is to use: Google Desktop which provides a side-bar and more importantly an indexer which will look inside all your files and provide Google Search to them. Very useful for going deeper.
Links:
http://en.wikipedia.org/wiki/RSS - RSS Description
http://www.google.ca/reader/ - Google Reader
https://chrome.google.com/extensions/detail/nlbjncdgjeocebhnmkbbbdekmmmcbfjd - RSS Subscription Extension
http://www.feedly.com/ - Feedly
http://www.lazyfeed.com/ - Lazyfeed
http://twitter.com/ - Twitter
https://chrome.google.com/extensions/detail/encaiiljifbdbjlphpgpiimidegddhic - Chromed Bird
http://desktop.google.ca/en/?ignua=1 - Google Desktop
http://digiphile.wordpress.com/2009/12/17/linking-tweeting-and-social-search-on-the-human-curated-web/ - Article on social search
http://oneforty.com/ - Th
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.
Portable versions of Firefox, GIMP, LibreOffice, etc
I use SPF, but only to block known or likely forgeries. That is, an e-mail that claims to be from somehost.com AND somehost.com has SPF records, but the message fails the SPF test. In this case, either the message is forged, or the admin of somehost.com hasn't properly educated his users. I also block a very limited case of messages that claim to be from our own domain, but are in fact spoofed. It has to do with a mismatch of the From: header and the MAIL FROM response. You can read more about it here: http://www.eisbox.net/2009/07/23/2395-mail-from-vs-from-vs-sender-exploiting-spf/
I've had this floating around on my hard drive for quite a while, and have used it on occasion. Not sure if Yahoo still sends it out, but you get the drift from their questions....
Yahoo's 17 Questions
1. Do you rent, lease, buy or otherwise obtain email lists from companies, individuals, organizations, or websites (other than those you own) that do not indicate that the customer will be subscribed to this specific email list?
a. If yes, do you explicitly send an opt-in confirmation email to the email addresses you have acquired?
-- If yes, please send a text-only example of this email.
b. If no, please explain how you obtain email addresses.
2. How do you verify that the true owner of the email address you have obtained is valid?
3. Do you offer list management services for other companies (i.e., as an ASP)? If so, please provide us with your standards for accepting your clients' email lists.
4. Do you rent, lease, sell, or otherwise give email lists to other companies, individuals, organizations, or affiliates without providing notice to the email users that they will be subscribed to the buyer's specific email list?
5. Please indicate the information below pertaining to email sent to Yahoo! mail.
a. How frequently do you send email to Yahoo! users in a given month and how many emails are sent in the average mailing?
b. If you send email to multiple addresses, how many addresses are sent to, for an average mailing?
c. If you are an ASP, what has your average client mailing frequency been over the past six months?
d. Are you emails informational and subscriber based (newsletters)?
e. Are your emails for marketing to other than existing customers?
6. Please specify your policies pertaining to both soft (4xx) and hard (5xx) SMTP response codes or bounce messages.
a. Do you remove email addresses from your mail server or list if emails to them bounce?
Soft:
Hard:
b. How many bounced emails are required before you consider an email address to be inactive and subject to removal from your list?
Soft:
Hard:
-After an email address reaches your bounce limit, how long (i.e., minutes, hours, etc.) does it typically take to remove the email address from your list?
Soft:
Hard:
c. Are there any circumstances under which you ignore the standard definitions (4xx) being temporary and (5xx) being permanent, and instead apply your own non standard interpretation? If so, when/what/how?
7. If a user requests removal from your email list, how long (i.e., minutes, hours, etc.) does it typically take to remove the email address?
When user clicks an unsubscribe link (if applicable):
When user requests removal:
Other:
8. If a user is removed from your email list, what happens to that email address in your database?
9. Please copy and paste a text-only example of a recent mailing, having the delivery issue, including full Internet headers. Include the entire error message if email is being returned or undeliverable.
Within a Yahoo! Mail account, you can display this information by clicking the "Full Headers" link located within the message in the bottom right-hand corner.
10. Please provide all of the active email IP address(es) and domain names you are currently using to send your mailings including notes with regards to dedicated or shared status for each. We do request email administrators to describe which of their clients corresponds to each IP address. Please submit this information in the following format:
IP Address: xxx.xxx.xxx.xxx
Mail Server Domain Name: server_name.domain.com
Notes: dedicated IP, domain/list server
At this time we can only consider active and correctly configured mail servers/IPs for possible addition to the whitelist.
11. Are these IP addresses dedicated solely for your company's mai
My Doctor prescribed daily nasal saline irrigation, hehe
I set up DKIM and SPF on my mail server.
I still end up in the spam box on Yahoo and Hotmail. I'm guessing it's because I chose a semi-random four-character domain name which looks it could be a spammer domain. Why would I choose such a domain name? Because it's easy to type.
I keep waiting for Yahoo's system to whitelist me, since I send a considerable amount of email to my friends there, but after a year, every time I meet someone with a @yahoo.com address, I have to tell them to dig my first message to them out of their spam folder.
My SPF records all return as valid from the testers. Any suggestions?
... the last 3 times we attempted to, we had too many recipients rejecting our e-mails due to broken forwards.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Yes it does
If your mail does not arrive your supposted to get a helpful answer here: www.openspf.org/Why
It's been down for ages.
I tried to implement SPF for our clients not long after the spec was released, but found two problems with it:
* Most of our clients send e-mail through their ISP's MXs. Most of the ISPs wouldn't provide an SPF record with a list of all their outbound MXs that I could refer to.
* Even when I was able to set it up because the ISP was cooperative, the client often ended up complaining that messages they sent to mailing lists were being rejected.
Because of these two problems I wrote the system off as useless. The first is an administrative hassle that I cold do without, but the second produces false positive swhich is an absolute fail, IMO.
We are a small business. We're using a shared hosting service (quite big but still heavily abused). We used to have a regular stream of calls from people not getting our emails. We implemented SPF a year ago and have had no problems since.
There was a recent thread on the topic on the NANOG mainling list, see http://www.merit.edu/mail.archives/nanog/msg02874.html
http://www.openspf.org/ has been down all week and it has all the instructions
3 Install postfix-policyd-spf-perl
Next we download postfix-policyd-spf-perl from http://www.openspf.org/Software to the /usr/src/ directory and install it to the /usr/lib/postfix/ directory like this:
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
No Thanks, M$.
Use Public key infrastructure, register an email with a public directory. If the email sent from that address doesn't match the digital signature, then reject it - case closed ...
So now every poor sod that has set up a website for his school, his football club or friend's private business is asking himself: What should I do? Do I need to do anything at all?
While it's nice to hear that it doesn't mean a whole lot because it's not accepted or implemented widely, there is still something quick and easy you can start with to see where you stand.
Use http://www.trustedsource.org/query/mydomain.tld and they'll tell you where you stand today. Chances are, your ISP host has got SPF turned on already, and you're all cool if any overly officious school board member comes whining at you. It's a McAfee site, but it's free, and a good start to investigating further if you've really got the spare time to waste.
The server will forgive your sins, my son, if you say three Hail Linuses.
I host email for a bunch of small businesses, many of which work from their homes. When my clients' access to their own (my) mailserver is blocked by their ISP (comcast, verizon, etc.), they're forced to use their ISP's outgoing mailserver(s). I can't do SPF records for all the possible ISP outgoing servers, and that would defeat much of the purpose anyway, so I don't do SPF at all.
I'm on the big guys' (aol, comcast) feedback loop programs, and that seems to have been the biggest factor in getting them to accept lots of mail from my domains. That and having a rock-solid spam filtering setup for incoming mail so crap doesn't get forwarded out....
I did set up SPF some time back, but was soon contacted by quite a few of my users (I run the mail servers for our family with the family name as the domain) contacted me and said that they could not send E-mails to some destinations. The problem is that some ISPs demand that all outgoing mail go through their servers (in a spam-prevention measure) and my users therefore could not go directly through my servers. I could try to update my SPF-records with these servers, but that would be one more thing to administer -- and the same goes for setting up VPN connections to my servers and use it that way through. The latter also means more strain on my limited bandwidth.
In view of the problems and of the (so far) limited benefit from SPF, I will not use it.
The SPF headers in emails could help with the spam filter - I have mail rules that use the spam rank # in the header (from the server) combined with the SPF to mark emails as junk. This helped reduce a lot of spam: raise the bar for poor SPF results. I also filter spam from my own server using SPF, this cuts down on SOME spam; however, for some technical reasons I can't have a strict SPF record on all my domains and some spammers exploit that so I didn't remove all of it.
Also, I've noticed a huge majority of emails with the SPF header containing: "Maximum nesting level exceeded" and I've not noticed a single legit email with it. I just filter those out now.
When I momentarily tried stricter SPF policies I noticed all of the spammers who get past the normal filtering were using SPF; probably the 1st people to use SPF were the spammers. You know, SPF includes a "loose" mode where you essentially say: these are my mail servers but I might break from it. Strict SPF use stops spam (outside DNS spoofing) but I rarely see strict SPF and everybody would have to use it along with blacklists to stop spam. So many servers lack SPF completely that I couldn't ever require it.
Although, spammers adapt to any popular trick quickly - its their job to do so.
My wish is that more software use the X-Spam email headers... Would be nice if clients would indicate spam rank as well. So I still see the low chance spam but it is color coded (by degree) and the high chance spam is auto filed out of sight.
Democracy Now! - uncensored, anti-establishment news
Our annual survey of the Internet's DNS infrastructure measures (among other things) the percentage of a random sample of com, net and org subzones that use SPF. In the October 2009 survey, we found that 12.2% of the sample used SPF records. For more information, see http://dns.measurement-factory.com/surveys/200910.html
At the very least use ?all if you're an MTA slut.
...if a handful of AOL users flag your email as spam, AOL will not whitelist your server. This includes double-opt in email sent to verify registration for a newsletter or service. I swear to Bob, AOL use will mark these as spam then complain because they cannot register for your site.
We now simply tell potential registrants who enter an AOL address, "Sorry, get a real email service then we will talk."
Ignorance is curable, stupid is forever.
is add an authentication code to the return address on every message you send out. If you get a bounce to an address without the code, you know it was forged.
No doubt you thought of this, but is it possible the bounces are fake - i.e. not really from a Hotmail transmitter? Could also be that Microsoft really is screwing up their SPF checks, and the reason you are seeing more bogus bounces from them than everyone else, is that you have a specific spammer targeting your domain and not others.
Personally, I don't mind it at all. If a remote email address isn't set up correctly to receive emails with proper SPF records, it is their problem to deal with, not mine. My responsibility regarding email only extends to the point where the remote server accepts the email. Once that is done, it is their problem if they can't relay it properly.
I started using SPF because the backscatter from spammers forging my domain was getting to be 5-10 times more than the amount of spam I was getting. The backscatter stopped almost completely and it stopped immediately. Every once in a while I get a small burst of backscatter, but it doesn't last long.
I don't know this for sure, but I suspect that the spammers are checking for SPF before using a domain for forgeries. It would make sense, because using a domain with SPF records for spam makes it possible for anybody to determine it's spam. In particular, if any tier one suppliers are using SPF combined with mail volume to identify spam, they could spot the spam almost instantly -- no wait for complaints to come in. In particular, the spam could be spotted quickly enough to shut down the sender. It probably doesn't happen that much, but if one was sending spam, why would one forge a domain with an SPF record when there are so many others out there with no SPF record.
An engineer who ran for Congress. http://herbrobinson.us
I completely dislike SPF... I had to enable them when completely legitimate emails, from the company I work for, were blocked by SPAM Haus. The emails we were attempting to send were ALL properly solicited emails to customers that were using Yahoo and MSN / hotmail / live accounts. These email / webmail providers chose to use SPAM Haus Spam filtering and would bounce every email back. It took me almost 25 Hours to identify the problem and present a solution to my boss, who had to approve the change before I could add it to our mail servers. Also, I have to say that Microsoft surprisingly was very helpful and was able to assist me in identifying the problem ( well, after I was placed on hold for 3 of the 25 hours ) . So long story short I was quite mad about having a boss breathing down my neck to fix our mail systems while I was on a much earned and deserved vacation, since then SPF is still the bane of my existence and I would never have chosen to use it if I hadn't be made to.
I used to work for an antispam provider.
Interestingly in the first couple of years of SPF et al, were almost a guaranteed indicator of a spam domain - the spammers immediately implemented SPF to make their domains look more legitimate! Nowadays (as gujo-odori said), a valid SPF record is an indicator that the email has not been forged, but not whether it is spam or not.
There are two sides to SPF: having your own valid SPF record marginally improves the chance of your legitimate email being delivered correctly, but as has been alluded to by others, if you get it wrong or forget to update it when you change your email setup, then it could likewise adversely affect the delivery of your email. The other side of it is checking incoming email for SPF records: if the SPF record is invalid then there is a good chance it has been spoofed, but any other result (e.g. inconclusive or valid) does not necessarily mean that the email is worth reading!
We all know that SPF is an imperfect patch to an old, old system; SMTP We can't make a change that fixes spam but breaks SMTP so we are left with opt-in fixes or a total re-write (ala Google Wave) I have implemented SPF because for now it's all we have.
See subject. Nuff said.
Who is General Failure and why is he reading my hard disk?
We've been using SPF at our company for a while but it gave us so much trouble e.g. lots of bounced emails that we had to stop using it. We heard the same from our partners who've been giving it a try.