DKIM and Its Setup — Explained Simply with Examples
Published 6 June 2025 · Kristyna Vrbova
DomainKeys Identified Mail (DKIM) is a core component of modern email authentication. It allows domain owners to digitally sign outgoing emails.
In this guide, we’ll explain DKIM in simple terms, why it matters, and how it works behind the scenes. Whether you're using an email delivery service like Sidemail, Sendgrid, Mailgun or similar, or managing your own mail server, this article will guide you through everything you need to know to get DKIM up and running smoothly.
What is DKIM? Explained simply
DomainKeys Identified Mail (shortly DKIM) is an email authentication standard that uses cryptographic signatures to verify that an email was truly sent by the owner of the sending domain and that it wasn’t altered in transit. It allows you (your service, application, or website) to “sign” its outgoing emails with a digital signature linked to your domain.
Imagine DKIM like putting a unique, tamper-proof seal on every email you send, so that when it arrives, the recipient’s mail service can check that it really came from you and hasn’t been changed along the way. It works by using a digital signature, created with a private key only the sender controls, and matched against a public key published in their domain’s DNS records. If the signature checks out, the email is considered authentic and trustworthy; if not, it might be treated as suspicious or rejected. This helps protect against email forgery and ensures messages stay intact from sender to recipient.
Why does DKIM matter?
Because email is a critical channel for user communication – from verification codes and password resets to onboarding emails and newsletters. Implementing DKIM is one of the best ways to protect your brand against email spoofing and to ensure reliable delivery. It effectively ties your domain’s identity to every email you send, making it much harder for attackers to send fraudulent emails pretending to be from your SaaS. In conjunction with other measures, DKIM improves your email deliverability (less chance of being flagged as spam) and safeguards your customers by preventing tampering with email content.
In short, DKIM adds a layer of trust to your outbound emails that mailbox providers and recipients can rely on.
How DKIM works (step‑by‑step)
At a high level, DKIM works by using a pair of cryptographic keys (one private and one public ) to sign and verify emails. Here’s a step-by-step overview of how the DKIM process unfolds:
- Key generation:
- A domain owner (or their email service provider) generates a public/private key pair for DKIM. The private key is kept secret on the sending mail server, and the public key is published in the domain’s DNS records (as a special TXT record). This public key DNS entry is known as the DKIM record, and it’s what recipients will use to verify signatures.
- Email signing:
- When your service or application sends an email, the mail server uses the domain’s private key to create a unique digital signature for the message. It does this by hashing select parts of the email (for example, the headers like “From:”, “Subject:”, and the message body) and then encrypting that hash with the private key. The result is placed in a new email header called DKIM‑Signature. This header includes: the domain that is claiming responsibility (the
d=
tag), the selector name (thes=
tag – we explained more details about DKIM selectors in separate article), and the signature itself (b=
tag), among other metadata. For example, a DKIM‑Signature header might look like:
DKIM-Signature: v=1; a=rsa-sha256; d=saasapp.com; s=txn1; h=from:subject:date:content-type; bh=…; b=<long signature hash>
- This header is added to your email and travels with it to the recipient.
- When your service or application sends an email, the mail server uses the domain’s private key to create a unique digital signature for the message. It does this by hashing select parts of the email (for example, the headers like “From:”, “Subject:”, and the message body) and then encrypting that hash with the private key. The result is placed in a new email header called DKIM‑Signature. This header includes: the domain that is claiming responsibility (the
- DNS lookup (public key retrieval):
- When the recipient’s mail server gets the email, it sees the DKIM‑Signature header and extracts the domain (
d=saasapp.com
) and selector (s=txn1
). Using these, the receiver constructs a DNS query to retrieve the public key. Specifically, it looks up a TXT record attxn1._domainkey.saasapp.com
, which is the location of the DKIM public key for that domain/selector. (By convention, all DKIM public key records live under the_domainkey
subdomain of your domain.)
- When the recipient’s mail server gets the email, it sees the DKIM‑Signature header and extracts the domain (
- Signature verification:
- The recipient’s mail server then uses the fetched public key to decrypt the signature in the DKIM‑Signature header. It also computes its own hash of the email’s relevant parts (the same parts that were hashed by the sender). If the decrypted signature matches the hash that the receiver computes, it means two things:
- the email truly originated from the holder of the domain’s private key (i.e., your SaaS or its mail service), and
- the email’s headers and content weren’t altered in transit. In other words, the signature is valid and the email passes DKIM verification.
- The recipient’s mail server then uses the fetched public key to decrypt the signature in the DKIM‑Signature header. It also computes its own hash of the email’s relevant parts (the same parts that were hashed by the sender). If the decrypted signature matches the hash that the receiver computes, it means two things:
- Resulting trust:
- If DKIM verification passes, the recipient server flags the message as authenticated for that domain. This makes the email far more likely to land in the inbox rather than being suspected as spam or phishing. (Other filters still apply, but DKIM pass is a positive signal.)
- If the DKIM check fails (because the signature was missing, broken, or the keys didn’t match), the email will be treated with suspicion – it might be marked as spam or rejected, especially when combined with other policies like DMARC (more on that later).
How to set up DKIM for your domain
Setting up DKIM may sound technical, but modern email providers (ESP) and services have made it straightforward. As a SaaS company, you’ll typically use an email sending service (like Sidemail, SendGrid, Mailgun, etc.) or your own mail server to send emails. Let’s break down the setup process:
DKIM setup with email delivery services (e.g., Sidemail, SendGrid, Mailgun)
- Obtain DKIM from your dashboard
- Most email delivery services generate a DKIM key pair for you. This includes a public key (to be published in DNS) and a private key (used by the provider to sign emails). You’ll typically find this in the service’s dashboard under sections like “Domain authentication” or “Sending domains.”
- Publish the Public Key via DNS
- Your provider will supply one or more DNS records (CNAME or TXT). These records must be added to your domain’s DNS settings. Be sure to include the entire public key string without modifying it, and avoid line breaks, spaces, or punctuation changes.
- CNAME record example:
Name:ka76aowijf._domainkey
Value:ka76aowijf.dkim.sidemail.net
- TXT record example:
Name:selector._domainkey.yourdomain.com
Value:v=DKIM1; k=rsa; p=MIIBIjANBg…(base64 public key)
- Verify DNS Setup in Your Provider Dashboard
- Once the DNS record is added, the provider will typically attempt to verify it. Status indicators like “DNS record not found” will change to “Verified” once the record is correctly propagated.
- Start Sending Signed Emails
- Once verification succeeds, your emails will be automatically signed with the DKIM private key managed by the service. No code changes are needed. If you want to double-check it’s working, send a test email and check for the DKIM‑Signature header, ensuring the domain in the d= field matches yours.
💡 Note: Some modern email services like Sidemail offer direct integration with DNS providers such as Cloudflare. This allows you to authenticate with your DNS provider through the service’s dashboard and have all required DKIM records added automatically, eliminating the need for manual copy-pasting or DNS editing.
DKIM setup for self-hosted mail servers
- Generate a DKIM key pair
- You can use OpenSSL, which is commonly preinstalled on Unix/Linux systems to generate a key pair:
- a. Generate a 2048-bit private key (private key will be then used by your server to sign outgoing emails)
openssl genrsa -out mail2025.private 2048
- b. Extract the public key (public key will be then published in DNS)
openssl rsa -in mail2025.private -pubout -out mail2025.public```
- c. Extract the Base64 public key for DNS
awk 'NR>1 && NR<$(NF){printf "%s", $0} END {print ""}' mail2025.public | \ sed 's/-----.*-----//g' | tr -d '\n' > dkim_key.txt
- a. Generate a 2048-bit private key (private key will be then used by your server to sign outgoing emails)
- You can use OpenSSL, which is commonly preinstalled on Unix/Linux systems to generate a key pair:
- Publish the Public Key via DNS
- Create a TXT record in your DNS zone. If you used commands above for generating DKIM key pair, open dkim_key.txt, copy the content, and paste it into your TXT record like this:
- Name:
mail2025._domainkey.yourdomain.com
- Value:
v=DKIM1; k=rsa; p=<contents_of_dkim_key.txt>
- Name:
- Create a TXT record in your DNS zone. If you used commands above for generating DKIM key pair, open dkim_key.txt, copy the content, and paste it into your TXT record like this:
- Configure your mail server to sign emails
- Update your mail server settings to use DKIM signing. This involves:
- Specifying the path to the private key
- Setting the DKIM selector (used in the DNS name)
- Enabling signing for the correct domain(s)
- Update your mail server settings to use DKIM signing. This involves:
- Verify your DNS records
- Use tools like nslookup, dig, or online DKIM checkers to confirm your DNS record is visible. Propagation can take a few minutes to 72 hours depending on your TTL settings.
- Test email signing
- After setup, send a test email and inspect the headers for a DKIM‑Signature. Look for your domain in the d= tag to ensure the signature is applied correctly.
What is DKIM alignment
Setting up DKIM is an important step in email authentication. But if you choose to use DMARC (Domain-based Message Authentication, Reporting & Conformance) to protect your domain, there’s more to it than just having DKIM – it also needs to be aligned.
DKIM alignment means the domain used in your DKIM signature (the d= value) matches the domain in the “From” address of your email. This helps receivers confirm that the sender is who they claim to be.
Types of DKIM alignment
- Relaxed (default): The domains can be a parent and subdomain (e.g.,
yourcompany.com
andupdates.yourcompany.com
), and still be considered aligned. - Strict: Domains must match exactly. Using
yourcompany.com
for the DKIM signature while sending fromupdates.yourcompany.com
would fail under strict alignment.
Scenario | From address domain | DKIM d= domain | DKIM alignment |
---|---|---|---|
Same domain (exact match) | user@yourcompany.com | yourcompany.com | Aligned (passes in both strict and relaxed) |
Subdomain vs. root domain | user@updates.yourcompany.com | yourcompany.com | Aligned (passes in relaxed mode; fails in strict mode) |
Different domains (mismatch) | user@yourcompany.com | someotherservice.com | Not aligned (fails alignment) |
Even if your DKIM signature is valid, it won’t pass DMARC unless the domain is aligned – or unless SPF (another method) passes and is aligned instead. DMARC only requires one of these (DKIM or SPF) to both pass and be aligned.
💡 Note: DMARC is optional, but it’s a valuable to protect your domain from spoofing and phishing. It’s widely recommended, especially for bulk senders.
Related terms – SPF and DMARC
DKIM is a cornerstone of email authentication, but it’s not the only piece. Two other major protocols that SaaS companies should implement are SPF and DMARC:
- SPF (Sender Policy Framework): SPF allows a domain to specify which mail servers are authorized to send email on its behalf. This is done via a DNS TXT record that lists permitted IP addresses or hostnames. When an email claiming to be from your domain arrives, the receiver can check the SPF record to see if the sending server’s IP is on the list. If it’s not, the email fails SPF. In effect, SPF helps prevent fraudsters from spoofing your domain to send unauthorized emails
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): DMARC is built on top of SPF and DKIM to enforce alignment (as discussed above) and to provide instructions to receiving servers on how to handle emails that fail authentication. With DMARC, the owner of the domain publishes a DNS record that tells receivers what policy to apply if an email doesn’t pass SPF and/or DKIM checks – for instance, do nothing, quarantine it (e.g. send to spam), or reject it outright.
Wrapping up
Together, SPF, DKIM, and DMARC form a triad of defenses for your outbound email.
SPF addresses who can send emails for your domain, DKIM addresses how to verify an email’s integrity and sender via a signature, and DMARC ties the results of SPF/DKIM to the domain’s own policies and enforcement. For a SaaS startup looking to establish trust and hit the inbox consistently, setting up all three is highly recommended.
By implementing these authentication standards, you not only protect your brand’s reputation and your users from phishing, but you also signal to mail providers that you’re a legitimate sender – which over time improves your deliverability.
👉 Try Sidemail today
Dealing with emails and choosing the right email service is not easy. We will help you to simplify it as much as possible. Create your account now and start sending your emails in under 30 minutes.