
DomainKeys Identified Mail is a system that verifies the authenticity of emails by using a public-private key pair to sign messages. This helps prevent spammers from sending emails that appear to come from your domain.
To implement DomainKeys Identified Mail, you'll need to generate a pair of keys: a private key and a public key. The private key is kept secret and used to sign your emails, while the public key is shared with your email service provider.
Your email service provider will use the public key to verify the authenticity of your emails. This is done by checking the digital signature attached to each email against the public key. If the signature matches, the email is verified as coming from your domain.
By implementing DomainKeys Identified Mail, you can reduce the likelihood of your domain being used for spamming and phishing attacks.
You might enjoy: Service Set Identifier
What is DomainKeys Identified Mail?
DomainKeys Identified Mail, or DKIM, is a protocol that allows an organization to take responsibility for transmitting a message by signing it. This signing process is made possible through cryptographic authentication.
DKIM signatures are used to verify the authenticity of a message and prevent forged addresses and content from being created. Forged addresses and content are commonly used in spam, phishing, and other email-based fraud.
DKIM operates on the RFC 5322 message, which is the transported mail's header and body, not the SMTP "envelope" defined in RFC 5321. This means that DKIM signatures survive basic relaying across multiple message transfer agents.
Take a look at this: Bounce Message
Overview
The need for email validation is crucial because forged addresses and content are easily created and used in spam, phishing, and other email-based fraud.
System administrators often deal with complaints about malicious emails that appear to have originated from their systems, but didn't.
DKIM provides a way to sign a message and allows the sender's organization to communicate which emails it considers legitimate.
It doesn't directly prevent or disclose abusive behavior, but it does provide a process for verifying a signed message.
Verifying modules typically act on behalf of the receiver organization, possibly at each hop.
DKIM operates on the RFC 5322 message, the transported mail's header and body, not the SMTP "envelope" defined in RFC 5321.
This means DKIM signatures survive basic relaying across multiple message transfer agents.
You might like: Message Submission Agent
What is a selector?
A selector is a crucial component of DomainKeys Identified Mail (DKIM). It's a string of characters that identifies where the recipient's email server can find the domain's public key.
The selector is included in the DKIM-Signature header of every email message sent with DKIM configurations. It's found in the "s" tag, like this: "s=s837fhs;".
You can find your own DKIM selector by setting up DKIM on your email server and sending a message to yourself.
Additional reading: Courier Mail Server
Technical Details
Email authentication is a crucial aspect of DomainKeys Identified Mail (DKIM). It ensures that the sender's identity is verified and the email is not tampered with during transit.
DKIM uses cryptographic protocols to secure email communication. These protocols include hashing and encryption to prevent unauthorized access to the email content.
To prevent spam and maintain email integrity, DKIM employs anti-spam measures. This includes verifying the sender's identity and ensuring that the email content remains unchanged during transit.
The technical details of DKIM involve internet architecture and network addressing. These concepts enable the secure transmission of emails between servers and ensure that the DKIM signatures are correctly processed.
Here are the key technical details involved in DKIM:
- Email authentication
- Cryptographic protocols
- Anti-spam
- Internet architecture
- Network addressing
- Internet governance
How It Works

DKIM signing and receiving happens in three steps. The sender decides what to include in a DKIM record, which can be as specific as just the "From", "To", and "Subject" fields, or as broad as the entire header and body.
The more specific details included, the more reliable authentication will be. However, be careful not to include too much, as even the tiniest changes can lead to a failed DKIM authentication.
A hash is created from the included fields, which is then encrypted with a private key. This private key is used to decrypt the hash when it's received by the server.
Here's a simplified overview of the DKIM signing process:
The receiver generates its own hash of the fields included in the DKIM signature and compares it with the decrypted hash string. If they match, the authentication is successful, and we know the DKIM signature fields were not changed in transit, and the signer of the email truly owns the email.
Readers also liked: Html Email Signature Mac Mail
Computation Overhead

