Why is DKIM key rotation critical for Microsoft 365 senders?

You send emails from a Microsoft 365 domain. They're authenticated. They're delivered. Then, one day, they start vanishing into spam folders—or worse, bouncing. No new messages appear to have been sent. What went wrong? The DKIM key has expired.

Digital signatures are the backbone of email trust. DKIM keys validate that your emails truly came from your domain. In Microsoft 365, the system uses two selectors—selector1 and selector2—to maintain continuity during key rotation. Skipping proper rotation means breaking that chain, damaging your sender reputation, and increasing the risk of rejection by major inboxes.

Without a structured rotation plan, even a single expired key can disrupt email flow. Properly managing selector1 and selector2 ensures that no email loses authentication during the switch. This isn't optional. It’s how consistent deliverability survives.

Key takeaways

  • DKIM keys must be rotated before expiration to maintain email deliverability in Microsoft 365.
  • Using both selector1 and selector2 allows for seamless key transitions during rotation without email failure.
  • Failure to rotate keys can result in inbox placement drops, increased spam filtering, and reputational harm.

What exactly does 'selector1 selector2 rotation' mean in M365?

Microsoft 365 uses two DNS selectors—selector1 and selector2—to safely rotate DKIM signing keys without breaking email authentication. While selector1 signs outgoing messages, selector2 acts as a backup during key changes, ensuring continuous signing and trust. This dual-key approach prevents email failures during updates, which is critical for maintaining sender reputation.

How the rotation process works step-by-step

  1. Publish the new DKIM key under selector2 while keeping selector1 active. This allows both keys to be validated by email receivers, ensuring no gap in message signing.
  2. Verify the new key works by sending test emails and checking delivery. Use tools like inbox placement testing to confirm authentication passes and messages land in inboxes.
  3. Wait for the transition window—usually 7–14 days—to let all receiving systems update their cache of the new key. This minimizes the risk of rejection due to outdated records.
  4. Deactivate selector1 once you’re confident selector2 is widely recognized. The old key remains in DNS for a time to accommodate any lagging receivers.
  5. Reassign selector2 as the primary by removing selector1 entirely after the full transition period. This completes the rotation smoothly.

Why this method prevents delivery issues

Without multiple selectors, rotating DKIM keys would cause temporary signature failures. A single key update could lead to rejected emails, especially by strict providers like Gmail or Yahoo. Microsoft’s use of selector1 and selector2 avoids this by allowing overlapping validation—emails signed with either key are accepted during migration.

According to the DKIM specification (RFC 6376), using multiple selectors is an industry-standard practice for maintaining continuity during cryptographic updates. This approach aligns with best practices for email authentication, ensuring systems can adapt without disrupting delivery.

While the process is handled through the Microsoft 365 admin center, many teams miss the timing and validity checks. Verifying your DNS records and test emails before and after rotation reduces risk. You can check if your configured keys are valid and properly published with MailTester’s email checker, which validates DKIM setup and detects common misconfigurations.

How does DKIM rotation affect inbox placement and deliverability?

DKIM key rotation using selector1 and selector2 ensures uninterrupted authentication by allowing a smooth transition between old and new keys. Without proper rotation, receiving servers may reject emails due to signature validation failures, which harms sender reputation and increases inbox filtering. Maintaining continuous authentication helps preserve consistent inbox placement.

Why unrotated DKIM keys harm deliverability

If you keep the same DKIM key indefinitely without rotation, you increase the risk of key compromise. And if you rotate keys incorrectly—say, by removing the old one before the new one is fully validated—receiving servers may fail to verify signatures. This leads to authentication failures on both current and future emails, even if the content is harmless.

Repeated failures like these are tracked by mailbox providers. Tools like Microsoft’s Smart Network Data Services (SNDS) monitor sender behavior and correlate poor authentication with spam-like patterns. When the same domain shows consistent signature issues, inbox placement can drop sharply. Some providers may start routing messages to junk folders or outright blocking them after a threshold of failures.

How selector1 and selector2 prevent delivery issues

Using two selectors—selector1 and selector2—lets you run old and new keys in parallel during the transition. For example, you can configure selector1 with today’s key and selector2 with the new one. Receiving servers check both keys, so messages remain valid during the switch. Once the new key is fully trusted, you can disable the old one safely.

