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
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 Hexiosec ASM:
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:
So what’s the TL;DR? Here are the high-level conclusions:
~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.p=none), somewhat pointlessly.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.
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.
Let’s look first at the most important of the three: SPF.
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:
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:
all field as you’re supposed to, including some that plain forget it e.g. v=spf1 ip4:193.240.73.102+include entry, which is no longer recommended as it is explicit (see here)."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"
ptr) mechanism, which is discouraged.Ip4:88.151.128.0/21 and a Include:3pmail.ess.uk.barracuda.com.Of the FTSE250 companies we have 179 SPF records, with four with a “just block” record. Of the rest, they include:
spf.protection.outlook.com entry)_spf.google.com entry)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:
40.92.0.0/14), and it’s a range belonging to Microsoft, so that’s hard to explain.IP4:).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...
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 ...
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.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:
all field last.ptr.4 in ip4 (v=spf1 ip:12.46.7.226 -all), which is an easy mistake to make.+.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.
| Group of Domains | Microsoft 365 Using DKIM | Google Workspace Using DKIM |
|---|---|---|
| FTSE250 | 53% | 100% (only one domain) |
| Finance 500 | 43% | N/A (no-one using it) |
| Mozilla 500 | 80% | 69% |
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.
Finally we have DMARC, for which the results were pretty consistent across the three groups.
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:
sp=none), which leaves them more vulnerable for spamming.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.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%)
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.
Scan your domain to get an instant, no-registration snapshot of your internet-facing assets.
Scan my domain
Send files, collect with forms, and collaborate in spaces - all with zero-knowledge encryption and UK hosting.
Try free