Computation overhead is a key aspect of DKIM that affects the efficiency of email delivery.
DKIM requires cryptographic checksums to be generated for each message sent through a mail server, which results in additional computational overhead.
This overhead is a hallmark of digital postmarks, making sending bulk spam more expensive.
The computational overhead is similar to hashcash, but the receiver side verification is a negligible amount of work.
A typical hashcash algorithm, on the other hand, would require far more work.
In 2013, concerns were raised about the computational overhead of DKIM, but they were refuted at the time of standardization.
Consider reading: Hashcash
SPF
SPF is a critical component in securing email communication. It stops spoofed messages using the sender's domain.
An SPF record is a TXT record on a domain's DNS servers that lists all email servers approved to send email messages on behalf of the domain. This record enables the recipient's email server to detect fraudulent messages and block them from reaching the intended victim's inbox.
For more insights, see: Comparison of Mail Servers
Here's a key point to remember: an SPF record only ensures that spoofed email messages cannot be sent to recipients, but it does not guarantee that an attacker did not tamper with the message.
SPF works in conjunction with DKIM to add security to the email system. Together, they prevent attackers from hijacking messages and sending altered messages to the recipient.
In practice, SPF helps prevent identity theft and user credential stealing, which were common issues in the past due to the inability to detect spoofed messages.
Recommended read: Why Am I Not Getting My Aol Mail
Advantages
The primary advantage of DomainKeys Identified Mail (DKIM) is that it allows the signing domain to reliably identify a stream of legitimate email, making domain-based blacklists and whitelists more effective.
This is a game-changer for email recipients, as it makes it easier to detect phishing attacks.
DKIM-enabled domains can experience a great reduction in abuse desk work if email receivers use the DKIM system to identify forged email messages claiming to be from that domain.
Intriguing read: Identify Schonbek Chandelier
The domain owner can then focus its abuse team energies on its own users who actually are making inappropriate use of that domain.
Here are some benefits for mail senders who sign outgoing email:
- It reduces abuse desk work for DKIM-enabled domains.
- The domain owner can focus its abuse team energies on users who make inappropriate use of the domain.
DKIM can prevent spammers from forging the source address of their messages, a technique they commonly employ today.
This can make it easier to identify mail that is known not to be spam and need not be filtered.
For another approach, see: Aol Mail on Android Not Working
Configuring and Implementing
DomainKeys Identified Mail (DKIM) requires a public-private key pair for authentication, which is generated using a cryptographic algorithm such as RSA or Elliptic Curve.
The public key is published in the DNS as a TXT record, while the private key remains on the mail server.
DKIM is typically implemented at the mail server level, but can also be used with email clients.
You might like: Hot Mail Server
Rotate Keys
You should periodically change the DKIM key that's used for DKIM signing, just like you would change passwords. This is known as DKIM key rotation.