This approach is an industry-standard practice and is recommended in RFC 6376, the foundational document for DKIM. It’s designed to avoid service interruptions while maintaining security. Many large senders, especially those using Microsoft 365, rely on this dual-key method to prevent delivery disruption during routine key updates.

Proper key rotation isn’t just about security—it’s about consistency. A smooth transition preserves sender reputation. You can validate this by testing your setup with tools like inbox placement testing, which simulates how real inboxes will treat your messages. If your DKIM is mismatched or expired, the test will flag it early.

Let’s make it real: if you’re sending thousands of emails via Microsoft 365 and haven’t tested your DKIM alignment recently, you’re likely exposing your messages to unnecessary filtering. Verify your setup with a tool that checks for alignment, key expiration, and delivery consistency. Run a bulk verification to catch problems before they harm your reputation.

What happens if you skip selector2 during rotation?

If you skip selector2 during DKIM key rotation in Microsoft 365, email messages sent during the transition period may fail validation because receiving servers check for the correct signature using the published selector. If the new key isn’t active before the old one is removed, messages may appear unsigned or use a revoked key, triggering rejection by strict filters. This leads to delivery failures, increased bounce rates, and can damage sender reputation over time.

The Risks of Skipping selector2

  • You risk message rejection during the transition window, even if both keys are technically valid, because some receivers perform strict DKIM signature checks and reject messages with missing or expired selectors.
  • Receiving servers that enforce multi-layer authentication (like SPF, DKIM, DMARC) may block messages if the DKIM signature is missing or invalid, especially if the DNS record no longer references the current key.
  • If mail flow continues with only the new key (selector2) and selector1 is removed prematurely, messages from older systems or delay-based delivery engines might still use the old key, causing signature mismatches.
  • Some organizations that use custom or third-party gateways may not rotate keys in sync, meaning they could fail DKIM checks even if your setup is correct — a mismatch in selector management across systems amplifies impact.
  • MailTester’s email checker can verify whether a recipient address is valid and capable of receiving authenticated mail, helping you test how a new configuration behaves before rollout.

Best Practices for Safe Rotation

  • Always keep both selectors (selector1 and selector2) active during the transition — Microsoft 365 supports multiple active keys via DKIM record updates.
  • Test your new DKIM record with tools like MxToolbox or Spamhaus’s DKIM guide to confirm DNS propagation and correct signature alignment.
  • Monitor bounce rates and authentication failures in your reporting tools during rotation — spikes often signal DKIM misconfiguration.
  • Use a phased rollout: introduce selector2 first, run it in parallel, confirm delivery, then deprecate selector1 over a 3–5 day period.
  • Verify that your email sending system supports multiple active keys and that headers are correctly signed — a common oversight in managed senders.

How to prepare your domain’s DNS for DKIM key rotation

You need to ensure your DNS provider allows TXT record updates, access to the Microsoft 365 admin center, backup your current DKIM keys (selector1 and selector2), and verify DNS propagation after changes using tools like mxtoolbox.com. These steps prevent email delivery failures during key rotation.

Check your DNS and admin access

  • Confirm your DNS hosting provider lets you add or update TXT records in real time. Most major providers (like Cloudflare, AWS Route 53, Google Cloud DNS) support this natively.
  • Log into the Microsoft 365 admin center at admin.microsoft.com to access your domain’s email settings. You’ll need a Global Administrator or Mailbox Administrator role.
  • Before making changes, export your current DKIM public keys for selector1 and selector2. Save them in a secure location. This is a safety net if you need to revert or troubleshoot.

Verify DNS changes post-update

  • After updating TXT records, check propagation using tools such as mxtoolbox.com or the command-line dig txt yourdomain.com. Propagation can take minutes to hours depending on your TTL settings.
  • Wait at least 5 minutes after saving DNS changes before testing. Some systems cache DNS responses for up to 1 hour or more.
  • If your domain uses multiple email senders or shared infrastructure, ensure all relevant DKIM selectors are correctly aligned with their public keys. Mismatched or missing keys result in DMARC failures.
  • Monitor email deliverability logs afterward. A successful rotation should not impact message delivery — but monitoring confirms it.
DKIM failure can lead to mail rejection or inbox filtering, even with a valid SPF and DMARC policy. Proper DNS configuration is non-negotiable.

