eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Last week my wife’s 90-year-old mother, Shirley Montner, finally convinced me to do E-mail Sender ID Authentication. You know, that industry-wide initiative to keep spammers from spoofing your domain in the “From” box?
Mom illuminated me in normal motherly fashion – via scolding. She couldn’t understand why I was not writing her after she took the time to learn how to do e-mail. Set aside for a minute that I was the one who taught her to do it.
Thing was, I knew I was innocent; I had sent her three e-mails in three days. I shrugged it off as operator error. She often forgets that you have to actually click on the messages in order to read them.
Confident I could give her a proper “I told you so,” I logged into her Gmail account. Sadly, however, she was right. There was no e-mail from me in her Inbox. Seems Gmail was putting all my e-mail into her Spam folder. It might as well be on Mars in my mom’s case.
The Spam Score – Three Strikes and You’re Out
A little investigating revealed to me why it was placing all my e-mail into her Spam folder. Even if you’re a good guy sending normal things to your mom, you get a Spam score. Three points and you’re out.
First, having “no sender ID authentication” counts as 2.4 Spam points. Ouch. Then I had embedded photos in my e-mails to her. (Attachments with her? You’re kidding, right?) That was another Spam point. So, there you have it: my e-mail to mom, and undoubtedly to a lot of other people, was tagged as “Spam.” Yikes!
A Sobering Realization Leads to Action
So, now you know how Mom finally convinced me to do E-mail Sender ID Authentication. Of course, my real concern was my PR business. I’d been looking at bounceback e-mails spoofing my domain for years but, unfortunately, my two hosting providers, EarthLink and 1and1, do not support Sender ID Authentication for hosted sites. Nor were they much help telling me what to do, which is even more irritating because it’s not that hard once you learn how to do it.
That’s where this article comes in. I spent about 40 hours figuring out how to implement E-mail Sender ID Authentication and actually doing it. (If you keep reading, I’ll cut that time down to about two hours for you). Here’s what I learned, how I did it and some great resources for you to check out.
What Is E-mail Sender ID Authentication?
E-mail Sender ID Authentication is a kind of telephone book that enables e-mail recipients to make sure an e-mail with your domain in the “From” line really came from someone at your organization. There are different standards, but I am going to explain how to do one called Sender Policy Framework (SPF). SPF works by checking incoming e-mail headers against an SPF record (i.e., a text file) stored on your DNS.
Since 95 percent of all Spam uses spoofed domains, just about everyone is checking this now. You really need to implement this. Here’s how to do it in six steps:
Step 1: Test Your Current E-mail Sender ID Authentication
The first step is to test your current E-mail Sender ID Authentication. The E-Mail Service Provider Coalition provides a tool on their web site that I really love. Just send an e-mail to the address it gives to you, then check the result. You will see how your e-mail looks to everyone providing e-mail services and checking sender IDs. It shows all the standards, but remember, supporting one is enough. When checking out the result page, see if you scored five big X’s at the top of it. Did you? If so, that’s not good.
Step 2: Ask Your Hosting Service if They Support Sender ID Authentication
The second step is to ask your hosting service if they support Sender ID Authentication. Unfortunately, most big ones don’t, or I would have just switched.
Step 3: Meet the SPF Record
The third step is to meet the Sender Policy Framework (SPF) record. This next step requires two critical skills: reading, and the courage not to panic when you see a real IP address. Don’t worry, it’s really not that bad.
The SPF record is a text file stored in your DNS record. The syntax is here, but I’ll offer what I did as a quick and easy starting point. I used the IPv4 and SoftFail “mechanisms.” Let me explain.
Here’s an example of an SPF record that would work using IPv4 and SoftFail:
v=spf1 ip4:192.168.0.1/16 -all
That says, “Here’s my Sender Policy Framework version 1 statement, and if you get an e-mail from any IP address between 192.168.0.1 and 192.168.255.255, it probably came from someone at my domain. If it came from another IP address outside of that range, it probably did not come from someone at my domain and I’d be suspicious of it.”
The “It may be me anyway” suggestion is called the SoftFail, which is the “-all” command. Sort of a hedge if you are new to this and a little unsure. Worked for me.
Also, don’t be tempted to use the “Include” mechanism. It looks like a shortcut, but probably won’t work – which is a warning they themselves give you. I tried it anyway, of course. They were right.
Step 4: Find Your IP Ranges for Every SMTP Your Employees Use
The fourth step is to find your IP ranges for every SMTP your employees use where the
“@yourdomain.com” is in the “From” line. And I do mean everywhere: home, on the road, BlackBerry, etc. Everywhere. Our associates all log in remotely, and always send e-mail from office desktops. So all I had was EarthLink at the office, Cablevision at home (just for me), and my BlackBerry.
If, like me, you’re not great at reading message headers, here is a neat cheat to find your sending SMTP IP addresses: From the e-mail SMTP account you want to authorize, send an e-mail to spf-test@openspf.org. Delivery will fail but don’t worry, that’s how it works. You will receive a distinctly user-unfriendly response e-mail with the subject line of “Delivery Notification: Delivery has failed.” In fact, even when you do have Sender Authentication properly working, you still get that scary-sounding subject line.
The e-mail itself is very helpful though. Sift through it and you will see something like this:
SPF Tests: Mail-From Result=”none”: Mail From=”you@youraddress.com” … Remote IP=”167.206.4.200″
Two cool things here. First, this is one of your SPF test tools. Eventually you will see Mail-From Result=”pass.” Second, this is an easy way to see the IP address from which you are sending, shown as Remote IP=”xxx.xxx.x.xxx”. That is information you will need to know.
If you want to check against message headers, send yourself an e-mail and look at the “message source.” Remember, you have to read them bottom up, and the first IP address above the message (where you see your machine name) is the IP address of your desktop – not the SMTP sender. The next one up should have the name of your SMTP provider and the IP address you want. More about reading headers can be found by clicking on this link.
You’re not done, though. You want to be sure you have all possible IP addresses for your host SMTP. So I used this IP lookup tool to query my sending IPs. That returned the range of servers at Earthlink: 207.217.0.0 through 207.217.255.255.
An SPF record using the IPv4 command covering that range, including SoftFail, is:
v=spf1 ip4:207.217.0.1/16 ~all
IMPORTANT: You have to repeat this step for everywhere any of your employees sends legitimate company e-mail, and where the “From” address is shown as: name@yourdomain.com.
Step 5: Create and Test the SPF Record
The fifth step is to create and test the SPF record. This part is fun. The Sender Policy Framework Project offers many tools on its Web site to help you with this. Start with the wizard to build your SPF record. You can enter my domain, montner.com, to see how the wizard looks at mine, for example.
The wizard looks at your current DNS records, and then you need to answer the following questions. Here they are, along with the answers that worked for me:
1. montner.com’s IP address is 207.217.125.50 (It looks that up for you).
2. Does that server send e-mail from montner.com? (No).
3. This wizard found two names for the MX servers for montner.com:
mx01-dom.earthlink.net and mx00-dom.earthlink.net. MX servers receive mail for montner.com.
Do they also send mail from montner.com? (No).
4. Do you want to just approve any host whose name ends in montner.com? (No, since this is expensive, unreliable, and not recommended. Besides, saying “yes” would defeat the purpose of sender ID authentication).
5. Do any other servers send e-mail from montner.com? (No. For me this was simple, because I only have one domain. If you have multiple domains/subdomains from which you’re sending, you need to look into this).
Getting the Results
The result for me is this SPF record:
v=spf1 ip4:207.217.0.1/16 ip4:209.86.0.1/16 ip4:216.9.240.1/20 ip4:167.206.0.0/16 ~all
So, for me, the main things I wanted was the information in the last two boxes:
1. IP networks can be entered using CIDR notation (i.e., 192.0.2.0/24). Enter your IP ranges here, like this: 207.217.0.1/16 – without using Enter or commas. The wizard inserts the IPv4 command.
2. Could e-mail from montner.com originate through servers belonging to some other domain? (If you send mail through your ISP’s servers, and the ISP has published an SPF record, name the ISP here. This creates the Include command – do not use because your ISP probably does not publish an SPF Record so your e-mail would get “permanent error.”)
3. Do the above lines describe all the hosts that send e-mail from montner.com? (No. This adds Softfail command if you say no).
Here’s the cool part: Press continue and you will see your SPF record and its clear interpretation. Keep working with the wizard until you think you are done.
Then test (and re-test) the SPF record at this link. First test the syntax, then test all the different IP addresses from which you will send. This really is a great tool.
Step 6: Publish the SPF Record in Your DNS Record
The sixth step is to publish the SPF record in your DNS record. I learned that your domain registrar, DNS host and Web host can be three different providers. Not all DNS providers let you publish SPF records. A list of providers who do so can be found by clicking this link.
I chose to use a provider named EasyDNS. I transferred my DNS service to them using their wizard (which worked great), and published my already tested SPF record. I love this provider. They have great tutorials on DNS and sender authentication. They have their own SPF record wizard, too, but I did not try it. And get this, they actually answer e-mail support questions. All for $35 a year.
There was only one minor wrinkle for me. For downloading e-mail, I had to change my Outlook Express e-mail client’s accounts setup. I changed the POP3 server from pop.montner.com (which no longer resolved so I couldn’t download e-mail at some desktops) to the alternate, pop.hosting.earthlink.net. I could also have fixed this by adding a record for pop.montner.com on the DNS, but it was easier for me to change the POP3 setups on the clients.
And here’s a great thing: Once the new DNS record takes hold, you can test it by sending e-mails to spf-test@openspf.org and use the tool at http://senderid.espcoalition.org/.
So, with a “Love my new Carrera” kind of exuberance, I send e-mails every day to spf-test@openspf.org just to see the Result=”pass” message.
And the best part?
Mom now gets my sender ID-authenticated e-mail in her Inbox. With pics.
[Editors Note: Since submitting this article, Michael Smith reports that someone has attempted to spoof his domain for the purpose of sending spam. The spam using his spoofed account name was rejected because of the failed SPF. Mr. Smith, as you might imagine, is delighted. -Wayne Rash]