Link to home
Start Free TrialLog in
Avatar of dgower
dgower

asked on

Any downside to implementing SPF (Sender Policy Framework)?

I have a customer who has hired a web company to send out "e-blast" emails under the customer's address. In other words, the web company sends out a message addressed to a large number of recipients simultaneously. The messages are sent to interested parties only in the customer's own industry.  This is a legitimate business and not spamming.  

Here's the problem:  some recipients reject the e-blasts because their firewalls detect that the emails are aliased ... that is, the sender address is the customer's email address, but in reality the email is coming from the web company's email server, which is not the same domain.  

The web company is recommending that we have the customer's Internet provider add an SPF Record that will include the web company's server as one of the authorized addresses.  It would also cause all email sent from anyone other than the customer's or the web company's email server from getting delivered, which sounds like a great thing.  Here's what the web company is recommending ...

******************************************************************************************************
Below you will find the SPF record we have created for you. Please forward this email to your IT person and have them add the SPF Record as a record of type TXT to the DNS for your domain.

New SPF Record: v=spf1 a mx ip4:64.78.151.128/26 ip4:216.241.183.0/24 ~all

Note for IT admins
If you did not previously have an SPF record we assume:
1. Your domains inbound email servers may send email (i.e. they are listed as valid senders in the SPF policy).
2. All addresses listed in A records for your domain may send email (i.e. they are listed as valid senders in the SPF policy)
******************************************************************************************************

First, I think they're saying if we don't include the customer's own Exchange server in the new SPF Record that the customer will have problems sending its OWN email. I get that and I can see it would have to be added along with the web company's recommended SPF syntax.  I'm right about that, yes?

Second, and more important...

Is SPF reliable?  I haven't worked with SPF before.  Does it have any downsides?  Is it erratic?  Will it slow the receiving of the customer's emails or anything like that?  Will some recipient email systems refuse to work with it?

Also, do you have any other pointers you think I need to know, to avoid making newbie mistakes in this area?

Thanks!



Avatar of dgower
dgower

ASKER

ADDING THIS NOTE...

I did a little research and found a helpful page at http://www.openspf.org/Introduction.  Among other things, they say...

"The domain sender policies alone are not worth much  it is the receiving mail servers that need to enforce them. Most mail servers support SPF checking either natively or through extensions.."

Sounds to me like the effect of implementing SPF may be hit or miss, depending on whether a recipient's email server is set up to respond to it.  How well does SPF work on average today?

The same page also warns that the SFP syntax has to be done right or legitimate messages can be blocked.

Avatar of dgower

ASKER

ADDING ANOTHER NOTE...

Also note the below from the Wikipedia article on SPF.  Sounds like SPF can cause some legitimate forwarded emails to be rejected??

"FAIL and forwarding

SPF does not allow plain message forwarding. When a domain publishes an SPF FAIL policy, then legitimate mails sent to receivers forwarding their mail to third parties can be rejected and bounced if

   1. the forwarder doesn't rewrite the Return-Path, unlike mailing lists,
   2. the next hop doesn't white list the forwarder, and
   3. this hop checks SPF.

This is a necessary and obvious feature of SPF  checks behind the "border" MTA (MX) of the receiver can't work directly.

Publishers of SPF FAIL policies must accept this potential problem. They should test, e.g. with a SOFTFAIL policy, until they are satisfied with the results. See below for a list of alternatives to plain message forwarding."
ASKER CERTIFIED SOLUTION
Avatar of Chris Dent
Chris Dent
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of dgower

ASKER

Chris-Dent:

This sounds good.  Question ...

I SAID  - > Sounds like SPF can cause some legitimate forwarded emails to be rejected??

YOU REPLIED - That's not a problem with SPF itself, rather a problem with mailing list or forwarding implementation. That comes under the category human error. If you account for it in a rule set you won't be troubled by it.

Could you give me an example of the kind of rule set you're talking about?  Would this be on the email server or are you referring to Microsoft Outlook or something?

Thanks.


Email server, SPF only works on the server level because clients never send directly to remote systems.

In the forwarder situation you have another server (as a mail server) that picks up and relays the mail on (transparently). But it's not transparent to the server receiving the message and checking the SPF.

It's unusual to bump into a situation where that becomes important, you won't encounter it in the vast majority of configurations. I can't give you a better example than that in the Wiki though.

Chris
The only downside I've seen so far is with clueless admins. I deal with a company who has a bad SPF record. By bad, I mean it doesn't match their email server (maybe it did at one point, but it doesn't now) and all their mail lands in my spam folder. It's super annoying. I've emailed them a bunch of times practically spoon feeding them how to fix it, but they either don't get it or don't care.

So if you publish SPF records, make sure your system matches it. Nothing says clueless to potential customers like your mail landing in their spam folders.

See what I mean about human error? :) It's extremely rare to see a problem caused by the system, if you take a bit of care implementing it you will be absolutely fine :)

Chris