Why Your SPF Project Will Fail

Having worked with many of Australia’s largest organisations to help secure their email ecosystem over the past 10 years, I’ve never seen so much hype about tackling Email Authentication than now. Whether that’s because of the exponential growth of domain spoofing or The Australian Signals Directorate’s Top 35 Cyber Mitigation Strategies, that recommended organisations deploy Email Authentication, there’s few organisations that aren’t at least considering deploying Email Authentication. But what is Email Authentication? Well, many organisations have been led to believe that SPF (Sender Policy Framework) will provide the domain resilience they need to ensure their email domains are locked down. SPF (Sender Policy Framework) was created back in 2002 as a protocol to eliminate unauthorised use of email domains. Now, pause for a moment and consider what other controls in the Security stack that were invented 15+ years ago have stood the test of time without adaptation or some form of evolution? Can’t think of any? Neither could I. Whilst SPF dramatically improved upon the inherently insecure platform that is Email, several fundamental flaws remained. And this forms the basis of why your SPF project will fail.

Flaw #1 – Correctly configured domains with an SPF record can still be spoofed

In an email, there are two “from” addresses. The envelope from (or “mail from”) and header from.  SPF’s primary function was to validate the envelope from address, which is the “from” address that is invisible to the recipient. The header from address (what the recipient can see) can still be imitated without SPF failing. What’s worse, if for example the envelope from was badguy@dodgy.net, the domain owner could publish an SPF record and still display a header from of bob@acmecorp.net and successfully pass SPF.

Flaw #2 – SPF does not survive message forwarding

Over time, many consumer mailboxes have been configured with forwarding rules to deliver email to another mailbox. Unfortunately, a limitation of SPF is that when a message is forwarded, the originating IP’s are altered, rendering the SPF record invalid and therefore failing SPF. This can result in loss of legitimate emails intended for your recipients.

Flaw #3 – SPF Implementations are restricted to a maximum of 10 DNS lookups

The RFC that governs the SPF standard has placed a limit on the number of included DNS lookups that an SPF record can contain, restricting the total number of lookups to a maximum of 10. The use of ‘include’ statements, as well as ‘mx’ and ‘a’ records in an SPF entry allows an organisation to approve additional senders as defined in a third party’s SPF record. However due to the nested nature of these ‘include’ statements, particularly within your SPF record, simply including a single third party’s SPF record can in actual fact result in a multiplier effect of sorts, where that third party’s own SPF record consequently includes multiple additional DNS lookups of its own. This problem is commonly encountered where an organisation includes Outlook’s SPF record, which in turn includes a further 2 look-ups of its own.

It’s easy to see how the DNS lookup limitation is quickly reached, and critically important to understand the risks that this limitation presents. Most notably, the RFC for SPF specifies that if this limit is exceeded, it must result in a ‘PermError’, effectively meaning that even if your SPF record is currently set to ‘SoftFail’, receiving email gateways will automatically treat this record as a ‘HardFail’, potentially rejecting a significant volume of legitimate email. Additionally, the potential exponential scaling of the resulting DNS requests associated with these lookups can be exploited as part of a DOS or Amplification attack, while also resulting in excess bandwidth and memory utilisation in some cases.

Flaw #4 – SPF lacks visibility, resulting in potential (and likely) loss of business email

A modern businesses email environment is complex. Typically, the list of applications that are approved to send email on your behalf quickly runs into the dozens. But what happens when those systems (some of them owned and managed by third parties) change their IP address? What happens when the business (or shadow IT) decides to acquire a new platform for ad-hoc customer alerts or notifications? Email originating from these applications will fail SPF, but it may be some time before anybody realises, costing your business time and money.

————–

The net result from the above limitations of SPF is that for many organisations, the Email Authentication project loses momentum and quickly falls into the too hard basket. This is evidenced by the results of our analysis of the 5200 Australian organisation domains that currently have SPF, where we have found that over half have a fail open SPF record.

It’s not all bad news. In 2004, DKIM (DomainKeys Identified Mail) was created to authenticate an email through Cryptographic Authentication. And much later, in 2012, a collaboration between PayPal, Yahoo and other leading mail senders and receivers, saw the development of DMARC (Domain-Based Mail Authentication Reporting & Compliance). DMARC addresses and plugs the gaps that existed in SPF and DKIM, and adds visibility and control. DMARC is an open standard for authenticating email, which when done correctly, can eliminate Email Fraud for an organisation.

Infotrust specialises in securing the email ecosystem and is actively evangelising the use of DMARC, alongside SPF and DKIM across the Asia Pacific Region to solve Email Fraud as an issue for businesses and Government. Here’s some of the brands that have already implemented DMARC to protect their brand and customers from Email Fraud.

For more information on DMARC, visit the Infotrust Email Fraud page on our website or check back next week for our blog on DMARC.