DKIM pass, bounce anyway? Outlook's new mystery rejection

Word is coming in that Outlook is bouncing authenticated emails, and the ‘why’ is a bit of a mystery. Here’s our take after diving into the logs, reports, and talking the ears of our industry peers.

In March 2025, Microsoft announced new sender requirements for Outlook, Hotmail, and Live.com inboxes. This is in line with new sender requirements that we saw Gmail and Yahoo release in 2024. We immediately covered Microsoft’s changes on our blog, and made them the focus of the second episode of Deliverability Academy.As seasoned deliverability veterans, we were prepared for some growing pains, and we expected that some senders might start seeing rejections due to stricter authentication requirements, but this error feels unexpected to senders. Here’s our take.

Over the past few weeks, a rising number of Mailgun customers (and industry peers across other ESPs) have encountered bounce messages like this:

550 5.7.515 Access denied, sending domain DOMAIN.TLD doesn't meet the required authentication level. The sender's domain in the 5322.From address doesn't meet the authentication requirements defined for the sender.

These errors often show:

• SPF = Pass
• DKIM = Fail (but falsely!)
• DMARC = Pass

In short: DKIM appears to pass in one place (like Gmail or your DMARC reports) but fails at Microsoft. And when it fails, Outlook blocks the message, even if it meets standard DMARC policy of p=none.

We don’t have a complete answer yet, but here’s what we’ve learned so far, both from our own data and broader industry collaboration:

Some messages bounce; others don’t, even with identical headers and content. Previously unaffected domains might suddenly start failing.

If you’re seeing 550 5.7.515 errors start by confirming your authentication setup

• SPF: Must include Mailgun IPs and stay under the 10-lookup limit.
• DKIM: Check that your DKIM TXT record is correctly published in DNS (preferably as a single-line value) and matches the selector used by Mailgun for signing.
• DMARC: Valid policy (p=none/quarantine/reject) aligned with SPF or DKIM.

Messages pass DKIM at Gmail and Yahoo but fail at Microsoft. Our working theory is that Microsoft is applying additional checks prior to delivery (breaking DKIM) or interpreting alignment more strictly than DMARC requires.

How to fix: Check alignment

• Microsoft may be enforcing strict alignment, even if DMARC allows relaxed.
• If you’re seeing persistent bounces, contact our support team to explore signing directly with your root domain (e.g., example.com). While Mailgun typically uses a subdomain for DKIM, strict alignment with the From domain may improve deliverability to Microsoft.

Emails with these factors seem more likely to be rejected:

• Non-ASCII characters (like accents or emojis)
• MIME-encoded headers (Subject or From)

Older DKIM keys, especially those last rotated before March 2025, seem more vulnerable. Newer keys show fewer failures.

How to fix: Consider DKIM key rotation

Even the strongest keys have a shelf life. If a DKIM key gets exposed, it can open the door to spoofing, spam, and replay attacks that piggyback off your good reputation. That’s bad news for your brand, and for anyone else sending from the same IP.

To reduce the risk, it’s best practice to rotate your DKIM keys every 6–12 months. If you’re using Mailgun’s Automatic Sender Security, congrats! We’ve got this covered. But if you manage your own DNS or use a custom sending domain, it’s up to you to schedule regular key updates.

• Consider rotating any DKIM keys older than 6–12 months.
• Wait for DNS to propagate, then retest.

If a DKIM signature references headers that are missing from the actual message (e.g., MessageID:), it can invalidate the signature.

How to fix: Look at the headers you can access

You won’t be able to view full headers from a message that Microsoft rejects, but you can still get clues elsewhere. Review the headers of a successfully delivered message from a different provider to spot potential header or encoding issues like:

• Non-ASCII characters (like emojis or accents) in Subject or From
• MIME encoding that might be interpreted differently by Outlook
• Which headers were signed via DKIM vs. which ones were actually included in the message
• Differences in DKIM signature alignment (e.g., subdomain vs. root domain)

Roughly 1.8% of Microsoft-related bounces in our data from May–June 2025 stem from authentication issues – mostly Hotmail. High-volume senders may be more exposed, either due to message complexity or just scale.

How to fix: Make sure you’re monitoring your authentication

Use DMARC Reports like Red Sift or similar tools to see where failures are happening, and what IPs/domains are affected and review the sender guidelines in detail. Gmail and Yahoo have very specific thresholds but Microsoft’s approach reminds us that Inbox providers are looking at several behavioral factors, not just technical ones.

Since regular key rotation is a best practice, give yours a quick review. If you rotate manually and your current key predates May 2025, it may be time for a refresh. Even valid keys can be rejected if Microsoft is filtering based on adherence to best practices; a new one may help alleviate these false failures.

Microsoft may be applying stricter alignment logic than DMARC requires, and not always in predictable ways. Even if you’re signing with your root domain and using a subdomain in your From: address (or vice versa), rejections may still occur.

It’s a good idea to check alignment, but don’t assume simpler is better. If you’re unsure whether your current DKIM setup is strict or relaxed, or want to explore adjustments, our support team can help review your domain configuration.

Avoid emojis, accented characters, or unnecessarily complex MIME-encoding in your From: or Subject: fields. If you’re troubleshooting rejections, test with a stripped-down message to rule out encoding-related surprises.

Use DMARC aggregate reports (via tools like Red Sift) to keep an eye on alignment issues, unauthorized senders, and shifting bounce trends—especially at Outlook, Hotmail, and Live domains.

Mailgun already dual-signs messages for many customers, typically using both a platform domain and the customer’s subdomain. In theory, this should meet the highest standard for authentication. However, based on industry chatter and what we’ve seen, Microsoft may be evaluating only one of the signatures (and not always the one that passes alignment).

We’re actively researching whether Microsoft is misapplying DKIM evaluation logic in dual-signed messages, and if so, what patterns or configurations increase risk.

What should my domain structure look like?

Avoid unnecessarily complex subdomain configurations (e.g., send13.mailgun.example.com) unless critical to your setup. Overly specific or inconsistent subdomains may increase the chance of alignment confusion or DNS resolution hiccups.

What do my clients need to know?

If you’re an ESP or agency working on behalf of senders, help your customers:

• Understand DKIM alignment
• Avoid risky content and headers
• Regularly review DNS and rotate keys

We’re not just watching, we’re working:

• Ongoing Monitoring: We’re tracking bounce trends across all Microsoft-bound traffic.
• Industry Collaboration: We’re talking with other ESPs and providers to pool insights and build pressure for Microsoft transparency.
• Customer Support: We’re helping users audit their settings and run tests.
• Escalation: We’re compiling data to present to Microsoft and pushing for clarity on these false DKIM failures.

Unfortunately, there’s no guaranteed workaround yet. But here’s what seems to help reduce bounce rates:

• Freshly rotated DKIM keys
• Simpler headers with ASCII-only characters
• Fewer MIME-encoded fields in From: and Subject:

We’re closely monitoring all of the above to determine which changes consistently make a difference.

This issue isn’t limited to Mailgun, or even to ESPs in general, it’s a broader issue stemming from Microsofts evolving filtering behaviors. We’re in the thick of it with the rest of the industry, and we’ll continue to share what we learn.

If you’re a Mailgun customer and need help troubleshooting 550 5.7.515 errors, reach out to our Support team with as much detail as possible: affected domains, bounce messages, and full headers.

We’ll update this post as the situation evolves. Stay tuned and stay authenticated.

Author: Alison Gootee