DKIM Record Example: Working Templates You Can Copy and Use Today

DKIM Record Example: Working Templates You Can Copy and Use Today

Slug: /information-security-guides/dkim-record-example/

H1 (on-page title): DKIM Record Example: Working Templates You Can Copy and Use Today

Meta title (57 chars): DKIM Record Example: Working Templates for Every Provider

Meta description (146 chars): Real DKIM record examples you can copy and adapt, covering Google Workspace, Microsoft 365, Mailchimp, SendGrid, HubSpot, and more, with breakdowns.

Focus keyphrase: DKIM record example

Excerpt (1-3 sentences for archive/listing): Sometimes the fastest way to understand DKIM is to see a working record next to an explanation of each part. This guide gives you real DKIM record examples for every common setup, from Google Workspace and Microsoft 365 to Mailchimp, SendGrid, HubSpot, and a self-hosted signer. Each example includes a full tag breakdown, a note on CNAME versus TXT publishing, and a copy-paste template you can adapt.

Suggested featured image alt text: "DKIM record example templates on a DNS console screen, iO™ information security guide"

DKIM records look intimidating until you have seen a few. Then the pattern becomes obvious, and you realize most of what your email provider generated for you is boilerplate with one very long string in the middle.

This guide walks you through real DKIM record examples for every common setup, from the simplest single-provider configuration to a multi-vendor enterprise stack with key rotation in flight. Each example includes a full breakdown of what every tag does, and a note on whether the provider wants you to publish a TXT or a CNAME (because both are common and people mix them up all the time).

Use these as starting points. Adapt them to your own sending stack. Verify with our DKIM Checker before you consider the deployment complete. Then move on.

Let's get into it.

Key Takeaways

• DKIM records live at a very specific hostname: <selector>._domainkey.<yourdomain>. Get the selector right and the rest is mechanical.

• Most hosted providers use CNAME delegation, not raw TXT records. That lets the provider rotate keys on your behalf without you touching DNS again. Microsoft 365, Mailchimp, SendGrid, HubSpot, and Amazon SES all do this.

• Self-hosted signers and Google Workspace use raw TXT records with the full public key embedded. Longer, uglier, but fully under your control.

• 2048-bit RSA with SHA-256 is the current standard. Anything 1024-bit is either deprecated or about to be. Upgrade during your next rotation.

• Publish a key per sending service. Every provider that sends on your behalf needs its own selector and its own record. There is no single "DKIM record for your domain" the way there is with SPF.

• Always verify with a checker before you trust it. A record that looks right in DNS can still fail verification because of a split-string issue, a CNAME typo, or a stale key. Our DKIM Checker catches those in one query.

Table of Contents

1. Anatomy of a DKIM Record

2. Example 1: Google Workspace (TXT)

3. Example 2: Microsoft 365 (CNAME)

4. Example 3: Mailchimp and Mandrill (CNAME)

5. Example 4: SendGrid (CNAME)

6. Example 5: HubSpot (CNAME)

7. Example 6: Amazon SES (CNAME)

8. Example 7: Self-Hosted Signer (TXT)

9. Example 8: Multi-Provider Setup with Distinct Selectors

10. Example 9: Key Rotation Overlap (Two Keys Live)

11. Example 10: Revoked Key (Empty p=)

12. DKIM Tag Reference Table

13. What a Bad DKIM Record Looks Like

14. Copy-Paste Templates

15. FAQ

Anatomy of a DKIM Record

A DKIM record is a DNS record (usually TXT, sometimes CNAME) published at a very specific location, with a specific set of tags inside it. The location and the tags are where everyone gets confused, so let's break down each piece.

The hostname (where the record lives):

<selector>._domainkey.<yourdomain>

So if your selector is google and your domain is yourdomain.com, the record is published at google._domainkey.yourdomain.com. The _domainkey label is required by the DKIM spec. The selector is whatever short label you chose (or your provider assigned).

