An integrated threat protection solution designed to detect, investigate, and respond to cyber threats across Microsoft 365 services.
AS9031519 normally means Microsoft rejected the incoming message because the sender’s domain lacks or fails SPF, DKIM, or DMARC authentication; the sender or their email administrator must correct those records rather than changing your Outlook app settings.^1^
What to do
- Obtain the complete bounce message from an affected sender.
Look for the SMTP status immediately beforeAS9031519, particularly:-
550 5.7.23: the sending domain’s SPF record is missing or misconfigured. -
550 5.7.1: rejection can involve incomplete SPF, connector configuration, or destination security policy.^2^
-
- Ask the sender’s email administrator to validate the domain shown in the message’s
From:address:- SPF: There must be one SPF TXT record, and it must authorize every service that sends mail for the domain. Multiple SPF records, more than 10 DNS lookups, or an omitted third-party sender can cause failure.
- DKIM: Outgoing messages must be signed, and the selector’s public DNS record must match the signing key.
- DMARC: A DMARC record must exist, and either SPF or DKIM must both pass and align with the domain in the visible
From:address.
- If only one organization’s messages bounce, that organization should correct its authentication and then send a new test message. Forwarding services, mailing lists, gateways, and transport rules can modify messages or break SPF/DKIM alignment, so they must also be included in the investigation.
If multiple unrelated senders started failing simultaneously
Recent matching reports describe AS9031519 rejections affecting Outlook.com or Microsoft-hosted recipients even where administrators believed authentication was already configured.^1^ Do not assume an incident until the full headers show spf=pass, dkim=pass, and dmarc=pass with correct alignment.
If those results all pass:
- Have your Microsoft 365 administrator open the Microsoft 365 admin center and check Health → Service health.
- Run the NDR diagnostic using the complete error text. The diagnostic requires an administrator account and is unavailable for Microsoft 365 Government, 21Vianet, and Microsoft 365 Germany.^3^
- If no incident appears, open a Microsoft 365 support request and attach:
- The complete NDR
- Message headers
- Sender and recipient domains
- UTC timestamp
- Microsoft server/request identifiers shown beside
AS9031519
If the bounced messages were not actually sent to you—or you are receiving NDRs for messages nobody recognizes—check Sent Items. They may be backscatter caused by a forged sender address rather than failed incoming mail.^4^
References