SPF Validation Error

The sending-domain administrator must use the exact code in the non-delivery report to correct SPF and related authentication; Microsoft Q&A does not provide a private email address for submitting message content.

Identify and fix the rejection

Open the bounce message—also called an NDR—and locate Diagnostic information for administrators, then follow the matching branch:

• 550 5.7.515 Access denied...does not meet the required authentication level
  This applies to domains sending at least 5,000 messages per day to Microsoft consumer services such as Outlook.com, Hotmail, Live.com, and MSN. The administrator must:
  1. Publish SPF and authorize every actual sending service or server.
  2. Enable DKIM signing for the From domain.
  3. Publish DMARC, initially with a valid policy such as v=DMARC1; p=none.
  4. Ensure SPF or DKIM aligns with the domain shown in the visible 5322.From address.
  Microsoft requires both SPF and DKIM to pass for these high-volume senders, as well as DMARC validation and alignment.^1^
• 550 5.7.23 or “Sender Policy Framework violation”
  The sending-domain administrator should verify the public SPF record, add any omitted on-premises sending IPs, and check whether Microsoft 365 routed the message through the High Risk Delivery Pool.^2^
• SPF result none, softfail, fail, permerror, or temperror
  • none: no SPF record exists.
  • softfail or fail: the sending IP is not authorized.
  • permerror: commonly multiple SPF records or more than 10 DNS lookups.
  • temperror: a temporary authoritative-DNS failure or timeout.
    These results and their corresponding checks are documented in Microsoft’s authentication troubleshooting table.^3^

There must be only one SPF TXT record per domain or subdomain, no more than 10 DNS lookups, and Microsoft recommends a TTL of at least 3,600 seconds.^4^

Do not replace an existing SPF record with an example blindly. If Microsoft 365 is the only sender, the documented form is:

Name:  @
Type:  TXT
Value: v=spf1 include:spf.protection.outlook.com -all

If a website, CRM, bulk-mail platform, on-premises server, or other service also sends mail, its authorized source must be merged into the same SPF record.^5^

If mail passes through a third-party gateway

If the NDR is 5.7.367 and mail is forwarded or relayed through a non-Microsoft gateway such as Proofpoint or Barracuda, configure Enhanced Filtering for Connectors. Without it, Exchange Online can evaluate SPF against the gateway address rather than the original sending address.^6^

Submit the full NDR securely

Remove personal message content when posting publicly. Preserve these technical fields:

• Complete SMTP error code and text
• Sending domain and sending IP
• Timestamp and time zone
• Authentication-Results
• Return-Path
• From
• DKIM d= domain
• Relevant message or correlation identifiers

For delivery specifically to @outlook.com, @hotmail.com, @live.com, or @msn.com, use the Outlook.com Sender Support troubleshooting form linked under Sender services, tools, and issue submission. It is the supported escalation route after authentication and sending-policy checks pass.^7^

For Microsoft 365 business mail, an administrator should open Microsoft 365 admin center → Help & Support → New service request and attach the original NDR there. Email support is available only to organizations licensed for Business Assist, through its documented Business Assist address; it is not a general Outlook support mailbox.^8^

References

1. Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support
2. Fix NDR error "550 5.7.23" in Exchange Online
3. Troubleshoot email authentication in Microsoft 365
4. Set up SPF to identify valid email sources for your custom cloud domains
5. External Domain Name System records for Microsoft 365
6. Forwarded or relayed email messages from Microsoft 365 are rejected with error 5.7.367
7. Sender Support in Outlook.com | Microsoft Support
8. Business Assist for Microsoft 365