Step 3 – Publish an SPF Record

At this point, mail should be flowing pretty well. Your mail organization should be off most, if not all, spam lists. Mail should not be being rejected due to a lack of a reverse or PTR record in DNS for your Send Connector. Now how do we further ensure that this becomes the norm? One step would be to publish a Sender Policy Framework or SPF record for your mail domain(s).
A SPF record is simply a listing of what servers are "authorized" senders for your domains. You are essentially telling the world what host(s) should be considered valid for your domain and that if they receive mail for your domain from any other host, it should be dropped and not considered from your domain. This greatly reduces the likelihood of your true production servers being listed on any blacklist. SPF is one of 3 main mechanisms intended to ensure mail senders are who they say they are. The other 2 are Domainkeys IM and Sender ID. Sender ID and DomainKeys also try to tackle the problem of authentication, by publishing the public keys for the TLS encryption/signing of messages. While these are noble goals, they are overkill for the vast majority of organizations. I have never seen a native implementation of DomainKeys for Exchange, and while Microsoft has definitely backed Sender ID, its use is nowhere near as widespread as SPF. If you would like to see the full details behind SPF, their comparison of the 3 implementations, and SPF's full record syntax, see the Open SPF organization website.
Fundamentally, the SPF record is simply a TXT record inserted as another DNS record for your domain. As many organizations use their incoming server(s) also as their send connectors to the exclusion of any others, the most common SPF record is something similar to: "v=spf1 +mx -all". This allows hosts in the domain's MX records to send, but no other host. If you have an additional server called mailer.example.com that is used as a sender for either a web application or other reason, you can add that server to your SPF record using the "a" operator. That results in a SPF record that looks similar to: "v=spf1 +a:mailer.example.com +mx -all". There are many other options including support for including records from other domains and allowing or disallowing individual hosts by name or IPv4 or IPv6 address. If you need a more complicated SPF record than the 2 very simple examples, take a look at the configuration wizard provided by the Open SPF organization. It walks you through all of the various options and provides the final SPF text as an output. It is then, simply a matter of working with your DNS hosting provider to insert the appropriate record.
One quick note on the use of SPF records to help avoid unsolicited spam. If you use an Anti-spam appliance or service that makes use of SPF records as part of its checks, make sure that it is the host listed in your MX record, not a host which has the mail to be scanned forwarded to it by another host on your network. This is because the Anti-spam host will see the forwarded as the apparent host, rather than the real originator, which will cause the system to block mail for any domain that has an SPF record published. This was the cause of a significant mail delivery problem with a partner's domain at a prior employer of mine.