550 5.7.515 — Outlook rejected your email

What does 550 5.7.515 mean?

Microsoft returns this error when a message from a high-volume sending domain doesn't meet their authentication requirements. The full rejection string is:

550; 5.7.515 Access denied, sending domain [your-domain.com]
does not meet the required authentication level.

Microsoft announced these requirements for high-volume senders to Outlook.com consumer mailboxes (Outlook.com, Hotmail.com, Live.com). The published requirements say that domains sending more than 5,000 messages per day must comply with SPF, DKIM, and DMARC:

• SPF must pass for the sending domain, and the domain's SPF record must accurately list all authorized sending IPs.
• DKIM must pass for the sending domain.
• DMARC must be published with at least p=none, aligned with either SPF or DKIM.

Microsoft said non-compliant mail would first go to Junk, then updated its rollout plan and stated that messages failing the requirements would be rejected with 550 5.7.515 starting May 5, 2025.

DMARCit monitors authentication results across all receiving providers — so you can see whether a sender that passes at Gmail is also passing at Outlook.

Why did this happen?

Cause 1: You don't have a DMARC record published

This is the simplest trigger. Microsoft requires a DMARC record — even p=none counts. If your domain has no _dmarc TXT record at all, high-volume messages to Outlook.com addresses get rejected.

Cause 2: SPF or DKIM isn't passing for this sender

Microsoft's published requirements for high-volume senders say SPF must pass and DKIM must pass, in addition to publishing DMARC. A sender that passes DKIM but fails SPF may satisfy DMARC's own logic (which requires only one to pass and align), but may still not meet Microsoft's stated requirements.

This distinction catches organizations that rely on DKIM-only alignment for third-party senders. If the sender's SPF include isn't in your record (or you've hit the 10-lookup limit), SPF fails even though DMARC might still pass via DKIM.

Cause 3: DKIM is configured but not for your domain

Your sending platform may be DKIM-signing with its own default domain rather than yours. DKIM passes for the platform, but Microsoft's check requires it to pass for your sending domain.

This is the same alignment issue behind Gmail's 550 5.7.26, but Microsoft's error message is less explicit about the cause, which makes it harder to diagnose from the bounce alone.

Cause 4: You're under the volume threshold on most days, but spikes push you over

The 5,000 messages/day threshold means some domains only hit this error on high-send days — a monthly newsletter, a seasonal campaign, a batch of invoices. The error appears intermittently, which makes it harder to diagnose. Authentication needs to be correct all the time, not just on high-volume days.

Note: Microsoft's filtering stack can make troubleshooting feel less transparent than Gmail, so checking real authentication results in message headers is especially important for Outlook-bound mail.

How to fix 550 5.7.515

Step 1: Publish a DMARC record if you don't have one

If your domain has no DMARC record, add one:

_dmarc.yourdomain.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"

This satisfies Microsoft's minimum requirement and starts sending you aggregate reports so you can see what's passing and failing.

Step 2: Verify SPF passes for the affected sender

Check that the sending source's IP is covered by your SPF record. Remember that Microsoft's requirements say SPF must pass — not just DKIM. If your SPF record is over the 10-lookup limit, SPF fails for everything. → See: SPF PermError — Too many DNS lookups.

Step 3: Verify DKIM passes and is signed with your domain

Check that the sending platform is DKIM-signing with your domain (the d= value in the DKIM-Signature header should match or align with your From: domain). If DKIM is signed with the platform's default domain, configure custom DKIM. → See: What is DKIM?

Step 4: Confirm DMARC alignment

Both SPF and DKIM should pass, and at least one should align with your From: domain. Check your Authentication-Results headers for:

spf=pass; dkim=pass; dmarc=pass

If you see dmarc=fail despite SPF and DKIM passing, you have an alignment problem.

This isn't a one-time fix

Email authentication tends to break again because:

• Microsoft's enforcement is new and may evolve. The May 2025 enforcement is the first phase. Microsoft may tighten requirements further — following the pattern Gmail set by starting with p=none and gradually raising expectations. Organizations that meet the minimum today may need to do more later.
• Volume thresholds create intermittent failures. If your domain hovers around 5,000 messages/day, you'll only see this error on high-send days. That makes it easy to miss the pattern and hard to reproduce during troubleshooting.
• Third-party senders need ongoing attention. Every new SaaS tool that sends as your domain needs SPF, DKIM, and DMARC alignment configured. Marketing platforms, ticketing systems, billing tools — each one is a potential authentication gap that only shows up when volume spikes push you over the threshold.
• Authentication that works at Gmail doesn't guarantee it works at Outlook. Microsoft's requirements specify that both SPF and DKIM must pass. A sender that passes DMARC at Gmail via DKIM-only alignment can still trigger 5.7.515 at Outlook if SPF fails.

Monitoring authentication results across providers — not just one — is the only way to catch these gaps before they cause rejections.