To set up DKIM, you generate a key pair with a selector, publish the public key in DNS, and enable DKIM signing in your email provider’s console, then confirm the result by checking for a dkim=pass result in the Authentication-Results header of a message sent to an external mailbox. DNS changes can take 48 to 72 hours to propagate fully. Getting this sequence right matters for DMARC enforcement, and services like PlusVibe can handle the entire configuration for teams that would rather not manage DNS records manually.

Key Takeaways

Proper DKIM setup enhances email deliverability and the effectiveness of DMARC by verifying message authenticity through DNS-published public keys and enabled signing.

Table of Contents

• How DKIM works and why it matters for deliverability and DMARC
• Prerequisites and checklist before you start
• Step 1: generate a DKIM key pair and choose a selector
• Step 2: publish the DKIM public key in DNS
• Step 3: enable signing and verify DKIM is working
• Provider-specific setup notes: Google Workspace, Microsoft 365, Amazon SES
• Rotate keys and maintain DKIM over time
• Testing and troubleshooting checklist for DKIM failures
• Why DKIM deserves more attention than it usually gets
• Let us handle your DKIM setup for you
• FAQ
• Sources

How DKIM works and why it matters for deliverability and DMARC

DKIM, or DomainKeys Identified Mail, attaches a digital signature to outgoing email using a private key held by your mail server. The receiving server looks up the matching public key in your domain’s DNS records and uses it to confirm the message actually came from your domain and wasn’t altered in transit, a process Google Workspace describes as central to verifying sender legitimacy. The signature covers specific header fields and the message body, so any tampering after signing breaks the match and the check fails.

This is a different job from what SPF does. SPF authorizes which IP addresses may send mail for your domain, a permission check performed before delivery. DKIM instead verifies message integrity after the fact, confirming the content wasn’t modified and the signature matches a key your domain actually published, a distinction SPFmonitor’s setup guide lays out clearly. DMARC sits above both, telling receiving servers what to do when SPF or DKIM checks fail and giving you reporting on the results.

Together, the three controls close most of the gaps that let attackers spoof your domain:

• SPF confirms the sending server is authorized for your domain.
• DKIM confirms the message content hasn’t been altered since signing.
• DMARC enforces a policy (reject, quarantine, or monitor) when either check fails and reports the outcomes back to you.

Skipping DKIM, or publishing it incorrectly, weakens DMARC enforcement and tends to push more of your mail into spam folders, even when SPF passes on its own.

Prerequisites and checklist before you start

Before touching any DNS settings, confirm you actually have the access you’ll need. That means an account with zone-editing rights at your DNS host, plus admin access to your email platform’s console, whether that’s Google Admin, the Microsoft 365 admin center, or Exchange Online PowerShell for more granular control. Microsoft 365 admins in particular need the correct portal permissions to toggle DKIM signing, a step that trips up a surprising number of otherwise correctly configured domains, as detailed in a Microsoft Q&A thread on enabling DKIM signing.

A quick checklist before you begin:

• Confirm your “From” sending domain is already verified inside your email platform.
• Decide on a selector naming convention now, since changing it later means republishing DNS records.
• Prefer a 2048-bit key where your DNS host supports it; fall back to a 1024-bit key only if required.
• Line up a test mailbox at an external provider (a personal Gmail or Outlook account works fine) for verification later.
• Expect DNS propagation to take 48 to 72 hours before testing is reliable.

Pro Tip: Write down your selector name and creation date in a shared document before you publish anything. It saves confusion later when you’re rotating keys across multiple domains.

Step 1: generate a DKIM key pair and choose a selector

A selector is a short string that acts as the address for your public key in DNS. It becomes the first part of the hostname where your key lives, something like selector1._domainkey.yourdomain.com, and its real purpose is letting you rotate keys or run multiple signing configurations without ever changing that hostname pattern. Pick something short and identifiable, such as a date-based string or a provider abbreviation, and keep a record of it.

You have two routes for generating the key pair:

1. Provider-generated keys: Google Workspace and Microsoft 365 can generate DKIM keys for you through their services, which may be a simpler path than generating keys yourself.
2. Self-generated keys (BYODKIM): you create the key pair yourself when you need more control over the configuration or are signing from infrastructure outside a provider-managed service.

Whichever route you take, Google Workspace’s setup documentation recommends a 2048-bit key whenever your DNS provider supports it, since longer keys are harder to compromise; 1024-bit remains an acceptable fallback where the DNS host enforces tighter record limits. The private half of the key pair stays on your mail server or inside your provider’s signing infrastructure. It never gets published anywhere, DNS included. Only the public key goes into your DNS zone.

Pro Tip: If you’re generating your own key pair with OpenSSL, double-check the output format before uploading it. Providers expect the public key stripped of header and footer lines and the newlines removed, and a stray line break is one of the most common reasons a freshly published record fails validation.

Step 2: publish the DKIM public key in DNS

