Improving Email Security With DKIM
Gmail blocks over 100 million phishing emails every day. With the growing cyber menace and the integration of readily available AI-driven tools on the dark web, this number has seen a steep growth. Despite the efforts made by Gmail and other email service providers, some fraudulent emails still bypass email security filters, culminating in the exploitation of personal information, BEC attacks, ransomware attacks, impersonation attacks, etc. This is where DKIM stands as a fortifier.
DKIM or DomainKeys Identified Mail is one of the email security protocols that was developed in 2004 to overcome the shortcomings of the Simple Mail Transfer Protocol (SMTP) and Sender Policy Framework (SPF). DKIM is the combination of Cisco’s Identified Internet Mail (IIM) and Yahoo’s DomainKeys.
DKIM uses a signing method to help recipients verify the authenticity of messages they receive from your domain. This way, you disable malicious actors from compromising your email-sending domain to impersonate one of your representatives and victimize someone, tarnishing your brand reputation.
What is a DKIM Signature?
DKIM affixes a digital signature with every email dispatched from your domain to allow the receiving mail server to verify if the sender is actually who they are claiming to be. To perform this verification, the recipient’s server looks up the sending domain’s public key published in the DNS.
Apart from checking a sender’s authenticity, a DKIM signature also guarantees that nobody altered the message since the signature was affixed. Generally, an end user can’t see a DKIM signature and is placed by the infrastructure and not the email’s sender or receiver.
DKIM Signing
A message’s signing organization is either the author (the direct handler) or an independent service provider. Signing modules insert DKIM signatures to emails’ header fields, allowing signers to pick the header fields they sign. Also, the From: field should always be signed.
DKIM Tags
Here are the primary DKIM tags and their usage rules, along with examples-
v (Version)
- Usage Rule: Specifies the DKIM version being used.
- Example: v=1
a (Algorithm)
- Usage Rule: Specifies the signing algorithm.
- Example: a=rsa-sha256
c (canonicalization)
- Usage Rule: Specifies the canonicalization algorithms for the header and body.
- Example: c=relaxed/relaxed
d (Domain)
- Usage Rule: Identifies the signing domain.
- Example: d=example.com
i (Identity)
- Usage Rule: Identifies the sender’s signing identity.
- Example: i=user@example.com
q (Query)
- Usage Rule: Indicates how a signature should be treated if some missing email parts.
- Example: q=dns/txt
s (Selector)
- Usage Rule: Specifies the selector subdividing the namespace for the domain.
- Example: s=selector1
h (headers)
- Usage Rule: Lists the header fields included in the signature.
- Example: h=from:to:subject:date
bh (Body Hash)
- Usage Rule: Contains the hash value of the email body.
- Example: bh=abcdef123456…
b (signature)
- Usage Rule: Contains the digital signature applied to the headers and body.
- Example: b=zyxwvutsrponmlkjihgfedcba…
DKIM Record
A DKIM record is a DNS record that stores the public key used for verifying the digital signatures added to every outgoing message. Here’s a basic overview of what a DKIM record contains:
Selector (_s)
A selector is a subdomain’s prefix to the DKIM key that supports the management of multiple keys for the same domain.
Domain (_d)
This tag specifies the domain that is signing the email. It is the domain for which the DKIM record is published.
Public Key (_p)
It’s the cryptographically secured key used by recipients’ mailboxes or mail servers to verify senders’ legitimacy through digital signature affixed to incoming emails.
DKIM Record Example
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQE..."
Where;
- selector1: the selector
- _domainkey: A standard subdomain prefix used for DKIM records.
- example.com: the domain that is signing the outgoing message’s header.
- “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQE…”: The DKIM record itself, including the version, key type (in this case, RSA), and the public key.
Relationship with SPF and DMARC
SPF stands for Sender Policy Framework, a seasoned protocol that lets domain owners enlist which mail servers are authorized to send messages on behalf of their domain. This works by creating a TXT-type SPF record that includes all the mail servers along with syntaxes that give details and instructions to recipients’ mail servers.
SPF allows the recipient’s mail server to check whether an incoming email originated from an authorized IP address for the sending domain. It helps prevent email spoofing.
On the other hand, DMARC, or Domain-based Message Authentication, Reporting, and Conformance, is built on SPF and DKIM to operate as a framework for domain owners to specify how to check the From: field presented to end users. It directs a receiving mailbox on the handling and reporting of emails failing DKIM and/or SPF checks.
The relationship between SPF, DKIM, and DMARC is characterized by their complementary nature and triangulation of authentication. This means that if one protocol encounters a failure, the remaining protocols can take care of the assessment and authentication to shred off the efforts made by threat actors.
DKIM Key Length
Please remember that authentication is not equivalent or synonymous with abuse prevention. Bad actors can compromise DKIM keys, so the longer the DKIM key, the better you are immune against DKIM factoring.
In 2012, a mathematician, Zach Harris, detected and demonstrated the short DKIM key vulnerability in Google, Paypal, Yahoo, Amazon, eBay, Apple, Dell, LinkedIn, US Bank, HP, Match.com, and HSBC. As per him, 384-bit keys are extremely easy to compromise in less than 24 hours and 512-bit keys in almost 72 hours. Hence, it’s recommended to use DKIM signing keys that are longer than 1024 bits, which means 2048 bits or higher is what you should go for.
DKIM Key Rotation Practice
Regularly rotating DKIM keys mitigates the risk associated with compromised keys. While the frequency of key rotation depends on an organization’s email infrastructure, the IT team’s scope, attack surface, and the availability of resources, it’s strongly recommended to rotate keys at least once a year.
This ensures that any malicious activities using the compromised key become obsolete, limiting the potential damage.
The Last Thoughts
By implementing DKIM, SPF, and DMARC together, organizations can significantly elevate the security of their email communications, mitigate the risk of phishing attacks, and achieve improved visibility into potential authentication issues.
We suggest you benefit from DMARC monitoring and reporting as well to minimize the rate of false positives and efficiently transit policies. Book a demo to get started.