Generate DKIM Keys with SHA256

Why Does Gmail Require SHA256 for DKIM?

You sent a message, and it landed in Gmail’s spam folder—despite having SPF and DKIM set up. You checked the headers. Everything looked correct. So why didn’t it pass?

The answer often lies in the hash algorithm behind your DKIM signature. Gmail now requires SHA256 by default. If your domain signs with SHA1 or an older digest method, Gmail may reject the signature—even if your setup otherwise appears valid.

Drafting a message with SHA256 isn’t just about compliance; it’s about ensuring Gmail treats your emails as trustworthy. SHA256 provides stronger cryptographic integrity than SHA1, which is no longer considered secure. Using it aligns your domain’s email authentication with modern standards, especially for Gmail recipients.

Key takeaways

Gmail validates DKIM signatures using SHA256 as the default algorithm.
Using SHA1 or older algorithms can cause DKIM failures and hurt inbox placement.
Generating new DKIM keys with SHA256 ensures compatibility with Gmail and modern email security requirements.

How to Generate New DKIM Keys with SHA256

You generate new DKIM keys with SHA256 by creating a 2048-bit RSA key pair using OpenSSL, explicitly setting the signing algorithm to SHA256 in your email system, publishing the full selector and domain in a DNS TXT record, confirming your ESP supports SHA256 signing, and testing the record’s visibility with tools like dig or MxToolbox.

Step-by-step key generation and setup

Generate a 2048-bit RSA key pair using a secure tool like OpenSSL. This ensures cryptographic strength and is widely accepted by email providers including Gmail. Use the command: openssl genrsa -out dkim.private 2048.
Extract the public key from the private key file. The public key is used in DNS and must be properly formatted. Use: openssl rsa -in dkim.private -pubout -out dkim.public.
Ensure your signing process uses SHA256. Many older systems default to SHA1. You must configure your mail server or ESP to explicitly sign with rsa-sha256. This is required for modern compatibility and better reputation signals.
Format the DNS TXT record correctly. Combine the selector (e.g., default), your domain, and the public key with proper wrapping. Example: default._domainkey.example.com IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC...". Include no extra spaces or line breaks.
Verify your ESP supports SHA256. Not all providers default to it. Check your ESP’s documentation or settings. Some require manual enrollment or API calls to enable stronger algorithms.
1. Test by querying your DNS record using MxToolbox or the dig command: dig TXT default._domainkey.example.com. Confirm the output matches your published key.

Why proper configuration matters

Using SHA256 strengthens your email reputation. Email providers like Gmail prioritize messages that use modern signing methods. Older algorithms like SHA1 are deprecated and may trigger extra scrutiny.

As outlined in RFC 6376, DKIM signatures must use a verified hash algorithm. SHA256 is the current industry standard for reliability and performance. Misconfigured keys or weak algorithms can limit inbox placement.

Even if your key is technically valid, improper DNS publishing breaks verification entirely. Always validate visibility before sending large volumes.

Proper DKIM configuration is not about hype — it's about being recognized as a trusted sender over time.

When in doubt, test your setup with real email traffic using inbox placement tools. You can test deliverability with MailTester’s inbox placement tester, which simulates real-world delivery conditions across major providers.

Common DKIM Misconfigurations That Break Gmail Delivery

You're sending with DKIM but Gmail still marks your messages as unverified or rejects them? It’s likely due to one of these five common setup errors: using SHA1 instead of SHA256, mispublishing the public key, overlapping DNS records, failing to update the selector after rotation, or using a too-short key. Each can break authentication, even if the rest of your setup looks correct. Let’s fix them.

Signature Algorithm and Key Length

Using SHA1 in the DKIM-Signature header is deprecated. Gmail now requires SHA256 for modern compatibility. If your signing tool defaults to SHA1, update it — SHA1 signatures are no longer trusted.
Keys shorter than 2048 bits are considered weak. Gmail and other major providers favor 2048-bit or higher. A 1024-bit key may pass validation but will not meet long-term deliverability standards.

Selector, Domain, and DNS Alignment

