Sender authentication part 21: Some recommendations
In documentation that Microsoft is going to release shortly, they have some recommendations on how to set up your SenderID records as well as a list of frequently asked questions. I will post a link to the relevant documents when they become available. For now, here's a sneak peek at some of the comments and recommendations (I have made a few modifications for grammar and added a couple of extra commentaries):
What type of SPF records should I NOT use?
The IETF specification allows for the use of SPF records for testing utilizing a record ending with a "?all" as well as provides a syntax declaring anyone can mail from your domain, utilizing a "+all". In both cases, these syntaxes SHOULD NOT be used because they provide no protection from spoofing and no benefits for enhanced email deliverability. Domain holders should be advised ISPs may place a negative score on any such email associated from such records, as they have been used by spammers who mistakenly think their email would be considered SIDF compliant and obtain a favorable score by doing so.
Recall what these syntaxes mean - if an IP sends mail from outside the specified range, a "+all means that all IPs are acceptable meaning anyone can spoof the domain, while ?all means that we don't say one way or the other whether or not the IP is allowed to send mail (which is effectively a de facto +all).
Why should I NOT include a PTR (Pointer Record) or reverse DNS lookup?
Windows Live Hotmail does not support the use of records with a PTR. Such inclusion may induce fails and mail being junked and/or deleted. As a reference, the Internet Engineering Taskforce (IETF) does not recommend the inclusion of a PTR within an SPF record as it will create unnecessary DNS traffic, be more prone to errors and will not function in implementations where SPF records are cached on local servers.
Mobile employees often send e-mail from hotel or other “guest” e-mail servers. What do I put in my SPF record to cover these situations?
The best option, if possible, is for mobile users to send e-mail over a VPN connection or by using a Web-based e-mail client (this also helps SPF checks). This way their e-mail flows through your regular e-mail servers and you don’t need to make any changes to your SPF record. If mobile users submit e-mail using a POP or IMAP client, their messages flow through the hotel or guest e-mail server. To deal with this, you could terminate your SPF record with “~all.” The “~all” causes a “soft fail” when Sender ID checking is performed. This does not mean that messages will be rejected, but they may be subject to additional spam filtering. Microsoft also suggests that the hotel or other guest e-mail service publish its own SPF record, and then insert a header into outbound messages identifying the guest account. In this way, e-mail can be authenticated as legitimately originating from that service.
This type of situation actually happens quite often. I have seen a lot of email get tagged as spam because a user logs in remotely and sends mail using the hotel email server. The above description work, but there really is no elegant workaround in the absence of webmail because there's no guarantee that a hotel will be SenderID or SPF-compliant.
I have SPF1 or SPF classic records already posted in my DNS. Do I need to make a change?
Typically, no. The same SPF record can generally be used to authenticate both the MAIL FROM and PRA domains. Sometimes, however, different domain names are used in the MAIL FROM (or “envelope”) address and the addresses used in the message body. You need to ensure that SPF records are published for all the domains used in both the MAIL FROM and PRA addresses of messages sent from your domain.
Do I need to create separate records for receivers who have implemented the MAIL FROM or the PRA check?
Typically, no. The SIDF specification has been designed to use the same SPF record for both. Sometimes, however, different domain names are used in the MAIL FROM (or “envelope”) address and the addresses used in the message body. You need to ensure that SPF records are published for all the domains used in both the MAIL FROM and PRA addresses of messages sent from your domain.
The last two questions, I think, are especially relevant to the SPF vs SenderID debate. The guys at OpenSPF say that there will be a big problem if you use SenderID, whereas Microsoft says in most cases there won't be. However, Microsoft does acknowledge that sending domains need to be careful if they use different domains in the envelope sender from the one that shows up in the From: address. In other words, it works most of the time by default but there are special cases that need to be handled.
This is just like anything in life - there are always exceptions to the rule.