The short answer is that DomainKeys Identified Mail (DKIM) uses a TXT (Text) record. When you set up DKIM for your domain, you're essentially creating a specific type of TXT record in your DNS (Domain Name System) that holds your public key. This allows receiving mail servers to verify that an email was actually sent by you and that it wasn't altered in transit.
Hostinger's tutorial on the subject puts it clearly: the DKIM record is a DNS TXT entry that contains the public key. While this is the direct answer, there's a little more nuance to it, particularly with how some providers use CNAME records to make managing DKIM easier.
The structure of a DKIM record
A DKIM record isn't just any TXT record. It has a specific format and lives at a specific location within your DNS. The location, or 'name', of the record typically looks like this: selector._domainkey.yourdomain.com. The 'selector' is a unique name you or your email service provider (ESP) chooses. It allows for multiple DKIM keys on the same domain, which is useful for when you send email from different services.
As Rackspace explains, this selector is specified in the DKIM-Signature header of every email you send, telling the receiving server exactly where to look for the public key.
The actual content of the TXT record, the 'value', contains several important tags:
- v=DKIM1: This specifies the version of DKIM being used. It's almost always "DKIM1".
- k=rsa: This defines the key type, which is typically RSA (Rivest-Shamir-Adleman), a common public-key cryptosystem.
- p=This is the most critical part. The 'p' tag contains the public key data itself, encoded in base64. This is the key that receiving servers use to verify your email's signature.
Why use a TXT record for DKIM?
The DNS was originally designed for simple mappings, like an A record pointing a domain name to an IP address. The TXT record type was created to hold descriptive, human-readable text. Over time, its flexibility has made it the standard for embedding machine-readable data for protocols that came after the original DNS specification.
Because a DKIM public key is essentially a long string of text, the TXT record is the perfect vehicle for publishing it. It's the same reason other critical email authentication standards like SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting & Conformance) also use TXT records.
The role of CNAME records in DKIM
While the DKIM information itself is always stored in a TXT record, you might be asked by your email provider to create a CNAME record instead. This can seem confusing, but it's a clever way to simplify DKIM management.
A CNAME (Canonical Name) record is essentially an alias. When a DNS resolver looks for a record at a name that has a CNAME, it is redirected to look for the record at the alias instead. In the context of DKIM, you might create a CNAME record like this:
- Name: selector._domainkey.yourdomain.com
- Type: CNAME
- Value: selector.dkim.emailprovider.com
Your email provider then manages the actual TXT record at selector.dkim.emailprovider.com. This allows them to update, or 'rotate', your DKIM key on your behalf without you ever needing to log in to your DNS provider and change the public key manually. It's a common and highly recommended practice when offered by your ESP.
So, to recap, DKIM data is always stored in a TXT record. However, that TXT record is sometimes accessed indirectly via a CNAME record to make life easier for everyone.
