If you haven’t already found www.open-spf.org, it’s a great resource. Pay attention to the SPF vs. Sender ID topic. Check out http://www.open-spf.org/SPF_Record_Syntax for the down and dirty.
If you’re hosting your own mail server and your MX records constitute the only sending servers, you can get away with just the ‘mx’ mechanism.
If you’re using a hosted service for your email (Google Apps for example), or even forwarding outgoing mail from your internal SMTP server to a service like SendGrid, check with those services for specific SPF configuration instructions.
Edited to add better descriptions of SPF, mechanisms, and qualifiers
When a mail exchange that supports the use of SPF receives an email, it looks at the purported domain of the sender (someone@sendingdomain.tld) and the IP address of the server that sent the message. The question is, does that IP address have permission to send email on behalf of the sender's domain (sendingdomain.tld)?
To answer this question, the server retrieves the SPF record (stored as a DNS TXT record) from the purported domain (sendingdomain.tld) and checks the sending servers IP address against the that SPF record.
SPF uses mechanisms to create lists of valid sending servers for email. Each mechanism can be qualified with a +, -, ~, or ? prefix (this information was taken from open-spf.org):
'+' means pass (or valid) - Note: This is the default action
'-' means fail (or invalid)
'~' means soft fail (treated by many servers as neutral)
'?' means neutral (validity is neither confirmed nor denied)
When a record is being evaluated, it matches the first mechanism from left to right. If no mechanism matches, the default result is neutral.
In general, the 'All' mechanism matches everything, so...
The '+All' mechanism means, all servers are valid senders for this domain (don't use this option).
The ‘-All’ mechanism fails all sending servers. Use this at the end of an SPF record to override the neutral default result with a fail result. Some services (like Google) warn against this, but I have yet to run in to any problems with it yet.
The ‘~All’ and '?All' mechanisms are the equivalent of saying, “if the sending server doesn't match any of the valid servers listed, don’t worry about it.” Use these for testing SPF records only.
For a full list of mechanisms, refer to open-spf.org's Record Syntax page.
The one other mechanism I'd like to discuss here is, ‘include:< domain >’. This mechanism directs a server parsing an SPF record to include additional mechanisms specified in another SPF record hosted by < domain >.
Examples:
If your domain uses the same servers (as in same IP address) for sending and receiving:
- v=spf1 mx –all
- The above is equivalent to, v=spf1 +mx –all
If you use Google Apps to host mail, but sometimes use an internal SMTP server for automated messages:
- v=spf1 ip:< ip address of internal server > include:_spf.google.com -all
DKIM is a different beast all together. If you’re using a hosted email service, check with that service for instructions. If you hosting your own mail exchange, check with the documentation for your server software to figure out how to implement it. It’s a bit beyond the scope of this question.
