DKIM setup can look like a matter of pasting one long string into DNS. Then the record is saved, but messages still have no signature. Or employee mail passes while the newsletter fails. The missing piece is often the relationship between the DNS record and the service actually sending the mail.
This guide follows fictional Gaon Trading at example.com. Employees send quotes through Google Workspace, while marketing uses a separate newsletter platform. We want both routes to produce a valid signature from the company domain. There is also a separate setup path for businesses using Microsoft 365.
A signature that the receiver can verify
DKIM attaches a digital signature to each message. Unlike a company logo pasted into the footer, the signature depends on the content being signed. If that content changes, the receiving system can detect that the signature no longer matches.
The sending server calculates hashes, short values derived from the message body and selected headers. It signs the relevant header data, including the body hash in the signature information, with a private key. The receiver repeats the calculations and verifies the signature using the corresponding public key. Changes to signed material can cause verification to fail.
- 01Sign
The sender calculates message hashes and creates a signature with its private key.
- 02Find the key
The receiver uses the signature's domain and selector to look up the public key in DNS.
- 03Verify
The receiver checks the signature and compares the received content with the signed hashes.
The private key must remain secret. With Google Workspace or Microsoft 365, the provider manages it; you do not publish it in DNS. The public key is deliberately available to anyone checking mail. Possessing that public key does not let someone create the same valid signatures. DKIM hashes and signatures ↗
DKIM does not encrypt the message. A pass also does not prove that a particular employee wrote it, a payment request is authorized, or an attachment is safe. Someone using a compromised account through the legitimate sending service can produce mail that passes.
The selector tells the receiver where to find the key
In d=example.com; s=google, d= is the signing domain and s= is the selector. Think of a selector as the name of a key slot. Employee email and newsletters can use different slots under the same domain.
Signing domain d=example.com
Selector s=google
Public-key lookup: google._domainkey.example.comThat name can contain a public-key TXT record or a CNAME pointing to a location where the public key is hosted. Calling the selector google does not itself authenticate anything. The selector in the message, DNS name, published key, and signing key must agree. How DKIM constructs the lookup name ↗
Separate the DNS settings from the message signature
During setup, you will read two kinds of information: the public-key record in DNS, and the signature and results in a received message. Your provider normally generates these values. Understanding them helps you find the right part to investigate when a check fails.
Scroll sideways to read the full table.
| Field | Purpose | What to check |
|---|---|---|
| DNS name | selector._domainkey.signing-domain | Use the issued selector at the correct domain. |
| v=DKIM1 | Public-key record version | Keep the issued value. This differs from v=1 in a message signature. |
| k=rsa | Public-key type | Use rsa when the provider issued an RSA key. |
| p=long-string | Public key for signature verification | Publish the entire key. This p= is unrelated to DMARC's policy tag. |
Scroll sideways to read the full table.
| Field | Example | What it tells you |
|---|---|---|
| d= / s= | example.com / google | Signing domain and public-key selector |
| a= | rsa-sha256 | The signature uses RSA with SHA-256. |
| h= | from:to:subject:date | Headers covered by the signature; From must be included. |
| bh= | Body hash | A calculated value for the body, not a pass indicator. |
| b= | Signature value | The actual digital signature made with the private key. |
| c= | relaxed/relaxed | Rules for normalizing headers and body before verification. |
c=relaxed/relaxed tolerates certain whitespace differences; it does not authorize arbitrary content changes. Headers absent from h= are not automatically protected. With a managed service, follow its signing configuration rather than manually rewriting signature fields. DKIM signature field definitions ↗
Choose 2,048-bit RSA keys for new deployments when supported
RSA keys of at least 2,048 bits are the recommended choice where the sending service and DNS support them. This does not mean every 1,024-bit signature immediately fails everywhere. It means shorter keys are a poor default for a new deployment. Use rsa-sha256; do not use the retired rsa-sha1 algorithm. If a provider manages the keys, check its current key sizes and rotation options. DKIM algorithm and RSA key-size requirements ↗
Google Workspace: publish the TXT record, then start signing
First confirm access to the Google Admin console and the active DNS zone for example.com. The registrar may not host the current DNS. If DKIM records already exist, find out which services use them before making changes.
- Select the domain and generate its record
In Google Admin, go to Apps → Google Workspace → Gmail → Authenticate email. Select the company domain. When a new record is needed, choose a 2,048-bit key where supported and a selector that will not conflict with an existing setup. The default selector is google.
- Publish the issued name and complete TXT value
Copy the DNS host name and TXT value from the console. Check whether your DNS host automatically appends the domain. Use the issued key, not a key copied from another company or an example.
- Confirm DNS, then start authentication
Once the correct public key is available at the expected name, return to Google's authentication screen and start authentication. Send a new message to an external mailbox to check the actual signature.
Type: TXT
Name: google._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY_FROM_ADMIN_CONSOLE
Final lookup name: google._domainkey.example.comIf the result is google._domainkey.example.com.example.com, the domain has been appended twice. Correct the name using the DNS host's input rules, then verify the final lookup location. Caches can delay visibility. Repeatedly generating new keys while waiting can make it harder to tell which key was actually published. Google Workspace DKIM setup ↗
A long key can appear as more than one quoted string
A DNS tool may display one TXT record as "first part" "remaining part". The receiver joins those strings. Splitting half the key into one TXT record and half into a second is different and incorrect. Publish one complete public-key record at the selector, and do not publish competing keys at the same name. DKIM TXT string and record handling ↗
Never trim a public key to fit a short input field. Check the DNS host's instructions for long TXT values or ask its support team how to store the complete record. Google: long TXT values and DKIM troubleshooting ↗
Microsoft 365: publish the two CNAMEs issued for your domain
Microsoft 365 normally uses two CNAME records that point to provider-managed public keys. Preparing both allows the service to use one selector and rotate to the other.
In the Microsoft Defender portal, open Email authentication settings → DKIM, select the custom company domain, and retrieve its CNAME values. Populate the targets below with the exact addresses issued for your domain.
Scroll sideways to read the full table.
| Type | Name | Target |
|---|---|---|
| CNAME | selector1._domainkey | The domain's issued Selector1CNAME value |
| CNAME | selector2._domainkey | The domain's issued Selector2CNAME value |
Microsoft introduced a new CNAME format for new custom domains in May 2025; existing configurations may use the older format. Do not construct targets by substituting a company name into a blog example. Use the current domain-specific values, publish both, and enable DKIM signing after DNS detection. Microsoft: CNAME formats and DKIM activation ↗
If you use Exchange Online PowerShell, the following read-only command retrieves configuration after you have connected with the appropriate permissions:
Get-DkimSigningConfig -Identity example.com |
Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMECheck the enabled state and status, and compare both CNAME targets if the service reports CnameMissing. Also confirm that you edited the active DNS zone. A healthy configuration status still needs an external test message. Get-DkimSigningConfig reference ↗
Verify DNS, the signature, and alignment in that order
Gaon's administrator sends a quote from an employee account to an external test mailbox. Sending only to another account inside the same organization can miss the route an outside receiver evaluates. Open the received message's complete headers, for example with Gmail's More → Show original.
1. Follow the selector in the actual message
dig +short TXT google._domainkey.example.com
# Microsoft 365 CNAME checks
dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.comFor Google, compare the public TXT key with the console-issued value. For Microsoft, compare the two CNAME targets with the issued values, and look up TXT at the targets if needed. If DNS has no answer or the wrong answer, resolve that before investigating signature calculations. Trace the selector actually present rather than guessing several possible keys.
2. A signature header and a passing signature are different things
From: sales@example.com
DKIM-Signature: v=1; a=rsa-sha256;
d=example.com; s=google;
h=from:to:subject:date; bh=...; b=...;
Authentication-Results: mx.receiver.example;
dkim=pass header.d=example.com header.s=google;
dmarc=pass header.from=example.comDKIM-Signature is what the sender attached. Authentication-Results records the receiving system's evaluation. Here the company signature passes and its domain matches From, so the DKIM path also supplies DMARC alignment.
Rely on results recorded by the actual receiving service, not any line containing PASS. An original can contain intermediate results or headers inserted by the sender. Compare the service's authentication summary with the original, and ask the recipient's administrator when the trusted result is unclear. The scope of Authentication-Results ↗
Scroll sideways to read the full table.
| Observation | What it suggests | First check |
|---|---|---|
| No signature / dkim=none | There may be no signature to evaluate. | Confirm signing is enabled on the service that actually sent the mail. |
| Signature present, verification fails | The signature, received content, or available key does not match. | Check selector, public key, and content changes after signing. |
| dkim=temperror | A temporary verification problem occurred. | Read the detailed error, check DNS, and retry. |
| dkim=permerror | A format or configuration problem prevents proper verification. | Use the detailed error to inspect the signature and DNS record. |
| dkim=pass, dmarc=fail | The passing signature may not align with From. | Compare header.d with From and inspect other signatures and SPF results. |
If a message has no company-domain signature, first check whether signing was activated rather than regenerating DNS keys. If it has a body-hash mismatch, investigate an outbound gateway adding a footer after signing. Adjust the processing order so final content is signed, then send a new test. Google: DKIM failures caused by the sending path ↗
3. Test the newsletter separately
Next, the marketing team sends through its newsletter platform. The platform's own signature passes, but it does not yet sign for Gaon:
Before
From: news@example.com
spf=pass smtp.mailfrom=bounce.mailer.example.net
dkim=pass header.d=mailer.example.net
dmarc=fail header.from=example.com
New message after company-domain DKIM setup
From: news@example.com
spf=pass smtp.mailfrom=bounce.mailer.example.net
dkim=pass header.d=example.com header.s=news
dmarc=pass header.from=example.comMake the change in the newsletter platform's sending-domain settings. Publish the separate DKIM records it issues and activate company-domain signing there. Copying Google's public key into the newsletter setup does not work: each service signs with its own private key and needs the matching public key.
The SPF domain stays different in this example, but the aligned DKIM pass is sufficient for DMARC. If the service signs as d=news.example.com while From is example.com, that can satisfy relaxed alignment but not strict alignment. Check the actual DMARC result as well as the new d= value. DKIM alignment in DMARC ↗
Prepare the next key before retiring the current one
Key rotation replaces a private/public key pair. For a system you manage yourself, a new selector makes the transition easier to track. Suppose current messages use s=mail2026a.
- 01Prepare
Publish the new mail2026b public key and confirm its DNS visibility.
- 02Switch
Start signing with the new private key and selector, then check a fresh externally received message.
- 03Retire
Remove the old public key after the planned overlap period accounts for delivery delays and caches.
Deleting the old public key the moment you switch can break verification for messages sent earlier but still in transit. DNS TTL describes caching, not the maximum lifetime of a queued message. Choose the overlap using the mail queues, retry behavior, and provider's rotation procedure rather than applying one duration everywhere. Managing selector and key lifetimes ↗
For managed services, follow the provider's rotation feature. Microsoft documents a four-day, 96-hour delay before the new private key starts signing during its custom-domain rotation process. That is a Microsoft workflow, not a universal DKIM rule. When moving to 2,048-bit keys, check both the current and next selector's key size. Microsoft 365 key rotation ↗
A leaked private key needs an incident response
If someone else has the private key, leaving the old key valid for a routine overlap may allow further misuse. Follow the sending service's compromise procedure to stop and revoke the affected key and move to a replacement. Investigate the server, administrator accounts, and sending permissions as well. Otherwise the replacement could be exposed through the same access. Cached public keys can delay the effect of revocation. Protecting DKIM private keys ↗
Gaon now has passing, aligned signatures for both employee mail and newsletters, with a record of which service owns each selector. The next step is to set up DMARC reporting and check for other senders, including automated messages the initial inventory may have missed.
Genharden DMARC · Updated 2026-09-22. Based on the SPF, DKIM and DMARC standards and the official documentation linked above. Companies, domains, IP addresses and report figures are illustrative unless stated otherwise.