Sender Authentication
“Return Path manages all aspects of our deliverability. We rely on Return Path to protect our email revenue by keeping our reputation intact and our inbox delivery rates high. You can't argue with a 22% increase and that translates directly into sales for us.”
Chris Woodward,
Manager E-commerce Content & Email - Orvis
Other than a sender's IP address, no information in an email can be verified. It is quite easy to make an exact copy of an email from citibank.com, including a sequence of headers and a genuine logo in the body of an email, then change the content to send recipients to a website that appears to be genuine, but is actually a "Phishing" scam designed to capture names, passwords, and credit card numbers.
Sender authentication protocols exist in two varieties: path-based protocols and cryptographic protocols. SPF and SenderID are examples of path-based protocols, and DomainKeys is an example of a cryptographic protocol.
SenderID is a sender authentication protocol. It is a method for a domain to specify which hosts are allowed to send email on behalf of that domain. The sending domain adds a specially formatted record into its DNS zone file identifying all authorized mail servers. A receiving mail server checks the sending domain's DNS zone file to see if the IP address from which the message is originating matches one of the authorized IP addresses.
The technical specifications for SenderID are contained in the following three documents:
These specifications have been released as experimental RFCs.
Additional information about SenderID can be found at http://www.microsoft.com/senderid. This web site also includes a wizard which will create SenderID records.
Information about SenderID is located at:
http://www.microsoft.com/senderid
This site includes wizards for creating both SPF and SenderID records. In order to create a SenderID record, select the radio button next to "The Purported Responsible Address (PRA) derived from RFC 2822 headers" in the Scope section of Step 3 of the wizard. Selecting the radio button next to "Both" in the Scope section will generate an SPF and a SenderID record.
When the record has been created, it will then need to be added to the domain's DNS Zone File.
Habeas strongly recommends you do not publish a SenderID record until you have tested it and are sure it is correct. Port25 Solutions has created an automated testing tool to verify SenderID implementation. To use the tool, send an e-mail message to check-auth@verifier.port25.com. In return, you receive a reply containing an analysis of the authentication status of the message you sent.
SPF (Sender Policy Framework) is a sender authentication protocol. It is a method for a domain to specify which hosts are allowed to send email on behalf of that domain. The sending domain adds a specially formatted record into its DNS zone file identifying all authorized mail servers. A receiving mail server checks the sending domain's DNS zone file to see if the IP address from which the message is originating matches one of the authorized IP addresses. Additional information about SPF can be found at http://www.openspf.org. This web site also includes a wizard which will create SPF records. Additional information about SPF may be found in the technical specification which is located at the following URL: http://www.rfc-editor.org/rfc/rfc4408.txt. This specification has been released as an experimental RFC.
http://www.openspf.org
This site includes a wizard for creating SPF records. Habeas has found that entering only the IP address information creates the most efficient SPF record.
When the record has been created, it will then need to be added to the domain's DNS Zone File as a TXT record. An example SPF record appears below:
v=spf1 a mx ip4:208.185.42.0/24 -all
Habeas strongly recommends that you do not publish an SPF record until you have tested it and are sure it is correct. Errors in SPF records can impact delivery at some ISPs. SPF includes a mode of operation which permits testing of the record without causing mail to be rejected inadvertently. Habeas recommends the following validator:
http://www.kitterman.com/spf/validate.html
On an ongoing basis Habeas Email Monitor is an excellent tool to validate that SPF is implemented correctly.
Most often a "Neutral" response to an SPF check is caused by an "?all" mechanism which is an explicit directive to interpret the SPF records as neutral -- neither pass nor fail.
The "redirect=" modifier transfers responsibility for the SPF record to the specified domain.
http://antispam.yahoo.com/domainkeys
This site includes the paper "DomainKeys: Proving and Protecting Email Sender Identity" which describes DomainKeys in more detail. Even more details, including implementation details for various MTAs, is located at the following web site:
http://domainkeys.sourceforge.net
The site referenced above also includes information about testing newly created DomainKeys records. The technical specifications for DomainKeys is located at the following URL:
http://www.ietf.org/internet-drafts/draft-delany-domainkeys-base-05.txt
DomainKeys has been merged with a similar proposal, Internet Identified Mail, and the combined specification is known as DomainKeys Identified Mail (DKIM). Work on the DKIM specification is currently in progress. However, the specification will provide for backwards compatibility with DomainKeys, so any DomainKeys records created now will remain valid after the DKIM specification is released. Habeas recommends that its customers begin planning for adoption of DKIM.
DKIM is a sender authentication protocol developed in order to address the problem of forged email messages. Yahoo! released the DomainKeys specification and Cisco released the Internet Identified Mail specification. Both methods are based on cryptographic message signing. The two efforts have been merged, and the combined specification is known as DomainKeys Identified Mail (DKIM). DKIM currently is based on four specification documents, and drafts of these specifications may be found at the following URLs:
Work on the DKIM specifications currently is progressing, and the specifications cited above are preliminary. Discussions on the next drafts of the specifications are ongoing, and the specifications cited above are likely to be replaced. However, the final specifications will provide for backwards compatibility with DomainKeys, so any DomainKeys records created now will remain valid after the final DKIM specifications are released. Habeas recommends that its customers begin planning for adoption of DKIM.
Adoption of sender authentication protocols is not merely recognized as a best practice; it may have an impact on email delivery. For example, Microsoft announced plans to begin inserting visual warnings in the MSN Hotmail user interface on messages where sender authentication cannot be verified. The new warning was to be made available in 20 languages supporting over 200 million MSN Hotmail users worldwide. Implementation of the new interface began in June 2005. Microsoft is deploying its SenderID checks in three phases: In the first phase, which began in June 2005, implementation applied only to email senders that publish SPF records which fail the authentication check due to a mis-match between the IP address and domain or due to an incorrectly published SPF record. Email failing the SenderID check may be placed in the inbox with a warning icon as illustrated below:
In the second phase, senders that publish SPF records which fail the authentication check due to a mis-match between the IP address and domain or due to an incorrectly published SPF record may be placed in the junk mail folder or rejected altogether based on the sender's reputation and other anti-spam heuristics. Messages that fail SenderID checks and email from domains without SPF records will face further scrutiny. Also, email messages originating from invalid domains will be sent to the junk mail folder. Microsoft will be testing and adjusting its filtering policies during this second phase. Finally, in the third phase, Microsoft will begin routing all email either failing the authentication check or lacking a published SPF or SenderID record to the junk folder. In 2006, Yahoo! will begin requiring senders that wish to establish a feedback loop to utilize the DomainKeys protocol. Gmail is checking and validating DomainKeys records for incoming email, but is not currently taking any action as a result of its checks. Habeas has been promoting the use of sender authentication for some time, but Microsoft's and Yahoo's announcements makes adoption of sender authentication more urgent in order to ensure continued delivery of email. No cost is associated with creating an sender authentication records, and correct sender authentication records can only improve delivery rates, not damage it.
