NewsCSO OnlineFinancePublic sectorSME

    Microsoft’s email security is unexpectedly blocking legitimate business mail

    Share
    Microsoft’s email filters meant to protect users from malicious messages appear to be rejecting legitimate ones. Over the last few days, some mail sent to Microsoft consumer addresses have bounced if they did not publish a domain-based message authentication, reporting, and conformance (DMARC) record. This includes messages to Outlook, Hotmail, Live, and MSN. The refusals began November 5 and are ongoing as of publication time . Microsoft did not announce a policy change and has not published a postmaster notice, service-health entry, or other blog post. The issue may indicate that a policy change and a bug may both be in play, noted Frank Dickson of Dickson Research. “Requiring every sending domain to prove it is who it says it is makes email safer,” he pointed out. “Doing it without notice, with an error message that points at the wrong problem, makes a mess.” Intermittent sending issues DMARC is meant to protect against spoofing, phishing , and business email compromise. Microsoft has had a rule in place since May 2025 requiring DMARC, but only from domains sending more than 5,000 messages a day to consumer mailboxes. But as of November 5, mail from small, ordinary senders, rather than from bulk ones, have been bounced due to lack of DMARC, Sender Policy Framework (SPF), or DomainKeys Identified Mail (DKIM). Senders have been receiving Non-Delivery Reports (NDRs) citing 550 5.7.1 or 550 5.7.23 errors, but are doing so inconsistently; some messages are getting through while others are rejected. For instance, one user reported this error message on Microsoft’s community forum : Your message to @hotmail.com couldn’t be delivered. hotmail.com couldn’t confirm that your message was sent from a trusted location. Another user reported the same problem, adding: “Some emails work fine and others return errors with SPF failed.” Adding to the confusion, some bounced domains were reported to have working SPF, DKIM, and DMARC. A Microsoft external staff moderator called it a “service degradation” currently under active investigation. According to email security company MailRoute , enterprises can determine if their domain is impacted with this command on any terminal (replacing example.com with their domain): dig +short TXT _dmarc.example.com . A response starting with v=DMARC1 means there is a DMARC record; no reply means there isn’t, MailRoute said. The fix is a single TXT record: v=DMARC1 ; p=none . This declares that a domain uses DMARC and asks receivers to send reports, but it tells them to take no action on failures, MailRoute explained. DMARC meant to make impersonation difficult DMARC relies on two foundational email authentication tools that must be active on a domain: SPF and DKIM. SPF verifies whether the sending server’s IP address is allowed to send email on behalf of a domain, while DKIM adds a cryptographic signature to the message to prove it wasn’t altered along the way and actually belongs to the domain it says it is coming from. DMARC checks the two, identifying whether the domain listed on the “from” address aligns with the validated domains. It ties those checks to the name the reader actually sees and tells receivers what to do with forgeries, Dickson explained. “Without it, impersonating your domain is easy,” he said. “That is where a lot of phishing and business email compromise starts.” But because Microsoft, at least to this point, has only required DMARC for larger senders, it is not standard across the board; many small senders reasonably concluded it did not apply to them, Dickson noted. This includes SMBs, nonprofits, schools, and professional practices such as law firms, accountants, and doctors’ offices running on domains that “someone set up years ago, and nobody has touched since.” Larger organizations miss DMARC on secondary domains, regional domains, and the subdomains that their marketing and billing platforms send from for mundane reasons. No one owns the domain name system (DNS), and “people fear breaking legitimate mail sent by third parties,” Dickson said. Quiet, inconsistent failure As MailRoute pointed out, what makes this particular malfunction so dangerous is its inconsistency: The person who sent the message sees a bounce “full of acronyms, assumes a glitch, and moves on.” Meanwhile, the customer never knows a message was sent. It fails quietly, which is “the bane of an email marketer’s existence,” Dickson said. Customers, patients, job applicants, and others use Hotmail, Outlook, Live, and MSN, and when invoices, password resets, appointment confirmations, and offer letters go missing, the customer thinks they’re being ignored, not necessarily that the message is not getting through. The good news is that the failures are findable, he pointed out. Every rejection generated a bounce, and bounces are logged. Enterprises should search mail logs, email platforms’ bounce reports, and help desk tickets for entries citing “ Message lacks SPF/DKIM/DMARC ” since Nov. 5. Then, resend what matters, time-sensitive transactional mail first. From there, fix the cause by confirming that every domain sending mail as you publishes a DMARC record, Dickson advised. If one is missing, a basic monitoring record (p=none) stops these bounces without changing how anyone else treats your mail, as long as SPF or DKIM lines up with the From domain. Microsoft 365 customers who never turned on DKIM for their own domains should do it now, he advised. “Do not rewrite SPF just because the bounce blames it,” he said. If your records are clean and mail still bounces, send the full bounce to Microsoft so it lands in the investigation. However, a p=none record is “first base, not home plate,” he said. The goal is p=reject , which tells receivers to refuse anyone forging your name. Inventory every service that sends email as you, Dickson advised: The CRM, the billing system, the HR platform, and the marketing tools. “Most organizations cannot produce that list,” he noted. “You cannot protect a domain when you do not know who is speaking for it.” A signal of what is to come While it remains to be seen what is causing this glitch, enterprises should make no mistake about where things are heading, Dickson said: DMARC will be enforced for every sender. Google and Yahoo began requiring it of bulk senders in February 2024; Microsoft followed in May 2025. “Requirements start with the big senders and then become the floor for everyone,” he said. “The rollout was botched, but the destination is not in doubt.” But while Microsoft has the destination right, “nobody should learn about a new rule from a bounce message.” Update Nov. 10: On Tuesday, Microsoft issued a statement saying that the issue, related to an update to its spam rules, has been resolved. Users do not need to adjust any settings or take additional action. A Microsoft spokesperson said, “ We’ve resolved an issue that may have prevented some email messages from reaching Outlook.com, Hotmail and Live addresses, and mail flow has been restored. We’re continuing to monitor to help ensure email is delivered as expected. Customers can learn more via EX1545193 in the Microsoft 365 admin center. “ This article originally appeared on Computerworld .

    More on unexpectedly

    Other advisories

    Other news entries

    Source: https://www.csoonline.com/article/4246592/microsofts-email-security-is-unexpectedly-blocking-legitimate-business-mail-2.html

    ID