According to recent research, nearly 90% of email attacks are based on false sender identities, both brands (83% ) and individuals (6%). One type of identity theft, so-called exact domain identity theft, occurs when scammers use a domain in the From field of the message that is owned by the organization they are impersonating.

There are ways to prevent spammers and phishers from spoofing your domain. Email authentication – verify that an email really comes from the domain it claims to come from – is based on widely-accepted standards, well documented in our article. These security mechanisms are relatively easy to set up and offer a good level of protection.

If these methods almost completely block spam, why are we still hearing about them widely? In practice, not all companies implement them.

SPF, DKIM, DMARC

Implementing SPF is just the beginning, for effective protection, it is also necessary to implement DMARC, and consequently, DKIM.

DMARC provides three main elements to the previously existing email authentication standards:

• Reports: Recipients who participate in DMARC agree to provide email authentication reports to sending domains
• Policy: With DMARC, sending domains can advise how a recipient should treat an email that fails authentication, rather than leaving it to the recipient’s discretion
• Identity Alignment: DMARC prioritizes the user-readable From address as the origin of the identity and considers only authentication results for identities that are aligned with this From address

Problems

Like any protection, these too are an additional problem to solve for the proper functioning of the system: Broadly speaking, the owner of the domain decides what the recipient will do with the emails received in his name.

There is no quick and safe way to test whether a configuration works or not, without involving several parties at the same time. This makes everything more academic: You have to sit in front of a paper and design the policy so that it can theoretically work; once implemented, you must monitor its actual functioning and react to any problem.

The protection systems mentioned are difficult to understand and implement for a common IT department, because:

• is a one-time setup
• as soon as you touch the email and something doesn’t work, you are overwhelmed with phone calls and complaints

Besides, there are some specific technical criticalities:

• Protocols are interdependent: DMARC is based SPF and DKIM, which are also delicate to implement and prone to errors
• SPF Request Limit as a Risk: A security measure that can cause a lot of trouble if underestimated

This explains, in part, why many administrators prefer to avoid its implementation or implement it “Pro-forma”.

The Analysis

To find out what is the implementation state in the various companies that communicate daily with millions of users, we tried to do a sample analysis of domains that we think are interesting. The list of domains is provided by OpenPage Rank, we have selected the domains (based on TLDs, keywords, etc.), analyzed the public DNS records, and assigned a security score to the various policies found.

Method

The analysis of the records includes both the identification of the mechanisms present (SPF, DKIM, DMARC) and the defined policies.

In policy analysis:

• the mechanism used is identified
• its configuration is weighted: For example, for SPF, the policy of the all_qualifier is analyzed, and only if it is - no point is subtracted
• a score is assigned to the policy: +100 the safest and -100 the weakest policy

The information collected is stored in a MongoDB for analysis:

Dataset

We analyzed 414783 domains, selected by specific top-level-domains:

Results

Usage of security mechanisms

The following figure shows how many domains, in total and grouped by selected TLDs, are implementing protection mechanisms.

The next figure illustrates in detail for each TDL the percentage of domains using protection mechanisms.

Takeaway:

• a very small number of organization use all security mechanisms
• the most implemented protection mechanisms is SPF
• the average SPF implementation ratio is around 45%/55%
• the .bank domains (to become a .bank Registrant, your organization must be one government-regulated entitiy) have an SPF implementation ratio of 75%/25%, also much secure as the average domain
• the implementation in education and government TLDs is in an early stage

Domains Security Levels

The next figure shows the distribution of domains per security level range.

The security level is calculated based on the presence of the protection mechanisms and how good is configured.

Takeaway:

• about 70% of analyzed domains perform poorly
• about 25% of analyzed domains has an acceptable policy

SPF configuration quality

We now take a closer look at two specific SPF mechanisms (all and ip4_prefix), to show the creativity of some administrators with SPF policies.

The all mechanism

This shows how the most important mechanism of the SPF policy, the all, is configured across the analyzed domains. This mechanism indicates what to do with the non-compliant emails (drop, tag, or ignore). This mechanism is mandatory.

This is a good example of what can go wrong: "v=spf1 +all" is a valid SPF policy, but as stated by SPF organization, The domain owner thinks that SPF is useless and/or doesn’t care.

Takeaway:

• 50% of the .bank TDL correctly requests to drop the non-compliant mails
• only 12% of the TDLs correctly requests to drop the non-compliant mails
• 30% of the TDLs requests to drop or flag the non-compliant mails
• 70% of the domains basically ignore the configured SPF policy

The ip4_prefix mechanism

The figure shows the configuration of another SPF mechanism, the ip4. This mechanism is used to mark a certain number of servers as valid mail servers for the domain. We extracted the mask to calculate how many servers are whitelisted with this mechanism. The number of those servers should be limited to the mail servers only. Note, that this mechanism is optional.

Takeaway:

• 25% of the domains correctly restrict the ip4_prefix to the smallest number possible (32), marking only one ip as a valid mail server
• about 1000 domains allow big-masks to send mails in its own name (v=spf1 mx a ip4:12.0.0.0/2 ip4:72.0.0.0/2)

Other Mechanisms

There are eight mechanisms analyzed for the SPF. We have shown only two in detail, to emphasize that even the presence of the SPF policy is not a guarantee of safety. Furthermore, the intentions of those who configure an ip4 prefix to 0 are always, at least, rummy.

Summary

Systems to protect against identity theft exists for many years, but for various reasons, they are not yet used on a large scale and are often used only in an informational mode.

Our research shows how the implementation of such systems, even for sensitive domains, is still far from complete.

About the Author

Rocco Gagliardi has been working in IT since the 1980s and specialized in IT security in the 1990s. His main focus lies in security frameworks, network routing, firewalling and log management.

Links

• http://dkim.org
• http://www.open-spf.org
• http://www.open-spf.org/SPF_Record_Syntax/
• https://assets.barracuda.com/assets/docs/dms/Spear_Phishing_Top_Threats_and_Trends.pdf
• https://dmarc.org
• https://github.com/tb0hdan/domains
• https://www.domcop.com/openpagerank/what-is-openpagerank