How to fix - hotmail-com.olc.protection.outlook.com. (52.101.41.123, the server for the domain hotmail.com.).

If the message’s From address ends in @gmail.com, submit the complete bounce to Outlook.com Sender Support because Google—not the Gmail user—controls the gmail.com authentication records.

The response identifies the actual rejection:

550 5.7.1 Message rejected:
Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

This is not a problem with the displayed 52.101.x.x address; that is the Outlook.com server which rejected the message.

For a standard @gmail.com sender

1. Open Outlook.com’s Sender Support troubleshooting form.
2. Report that mail from a standard @gmail.com address is rejected for multiple Outlook.com/Hotmail recipients.
3. Include:
   • The complete SMTP rejection shown above.
   • AS9031519.
   • The Outlook.com server name, timestamp, and message/correlation value from the bounce.
   • Confirmation that multiple Microsoft consumer addresses are affected.
4. Remove sender and recipient addresses, subject lines, and message content before posting the report publicly.
5. Retain the original bounce because support may need its full headers.

Microsoft provides this route when mail complies with sender requirements but delivery problems to Outlook.com, Hotmail, Live, or MSN remain unresolved.^1^

Also report the bounce through Gmail’s support or feedback channel. A normal Gmail user cannot add SPF, DKIM, or DMARC records to gmail.com; changing Outlook Safe Senders or Contacts is unlikely to help because the message is rejected before it reaches the recipient mailbox.^2^

If Gmail is sending from a custom domain

If Gmail displays an address such as [Email]—including a Google Workspace account or Gmail Send mail as alias—the domain owner or mail administrator must fix authentication:

1. Check the failed message’s From, Return-Path, and Authentication-Results headers.
2. Publish one valid SPF TXT record authorizing every service that sends for the domain.
3. Enable DKIM signing in the sending service and publish its required DNS key.
4. Publish a valid DMARC TXT record.
5. Ensure either the SPF envelope domain or DKIM signing domain aligns with the visible From domain so DMARC passes.
6. Check any forwarding gateway, mailing service, CRM, or relay that could alter the message or send through an unauthorized path.

Microsoft documents that simultaneous SPF/DKIM failures prevent DMARC from passing and recommends fixing SPF, then DKIM, then verifying DMARC alignment.^3^ Outlook.com’s documented authentication requirements also call for SPF and DKIM records, a DMARC record, and alignment with the visible From domain for applicable high-volume senders.^4^

Do not copy a generic SPF value into DNS: the correct record depends on every system authorized to send for that custom domain.

References

1. Sender Support in Outlook.com - support.microsoft.com
2. Incoming emails being blocked due to lack of SPF/DKIM/DMARC records on my @outlook.com account - Microsoft Q&A
3. Troubleshoot email authentication in Microsoft 365
4. Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support