There’s a fair amount of confusion around the usage of SenderID and SPF records, and rightly so — their syntax is nearly identical and they both seem to do the same thing. So, what’s the deal?
Email is incredibly easy to forge. So easy that I can send you can email from my laptop claiming to be “From” email@example.com and when you receive that email you’ll see whatever I placed in the “From” field in your inbox. This is what makes phishing and other online email scams so easy to pull off.
Understanding what’s happening here requires basic knowledge of an SMTP transaction, namely the “MAIL FROM” command which is used to identify the entity that’s actually sending the mail. The problem with this is I can simply send the command “MAIL FROM firstname.lastname@example.org” and the receiving system will be none the wiser.
To defend against this type of forgery, SPF (Sender Policy Framework) was introduced to allow domains (i.e. yourdomain.com) to specify IP addresses that are allowed to send email on their behalf. When an email is received, the system performs a TXT record lookup on the sender (this is not the “From: ” header) to see if yourdomain.com lists my IP address as a permitted sender. If it doesn’t find my IP address listed, then it can do a number of things such as dropping the email completely or labeling it as SPAM.
This process works well in the majority of cases and makes phishing attempts much more difficult.
A potential hole this process leaves open however has to do with the “From:” header that we see when we’re viewing an email. This is the first entity we see in GMail, Outlook, Mail.app, or whatever email client we’re using and it does not have to match the sender. So yes, that means that if yourdomain.com lists emailmarketing.com’s IP address as a permitted sender and I’m using emailmarketing.com, I can send you an email with a forged “From:” header and it will appear to come from the IP address that you authorized.
Enter Sender ID.
Sender ID looks very similar to SPF with the addition of one option called PRA (Purported Responsible Address). The PRA is determined by an algorithm that looks at the headers of the email (Resent-Sender, Resent-From, Sender, and From) to determine who was most recently responsible for sending the email and uses that, possibly in conjunction with the sender (if desired), to determine the authorization status of the email.
This seems OK on the surface and given the proper DNS configuration, should allow the email to be authorized. Unfortunately, the RFC that describes the implementation of Sender ID instructs the system to treat a standard SPF record as a Sender ID record enforcing both sender and PRA authorizations by default. Going back to our emailmarketing.com example, this would block both forged emails and legitimate emails.
There’s still a debate on how to handle this. See OpenSPF.org’s website for their take.