Since about 5 November 2026, legitimate emails sent to Outlook.com, Hotmail and Live.com addresses have been bouncing back, even when the sender did everything right. The Register reported on 9 November that a validation error has stopped Outlook.com from accepting some genuine mail, with the errors pointing to missing DMARC records or failing SPF checks. Microsoft has acknowledged the problem as a service degradation and says it is investigating. At the centre of the story is a little-known email standard called DMARC. This explainer sets out what DMARC is, how it works, and why it suddenly matters to anyone who sends email from their own domain.

What is DMARC?

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is a way for the owner of an internet domain to publish a policy telling receiving mail servers what to do with email that claims to come from that domain but fails authentication checks. The policy is published as a text record in the domain's DNS, the internet's address book, at a special address beginning with "_dmarc". When an email arrives, the receiving server looks up that record and follows the instruction it finds there.

DMARC was first defined in 2015 in a document known as RFC 7489. The specification has since been updated: the RFC Editor now marks RFC 7489 as obsolete, replaced by newer documents, and reporting in 2026 notes that RFC 9989 replaced it on 19 May 2026. The underlying idea has not changed. DMARC exists to stop criminals sending email that pretends to come from a domain they do not own, a trick known as spoofing, which is used in phishing scams and business email compromise fraud.

It is important to understand that DMARC is not a product you buy or a setting inside your email app. It is a public instruction attached to a domain name, and it only applies to mail sent from that domain. If you send email from a free Gmail, Outlook.com or Yahoo address, DMARC is your provider's problem, not yours. It matters to businesses, charities, schools, clubs and anyone else who sends mail from an address at a domain they control.

How does DMARC work with SPF and DKIM?

DMARC does not work on its own. It builds on two older email authentication methods, SPF and DKIM, and ties them to the address the recipient actually sees.

SPF, or Sender Policy Framework, is a DNS record that lists the servers allowed to send email on behalf of a domain. When a message arrives, the receiving server checks whether the server that sent it is on the list. If it is not, the message may be forged. DKIM, or DomainKeys Identified Mail, adds a cryptographic signature to every outgoing message, created with a private key held by the sending service. The domain's DNS holds the matching public key, so the receiver can check that the message was genuinely signed and has not been altered on the way.

The catch is that SPF and DKIM on their own do not check the address the reader sees. SPF checks the hidden "envelope sender" used behind the scenes, and a criminal can pass SPF with one domain while showing the victim a different domain in the visible From line. That is where DMARC comes in. It requires that the domain that passed SPF or DKIM matches, or "aligns" with, the domain in the visible From address. If neither check aligns, DMARC fails, and the receiving server follows the domain owner's published policy. In short, SPF says who may send, DKIM proves the message is genuine and unaltered, and DMARC ties both checks to the name the reader sees and decides what happens when they fail.

What are the three DMARC policies?

A DMARC record sets one of three policies, and the choice determines how strictly receiving servers treat mail that fails. The first policy is "none", written as p=none. It tells receivers to take no special action against failing mail, but to send reports back to the domain owner. It is a monitoring mode, and it is where every domain should start, because it lets the owner see what is being sent in their name before anything is blocked.

The second policy is "quarantine", or p=quarantine. It asks receivers to treat failing mail as suspicious, usually by sending it to the spam or junk folder. The third and strictest policy is "reject", or p=reject, which asks receivers to refuse failing mail outright. Most guidance recommends moving gradually: start at p=none, study the reports for a few weeks to find any legitimate services sending mail from the domain that have not been set up correctly, fix those, and only then tighten the policy to quarantine and eventually reject.

The reports are one of DMARC's most useful features. Receivers that check DMARC can send the domain owner regular aggregate reports listing every server that has sent mail claiming to be from the domain, and whether each message passed or failed. Those reports reveal forgotten mailing tools, misconfigured services and, sometimes, criminals actively spoofing the domain.

Why is DMARC in the news now?

DMARC is in the news because Outlook.com appears to have started enforcing it far more widely than before, and legitimate mail is being caught in the net. According to The Register, the problems began at the end of the week before 9 November, and users reported non-delivery messages with error codes related to SPF validation failures and missing DMARC information. Some reported the bounce message "550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records". The issue affects Microsoft's consumer email services, including Outlook.com, Hotmail, Live.com and MSN addresses.

