Email Security - Surveying big organisations' configuration

We recently wrote a guide into the basic email security configuration, which includes SPF, DKIM and DMARC. Good practice for all three is well established, and making a mistake could affect how reliably email from your domain is received by the intended recipients. So how well are big companies doing at getting it right? This blog covers some survey research we completed, which shows big companies are far from perfect

Overview

We have our own tool, written in Go, for grabbing and inspecting a given domain’s email configuration. We use it for consultancy, and it’s now integrated into FractalScan Surface:

After a bit of an update to take a target list of domains, run in lots of goroutines and output a big CSV file, it was good for doing some surveys.

Taking some of the lists from Naz’s survey of security.txt files we had some decent target lists. For this survey we used the domains from three sources:

1. the FTSE250,
2. the Mozilla Top 500 list,
3. and a list of 500 UK finance and professional services companies.

So what’s the TL;DR? Here are the high-level conclusions:

1. Most big organisations have an SPF record:
   1. But there’s a decent split between those set to soft fail (~all) and hard fail (-all). Hard fail does seem like the more rigorous option, but can lead to delivery issues, so soft fail is often recommended as the best option.
   2. Somewhere between a third and a half of records have at least one error in them. Mostly small issues, but there are some big mistakes that could impact email delivery.
2. Around half of all big organisations have a DMARC record:
   1. But around half of them have the policy set to do nothing (p=none), somewhat pointlessly.
3. DKIM adoption is harder to test, as the records can be in different places.
   1. But for email services like Microsoft 365, where we know where the DKIM key should be, we can see that lots of organisations don’t have DKIM set up.

So it’s fair to say: many big companies could do better with their email configuration. This is pretty poor; whilst getting all three records sorted can be fiddly, but doing it properly makes it harder for spammers to spoof your domains, and improves the reliability of your emails being delivered. It also shows the value of testing your own configuration, as mistakes are pretty common and could impact email delivery.

The following sections break down the results, but first there’s an important point to make on the process.

Caveats

We didn’t do much grooming or tidying of the input domain lists, so in some cases where we didn’t find a record it might be that the tested domain isn’t the principal domain in use. For example, it could be the domain for the company group or corporate site, which isn’t used to send emails. For example, 62 of the 500 finance companies and 4 of the FTSE250 have a “just block” SPF record that v=spf1 -all, which tells us that that domain doesn’t send emails, but they have at least published an SPF record to make that explicit.

We’ve not taken the absence of a record to mean one doesn’t exist, just that we didn’t find it. Although there are presumably lots of cases where we have the correct domain but they genuinely don’t have SPF, DKIM or DMARC. For now, we’ll let them get away with it and focus on examining the records we can find.

SPF

Let’s look first at the most important of the three: SPF.

Finance 500

We found 471 spf records of the 500, which given the caveat above is pretty good. Although 62 records are the “just block” record of v=spf1 -all, so really we have 409 records that send email.

Of those, 14 have the Microsoft 365 entry spf.protection.outlook.com, and none are on Google Workspace, which means a lot of people are using security products that sit between the email service and the sending process, and/or have their own mail servers. To reinforce the former point, for the 409 records we can find:

• 177 using Mimecast
• 11 on Proofpoint
• 32 on Symantec Messagelabs

Bonuses all round at the Mimecast sales team, that’s decent penetration.

In teams of the all policy, which tells recipients what to do when they receive email from a source other than those listed in the SPF record, there’s a fair split between hard and soft fail, and a small number doing nothing:

There’s also a fair spread of minor mistakes in the records, with around a half of them having at least one issue. The more common mistakes include:

1. 5 that don’t end with all field as you’re supposed to, including some that plain forget it e.g. v=spf1 ip4:193.240.73.102
2. 8 records still using the leading +, such as for a +include entry, which is no longer recommended as it is explicit (see here).
3. 5 records have large IP ranges, such as /15 ranges. This covers 131,072 addresses, which seems too broad.
4. 2 private IP ranges
5. One has three published SPF records:

   "v=spf1 include:spf.protection.outlook.com -all"
   "v=spf1 +a +mx +ip4:35.214.42.72 include:_spf.mailspamprotection.com ~all"
   "v=spf1 include:trustpilotservice.com include:outlook.com ~all"
   

   This can cause a SPF authentication fail.
