Here are the steps that I take to get an SPF Record going on DreamHost
SPF records
Sender Policy Framework (SPF) records allow domain owners to specify which hosts are permitted to send email on behalf of their domains. Normal SMTP allows any computer to send an email claiming to be from anyone. Thus, it's easy for spammers to send emails with forged From: addresses. SPF allows a domain owner to use a special format of DNS TXT records to specify which machines or hosts are authorized to transmit email for their domain; this makes it difficult to forge From: addresses.
For example, if you own the domain askapache.com, you can designate which hosts are authorized to send email originating from user@askapache.com. Your recipient's servers will then identify the origin of your message by checking the SPF record.
SPF For Gmail
Sender Policy Framework (SPF) records allow domain owners to specify which hosts are permitted to send email on behalf of their domains, making it hard to forge From: addresses. We strongly encourage you to publish SPF records for your domain -- having these records in place will ultimately help fight spam.
How do I set my SPF records?
To set your domain's SPF record, publish the following TXT record on the DNS resource: v=spf1 include:aspmx.googlemail.com ~all.
If I get mail from pielovers.demon.co.uk, and there's no SPF data for pielovers, should I go back one level and test SPF for demon.co.uk?
No. Each subdomain at Demon is a different customer, and each customer might have their own policy. It wouldn't make sense for Demon's policy to apply to all its customers by default; if Demon wants to do that, it can set up SPF records for each subdomain.
So the advice to SPF publishers is this: you should add an SPF record for each subdomain or hostname that has an A or MX record.
Sites with wildcard A or MX records should also have a wildcard SPF record, of the form: * IN TXT "v=spf1 -all"
What should an ISP keep in mind?
Vanity domain holders may point to you using an include: directive. Keep in mind the overall processing limits will apply to their SPF record and yours together, so try to minimize the number of DNS lookups your record requires.
You should support SASL AUTH on ports 25, 465 and 587. When your users need to phone home from an Internet cafe, port 25 may be blocked, but port 465 and 587 are not. Most modern mail clients support STARTTLS and SASL AUTH on port 587, but Microsoft Outlook and Outlook Express support the older SMTPS approach via a 'wrapped port' on port 465.
You may want to set a default of "unknown" by saying "?all" instead of "-all" for the first few months, to accommodate legitimate users who have been sending mail through somebody else's servers.
You can tell who these users are by adding an "exists:%{l}.%{i}._spf.ISP.COM" record, and grepping in your DNS server logs to see who's mailing through what machines. Then you can contact all nonconformant users and tell them to use your SMTP server.
You should never publish -all for customers domains without the consent of your customers. They WILL have ways of sending mail that you don't know about. Keep your customers informed about your spf roll-out, this will prevent them from being unpleasantly surprised by mail that suddenly is not delivered due to spf FAIL results. Insufficient communication will drive up your support costs and result in your customers being less happy with both your service and SPF.
Can I run an SMTP server on my laptop?
If you run a personal domain, you can either not publish SPF records at all, or set up "v=spf1 ?all" for your domain, and you'll be able to send mail from your laptop no matter where you are. A better solution would be to set up your own smtp server that accepts mail from your laptop through POP-before-SMTP or SASL AUTH, so that you can still publish a more restrictive spf record.
If you are the customer of an ISP that publishes SPF records, your ISP should provide you with an SMTP server that you can authenticate to, using either POP-before-SMTP or SASL AUTH. Or you can ask them to exclude you from SPF using a user-specific "exists" mechanism.
DreamHost SPF WikiOnline SPF Wizard SPF Faq
Basic DNS RecordsA Forward mapping of hostname (dreamhost.com) to an IP address (66.33.201.141). PTR Reverse mapping of an IP address (66.33.201.141) to a hostname (dreamhost.com). MX Mail eXchange records tell you which hostname to connect to for sending email. CNAME Say it, See Name, it points one domain name to another domain name, including mail service. TXT Text records, these are free form text strings, used for things like SPF. SRV Service records advertise a specific service a server offers (Not common on the internet). NS Delegates a domain or subdomain to another DNS server.
Do I have to publish spf for each of my smtp servers?
No (or better: probably not, you are asking the wrong question).
You should publish spf records for each and every domain you wish to protect from being used by spammers/virusses. If, for example, your domain is somedomain.tld and you furthermore have a subdomain www.somedomain.tld registered, you would publish for both somedomain.tld and www.subdomain.tld (the latter probably being set to "v=spf1 -all"). Note that you will have to publish for each and every A record, including any wildcard (*) or @ entries in your dns.
Why? Consider how spf works: when an spf aware mail server receives an incoming message it will request the spf record for the domain in the envelope from. If you only publish the spf record on somedomain.tld, and not on www.subdomain.tld, a forged message pretending from www.subdomain.tld will be happily accepted for lack of an spf record.