The process of DKIM key rotation takes four days, or 96 hours, for the new private key to start signing messages. Until then, the existing private key is used.
To confirm the corresponding public key that's used to verify the DKIM signature, check the s= value in the DKIM-Signature header field, which infers the private key that was used to sign the message.
You can only rotate DKIM keys for domains that are enabled for DKIM signing, as indicated by the Status value being Enabled.
To rotate DKIM keys, you can use the Get-DkimSigningConfig and Rotate-DkimSigningConfig commands in Exchange Online PowerShell.
To confirm the DKIM key rotation, run the Get-DkimSigningConfig command again to check the property values, such as SelectorBeforeRotateOnDate and SelectorAfterRotateOnDate.
The recommended key rotation period is from quarterly replacement up to every six months, but the frequency should be established individually by the organization.
Here's a quick reference guide to the DKIM key rotation process:
Relationships and Interoperability
DomainKeys Identified Mail (DKIM) works well with other email authentication protocols like SPF, which also verifies email sender identity.
DKIM and SPF are two different measures of email authenticity, but they can be used together to provide a stronger authentication mechanism.
DMARC, on the other hand, allows organizations to publish a policy that specifies which mechanism (DKIM, SPF, or both) is employed when sending email from their domain.
Check this out: Email Authentication
SPF and DMARC Relationship
SPF and DMARC are two email authentication protocols that work together to secure email communication. SPF is used to stop spoofed messages using the sender's domain.
DMARC provides the ability for an organisation to publish a policy that specifies which mechanism (DKIM, SPF, or both) is employed when sending email from that domain. This policy determines how to check the From: field presented to end users, how the receiver should deal with failures, and a reporting mechanism for actions performed under those policies.
SPF records list all email servers approved to send email messages on behalf of the domain. If an attacker uses spoofed message headers, the SPF record enables the recipient's email server to detect fraudulent messages and block them from reaching the intended victim's inbox.
DMARC determines what happens to a message if it fails validation. For large businesses, DMARC rules can quarantine messages for review by an administrator. Quarantined messages don’t reach the intended recipient unless the administrator passes them to their inbox.
Here's a comparison of SPF and DMARC:
By working together, SPF and DMARC add security to the email system, a primary communication tool on the internet. This helps prevent email-based identity theft and phishing attacks.
Mail from Custom Domain at Other Email Services
Some email service providers or software-as-a-service providers let you enable DKIM signing for your mail that originates from the service.
The methods depend entirely on the email service, so be sure to check with your provider for specific instructions.
Suggestion: Quality of Service
You can use a public key to sign your mail, and the private key to verify it. This is a common practice among email services.
In some cases, you'll need to publish the public DKIM key in DNS at the domain registrar for the custom domain subdomain. This is usually done as a TXT record or a CNAME record.
To verify DKIM signing of mail from your custom domain at other email services, you'll need to follow these steps:
- Get a public key from the email service and use it for DKIM signing of outbound mail.
- Publish the public DKIM key in DNS at the domain registrar for the custom domain subdomain.
- When the email service sends mail from senders in the custom domain, the messages are DKIM signed using the private key that corresponds to the public key.
- If the destination email system checks DKIM on inbound messages, the messages pass DKIM because they're DKIM signed.
- If the destination email system checks DMARC on inbound messages, the domain in the DKIM signature matches the domain in the From address, so the messages can also pass DMARC.
What Is Gappssmtp?
Gappssmtp is a default domain key for emails sent through the Gmail SMTP server. It's used for DKIM authentication, which helps verify the sender's identity and prevent phishing.
The DKIM record will show gappssmtp for emails sent through Gmail. For example, if you receive an email from [email protected], the DKIM record will show railsware-com.20150623.gappssmtp.com.
To check the DKIM authentication record, look for the "signed by" section when you click "show details" under the sender's name. If it says "gmail", then the email was sent from a secure server with a default authentication key.
Take a look at this: Hot Mail Com
Security and Best Practices
DKIM key rotation is a must to keep your email flow secure, and it's recommended to do it from quarterly to every six months. The frequency of key rotation should be established by your organization individually.
You need to minimize the time your DKIM keys are actively used to mitigate the risks of compromising them. Private keys can be stolen if the system where they're stored is hacked.
The process of DKIM key rotation can be complicated, especially for companies with multiple email streams, delegated subdomains, or streams sent on their behalf by third parties. It's essential to plan ahead and inform all the necessary stakeholders about the key rotation process.
Non Repudiability
DKIM's non-repudiation feature prevents senders from credibly denying having sent an email.
This has proven useful to news media sources like WikiLeaks, which has leveraged DKIM body signatures to prove leaked emails were genuine.
Matthew D. Green considers non-repudiation a non-wanted feature of DKIM, as it can be forced by behaviors like those just described.
In fact, DKIM protocol provides for expiration, which can be used to minimize the impact of compromised keys.
Domain owners can revoke a public key by removing its cryptographic data from the record, thereby preventing signature verification unless someone saved the public key data beforehand.
Expired secret keys can be published, allowing everyone to produce fake signatures and voiding the significance of original ones.
Anti Phishing
DKIM can be a powerful tool in the fight against phishing. It allows mailers to digitally sign their emails, proving their authenticity and helping to prevent forged emails from reaching their intended recipients.
To take advantage of DKIM's anti-phishing capabilities, mailers can use a feature called DMARC, which allows domains to self-publish their authentication techniques. This makes it easier for recipients to determine whether an email is legitimate or not.
DKIM can also be used to identify domains that are frequently targeted by phishing attacks. By analyzing the absence of a valid DKIM signature, recipients can infer that an email may be forged.
Here's a brief overview of how DMARC works:
For example, eBay and PayPal both use DMARC to publish policies that all of their mail is authenticated. This helps to prevent phishing attacks and ensures that their customers receive legitimate emails.
Email Security
Email security is crucial in today's digital age, and one effective way to enhance it is through DomainKeys Identified Mail (DKIM). DKIM digitally signs your email messages to allow authentication, and many ISPs check the domain key in an email to determine whether it's spam.
To set up DKIM in your NetSuite production account, you'll need to follow a specific process, which involves creating a user with an Administrator role, setting up your email domain on the Email Domains (DKIM) subtab, and adding two CNAME records to your DNS. This will authenticate email messages sent from NetSuite and help enhance your reputation as a legitimate marketer.
DKIM key rotation is an essential security feature that involves systematically replacing old DKIM pairs of keys with new ones to minimize the time they're actively used. The recommended key rotation period is from quarterly replacement up to every six months, and this process should be planned ahead to keep your email flow secure.
One of the benefits of DKIM is its ability to be used as an anti-phishing technology. By signing mail from heavily phished domains, mailers can show that their mail is genuine, and recipients can take the absence of a valid signature on mail from those domains to be an indication that the mail is probably forged.
Some email service providers, like Microsoft 365, allow you to enable DKIM signing for your mail that originates from their service. However, the methods depend entirely on the email service, and you'll need to follow specific steps to enable DKIM signing for your custom domain at other email services.
It's worth noting that short DKIM keys can be vulnerable to email source spoofing, and using keys shorter than 512 bits might be incompatible. In fact, mathematician Zach Harris detected and demonstrated an email source spoofing vulnerability with short DKIM keys for several high-profile domains, including google.com.
DKIM also has a non-repudiation feature that prevents senders from credibly denying having sent an email. This feature has proven useful to news media sources like WikiLeaks, but it can also be a weakness in certain situations.
Key Rotation for Security Updates
Key rotation is a critical security update that helps keep your DKIM security up to date. It's recommended to rotate DKIM keys every 3 to 6 months, but the frequency should be established by your organization individually.
To minimize the risks of compromising DKIM keys, you need to minimize the time they are actively used. This is because even 2048-bit keys can be a target of attack if published in DNS records.
The process of key rotation can be quite complicated, especially for companies with multiple email streams, delegated subdomains, or third-party vendors. To keep your email flow secure, plan the key rotation process ahead.
Here are the key steps to consider:
- KeyCreationTime: The UTC date/time that the DKIM public-private key pair was created.
- RotateOnDate: The date/time of the previous or next DKIM key rotation.
- SelectorBeforeRotateOnDate: The CNAME record that DKIM uses before the RotateOnDate date-time.
- SelectorAfterRotateOnDate: The CNAME record that DKIM uses after the RotateOnDate date-time.
It's essential to note that the change isn't immediate, it takes four days (96 hours) for the new private key to start signing messages. Until then, the existing private key is used.
To confirm the corresponding public key that's used to verify the DKIM signature, check the s= value in the DKIM-Signature header field.
Testing and Verification
You can verify DKIM signing of outbound mail from Microsoft 365 by sending test messages and viewing the related header fields from the message header in the destination email system.
Use any of the following methods to verify DKIM signing: send test messages and view the related header fields from the message header in the destination email system, or use the test in Microsoft 365 help.
DKIM verification failure does not force rejection of the message, instead, the precise reasons why the authenticity of the message could not be proven should be made available to downstream and upstream processes.
The receiver can use the public key to validate the signature on the hash value in the header field, and check it against the hash value for the mail message (headers and body) that was received.
You can use online DKIM analyzers, such as our free DKIM Record Checker, MXToolbox, or Mail-tester.com, to validate your DKIM configuration.
Recommended read: Mercury Mail Transport System
To verify the DKIM record on Yahoo, click on “View Full Header” and search for the trace of DKIM. If you find dkim=pass (ok), you passed the test!
Here are the available tags in a DKIM TXT record:
- v (recommended), version (default DKIM1, must be the first tag if present)
- h (optional), acceptable hash algorithms (default all)
- k (optional), key type (default rsa)
- n (optional), human-readable administrator notes
- p (required), public key data (base64 encoded, or empty if the public key has been revoked)
- s (optional), service type (default *, else email)
- t (optional), toggle flags (colon-separated list, default none, may include y for testing DKIM without rejecting failed signature verifications, and/or s which is recommended for subdomain strictness as explained in the RFC)
Common Misconceptions and Troubleshooting
DKIM is often misunderstood as preventing message modification, but it's actually designed to verify and confirm that the message is intact. A passed DKIM verification test means the email sent has permission to be sent from this domain and the message content was not altered while in transit.
DKIM cannot be forged because it's based on PKI, which involves a pair of keys: one public and one private. The public key is published in the DNS records, but the private key remains secret and is used to sign messages.
DKIM only lowers the chances of spammers using forged or stolen email addresses, but it doesn't completely prevent them from doing so. In fact, spammers can buy a domain, set up a DKIM record, and continue with their spamming activities.
Using a real domain name instead of a forged one can minimize phishing attacks, like when you receive a forged email from your "bank" asking you to confirm your credit card details.
Frequently Asked Questions
What is the difference between DKIM and DomainKeys?
DKIM and DomainKeys are both email authentication protocols, but DKIM offers more flexibility and options, including multiple signature algorithms and the ability to validate both headers and bodies, whereas DomainKeys has limitations in these areas. This difference allows DKIM to provide more comprehensive email authentication and verification capabilities.
What do sender policy framework spf DomainKeys identified mail DKIM and domain based message authentication reporting and conformance DMARC provide for a domain?
SPF, DKIM, and DMARC help verify email authenticity, preventing spam and phishing attacks by ensuring emails come from the claimed domain. These authentication methods protect your domain's reputation and help keep your inbox secure.
Featured Images: pexels.com