Publishing the DKIM public key under the wrong selector (e.g., using default when your system expects mail) invalidates the signature. The selector must exactly match what’s in the signature header.
Using a key published under a subdomain like dkim.example.com instead of .example.com breaks alignment. Your DKIM record must reside at selector._domainkey.example.com.
Running multiple senders on the same domain with overlapping or conflicting DKIM records causes signature mismatches. Each sender needs a unique selector and distinct key.
Rotating keys without updating the selector leads to failed validation. If you change keys but keep the same selector, Gmail will not find the new public key — the signature won’t verify.

These configurations are often overlooked, but they’re critical. Even a single incorrect DNS record can sink your deliverability with Gmail, especially when sending at scale. You can verify DNS records directly using public tools like MxToolbox or RFC 6376, which outlines DKIM specification requirements.

Before sending, always test your email flow. Use MailTester’s inbox placement tool to validate real-world delivery and DKIM alignment across major inboxes, including Gmail’s. It shows not just if your message arrives, but if authentication checks pass — without guesswork.

How to Verify That Your DKIM Setup Is Working

You can confirm your DKIM setup is working by sending a test email from your domain to a Gmail address, then checking the raw headers for a valid DKIM-Signature header with the correct algorithm=rsa-sha256, matching d= and s= values, and ensuring your DNS TXT record includes the correct public key. Once verified, use tools like MailTester’s real-time API to test consistency across multiple recipients.

Test Your DKIM Signature with a Real Email

Send a test email from your domain (e.g., [email protected]) to a Gmail address.
Open the email in Gmail, click the three-dot menu, and select "Show original" to view the raw headers.
Look for a DKIM-Signature header. It should include algorithm=rsa-sha256 — this confirms Gmail-compatible signing.
Check that the d=yourdomain.com field matches your sending domain exactly, and s=yourselector matches the selector you used in DNS.

Validate DNS and Key Alignment

Use a DNS lookup tool like MXToolbox or DNSChecker.org to verify your TXT record for yourselector._domainkey.yourdomain.com.
Ensure the public key in the TXT record matches the one used to sign the email — a mismatch breaks alignment.
Double-check that the selector (e.g., google, default, or a custom name) is correct and consistent across your email system and DNS.
Confirm that the d= domain in the signature is the same as your sending domain (not a subdomain or alternate domain).

Even if one test passes, DKIM can fail silently for some recipients due to DNS timing, caching, or inconsistent alignment. Let’s go further.

The 4 steps described in “Test Your DKIM Signature with a Real Email”, in order.

Use MailTester’s real-time verification API to validate DKIM alignment across multiple inboxes, including Gmail and other major providers. The API checks the full email envelope and header structure, confirming the signature is recognized, the algorithm is correct, and the domain alignment is properly enforced.

If DKIM is misconfigured, even a single incorrect character in the public key or a mismatched selector can cause rejection — no exceptions.

Keep your keys current. If you’re generating new DKIM keys, never disable old ones until the new one is fully validated. Some email providers still accept old signatures for a grace period, but relying on legacy keys increases risk.

What Happens If Your DKIM Uses SHA1 Instead of SHA256?

If your DKIM signatures rely on SHA1, Gmail may reject or flag your emails as suspicious, especially if other authentication signals are inconsistent. This can lead to delivery failures, poor inbox placement, and long-term damage to your sender reputation. Even a single failed DKIM check can trigger stricter filtering or rate-limiting, particularly when SPF or DMARC are weak or missing.

Why SHA1 Is No Longer Trusted by Gmail

Gmail enforces strong cryptographic standards, and SHA1 is considered outdated and insecure since it’s been shown to be vulnerable to collision attacks. Google requires SHA256 for DKIM signatures in new or updated configurations, especially for high-volume senders. Using SHA1 may result in DKIM verification failure, meaning your message is treated as unverified — even if SPF passes.

When DKIM fails, Gmail looks at the full authentication stack. If SPF or DMARC are also misconfigured or missing, the likelihood of your email being rejected outright or sent to spam increases. These systems work together, so one weak link can compromise the whole chain.

Long-Term Impact on Sender Reputation

