How to set up DKIM

DKIM is the part of email authentication that proves a message genuinely came from your domain and was not altered on the way. It works by signing each outgoing message with a private key that only your sending system holds, and publishing the matching public key in your DNS as a TXT record. Receivers read that public key, verify the signature, and know the mail is authentic. DKIM is also the most reliable way to pass DMARC alignment, because unlike SPF it survives forwarding. This guide shows you the exact record to publish, where to add it at every major DNS provider, and the mistakes that trip people up.

What a DKIM record is, and the part that confuses everyone

A DKIM record is a public key, published as a DNS TXT record, that lives at a host built from a selector. The format is always <selector>._domainkey.yourcompany.com. The selector is a label you choose, or more often one your email provider chooses for you, and it lets a single domain carry several DKIM keys at once without them clashing. Your newsletter platform might sign with selector s1, Google Workspace with google, and a transactional provider with smtp, each publishing its own key at its own host. That is the whole reason selectors exist: one domain, many independent signers, no collisions.

The value itself names the key type and carries the key. Defined in RFC 6376, a typical record looks like this:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvz8...your...long...base64...public...key...goes...here...IDAQAB

The v=DKIM1 tag is the version. k=rsa declares the key algorithm. p= holds the public key as a long Base64 string. That string is the part people stumble over, because for a 2048-bit RSA key it is long enough that DNS may force you to split it, which we cover below.

The record to publish

DKIM comes in two shapes depending on your provider, and you need to know which one you have before you start. Some providers hand you a full TXT value to paste. Others, including Google, Microsoft and many transactional senders, hand you a CNAME that points at a record they host, so they can rotate the key for you without you touching DNS again. Both are valid. Publish whichever your provider gives you, exactly as given.

If your provider gives you a TXT value

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvz8...IDAQAB

If your provider gives you a CNAME

selector1._domainkey.yourcompany.com  CNAME  selector1.dkim.provider.example

Providers such as SendGrid, Amazon SES, Mailchimp and others commonly ask for two or three CNAMEs (for example s1._domainkey and s2._domainkey). Add every one of them. If you only add some, signing rotates between keys and a portion of your mail will fail DKIM. Our DKIM record generator will build a clean TXT key pair for self-hosted signing, and the DKIM checker confirms a published record resolves and parses correctly.

Key size, and whether to use ed25519

Two key-size choices matter. The first is RSA length. A 2048-bit RSA key is the current standard and what you should publish wherever you can; 1024-bit is weaker and considered legacy, though some older platforms still default to it. If your provider offers a choice, choose 2048. The only practical cost is that a 2048-bit public key is long enough that some DNS interfaces will not accept it as a single unbroken string, which leads to the splitting step below.

The second choice is the algorithm. Alongside RSA, RFC 8463 added ed25519, an elliptic-curve signature that is far shorter and just as strong. An ed25519 record uses k=ed25519 and a short p= value that never needs splitting. The catch is support: not every receiver verifies ed25519 yet, so the usual advice is to publish ed25519 and a 2048-bit RSA key on separate selectors, letting receivers use whichever they understand. If that sounds like a lot to manage by hand, it is exactly the kind of thing our hosted DKIM handles for you, keys, selectors, rotation and all.

Splitting a long key into 255-character strings

A single TXT character string cannot exceed 255 characters, which a 2048-bit DKIM key comfortably overruns. The DNS standard allows a TXT record to hold several quoted strings back to back, and resolvers concatenate them into one value. So a long key is published as multiple quoted chunks:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvz8FzZ...first255chars..."
"...second chunk of the Base64 key continues here without any extra spaces...IDAQAB"

The split must fall inside the Base64 string, never adding spaces or characters of its own; the resolver simply joins the pieces. Most modern DNS dashboards (Cloudflare, Route 53, GoDaddy) handle long values for you and you can paste the whole key as one line. Some BIND-style or registrar text editors require manual chunking. If you have to split by hand, our DNS record splitter chops the key into correctly sized 255-character strings so the joined result is byte-for-byte identical to the original.

Where to add it: Cloudflare

Open the Cloudflare dashboard, select your domain, and go to DNS > Records. Click Add record. For a TXT key, set Type to TXT, set Name to your selector host, for example s1._domainkey, and paste the full value into Content. For a provider CNAME, set Type to CNAME, Name to the selector host, and the target into Target. Cloudflare appends your domain automatically, so enter the host as s1._domainkey, not s1._domainkey.yourcompany.com. Leave Proxy status off (DNS only) for the CNAME, set TTL to Auto, and save. Cloudflare accepts long TXT values without manual splitting.

Where to add it: GoDaddy

