SPF and Sender ID: How they work
Both SPF and Sender ID work by requiring that senders publish their comprehensive list of authorized servers in the appropriate DNS domain(s)-for example, mye-maildomain.net. The list is published in a SPF record. Nothing more needs to be done on the sending side, except to make sure that the record remains up-to-date as mail servers are added or retired. No additional processing is required in Step 2 of the authentication flow.
On the receiving side, the verifier determines the domain to be authenticated, and then looks in that domain's DNS entry for the list of authorized servers. If the list contains the address of the server that delivered the message to the receiver, then the message authentication succeeds. If the list does not contain the delivering server, then the authentication fails. If it finds no record, the result is neutral.
It is important to note that path-based authentication mechanisms such as SPF and Sender ID are very sensitive to breakage caused by forwarding. Although it is possible to deal with this problem by adding special Resent-From headers, very few forwarding mail servers add them. In order to avoid SPF and Sender ID validation failures, many sites choose to terminate their SPF records with "~all" rather than "-all", which indicates a "soft" failure rather than an absolute violation.