Remember: changing DKIM keys without ensuring DNS records are correct breaks authentication. This can cause legitimate mail to be flagged as spam or blocked entirely. When in doubt, test the setup with a real email address before fully rotating keys in production.

To validate the broader health of your email infrastructure, you can use inbox placement tests that simulate how your messages arrive in real inboxes, identifying any lingering deliverability issues before they impact your campaign results.

What role does MailTester play in verifying DKIM rotations?

MailTester ensures your DKIM key rotation in Microsoft 365 works across real email environments. Its real-time API checks whether emails signed with new keys pass validation, while inbox placement tests confirm deliverability to Gmail, Outlook, and Yahoo. Bulk verification confirms existing subscribers remain valid after changes. With 98.9% accuracy, it catches issues before they hit your campaigns.

Testing DKIM signing success post-rotation

After rotating your DKIM keys in Microsoft 365, you need to confirm that outbound emails still pass cryptographic validation. MailTester’s real-time verification API checks this in seconds. It simulates sending an email using your new key, validates the signature against the DNS record, and returns a definitive result.

Unlike simple DNS lookups, MailTester confirms whether the signing key actually works in practice. This prevents silent failures where a record appears correct but fails due to misconfiguration, incorrect selector alignment, or expired key material. The process is repeatable and traceable, letting you validate each change before going live.

Validating deliverability across inbox providers

Even with correct DKIM, deliverability depends on how receivers interpret your signals. A new DKIM key might be technically valid but trigger filtering if it's associated with inconsistent sending behavior. MailTester runs inbox placement tests across Gmail, Outlook, and Yahoo, showing you whether messages land in the inbox or get quarantined.

These tests reflect real-world conditions. You're not just checking a single SMTP response—you're mimicking a live campaign. The results include detailed reports on header headers, spam score estimates, and any warnings related to authentication. This lets you adjust your setup before a large send.

For teams managing large lists, MailTester’s bulk verification lets you confirm that existing subscribers’ addresses remain valid after your configuration change. No outdated or invalid addresses slip through due to key rotation side effects.

Real DKIM rotation failures often go unnoticed until deliverability declines. MailTester gives you the confidence to update keys without disrupting sending. You can access the verification API for on-demand checks here, or run inbox placement tests before your next email campaign here. For a complete verification workflow, including bulk list validation, head to our bulk verifier. The accuracy of 98.9% reflects real-world performance across thousands of test runs, meaning you catch problems before they impact your sender reputation. You can read more about email authentication standards from RFC 6376.

Common pitfalls to avoid during DKIM key rotation in M365

You must rotate DKIM keys in Microsoft 365 one selector at a time, allowing full DNS propagation and real-world testing before deactivating the old key. Skipping steps like waiting for DNS to settle or using the same key across both selectors breaks email authentication and risks deliverability. Always test post-rotation in actual inboxes to confirm alignment.

Don't rush the transition

  • Remove selector1 only after selector2 is fully active and emails are successfully authenticated. Premature removal leaves outbound messages unverified, risking rejection by receiving servers.
  • Wait at least 24–48 hours after updating DNS records before deactivating the old key. DNS propagation times vary; skipping this window increases the risk of message failures during the overlap period.
  • Using the same key for both selector1 and selector2 defeats the purpose of redundancy. It creates a single point of failure. Each selector should use a unique key to maintain alignment with the standard practice outlined in RFC 6376.

Test, then verify in production

  • Failing to send test emails to real inboxes after rotation is a common oversight. Authentication checks in tools often pass, but real-world mail servers may still reject messages if the DNS or key settings are misaligned.
  • Use a tool like MailTester’s inbox placement tester to verify delivery across major email providers. This confirms that your DKIM configuration is recognized and trusted in live environments. Test your messages in real inboxes before sending to your full list.
  • Monitor your bounce and spam reports after rotation. A sudden spike can signal a misconfigured DKIM record or a failed key transition. Let’s not treat this like a one-off setup — it’s ongoing maintainability.

Microsoft’s documentation notes that misconfigured DKIM can trigger message rejection with no clear error, making validation essential. The best way to avoid issues is to treat this not as a one-time act, but as a testable event. Microsoft’s official guide covers key setup, but it doesn’t walk through real-world failure points. That’s where your process matters.

How to test DKIM key functionality after rotation

