Defaults.Exposed

Defaults.Exposed › Setup walkthroughs › DKIM › GoDaddy

How to set up DKIM on GoDaddy

The GoDaddy account has no DKIM (DomainKeys Identified Mail) switch. GoDaddy publishes DKIM records and does not generate them, unless GoDaddy is also selling you the mailboxes. The key comes from whoever runs your email, and GoDaddy’s job starts when you have it in your hand.

Why there is no DKIM button here

Signing mail and publishing a key are two different jobs owned by two different systems. The mail platform generates a key pair inside its own console, keeps the private half, and signs every outgoing message with it. What it hands you is the public half plus a short name called a selector. A receiving server reads the selector out of the message’s DKIM-Signature header, looks up <selector>._domainkey.yourdomain.com, and checks the signature against whatever key it finds there.

That lookup goes to your nameservers, which is why the record lands in GoDaddy rather than in the mail platform. Receivers do not ask your mail platform for the key and they do not ask your registrar unless the registrar also runs the zone. A DKIM button in GoDaddy would have nothing to generate, because GoDaddy has no access to the private key that does the signing. The DKIM guide covers what the receiver does with the result; this page covers getting the record published correctly.

GoDaddy is worth being precise about because it does several jobs at once. It sells domains, it runs DNS (Domain Name System) for a large share of them, and it resells mailboxes, including Microsoft 365 tenants. Plenty of GoDaddy customers buy all three in the same basket and then reasonably assume one console covers everything. It does not. Whichever mail product you bought, the key comes out of that product’s admin area, and only then does the GoDaddy DNS screen matter.

What you are about to paste

Most platforms give you a TXT (Text) record whose value starts v=DKIM1; k=rsa; p= and then runs to hundreds of characters of base64 with no spaces in it. The p= tag carries the key and is the part receivers insist on. If the platform offers you a choice of key length, take the 2048-bit option; that is what platforms now issue by default and receivers accept it. If the value arrives carrying t=y, that marks the key as being in test mode, and a receiver treats a failed signature as though the message carried none. Take t=y out once mail is flowing properly, so a failure counts as a failure.

Some platforms give you a CNAME (Canonical Name) instead, and Microsoft 365 is the one GoDaddy customers meet most often. The name is still <selector>._domainkey, but the value is a hostname on the platform’s own servers that holds the key, which lets the platform rotate keys without you opening GoDaddy again. Publish a CNAME where you were given a CNAME. Turning the target hostname into a TXT record publishes a hostname where a receiver expects a key, and nothing in the GoDaddy console will warn you.

Whatever the type, the selector has to match letter for letter. A receiver builds its lookup from the s= tag the platform signs with, so selector1 and selector2 are two different keys, and so are mail and mail1. Copy the name from the platform’s page rather than typing it from memory.

Confirm GoDaddy is the one answering

A record saved in a console your domain does not delegate to is invisible to receivers, whatever that console tells you afterwards. Open the domain in your GoDaddy account and look at the Nameservers section. If it shows another company’s nameservers, a web host’s, Cloudflare’s or the email provider’s own, the DKIM record belongs at that company and adding it here changes nothing.

This trips people up because owning a domain at GoDaddy and having GoDaddy answer DNS for it are separate arrangements, and a site build or a migration years ago may have moved the second one without anybody noting it. GoDaddy’s nameservers answer for 53,313,849 domains in the October 2026 census, 16.33% of the domains that have nameservers at all. The Nameservers section shows whether yours is one of them.

Add the record in GoDaddy

Copy both pieces from the platform’s DKIM or email authentication page and keep that tab open until the check at the end passes. Laid out the way GoDaddy expects it, the record looks like this:

selector1._domainkey
selector2._domainkey
google._domainkey
selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector1-yourdomain-com._domainkey.yourtenant.n-v1.dkim.mail.microsoft
v=DKIM1; ...

