Outlook Sender Requirements: What High-Volume Senders Must Do to Avoid Filtering and Rejection

Microsoft stepped into the bulk sender enforcement arena in 2025, joining Google and Yahoo in requiring strict email authentication for high-volume senders. Starting May 5, 2025, senders who deliver 5,000 or more emails per day to Microsoft's consumer email domains must have valid SPF, DKIM, and DMARC records in place. Messages that fail these checks are now rejected outright.

This guide covers exactly what Microsoft requires, how enforcement works, what you need to configure, and how to verify your compliance.

Who Is Affected?

The requirements apply to any sending domain that transmits 5,000 or more emails per day to addresses on Microsoft's consumer email services. The affected domains include:

• outlook.com
• hotmail.com
• live.com
• msn.com

These requirements do not currently apply to email sent to Microsoft 365 business or enterprise accounts (Exchange Online). However, Microsoft has signaled that similar standards may extend to business domains in the future, and enterprise Microsoft 365 administrators already have the ability to enforce strict authentication policies on their tenants independently.

Authentication Requirements

Microsoft's three mandatory authentication requirements are the same protocols that Google and Yahoo began enforcing in early 2024. Here is what each requires for compliance:

SPF (Sender Policy Framework)

Your sending domain must have a valid SPF record published in DNS that accurately lists all IP addresses and hosts authorized to send email on your behalf. The SPF check must pass for your sending domain, meaning the mail server's IP must be included in the SPF record for the domain used in the envelope sender (Return-Path).

Use our SPF checker to verify your record. Common issues that cause SPF failures include missing third-party sender IPs (your ESP, CRM, marketing automation platform), exceeding the 10 DNS lookup limit, and stale records that reference decommissioned infrastructure.

DKIM (DomainKeys Identified Mail)

DKIM must be configured and passing for your sending domain. This means your outbound emails must carry a valid DKIM signature that can be verified by the recipient's mail server using the public key published in your DNS.

Most ESPs handle DKIM signing automatically once you complete their domain authentication setup, which typically involves adding one or more CNAME or TXT records to your DNS. Verify your configuration with our DKIM checker.

DMARC (Domain-based Message Authentication, Reporting and Conformance)

A valid DMARC record must be published for your sending domain with a minimum policy of p=none. The DMARC record must align with either SPF or DKIM (preferably both), meaning the domain used in the visible "From" header must match the domain that passes SPF or DKIM checks.

A minimal compliant DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

While p=none is the minimum for compliance, Microsoft and all major mailbox providers recommend moving toward p=quarantine or p=reject for stronger protection. Our DMARC checker and DMARC generator can help you verify your existing record or create a new one.

Enforcement Timeline

Microsoft rolled out enforcement in phases:

The rejection message for non-compliant senders is:

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

This is a permanent failure (hard bounce), meaning the recipient's server will not retry delivery. If you are seeing this error in your bounce logs, your domain is failing one or more of the authentication requirements above.

Additional Best Practices Microsoft Recommends

Beyond the three mandatory authentication protocols, Microsoft's announcement includes several strongly recommended practices. While these are not yet enforced through automated rejection, Microsoft explicitly states that it reserves the right to filter or block senders who do not follow them, especially for "critical breaches of authentication or hygiene."

Valid, Compliant Sender Addresses

Your "From" and "Reply-To" addresses must be valid, reflect the true sending domain, and be capable of receiving replies. While using a "noreply@" address is technically permitted, Microsoft recommends that the domain behind it is fully authenticated and that the address resolves to a real mailbox. Senders that use unresolvable or deceptive From addresses risk additional filtering.

Functional Unsubscribe Links

Marketing and bulk email must include a clearly visible, easy-to-use unsubscribe mechanism. This aligns with the one-click unsubscribe requirement that Google and Yahoo enforced in 2024 via the List-Unsubscribe header.

Microsoft specifically calls out that unsubscribe links must be functional, not buried in small text, and that opt-out requests must be honored promptly. For implementation details, see our guide on List-Unsubscribe and one-click unsubscribe.

List Hygiene and Bounce Management

Senders must remove invalid addresses regularly to reduce spam complaints, bounces, and wasted messages. Microsoft monitors bounce rates and complaint rates as signals of list quality. High bounce rates suggest that a sender is emailing stale or unverified addresses, which correlates strongly with spam trap hits and poor deliverability outcomes.

Best practices include removing hard bounces immediately after they occur, monitoring soft bounces and removing addresses that persistently fail, running periodic email verification on your list, and implementing a sunset policy for unengaged subscribers.

Transparent Mailing Practices

Use accurate subject lines that reflect the content of your email. Do not use deceptive headers. Ensure that all recipients have provided consent to receive your messages. These requirements echo the principles of CAN-SPAM and GDPR compliance, and Microsoft expects senders to follow them regardless of geographic jurisdiction.

How to Verify Your Compliance

Before assuming you are compliant, actively verify each requirement. Here is a checklist:

1. Check SPF: Use our SPF checker to verify your record is valid, includes all authorized senders, and stays within the 10-lookup limit.
2. Check DKIM: Use our DKIM checker to confirm that your DKIM signatures are being applied correctly and that the public key in DNS is accessible.
3. Check DMARC: Use our DMARC checker to verify that your DMARC record exists, has at least p=none, and shows proper alignment with SPF or DKIM.
4. Review bounce logs: Search your bounce logs for the error string "5.7.515" to identify any messages that have already been rejected by Microsoft due to non-compliance.
5. Send test emails: Send test messages to Outlook.com and Hotmail.com addresses and inspect the full headers to confirm that SPF, DKIM, and DMARC are all passing with alignment.
6. Monitor DMARC reports: If you have a rua address configured, review your DMARC aggregate reports for any sources failing authentication. These reports reveal third-party senders using your domain without proper setup.

What About Third-Party Senders and ESPs?

If you use one or more third-party services to send email on your behalf (marketing automation platforms, CRM systems, transactional email providers), each one must be properly authenticated under your domain. This means:

• Each ESP's sending IPs or include mechanism must be listed in your SPF record.
• Each ESP must sign emails with DKIM using your domain (not theirs).
• Your DMARC record must be published and receiving reports so you can identify any source that is sending on your behalf without proper alignment.

Most major ESPs provide documentation on how to set up custom domain authentication. If you are using multiple sending services, SPF can become complex quickly. Review our guide on fixing SPF lookup limits if you are approaching or exceeding the 10-lookup ceiling.

How Outlook Requirements Compare to Gmail and Yahoo

Microsoft's requirements closely mirror what Google and Yahoo began enforcing in February 2024. Here is a comparison:

What to Do If You Are Not Yet Compliant

If you are currently seeing "5.7.515" bounce codes from Microsoft, or if you have not yet implemented all three authentication protocols, follow this priority order:

1. Publish a DMARC record immediately. Even a minimal v=DMARC1; p=none; rua=mailto:reports@yourdomain.com record satisfies the requirement and starts generating reports.
2. Verify SPF is passing. Check that your SPF record includes all legitimate sending sources and is syntactically valid. Fix any lookup limit issues.
3. Verify DKIM is passing and aligned. Ensure your ESP is signing with your domain and that the DNS public key records are correct.
4. Test with real messages. Send to Outlook.com addresses and verify authentication results in the headers. Look for spf=pass, dkim=pass, and dmarc=pass.
5. Address list hygiene. Remove addresses that have bounced, suppress complaints, and verify any segments you have not mailed recently before resuming sends to Microsoft domains.

For a complete walkthrough of the authentication setup process, see our email authentication guide.

Frequently Asked Questions