With authentication quickly gaining acceptance among both e-mail receivers, like ISPs, and senders, like marketers and publishers, now’s a good time to examine how changes at Hotmail might affect your use of Sender ID and SPF records.
Authentication is the process by which you identify yourself to an e-mail receiver, such as an ISP, and verify which IP addresses are allowed to send e-mail from your domains. You can do this multiple ways, but I’ll focus here on how to make it easier for an ISP to look up your authentication record and to improve your chances of being properly identified as a legitimate sender. In fact, last week, Yahoo and eBay announced a partnership to use e-mail authentication measures to block phishing (define) attempts.
You may think: “Why do I need to know this geek stuff? That’s my IT department’s issue, not mine.” It’s like comprehending what goes on under your car’s hood. You can drive without knowing the sparkplug-firing pattern or the piston-compression rate, but when something goes wrong, you can help your mechanic find the problem faster if you have a clue about where to look first.
Same thing goes for e-mail authentication. If an increasing number of messages are blocked by an ISP, check your authentication records before tearing down your entire program.
Today, I’ll outline how Hotmail implements Sender ID and SPF, because this e-mail service has made a high-profile effort to help senders understand what it looks for and what it checks when authenticating a sender. Knowing this information might help you deliver more e-mail messages to Hotmail addresses, which is important for consumer marketers.
Sender ID vs. SPF: What’s the Difference?
These two methods, called protocols, are almost identical in syntax. They differ in how the receiver domain looks up your authentication record, which is a line of code inserted in your DNS (define) record that appears in your e-mail message headers.
SPF checks are performed against the domain from the envelope’s return-path address, typically called the bounce address. Sender ID checks are performed against the purported responsible address (PRA), that is, the visible sender address in the message.
Let’s say the domains in those addresses are the same. Then you as the sender can pass a Sender ID check with only an SPF record. If the domains are different, you should create both records and place them in the corresponding domains.
When in doubt, place your SPF record in all domains you have control over. This increases the chance the record will be placed where the receiver is checking. That’s what I mean by making it easy for your receiver.
Here’s a shorthand way to see the difference:
|Address checked||PRA||Envelope domain (return-path address)|
|Where check’s made||Visible message-body header in sender line||Root and subdomains|
|Example||example.com (as in firstname.lastname@example.org)||mail.example.com (subdomain) and example.com (root domain)|
Sender ID’s and SPF’s syntax differs only slightly. SPF records begin with “v=spf1,” while typical Sender ID records begin “SPF2.0/PRA.” The rest of the records are identical. The basic, most ISP-friendly SPF entry is “v=spf1 a mx IP4:XXX.XXX.XX.XX –all.” For Sender ID, it would be “spf2.0/pra a mx IP4:XXX.XXX.XX.XX -all.”
Hotmail has been the most vocal Sender ID advocate. Recently, it issued guidelines for creating a record and the mechanisms to avoid. Hotmail has specifically requested senders not to use the PTR (define) mechanism. It also recently asked senders to use a hard fail ” -all” at the end of their records to indicate their e-mail infrastructure is secure.
The syntax your record should use to indicate your level of e-mail security:
|-all||Fail||Fail all servers not listed here (recommended option)|
|˜all||Soft fail||Give extra scrutiny to servers not listed here|
|?all||Neutral||Unsure whether e-mail infrastructure is secure|
|+all||Pass||There’s no infrastructure security at all|
One last note on implementing Sender ID and SPF: It’s not uncommon for a sender to change IP addresses or providers. Most ISPs will perform authentication checks on inbound e-mail by directly querying your DNS zone.
If you’ve changed your Sender ID and SPF records recently, use the following URL to update Hotmail: http://support.msn.com/default.aspx?productKey=senderid&mkt=en-us.
In some cases, if the Sender ID/SPF record contains syntax errors, Hotmail will even send an e-mail to alert you of the problem so you can make corrections before you have delivery problems.
Test Your Record Setup First
You can use free tools to test your authentication record, but I often prefer to view results that come directly from the receivers by checking the posted results in the e-mail headers.
Both Gmail and Hotmail provide this detail and are easy to test for compliance. You always want to see “pass” as your result, never “fail” or “neutral.” In some e-mail services, a “neutral” result might mean your e-mail gets rerouted to the bulk folder or blocked; a “fail” result always denies entry to your e-mail.
For example, an SPF Gmail headers might look like this:
Authentication-Results: mx.google.com; spf=pass (google.com: domain of email@example.com designates XX.XX.XX.XXX as permitted sender)
A Sender ID Hotmail header might look like this:
X-SID-PRA: FirstName LastName
Until next time, keep on deliverin’!
Want more e-mail marketing information? ClickZ E-Mail Reference is an archive of all our e-mail columns, organized by topic.
No matter your industry, field, career, day-to-day responsibilities, or duties, communication is integral to your success. This is particularly true in SEO ... read more
Do your email subscribers use social media? Let me ask this a different way. Is anyone not using social media? Like email, ... read more
Shift 2016, a conference held in San Francisco that focuses on digital disruptions in various industries, invited M&C Saatchi Mobile’s very own ... read more