Table of Contents
- Why Your Gmail Emails Land in Spam and How DKIM Fixes It
- What Gmail is actually checking
- Why this affects revenue and reputation
- Generating Your DKIM Key in the Google Admin Console
- Where to generate the key
- What to choose and why
- What you should copy before leaving the page
- Publishing and Verifying Your Gmail DKIM Record
- How to publish the TXT record
- How to verify that Gmail is signing mail
- Manual check versus faster diagnosis
- Troubleshooting Common Gmail DKIM Failures
- Google Admin says Authenticating
- The record exists but DKIM still fails
- The selector and signing path don't match
- Advanced DKIM for Third-Party Senders and DMARC Alignment
- Why a DKIM pass can still go to spam
- How to check alignment in Gmail headers
- A practical workflow for apps and AI agents
- Frequently Asked Questions about DKIM for Gmail
- What is a DKIM selector
- Is a 1024-bit DKIM key still okay for Gmail
- How often should DKIM keys be rotated
- Can AI agents verify DKIM automatically
- Does DKIM protect the whole email
- Frequently Asked Questions about DKIM for Gmail
- What is a DKIM selector
- Why does DKIM affect email deliverability
- How does someone check DKIM for Gmail
- Why do authenticated emails still land in spam
- Can AI agents check DKIM automatically
Do not index
Do not index
Sales emails stop getting replies. Password reset emails arrive late or land in spam. A founder launches a campaign, sees clean copy and decent targeting, then watches Gmail bury messages anyway. That usually isn't random. It's often authentication breaking at the DNS or sender level.
DKIM is one of the first places to look. If Gmail can't verify that a message really came from the domain in the From line, inbox placement gets harder, spoofing risk goes up, and sender reputation becomes fragile. For teams using Google Workspace, the setup is straightforward. For teams sending through CRMs, outbound tools, or AI agents, the issue often runs deeper than basic setup.
A lot of guides stop at “publish the key.” That isn't enough for modern deliverability. The useful question is whether Gmail sees a valid DKIM signature, whether that signature aligns with the visible From domain, and whether every sending source is using the right signing path.
Table of Contents
Why Your Gmail Emails Land in Spam and How DKIM Fixes ItWhat Gmail is actually checkingWhy this affects revenue and reputationGenerating Your DKIM Key in the Google Admin ConsoleWhere to generate the keyWhat to choose and whyWhat you should copy before leaving the pagePublishing and Verifying Your Gmail DKIM RecordHow to publish the TXT recordHow to verify that Gmail is signing mailManual check versus faster diagnosisTroubleshooting Common Gmail DKIM FailuresGoogle Admin says AuthenticatingThe record exists but DKIM still failsThe selector and signing path don't matchAdvanced DKIM for Third-Party Senders and DMARC AlignmentWhy a DKIM pass can still go to spamHow to check alignment in Gmail headersA practical workflow for apps and AI agentsFrequently Asked Questions about DKIM for GmailWhat is a DKIM selectorIs a 1024-bit DKIM key still okay for GmailHow often should DKIM keys be rotatedCan AI agents verify DKIM automaticallyDoes DKIM protect the whole emailFrequently Asked Questions about DKIM for GmailWhat is a DKIM selectorWhy does DKIM affect email deliverabilityHow does someone check DKIM for GmailWhy do authenticated emails still land in spamCan AI agents check DKIM automatically
Why Your Gmail Emails Land in Spam and How DKIM Fixes It
If a company sends through Gmail or Google Workspace without DKIM, Gmail has less proof that the message is authentic. That weakens trust before content, links, and engagement are even considered. For outbound, that means lower inbox placement. For transactional mail, it means real users may miss critical messages.
A useful benchmark comes from a DMARC Analyzer report covered by mailX: only approximately 33.4% of the top 1 million domains globally currently publish valid DKIM records that are properly enforced. That low adoption helps explain why Gmail has tightened authentication enforcement. It also means many domains still look less trustworthy than their owners assume.
For teams that want a broader operational view, this guide for app teams on email deliverability is useful because it connects authentication problems to app onboarding, lifecycle email performance, and sender reputation.
What Gmail is actually checking
DKIM stands for DomainKeys Identified Mail. In practice, it's a cryptographic signature attached to an outgoing email. The receiving server looks up a public key in DNS and uses it to verify that the signed parts of the message were authorized by the sender's domain.
That matters because Gmail doesn't want to trust the visible From address by itself. Anyone can put a brand name in the From line. DKIM gives Gmail a technical way to ask, “Did a server with access to this domain's private key sign this message?”
Why this affects revenue and reputation
The business impact is direct:
- Sales outreach suffers: Reps can send good campaigns that never reach the primary inbox.
- Marketing performance drops: Newsletter and nurture sequences lose visibility before subject line testing even matters.
- User trust erodes: If billing notices, invite emails, or login links go missing, users blame the product, not the mailbox provider.
- Domain reputation gets weaker: Repeated unauthenticated or inconsistently authenticated traffic trains mailbox providers to be cautious.
A strong DKIM setup doesn't guarantee inbox placement. Content quality, complaint rates, sending patterns, and infrastructure still matter. But without DKIM, every other deliverability improvement starts from a weaker position.
Generating Your DKIM Key in the Google Admin Console
Google Workspace makes DKIM for Gmail relatively simple if the domain sends directly from Workspace. The exact path is in Google Admin: Apps > Google Workspace > Gmail > Authenticate email. Google documents that workflow in its official Admin help for DKIM setup.
Where to generate the key
Inside Authenticate email, the admin selects the domain and generates a new DKIM record. Google provides the selector and the public key value that will later be published in DNS.
The practical sequence is:
- Open Admin Console: Sign in with an account that has the right admin permissions.
- Go to Gmail authentication: Proceed to Apps, then Google Workspace, then Gmail, then Authenticate email.
- Pick the sending domain: Make sure the correct domain is selected if the account manages more than one.
- Generate a new record: Google will present a selector and a public key.
What to choose and why
Google's documented setup requires generating a 2048-bit key, using the google prefix selector, and then publishing the TXT record in DNS. The same documentation notes a common operational issue: DNS propagation typically takes 15 to 48 hours, and clicking Start authentication too early can leave the status stalled at authenticating in the Admin Console, as explained in Google's DKIM instructions.
That creates three practical rules.
Choice | Recommended setting | Why it matters |
Key length | 2048-bit | Stronger modern standard for authentication |
Selector | google | Keeps setup simple and predictable |
Activation timing | After propagation | Prevents false setup failures |
A selector is just a label that tells receiving servers which DKIM key to look up. For Google Workspace, using the default google selector keeps administration simpler unless there's a specific reason to manage multiple selectors.
What you should copy before leaving the page
Before closing the Admin Console, capture these values carefully:
- Selector name: Usually
google
- DNS host/name: Built from the selector and domain
- TXT value: The DKIM public key string that starts with
v=DKIM1; k=rsa; p=...
Copying errors here cause a surprising share of failed implementations. A missing character, a broken line wrap, or publishing the record under the wrong host name is enough to stop Gmail from signing correctly later.
Publishing and Verifying Your Gmail DKIM Record
The key generation step happens in Google. The success or failure usually happens in DNS. During this phase, many teams think DKIM is live when it isn't.
How to publish the TXT record
The record goes into the DNS provider that hosts the domain, such as Cloudflare, GoDaddy, or another registrar or DNS platform. The format Google expects is a TXT record with a value like
v=DKIM1; k=rsa; p=<public_key>.A clean publishing checklist looks like this:
- Use the exact host name: It should match the selector and domain Google generated.
- Paste the full TXT value: Don't trim spaces or break the key into the wrong format.
- Save only one intended record: Avoid duplicate or conflicting entries for the same selector.
- Wait for propagation: DNS changes aren't immediate.
If the domain team wants a simpler way to create the right value format before publishing, a DKIM record generator for Gmail and other senders can help validate the expected structure.
How to verify that Gmail is signing mail
Publishing the record is only half the job. Verification is what tells a team whether Gmail is signing outbound messages and whether receiving servers can validate the signature.
The manual workflow is:
- Wait for DNS to propagate
- Return to Google Admin and start authentication
- Send a test message to an external mailbox
- Open the received message and inspect the original headers
- Look for Authentication-Results and the DKIM result
Google's Workspace guidance is explicit on one easy-to-miss trap: sending a test email to the same sender account will not show a valid DKIM verification result. Gmail suppresses self-validation, so 100% of internal self-tests create a false negative in this scenario, according to Google Workspace's DKIM verification guidance.
Manual check versus faster diagnosis
In the full headers, the line to inspect is Authentication-Results. A healthy result usually shows DKIM=pass or DKIM=OK. If there's no DKIM result at all, the message may not have been signed. If it shows fail or neutral, something is wrong in DNS, signing, or both.
A quick interpretation table helps:
Header result | What it usually means | Next action |
DKIM=pass | Gmail signed the mail and the receiving server validated it | Move on to alignment and DMARC checks |
DKIM=fail | Signature exists but validation failed | Check selector, TXT formatting, and key match |
DKIM=neutral | Receiver couldn't confidently validate | Recheck DNS publication and signing path |
No DKIM line | Message may not be signed | Confirm Google authentication is enabled and test externally |
For founders and marketers, reading raw headers isn't pleasant. For developers, it's useful but still slow. The important thing is to confirm not just record existence, but whether the live message indeed passes authentication.
Troubleshooting Common Gmail DKIM Failures
Most Gmail DKIM failures aren't mysterious. They're usually one of a handful of operational mistakes. The problem is that the error message is often vague, and legacy DNS tools tend to show raw records without telling the team what to fix next.
A solid starting point is to run an email authentication check for Gmail and other providers before changing multiple things at once. That keeps troubleshooting disciplined instead of turning it into guesswork.
Google Admin says Authenticating
This is the most common frustration after setup. The record has been pasted into DNS, but Google still won't activate DKIM cleanly.
The first suspect is propagation delay. DNS updates may take time to appear across resolvers, and Google may not see the record yet even if the admin can see it inside one DNS interface.
Fix sequence:
- Wait before retrying: If the record was just added, patience is part of the process.
- Recheck the exact host name: A record on the wrong name won't be found.
- Confirm there isn't an old conflicting record: Multiple entries can create inconsistent validation.
The record exists but DKIM still fails
A visible record isn't the same as a valid record. Formatting mistakes are common. Quoting problems, line wrapping, or publishing an incomplete public key can all break validation.
When headers show fail or neutral, check these items:
- TXT formatting: The value should match the key Google generated.
- No copy-paste corruption: Long keys often pick up hidden errors during manual editing.
- Correct DNS location: The selector path must be published in the right place.
The selector and signing path don't match
Selector mismatch is another repeat offender. The selector in the DNS record has to match the selector used by the sender when it signs the message. If Google signs with one selector and DNS publishes another, verification fails.
A quick symptom-to-fix table makes this easier:
Symptom | Likely cause | Fix |
Admin stays stuck on authenticating | DNS hasn't propagated or record is misplaced | Wait and verify host name |
DKIM=fail in headers | Key formatting issue or wrong public key | Republish the exact TXT value |
No DKIM signature | Authentication not enabled or sending path bypasses Workspace | Check Google Admin and actual sender |
Intermittent results | Conflicting records or mixed sending sources | Audit all active senders and selectors |
The useful mindset is simple. Diagnose one layer at a time. DNS first. Then Google activation. Then live message headers. Then sending source.
Advanced DKIM for Third-Party Senders and DMARC Alignment
Basic setup in Google Workspace only covers messages that Google Workspace signs. That's where many teams get caught. A domain can have perfect Gmail DKIM for direct Workspace mail and still have poor inbox placement from HubSpot, Salesforce, a sales engagement tool, or an AI agent using a relay path.
Why a DKIM pass can still go to spam
The hidden issue is alignment. A message can technically pass DKIM, but if the domain that signed it doesn't align with the visible From domain, DMARC may not treat that as a valid aligned authentication signal.
This matters a lot with third-party senders. An ESP may sign with its own domain while the visible From address shows the company's root domain. The message is signed, but not in a way that supports the domain's DMARC policy cleanly.
A particularly useful data point comes from mailX's analysis of DKIM and DMARC alignment failures: analysis of 50,000+ campaign logs indicates that 35% of ESP-relayed failures are misdiagnosed as “missing DKIM” by users, whereas the root cause is instead a “DKIM non-alignment” issue where the signing domain and From domain do not match.
That explains a common complaint: “DKIM passes, but Gmail still treats the mail badly.”
How to check alignment in Gmail headers
The place to inspect is still the original message headers. The team should compare:
- From domain: The domain visible to the recipient
- DKIM signing domain: The
d=value in the DKIM-Signature
- DMARC result: Whether the message shows a DMARC pass tied to aligned authentication
A simplified reading guide:
Header element | What to compare | Why it matters |
From | Visible sender domain | This is the identity users see |
dkim.d | Domain that signed the message | Must align properly for DMARC value |
DMARC result | Pass or fail status | Tells whether alignment worked in practice |
If the From domain is
company.com but the DKIM signature uses a third-party domain, the message may authenticate without aligning. That's the gap many basic tutorials miss.A practical workflow for apps and AI agents
For relayed or automated sending, a disciplined workflow helps:
- List every sending source Include Google Workspace, CRM platforms, support tools, product mailers, and AI-driven workflows.
- Check who signs each message A Gmail setting doesn't automatically cover external senders or relays.
- Inspect the live headers Look for the actual signing domain, not just whether a DNS record exists.
- Confirm DMARC alignment A DKIM pass by itself isn't the finish line for modern Gmail deliverability.
- Fix the sending path Either configure the third-party platform to sign with the primary domain, or adjust the architecture so mail isn't relayed in a way that breaks alignment.
Teams using Google as relay infrastructure for external tools should also understand how the relay path affects authentication. This guide to Google SMTP relay behavior is helpful when mail appears to come through Gmail but is signed elsewhere.
For AI agents, the risk is operational. An agent can write and send messages at scale, but if it doesn't verify the signing and alignment path first, it can automate poor deliverability faster than a human ever could.
Frequently Asked Questions about DKIM for Gmail
What is a DKIM selector
A DKIM selector is the label used to identify which public key a receiving server should fetch from DNS. In Google Workspace, the common default is google. One domain can use more than one selector, but most small teams only need one unless they are rotating keys or separating senders.
Is a 1024-bit DKIM key still okay for Gmail
Google Workspace supports 1024-bit keys, but 2048-bit is the better choice for current setup. It's the recommended option in Google's own workflow for DKIM generation, and it's the safer standard for a fresh implementation.
How often should DKIM keys be rotated
Key rotation is a sensible security practice, especially for domains with multiple senders or more complex infrastructure. The exact schedule depends on the organization's risk tolerance and change management process. The important part is to rotate carefully, publish the new DNS record correctly, and verify live signing before retiring the old path.
Can AI agents verify DKIM automatically
Yes, if the workflow includes live checks instead of assumptions. An agent should verify that the domain publishes the expected record, inspect whether live mail is signed, and confirm whether the signing domain aligns with the From domain. This is one reason modern deliverability tooling needs API and MCP support rather than only a human-facing DNS lookup page.
Does DKIM protect the whole email
No. A useful technical detail from a Cryptography Engineering analysis of Gmail DKIM behavior is that Gmail's DKIM implementation signs a specific set of headers using the
h= tag, including mime-version:references:in-reply-to:from:date:message-id:subject:to. That means DKIM verifies sender-origin information and the integrity of those headers, but it does not sign the body content in the same way. So DKIM is about origin and header integrity, not a blanket guarantee about every part of the visible message.Frequently Asked Questions about DKIM for Gmail
What is a DKIM selector
A selector is the name used in DNS to point receivers to the right DKIM public key. For Google Workspace, the common default is
google. If a team uses multiple senders or rotates keys, it may use more than one selector.Why does DKIM affect email deliverability
DKIM helps Gmail verify that a message was authorized by the sending domain and that key message headers weren't tampered with in transit. That improves trust in the email's origin, which supports inbox placement and protects domain reputation.
How does someone check DKIM for Gmail
The reliable way is to send a message to an external mailbox, open the original headers, and look for DKIM=pass in the Authentication-Results line. For third-party apps, the team should also compare the signing domain against the visible From domain to confirm alignment.
Why do authenticated emails still land in spam
Authentication is necessary, but it isn't the only signal. A message can pass DKIM and still have problems with alignment, reputation, sending behavior, or content patterns. For many app and AI-agent workflows, alignment is the hidden failure point.
Can AI agents check DKIM automatically
Yes. They should query live DNS, validate signing results from message headers, and check alignment before sending or scaling campaigns. That's much safer than letting an agent send blindly and discovering the issue after reply rates collapse.
Email deliverability problems usually aren't random. They come from authentication gaps, DNS mistakes, sender misalignment, or infrastructure decisions that mailbox providers don't trust. DKIM for Gmail is one of the core fixes, but the ultimate benefit comes from validating the full sending path, especially for third-party tools and AI agents.
mailX is built for exactly that job. It runs live checks across DKIM, SPF, DMARC, DNS, MX, blacklist status, SMTP and more, then explains what matters and what to fix next in plain English. For teams that want the fastest path from “our emails are going to spam” to a concrete diagnosis, it's one of the best free deliverability tools available, and it's built for humans and AI agents alike.