News
Outlook.com Started Bouncing Mail From Domains Without DMARC. One TXT Record Stops It (2026)
Sixteen characters of DNS now decide whether your mail reaches a Hotmail inbox, and Microsoft never announced it. Since about November 5, 2026, Outlook.com has been refusing some mail from domains with no DMARC record, at any volume. Here is the evidence, the ten-minute fix and the caveats, and why it belongs ahead of the launch assets you were about to make for SaaSCity or anywhere else.

Contents (10)
- Key Takeaways
- Why is Outlook.com rejecting my email?
- Does this affect small senders and low-volume SaaS?
- How do you check whether your domain has a DMARC record?
- How do you fix the Outlook.com DMARC bounce?
- SPF vs DKIM vs DMARC: which one failed?
- From p=none to quarantine to reject: what's the rollout path?
- What nobody can tell you yet
- Questions founders ask about the Outlook.com DMARC bounce
- Go run the lookup
Sixteen characters of DNS now decide whether your password resets reach anyone with a Hotmail address, and Microsoft never said a word.
Quick answer: Since about November 5, 2026, Microsoft's consumer mail platform (Outlook.com, Hotmail, Live and MSN) has refused some mail from domains with no DMARC (Domain-based Message Authentication, Reporting and Conformance) record, returning 550 5.7.1 with code AS9031519. Publishing a TXT record at _dmarc, starting with v=DMARC1; p=none, has cleared every confirmed case so far. Microsoft has announced nothing.

Last updated: November 9, 2026. Microsoft has not commented, so anything about its intent is marked as inference. Sources are linked and dated where they appear.
Here is what the sender gets back, as MailRoute founder Thomas A. Johnson reported on November 6, 2026:
550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)
For eighteen months the advice was easy to follow and easier to ignore. DMARC is for bulk senders, you need it once you cross 5,000 messages a day, come back later. Plenty of founders did exactly that. That threshold now appears to be gone at Outlook.com, at least for part of the traffic, and the only announcement so far has been the bounce.
You are reading this on a directory's blog. SaaSCity is a gamified startup directory with a live city map and human editorial review, which means we don't sell DMARC tools and have no stake in whose you pick. Several sources below do sell them, and I flag that where it matters. I also looked up our own domain on November 9, 2026 before telling you to check yours: saascity.io publishes a record at p=quarantine with relaxed alignment.
Key Takeaways
- The rejection is reproducible: Spam Resource, DmarcKoff and EasyDMARC each triggered 550 5.7.1 from domains with no DMARC record on November 7 and 8, 2026.
- Microsoft has said nothing: No postmaster notice, blog post or service-health entry as of November 9, 2026, and the AS9031519 code appears nowhere in its documentation.
- Volume doesn't protect you: DmarcKoff hit this in its November 2026 test at a few dozen messages a day, far below the 5,000-a-day line in Microsoft's May 2025 rule.
- Consumer mailboxes only, so far: Microsoft 365 business mailboxes accepted the same mail in every public test.
- The fix is one record: A TXT record at _dmarc at p=none with a rua address, backed by aligned SPF (Sender Policy Framework) or DKIM (DomainKeys Identified Mail).
- p=none stops the bounce and protects nothing: Mail from one DmarcKoff subdomain was accepted straight into Spam, so treat it as the floor.
Why is Outlook.com rejecting my email?
Outlook.com is rejecting your email because your sending domain publishes no DMARC record, and since about November 5, 2026 Microsoft's consumer platform has been refusing part of that mail during the SMTP session. The recipient never sees it, not even in Junk, and your server gets a permanent failure.
Each part of the bounce makes it harder to diagnose. 550 is a permanent refusal. 5.7.1 is a broad code: Microsoft's own DMARC setup guide lists 550 5.7.1 as the response for inbound mail rejected under p=reject, which is a different situation entirely. And AS9031519 is an undocumented Microsoft code that nobody outside the company can read. On a Microsoft Q&A thread opened November 6, Microsoft's AI-generated answer concedes it: "AS9031519 is not defined in the available Microsoft documentation." On day one, MailRoute notes, the same text came back with no suffix at all.
The evidence piled up over four days.
| Source and date | What they did | What they saw |
|---|---|---|
| MailRoute, Nov 6, 2026 | Read its own outbound logs | Bounces from Nov 5; domains "mostly had working SPF", many had DKIM, DMARC was the missing piece |
| Spam Resource (Al Iverson), Nov 7 | Removed DMARC from low-volume personal domains | Postfix log at 13:52 Central shows outlook.com refusing; a Microsoft 365 domain accepted |
| DmarcKoff, Nov 8 | 24 seed mailboxes per test, sent via Mailgun | No DMARC anywhere: 16 of 16 Outlook.com and Hotmail mailboxes refused |
| EasyDMARC, Nov 9 (test Nov 8) | Zoho-hosted domain, SPF and DKIM aligned, no DMARC | Mail to live.com bounced at 14:01:49 UTC |
| Microsoft Q&A, Nov 6 to 9 | Admins comparing bounces | One poster: "about 50%" of clients; 80+ "same question" clicks |
| mailop list, Nov 6 to 8 | Mail operators comparing logs | Trigger looks like a missing DMARC record; one.com sees it only on NXDOMAIN |