Microsoft 365 targets come in two formats. Domains added to Microsoft 365 before May 2025 point at onmicrosoft.com; domains added since point at dkim.mail.microsoft, with a short partition code such as n-v1 or r-v1 that Microsoft assigns. Paste whichever target Microsoft shows for your domain.

The Name field, also shown as Host, takes only the selector part the provider supplied, such as selector1._domainkey, selector2._domainkey or google._domainkey, because GoDaddy appends the domain itself. The Value field takes the target hostname the provider gave for a CNAME record, or the full key string starting v=DKIM1; for a TXT record, pasted without surrounding quotes since GoDaddy handles the quoting. The Type field must match whatever the provider specified, usually CNAME, sometimes TXT, and TTL (Time to Live) stays at its default.

  1. Sign in to GoDaddy and open the domain’s DNS settings, labelled DNS, Manage DNS, or DNS / Records.
  2. Select Add or Add New Record to start a new entry.
  3. Choose the record type the email provider specified, usually CNAME, sometimes TXT.
  4. In the Name field, also labelled Host, enter only the selector part exactly as the provider gave it, such as selector1._domainkey or google._domainkey.
  5. Do not add the domain on the end of the Name field, because GoDaddy appends the domain automatically.
  6. In the Value field, paste the target the provider gave: a target hostname for a CNAME record, or the full key string for a TXT record.
  7. Leave the TTL field at its default setting.
  8. Save the record, then repeat the same steps for every DKIM record the provider listed.
  9. Return to the email provider’s own console and use its verify or enable DKIM control to confirm it can see the published records.

Before you save, compare the last few characters of the pasted value with the platform’s page, because a copy that stops early publishes a key that will never verify, and the console will not warn you. Check the selector in the name against the platform’s page in the same pass.

The same DNS screen holds your SPF record, which most platforms ask you to set up in the same sitting. That one is a separate TXT row at Name @, so keep the two apart and do not paste either value into the other’s row.

Traps specific to GoDaddy

Save, wait, then check

A saved record can take from minutes up to a couple of hours to spread, after which it sits alongside the domain’s other rows in the GoDaddy DNS screen. A check run in the first few minutes can read as absent while nothing is wrong, so give it some time before you conclude anything.

Once the record shows in the console, run the free scan against your domain. It asks DNS for the selector the way a receiving server does and tells you in plain words whether the key is published and readable.

How the scan grades this record: the DKIM check, with its pass and fail rules and how many domains pass it.

Then check from the mail side. Send a message from the domain to a mailbox you control and open the Authentication-Results header. dkim=pass with your domain in header.d= means the signature verified against the key you published. dkim=fail or dkim=none with the record sitting in the console points at the selector or at the platform, and the next section says where to look.

When the scan comes back empty

Without a record at the selector, the receiver gets no key and the message carries no verified signature. It will not bounce on that alone, though DMARC (Domain-based Message Authentication, Reporting and Conformance) then has only SPF (Sender Policy Framework) to lean on, and SPF breaks on forwarding, so a forwarded message arrives with neither.

A malformed record fails the same way: a p= value cut short, a stray space or line break in the middle, a doubled host such as mail._domainkey.yourdomain.com.yourdomain.com, or a selector that is off by one character. The receiver logs dkim=fail or dkim=permerror and moves on, and you hear nothing about it unless DMARC reports are arriving. The DMARC piece shows how those reports expose a DKIM failure per sending source.

There is no way to list the DKIM records on a domain, so any checker has to ask for selectors by name and can only ask for the ones it knows to try. A key under a selector the checker doesn’t try is invisible to it, so this scan records that case as not determinable, never as absent. The census has the same limit: of the 76,563,365 domains where it could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%).

If your scan reports nothing found while the record sits in the GoDaddy console, finding your DKIM selector shows how to read the live selector out of a sent message’s headers before you change anything.

Work a failure in this order: the selector spelling, then the nameservers, then the tail of the pasted value, then whether the platform still needs you to switch signing on.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.