.svg){kind=icon}
.svg){kind=icon}
Email has become an essential communication tool, but with its rise, so have email-based threats. From phishing scams to spoofed emails, cybercriminals exploit weaknesses in email security to deceive users and compromise sensitive information. Thankfully, technologies like SPF, DKIM, and DMARC offer robust defenses against such threats. While these terms might seem intimidating at first glance, they can be broken down into straightforward concepts that enhance email security. In this blog, we'll demystify SPF, DKIM, and DMARC, providing a clear and concise explanation for beginners and insights for those looking to refine their understanding.
E-Mail Security l SPF, DKIM, DMARC
The terms SPF, DKIM, and DMARC initially seemed like complex and unfamiliar concepts to me. They were technical topics that I hesitated to explore due to the abundance of technical information. In this article, I will try to explain these concepts in a simple way for those who are not familiar with them and clear up any doubts for those who are already acquainted with them.
A Brief Overview for Those Who Don't Need Many Details:
SPF, DKIM, and DMARC are standards that help enhance email security.
- SPF allows us to determine the true sender of an email (e.g., whether an email claiming to be from Facebook actually originated from Facebook or if someone is trying to deceive us).
- DKIM, like SPF, verifies the authenticity of the claimed sender but also ensures that the email’s content remains unchanged and original.
- DMARC allows us to create rules based on SPF and DKIM outcomes. We can decide whether to accept the incoming email, mark it as spam, or reject it outright. Additionally, DMARC specifies where these events should be reported (logs).
Mechanism Workflows:
SPF (Sender Policy Framework):
By creating an SPF record for our domain or organization, we can prevent attempts to send phishing emails using our domain name. So, how do we add an SPF record?
An SPF record is a DNS TXT record. We can create an SPF record by writing the relevant text in the DNS TXT record. Here’s an example of an SPF record:
v=spf1 ip4:61.1.1.1 include:thirdparty.com -all
Explanation of the SPF record example:
v=spf1: The “v” parameter indicates the SPF version. It is generally set as static and often uses “spf1” in the modern context.
ip4:61.1.1.1: The “ipv4” parameter represents the email source IP address. This condition applies to emails coming from these specific IP addresses.
include:thirdparty.com: The “include” parameter indicates the accepted source domain addresses. Multiple domains can be included separately with the “include” parameter. The SPF record of the included domain is checked (via DNS TXT query). If the incoming email is present in the included domain’s SPF records, the condition is met. Note that a DNS query is performed for each included value.
The 'all' parameter specifies how to handle all incoming emails based on these parameters:
-all: If the sending server is not listed in the SPF records, reject the email (considered “fail and discard”).
~all: If the sending server is not listed in the SPF records, accept the email but mark it as spam (referred to as “Not pass” or “Softfail”).
+all: Accept the email regardless of the SPF records of the sending server.
Additionally, other parallel parameters may exist in DNS records, such as “a=example.com.” In this case, “example.com” represents an A record IP address. If the A record (or multiple A records) for “example.com” matches the sender’s server IP address, it is considered valid. The same logic applies to MX, IPv6, and PTR DNS records.
DKM(DomainKeys Identified Mail):
DKIM uses asymmetric encryption methods to verify the authenticity and source of an email.
Asymmetric encryption uses a public key to encrypt data and a private key to decrypt it. Data encrypted with the public key can only be decrypted with the private key. Data signed with the private key can be verified with the public key.
How Does DKIM Work?
-
The email sending server signs the email headers using its private key (stored only on the sending server).
-
The email content (body) is then signed with the private key.
-
The resulting signatures are treated as hashes. These signatures are also added to the email headers.
-
The email receiving server checks if the domain has a DKIM record by performing a DNS query. If a DKIM record is found, it retrieves the corresponding public key.
-
The email receiving server verifies the signatures using the public key from the DNS record.
-
Based on the verification result, the email’s validity is determined.
Example of a DKIM Signature:
An Example of a DKIM Record (inside a DNS TXT record)
:myselector._domainkey.domain.com TXT “k=rsa; p=AIGf … AQAB
In the email, the selector appears as “selector_domainkey.domain.” The “_domainkey” part is automatically generated, and the selector is not mandatory. However, multiple selectors can be used along with their corresponding assigned public keys.
“K” specifies the encryption algorithm used, and “p” indicates the public key.
DMARC (Domain-based Message Authentication, Reporting, and Conformance):
The DMARC standard makes decisions based on specific parameters of incoming emails (e.g., SPF, DKIM) and determines whether to accept the email, mark it with a different flag, or reject it. DMARC is satisfied if either SPF or DKIM meets the condition. If both fail, DMARC is not satisfied and is marked as “fail.” The DMARC policy then decides what action to take. Subsequently, this event is reported.
Example of a DMARC Record:
Explanation of the DMARC record:
v: Specifies the used version. We can use “DMARC1” as a constant.
p: Defines the desired policy or rule.
- none: No specific policy is defined. If there is no DMARC, the action will be the same as in the absence of DMARC.
- quarantine: Allow the email but move it to the spam folder. Usually, these emails end up in the spam folder.
- reject: Reject the email.
rua: The email address to which daily email reports will be sent.
ruf: The email address to which immediate reports will be sent in case of failure.
pct: Indicates what percentage of incoming emails should follow the specified DMARC rules. For example, if pct=10, only 10% of incoming emails will follow the defined DMARC rules, while the remaining 90% will have “none” as the policy.
How to Check SPF, DKIM, and DMARC Configurations: A Guide for Security Researchers
To wrap things up, let's dive into how security researchers can verify these configurations using various tools and techniques.
Command-Line Tools for Manual Checks
For those who prefer the command line, these tools allow you to directly query DNS records to check SPF, DKIM, and DMARC configurations:
SPF Records: Use dig or nslookup to retrieve SPF records from the domain's DNS.
Look for the v=spf1 tag in the TXT records, which indicates the SPF configuration.
DKIM Keys: Similarly, use dig to fetch DKIM public keys.
The presence of a k=rsa; or k=ed25519; tag indicates the public key used for DKIM.
DMARC Policies: You can also use dig to retrieve DMARC policies.
The v=DMARC1 tag will confirm that a DMARC policy is in place.
Online Tools for Quick Analysis
If you prefer a graphical interface or need a more detailed analysis, several online tools can help:
- MXToolbox: This tool offers comprehensive checks for SPF, DKIM, and DMARC.
- SPF Check
- DKIM Lookup
- DMARC Lookup
- DKIM Core Validator: This tool validates your DKIM keys to ensure they are set up correctly.
- DMARC Analyzer: A specialized tool that provides insights into your DMARC setup.
Leveraging Open Source Intelligence (OSINT) Tools
For more in-depth research, OSINT tools can be invaluable:
- SPF Toolbox: A web-based tool for checking and analyzing SPF records.
- SecurityTrails: This tool allows researchers to track DNS changes, including SPF, DKIM, and DMARC.
- DNSDumpster: A reconnaissance tool that helps in identifying mail servers and associated DNS records.
Final Thoughts
Securing email communication is no longer optional—it's a necessity in today’s digital landscape. By implementing SPF, DKIM, and DMARC, organizations can significantly reduce the risk of email-based attacks, safeguarding their reputation and user trust. Whether you’re a cybersecurity novice or a seasoned professional, understanding and applying these protocols is a critical step toward a safer email ecosystem. With the tools and techniques shared in this blog, you're now equipped to evaluate and strengthen your security strategy.
