Guide: authentication
How to set up DKIM
DKIM signs each message with a private key and publishes the matching public key in your DNS, so a receiver can check which domain took responsibility for the message and that the signed parts were not changed on the way.
Last reviewed November 4, 2026
What a DKIM signature proves
DomainKeys Identified Mail (DKIM, RFC 6376) adds a DKIM-Signature header to every message. The header names a signing domain (d=) and a selector (s=), lists the headers that were signed, and carries a hash of the body and a signature over both.
The receiver fetches the public key from DNS, checks the signature and recomputes the body hash. A pass shows that the signing domain took responsibility for the message and that the signed parts did not change after signing.
Where the key lives
The public key is a TXT record at selector._domainkey.yourdomain. The selector lets a domain hold several keys at once, for example one per sending service, or an old and a new key during a change.
Your sending service generates the key pair, keeps the private key and gives you the record to publish. Copy the value exactly: a missing character in the p= value makes every signature fail.
- Long keys exceed 255 characters, the limit of one TXT string. Most DNS providers split them for you; if yours does not, enter the value as several quoted strings, which receivers join.
- Publish the record as a plain TXT record, not proxied or rewritten by a DNS service.
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...Key length and algorithm
RFC 8301 says signers must use RSA keys of at least 1024 bits and should use at least 2048 bits, and must not sign with rsa-sha1. A 2048-bit RSA key with rsa-sha256 is the common choice today and is accepted by every major mailbox provider.
What breaks a signature
Anything that changes the signed headers or the body after signing: a mailing list that adds a footer or edits the subject, a security gateway that rewrites links, or a server that re-encodes the message. Relaxed canonicalisation (c=relaxed/relaxed) tolerates changes to whitespace and to the case of header field names, not to content.
Plain forwarding usually keeps the signature intact, which is why DKIM is the more robust half of DMARC.
Check the result
Send a message to a mailbox you control and read the Authentication-Results header: dkim=pass with header.d= set to your domain is what you want. If the d= domain is your provider's and not yours, the message is signed but will not align for DMARC.
How Mail.Land handles DKIM
When you add a domain, Mail.Land generates a 2048-bit RSA key pair for it and gives you one TXT record to publish at mlnd._domainkey.yourdomain (the selector is mlnd). Every message from that domain is signed with its own key, with your domain as d=, so DKIM aligns with your From address.
DKIM is required: SPF, DKIM and DMARC must all verify before the domain can send.
Sources
- RFC 6376, DomainKeys Identified Mail (DKIM) Signatures (checked November 4, 2026)
- RFC 8301, Cryptographic Algorithm and Key Usage Update to DKIM (checked November 4, 2026)
- Google, Email sender guidelines (checked November 4, 2026)
- Yahoo, Sender best practices (checked November 4, 2026)
Put it into practice
Add your domain to Mail.Land and the dashboard shows the exact SPF, DKIM and DMARC records to publish.