DKIM Explained: The Signature Behind Trusted Email
DKIM is the part of email authentication that survives forwarding and does most of the work for DMARC. It is also the part most often left signing with someone else's domain.
If SPF asks whether a server was allowed to send, DKIM asks something more useful: was this exact message sent by a system holding the domain’s private key, and has it been changed since? DomainKeys Identified Mail is the authentication method that survives forwarding, that most third-party platforms can align with your domain, and that does most of the real work behind an enforced DMARC policy. It is also the part most often set up on the wrong domain.
How DKIM signing works
DKIM uses a key pair. The sending platform keeps a private key and uses it to sign each outgoing message, adding a DKIM-Signature header. The matching public key is published in your DNS. A receiving server reads the signature, fetches the public key, and verifies that the signed parts of the message have not changed.
The signature header carries the details a receiver needs:
DKIM-Signature: v=1; a=rsa-sha256; d=yourcompany.co.za; s=selector1;
h=from:to:subject:date:message-id; bh=...; b=...d=is the signing domain. This is the domain DMARC checks for alignment.s=is the selector, which tells the receiver where to find the public key.h=lists the headers covered by the signature. The From header is always included.
Selectors and where keys live
The public key is published at selector._domainkey.yourdomain. Selectors let one domain have many keys at once, which is exactly what a real business needs: one for Microsoft 365, one for the CRM, one for the newsletter platform, each managed separately.
selector1._domainkey.yourcompany.co.za CNAME selector1-yourcompany-co-za._domainkey.yourtenant.onmicrosoft.com
google._domainkey.yourcompany.co.za TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC..."Some platforms ask you to publish the key as a TXT record. Others, including Microsoft 365, ask for a CNAME pointing to a record they host, which lets them rotate keys without you changing DNS again. Both work.
Signing with the right domain
This is where most DKIM set-ups fall short. Many platforms sign your mail by default, but with their own domain in the d= tag. The signature is valid, DKIM passes, and receivers can see the message was not altered. But the signing domain is the platform’s, not yours, so under DMARC it is an unaligned pass and it counts for nothing.
The fix is to enable custom domain signing in each platform, publish the key or CNAME records they give you, and confirm the d= value becomes your domain or a subdomain of it. For relaxed alignment, which is the default, a signing domain such as mail.yourcompany.co.za aligns with a From address at yourcompany.co.za.
For many platforms, custom DKIM is the only way to achieve alignment at all, because they cannot set a custom return-path for SPF. That makes DKIM the backbone of most DMARC deployments.
Why DKIM survives forwarding
SPF checks the IP address that delivered the message, so it breaks whenever mail is forwarded through another server. DKIM is attached to the message itself. As long as the signed headers and body are not changed along the way, the signature still verifies at the final destination.
Some forwarders and mailing lists do modify messages, adding a footer or rewriting the subject line, which breaks the signature. The Authenticated Received Chain standard, ARC, was developed to help receivers trust authentication results recorded by intermediaries in exactly these cases. For direct and simply forwarded mail, DKIM is the method that holds.
Managing DKIM properly
| Practice | Why it matters |
|---|---|
| Use 2048-bit RSA keys | 1024-bit keys are considered weak and some receivers treat them with suspicion. |
| One selector per platform | Lets each service be enabled, rotated or removed without affecting the others. |
| Remove keys for retired services | An old key left published is an unnecessary risk if that platform’s systems are ever compromised. |
| Rotate keys on a schedule | Limits the damage if a private key is exposed. Dual-selector platforms make this painless. |
Verify d= in real messages | The only way to confirm a platform is signing with your domain rather than its own. |
Where DKIM fits with DMARC
DMARC passes when either SPF or DKIM passes with alignment. In a well-run domain, every legitimate sending service passes DKIM with your domain as the signer, and SPF alignment is a useful second route rather than the only one. When the DMARC reports show aligned DKIM passes across all your legitimate sources, you are close to being ready for enforcement.
The short version
- DKIM signs each message with a private key; receivers verify it with the public key in your DNS.
- The
d=signing domain must be yours for DKIM to count under DMARC. - Many platforms sign with their own domain by default. Custom domain signing fixes that.
- DKIM survives normal forwarding, which makes it the backbone of most DMARC deployments.
- Use 2048-bit keys, one selector per platform, and retire keys you no longer use.
Frequently asked questions
How do I find which DKIM selectors my domain uses?
Selectors cannot be listed from DNS; you have to know the name to look it up. They appear in the DKIM-Signature header of messages you send, in the s= tag, and DMARC aggregate reports show the selectors used by every service sending as your domain.
What key length should DKIM use?
2048-bit RSA is the current standard. 1024-bit keys are still accepted by most receivers but are considered weak, and should be replaced where the platform allows it.
How often should DKIM keys be rotated?
Periodic rotation limits the damage if a private key is ever exposed. Many platforms, including Microsoft 365, support two selectors so one can be rotated while the other stays active. The schedule matters less than having a process that actually runs.
Does DKIM encrypt my email?
No. DKIM signs the message so receivers can verify it, but the content is not encrypted. Transport encryption between servers is handled separately by TLS.
Sources and standards
- RFC 6376: DomainKeys Identified Mail (DKIM) Signatures. The IETF specification for DKIM signing and verification.
- RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM. Requires RSA keys of at least 1024 bits and recommends 2048.
- Microsoft Learn: How to use DKIM for email in your custom domain. Enabling DKIM signing with the selector1 and selector2 CNAME records.
MailMarq
MailMarq is a managed DMARC service run from Johannesburg. Our team has built and managed business websites, hosting and email infrastructure for South African companies since 2016, and writes these guides from work on real domains.
Keep reading
What Is DMARC, and Why It Is No Longer Optional
DMARC is the record that decides whether criminals can send email as your business. Here is how it works, what the three policies really do, and why monitoring alone protects nothing.
SPF Explained: Why a Pass Does Not Always Mean Safe
SPF is the oldest email authentication standard and the most misunderstood. It checks a different address to the one your recipient sees, and it breaks in ways nobody notices until mail stops arriving.
DMARC for Agencies, MSPs and IT Teams: What Changes at Scale
One domain is a project. Forty client domains, each with its own senders, DNS host and approver, is an operation. Here is what breaks at scale and how to run DMARC for clients without carrying the risk alone.
Find out where your domain stands
Send us your domain. We will review your DMARC, SPF and DKIM set-up, map the services sending as you, and tell you plainly what it would take to reach enforcement. No charge and no obligation.