{"id":10366,"date":"2026-11-10T01:57:23","date_gmt":"2026-11-10T01:57:23","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=10366"},"modified":"2026-11-10T01:57:23","modified_gmt":"2026-11-10T01:57:23","slug":"microsofts-email-security-is-unexpectedly-blocking-legitimate-business-mail","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=10366","title":{"rendered":"Microsoft\u2019s email security is unexpectedly blocking legitimate business mail"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Microsoft\u2019s email filters<\/a> meant to protect users from malicious messages appear to be rejecting legitimate ones.<\/p>\n

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.<\/p>\n

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.<\/p>\n

The issue may indicate that a policy change and a bug may both be in play, noted Frank Dickson<\/a> of Dickson Research.<\/p>\n

\u201cRequiring every sending domain to prove it is who it says it is makes email safer,\u201d he pointed out. \u201cDoing it without notice, with an error message that points at the wrong problem, makes a mess.\u201d<\/p>\n

Intermittent sending issues<\/h2>\n

DMARC is meant to protect against spoofing, phishing<\/a>, 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.<\/p>\n

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.<\/p>\n

For instance, one user reported this error message on Microsoft\u2019s community forum<\/a>:<\/p>\n

Your message to @hotmail.com couldn\u2019t be delivered.<\/em>
hotmail.com couldn\u2019t confirm that your message was sent from a trusted location.<\/em><\/p>\n

Another user reported the same problem, adding: \u201cSome emails work fine and others return errors with SPF failed.\u201d Adding to the confusion, some bounced domains were reported to have working SPF, DKIM, and DMARC.<\/p>\n

A Microsoft external staff moderator called it a \u201cservice degradation\u201d currently under active investigation.<\/p>\n

According to email security company MailRoute<\/a>, 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<\/em>. A response starting with v=DMARC1<\/em> means there is a DMARC record; no reply means there isn\u2019t, MailRoute said.<\/p>\n

The fix is a single TXT record: v=DMARC1<\/em>; p=none<\/em>. 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.<\/p>\n

DMARC meant to make impersonation difficult<\/h2>\n

DMARC relies on two foundational email authentication tools<\/a> that must be active on a domain: SPF and DKIM.<\/p>\n

SPF verifies whether the sending server\u2019s 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\u2019t altered along the way and actually belongs to the domain it says it is coming from.<\/p>\n

DMARC checks the two, identifying whether the domain listed on the \u201cfrom\u201d 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.<\/p>\n

\u201cWithout it, impersonating your domain is easy,\u201d he said. \u201cThat is where a lot of phishing and business email compromise starts.\u201d<\/p>\n

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\u2019 offices running on domains that \u201csomeone set up years ago, and nobody has touched since.\u201d<\/p>\n

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 \u201cpeople fear breaking legitimate mail sent by third parties,\u201d Dickson said.<\/p>\n

Quiet, inconsistent failure<\/h2>\n

As MailRoute pointed out, what makes this particular malfunction so dangerous is its inconsistency: The person who sent the message sees a bounce \u201cfull of acronyms, assumes a glitch, and moves on.\u201d Meanwhile, the customer never knows a message was sent.<\/p>\n

It fails quietly, which is \u201cthe bane of an email marketer\u2019s existence,\u201d 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\u2019re being ignored, not necessarily that the message is not getting through.<\/p>\n

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\u2019 bounce reports, and help desk tickets for entries citing \u201cMessage lacks SPF\/DKIM\/DMARC<\/em>\u201d since Nov. 5.<\/p>\n

Then, resend what matters, time-sensitive transactional mail first.<\/p>\n

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 <\/em>domain.<\/p>\n

Microsoft 365 customers who never turned on DKIM for their own domains should do it now, he advised. \u201cDo not rewrite SPF just because the bounce blames it,\u201d he said. If your records are clean and mail still bounces, send the full bounce to Microsoft so it lands in the investigation.<\/p>\n

However, a p=none<\/em> record is \u201cfirst base, not home plate,\u201d he said. The goal is p=reject<\/em>, which tells receivers to refuse anyone forging your name.<\/p>\n

Inventory every service that sends email as you, Dickson advised: The CRM, the billing system, the HR platform, and the marketing tools. \u201cMost organizations cannot produce that list,\u201d he noted. \u201cYou cannot protect a domain when you do not know who is speaking for it.\u201d<\/p>\n

A signal of what is to come<\/h2>\n

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 \u00a0for every sender. Google and Yahoo began requiring it of bulk senders in February 2024; Microsoft followed in May 2025.<\/p>\n

\u201cRequirements start with the big senders and then become the floor for everyone,\u201d he said. \u201cThe rollout was botched, but the destination is not in doubt.\u201d But while Microsoft has the destination right, \u201cnobody should learn about a new rule from a bounce message.\u201d<\/p>\n

This article originally appeared on Computerworld<\/a>.<\/em><\/p>\n

\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Microsoft\u2019s 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 […]<\/p>\n","protected":false},"author":0,"featured_media":10367,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-10366","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10366"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=10366"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/10366\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/10367"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=10366"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=10366"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=10366"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}