Set up DKIM: find the signer, then check DNS and the message

What to establish before setup

Domain registration, DNS operation and email sending may be handled by three different providers. The receiving MX also does not reliably identify the service signing your outgoing messages. A newsletter service or website may use a separate sending route alongside your mailbox provider.

For every route actually used, record:

For your own Google Workspace domain, use the Google guide; for Exchange Online, the Microsoft 365 guide. A personal Gmail or Outlook.com account does not provide the corresponding domain administration access.

Find the correct selector

Start in the DKIM configuration of the service responsible for sending. If you already have a message sent through it, the corresponding DKIM-Signature header contains the selector in s= and the signing domain in d=. If there are several signatures, examine each combination separately. The presence of the header does not yet prove a valid signature.

The following shortened example is synthetic, not a real or verifiable signature:

d=example.com; s=mail202609
mail202609._domainkey.example.com

default, google and selector1 are possible names, not a complete list. A freely chosen selector works only if the signer uses exactly that name too. If you find no key at known selectors, other selectors may exist. There is no general DNS query that lists every DKIM selector for a domain.

1. Prepare keys at the responsible signer

With a managed sending service, let the service generate the keys. Use the DNS values it provides. The private key stays with the service and belongs neither in DNS nor in a check report. Some services supply a TXT value; others specify CNAME targets behind which they manage the public key.

For a self-hosted signer, follow its documented key format and permissions. For new RSA keys, RFC 8301, section 3.2 recommends at least 2048 bits. The mandatory minimum is 1024 bits; 1024 bits alone therefore does not establish an invalid signature. rsa-sha1 must no longer be used for signing or verification. Ed25519 is a separate DKIM algorithm, but not an option automatically available from every provider.

The following example only shows local RSA key generation in a new protected working directory. The commands were run with OpenSSL 3.6.3 for the isolated signature test. Existing files must not be overwritten; the generated private file has no passphrase and must remain protected. Importing it into the specific mail service is a further step.

umask 077
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out dkim-private.pem
openssl pkey -in dkim-private.pem -pubout -out dkim-public.pem

The second file contains only the public key in PEM format. For the DNS entry, use the export intended by the DKIM signer. Merely removing PEM boundary lines is not a complete format or setup check. Do not upload the private key to an online generator or checker. OpenSSL: genpkey, pkey.

2. Publish the intended DNS record

Identify the DNS administration that is actually responsible. dig NS example.com can indicate the name servers; for delegated subzones, examining the main domain is not enough. The registrar is the right place to enter the record only if it also manages that DNS zone.

For a direct TXT record, the public key is stored under the name formed from the selector, _domainkey and signing domain. This schematic example is not a usable key:

mail202609._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY_BASE64"

A long TXT record may consist of several character strings within one record. The limit of 255 octets applies to each string, not to the entire DKIM key. The strings are joined without an additional space. Several separate DKIM TXT records at the same selector name are not a substitute. Check how your DNS interface accepts long values. RFC 6376, section 3.6.2.

If the service specifies CNAMEs, use those instead of assembling a TXT record yourself. Check the record type, full name and target. An interface may automatically append the zone to the name entered. Do not displace an existing record at the same name without checking which sending route uses it first.

3. Activate signing

For a managed service, DNS publication is followed by that service’s activation and status check. “Record saved” in DNS administration and “signing active” at the sending service are different states.

If you manage the server yourself, the private key, signing domain and selector must match in the relevant DKIM component. Restrict key access to the service that needs it. Check the configuration with that implementation’s tools and load it using its procedure. A blanket restart of all mail services is not part of DKIM setup.

relaxed/relaxed identifies particular rules for header and body canonicalisation. They can tolerate some whitespace changes, but not arbitrary content changes. Use the documented setting for your signer; changing it does not repair a signature already damaged.

4. Check DNS and an actually sent message separately

Query the name that corresponds to the actual signing configuration. The examples use only the synthetic domain and selector from above:

dig TXT mail202609._domainkey.example.com +short
dig CNAME mail202609._domainkey.example.com +short

A CNAME leads to the key target managed by the service. Read the full response if the short form is empty or unclear, for example with dig TXT mail202609._domainkey.example.com without +short. An empty short response does not reliably distinguish a missing name from all DNS errors. Cache state, resolver and query time form part of the observation. These commands do not send a test email.

To demonstrate the signature, you need your own message sent through the route under examination and received externally. Read its original headers: which signature contains the expected d= and s=? What result does the trusted receiving service report for that signature in Authentication-Results? A freely inserted header is not a trusted verification result. The guide to interpreting header findings helps establish the connection.

The Email Security Check examines publicly discoverable DKIM keys using a limited set of known or supplied selectors. Enter the actual selector where the form provides for it. Failure to find a key does not prove that DKIM is absent. The domain check does not read a message or automatically monitor later changes.

For a new message of your own, the free German test email beta with its limited initial eligibility and scope is available through the Email Check. Observe the requirements stated there. Your private message finding remains separate from the public domain finding; it does not replace its grade. A complete English service flow is not currently enabled. If you need to document the position for a handover, the report overview explains the limited findings each document contains. A report is not an audit, compliance or security certificate.

Multiple sending services and key changes

If several services use the same From domain, every route that actually signs needs a suitable configuration. A key provided for Google Workspace does not configure a separate newsletter service. Record the signing domain, selector, record type and responsibility for each service; avoid name collisions.

For a planned change, publish the new public key under the intended new selector, check that it is reachable and then switch the signer only according to the service’s procedure. Afterwards, check a new message for the selector actually used and the recipient’s result. Old DNS keys may remain relevant to messages still in transit or verified again later. Do not remove them merely because the new configuration has been saved.

One general waiting period does not suit all caches, queues and providers. An emergency involving a compromised private key also requires a different assessment from a planned change. The DKIM chapter provides the detailed explanation; each provider’s rotation remains governed by its documented procedure.

What the isolated signature test shows

On 29 September 2026, fresh 2048-bit RSA keys were generated with OpenSSL 3.6.3. dkimpy 1.1.8 signed a synthetic message with rsa-sha256, d=example.com and s=mail202609. The verifier received the public key solely from local DNS fixtures. Their wire format and CNAME chain were processed with dnspython 2.7.0. No email was sent and no public DNS query was made.

The eleven controlled cases test signature behaviour and DNS representation. They are not the receiving internet mail service’s own Authentication-Results, nor evidence of delivery, Google or Microsoft behaviour. The private test keys were removed after the test. Your own acceptance check remains the message on the intended sending route described in step 4.

When the evidence does not match

Missing DKIM does not automatically mean DMARC failure: a successful aligned SPF path can satisfy the general pass criterion. Conversely, a published p=reject policy does not guarantee a particular recipient decision. DMARC and alignment explains these limits.

Related setup guides

More DKIM guidance: Google Workspace · Microsoft 365

For context: SPF, DKIM foundations and DMARC. For the relationship with the visible sender domain: understand DMARC alignment.