Арваннэгдүгээр сарын 5-наас Outlook, Hotmail, Live болон MSN хаяг руу илгээсэн зарим имэйл домэйн баталгаажуулалтын мэдээлэлгүй гэх шалтгаанаар хүрэхгүй байна.
Буцаалт арваннэгдүгээр сарын 5-наас эхэлж, нийтлэл гарах үед үргэлжилж байсан бөгөөд Microsoft бодлогын өөрчлөлт зарлаагүй. Илгээгчид 550 5.7.1, 550 5.7.23 алдаатай хүргэлтийн тайлан авч байгаа ч зарим захидал хүрч, зарим нь буцаж байгаа аж. Зарим буцаагдсан домэйнд SPF, DKIM, DMARC бүртгэл байсан гэж мэдээлсэн бөгөөд Microsoft-ын ажилтан асуудлыг шалгаж буй үйлчилгээний доголдол хэмээн тодорхойлжээ.
Microsoft 2025 оны тавдугаар сараас өдөрт 5,000-аас олон захидал хэрэглэгчийн хаяг руу илгээдэг домэйнүүдэд DMARC шаардаж ирсэн ч одоогийн доголдол жижиг илгээгчдэд ч нөлөөлж байна. SPF нь домэйн нэрийн өмнөөс захидал илгээх эрхтэй серверийг шалгадаг бол DKIM нь мессежид криптограф гарын үсэг нэмж, DMARC эдгээр баталгаажуулалтыг “From” хаягтай тулган шалгадаг. Эдгээр нь домэйн дуурайлт, фишинг болон байгууллагын имэйлээр залилан хийхээс сэргийлэхэд чиглэдэг.
Байгууллагууд dig +short TXT _dmarc.example.com командыг ажиллуулж DMARC бүртгэлээ шалгаж болно; v=DMARC1-ээр эхэлсэн хариу нь бүртгэл байгааг илтгэнэ. MailRoute-ийн тайлбарласнаар v=DMARC1; p=none гэсэн TXT бүртгэл нь тайлан авах тохиргоо хийж, баталгаажуулалт амжилтгүй болсон тохиолдолд хүлээн авагчаас арга хэмжээ авахыг шаардахгүй. Байгууллагуудад арваннэгдүгээр сарын 5-наас хойших буцаалтын тайлан, имэйлийн бүртгэлээ шалгаж, чухал захидлыг дахин илгээх, бүх илгээгч домэйндээ DMARC тохируулж, Microsoft 365 дээр DKIM-ийг идэвхжүүлэхийг зөвлөжээ.
Frank Dickson-ийн хэлснээр p=none нь эхний алхам бөгөөд цаашдын зорилго нь хуурамч илгээгчийг татгалзуулах p=reject тохиргоо юм. Мөн байгууллагууд CRM, төлбөр тооцоо, хүний нөөц, маркетингийн систем зэрэг өөрийн нэрээр имэйл илгээдэг бүх үйлчилгээг бүртгэх шаардлагатай. Google болон Yahoo 2024 оны хоёрдугаар сараас, Microsoft 2025 оны тавдугаар сараас их хэмжээний захидал илгээгчдэд DMARC шаардаж эхэлсэн бөгөөд Dickson цаашид энэ шаардлага бүх илгээгчид өргөжнө гэж үзжээ.
Дэлгэрэнгүйг эх сурвалжаас харах
↓Эх сурвалжийг нээх ↓
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.”