After rotating your DKIM keys in Microsoft 365, send a test email from your domain using MailTester’s inbox-placement testing to verify both signatures appear in the headers. Check that selector1 and selector2 are both correctly published in DNS during transition, and monitor bounce reports and spam complaints for disruptions. This confirms your emails remain authenticated and trusted by recipient servers.

  1. Send a test email via MailTester’s inbox-placement tester to validate that messages sent from your domain now carry a valid DKIM signature. This tools simulates real-world delivery to major inboxes, letting you confirm that authenticated messages land in the inbox, not spam.
  2. Inspect the email headers of the received message to verify the DKIM-Signature field contains both selector1 and selector2 entries. This confirms Microsoft 365 is signing with both keys during the transition phase. Misconfigurations here often result in failed authentication and poor deliverability.
  3. Check DNS records for both selectors using tools like MxToolbox or dnscheck.org to ensure both selector1._domainkey.yourdomain.com and selector2._domainkey.yourdomain.com are present and correctly configured. Remove old keys only after confirming both new keys are active and delivering.
  4. Monitor post-send metrics over 48–72 hours for increases in hard bounces, spam complaints, or delivery delays. A spike in any of these indicates that signature mismatches or misconfigurations are affecting how mail servers handle your messages.

Why double-checking both selectors matters

Many email providers, including Gmail and Outlook, validate both keys during key transitions to prevent sudden drops in deliverability. If one selector is missing or malformed in DNS, recipients may reject your messages or mark them as spam. This is especially critical during a switch where old keys are phased out but new ones are still being trusted.

Use real traffic data to confirm success

Let’s not rely on test sends alone. Monitor your sending domain’s reputation using Spamhaus or AbuseIPDB. If your domain’s IP or sending behavior shows no new blocklist alerts after rotation, that’s a strong signal the transition worked. MailTester’s inbox-placement testing gives you a controlled way to catch issues early before they impact your real campaigns.

Why you should never skip DNS propagation checks before deactivating keys

You must verify DNS propagation before deactivating old DKIM keys like selector1 in Microsoft 365, even if your new selector2 is correctly set up. DNS changes can take up to 48 hours to spread globally, and if you disable selector1 too soon, receiving servers may not find any valid signature—leading to delivery failures, even with perfect configuration. Always confirm propagation using tools like MXToolbox or dig before finalizing the change.

Propagation delays are not optional

Every DNS change, even a single TXT record update, can take time to reach all global resolvers. Delays aren’t rare—they’re expected. Microsoft 365’s DKIM key rotation relies entirely on this propagation. If selector1 is disabled before selector2 is fully visible worldwide, messages will fail signature validation. This doesn’t mean your setup is broken—it means the keys are temporarily unavailable to the receiving server during the transition window.

How to check propagation reliably

Use command-line tools like dig or online checkers such as MXToolbox DNS Lookup to query your domain’s TXT records from multiple geographic locations. Look for both the old selector1 and new selector2 keys. If either is missing on one of the test sites, propagation isn’t complete. Be skeptical of “instant” updates—routers and caches don’t update on demand. Waiting for full consistency prevents unnecessary message drops.

Even with a flawless configuration, cutting the old key too early results in temporary bounces. These often appear as temporary failures (5xx SMTP responses), but they’re not due to policy or spam—just missing keys during the transition. Once propagation finishes, deliveries resume normally. That’s why it’s better to wait, verify, then deactivate.

Consider using an email verification service like MailTester’s real-time email checker to test individual addresses before sending. If you're rotating keys across a large list, bulk list verification can help identify dead or malformed addresses in advance, reducing the risk of delivery failure during the transition.

How integrations with Mailchimp, SendGrid, or Klaviyo help during rotation

You can maintain consistent email delivery during DKIM key rotation with Microsoft 365 by using Mailchimp, SendGrid, or Klaviyo—provided your domain’s authentication policies remain stable. These platforms depend on your domain’s DNS records, including DKIM selectors like selector1 and selector2. If the DKIM signature fails during rotation, they treat it as a temporary authentication issue, which can trigger throttling or delays in sending.

Authentication stability is critical across platforms

When you rotate DKIM keys, the old selector must remain valid until all outgoing messages from the old key have been delivered. During this overlap, both selector1 and selector2 must be correctly published in DNS. If a platform like SendGrid or Mailchimp tries to send using an expired selector, the message fails SPF/DKIM checks. This often leads to temporary rejections, reduced sender reputation, and delayed delivery.

