Email Security Hardening (Part 1): The Sender Policy Framework (SPF)

Welcome to Part 1 in our 4 part series where we will be looking at Email Security Hardening by setting up SPF, DMARC, DKIM and creating MailFlow rules. In Part 1, we will be looking at The Sender Policy Framework (SPF).

As denizens of the internet, you will have undoubtably encountered a multitude of phishing emails, ranging from the fairly obvious to the more finely crafted. As part of our “Big Red Button: PHISH” service, we track the gamut of phishing emails, looking for new trends and campaigns that emerge in messages received by our users.

One such recent campaign we have been tracking is threat actors exploiting weaknesses in (or the lack of) SPF/DMARC/DKIM entries present in a domains’ DNS record, in order to send malicious messages; spoofing the vulnerable domain.

In this tech blog, we will be looking at what SPF, DKIM, and DMARC are, as well as guidance on how they might be configured on your DNS to reduce attempted spoofing of your domain in order to send malicious emails to others (or your own users). We will also recommend some mail flow rules which can be implemented so as to better warn users.

SPF

The Sender Policy Framework (SPF) is the first port of call when hardening your domain from being spoofed by attackers. SPF is used to identify which servers are permitted to send email on behalf of your domain – both your own servers and any third-party providers – this is achieved by comparing the sending servers IP to the list of authorized IPs published in the SPF TXT entry of your DNS record.

Before starting work on constructing what your SPF entry should look like, first consider what is legitimately allowed to send mail as your domain. This may include (but is not wholly limited to) services such as:

• Mailservers (both on-prem and cloud hosted)
• eSigning services
• email signature application (if not done in house)
• mailing services (i.e. MailChimp)
• Invoicing services (SalesForce / Zoho /etc)

An SPF entries’ structure is fairly simple and can contain a number of possible elements, however, at a minimum, must contain a declaration, an IP and an enforcement rule.

Declaration

This is a fixed statement to identify in the TXT entry that it is your SPF record and should always look like

• v=spf1

IP

This lists the servers allowed to send mail on your domain’s behalf

• ip4 – a specific IPv4 address, or range (identified by including the appropriate subnet after the IP) for example

i.       ip4:240.84.10.5
ii.      ip4:207.46.100.0/24

• ip6 – operate and applied the same as above, however, specifies IPv6 addresses

 

• a – All the A records for the domain are tested. If the sender IP is found among them, this mechanism matches.

 

• mx – All the A records for all the MX records for the domain are tested. If the client IP is found among them, this mechanism matches

 

• ptr – hostname or hostnames for the client IP are looked up using PTR queries. The hostnames are then validated: at least one of the A records for a PTR hostname must match the original client IP.

 

• exists – Performs an A query on the provided domain. If a result is found, this constitutes a match. It doesn’t matter what the lookup result is, just that a match was found.

 

• include – The specified external domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next mechanism. If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Enforcement

This denotes how strictly servers should enforce the SPF rule. There are 4 possible operators to use:

• Pass [default if no explicit qualifier used]
• SoftFail [accepted by the recipient but may be marked as “likely spam”, also the best option to use when testing]
• Fail [email from unauthorized hosts should be rejected]
• Neutral [regardless of the result, accept email])

Once all valid mail servers have been determined an SPF entry may look like the following:

This is one of the more common SPF strings and usually indicates that the mail infrastructure is hosted entirely within the Microsoft 365 cloud. For other cloud-hosted mail infrastructures, the include portion would be different, for instance, include:spf.messagelabs.com would be for Symantec services (refer to your mail provider for any specific include statements you should add). It is important to note, however, the use of a SoftFail in the enforcement portion of the entry. It is recommended that you initially use the SoftFail to enable mail to continue to pass into your environment and investigate if any unexpected emails are flagged as spam, or, if additional services must be added as it is not currently present in the SPF entry.

Once created, the entry should be applied as a TXT entry in your DNS record with a hostname of @. Once testing has been conducted and the complete SPF entry is created, the SoftFail (~) should be changed to a Fail (-). Once applied, your domain will be protected (as long as the receiving server has SPF lookups enabled) from being used in a spoofing attack to external parties and assist in protecting your users from receiving messages which appear to be sent from within your organizations’ domain (i.e. internal email traffic).

An example of a finalized SPF entry may look something like this:

Common Mistakes:

Incorrect syntax/content

The rules regarding SPF/DKIM/DMARC contents in your DNS record are fairly rigid, specific tags must be included as well as a series of optional tags for more granular control. However, outside this, any additions/notations/etc may cause the policy to fail due to errors in how it is interpreted. This also applies to the addition of unexpected information in fields, such as an email address with the SPF record. Care should be taken when adding IP ranges, as the omission of “2” in a “/32” address range, could have a significant impact.

Multiple SPF record entries

A single entry is required for SPF to operate. If more than one entry is present, you will likely encounter “permerror” which means your message may be immediately rejected by mail receivers.

No tool to understand DMARC reports

DMARC aggregate and forensic reports are XML documents that contain a list of every message from your organization to the recipient domain (as discussed previously you will receive an aggregate report for each unique domain your organization has sent emails to). These reports contain a large amount of information, including; dates/IPs/SPF & DKIM results/dispositions/etc. Depending on the number of emails sent to a given domain, these reports can be very lengthy and difficult to understand. Therefore, a tool to assist in understanding these can be very beneficial. No lookup is required for ip4/ip6/all

Too many lookups

SPF is capped to 10 DNS lookups during its check. A lookup is any of the following in your SPF record: include/a/mx/ptr/exists/redirect. You should also be aware that if any referenced domain in these lookups has its own lookups, this will count towards the max lookup count. Therefore, each entry should be carefully considered as if the record exceeds 10 lookups, emails will fail SPF checks.

Use of +all

Whilst there are likely many “+” entries in your SPF record (assumed it is included before each ip4/ip6/include/etc). The inclusion of “+all” in your SPF record opposed to “~all” or “-all” will undo all the work you have implemented to further your security journey. By including “+all” if your SPF record, you authorize the entire internet to legitimately send email as your domain.

Use of SPF DNS

It was originally possible to implement your SPF entry as an SPF type in your DNS record. This is no longer possible as the option has become deprecated. Your SPF entry must now be added as a TXT type.

 

For further support from our expert Security Operations Centre and Professional Services teams, contact the Quorum Cyber team today.