Once you have a key pair, the public key needs a home in DNS. The canonical hostname pattern looks like selector._domainkey.yourdomain.com, and the TXT record value starts with v=DKIM1; k=rsa; p= followed by the base64-encoded public key, a format Google Workspace’s DKIM guide specifies exactly.

Not every provider wants a TXT record, though. Google Workspace and most BYODKIM setups use a direct TXT record containing the full key string. Microsoft 365 instead issues two CNAME records per domain, commonly named selector1 and selector2, that point to Microsoft-hosted DKIM hostnames rather than exposing the key directly, a structure explained in Microsoft Learn’s walkthrough of hooking up DKIM signing in Office 365. Mixing these up, pasting a Microsoft CNAME value into a TXT record or vice versa, is one of the more common setup errors.

A practical detail matters here:

• Most DNS hosts cap individual TXT strings at 255 characters, which a 2048-bit key will exceed on its own.
• When that happens, split the key into multiple quoted strings within the same record so your DNS host concatenates them correctly rather than truncating the value.
• Choose a TTL appropriate for your DNS host and setup.
• Verify the published record externally with a tool like dig or Google’s Admin Toolbox before assuming it’s live.

Many DNS providers enforce a 255-character limit per TXT string, which means a full 2,048-bit DKIM key almost always needs to be split across multiple quoted segments to avoid silent truncation that breaks signature validation.

Pro Tip: After publishing, run a DNS lookup on the exact selector hostname before you touch the provider console. If the record doesn’t resolve cleanly at this stage, enabling signing won’t fix anything.

Step 3: enable signing and verify DKIM is working

Publishing the DNS record is only half the job. The signature never gets attached to outgoing mail until you flip the “enable signing” toggle inside your provider’s admin console, a step administrators forget often enough that it has its own name in DKIM Test’s troubleshooting guide: the record exists, DNS checks out, and mail still isn’t signed because signing was never switched on.

Once signing is active, verification follows a consistent pattern:

1. Send a test message to an external mailbox, such as Gmail or Outlook, rather than to an address inside your own organization.
2. Open the message’s full headers and look for the Authentication-Results line.
3. Confirm it reads dkim=pass, and check the accompanying DKIM-Signature header to verify the selector and domain match what you published.

Internal self-tests are unreliable here because many mail systems skip authentication checks entirely for messages that never leave their own infrastructure, a point Google Workspace’s documentation flags specifically.

Each major provider also ships its own diagnostic tool:

• Google Admin console’s “Authenticate email” page can be used to check DKIM status for a domain.
• Check Microsoft Defender’s DKIM settings to see whether signing is enabled.
• Check your email provider’s console for DKIM configuration status.

If the first check fails right after enabling signing, allow time for DNS propagation before re-running diagnostics.

Provider-specific setup notes: Google Workspace, Microsoft 365, Amazon SES

The core steps stay the same across providers, but the exact clicks and record types differ enough to trip people up.

Google Workspace:

1. Generate the DKIM key inside the Admin console under Apps > Gmail > Authenticate email.
2. Publish the resulting TXT record with your DNS host, using the selector and value Google provides.
3. Return to the Admin console and click “Start authentication” to turn on signing.

Google’s own guidance says to wait 24 to 72 hours after first enabling Gmail for your organization before generating keys, giving the service time to provision the domain.

Microsoft 365:

1. Publish two CNAME records per domain, commonly selector1 and selector2, pointing to the Microsoft-hosted hostnames supplied in the admin center.
2. Do not attempt to substitute a TXT record here; Microsoft’s managed DKIM relies specifically on the CNAME structure, as Microsoft Learn’s configuration guide confirms.
3. Enable signing from the Defender portal’s email authentication settings, or run the equivalent Exchange Online PowerShell cmdlet if you manage many domains at once.

One detail worth flagging: DKIM settings don’t carry over between domains or subdomains automatically. Each one you send from needs its own CNAME pair and its own signing toggle, a requirement spelled out in the Microsoft Q&A guidance on fixing DKIM signing.

Amazon SES:

• Check Amazon SES’s documentation for the available DKIM configuration options and the steps for your sending identities.

Rotation support varies between provider-generated and self-generated keys: provider-generated keys (Google Workspace, Microsoft 365, SES Easy DKIM) typically rotate automatically on a schedule the provider manages, while BYODKIM setups put rotation entirely on you.

Rotate keys and maintain DKIM over time

DKIM isn’t something you configure once and forget. Review your provider’s key-rotation guidance and follow its recommended sequence when replacing a key. Replacing a key in the wrong order risks a window where mail fails authentication entirely.

Keep a simple running inventory of every selector in use across your domains, along with when each was created and which system manages it. That record becomes essential once you’re running more than one domain or juggling both provider-managed and self-generated keys.

• Document each selector’s name, creation date, and which domain or provider it belongs to.
• Sample message headers periodically to confirm pass rates haven’t degraded.
• If your provider manages rotation automatically, confirm the schedule and whether any action is required on your end before an old key expires.