The value (a TXT record):

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...longBase64string...IDAQAB

Three tags minimum, plus more optional ones. The most common tags you will see are:

• v=DKIM1 identifies the record as DKIM version 1 (always include it)

• k=rsa identifies the key algorithm as RSA (the default, almost always RSA)

• p=<base64 public key> is the actual public key, Base64-encoded, and can be very long (around 400 characters for a 2048-bit key)

• t=y (optional) flags the record as test mode, receivers should treat it accordingly

• t=s (optional) enforces strict alignment, subdomains cannot use this key

• s=email (optional) restricts this key to email use only

• h=sha256 (optional) restricts the allowed hash algorithm

• n= (optional) a free-text notes field

The value (a CNAME record, for hosted providers):

<selector>._domainkey.<yourdomain>  CNAME  <provider-managed-hostname>

No public key, no tags, just a pointer. The provider publishes the real DKIM record on their side and rotates it as needed. Your job is just to publish the CNAME and forget about it. This is why CNAME delegation is so popular with SaaS providers.

Suggested image: labeled diagram of a DKIM TXT record with v, k, and p tags highlighted, alt text "DKIM record syntax breakdown showing version, key type, and public key tags"

Now let's look at real records.

Example 1: Google Workspace (TXT)

Google Workspace generates a DKIM public key in its admin console and expects you to publish it as a TXT record. Typical setup:

Hostname:

google._domainkey.yourdomain.com

Record type: TXT

Value:

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyQvK+7Hh... (long Base64 string continues for hundreds of characters) ...IDAQAB

What each part is doing:

• Hostname starts with google, which is Google's default selector label (you can rename it in the admin console if you want, but most people leave it)

• v=DKIM1 declares this as a DKIM v1 record

• k=rsa says the key is RSA (Google generates 2048-bit RSA by default as of 2023)

• p=<key> carries the actual public key

When to use it: Any Google Workspace tenant. This is the default DKIM setup for anyone sending through Google.

Gotcha to watch for: Google's admin console gives you the raw value in one long string. Your DNS provider should handle the 255-character split automatically. If it does not, see Example 7 for how to split manually.

Verify with: iO™ DKIM Checker against google._domainkey.yourdomain.com.

Example 2: Microsoft 365 (CNAME)

Microsoft 365 uses CNAME delegation, which is one of the nicest DKIM setups because it means Microsoft rotates the keys for you and you never touch DNS again after the initial publish.

Two CNAME records are published, one per selector:

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Record type: CNAME (for both)

What each part is doing:

• Microsoft creates two selectors (selector1 and selector2) so it can rotate between them without a gap

• The target hostname includes your tenant's .onmicrosoft.com domain, with your apex domain embedded in the target name

• When receivers query selector1._domainkey.yourdomain.com, DNS follows the CNAME to Microsoft's record, which contains the actual public key

When to use it: Every Microsoft 365 tenant that sends mail from a custom domain. You must also enable DKIM in the Microsoft 365 Defender portal under "Email authentication settings," otherwise the CNAMEs alone are not enough.

Gotcha to watch for: The target hostname must match your exact tenant name. If your tenant is fabrikam.onmicrosoft.comand your custom domain is fabrikam.com, Microsoft generates the correct target for you. Copy and paste, do not type manually.

Verify with: Our DKIM Checker against both selectors. You should see the CNAME resolve and the published key come back.

Example 3: Mailchimp and Mandrill (CNAME)

