SPF Woes with Third Party Services: A Workaround

By: Yves Lacombe

Many people use SPF (Sender Policy Framework) as an anti-spoofing measure. They create an SPF record in their DNS zone for their domain. From time to time, some customers will do business or use third party services that will send out Email on behalf of their domains and unfortunately, this will cause recipient MTAs to hard-fail or soft-fail these messages.

Typical example: widget.com has an SPF record identifying which MTAs can send out Email on behalf of said domain. The company decides to use SalesForce (hosted CRM solution) for their sales team. Since SalesForces MTAs are not declared in widget.com SPF record, recipient MTAs will reject messages with @widget.com in the senders Email since these Emails are not originating from any of the permitted MTA IP Addresses.

The Workaround

Add SalesForces MTAs to widget.coms SPF record.

Most third party services will have their own SPF record so all you need to do is use the …include directive to include their SPF record information into your own.

Let’s say widget.coms SPF record looks like this:

v=spf1 ip4:10.10.10.0/24 -all

All widget.coms administrator would do is something like this:

v=spf1 ip4:10.10.10.0/24 include:salesforce.com -all

Assuming the MTA that salesforce.com uses to send OUT email with @widget.com in the senders address is covered by the existing salesforce.com SPF record, this should work.

References:

Sender Policy Framework: http://www.openspf.org/