Ensure automated email notifications won't be rejected by Sender Policy Framework
My company sends to some clients' automated notification e-mails with rewritten source email address to xxx@ClientA.com, instead of the real source, firstname.lastname@example.org. With the introduction of Sender Policy Framework (SPF) for anti-spam proposed to take place in October, what steps do we need to take to ensure this sort of "proxy" email notification will be accepted properly?
To use SPF, your client will need to add a TXT record for clientA.com describing the hosts that can legitimately send mail addressed from clientA.com. SPF is flexible enough to allow your client to specify that your mail servers may send mail from clientA.com. He can do that in one of several ways:
Using the "a" option and the domain name of one of your mail servers
as an option argument (i.e., "a:mail1.hsntech.com").
Using the "ip4" option and the IP address of one of your mail servers
as an option argument (i.e., "ip4:10.0.0.1").
Using the "include" option and your domain name (i.e.,
This allows any mail server whose name ends in the specified domain
name to send mail from the client's domain name.
To designate multiple options, just use more than one option, each with
an option argument, separated by whitespace. For example, "a:mail1.hsntech.com
There's more to the TXT records that SPF uses: the records start with
"v=spf1", for example. For an excellent web-based wizard that will walk you through the process of determining the right TXT record for your client to use, see http://spf.pobox.com/.
This was first published in August 2004