Repeated DKIM failures — even if isolated — signal inconsistent sending behavior to Gmail’s filters. Over time, this harms your sender reputation. You may see declining open rates, reduced inbox placement, or even temporary suspension of sending privileges from Gmail’s inbound system.

Some senders report that a single failed DKIM check after upgrading to SHA256 caused their volume to be throttled. This isn’t random: Gmail applies increasing scrutiny when it detects weak or changing authentication practices, particularly around high-risk domains or frequent policy shifts.

You can test your DKIM configuration using tools like MxToolbox or the DMARC.org troubleshooting guides. Always verify that your DKIM signatures use SHA256 and are aligned with your domain. If you’re using a third-party service, confirm they support SHA256 signing and don’t default to SHA1.

If you're building or managing a sending infrastructure, consider validating your entire email stack — including SPF, DKIM, and DMARC — before sending at scale. For example, you can check if your domain’s public keys are correctly published and aligned with your sending practices via our email checker, which evaluates both syntax and deliverability risks.

How MailTester Helps Prevent DKIM Failures

DKIM mismatches can cause Gmail to block your emails, even if the sender domain is legitimate. MailTester identifies these issues early by testing inbox placement and verifying authentication health across your list. Its real-time API, bulk checks, and AI-powered diagnostics catch problems before they hurt deliverability. You’re not guessing — you’re fixing with confidence.

Proactive DKIM Detection Across Your Email List

Use bulk email verification to scan entire lists and detect domains with missing or weak DKIM signatures — a common root cause of Gmail rejections.
MailTester’s inbox-placement testing simulates real sending to Gmail and other providers, flagging DKIM mismatches that would otherwise lead to silent delivery failures.
Check individual addresses with the real-time API, which returns detailed authentication health reports, including SPF, DKIM, and DMARC status.
If DNS records are misconfigured, the in-app AI assistant can parse raw email headers and DNS data to help you isolate whether the issue lies in DKIM key alignment or a malformed signature.
With 98.9% accuracy, MailTester minimizes false positives — you won’t mistakenly mark valid domains as invalid due to imperfect detection, preserving your sender reputation.

How This Actually Works in Practice

Let’s say your campaign bounces in Gmail despite correct sender setup. The problem might not be your mail server — it could be that your DKIM key isn’t properly aligned with your domain’s public DNS records. Tools like MailTester don’t just flag invalid addresses; they validate the full authentication chain.

For example, when you test an address via the email checker, you get a breakdown that says "DKIM: Mismatch — key not found in DNS" or "Valid, but signature uses deprecated SHA-1." That’s actionable intel, not noise.

According to the DKIM standard (RFC 6376), signatures must align with published keys. MailTester ensures your implementation follows this — including validating that new keys use SHA-256, which is now required for strong authentication in Gmail and other modern systems.

Best Practices for DKIM Management and Rotation

You should rotate DKIM keys every 6–12 months to reduce exposure if a key is compromised. Keep old keys for a transition period, use a consistent selector naming convention like selector=2026q1, test new keys before disabling old ones, and never reuse keys across unrelated domains. This reduces risk and ensures your domain remains trusted.

Key Rotation and Recovery

Rotate your DKIM keys at least once per year. The longer a key remains active, the higher the chance of exposure or accidental compromise.
Always retain the previous key for at least two weeks after deployment. This prevents delivery failures during transition and allows you to roll back if issues arise.
Use a predictable selector naming pattern, such as 2026q1 for Q1 2026, to track key versions and simplify audits or troubleshooting.
Test the new key’s alignment and signature validity using real email sends or deliverability checkers before retiring the old one.

Security and Configuration Discipline

Do not use the same DKIM key across multiple domains or subdomains unless your infrastructure explicitly requires it. Each domain should have its own key pair.
Never expose private keys to third parties. Store them securely, preferably in a dedicated key management system or encrypted vault.
Use SHA-256 as the digest algorithm. It’s required for Gmail’s strict verification standards and ensures compatibility with modern email providers.
Regularly audit your DNS records to confirm only active keys are published. Remove outdated entries to prevent confusion or accidental misuse.
Monitor for unexpected authentication failures or high bounce rates post-rotation. These can signal key misconfiguration or delivery issues.

