If your business uses Google Workspace, there’s a good chance your email is already signed with DKIM, just not with your domain. Out of the box, Google signs outgoing mail with a default key that belongs to a Google domain. Messages still go out, but that signature doesn’t line up with your From address, so it does nothing for DMARC and gives mailbox providers less reason to trust you.
Setting up your own DKIM key takes about 15 minutes of work plus some waiting for DNS. Here’s the whole process.
Why custom DKIM matters
DKIM adds a cryptographic signature to every message. Receiving servers look up a public key in your DNS and confirm the message really came from you and wasn’t altered on the way.
With your own key in place:
- DMARC can pass on DKIM alone, even when SPF breaks because a message was forwarded.
- You meet Gmail, Yahoo and Outlook.com’s sender requirements, which expect authenticated, aligned mail.
- Your domain builds its own reputation, separate from everyone else using Google’s default key.
What you need
- A Google Workspace super admin account.
- Access to your domain’s DNS settings (at your registrar, Cloudflare or wherever your DNS is hosted).
- If your Workspace account is brand new, give it a day or two. Google may not let you generate a key immediately after setup.
Step 1: Generate the DKIM key in the Admin console
- Sign in to the Google Admin console.
- Go to Apps → Google Workspace → Gmail → Authenticate email.
- Pick your domain from the drop-down. Each domain you send from needs its own key.
- Click Generate new record.
- Choose 2048 bits as the key length. Use 1024 only if your DNS host can’t store a longer record.
- Leave the prefix selector as google unless you already use that name. Then click Generate.
Google now shows two values: the DNS host name (google._domainkey) and a long TXT value starting with v=DKIM1; k=rsa; p=.
Step 2: Add the TXT record to your DNS
In your DNS provider, create a new record:
| Field | Value |
| Type | TXT |
| Name / Host | google._domainkey |
| Value | The full v=DKIM1; k=rsa; p=… string from Google |
| TTL | Default, or 3600 |
Two things catch people out here:
- Don’t add your domain to the name if your DNS host appends it automatically. Otherwise you create google._domainkey.example.com.example.com, which nobody will ever find.
- Long values. A 2048-bit key is longer than 255 characters, the limit for a single TXT string. Most modern DNS hosts split it for you. If yours complains, split the value into two quoted strings in the same record, or fall back to a 1024-bit key.
Step 3: Turn on signing
DNS changes are often visible within minutes, but can take up to 48 hours. Once the record is live, return to Authenticate email in the Admin console, select the domain and click Start authentication.
The status should change to say that email is being authenticated with DKIM. If you see an error, the record usually hasn’t propagated yet or the name is wrong. Wait an hour and try again before changing anything.
Step 4: Verify it’s working
Don’t trust the green status alone. Check from the outside in two ways.
Read a real message’s headers. Send an email from your Workspace account to a personal Gmail address. Open it, click the three-dot menu and choose Show original. Near the top you should see DKIM: ‘PASS’ with domain yourdomain.com. If it still shows a Google domain, signing hasn’t started.
Run a DKIM check on your DNS. An online dkim check looks up the public key at your selector, confirms it parses correctly and shows the key length. The same tool usually checks SPF and DMARC at once, which is useful because DKIM is only one part of the picture.
Troubleshooting
| Problem | Likely cause | Fix |
| “Start authentication” fails | Record not live yet, or wrong host name | Wait, then confirm the record exists at google._domainkey.yourdomain.com |
| DKIM check finds no key | Domain added twice to the name, or record on the wrong domain | Fix the host name field |
| Key looks cut off | DNS host truncated a long value | Split into two strings or use 1024 bits |
| Headers still show a Google domain | Signing not started, or mail sent from a different domain | Click Start authentication for that specific domain |
| DKIM passes but DMARC fails | Mail sent by another tool (CRM, newsletter) | Set up DKIM in that tool too |
Other senders need their own DKIM
Google’s key only signs mail that leaves through Gmail. Your newsletter platform, CRM, helpdesk and website each send separately and need DKIM set up in their own settings, usually with a CNAME or TXT record and a different selector. A DMARC report will show you any you’ve missed.
Rotate the key now and then
Good practice is to replace DKIM keys periodically, for example once a year. In Workspace, generate a new record with a different selector (say google2026), publish it, start authentication with it, and remove the old record a few days later once mail is signed with the new one.
Next step: DMARC
DKIM on its own proves messages are genuine, but it doesn’t tell receivers what to do with fakes. That’s DMARC’s job. With DKIM and SPF passing, publish a DMARC record at p=none, watch the reports and work towards enforcement. And because DNS records can quietly change during a migration or a provider switch, it’s worth monitoring them. A service such as FastPing alerts you when a DKIM key disappears, so a broken signature doesn’t go unnoticed for weeks.