What has surprised senders is how broad the impact appears to be. In May 2025 Microsoft announced new rules requiring domains sending more than 5,000 emails a day to Outlook.com to pass SPF and DKIM and to have a DMARC record of at least p=none. The recent bounces, however, have hit small senders too. The Register reports that complainants in Microsoft's support forum said even a single one-line email was rejected, and other reports describe senders whose SPF, DKIM and DMARC records were apparently set up correctly still having mail refused.

Microsoft has not published a customer advisory explaining any change. A moderator in Microsoft's support forum acknowledged the problem, saying it was "classified as a service degradation" and that Microsoft was "actively investigating the underlying cause of this email delivery issue", with engineering teams analysing service telemetry and customer data. The Register said it had asked Microsoft for more information and had not received a response at the time of publication. The failures have also been intermittent: some senders found that a message rejected once was delivered when sent again minutes later.

It is not yet clear whether Microsoft deliberately tightened its rules, extended the May 2025 requirements from bulk senders to all senders, or introduced a bug while changing its systems. Until Microsoft explains, the safest reading is the one the evidence supports: mail to Outlook.com from domains without DMARC, or with failing SPF, is currently at risk of being rejected.

What do Gmail, Yahoo and Outlook require in 2026?

The Outlook incident is part of a wider shift that has been under way since 2024. In February 2024, Gmail and Yahoo introduced bulk sender requirements: domains sending 5,000 or more messages a day to personal Gmail accounts must have SPF, DKIM and DMARC in place. Gmail later moved from temporarily deferring non-compliant mail to rejecting it outright, with its sender guidance warning of disruptions including temporary and permanent rejections from November 2025.

Microsoft followed in May 2025 with equivalent requirements for high-volume senders to Outlook.com, Hotmail and Live.com: SPF must pass, DKIM must pass, and DMARC must be present with at least p=none, aligned with SPF or DKIM. The November 2026 bounces suggest that, in practice, Outlook.com may now expect DMARC from every sending domain, not only bulk senders, although Microsoft has not confirmed that. The direction of travel is clear in any case: email authentication has moved from best practice to a condition of delivery.

How can a domain owner check and fix DMARC?

For a domain owner whose mail to Outlook.com is bouncing, the first step is to check the three DNS records. Free online tools can look up a domain's SPF, DKIM and DMARC records and report what is missing. The SPF record should list every service allowed to send mail for the domain, including the website host, the email provider and any mailing list or customer service tool. The DKIM record should be published for the sending service, using the selector that service provides.

If there is no DMARC record at all, publishing one is a single text record at _dmarc, and the simplest starting point is "v=DMARC1; p=none; rua=mailto:reports@yourdomain", with a real reporting address substituted. That record alone, with a policy of none, is enough to satisfy the minimum requirement reported by Microsoft, and it starts the flow of aggregate reports. The owner should then watch those reports, fix any legitimate sender that is failing, and only later consider tightening the policy to quarantine and then reject. Jumping straight to p=reject before checking the reports risks blocking the domain's own legitimate mail.

It is also worth checking that SPF has not hit its limit of ten DNS lookups, a common fault when a domain has added many services over the years, and that DKIM is actually signing outgoing mail rather than merely being published. If mail is still rejected after the records are correct, the problem may be on Microsoft's side, and the sender may need to wait for the service degradation to be resolved.

What DMARC cannot do

DMARC is a powerful tool, but it has limits worth knowing. It does not encrypt email, so it cannot stop anyone reading a message in transit. It does not stop all spam: a spammer can pass DMARC checks perfectly well by sending from a domain they own. And it only protects the domain it is published for, so it does nothing about scams sent from lookalike domains that differ by a single letter. What it does do, when set up properly, is make it much harder for criminals to impersonate a specific trusted domain, and it gives that domain's owner visibility over who is sending mail in their name.

The Outlook.com incident shows why that matters beyond security. A missing DNS record that once meant only a slightly higher chance of landing in spam can now mean mail is refused outright. For any organisation that relies on email to reach customers, students, patients or members, publishing a DMARC record has become basic housekeeping, like renewing a domain name or keeping a website certificate valid. The record itself costs nothing and takes minutes to add; the expensive part is discovering it is missing from a bounce message.