DKIM Setup Guide DNS Record Creation

DomainKeys Identified Mail, or DKIM, is one of the most critical authentication mechanisms in modern email security. Its purpose is to verify that an email was sent from an authorized server and that its contents have not been altered in transit. DKIM works by applying a digital signature to the headers of an outgoing message. This signature is generated using a private cryptographic key stored on the sending mail server. The corresponding public key is published in the domain’s DNS in the form of a specially formatted TXT record. When a recipient mail server receives the email, it retrieves the public key via DNS and uses it to verify the authenticity of the signature. A properly configured DKIM system ensures higher deliverability, helps prevent spoofing, and contributes to overall domain reputation.

Setting up DKIM begins with generating a key pair. The private key remains securely stored on the mail server or within the sending platform, depending on whether the mail is being sent through an internal mail system or a third-party provider. The public key must be published in the DNS zone for the sending domain. When generating the key pair, a selector is also specified. The selector is an arbitrary string that acts as a namespace identifier for the DKIM key and allows domains to support multiple keys simultaneously. This is useful for key rotation, multiple applications, or different mail streams within the same domain.

Once the key pair is generated, the next step is to create a DNS TXT record for the public key. The name of this record combines the selector and a fixed subdomain, forming a string such as selector._domainkey.example.com. For instance, if the selector is “mail1” and the domain is example.com, the DNS name for the DKIM record would be mail1._domainkey.example.com. The value of the TXT record contains the public key in a structured format, beginning with the tag v=DKIM1 to indicate the version and k=rsa to define the key type. The actual key itself follows the p= tag and must be a valid base64-encoded RSA public key. For example, a typical DKIM TXT record might appear as:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3…

The public key must be carefully copied into the DNS TXT record without introducing formatting errors. Line breaks, additional whitespace, or omitted characters can cause the DKIM signature to fail validation. Many DNS providers impose length limits on TXT records, and in some cases, long keys may need to be split into multiple quoted strings that are concatenated by the DNS server. Administrators should verify that their DNS host supports this behavior and test the formatting before deploying the record.

After publishing the DKIM TXT record, the sending mail server must be configured to use the corresponding private key to sign outgoing messages. This configuration varies by software. In Postfix, for example, the OpenDKIM milter is commonly used, and the configuration files must include the domain, selector, and path to the private key. In cloud-based platforms like Google Workspace, Microsoft 365, or SendGrid, the platform typically provides the DNS TXT value and handles signing internally once the record is verified.

Verification of the DKIM setup is a crucial step before considering the deployment complete. Tools such as Google’s Admin Toolbox, MXToolbox, DKIMCore, and various command-line utilities can perform DNS lookups on the DKIM selector and confirm whether the record is correctly published and readable. A test email sent to a Gmail account, for example, can be inspected by viewing the message headers and checking for a “DKIM=pass” result. If the DKIM signature fails, it is often due to mismatched keys, an incorrect selector, a malformed DNS record, or the absence of a valid signature in the message header.

Key management is also an important part of DKIM implementation. To maintain a secure and trustworthy setup, keys should be rotated periodically. This involves generating a new key pair, updating the mail server to sign messages with the new key, and publishing a new DNS record with a different selector. The old selector should be kept active in DNS until all messages signed with the old key have been processed and are no longer being verified. This transition ensures that mail delivery and authentication remain uninterrupted.

For domains that send email from multiple sources—such as internal systems, CRMs, marketing platforms, and helpdesk software—each source must have access to a valid DKIM key. This often involves creating multiple selectors, each corresponding to a different sending platform. It is essential to maintain documentation of which selector belongs to which system to avoid confusion during updates or decommissioning.

In addition to standalone use, DKIM should be integrated with SPF and DMARC to create a comprehensive email authentication strategy. DMARC relies on the results of DKIM and SPF checks to determine how to handle messages claiming to be from the domain. Publishing a DMARC policy requires consistent DKIM performance across all mail streams. If DKIM fails frequently due to incorrect DNS records or server-side misconfiguration, it can lead to deliverability problems when DMARC enforcement is applied.

Ultimately, creating a DKIM DNS record is not a one-time task but part of a broader lifecycle of managing email authentication. Careful attention to DNS syntax, secure key storage, and routine validation are essential to maintaining trust in the domain’s email. As phishing, spoofing, and email-based attacks continue to evolve, DKIM remains a critical defense mechanism that, when correctly implemented and maintained, significantly strengthens the security and reputation of outbound communications.

DomainKeys Identified Mail, or DKIM, is one of the most critical authentication mechanisms in modern email security. Its purpose is to verify that an email was sent from an authorized server and that its contents have not been altered in transit. DKIM works by applying a digital signature to the headers of an outgoing message.…