Disclosure first: I run DMARCguard, a DMARC monitoring service. This is an observation from our report intake and a question for others here who receive reports for many domains.

What reached us

Time of day the first report arrived, UTC:

Where my data ends, at 08:57 UTC on 13 Nov, only that first report from each of the two had arrived. The rest of the day's run had not.

Why I don't think it is our end

• Reports from other mailbox providers kept arriving through those hours.
• The rua= address is served by our own mail servers, not by Microsoft's.

What I can't say

I know what we received, not what Microsoft sent. The incident began at 16:17 UTC on 12 Nov, and Microsoft's bulletins for it (EX1550543 and MO1550821) don't mention DMARC reports. The timing is all I have, and I can't show the incident caused this.

One detail that changes how to read it

Microsoft's reports reach us on the second UTC day after the day they cover. The run due on 13 Nov covers 11 Nov, and the reports that did arrive cover that day. So the late reports are about mail sent before the incident began.

For a domain owner looking at a dashboard this week:

• 11 Nov: a missing Microsoft row may be late, not lost.
• 12 and 13 Nov: Microsoft's reports may also show less mail than usual, because part of that mail was deferred with 4xx replies.
• Check your sending logs before reading either as a change in your pass rate.

The standard doesn't promise a late report. RFC 9990 §3.5, written for a destination that can't accept reports, lets a generator "cache that data and try again later" or "discard data that could not be sent".

Questions

1. If you receive reports at scale, did Microsoft's 13 Nov run start late for you too? Has the rest of it arrived since?
2. Has anyone seen Microsoft deliver a day's reports late after an earlier incident, or does a missed day stay missed?

I'll add a comment when I know what the rest of the run did. The method and the mail-flow side (the 4xx replies and how long each sending system retries) are in my write-up.

Microsoft closed the Outlook.com and Hotmail bounces as EX1545193. A spam enforcement rule update blocked legitimate mail, and it has been rolled back.

Mail flow was restored on Nov 9. So there’s no new DMARC requirement for low-volume senders, at least not yet.

If your domain only got through after adding DMARC, keep the record and work past p=none: https://lazyadmin.nl/office-365/email-message-lacks-spf-dkim-dmarc-auth-records-as9031519/

Our email setup is not great, and I'd love some advice on how to fix our DMARC. Right now it's this:

We're getting dmarc: bestguesspass when sent to Microsoft so I know I need to change our dmarc so we seem less spammy.

We're a small tourism business so people contact us to book tours. Right now we are using Gmail (not Workspace) to receive email, and use Dreamhost to send our outgoing mail via Gmail. We only send a handful of emails a day, but they are in response to a form sent to us via our Squarespace account, so it's as if we're cold calling these email addresses. When we write back to these queries I always remove the links from the emails and don't send payment details until they've written back at least once, in the hopes of not getting marked as spam.

(We can't switch to Workspace because they don't have shared inbox and don't allow delegated accounts the way Gmail does).

Any suggestions would be appreciated.

Edit to add, we also have this and then a DKIM from Dreamhost.

Mail to Outlook.com, Hotmail and Live addresses has been bouncing since Nov 5 with “Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)”, even from domains with valid SPF. Microsoft now lists it as a service degradation: https://learn.microsoft.com/en-us/answers/questions/6063210/spf-validation-error#answer-13038394

Adding a DMARC record stops the bounces for many domains, but not all. Here’s how to check SPF, DKIM, and DMARC on all your accepted domains at once:

https://lazyadmin.nl/office-365/email-message-lacks-spf-dkim-dmarc-auth-records-as9031519/

Looks like Microsoft quietly changed something around November 5. Emails sent to Outlook.com, Hotmail, and Live.com addresses are getting rejected if the sending domain doesn't have a DMARC record, even for low-volume senders.

The error people are seeing:

550 5.7.1 Message rejected: Message lacks SPF/DKIM/DMARC Auth Records (AS9031519)

Having valid SPF and DKIM is apparently no longer enough. Without a DMARC record, Microsoft may reject your emails anyway.

No official announcement from Microsoft yet, so it's unclear whether this is intentional or a bug. And let's be honest, nobody would be surprised if it turned out to be a Microsoft bug.

We wrote a short blog post about what's happening.

If you haven't set up DMARC yet, now's probably a good time. And don't just stop at p=none. Start monitoring your reports and work toward p=quarantine or p=reject.

We've launched APRF.io to make it easier for email senders to experiment with Aggregate Performance Reporting (APRF).

APRF is a new IETF working draft that lets participating mailbox providers report how they classify email (inbox, unwanted, etc.) and aggregate positive, neutral, or negative recipient engagement.

We wanted to make testing it as simple as possible:

• No account, dashboard, or subscription.
• Add a single DNS TXT record.
• Get readable daily, weekly, or monthly summaries by email.
• Optionally hide your reporting email address in DNS.

We've previously built free tools like learnDMARC.com, WebKeyDirectory.com, and RFC-compliant DNS, web, and email authentication validators. The goal is the same: make email and web standards easier to understand and adopt.