Mailchimp and Klaviyo, like other trusted ESPs, monitor authentication signals closely. They don’t retry indefinitely on a failed DKIM check—instead, they may pause sending from affected domains or routes until authentication is restored. This is why it’s essential to verify that both selectors are active and properly recorded in DNS during the transition window.

Real-time verification reduces delivery risk

MailTester’s integration with these platforms lets you test sender addresses in real time before sending. This confirms whether a given email address is valid, has a working inbox, and passes authentication checks—including those tied to your current DKIM configuration. Using our bulk verification tool, you can proactively clear out invalid or problematic addresses while DKIM is in transition.

If delivery issues arise during or after rotation, the in-app AI assistant can analyze raw headers and signature data to pinpoint whether the failure is due to misconfigured DKIM, a missing DNS record, or a temporary bounce. It doesn’t guess—it cross-checks your DNS records against observed behavior and flag inconsistencies in real time.

For example, if a message from SendGrid fails delivery, MailTester can identify whether the failure is due to an expired selector or a server-side block. This helps you act faster than relying on vague error messages. DKIM’s RFC 6376 stresses the importance of overlapping key periods during rotation to avoid disruptions—which is exactly what these integrations with MailTester help you manage.

Summary: Keep your mail flow stable with proper DKIM rotation

During DKIM key rotation in Microsoft 365, always use selector1 and selector2 in succession. This ensures uninterrupted authentication while transitioning keys.

Maintain overlapping key validity in DNS until propagation is confirmed. A gap in valid keys can cause message failures, even with correct configuration.

Test every stage

  • Use MailTester’s real-time API to validate individual addresses during the transition.
  • Run bulk verification on your list to catch any newly invalid addresses before sending.
  • Perform inbox placement tests post-rotation to confirm delivery success across inboxes.

Plan for stability

Coordinate key changes during low-volume periods to minimize risk. Monitor delivery metrics closely after rollout to detect any anomalies early.

Sources

Keep reading

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

Frequently asked questions

Can I use only selector1 for DKIM in Microsoft 365?

No. Microsoft 365 expects both selector1 and selector2 to be configured during rotation. Relying solely on one selector increases risk of delivery failure during transitions.

How long should I keep both DKIM keys active during rotation?

Keep both active for at least 7 days after DNS propagation to ensure no email is lost during the shift. Monitor delivery metrics before deactivating the old key.

What happens if my DKIM key isn’t rotated?

Your emails may be rejected by receiving servers after key expiration. This harms sender reputation and reduces inbox placement. Microsoft 365 does not enforce rotation automatically.

Can MailTester detect DKIM signature failures?

Yes. MailTester’s inbox-placement testing and real-time API verify whether DKIM signatures are valid and accepted by major email providers.

Is there a risk of spoofing if DKIM rotation isn’t done properly?

Yes. Misconfigured or expired DKIM keys weaken email authentication, making your domain vulnerable to spoofing and abuse.

Do I need to rotate DKIM keys manually in M365?

Yes. Microsoft 365 does not rotate keys automatically. You must manually update the keys and manage selector1 and selector2 in the admin center.

How often should I rotate DKIM keys?

Microsoft recommends rotating DKIM keys at least every 365 days. Some organizations rotate every 180 days for enhanced security.

Can I use a third-party tool like MailTester for DKIM testing?

Yes. MailTester supports inbox-placement testing and real-time verification, which confirm whether DKIM signing works across major email services.

What’s the best way to verify DKIM records after update?

Use a DNS lookup tool like mxtoolbox.com to check TXT records. Also test email delivery using MailTester’s inbox-placement feature.

Do I need both SPF and DKIM for deliverability?

Yes. SPF and DKIM together are foundational for sender reputation. Missing either increases likelihood of spam filtering and delivery failure.

Why does Microsoft 365 use two selectors?

Selector1 and selector2 allow smooth transitions during key updates. One remains active while the other is tested, reducing risk of delivery disruption.

Can I use MailTester with SendGrid and M365 together?

Yes. MailTester integrates with SendGrid, Mailchimp, Klaviyo, and HubSpot. It verifies addresses and tests inbox placement regardless of the email platform used.