For organizations managing large-scale email systems, consistent DKIM hygiene improves trust metrics and reduces the risk of inbox placement issues. The practice aligns with industry standards like those from RFC 6376, which underpins email authentication.

If you’re validating email addresses before sending—especially in bulk—using tools like MailTester can help identify invalid or high-risk addresses early. Test new configurations in a controlled environment before rolling them into production.

For real-time verification of sender reliability and deliverability testing, explore how our inbox placement tester evaluates your email's path to the inbox. This complements DKIM setup by revealing issues that could affect delivery regardless of authentication.

Why SHA256 Is the Only Viable Choice for Modern Email Delivery

You must use SHA256 when generating new DKIM keys for Gmail and other major inboxes—SHA1 is no longer trusted, and systems like Google’s mail stack now reject messages signed with weaker algorithms. Even if SPF and DMARC are perfectly configured, failing on DKIM’s cryptographic strength will result in delivery failure. This isn't about preference; it's about compliance with established security standards.

SHA1 Is Fundamentally Broken for Email Authentication

SHA1 has been cryptographically compromised since 2017, when researchers demonstrated practical collision attacks. Any system relying on it for digital signatures—like DKIM—is vulnerable to forgery. Major email providers know this and have phased out support. The Internet Engineering Task Force (IETF) has officially deprecated SHA1 in protocols where integrity matters, including email authentication (RFC 6665 and RFC 8355).

Gmail, Yahoo, and Outlook Enforce SHA256 Today

Google’s Gmail system uses strict DKIM verification, and it requires SHA256 for messages to pass. Yahoo Mail and Microsoft Outlook follow the same standard. If your DKIM signature uses SHA1 or other weak hashing algorithms, your messages may be rejected outright—even if they come from a domain with correct SPF and DMARC policies. In practice, this means a well-configured email infrastructure still risks blocking if it uses outdated cryptographic methods.

It’s not enough to be “mostly right.” Modern inboxes treat authentication as a binary pass/fail system. Even a single failing verification—like using SHA1—triggers a rejection. This is especially true for high-volume senders or those targeting consumers, where inbox placement is critical. You’re not just protecting your reputation—you’re ensuring your email reaches the intended user.

Future-proofing your email infrastructure means rejecting old standards. Legacy compatibility with SHA1 is no longer a goal; it’s a vulnerability. By adopting SHA256, you align with industry-wide security best practices, protect your sender reputation, and maintain high deliverability across all major platforms. If you’re using older tools or manual processes to generate DKIM keys, now is the time to update your workflow.

To ensure your email setup remains compliant, test your DKIM signatures with a tool like inbox placement testing or run a real-time verification of your sending domain using MailTester’s DKIM verification check.

How to Ensure Your ESP Supports SHA256 DKIM Signing

Check your ESP’s documentation and settings to confirm they support SHA256-based DKIM signing. Gmail requires SHA256 for modern digital signatures, and using older algorithms like SHA1 can result in rejected or unauthenticated emails. If your ESP doesn't support it, you may need to switch to a provider that meets current standards.

Review your ESP’s official documentation for any mention of DKIM signing algorithms. Look for sections labeled “email authentication,” “DNS records,” or “SPF/DKIM/DMARC.” Providers like SendGrid, Mailgun, and Amazon SES document algorithm support in their setup guides. If SHA256 isn’t listed, it’s likely not available.
Check your dashboard interface for options to select the signing algorithm during DKIM configuration. Some platforms let you choose between SHA1 and SHA256 in the DKIM key setup flow. If no selection exists, the system defaults to SHA1 or doesn’t allow modern signing.
Test with a known valid domain using MailTester’s inbox-placement test. This simulates how Gmail receives and processes your messages. You can run a test at MailTester’s inbox placement checker to see if your DKIM signature passes Gmail’s validation. A failed test may point to signature misconfiguration or unsupported algorithms.
Contact your ESP’s support team directly and ask: “Do you support SHA256 DKIM signing with Gmail-compliant formatting?” Be specific. Many providers still default to SHA1, even if they claim to support DKIM. If they cannot confirm SHA256 support, it’s a red flag.
Consider switching ESPs if SHA256 is not supported. Modern email delivery depends on proper authentication. Providers that don’t support SHA256 may not meet Gmail’s evolving standards, increasing the risk of delivery failures or spam filtering. You’ll get more reliable inbox placement with a compliant system.