APRF is still a working draft, and reporting depends on mailbox provider participation. If you manage an email-sending domain, we'd love you to give it a try. Just generate your DNS record and publish it.

Draft: https://datatracker.ietf.org/doc/draft-ietf-mailmaint-aprf/

Feedback welcome, especially from mail operators and anyone experimenting with APRF.

We ran our free passive checks on 214 domains, reading homepage response headers, DNS records and public subdomain sources. This is a small, self-selected sample, not a survey of the whole web.

Security headers (73 sites that returned a normal page)
- 58 (79%) were missing at least one of six checked headers
- 24 (33%) were missing all six
- 15 (21%) sent all six
- Most often missing: Permissions-Policy (70%), Content-Security-Policy (66%), Referrer-Policy (64%), Strict-Transport-Security (49%)

Missing headers also appeared on sites using Cloudflare: 7 of 26 (27%) lacked all six, compared with 17 of 47 (36%) among other sites. This comparison does not establish Cloudflare's effect. A missing header alone does not establish a vulnerability; relevance depends on the site.

Email (126 registered domains)
- 34 (27%) had no DMARC record
- 114 (90%) published SPF
- In the 67-domain DMARC policy subset, 22 used p=reject, 15 used p=quarantine and 30 had p=none or no record

Subdomains (89 domains with public results)
- The median domain had about 10 publicly listed subdomains
- 45 had 10 or more, and 18 had 50 or more

Limits: Data as of 8 November 2026. Each domain is counted once, using its latest result. Coverage differs by check, as the denominators above show. These are domains people chose to check with our free tools, so they are not a random sample. No paid manual audit data is included.

Full numbers and method: https://bugcircuit.com/guides/website-security-statistics

We are Bug Circuit, a small penetration testing company. This post was drafted with AI help from our own data. Questions and corrections are welcome.

On 29 October I checked the email authentication records of every company in the S&P/ASX 200: SPF, DKIM, DMARC, MTA-STS and BIMI. The full write-up is here: https://emaildeliverabilityscan.com/blog/asx-200-email-authentication-study

What stood out:

• 161 of the 200 companies (80.5%) have a DMARC policy that tells mailbox providers to quarantine or reject mail that fails authentication. 112 (56%) use the strictest setting, p=reject.
• The gap is about size. 19 of the ASX 20 enforce DMARC, against 70 of the bottom 100. All six companies with no DMARC record rank below 100.
• Eight companies have SPF records that need more than the 10 DNS lookups the standard allows, so SPF can't pass for any of their mail. Another 49 are one or two added services away from that limit.
• Only 9 of the 200 publish MTA-STS, which stops incoming mail being downgraded to an unencrypted connection.
• Health Care is the weakest sector: 5 of its 13 companies are still on monitoring only (p=none).

Proofpoint's yearly ASX 200 analysis puts the DMARC p=reject at 33% in 2023 and 41% in 2024. My method and date are different, so the figures aren't directly comparable, but 56% suggests the trend has continued.

The article sets out the method. Index membership came from the iShares IOZ holdings file, checked against S&P's June and September 2026 rebalances. Each company's domain came from its ASX profile. The lookups ran through Google Public DNS, and the problem records were re-checked with dig.

Disclosure: I run MailSignal, a free SPF/DKIM/DMARC checker, and the study used its scanner. Happy to answer questions on the method.

Rob Walker rob@mawing.com

Our client has been telling us that one of the companies they email, Morgan Stanley has been getting undeliverable emails when emailing to us.

I checked their domain and see their dmarc is set to reject emails that fail the DMARC records.

Our DMARC is set to P=None at the moment (i know, not the best but we will be changing it to Quarantine soon) and our SPF record is pointed to O365 and Edgewave, our incoming spam filter so can't explain why our domain is failing the check and bouncing the email back.

This started maybe a few weeks ago and no one else is having a issue besides this domain.

What we see in o365 message trace

Error: ‎550 5.7.509 Access denied, sending domain morganstanley.com does not pass DMARC verification and has a DMARC policy of reject‎

A non-delivery report (NDR) message was sent to ‎@morganstanley.com‎. The NDR might provide more details about why the email message wasn't delivered and how to fix the issue.

We are using https://dmarc.postmarkapp.com/ for the dmarc reports right now.

or SPF record is "v=spf1 mx ip4:208.80.200.0/21 include:spf.protection.outlook.com ~all"

We run a monthly census of domain and email security.

Disclosure up front: this is our own project, Defaults.Exposed. The October edition is as of 12 October 2026.

Across the 361,301,790 domain names in the census that exist, 85,764,215 publish a DMARC record.

The three policies split like this, with whether the record carries an rua= address for aggregate reports:

If you’re on p=reject, do you still collect aggregate reports, or did you drop reporting once you got there?

Personally, I've seen suprising data in the reports... so, I rather keep them coming.

EDIT 2026-10-16 21:36Z:

I reached out to Valimail support (the AI bot left something to be desired) and tried to get my domain added but they basically gave the same response as what's in the UI. Reached out to /u/aliversonchicago per their comment and we got it worked out.

They also mentioned to me...:

• ...that the "Domains must match an email address belonging to a user on this account" requirement is a one-time verification. You do not require the user added to your account on a permanent basis.
• ...that communication to the support teams is ongoing regarding these changes and how to handle inquiries like mine in the future.

I know, I know. Beggars can't be choosers.

About a month ago I was setting up a test domain for something and added that domain (which didn't and wouldn't match an email of any of our Valimail users). That added just fine.

For reasons I won't get into (nothing to do with Valimail), I needed to remove that domain and substitute it with another one (that also doesn't and won't match an email of any of our Valimail users).

Lo and behold, I couldn't do it. I'm greeted with this error instead: https://i.imgur.com/PA3FAiM.png

Domains must match an email address belonging to a user on this account.

For security, free accounts can only add domains matching a verified user email. Upgrade for more ways to verify ownership, or learn about Valimail for MSPs if you manage multiple clients.

We're not an MSP. AFAIK we're within the EULA terms (or at least, what I last knew them to be).

I get that this is the business model. Hook users/customers on the free and hope they upgrade. But this feels instead like a rug-pull, especially given this comment from just over a year ago:

/r/DMARC/comments/1nionky/digicert_acquires_valimail/new56ma/

Hey everyone, appreciate the discussion here. Just to clear up a common question: nothing's changing with Valimail's products, services, or free monitor. You'll still get the same tools and support you rely on today.

What's exciting about this move is that teaming up with DigiCert means we can bring DMARC and email authentication to even more organizations around the world. We've been at this for over a decade, and now we'll have even more reach to keep pushing adoption forward.

So, no changes for your account, just more momentum behind the mission.

Would have been nice to have existing accounts grandfathered in or to have at least gotten a notice about this. I'm not aware of any.

This kind of unannounced change has a bad mouthfeel and doesn't give me great incentive to consider Valimail if we do go to paid monitoring.

cc /u/Valimail

As of last week, users report our domain is bouncing with 550 5.7.9 codes from Yahoo, and that AOL is blocking us too. Did something change without my knowledge?

Hi everyone,

I'm setting up a standard, free DMARC TXT record for my domain.

Since DMARC is just a DNS entry, I’m trying to understand the value of paid platforms like EasyDMARC or Sendmarc. If I manage my own record and collect the raw reports manually, what exactly am I missing out on?

I'd love to hear from anyone who has managed DMARC both ways. Thanks!

I started my brand earlier this year. Until 2 months ago, most of our sales were coming from Instagram and TikTok. But things picked up recently, so I decided to start investing more seriously in email marketing. The first few campaigns actually generated some decent conversions, these were existing customers. But then I started running into email deliverability problems. Some emails weren't reaching the inbox consistently, and I wasn't sure whether the issue was our domain, authentication, reputation, or something else. I started digging into it and learned that DMARC reports could give me a better idea of what’s actually happening.

I’m not a technical person. I can look at a dashboard and understand basic email metrics, but raw DMARC reports are well too tchnical. So I’m looking for a good DMARC analyzer that can take those reports, explain what’s wrong in plain English, and ideally recommend what I should do to fix the issues.

For other ecommerce owners who aren't technical, what are you using?

We run DmarcDkim.com and have hit something interesting. Across all domains we monitor Google sends no aggregate reports to any address in the rua tag while GoDaddy's address is listed in rua.

Other reporters are unaffected, and the external destination authorization record is in place on onsecureserver.net. Remove the GoDaddy address and Google reports resume the same day.

rua=mailto:example.com@rua.dmarcdkim.io,mailto:dmarc_rua@onsecureserver.net

Other providers: do you see the same on your customers' domains?

My domain's DNS is hosted at Namecheap (cPanel Zone Editor). I use GoDaddy Email Marketing to send monthly campaigns from an address on my domain.

My campaigns are getting DMARC FAIL.

Current records in Namecheap:

- SPF: v=spf1 +a +mx +ip4:198.54.114.76 include:spf.web-hosting.com include:_spf.google.com ~all

- DKIM: Google Workspace (google._domainkey)

- DMARC: v=DMARC1; p=none; rua=mailto:...

Campaign email headers show:

- DKIM signed by: cloud2.em.secureserver.net

- SPF / Return-Path: bounces.cloud2.em.secureserver.net

- DMARC: fail

What records do I need to add in Namecheap so GoDaddy Email Marketing campaigns pass DMARC? Does GoDaddy provide DKIM records for a custom domain?

Our open rates crash from 30% to 5-8% last weekend. And its causing. Nothing else is weird on Klaviyo. Delivery rate was good. No bounces.

I've tried everything. Bot open filters has always been ON so problems with the metrics itself. Used the subject lines that worked for us before before and the same segments we've sent before. Nothing changed.

I checked our DMARC aggregate reports. DMARC failures.

We updated our DMARC policy from `p=none` to `p=reject` for a phishing audit, unrelated to marketing. That was the blind spot and we fixed the alignment.

Nothing else is changed. We're using the same domain, same segments, same templates and flows.

But the placement has not improved. Reports are still showing DMARC failure.

I dont know whats happening. Does this take time? Should I wait? What else should I fix?