Microsoft rejects email lacking DMARC records without prior notice

On Friday morning, November 7, 2026, administrators noticed a sudden spike in rejected emails sent to Microsoft-run domains like hotmail.com and outlook.com. The rejection message cited missing authentication records, specifically pointing to the absence of DMARC policies despite valid SPF and DKIM configurations. This unannounced change has disrupted communication for numerous self-hosted email servers and small businesses relying on standard DNS setups.

What happened

The issue was first identified by Mythic Beasts, a hosting provider, after their logs showed over 500 rejections on Thursday that had not occurred previously. The error code returned by Microsoft’s servers was 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records. Crucially, the rejected messages possessed fully valid Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) records. The only missing component was a Domain-based Message Authentication, Reporting, and Conformance (DMARC) record in the domain’s DNS zone.

To test a fix, the team added a DMARC record with a policy set to "none" for several affected domains. This policy tells receiving servers that the domain owner has no specific instruction for handling unauthenticated mail, effectively acting as if no policy exists. Once this record was published, Microsoft’s servers accepted the emails again. A broader survey across the Fediverse confirmed that other independent operators were experiencing identical failures, indicating a widespread change in Microsoft’s inbound mail filtering logic rather than an isolated configuration error.

Initially, the lack of announcement led to speculation that this might be a deliberate tightening of security standards. Last year, Microsoft had introduced a requirement for domains sending more than 5,000 messages per day to publish a DMARC record, but that change was communicated well in advance. This recent shift appeared to apply to all senders regardless of volume and without warning. An update to the original report later clarified that the change was likely unintentional, yet Microsoft had not yet determined how to roll back the configuration error.

Key details

• Error message: Rejected emails return 550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records.
• Affected services: Mail delivery to hotmail.com and outlook.com is impacted.
• Root cause: Absence of a DMARC DNS record, even when SPF and DKIM are correctly configured.
• Temporary fix: Publishing a DMARC record with a p=none policy restores deliverability.
• Scope: The change appears to affect all senders, not just high-volume ones exceeding 5,000 daily messages.
• Status: Microsoft has not issued an official statement or rollback timeline, though internal sources suggest the change was accidental.

Background

Email authentication relies on three main protocols to prevent spoofing and phishing. SPF lists the IP addresses authorized to send email for a domain. DKIM adds a digital signature to each message, allowing the receiver to verify it hasn’t been altered in transit. DMARC builds on these two by specifying what the receiving server should do if a message fails SPF or DKIM checks. Policies can be set to "none" (monitor only), "quarantine" (send to spam), or "reject" (block entirely).

While DMARC is a best practice for security, many small self-hosted setups omit it because it requires careful monitoring to ensure legitimate mail isn’t accidentally blocked. Historically, major providers have phased in DMARC requirements gradually, often starting with high-volume senders. The sudden enforcement of DMARC presence, even with a passive "none" policy, represents a significant shift in how inbound filters validate sender identity. It moves DMARC from a recommended security enhancement to a mandatory structural requirement for basic delivery.

Why it matters

For teams running their own software or managing self-hosted email, this incident highlights the fragility of relying on external platforms with opaque operational changes. Without prior notice, critical business communications can vanish into black holes, with no immediate way to diagnose the issue unless one closely monitors bounce logs. The fact that valid SPF and DKIM were insufficient underscores that compliance requirements are evolving faster than many small operators can track.

Furthermore, the inability to contact Microsoft for support exacerbates the problem. Small IT leads and developers must rely on community forums and trial-and-error debugging to resolve delivery issues. This increases the operational burden on small teams who may not have dedicated email deliverability experts. It also serves as a reminder that "set and forget" DNS configurations are risky when major recipients change their validation logic unexpectedly.

What you can do

• Check your DNS: Verify if your domain has a DMARC record using online lookup tools or command-line utilities like dig.
• Add a temporary record: If missing, add a TXT record for _dmarc.yourdomain.com with the value v=DMARC1; p=none; to restore immediate deliverability.
• Monitor bounce logs: Review your mail server logs for 550 5.7.1 errors to identify any missed messages from the past few days.
• Validate existing records: Ensure your SPF and DKIM records are still valid and aligned with your current mail infrastructure.
• Communicate with users: If you know clients using Microsoft emails, inform them of potential delays and ask them to check spam folders.
• Plan for stricter policies: Once deliverability is restored, consider moving from p=none to p=quarantine or p=reject after verifying all legitimate sources pass authentication.