EasyDMARC's test is the cleanest because it removes the usual excuse. The domain sat on Zoho Mail with SPF and DKIM both passing and aligned, and no DMARC record. On November 8, 2026 at 14:01:49 UTC, mail to a live.com address came back refused, per EasyDMARC's November 9 write-up by Hagop K., its Director of Professional Services, with the remote server named as live-com.olc.protection.outlook.com. The author reads OLC as Outlook Consumer. EasyDMARC sells DMARC products, which matters more for its advice than for its bounce log.

DmarcKoff went wider. Its November 8 test, written up by co-founder and CTO Aliaksandr Markau, sent from subdomains of mailpath.io through Mailgun to 24 seed mailboxes per run. With no DMARC record at the subdomain or its parent, all 16 Outlook.com and Hotmail seeds refused the message, while the 5 Microsoft 365 seeds put the same mail in the inbox. The company states two limits itself: it sells DMARC tools, and it sent one message per mailbox per case, so a bigger sample "might show some getting through."
Al Iverson, who writes Spam Resource, ran the simplest version. He removed DMARC records from his own low-volume personal domains and sent mail. His November 7 Postfix log shows the refusal at 13:52 Central, while a Microsoft 365 domain accepted a control message. The line to remember: "If you use that domain to send email, you need to have a DMARC record in place, not just SPF and DKIM."

The forum reports add the human side. One poster on that Microsoft Q&A thread wrote on November 6 that "about 50% of my clients that have emailed me since yesterday" were getting the bounce, and more than 80 people had clicked "same question" when we captured the thread on November 9, 2026. That figure comes from one poster's inbox and says nothing about the overall rate. Others in the thread confirmed the fix. "Lack of a DMARC Record in public DNS for the domain was the culprit," David Goodloe wrote, and the mail that had been refused went through afterwards. On the mailop list, Jarland Donnell of MXroute reached the same conclusion on November 6: "this just seems to trigger when the sender domain doesn't have a DMARC record."
Does this affect small senders and low-volume SaaS?
Yes, and small senders are the group this changes things for, since nothing Microsoft has published covers them. DmarcKoff's test domains sent a few dozen messages a day. Iverson's were personal domains. Both got 5.7.1, and neither got the 5.7.515 code that belongs to the 2025 rule.