From your GoDaddy account open My Products, find the domain and choose DNS or Manage DNS. Under Records click Add. Pick TXT or CNAME to match what your provider gave you. In Name enter just s1._domainkey; GoDaddy adds the domain for you, so do not type the full hostname. Paste the value into Value (TXT) or the target into Points to (CNAME), set TTL to one hour, and save. GoDaddy handles long TXT values, but it is sensitive to a trailing dot, so do not add one to the CNAME target unless your provider explicitly included it.

Where to add it: Namecheap

Sign in, go to Domain List, click Manage next to the domain, then open the Advanced DNS tab. Under Host Records click Add New Record. Choose TXT Record or CNAME Record. In Host enter s1._domainkey only; Namecheap appends the domain, so the full hostname here is a common cause of a record that never resolves. Put the key in Value, or the provider hostname in the CNAME target, set TTL to Automatic, and click the green tick to save. Namecheap accepts long TXT values in a single field.

Where to add it: Amazon Route 53

In the AWS console open Route 53 > Hosted zones and select your domain's zone. Click Create record. Set the Record name to s1._domainkey (Route 53 shows your domain as a fixed suffix beside the field, so enter only the prefix). Choose TXT or CNAME as the record type. For TXT, paste the value wrapped in double quotes; if it is a long 2048-bit key you may need to enter it as two quoted strings on separate lines in the value box, which Route 53 stores as one record. For CNAME, enter the provider hostname as the value. Set TTL to 3600 and create the record.

Where to add it: Google Domains / Squarespace

Google Domains registrations were migrated to Squarespace Domains, so the path lives there now. Open the Squarespace dashboard, go to Domains, select the domain, and open DNS Settings (or DNS). Under custom records click Add record. Choose TXT or CNAME. In the Host field enter s1._domainkey only, without the domain; the interface appends it. Paste the key into Data (TXT) or the provider hostname into the CNAME target, leave TTL at the default, and save. If you use @ elsewhere for the root, note that DKIM is never at the root, it is always under the selector host.

Where to add it: Microsoft 365 / Outlook DNS

There are two cases here. If Microsoft is your email provider, you enable DKIM in the Microsoft 365 Defender portal under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Microsoft will show you two CNAMEs to publish, typically selector1._domainkey and selector2._domainkey, each pointing at an onmicrosoft.com target. Add both at whichever DNS host actually manages your domain, then return to the portal and toggle DKIM on.

If your DNS itself is hosted in Microsoft, open the Microsoft 365 admin centre > Settings > Domains, select the domain, and use DNS records > Add record. Choose the record type, enter the host as selector1._domainkey without the domain suffix, and paste the value or CNAME target. Publish both Microsoft selectors, or signing will rotate to a key you have not published and that mail will fail DKIM.

Common mistakes and gotchas specific to DKIM

DKIM fails quietly. A broken SPF record throws obvious errors; a broken DKIM key just silently fails to verify, and you only notice in your DMARC reports. These are the recurring culprits.

• The doubled domain suffix. Covered above, and worth repeating because it is the single most common DKIM error: enter the selector host without your domain on the end.
• Publishing only one of several keys. CNAME-based providers often need two or three records. Sending systems rotate selectors, so a missing second key means a clean-looking pass rate that mysteriously dips. Add every record the provider lists.
• Smart quotes and stray spaces. Pasting a key through a word processor can replace plain " with curly quotes, or add a space at a line break. The key then parses as invalid. Paste into a plain editor first, or use our tools, which never alter the bytes.
• Botched splitting. When a long key is chunked by hand, a character dropped at the boundary or an accidental space inside the join corrupts it. Let the record splitter do it.
• Wrong record type. Publishing a CNAME provider's target as a TXT value, or vice versa, never resolves. Match exactly what the provider issued.
• Editing a managed CNAME. If your provider gave you a CNAME so it can rotate keys, do not replace it with a static TXT copy of the current key. When the provider rotates, your frozen copy goes stale and mail starts failing. Leave the CNAME pointing at them.
• Expecting alignment automatically. A valid DKIM signature is not enough on its own for DMARC; the signing domain (d=) must align with the visible From domain. For mail sent through a third party, that usually means setting up a custom signing domain inside the platform. See how to reach enforcement for how DKIM alignment fits the wider picture.
• Forgetting it is one of three. DKIM sits alongside SPF and DMARC. Publishing DKIM alone does not stop spoofing; it is the building block that DMARC relies on. Review the full authentication requirements and the complete toolset to check the rest.

Get the selector host right, publish every key your provider lists, keep the Base64 value byte-perfect, and confirm the signing domain aligns with your From address. Do those four things and DKIM will quietly pass on every message, which is precisely what it is supposed to do.