Since November 5, email operators have reported a puzzling Microsoft Outlook email rejection DMARC pattern: messages sent to Outlook.com, Hotmail, Live.com, and MSN addresses are sometimes rejected because they supposedly lack authentication records—even when the sender can show that SPF and DKIM passed. The recurring bounce cites 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519). That has led administrators to ask whether Microsoft now requires every sending domain to publish DMARC.
The short answer is that publishing DMARC is increasingly important and may resolve some of these rejections, but the reports do not establish a formally announced universal requirement. As of the November 10, 2026 editorial cutoff, Microsoft has not published a definitive announcement saying that DMARC is mandatory for every sender to its consumer mailbox services. Reports also describe intermittent behavior, including successful delivery from the same domains. Administrators should therefore fix genuine authentication gaps without assuming every AS9031519 rejection has one simple cause.
What email operators are reporting
The issue appears to affect Microsoft’s consumer email infrastructure serving Outlook.com, Hotmail.com, Live.com, and MSN.com recipients. Operators have documented messages being accepted by other providers but rejected by Microsoft with the AS9031519 response. One early operator report on Outlook refusing mail without DMARC describes delivery resuming after a DMARC record was added.
The surprising detail is that some affected senders say their SPF and DKIM checks were already passing. In those cases, the wording of the Microsoft 550 5.7.1 error can appear inaccurate. Several explanations are possible: Microsoft may be checking for the presence of all three authentication mechanisms, the visible From domain may not align with the domain authenticated by SPF or DKIM, or different messages may be evaluated differently because of routing, forwarding, DNS visibility, or reputation signals.
These observations concern consumer Outlook services. They should not automatically be treated as a policy change for Microsoft 365 business tenants, where recipient organizations can configure Exchange Online Protection, anti-spam policies, transport rules, and third-party gateways. A rejection from an organization’s custom Microsoft 365 domain may have a different cause from Outlook Hotmail rejecting emails.
Is DMARC now mandatory for Outlook.com delivery?
Not as a confirmed universal policy. The available evidence supports a narrower conclusion: some domains without DMARC have encountered intermittent Outlook.com email delivery problems, and adding a valid DMARC record has reportedly helped in certain cases. It does not prove that every message from every domain without DMARC will be rejected.
That distinction matters. A universal requirement would normally be accompanied by official documentation defining the affected traffic, rollout schedule, enforcement behavior, and remediation process. No such definitive announcement had been published by the editorial cutoff. Microsoft’s error may reflect an unannounced experiment, phased filtering change, implementation defect, stricter treatment of particular traffic, or an existing authentication check interacting with reputation systems.
Nevertheless, DMARC is no longer an optional afterthought for a domain that sends legitimate email. A correctly deployed record gives receiving systems a clear authentication policy and provides reports that can reveal unauthorized or misconfigured senders. Even if Microsoft clarifies that DMARC is not universally required, configuring it safely remains a sound deliverability and security measure.
How SPF, DKIM, and DMARC authentication work together
SPF, DKIM, and DMARC solve related but different problems. Understanding those differences is essential when troubleshooting a rejection that claims all authentication is missing.
Sender Policy Framework uses a DNS TXT record to identify servers permitted to send mail for a domain. The receiving server compares the connecting IP address with the SPF policy for the envelope-from or return-path domain. A basic record might look like:
v=spf1 ip4:192.0.2.10 include:example-mail-provider.com -all
SPF can pass even when the authenticated return-path domain differs from the address users see in the From header. It can also break during forwarding because the forwarding server’s IP may not be authorized by the original sender’s policy.
DKIM authenticates a signed message
DomainKeys Identified Mail adds a cryptographic signature to selected message headers and content. The recipient retrieves the public key from a DNS TXT record at a selector-specific name such as selector1._domainkey.example.com. A valid signature shows that the signed portions were not altered and that a system with access to the private key signed the message.
A DKIM pass alone does not necessarily authenticate the visible From domain. A mailing platform could sign with its own domain rather than the customer’s domain, which is where DMARC alignment becomes important.
DMARC connects authentication to the visible From address
Domain-based Message Authentication, Reporting, and Conformance asks whether SPF or DKIM passed using a domain aligned with the one in the visible From header. At least one aligned mechanism must pass for DMARC to pass. The domain owner publishes a DNS policy telling recipients how to handle failures.
This is why the phrase SPF and DKIM pass does not always settle an authentication dispute. If SPF passes for bounce.vendor.example and DKIM passes for vendor.example, but the visible From address uses company.example, DMARC can still fail. Microsoft’s authentication systems may therefore see insufficient authorization for the domain the message claims to represent.
Microsoft provides a broader explanation of these mechanisms in its email authentication documentation.
How this differs from Microsoft’s bulk-sender requirements
In May 2025, Microsoft introduced stronger authentication requirements for domains sending more than 5,000 messages per day to Outlook.com consumer addresses. Those high-volume senders were expected to use SPF, DKIM, and DMARC, with at least a monitoring policy such as p=none. Noncompliant bulk traffic could be rejected.
The reports emerging in November 2026 are notable because some apparently involve small organizations, self-hosted servers, and other low-volume senders that do not approach that threshold. If accurate, this suggests either broader enforcement in some circumstances or an authentication filter producing unexpected results. It should not yet be described as an officially confirmed extension of the bulk-sender policy.
Practical DNS checks for affected administrators
Begin email server troubleshooting with evidence rather than immediately editing DNS. Save the complete non-delivery report, including the recipient domain, timestamp, sending IP, remote MX hostname, SMTP response, queue ID, and original message ID. Then perform these checks:
- Confirm the exact From and return-path domains. They may look similar while authenticating different organizational domains.
- Query authoritative DNS. Use
dig TXT example.comornslookup -type=TXT example.comto verify SPF. Query_dmarc.example.comfor DMARC and the correctselector._domainkey.example.comname for DKIM. - Check for duplicate records. A domain must not publish multiple SPF records. DMARC should also resolve to one valid policy record.
- Validate SPF processing. Confirm that the actual outbound IP is authorized and that nested
includemechanisms do not exceed SPF’s DNS-lookup limit. - Verify DKIM at the source. Ensure outbound messages contain a DKIM-Signature header, the selector exists, the key has not been removed, and intermediaries are not modifying signed content.
- Test DMARC alignment. Determine whether either the SPF return-path domain or DKIM signing domain aligns with the visible From domain.
- Check DNS propagation and DNSSEC. An administrator’s local resolver may see a record that Microsoft’s resolvers cannot retrieve because of delegation, DNSSEC, truncation, or authoritative-server problems.
- Compare multiple messages. Identify whether failures correlate with a specific outbound server, IPv4 or IPv6 address, DKIM selector, message stream, recipient domain, or forwarding route.
A safe DMARC DNS configuration strategy
A basic monitoring record is published as a TXT record at _dmarc.example.com:
v=DMARC1; p=none; rua=mailto:[email protected]
The p=none policy requests monitoring rather than quarantine or rejection. The rua address receives aggregate XML reports showing which sources send mail using the domain and whether SPF, DKIM, and alignment pass. Ensure the reporting mailbox or analysis service can process these files, and consider their security and privacy implications.
Do not jump directly to p=reject simply to fix Microsoft email deliverability. First inventory legitimate senders, including marketing platforms, support systems, website forms, invoicing applications, scanners, and employee services. Enable aligned DKIM wherever possible and correct return-path configuration where SPF alignment is needed.
After reviewing reports over a representative period, move cautiously to p=quarantine, potentially using the pct tag for limited application. Adopt p=reject only after legitimate sources consistently pass and business owners understand the effect. DMARC DNS configuration protects a domain most effectively when enforcement is based on observed traffic, not guesswork.
Investigating AS9031519 and other Microsoft rejections
The AS9031519 text points toward authentication, but a bounce code should be treated as a diagnostic clue rather than a complete root-cause analysis. Inspect authentication results from successful messages delivered to test accounts. Look for spf=pass, dkim=pass, and dmarc=pass, along with the domains evaluated for each result.
If all three pass and align, investigate reputation and filtering separately. Check whether the sending IP has valid forward and reverse DNS, uses a stable HELO name, accepts bounces correctly, and has been compromised. Sudden volume changes, spam complaints, poor list hygiene, malformed headers, suspicious URLs, or shared-hosting abuse can cause Microsoft filtering even when authentication succeeds.
Intermittent results can also indicate that only one node in an outbound pool is misconfigured. Compare rejected and accepted messages by source IP and DKIM selector. Do not repeatedly retry permanent 550 responses at high frequency; retain logs and use Microsoft’s sender support channels when the evidence shows aligned authentication but rejections continue.
Frequently asked questions
Will adding a p=none DMARC record guarantee Outlook delivery?
No. It may address a missing-record condition and provide useful reporting, but DMARC does not override content filtering, IP or domain reputation, recipient rules, or blocklists. Delivery still depends on the complete message and sender profile.
Why does Microsoft say authentication records are missing when SPF and DKIM pass?
The passing domains may not align with the visible From domain, Microsoft may have encountered a DNS lookup problem, or the rejected message may have traveled through a different server than the tested message. The generic error could also represent several internal checks. Compare the exact domains, source IPs, selectors, and timestamps.
Does this reported behavior apply to Microsoft 365 business mailboxes?
Not necessarily. The current reports focus on Outlook.com consumer infrastructure, including Hotmail, Live.com, and MSN. Microsoft 365 business tenants have organization-specific filtering and routing controls, so their administrators should review Exchange Online traces and policies.
Should every sending domain publish DMARC now?
Yes, as a security and operational best practice, but deployment should be controlled. Begin with valid SPF and DKIM, publish p=none with aggregate reporting, fix alignment, and progress toward quarantine or rejection only after reviewing legitimate traffic.
The cautious conclusion
The recent Microsoft Outlook email rejection DMARC reports deserve attention, especially from low-volume senders who believed the 2025 bulk-sender rules did not affect them. They do not yet prove that Microsoft has made DMARC universally mandatory. Administrators should validate DNS, alignment, and message paths; add DMARC through a measured rollout; and continue examining reputation and filtering factors when authentication passes.
This article should be updated if Microsoft publishes an official explanation, confirms broader enforcement, or identifies AS9031519 as a service issue. Until then, treat the reports as credible operational observations—not a definitive statement of universal Microsoft policy.