Compare that with what Microsoft did announce. Its April 2, 2025 post gave a month's notice that domains "sending more than 5,000 emails per day" to Outlook.com would need to pass SPF and DKIM and publish DMARC of "at least p=none" with alignment. Failing mail goes to Junk first, and the Outlook.com postmaster policy says it "may be rejected" with 550 5.7.515. The same post has an FAQ asking whether you still need this under 5,000 a day. The answer, from April 2025: "While enforcement first targets large senders, all senders benefit from these best practices." The word "first" now reads like a plan to widen the rule, though that is my inference and Microsoft hasn't said so.
| Rule | Who it covers | What it demands | How failure looks | Notice given |
|---|---|---|---|---|
| Gmail, Feb 2024 | All senders | SPF or DKIM | Spam, or rejection with 5.7.26 | Published guidelines |
| Gmail, Feb 2024, enforcement raised Nov 2025 | 5,000+ a day | SPF, DKIM, DMARC at p=none | Temporary and permanent rejections | Published guidelines |
| Yahoo, Feb 2024 | Bulk senders | SPF and DKIM, DMARC at p=none | Enforcement phased in over the first half of 2024 | Published requirements |
| Microsoft, May 5, 2025 | More than 5,000 a day | SPF, DKIM, aligned DMARC at p=none | Junk, then 550 5.7.515 | Blog post, Apr 2, 2025 |
| Microsoft, about Nov 5, 2026 (observed) | Any volume, consumer mailboxes | A DMARC record, apparently | 550 5.7.1 (AS9031519) | None |
Sources for the table: Google's sender guidelines and its FAQ, Yahoo's requirements, Microsoft's post above.

Every product sends mail to consumer addresses: password resets, receipts, trial-ending notices, waitlist invites, support replies. And this failure hides. Spam Resource calls it "sporadic". Engagor's November 8 write-up cites a Zoho user refused at 15:50 and accepted on resend at 16:09. So a founder who spot-checks one send concludes everything is fine.
Meanwhile nothing retries. Microsoft's own postmaster policy says that after a 5xx code "the sender must not attempt to retransmit that message to that recipient," and a compliant server obeys. A receipt that never arrives turns into a chargeback and a support ticket, and a reset link that never arrives can cost you the account. Launch email is worse, because the whole day was riding on it.
I looked for a clean, dated figure for how much of the consumer inbox market Outlook.com and Hotmail hold and found nothing I'd stand behind, so count your own users instead:
select lower(split_part(email, '@', 2)) as domain, count(*)
from users
group by 1
order by 2 desc
limit 20;
Anything ending in hotmail, outlook, live or msn, country variants included, is on this path. Then check how your bounce handling groups failures. Filter on the text "lacks SPF/DKIM/DMARC", because the 5.7.1 code lumps this in with unrelated refusals, and a sender on Microsoft 365 may see something else entirely. Frank Lawler's tenant got a 5.7.23 "SPF validation error" headline for the same problem on Microsoft Q&A, a label Lawler called misleading since SPF and DKIM were both fine.
A directory launch runs on email too: the confirmation, the Monday slot reminder, the "you are live" note. Our startup launch checklist counts failing email delivery among the failures that should delay a launch, and it's right. Before you spend a day on launch assets, spend ten minutes making sure the mail that announces them lands in an outlook.com inbox.
How do you check whether your domain has a DMARC record?
Query _dmarc.yourdomain.com for a TXT record: an answer starting with v=DMARC1 means you have one, and no answer means you don't. That DNS lookup is the only check that counts.
dig +short TXT _dmarc.yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com
Prefer a browser? MXToolbox's DMARC lookup does the same job and parses each tag for you. Check the exact domain in your From line, then its parent.
On November 8, 2026, Dan Malm, a systems engineer at one.com, wrote on mailop that the rejection "only happens when a TXT for dmarc returns a NXDOMAIN result," and that domains returning NOERROR with an empty answer weren't affected. Engagor flags this as one operator's finding that nobody has corroborated. To see which bucket you are in:
dig +noall +comments TXT _dmarc.yourdomain.com
Look for status: NXDOMAIN or status: NOERROR. Publish the record either way, since an empty answer that happens to pass today could stop passing tomorrow.
Reading a header is not a check. Microsoft's anti-spam header reference, updated July 2026, documents a value called dmarc=bestguesspass, defined as: "Indicates that no DMARC TXT record exists for the domain exists. If the domain had a DMARC TXT record, the DMARC check for the message would pass." So a result with "pass" in its name can describe a record that doesn't exist. On that same Q&A thread, David R reported headers showing "spf=pass, dkim=pass and even dmarc=pass, but the public DMARC record was missing." After adding v=DMARC1; p=none, the next test went through.

