|Email Plug-in (Reporting):||1.1.0-114|
|Email Plug-in (Encryption):||1.2.1-118|
One of the recommendations from the Analysis Teamis to implement the Sender Policy Framework (SPF).
Kindly enlighten us on how this works and how to implement this on our Cisco Ironport.
Is there any requirements needed? What are the pro’s and con’s of implementing this?
Solved! Go to Solution.
When working out what action to take on the various SPF verdicts, bear in mind that the Office 365 groupies are currently churning out epic numbers of PERMERRORs for valid domains they're converting. As that's mostly seagull conslutancy, there's no-one with any technical clue at the sender domain to fix things if you point the error out to them. The other unholy terror of SPF validation is the forgotten back office workflow system automatically churning out trivial things like invoices, process notifications, payslips and the like. Still, manually resending all that traffic (because you won't be the only one dropping it) will give all those suddenly-more-productive office staff something to do.
Most emphatically test with a log action before going live with a drop or quarantine action. I introduced SPF here one sender group at a time, starting with the lowest SBRS ranges. Even if you only act on hard FAIL verdicts, you'll still want an Incoming Mail Policy for folk with SPF errors that they simply can't correct.
Before getting into all of that, it's worth checking what your analysis team actually wanted. Remember that publishing SPF to authenticate your outgoing mail and doing SPF validation to check your incoming mail are two different things, and you don't have to do both though in this day and age the first is definitely recommended. The article Raed recommended focusses entirely on the second, as that's where an ESA fits into the process.
Depends upon which piece you're talking about
Implementing SPF record for your domain:
Pros: better deliveribilty of your mail... some of the big carriers claim they aren't accepting mail without SPF records.
Cons: none that I know of...
Implementing SPF record checking:
Pro: less spam gets through
Cons: You run across companies that don't know what they are doing, and you dump good mail. (I've sent MANY notes saying "here's your spf record, here's the mail trace from an IP that isn't covered by the spf record... YOU told me its spam... so I dropped it... fix your crap" )
John, on publishing an SPF record to authenticate your own domain there's the tricky question of whether to end your record with a SOFTFAIL (~all) or HARDFAIL (-all).
A soft ending may be acceptable to some of the bigger webmailers who can be seen to be checking SPF if you look at message source details in your own web mail test accounts (you of course will have test accounts with all the large free webmailers) but in my opinion still leaves you open to impersonation as unauthorised machines may be deemed acceptable by the checking system. The RFCs do not prescribe a specific action for any result, but are particularly (necessarily?) fuzzy on this subject. See RFC 4408 and 7208. I have a recollection that at least one contributor to this forum has stated that he only acts on HARDFAIL results.
A hard ending is much less open to question, but will cause problems with your deliverability whenever the recipient is forwarding your mail to another address. I believe there are mechanisms the recipient can implement to mitigate this problem, but many of the domain owners forwarding mail are precisely those least able to put such arrangements in place.
The main ones are fairly common knowledge, but if you are short of tools for checking SPF then let us know.