Business Email Compromise (BEC) is a phishing tactic where attackers impersonate a trusted sender, like a CEO, vendor, or attorney, to trick employees into taking harmful actions. Common variations include CEO fraud, invoice scams, and executive gift card requests. These attacks can cause serious financial and reputational damage.
For example, in August 2024, a Luxembourg-based company lost $60 million in a BEC attack after an employee was tricked into wiring funds to a fraudulent account. The attackers posed as a senior executive using a spoofed email address. The funds were never recovered.
Attacks like this highlight why email authentication matters. In this article, we’ll break down the three core email security protocols, SPF, DKIM, and DMARC, and how they help stop impersonation. We’ll also cover common implementation mistakes and how to avoid them.
The table below summarizes the top three email security protocols that we will cover in this article, and important things to remember when implementing them.
| Concept | Description |
|---|---|
|
Sender Policy Framework (SPF) |
SPF is one of the top three email security protocols that relies on DNS TXT records and the sender’s IP to verify the legitimacy of the sender. |
| DomainKeys Identified Mail (DKIM) | DKIM is an important email security protocol that uses digital signatures to verify the sender's identity and that the email has not been tampered with. |
| Domain-based Message Authentication, Reporting, and Conformance (DMARC) | DMARC builds on top of SPF and DKIM and provides instructions for the recipient on how to handle and report an email impersonating the sender. |
| Defense in Depth (DiD) | Configuring SPF, DKIM, and DMARC provides a defense-in-depth approach to email security, making domain impersonation in phishing emails hard for the threat actor. |
| Important SPF, DKIM, and DMARC tips to remember | While these three email security protocols significantly improve your email security, there are several caveats and misconfigurations to consider when implementing them. |
Before the Internet Engineering Task Force (IETF) community created SPF, DKIM, and DMARC, emails lacked some basic, but critical, security features. Any threat actor could establish a plaintext Simple Mail Transfer Protocol (SMTP) connection with a target mail server and present themselves as any sender domain during the HELO “greeting” phase. For example, the threat actor could tell the recipient's mail server that they are the some_trusted_vendor.com domain, and the mail server would blindly accept this claim without any verification, allowing the threat actor to send a phishing email that impersonates a trusted entity.
For many years, threat actors exploited SMTP’s lack of built-in sender authentication. To address that gap, engineers and vendors working through the IETF, with key contributions from Yahoo!, Cisco, Google, PayPal, and others, developed three complementary standards: SPF, DKIM, and DMARC. The next sections explain how each one works and how, when combined, they provide layered protection against domain impersonation.
SPF is an email security protocol that enables domain owners to define a list of servers (IP addresses, hostnames, or include-mechanisms) authorized to send emails on behalf of the domain the entity owns. These servers are configured in a special DNS TXT record, which is made available through a designated authoritative name server.
Once you have set up and published a DNS TXT record for your domain, every time you or someone else sends emails on behalf of your domain, the recipient’s mail server will extract the sender’s domain from the Mail From email header. It will then query your authoritative name server for the DNS TXT record that contains the SPF information and compare the sender’s IP address against the IP addresses listed in the SPF record. Based on the IP comparison result and the SPF configuration (-all vs. ~all vs. +all), the recipient's mail server will decide what to do with the email.
How a recipient server looks up the sender’s SPF record and decides to pass, quarantine, or reject.
Note that, while the recipient mail server doesn’t necessarily have to perform this SPF verification, almost all modern mail servers provide this security feature, as it mainly benefits the recipient by not falling prey to domain impersonation.
DKIM uses public-key cryptography to prove a message was authorized by the sending domain and hasn’t been altered in transit. Each domain owner can generate an RSA (2048-bit recommended) or Ed25519 key pair (i.e., a public and a private key). The private key is stored securely and used to digitally sign the email before it is sent to the recipient, while the public key is used to verify the digital signature created with the private key counterpart.
However, what part of the email is actually digitally signed? To answer this question, we would need to check the fields of the DKIM-Signature email header that the sender’s mail server appends to the signed email:
|
Tag |
Purpose |
|
h= |
Defines the list of email headers that were included in the signing process, e.g., Subject, Date, Message-ID, From, etc. |
|
a= |
Defines the cryptographic algorithm that was used for signing and hashing, e.g., rsa-sha256 |
|
bh= |
The cryptographic hash of the email content/body. |
|
b= |
The digital signature of the email elements that were signed (i.e., certain email headers and the email body hash). |
|
l= |
This field is optional and, if specified, it defines how many bytes of the email body were hashed and included in the digital signature. |
Once the recipient's mail server receives the signed email, it will require the public key from the same key pair to verify the digital signature and the integrity of the email. This requirement means that organizations should make the public key available to anyone who needs to verify the emails they send. That is why, similar to the SPF information, the public key is placed in a separate DNS TXT record in base64-encoded format.
The recipient’s mail server will base64-decode the encoded public key found in the DKIM record and use it to verify the email's signature. The signature verification will be successful only if the email was signed with the private key counterpart of this public key, which only the organization publishing the public key should possess. If verification fails, the mail server can quarantine, reject, or flag the message as suspicious, depending on the local policy.
DKIM verification workflow performed by the recipient’s mail server.
Note that the security and integrity of your DNS records are important for DKIM to work. If a threat actor manages to compromise your authoritative name server, they can replace your public key with their own and send malicious emails signed with a private key they control, impersonating your domain while passing DKIM verification.
One of the shortcomings of both SPF and DKIM is that they do not compare the From email header with the Mail From (crucial for SPF) or with the “d=” field of DKIM-Signature (crucial for DKIM). Put into simpler terms, a threat actor could forge a phishing email and “fool” the SPF check by:
This way, the SPF verification will succeed for attacker.com domain, but the email client will display the email as if it is coming from some_trusted_vendor.com, tricking the victim. Similarly, the threat actor can sign a malicious email and specify “d=attacker.com” in the DKIM-Signature email header, but show something of their choosing in the From header. This lack of verification allows the threat actor to satisfy SPF and/or DKIM verification, but still trick the employee into believing the email originated from a legitimate source.
To address this issue, DMARC was introduced. This email security protocol will cover the above weakness by performing the following checks:
If the answer to any of the above questions is no, DMARC verification will fail. In this scenario, the recipient’s mail server will query the sender’s authoritative mail server for the DMARC record. DMARC is published as a separate TXT record at _dmarc.example.com (note the leading underscore). While testing DMARC before enforcing it in production is necessary to avoid any email delivery issues, it is essential not to forget to change the configuration to strict mode (e.g., “quarantine” or “reject”) to benefit from DMARC.
We’ve seen how SPF or DKIM protocols are not perfect on their own and how organizations can use DMARC to address their shortcomings. On the other hand, we also know that DMARC itself cannot function without SPF or DKIM. Like many fields of cybersecurity, it is often wise not to rely on a single security concept or tool, but to combine multiple security measures to provide defense-in-depth protection, so that when one countermeasure fails, others will still protect you. In this sense, we recommend implementing all three email security protocols to elevate your email security to the next level.
Implementing SPF, DKIM, and DMARC offers numerous security benefits. However, there are certain mistakes or security bypasses that organizations need to consider during the implementation of these email security protocols:
Threats like BEC and other phishing attacks can do lasting damage to your company’s finances and reputation. That is why the IETF community has developed robust email security protocols, such as SPF, DKIM, and DMARC, to help organizations improve their email security posture and reduce the risk of domain impersonation. While these email protocols can greatly enhance your email security, it’s possible for mistakes in implementation and maintenance to create security gaps. It is especially important to correctly configure these protocols and perform periodic maintenance to ensure that your email flow is not negatively affected. Organizations that effectively implement and maintain SPF, DKIM, and DMARC can drastically reduce the risk of email-based security breaches and data compromise.