6. 6 uses of the pointer (ptr) mechanism, which is discouraged.
7. 12 double spaces in a record, which can trip up some parsers.
8. Some upper-case characters in the records, which shouldn’t be users. For example there’s one Ip4:88.151.128.0/21 and a Include:3pmail.ess.uk.barracuda.com.

FTSE250

Of the FTSE250 companies we have 179 SPF records, with four with a “just block” record. Of the rest, they include:

• 98 on Microsoft 365 (with the spf.protection.outlook.com entry)
• 6 on Google Workspace (with the _spf.google.com entry)
• 13 using Proofpoint
• 66 using Mimecast
• 16 using Symantec Messagelabs

There’s a similar breakdown of the all policy as we saw above:

For other issues, in total 95 of the 174 proper records have at least one issue. The common ones are:

1. Including a wide range of IP addresses e.g a /14 range. Intrigued as to whether the company owns the whole range, I looked into one of them (40.92.0.0/14), and it’s a range belonging to Microsoft, so that’s hard to explain.
2. A few entries in uppercase (IP4:).
3. one double space (look carefully):

   v=spf1  ip4:77.111.213.7/32 ip4:77.111.213.8/32 ip4:77.111.213.39/32 include:spf.protection.outlook.com...
   

4. One organisation has four private IP addresses specified, which isn’t wrong but is likely pointless as SPF won’t be evaluated for internal mail:

   v=spf1 ... ip4:10.208.82.53 ip4:10.208.48.52 ip4:10.151.176.16 ip4:10.112.2.70 include:spf.protection.outlook.com ...
   

5. There are 4 include: entries across all the records few include entries that don’t specify their own SPF record, presumably they’re all out of date entries.

Mozilla Top 500

Of the 500, we found 411 SPF records, of which 28 have a “just block” record.

The stats for the all policy are pretty much the same as the two groups above, with 49% using hard fail. Interestingly, compared the two UK groups, Mimecast don’t have such dominance, with Proofpoint being the most common email security tool. Similarly there are more organisations on Google Workspace (139) than Microsoft 365 (85)

In terms of issues with the records, it’s pretty much the same stuff:

1. There’s a bunch of included wide IP ranges, including a couple of /12s (1,048,576 addresses!).
2. Four records that don’t have the all field last.
3. A couple of records using ptr.
4. Two private IPv4 addresses in different records.
5. One record where they forgot the 4 in ip4 (v=spf1 ip:12.46.7.226 -all), which is an easy mistake to make.
6. Two with fields that have a leading +.

DKIM

It’s a little hard to measure DKIM usage, as the location of DKIM keys differs between services (we covered this previously). What we can do is look for DKIM keys where we know from the SPF record what email service they’re using, and therefore where the key should be.

These stats are pretty poor. We know these domains have an active SPF record, so they’re sending emails from that domain. Given that it’s fairly straightforward to implement DKIM for both services, there’s no real excuse. And turning it on means recipients can verify the message wasn’t changed, which is especially important given how common it is for spammers to pretend to be these sorts of companies.

DMARC

Finally we have DMARC, for which the results were pretty consistent across the three groups.

Finance 500

Looking first at the finance companies, over a third have their policy set to do nothing:

This makes the DMARC record somewhat pointless in defending against spam, although it will still work for reporting email issues.

Additionally, there are some other issues with some records:

1. 16 have the subdomain policy set to do nothing (sp=none), which leaves them more vulnerable for spamming.
2. 8 records don’t have the percent (pct) at 100, meaning whatever is in the record won’t be applied to all emails. One has it as low as 5%, which makes the whole record close to pointless. Let’s hope they’re just testing it now, and will change it to 100% soon.

FTSE250

An equal 41% have their policy set to none or reject, with the remaining 18% on quarantine. As above, 17 have no subdomain policy, and two don’t have pct at 100 (one at 50%, one at 25%)

Mozilla 500

Finally there are very similar results for the Mozilla Top 500 list, with 41% on reject, 21% on quarantine and 38% on none. 9 records don’t have pct at 100 (3 have it at 5%), and 29 have no subdomain policy.

• Are your domains protected from spoofing and phishing attacks?
• Email Security - The Basics
• Why we should stop using email attachments

About Scott Lester

Scott is a technical cyber security professional with over fifteen years’ experience across a broad range of roles within the public and private sectors. With a deep understanding of cyber security, he has in his career focused on applied cryptography, network technologies, digital forensics and security research. At Red Maple he leads the delivery of all of our cyber security services.