Guides

How to add a DKIM record at your DNS host

2 November 2026

To add a DKIM record, copy the record your email provider gives you into your DNS host as a new TXT or CNAME record. The name is the selector followed by ._domainkey, such as google._domainkey. Enter only that part in the Name field, because the host adds your domain for you. Then wait for the provider to see it and turn signing on. Most mistakes happen in that Name field.

This guide covers the DNS step: what to type, where, and how to check it worked. For what DKIM is and how each provider generates its keys, see how to set up DKIM. If you would rather have someone confirm the result, a $129 Snapshot reads the DKIM selectors your domain publishes and flags the ones that are missing or broken.

What you need before you start

TXT or CNAME: which one you get

A DKIM record holds a public key. Receiving servers look it up at selector._domainkey.yourdomain.com, the naming pattern set out in RFC 6376 section 3.6.2.1. Providers publish that key in one of two ways:

Do not convert one into the other. If the provider gives you a CNAME, a TXT record with the same name will not work, and the reverse is also true.

The Name field

Most DNS hosts want the name relative to your domain. GoDaddy’s help page on adding a TXT record describes the Name as the host name or prefix without the domain name. So for a Google key on example.com:

Type:  TXT
    Name:  google._domainkey
    Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...

If you type google._domainkey.example.com into a host that adds the domain itself, the record ends up at google._domainkey.example.com.example.com, and no receiver will find it. Google’s DKIM troubleshooting page says the same thing: do not add the domain again to the record name in your DNS settings.

A few hosts want the full name instead. If the form shows your domain as a suffix next to the box, or if existing records in the list show only the prefix, use the prefix. If existing records show the full name ending in a dot, follow that pattern.

Step by step at common hosts

GoDaddy

  1. Open your Domain Portfolio, select the domain, and open the DNS tab.
  2. Choose Add New Record and pick TXT or CNAME, whichever your provider gave you.
  3. Name: the selector part only, such as google._domainkey.
  4. Value: the key, or the CNAME target, exactly as given. GoDaddy’s TXT page says values can be up to 1,024 ASCII characters.
  5. Leave TTL at the default of one hour and save.

GoDaddy’s page on adding a CNAME record says changes usually apply within an hour but can take up to 48 hours.

Cloudflare

  1. Open the DNS Records page for the domain and choose Add record, as described in Cloudflare’s guide to creating DNS records.
  2. Pick the type, enter the selector part as the Name, and paste the value.
  3. For a CNAME, set proxy status to DNS only.
  4. Save.

Cloudflare’s docs note that proxy status is a choice you make on A, AAAA, and CNAME records. A proxied CNAME answers with Cloudflare’s own addresses instead of pointing to the provider’s record, so a mail server looking up the key does not reach it. DKIM CNAMEs should be DNS only.

Other hosts

The fields are the same everywhere: type, name, value, and TTL. Look for a DNS, Zone, or Advanced DNS page. If your website platform manages DNS for you, the setting is usually under Domains.

Long keys and the 255-character limit

A 2048-bit key is longer than 255 characters, and many DNS hosts limit each TXT string to 255. Google’s troubleshooting page says that if your host has this limit, you cannot enter a 2048-bit key as one string. Its advice:

The result looks like this:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
    "...rest of the key...IDAQAB"

This is safe because RFC 6376 section 3.6.2.2 says the strings in a TXT record must be joined with no space between them before use. Many hosts split long values for you, so try pasting the whole key first and check the result. If your host will not take a long value at all, Google says you can use a 1024-bit key instead, or ask the host whether it supports longer records. Google’s setup page recommends 2048-bit where the host supports it.

CNAME records do not have this problem. The long key lives at the provider.

Turn signing on, in the right order

Publishing the record does not start DKIM by itself. The provider has to start signing, and most will not let you until they can see the record.

Check that it published

From a terminal, ask DNS directly. For a TXT key:

dig TXT google._domainkey.example.com +short

You should see the v=DKIM1 value, possibly as several quoted strings. For a CNAME:

dig CNAME selector1._domainkey.example.com +short

You should see the provider’s target. Google’s troubleshooting page suggests its Admin Toolbox Dig tool if you do not have a terminal, and reminds you to add a period and your domain to the selector when you look it up there.

Then send a message to a Gmail address you control, open it, and choose Show original. The DKIM line should say PASS, and the signing domain should be your domain, not the provider’s.

Common mistakes

Next: DMARC

DKIM on your own domain is what lets most third-party mail pass DMARC, since SPF often checks the provider’s domain instead of yours. Once DKIM passes for every tool that sends as you, publish a DMARC record and read the reports. Our guide to why DMARC fails explains alignment if the reports show failures anyway.

Sources