Sender Policy Framework

When DNS records are queried, the answer contains a Time To Live (TTL) value. This is the amount of time, in seconds, that the answer should be remembered. If the same question is asked again during this time, a local copy of the answer is returned, the responsible DNS server is not queried again.

Make sure you don't get bitten by this when you modify your SPF record:

1. You test your existing record using one of the validators, or you look it up, whatever
2. You modify your SPF policy and publish a new record
3. You try testing your new policy. In stead you're looking at your previous policy.

Make sure you don't get bitten by this when you move to another provider:

1. You decide to change from cable to dsl. This means getting another IP address
2. You disconnect your host from one connection, connect it to the other. You give it the new IP address (or let DHCP take care of it)
3. You change your SPF policy and publish the new record, authorizing the new IP address.
4. You send mail to a relative. This relative's host still has your previous SPF record cached thus rejects your message.

Similar, but different:

1. You send mail, from your office, to a customer
2. There's a power failure at your office
3. You change your SPF policy so that it authorizes another location
4. You go to that other location
5. You send mail to that same customer. Your message is rejected, because the customer is still using the previous SPF record, not the new one

You've prepared for this failover situation. Your SPF record contains a hostname, not an IP address.

1. You send mail, from your office, to a customer
2. There's a power failure at your office
3. You change the hostname so that it points to another server at another location
4. You go to that other location
5. You send mail to that same customer. Your message is rejected, because the customer is still using the hostname's previous IP address, not the new one

Notice how remarkable similar these last two examples are... Using a hostname is not going to help.

Then what should you do?

• If you have a backup location to send your mail, authorize it in your policy before something happens, not after the problem occurs.
• If you are going through a planned change, make sure your DNS records have a low enough TTL value. Say the current TTL value is 86400 (one day). A little more than one day before the change, alter the number in 43200. A little more than half a day before the change, alter the number in 3600. One hour before the change, alter the number in 60. Do your changes, including changes in DNS. The entire world should know about the new situation within 60 seconds (30 on average). Test your new DNS settings. If they are wrong, fix them and it takes another 60 seconds for the world to know. Once you're happy with the new situation, change the value back to 86400.