Why It Matters: The Gmail Standard

Gmail enforces stricter authentication practices. According to RFC 6376, which defines DKIM, SHA256 is the recommended hashing algorithm for signing. While SHA1 is still technically supported, Gmail increasingly flags messages signed with weaker algorithms as low trust. This impacts delivery and inbox placement.

Don’t assume your ESP handles this automatically. Even if they claim "DKIM support," you need to ensure it’s SHA256. If your current setup uses SHA1, and you’re seeing high bounce rates or low inbox delivery, verify your setup with tools like MailTester’s inbox placement tester. It’s a direct, real-world check of how your messages are received by Gmail.

Final Checklist Before Going Live with New DKIM Keys

Generating a 2048-bit RSA key pair with SHA256 ensures compatibility with modern email providers, including Gmail. This is the foundation of a secure and trusted DKIM implementation.

Verification Steps

Published the DNS TXT record with the correct public key and verified it resolves as expected.
Confirmed that outbound emails include the DKIM-Signature header with the algorithm set to rsa-sha256.
Used MailTester’s inbox-placement test to validate delivery and spam placement with Gmail in real-world conditions.
Documented the key rotation process and tested a rollback procedure to restore the old key if issues arise.

Each step above reduces risk and ensures continuity during and after the transition. Skipping any of these can lead to delivery failures or degraded sender reputation.

Sources

After Gmail began requiring authentication for large senders, the number of unauthenticated messages Gmail users received plummeted by 75%. — Google (The Keyword blog) (2023)
Google reported 265 billion fewer unauthenticated messages sent to Gmail users in 2024 — a 65% reduction — after its bulk-sender rules took effect, with 500,000+ top domains publishing DMARC records in response. — Google (via MailOver bulk-sender requirements guide) (2024)

Keep reading

Ready to put this into practice? MailTester verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

Does Gmail still accept SHA1 for DKIM?

No. Gmail requires SHA256 for DKIM verification and no longer supports SHA1 for new messages.

Can I use multiple DKIM keys on the same domain?

Yes, but only if each key has a unique selector. Multiple keys must be published as separate DNS TXT records.

How often should I rotate my DKIM keys?

Every 6 to 12 months is recommended to reduce exposure risk while balancing manageability.

What is the minimum key length for DKIM?

2048 bits is the minimum recommended key length for strong cryptographic security.

How do I know if my DKIM signing algorithm is SHA256?

Check the DKIM-Signature header in a delivered email. It should include 'a=rsa-sha256'.

Can DKIM still fail even if the key is correct?

Yes. DKIM can fail due to incorrect header canonicalization, misconfigured selectors, expired keys, or missing DNS records.

Why is my email marked as spam even with valid DKIM?

DKIM must be paired with SPF and DMARC. If any of these fail, Gmail may still reject or flag the message.

Does MailTester verify DKIM alignment?

Yes. MailTester’s real-time verification API and inbox-placement tests assess DKIM integrity and alignment with SPF and DMARC.

Are disposable email domains affected by DKIM requirements?

Disposal domains generally don't use DKIM. However, sending to them is discouraged for deliverability and list hygiene.

How can I test DKIM without sending an email?

Use MailTester’s inbox-placement testing or analyze raw headers from existing messages to check DKIM signature and DNS record status.

Can I use SHA256 with non-Gmail providers?

Yes. SHA256 is the industry standard. Most modern mail providers, including Yahoo and Outlook, require or prefer it.

What happens if I publish the wrong DKIM public key?

DKIM validation will fail. Gmail and other providers will treat the email as unverified, increasing the likelihood of spam filtering or rejection.