What do marketing campaigns and CFO fraud have in common?

Does your communications department make use of marketing agencies to organise email campaigns? How often do they switch service provider? And… is your IT department informed?

Organisations are increasingly opting for SaaS solutions to replace their on-premises applications. This probably applies to your organisation too. SaaS solutions offer many advantages, such as simple scalability, flexibility, automatic upgrades and pay-per-use. So far, so good. One feature of these SaaS applications is that they often send emails, such as notification messages, to the users. A payslip, a message that the holiday has been requested or approved or, for example, a request for access to a component of the application. And that represents a security risk which many departments are unaware of.

These notifications usually pose no problem in situations where the applications are personally managed by your IT department, as in the case of an HR or financial software package. The IT department should know what to look out for when setting it up. However, the marketing and/or communications department is not the only one to use SaaS applications, for example in the case of direct mailings for campaigns, but often seeks help from external marketing agencies, who undoubtedly make use of SaaS services too.

So, where does the problem lie precisely?

"You simply add an ‘include’ to the existing record that the supplier offers and everything is totally fine once again. Or... is it?"

Standards to recognise emails as legitimate

In order to ensure that your own and other organisations recognise your organisation as the legitimate sender of the emails sent from such an application, many of these SaaS services give a standard instruction for modifications to the so-called ‘Sender Policy Framework’ (SPF) and ‘Domain Keys Identified Mail’ (DKIM) in the DNS (Domain Name System):

SPF is an authorisation mechanism that determines via DNS whether the IP address has permission from the sending server to send emails on behalf of your organisation.
DKIM is an authentication mechanism that determines via the same type of search whether the email service in question is authorised to send email with a private/public key combination.

However, not all systems that send email support DKIM. That is why most email domains are set up to accept the email sent as ‘validated’ if at least one of the SPF or DKIM protocols has been tested successfully.

Out of these two spam-reducing solutions, SPF record (rfc7208) is the oldest and simplest solution. You simply add an ‘include’ to the existing record that the supplier offers and everything is totally fine once again. Or… is it?

One thing you need to think carefully about is whether it is actually desirable that the SPF records for those different suppliers are added just like that.

‘SPF includes’ pose a continuity risk

I regularly come across requests from marketing and communications departments to add such an ‘include’ for a campaign. However, I almost never receive a request to cancel a request when the contract with that service provider is over. Your communications department may have switched to a different agency for the next campaign in the following year. And in this way, records are added to SPF each time. However: this can’t go on forever. A hard limit, which is included in the SPF standard, applies to this.

This limit in the standard prevents a hacker from being able to block the email server of an organisation with a small amount of emails. A hacker can do this, in theory, by setting up a Christmas Tree of interlinked SPF records and includes, as a result of which the email server has to be endlessly occupied with looking up those links. In order to prevent this, the Internet Engineering Task Force (IETF) has determined that a maximum of 10 (recursive) DNS look-ups are permitted for each email address to be verified. If the sending IP address is not validated after this, the address is determined as being non-valid and this leads to a ‘permerror’ in the SPF evaluation, as a result of which the recipient interprets the mail in question as junk mail or even does not accept it at all.

It is up to the supplier of such a SaaS service to manage their SPF record further. If they also add several includes or other DNS look-ups themselves, the limit of 10 is quickly exceeded. In that case, you no longer have any control over that.

Keeping the number of SPF records to a minimum is a prerequisite for good email management.

"We teach our employees to pay attention and to recognise phishing based on anomalous sender email addresses, but what if the email address from the sender is actually correct?"

Bulk email also a security risk

However, the CISO of your organisation also needs to take a look at such requests. Marketing and advertising agencies often make use of external bulk email solutions, such as Sendgrid, Mailgun, Flowmailer and Mailchimp, for your organisation’s email campaigns. Many of these solutions often have several large public IP ranges to send email from, which they use to prevent their systems from ending up on a blacklist. And if an address is temporarily blocked, these solutions simply use one of the other thousands of available addresses. And that’s where the security question emerges.

If you add this include to the generic SPF record, the email service concerned – or another system that can be found in such an IP range – can send emails on behalf of all (existing and non-existing) email addresses; also, for example, on behalf of the CEO or CFO. A committed hacker does not therefore have to attack your own organisation, but can also opt to read the general SPF record and to attack a bulk mailer, or another SaaS application that can be found therein. CFO fraud and phishing attacks are therefore a danger. We teach our employees to pay attention and to recognise phishing based on anomalous sender email addresses, but what if the email address from the sender is actually correct?

The fact that this is not an exaggerated way of thinking was confirmed at the end of March 2022 with a hack of Mailchimp: a bulk email solution was compromised after which phishing emails were sent via the platform to end users of one of their clients in an attempt to steal cryptocurrency tokens.

Improving your SPF record

There is another option however: the SPF standards provide the opportunity for use of macro variables in your SPF record; see the image below.

By working with these variables, organisation can limit the sending of emails from an SaaS application to a number of fixed email addresses. In particular, the variable highlighted in yellow lends itself well to this, because it can create specific SPF records per email address with the part before the @. In that case, the help desk package of your organisation can only send emails on behalf of helpdesk@company.com, the payroll package only on behalf of payment@company.com and the bulk email solution of the communications department only on behalf of customerevent@company.com.

This may not apply to all SaaS applications, but it does help considerably with keeping the number of look-ups in the main SPF record low and it reduces the risks of CEO or CFO fraud. The latter because, in the event of a successful hack, the application concerned is not authorised to send an email on behalf of something other than the pre-specified email address of this application.

Are you encountering SPF-related email problems, or do you have a lot of SaaS applications that can send emails on behalf of everything and everyone in the organisation? And would you like to do something to tackle the risk of CEO or CFO fraud? Please contact Solvinity! We will be happy to explain how you can best organise these email-specific SPF records, and are also happy to help with other security-related matters.