Companies that followed Microsoft's own setup steps can get caught by this. "M365 never creates one," Lawler wrote about DMARC records. Microsoft Learn confirms the gap: "There are no admin portals or PowerShell cmdlets in Microsoft 365 for you to manage DMARC TXT records in your custom domains." Its connect-your-domain guide lists MX, Autodiscover, SPF and optional DKIM records, and mentions DMARC in one sentence pointing to another article. Follow those steps exactly and you can end up with no record at all.

How do you fix the Outlook.com DMARC bounce?
You fix it by publishing one TXT record at _dmarc on each domain you send from, set to v=DMARC1; p=none with a rua address, then confirming that SPF or DKIM aligns behind it. Eight steps, and most of the time goes on step one.
- List every domain in your From addresses. Include the root domain, any mail. or notifications. subdomain, and second domains used by your billing or support tools. DMARC is evaluated against the domain in the visible From address, so the domain your email vendor's dashboard shows may be the wrong one to test.
- Look up each domain at _dmarc. Run dig +short TXT _dmarc.yourdomain.com or use MXToolbox's DMARC lookup. An answer starting with v=DMARC1 means a record exists. A record on the parent domain also covers subdomains that have none of their own.
- Create a mailbox for the reports. Set up an address such as [email protected]. Microsoft's DMARC guide advises a dedicated mailbox or group and says to keep the reports out of a person's own mailbox.
- Publish one TXT record at your DNS host. Add host _dmarc with the value v=DMARC1; p=none; rua=mailto:[email protected] at your registrar or DNS provider, because Microsoft 365 has no portal for this on custom domains. Publish exactly one record: RFC 9989 discards multiple records at the same name.
- Wait out the negative cache. Resolvers remember the old no-record answer for the lesser of the SOA TTL and MINIMUM values under RFC 2308. Amazon Route 53's default SOA TTL is 900 seconds, which means 15 minutes, and Engagor saw reported cases clear in a few minutes to about 90 minutes.
- Check alignment for every sending service. For each vendor, confirm that the return-path domain or the DKIM signing domain matches your From domain. Microsoft's support article for 550 5.7.515 names those exact checks.
- Send several test messages to an outlook.com or hotmail.com address. Use a mailbox you control and read the result. The rejection is intermittent, so one successful send proves little. Send a handful and check your server logs as well as the inbox.
- Resend what bounced. Search your logs for the text lacks SPF/DKIM/DMARC, going back to November 5, 2026, instead of filtering on the 550 5.7.1 code. Resend receipts and invites, and ask affected users to request a new password reset, since old links may have expired.
The record itself, for copying:
Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:[email protected]
Sources for the numbers in those steps, all read on November 9, 2026: RFC 2308 on negative caching, AWS's SOA record documentation for the 900-second default, RFC 9989 on duplicate records, and Microsoft's 5.7.515 support article for alignment.
Duplicates catch people. Lawler's second domain turned up with two DMARC records and an SPF syntax error on top, so read what is already there before you add anything.
In DmarcKoff's test, adding a parent record at p=none stopped the refusal, and the mail from that subdomain still landed in Outlook's Spam folder. So the record gets you accepted, and where the mail lands after that is a separate fight. DmarcKoff notes it couldn't separate the domain's effect from the shared Mailgun IP pairs it used.
SPF vs DKIM vs DMARC: which one failed?
If your bounce names AS9031519, the piece that failed is the DMARC record itself, since the public tests had SPF and DKIM passing and aligned. Once the record is up, the distinction still matters, because DMARC asks a different question than the other two.
A DMARC record is a DNS TXT entry at _dmarc.yourdomain.com that tells receivers how to treat mail failing authentication for your domain and where to send reports about it. RFC 9989, published in May 2026, is the current specification.
| Check | Question it answers | Domain it looks at | Classic SaaS failure |
|---|---|---|---|
| SPF | Is this server allowed to send for the return-path domain? | Envelope MAIL FROM | Passes for your vendor's domain, which says nothing about yours |
| DKIM | Was this message signed by a key at this domain? | The d= value in the signature | Signed with the vendor's domain until you add its DNS records |
| DMARC | Did SPF or DKIM pass for a domain matching the visible From? | 5322.From | No record at all, or a record with nothing aligned behind it |
Alignment is the part people miss. Microsoft's April 2025 FAQ defines it as the From domain that "matches (or sub domain) the domain used by SPF and/or DKIM." A green SPF result for your vendor's bounce domain doesn't align with your From domain, however reassuring the dashboard looks. Microsoft's 5.7.515 article tells you to verify this for every third-party service: the service's 5322.MailFrom contains your domain, and DKIM signs with your domain.
None of the public tests I read isolated a domain with a DMARC record and no aligned SPF or DKIM against the AS9031519 check, so nobody can say whether Outlook.com refuses that case. It would fail DMARC, and the May 2025 rule explicitly requires alignment, so treat an unaligned record as unfinished work.
The SaaS stack makes this harder than it sounds, because every tool that sends as you (billing, helpdesk, newsletter, CRM) needs its own aligned path. Our pre-launch security checklist puts SPF, DKIM and DMARC on the list before launch for that reason. And if the domain itself sits on a cheap, abused extension, read what that does to deliverability before you spend another hour on TXT records.
From p=none to quarantine to reject: what's the rollout path?
Start at p=none, read your reports, then move to quarantine and to reject only after every legitimate sender passes. Microsoft's April 2025 post advises exactly that order ("We advise moving gradually (none → quarantine → reject) to avoid unintended mail loss"), and EasyDMARC suggests two to eight weeks of reports before moving on.
| Policy | What it asks receivers to do | When to use it | What can go wrong |
|---|---|---|---|
| p=none | Nothing. RFC 9989 calls it Monitoring Mode | Day one | Protects nothing against spoofing |
| p=quarantine | Treat failing mail as suspicious; Microsoft 365 sends it to Junk Email | After reports look clean | A tool you forgot lands in spam |
| p=reject | Refuse failing mail; Microsoft 365 answers 550 5.7.1 | After quarantine stays clean | Forwarding, mailing lists and any sender you missed |
The rua address is why you bother with p=none at all. Aggregate reports are how you discover who is sending as your domain and whether each source passes, and Yahoo's requirements strongly recommend the tag for monitoring during setup. RFC 9989 says that at p=none "the Domain Owner expresses no handling preference for messages that fail DMARC validation," which is why you can sit there safely while you look. Expect surprises, like the CRM someone connected years ago or a co-founder's newsletter experiment.
What breaks at reject is well documented. RFC 9989 warns in its introduction that DMARC "can cause mail to be rejected" and points to RFC 7960 on indirect mail flows, meaning forwarded mail and mailing lists. Google carves those same flows out of its alignment requirement. Then there's the tool nobody remembered, which is usually what hurts a small company, since it fails on the day you flip the switch.
Not everyone agrees with the slow path. Tolle Colart, on the Microsoft Q&A thread, called v=DMARC1; p=none "a temporary (dangerous) workaround" and recommended going straight to p=reject, and Microsoft's postmaster policy does say "p=reject is recommended." As an end state, sure. As a Monday morning change on a domain you've never audited, it trades a bounce you can see for a bounce you caused.
Older guides that ramp up with pct= are going out of date. RFC 9989, published as a Proposed Standard in May 2026, replaces the Informational RFC 7489 from March 2015, drops the pct tag and adds t=y for testing. Microsoft's Learn page, updated in July 2026, still describes ramps from pct=10 to pct=100, so expect both to coexist for a while and don't assume a percentage gets honored precisely. Microsoft's other piece of advice there holds up well: start with low-volume domains or subdomains and save the parent domain for last.
What nobody can tell you yet
Nobody outside Microsoft can say whether this is a deliberate policy, a filter experiment or a mistake. Iverson was careful about it on November 7: "I'm not sure if this is an intended policy update in the world of Microsoft; time will tell." EasyDMARC rates a bug as highly unlikely. Neither has confirmation, and a Q&A contributor wrote on November 9 that "there has been no official acknowledgement of the issue from Microsoft." SMTPedia's November 9 summary says the same, and my own searches that day turned up no statement.
The rejection also isn't deterministic. DmarcKoff reported 16 of 16 refused in its November 8 write-up, EasyDMARC and Iverson describe it as intermittent, and only one operator has tied it to NXDOMAIN. Any single test result, including one of yours, tells you less than it feels like it does.
Then there are the reports of domains that do publish DMARC and still bounce. dmarcdkim.com wrote on November 7 that "a few admins report the same error from domains that do publish DMARC." SMTPedia says none of these is confirmed, and of the two cases Engagor examined in detail, the domain turned out to have no record. EasyDMARC separates out 550 5.7.23 reports from senders with DMARC in place, saying they "may be misconfigurations, or a second issue." If you have a valid record and still bounce, check that the record really resolves, check alignment, and open a case with Microsoft's sender support, which is what EasyDMARC advises too.
Whichever way this goes, you lose nothing by publishing the record, and Iverson's advice holds "even if this filter change was in error; even if they roll it back." Gmail and Yahoo already expect it from bulk senders, and Microsoft's postmaster page already says "We strongly recommend all senders implement SPF, DKIM, and DMARC."
Questions founders ask about the Outlook.com DMARC bounce
What does 550 5.7.1 Message lacks SPF/DKIM/DMARC Auth Records (AS9031519) mean? It is a permanent SMTP refusal from Microsoft's consumer platform (Outlook.com, Hotmail, Live, MSN), first reported by MailRoute on November 6, 2026 and seen from November 5. It appears when the sending domain publishes no DMARC record, even if SPF and DKIM pass. Microsoft has not documented the AS9031519 code; its own AI answer on Microsoft Q&A says the code is not defined in available documentation. The message is refused during the SMTP session, so the recipient never sees it.
Will resending the bounced mail work? Yes, once the record resolves, though timing depends on DNS caching. RFC 2308 says a negative answer is cached for the lesser of the SOA record's TTL and its MINIMUM field, and Amazon Route 53's default SOA TTL is 900 seconds, so a Route 53 zone can keep serving a no-record answer for 15 minutes. Engagor's November 8, 2026 review of reported cases saw rejections stop between a few minutes and about 90 minutes after publishing. A compliant server will not retry a 5xx on its own.
Does a DMARC record on the parent domain cover mail sent from mail.example.com? Yes. Microsoft Learn states that a domain's DMARC TXT record automatically covers all subdomains without their own record, including nonexistent ones. DmarcKoff's November 8, 2026 seed test agrees: with a record only at the parent, including at p=none, all 16 Outlook.com and Hotmail mailboxes accepted mail from the subdomain, though it landed in Spam. A record on the subdomain alone, tested at p=reject, also stopped the refusal. Each subdomain still needs its own working SPF or DKIM for DMARC to pass.
Does Microsoft 365 create a DMARC record for me? No. Microsoft Learn's DMARC guide, last updated in July 2026, says there are no admin portals or PowerShell cmdlets in Microsoft 365 for managing DMARC TXT records on custom domains; you add the record at your registrar or DNS host. Microsoft's domain-connection guide lists MX, Autodiscover, SPF and optional DKIM records, with DMARC mentioned in a single sentence pointing elsewhere. A domain connected by following those steps can easily have no DMARC record at all, which is the state Outlook.com started refusing around November 5, 2026.
Is the Outlook.com DMARC rejection a permanent policy or a glitch? Nobody outside Microsoft knows. As of November 9, 2026, Microsoft has published no postmaster notice, blog post or service-health entry, and a Microsoft Q&A contributor wrote that day that there has been no official acknowledgement. Al Iverson of Spam Resource wrote on November 7 that he was not sure it was an intended policy update, while EasyDMARC rates a bug as highly unlikely. Publish the record either way: Microsoft's own postmaster page already strongly recommends DMARC for all senders.
Does p=none protect my domain? No. RFC 9989, the DMARC standard published in May 2026, defines p=none as Monitoring Mode, in which the domain owner expresses no handling preference for mail that fails. It stopped the Outlook.com refusal in DmarcKoff's November 8, 2026 seed test but did not move mail out of the Spam folder, and it does nothing against spoofing. Microsoft's postmaster page sets p=none as the minimum and recommends p=reject. Treat p=none as the first step of a rollout.
Does this affect mail sent to Microsoft 365 business mailboxes? In every public test so far, no. DmarcKoff's November 8, 2026 seed test delivered mail with no DMARC record to the inbox of all five Microsoft 365 mailboxes, and Al Iverson's November 7 test saw a Microsoft 365 domain accept a control message while outlook.com refused mail. EasyDMARC says Microsoft 365 business tenants with custom domains don't appear to be affected as recipients. The refusal is limited to consumer domains such as outlook.com, hotmail.com, live.com, msn.com and country variants. That could change, since Microsoft has not documented any of this.
Why does my email header say dmarc=pass when I have no DMARC record? Because a header reports one receiver's verdict, and Microsoft's can include a guess. Its anti-spam header reference, updated in July 2026, defines dmarc=bestguesspass as meaning no DMARC TXT record exists but the check would pass if one did. On Microsoft Q&A in November 2026, one admin reported headers showing spf=pass, dkim=pass and dmarc=pass while the public record was missing, and the mail bounced until v=DMARC1; p=none was published. Check DNS at _dmarc.yourdomain.com instead.
Why do only some of my emails to Outlook.com bounce? The rejection is intermittent, and no one has explained why. Spam Resource called it sporadic on November 7, 2026, and EasyDMARC reports that some messages from the same domain get through. Engagor's November 8 write-up cites a Zoho user refused at 15:50 and accepted on resend at 16:09. DmarcKoff, by contrast, saw 16 of 16 Outlook.com and Hotmail mailboxes refuse one message each. One systems engineer at one.com reports it only for domains whose _dmarc lookup returns NXDOMAIN, which nobody has corroborated.
Do Gmail and Yahoo require DMARC too? Yes, for bulk senders. Since February 2024 Google and Yahoo have required SPF, DKIM and DMARC of at least p=none from bulk senders, which Google defines as 5,000 or more messages a day to Gmail accounts; Google says enforcement ramped up in November 2025 with temporary and permanent rejections. Below that volume, both ask for SPF or DKIM only, and Yahoo strongly urges DMARC. In DmarcKoff's November 2026 test, Gmail accepted mail with no DMARC record, placing two of three in the inbox.
Can I publish p=reject straight away instead of p=none? You can, but it is how real mail gets lost. One Microsoft Q&A contributor argued in November 2026 that p=none is a dangerous workaround and p=reject is better, and Microsoft's postmaster page does recommend p=reject. Yet Microsoft's own April 2025 guidance advises moving gradually from none to quarantine to reject to avoid unintended mail loss, and EasyDMARC suggests two to eight weeks of reports first. Any sender you have forgotten, such as a billing tool, fails immediately at reject.
What does a SaaSCity listing include? SaaSCity is a gamified startup directory with a live city map and human editorial review. A free listing gives you a listing page and a building on the map, and adding the SaaSCity badge to your site earns a dofollow backlink and a Monday launch slot. Quick Pass ($19.99) goes live within 24 hours, Premium ($39.99) adds a written launch post with three dofollow links, and Max ($99.99) adds 30 days of billboard, ticker and homepage pin.
Go run the lookup
Open a terminal, type dig +short TXT _dmarc. plus your domain, and read what comes back. If it's nothing, you have spent the past year and a half relying on a threshold Microsoft seems to have stopped applying, on a system that won't warn you when it applies something else. The next person who can't reset their password won't file a bug. They'll assume your product is broken, and they will be right.
Once the mail lands, give people somewhere to find you. SaaSCity gives every startup a listing page and a building on a live city map for free, and adding our badge to your site earns a dofollow backlink from a domain rated DR 71 at our latest Ahrefs refresh (November 9, 2026), plus a Monday launch slot.
Get your SaaS in front of founders
List your product on SaaSCity for $19.99, one-time: a permanent listing, a dofollow backlink and a building on the live city map.