Mailchimp (and Mandrill, which is Mailchimp's transactional product) uses CNAME delegation with a fixed selector name.

Single CNAME:

k1._domainkey.yourdomain.com  CNAME  dkim.mcsv.net

Record type: CNAME

What each part is doing:

• The selector k1 is fixed (Mailchimp does not let you customize it)

• The CNAME target is dkim.mcsv.net, which is Mailchimp's infrastructure DKIM record

When to use it: Any Mailchimp or Mandrill account sending from your domain. You publish this CNAME plus complete the "Authenticate your domain" flow in Mailchimp's settings.

Pair with SPF: Mailchimp also needs include:servers.mcsv.net in your SPF record, as covered in the SPF Record Exampleguide.

Verify with: Send a campaign test, inspect headers, confirm dkim=pass with header.d=yourdomain.com. If the signature shows header.d=mcsv.net instead, you have not completed the domain authentication and the signature is not aligned with your From domain. That matters for DMARC. For the alignment nuance, see our DKIM Signature Fix guide.

Example 4: SendGrid (CNAME)

SendGrid uses two CNAMEs so it can rotate keys without interruption.

Two CNAMEs, with a subuser-specific ID in the target:

s1._domainkey.yourdomain.com  CNAME  s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.yourdomain.com  CNAME  s2.domainkey.u12345.wl.sendgrid.net

Record type: CNAME (for both)

What each part is doing:

• s1 and s2 are the two selectors SendGrid uses for rotation

• The target hostname contains u12345, which is SendGrid's internal user ID for your subuser (your actual ID will be different)

• SendGrid manages the actual keys at their end

When to use it: Any SendGrid account sending from a custom domain. You publish the two CNAMEs plus also the link-branding CNAMEs SendGrid generates (for tracked link rewrites).

Gotcha to watch for: SendGrid sometimes asks you to publish CNAMEs under a subdomain like em1234.yourdomain.cominstead of the apex. If that is the case, your DMARC alignment may need adjusting (DMARC supports relaxed alignment, which tolerates subdomain mismatches). See What is SPF Email, DKIM, and DMARC? for the full alignment explanation.

Verify with: Our DKIM Checker against both s1 and s2 selectors.

Example 5: HubSpot (CNAME)

HubSpot also uses CNAME delegation, with a selector that encodes your HubSpot portal ID.

Single CNAME:

hs1-12345678._domainkey.yourdomain.com  CNAME  hs1-12345678.hubspotemail.net

Record type: CNAME

What each part is doing:

• The selector hs1-12345678 is specific to your HubSpot portal (the number is your portal ID)

• The CNAME target resolves to HubSpot's managed DKIM record

• HubSpot rotates keys on their end, so you never need to touch this again

When to use it: Every HubSpot portal that sends email from your custom domain. You enable "Connect your email sending domain" in HubSpot settings, which generates the CNAME values to publish.

Pair with SPF: Include include:_spf.hubspot.com in your SPF record so SPF alignment can also pass.

Verify with: Send a test email from HubSpot, inspect headers at the receiver, confirm dkim=pass with header.d=yourdomain.com.

Example 6: Amazon SES (CNAME)

Amazon SES uses a three-CNAME setup called "Easy DKIM" that lets SES rotate keys across three selectors.

Three CNAMEs:

abc123def456._domainkey.yourdomain.com  CNAME  abc123def456.dkim.amazonses.com
ghi789jkl012._domainkey.yourdomain.com  CNAME  ghi789jkl012.dkim.amazonses.com
mno345pqr678._domainkey.yourdomain.com  CNAME  mno345pqr678.dkim.amazonses.com

Record type: CNAME (for all three)

What each part is doing:

• Each of the three selectors is a random token generated when you enable Easy DKIM in the SES console

• The CNAME target resolves to the corresponding record in dkim.amazonses.com

• SES uses the three slots for rotation

When to use it: Any SES-based sending setup, including SES direct, SES-backed services, and most AWS-hosted mailer apps. The three selectors are required, not optional.

Gotcha to watch for: SES will not mark your identity as verified until all three CNAMEs are resolvable. If you see your SES identity stuck in "pending verification" for more than 72 hours, one of the three is wrong or not yet propagated. Query each one directly to find the broken one.

Verify with: Our DKIM Checker, or dig CNAME <selector>._domainkey.yourdomain.com +short for each of the three.

Example 7: Self-Hosted Signer (TXT)

If you run your own mail server with OpenDKIM, Exim, Postfix, or a similar stack, you generate the key pair yourself and publish the public key as a TXT record.

Generate the key:

openssl genrsa -out dkim-private.key 2048
openssl rsa -in dkim-private.key -pubout -outform DER 2>/dev/null | openssl base64 -A

The second command outputs the Base64 public key that goes into your DNS record.

DNS record:

Hostname:

mail2026._domainkey.yourdomain.com

Record type: TXT

Value (split across strings to stay under the 255-character per-string limit):

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxx" "yyyyyyyyyyyyyyyyyyyyyyyyyyyy" "zzzzzzzzzzzzzzzzzzzzzzIDAQAB"

What each part is doing:

• mail2026 is a chosen selector, pick something short and meaningful (date-based selectors like 202601 or jan2026 make rotation easier to audit)

• v=DKIM1; k=rsa declares the record and algorithm

• p=<base64 key> carries the public key material

• The quoted strings are the DNS provider's way of storing a value longer than 255 characters, most modern providers handle this concatenation automatically

When to use it: Self-hosted mail servers, corporate outbound relays, any signer you operate yourself.

Matching private key: The private key file stays on the signing server, protected with filesystem permissions (chmod 600minimum). Never commit it to version control. Never include it in the DNS record. The p= in the DNS record is the publichalf only.

Verify with: Run opendkim-testkey -d yourdomain.com -s mail2026 -vvv on the signing server, or use our DKIM Checker for a view of what a receiver sees.

Example 8: Multi-Provider Setup with Distinct Selectors

Most real companies have multiple sending services. Each one needs its own selector and its own DKIM record. Here is what a typical small business might have published:

google._domainkey.yourdomain.com         TXT    v=DKIM1; k=rsa; p=...
k1._domainkey.yourdomain.com             CNAME  dkim.mcsv.net
s1._domainkey.yourdomain.com             CNAME  s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.yourdomain.com             CNAME  s2.domainkey.u12345.wl.sendgrid.net
hs1-87654321._domainkey.yourdomain.com   CNAME  hs1-87654321.hubspotemail.net

What is happening here:

• Google Workspace handles employee email, with a TXT record at the google selector

• Mailchimp handles marketing campaigns, with a CNAME at k1

• SendGrid handles transactional email, with two CNAMEs at s1 and s2

• HubSpot handles CRM email, with a CNAME at hs1-87654321

Why the selector matters: When receivers verify a signature, they look up exactly <s-value-from-signature>._domainkey.<d-value-from-signature>. Each service signs with its own selector, so each service needs its own record at that selector. The records do not conflict because each lives at a unique hostname.

No lookup limit to worry about. Unlike SPF, DKIM does not have a 10-lookup ceiling. You can publish as many selectors as you need.

Audit tip: Pull two weeks of DMARC aggregate reports through iO™ DMARC to see every sender that is signing on behalf of your domain, plus every sender that is not and should be. That is the fastest way to catch a service that is silently failing DKIM because no one published its record.

Example 9: Key Rotation Overlap (Two Keys Live)

During a key rotation, you want both the old and new selectors live at the same time so in-flight messages can still verify against the old key while new messages use the new key.

oldselector._domainkey.yourdomain.com  TXT  v=DKIM1; k=rsa; p=<old 2048-bit key>
newselector._domainkey.yourdomain.com  TXT  v=DKIM1; k=rsa; p=<new 2048-bit key>

What is happening:

• The old selector continues to serve the old public key

• A new selector is published with the new public key

• The signer is reconfigured to use the new selector going forward

• After 7 days (to cover cached messages and queued mail), the old selector is removed

Why this pattern works: There is no moment where a legitimately signed message cannot find its corresponding public key. Receivers looking for the old selector still find it; receivers looking for the new one find it too.

The wrong way to rotate: Do not update the same selector in place. The moment you overwrite the old public key with the new one, any in-flight message signed with the old private key will fail verification, because the selector now points to a key that does not match the signature.

Full rotation details are in our DKIM Signature Fix guide under Error 7.

Example 10: Revoked Key (Empty p=)

When you want to explicitly revoke a DKIM key rather than remove the record entirely, the convention is to publish an empty p= tag.

oldselector._domainkey.yourdomain.com  TXT  v=DKIM1; k=rsa; p=

What is happening:

• The record still exists at the selector hostname

• The p= tag is empty, which tells receivers the key has been revoked

• Any signature still referencing this selector fails verification with a "revoked key" result

When to use this:

• You rotated keys and want to explicitly mark the old selector as revoked before removing it

• A key was compromised and you need to invalidate all outstanding signatures that reference it

• Compliance or audit policy requires an explicit revocation step

Versus removing the record entirely: Removing the record causes verification to fail with a "key not found" error, which receivers treat similarly. The empty p= is the explicit "intentionally revoked" signal, which is cleaner in audit logs.

How long to leave it: Keep the revoked record for at least 7 days, then remove it. At that point, no in-flight message should still reference the selector.

DKIM Tag Reference Table

A quick-scan reference for every tag you might see in a DKIM public key record.

TagMeaningTypical valuev=Version, requiredDKIM1k=Key typersa (default) or ed25519 (rare but supported)p=Base64-encoded public key, requiredLong string, 400+ chars for 2048-bit RSAt=yTest mode flagReceivers should not enforce based on this keyt=sStrict alignment flagSubdomains may not use this keys=emailService type restrictionRestricts key to email use onlyh=sha256Permitted hash algorithmRestricts which hash the signer may useg=Granularity (deprecated in RFC 6376)Do not usen=NotesFree-text, not evaluated by receivers

Most records in practice use only v, k, and p. The other tags are useful in specific scenarios but almost always optional.

What a Bad DKIM Record Looks Like

Three examples that will cause problems, and why.

Broken example 1: Private key published instead of public key

v=DKIM1; k=rsa; p=MIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQC... (private key material)

This is a catastrophic security failure. The DNS record is supposed to contain only the public key half. Anyone who retrieves this record now has your private key and can sign messages pretending to be from your domain. Regenerate the key pair immediately, publish the correct public key, and audit your servers for any signs of abuse.

Broken example 2: Truncated public key

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxxxxxxxxx

This record exists but the key is cut off (the full key should continue for hundreds more characters and end with IDAQAB). Receivers try to parse it, get garbage, and fail verification. Usually the result of a DNS provider that silently truncated at the 255-character per-string limit and did not auto-split. Republish with proper splitting.

Broken example 3: Missing or malformed tags

k=rsa p=MIIBIjANBgkqhkiG...

No v=DKIM1 prefix. No semicolons between tags (just spaces). This is not recognized as a DKIM record by most receivers, so they treat it as key not found and the signature fails.

Compare to a correct version:

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

Proper prefix, tag separators (semicolons), tag values paired with =.

If any of these patterns look familiar on your own domain, walk through the DKIM Signature Fix guide, specifically Errors 3 and 12, for the full remediation path.

Copy-Paste Templates

Bookmark this section. Replace the example values with your own, validate with our DKIM Checker, and publish.

Google Workspace (TXT at google._domainkey.yourdomain.com):

v=DKIM1; k=rsa; p=<public-key-from-Google-admin-console>

Microsoft 365 (two CNAMEs):

selector1._domainkey.yourdomain.com  CNAME  selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com
selector2._domainkey.yourdomain.com  CNAME  selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Mailchimp / Mandrill (CNAME):

k1._domainkey.yourdomain.com  CNAME  dkim.mcsv.net

SendGrid (two CNAMEs):

s1._domainkey.yourdomain.com  CNAME  s1.domainkey.u12345.wl.sendgrid.net
s2._domainkey.yourdomain.com  CNAME  s2.domainkey.u12345.wl.sendgrid.net

HubSpot (CNAME):

hs1-<portal-id>._domainkey.yourdomain.com  CNAME  hs1-<portal-id>.hubspotemail.net

Amazon SES (three CNAMEs, values come from SES console):

<token1>._domainkey.yourdomain.com  CNAME  <token1>.dkim.amazonses.com
<token2>._domainkey.yourdomain.com  CNAME  <token2>.dkim.amazonses.com
<token3>._domainkey.yourdomain.com  CNAME  <token3>.dkim.amazonses.com

Self-hosted signer (TXT):

v=DKIM1; k=rsa; p=<your 2048-bit public key in Base64>

Revoked key (TXT):

v=DKIM1; k=rsa; p=

For the full story on how these records fit into your overall email authentication posture, see What is SPF Email, DKIM, and DMARC? and pair with our SPF Record Example guide.

Frequently Asked Questions

1. What does a valid DKIM record look like? A valid DKIM record is a DNS TXT (or CNAME) record at <selector>._domainkey.<yourdomain>. For TXT records, the value starts with v=DKIM1; k=rsa; and ends with the Base64 public key in a p= tag. A simple valid example is v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB.

2. Can I see examples of DKIM records for specific providers? Yes. Google Workspace uses a TXT record at google._domainkey. Microsoft 365 uses two CNAMEs at selector1 and selector2. Mailchimp uses a CNAME at k1. SendGrid uses two CNAMEs at s1 and s2. HubSpot uses a CNAME at hs1-<portal-id>. Amazon SES uses three CNAMEs with random token selectors. Each provider publishes its own documentation with exact values.

3. TXT or CNAME, which should I use? Whichever your provider specifies. Hosted providers (Microsoft, Mailchimp, SendGrid, HubSpot, SES) use CNAMEs so they can rotate keys for you. Self-managed signers (OpenDKIM, Exim, Postfix) use TXT records because you control the keys yourself. Google Workspace uses TXT even though it is hosted, because Google gives you the public key value to publish directly.

4. How do I know if my DKIM record is working? Run it through the iO™ DKIM Checker for an instant view. You can also query DNS directly: dig TXT <selector>._domainkey.<yourdomain> +short. To see real verification results in the wild, ingest DMARC aggregate reports through iO™ DMARC.

5. How many DKIM records can a domain have? As many as you need. Each sending service gets its own selector and its own record. Unlike SPF, there is no lookup limit.

6. How often should I rotate DKIM keys? A common best practice is every 6 to 12 months, following the overlap pattern in Example 9. Some compliance frameworks require specific rotation cadences. Hosted providers that use CNAME delegation rotate for you automatically.

7. Why is my DKIM record not verifying even though it exists? The most common reasons are a truncated or split-string public key (DNS UI did not preserve the full value), a CNAME pointing at the wrong target, a stale record from a previous provider, or a selector mismatch between what the signer uses and what is published. Walk through our DKIM Signature Fix guide for each of those scenarios.

8. Can I use the same DKIM key for multiple providers? No. Each provider signs with its own private key, so each must have its own public key published at its own selector. Trying to point multiple selectors at the same key does not work, because the private key material lives at each provider's end, not yours.

Keep Your DKIM Clean

DKIM records are a little weirder than SPF, but they are not mysterious. Once you have seen a few real examples, the pattern is obvious: a selector hostname, a version tag, a key type tag, and a public key.

The work is in keeping them current. New providers get added, old ones get dropped, keys get rotated. The companies whose DKIM stays clean are the ones that treat it as infrastructure they monitor, not a project they finished.

If you want a second set of eyes on your records, or a full audit of your SPF, DKIM, DMARC, and BIMI posture, reach out at 844-InputOut (467-8868) or through inputoutput.com. Our Email Audit service turns the entire authentication picture into a prioritized action plan, and our iO™ DMARC platform keeps you watching the results in real time.

Get the records right. Keep them rotated. Your email does the rest.

BE BETTER. BE iO.™