Definition
DKIM is defined in RFC 6376. The signing server computes a hash of selected headers and the body, signs it with an RSA or Ed25519 private key, and inserts a DKIM-Signature header naming the domain (d=) and a selector (s=). The public key lives at selector._domainkey.domain in DNS.
Why it matters
SPF checks the connecting server, which fails legitimately when mail is forwarded. DKIM travels with the message and survives forwarding, so it is the most reliable way to prove origin. A valid DKIM signature on the same domain as the From header is what allows DMARC to pass, and increasingly what large providers require before they will accept mail at all. DKIM does not encrypt content; confidentiality in transit comes from TLS.
How it works
- Your provider generates a key pair for your domain and gives you the public key as a TXT record to publish.
- When you send, the server canonicalises the message, hashes it, signs the hash with the private key and adds the
DKIM-Signatureheader. - The receiver reads
d=ands=from the header, fetchess._domainkey.dfrom DNS, and verifies the signature against the message it received. - A match means the message is authentic and unmodified; a mismatch means it was altered or forged.
Example
ontech._domainkey.yourdomain.co.zm. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...IDAQAB"Here ontech is the selector, k=rsa the key type, and p= the base64 public key. A signed message carries a header such as DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.co.zm; s=ontech; h=from:to:subject:date; bh=...; b=....
Common problems
- Record split incorrectly. Long keys exceed 255 characters; some panels mangle the split. Paste exactly as shown and re-check.
- Wrong selector. The DNS name must match the
s=value used by the sender. - Mailing lists and footers. Anything that changes the body after signing breaks the signature. DMARC with a DKIM-only expectation should account for lists.
- Key never rotated. Rotate periodically by publishing a new selector, switching signing, then removing the old one.
- Signing from a shared provider key. Some hosts sign with their own domain rather than yours; that passes DKIM but fails DMARC alignment for your domain.
How ontechmail handles it
Each domain added to ontechmail receives its own key pair at creation. The dashboard shows the TXT record with the selector to publish; on ontechmail-hosted DNS it is seeded automatically. Every message sent through webmail, the OMail app, the REST API or SMTP submission is signed with that domain's key, so the signature is on your domain and aligns for DMARC. On a self-hosted deployment the private key is generated and stored on your infrastructure and is never held by Ontech. Domains that relay through a third-party provider instead of sending directly can still use their own DKIM key, published the same way.
Frequently asked questions
What is DKIM?
DKIM (DomainKeys Identified Mail) adds a digital signature header to outgoing email, created with a private key held by the sending server. Receivers fetch the matching public key from a DNS TXT record on the domain and verify the message was not altered.
What is a DKIM selector?
A selector is a label that tells receivers which DNS record holds the public key, so a domain can hold several keys. The public key lives at selector._domainkey.yourdomain.
Does DKIM encrypt my email?
No. DKIM proves origin and integrity; it does not hide content. Confidentiality in transit comes from TLS.
How does ontechmail handle DKIM?
Each domain gets its own key pair when it is added. The dashboard shows the TXT record to publish, and every message sent through webmail, the app, SMTP submission or the API is signed with that key.