secureserver1._domainkey — what this GoDaddy DKIM record is
secureserver1._domainkey is the first of the two DKIM selectors GoDaddy uses for Professional Email (the mailbox product "powered by Titan"). It's a CNAME record, paired with secureserver2._domainkey, and each one points at a target GoDaddy shows you in the Email & Office Dashboard. Their job is to let receiving servers find the public key that verifies the signature on your emails. If you use GoDaddy Professional Email, keep them exactly as they are. If your email is with someone else — Microsoft 365, Google Workspace, anything — these records are harmless but they don't sign anything for you: you need that provider's DKIM records instead.
Nothing here is a secret or a threat. Seeing secureserver1._domainkey in your DNS zone means either GoDaddy added it for you (domains bought after April 2025 get DKIM set up automatically for Professional Email) or someone followed GoDaddy's setup article.
Where it comes from, and what it points to
GoDaddy's own setup article for Professional Email lists three things to publish: an SPF TXT record, two DKIM CNAME records, and a DMARC TXT record.
| Record | Type | Name | Value |
|---|---|---|---|
| SPF | TXT | @ |
v=spf1 include:secureserver.net -all |
| DKIM 1 | CNAME | secureserver1._domainkey |
the target shown in your Email & Office Dashboard |
| DKIM 2 | CNAME | secureserver2._domainkey |
the second target shown there |
| DMARC | TXT | _dmarc |
the value shown in the dashboard — or your own, see below |
The CNAME targets are specific to your account: they are not something a tutorial can hand you. You copy them from the dashboard, and if your domain's DNS is at GoDaddy with the email in the same account, GoDaddy fills them in itself. Two selectors exist so GoDaddy can rotate the signing key without a gap.
The include:secureserver.net in the SPF record is the companion piece: it authorises GoDaddy's outgoing mail servers. GoDaddy states that if your domain, DNS and email are in the same GoDaddy account, it adds this SPF record for you.
How to check it actually works
A CNAME that exists is not a CNAME that resolves. Two checks, a minute each:
- Look up the CNAME.
secureserver1._domainkey.yourdomain.comshould answer with a CNAME to a GoDaddy-controlled hostname, and looking up the TXT at that hostname should return a record starting withv=DKIM1. Any public DNS lookup tool shows both. - Send yourself a message from your Professional Email mailbox to a Gmail address, open Show original, and look for
dkim=passwithheader.d=equal to your domain. That's the whole point of the record.
If the lookup fails, the usual cause is a name typed as the full hostname (secureserver1._domainkey.yourdomain.com) in a DNS panel that wanted only the prefix — GoDaddy's own field wants secureserver1._domainkey, nothing more.
If your DNS isn't at GoDaddy
GoDaddy can only write into a zone it hosts. If your name servers are at Cloudflare, Namecheap, Route 53 or your web agency, GoDaddy's article says it plainly: "If your domain is not with GoDaddy, you'll need to update your records with your DNS provider." Create the two CNAMEs there, with the exact targets from the dashboard, plus the SPF and DMARC TXT records.
If you moved your email away from GoDaddy
Say you switched to Microsoft 365 or Google Workspace and the secureserver1._domainkey record is still there. It won't hurt: a DKIM selector nobody signs with is just an unused pointer. But it won't help either — your new provider signs with its own selectors (selector1/selector2._domainkey for Microsoft 365, google._domainkey for Google Workspace), and those are the records that need to exist. Two things to review at the same time:
- SPF. If nothing still sends through GoDaddy,
include:secureserver.netis dead weight; replace it with your new provider's include. If some emails (a website contact form, an old mailbox) still go through GoDaddy, keep both includes in the same SPF line. - DMARC. New GoDaddy domains since April 2025 get an automatic DMARC record:
v=DMARC1; p=quarantine; adkim=r; aspf=r; rua=mailto:dmarc_rua@onsecureserver.net;. Two things to know: it starts atp=quarantine— fine if everything is authenticated, not so fine if your new provider's DKIM isn't in place yet — and it sends the reports to GoDaddy, not to you. Put your own address inrua=(DMARC allows several, comma-separated) so you can read what receivers see.
Frequently asked questions
Can I delete secureserver1._domainkey?
If you still send email through GoDaddy Professional Email: no — deleting it removes your DKIM signature and your messages fail DMARC. If you have moved all sending elsewhere: yes, it's safe, but it's also harmless to leave; make sure your current provider's DKIM records exist before you tidy up.
Is secureserver1._domainkey a TXT or a CNAME record?
A CNAME. GoDaddy's setup article says "Select CNAME" and has you paste the target from the Email & Office Dashboard. The actual public key (v=DKIM1; …) lives at that target, on GoDaddy's side, which is what lets GoDaddy rotate it without touching your zone.
Do I need both secureserver1 and secureserver2?
Yes. GoDaddy's setup article lists the two, and the second selector is what a key rotation switches to: while one is in use, the other is ready to take over. Add both, exactly as shown in the dashboard, so a rotation never leaves your messages unsigned.