Pro Tip: Set a calendar reminder tied to your key rotation schedule rather than relying on memory. Neglecting key maintenance on a self-managed BYODKIM setup may contribute to deliverability problems.

Testing and troubleshooting checklist for DKIM failures

When dkim=fail shows up, or a signature is missing entirely, work through the issue in order rather than guessing.

1. Confirm the selector name in the DKIM-Signature header matches exactly what’s published in DNS. A mismatch here, even a single character, breaks verification.
2. Check that the full public key resolved in DNS, with no truncation from the 255-character TXT limit.
3. Verify signing is enabled in your provider’s console, since administrators can publish a DNS record without enabling signing.
4. Confirm you used the correct record type for your provider, CNAME for Microsoft-managed DKIM, TXT for Google Workspace and most BYODKIM setups.
5. Allow for propagation delays before concluding a correctly published record has failed.

Always test with a message sent to an external mailbox rather than one inside your own organization, since internal delivery paths often skip the authentication checks you’re trying to verify, a caution Google Workspace’s own documentation raises directly.

• Useful tools: dig TXT selector._domainkey.yourdomain.com, Google’s Admin Toolbox Dig, any public DKIM lookup tool, and Exchange Online PowerShell scripts for bulk Microsoft 365 checks.
• If errors persist after confirming all of the above, check your DNS host for hidden formatting issues, extra quotation marks or escaped characters are a frequent, hard-to-spot cause, and contact your DNS provider’s support team if the record still won’t resolve cleanly.

Pro Tip: Keep a plain-text copy of the exact value you intended to publish. Comparing it character by character against what actually resolves in DNS catches formatting issues faster than reading through the provider’s web interface.

Why DKIM deserves more attention than it usually gets

Most teams treat DKIM as a box to check once during initial domain setup, then never look at it again. That’s backward. DKIM, SPF, and DMARC form a system that only works as well as its weakest, most neglected piece, and DKIM is usually the one nobody revisits once the initial green checkmark appears. Key rotation gets skipped, selectors pile up undocumented across domains, and nobody notices until a deliverability problem forces a DNS audit months later.

Ongoing monitoring can help teams maintain DKIM rather than treating authentication as a one-time setup task. If you’re running several domains, dealing with complex mail routing, or just want the verification done correctly the first time without burning a day on DNS edge cases, that’s exactly the situation where handing the setup to someone who does it routinely saves more than it costs.

— Yaro

Let us handle your DKIM setup for you

Setting up DKIM correctly across multiple domains, with the right selectors, clean DNS records, and signing actually switched on, takes real attention to detail that’s easy to get wrong once. Our Done-for-you Email Setup service can help with DKIM setup.

Here’s what we can help with as part of that setup:

• DKIM setup and configuration.
• Connecting your signed domain to our email warm-up process.

If you’d rather see the full picture of plans first, our plans page lays out every option, including the Done-for-you Email Setup, so you can pick the path that fits how many domains and inboxes you’re managing.

FAQ

How do I set up DKIM for my domain?

Generate a DKIM key pair with a selector, publish the public key in your DNS zone using the hostname pattern selector._domainkey.yourdomain.com, and enable signing in your email provider’s admin console. Confirm it worked by sending a test message to an external mailbox and checking for dkim=pass in the Authentication-Results header, per Google Workspace’s setup guidance.

How do I set up DKIM?

The process is the same regardless of which domain you’re configuring: generate the key pair, publish the public key in DNS as either a TXT record or provider-supplied CNAME, and enable signing in your email platform’s console. Each domain and subdomain you send from needs its own DKIM configuration, since settings don’t carry over automatically between them.

Is DKIM enabled on my domain?

Check your email provider’s admin console, Google Admin’s “Authenticate email” page, Microsoft Defender’s DKIM tab, or AWS SES’s identity dashboard, which all report current signing status directly. You can also send a test email to an external address and look for dkim=pass in the message headers to confirm signing is active and verifying correctly.

How do I set up DKIM for Outlook?

For Microsoft 365, publish two CNAME records per domain (commonly named selector1 and selector2) that point to the Microsoft-hosted DKIM hostnames shown in the admin center, rather than using a TXT record, as described in Microsoft Learn’s DKIM configuration guide. Then enable DKIM signing from the Defender portal’s email authentication settings or through Exchange Online PowerShell.

How does DKIM relate to SPF and DMARC?

DKIM verifies that a message’s content wasn’t altered after it was signed, while SPF checks whether the sending server is authorized to send for your domain, two different checks covering different risks. DMARC sits above both, telling receiving servers what to do when either check fails and giving you reporting, which is why properly aligned DKIM is a prerequisite for effective DMARC enforcement.

Sources

• Set up DKIM  |  Security & data protection  |  Google Workspace Help
• Manually hooking up DKIM signing in Office 365 | Microsoft Learn

Recommended

• DKIM alignment: the quiet deliverability killer
• Tech Setup for Cold Email - SPF, DKIM, DMARC
• A Guide to DKIM Records and Email Security
• SPF, DKIM & DMARC: The Ultimate Guide to Email Security