Email messages from a safe sender abruptly stopped being received - sender getting error (blocked) message

The sender’s email administrator or hosting provider must correct the sending domain’s SPF, DKIM, and DMARC authentication; adding the address or domain to Outlook.com Safe Senders cannot override this rejection because it occurs before the message reaches your mailbox.^1^

What to send your client

Forward the complete non-delivery report (NDR)—not only the quoted line—and ask the client to give it to whoever manages their domain or outgoing email service. Their administrator should:

1. Identify the actual sending service and From domain shown in the NDR.
2. Check SPF:
   • Exactly one SPF TXT record exists.
   • It authorizes every server or third-party service that sends mail for the domain.
   • It does not exceed the 10-DNS-lookup limit.
3. Check DKIM:
   • Outgoing messages are DKIM-signed.
   • The DNS selector exists and matches the signing key.
4. Check DMARC and alignment:
   • A valid DMARC TXT record exists.
   • Either SPF or DKIM passes and aligns with the visible From-address domain.
5. Check gateways and third-party services that might change messages after signing or send using a different envelope domain.

Microsoft documents missing records, unauthorized sending sources, DKIM failures, and domain misalignment as authentication conditions that can cause rejection, including 550 5.7.1 responses.^2^

The administrator should not copy a generic SPF or DMARC value without accounting for the client’s actual mail provider. Incorrect DNS records can disrupt delivery from other authorized systems.

Why Safe Senders did not help

Safe Senders controls how messages already accepted by Outlook.com are handled—for example, directing accepted mail to the Inbox rather than Junk.^3^ In this case, Outlook.com rejected the SMTP transaction, so there is no message in your mailbox for that setting to act on.

You also do not need to add SPF, DKIM, or DMARC records for your personal @hotmail.com or @outlook.com receiving address. Microsoft manages the Outlook.com domain; the records implicated by this error belong to the sender’s domain.^1^

Was this a sudden Outlook.com change?

Multiple reports using the exact AS9031519 wording appeared around November 6, 2026, but the available Microsoft Q&A reports do not establish an officially announced policy change for every sender.^4^

Microsoft does officially impose stricter requirements on high-volume domains sending at least 5,000 messages to Microsoft consumer services: SPF and DKIM must pass, a DMARC record must be published, and DMARC alignment must pass.^5^ That rule applies only if the sender meets the documented volume threshold; the NDR alone does not prove that your client does.

If authentication is already correct

After the sender’s administrator verifies that SPF, DKIM, DMARC, and alignment all pass:

• The sender should submit the complete NDR and sending details through Outlook.com Sender Support. Microsoft provides its sender issue-submission path for compliant mail that still has Outlook.com delivery problems.^6^
• If several unrelated, properly authenticated senders are producing the same rejection, sign in to Outlook.com and select Help → Still need help? → Yes, then provide the complete NDRs, including timestamps and the AS9031519 reference.^7^
• For urgent communication, ask the client to use another properly authenticated sending address while their administrator investigates.

References

1. Incoming emails being blocked due to lack of SPF/DKIM/DMARC records on my @outlook.com account - Microsoft Q&A
2. Troubleshoot email authentication in Microsoft 365
3. Help protect your Outlook.com email account | Microsoft Support
4. 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records
5. Fix NDR error "550 5.7.515" in Outlook.com | Microsoft Support
6. Sender Support in Outlook.com | Microsoft Support
7. Can't send or receive email in Outlook.com | Microsoft Support