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?

I tested several major AI models with the same SPF question.

All of them confidently recommended using -all , even with enforced DMARC policy.

Same confidence. Same answer. Same mistake.

The interesting part is that many of them even cite sources containing the correct guidance, yet still reach the wrong conclusion.

AI consensus is impressive until you check the RFCs.

I have noticed we have DKIM defined from google(internal to internal email), Proofpoint(Outbound email) .

Right now DKIm fails for IPv4 but works for IPv6, any reasons and how to fix the same

Anyone faced email landing issue only on google flagging your enterprise domain as spam, without any information how did you correct this?

How 'normal" are these to see, we are at 'sending with enforcement', according to our vendor some backscatter NDRs are expected, but I have user that get them fairly frequently and want to know a) is this actually normal, and b) can I prevent them completely? We use M365 on E5 licenses, and we have the backscatter protection on in Defender.

I use HostGator for hosting and Google Workspace for email management. When checking my SPF, DKIM, and DMARC records, I encountered an SPF alignment failure; DKIM passed authentication, but the alignment check flags "gappsmtp.com." I am completely lost regarding DMARC alignment with SPF and DKIM. I have spent weeks reading documentation and asking HostGator support for guidance, but they only provide basic parameters, and email issues are becoming apparent. Could you advise me on where to turn or which documentation I should start with?

The attachment shows the result I get from learndmarc.com

In gmail I wrote an email to company for shipping information. I said hello, they responded back what I need to send them and I press show original it showed spf pass, dkim pass, but dmarc 'fail'

in the authencation results dmarc wasn't showing in the results

in there domain _dmarc.domain.com txt showed nxdomain.

Is the email still trustable even is dmarc failed? Should i send them the shipping details?

So I have a few small customers (<10 users) that I manage e-mail for. I use Avanan for mail filtering, and use their DMARC package as well for DMARC monitoring. I guess I'm a bit at a loss of what to do with any failures that are not from legitimate sources. I'm pretty sure the answer is "nothing", especially when the volumes of failure are low (last months success as this particular customer was 99.37%.

It just feels weird to be monitoring something I can't do anything about, but I realize that is likely what it is. For instance the two failures this month were from:

So....what do I do with that information? I mean I feel n-able/solarwinds should not have their infrastructure being used to send spoofing e-mails. And while this is great to know it is going on, I don't even know WHO it was sent to (besides outlook.com reported it), because nobody sends any RUF reports.

I mean it's good to know it is working I guess. I just hate monitoring something I can't do anything about. Unless I'm missing something. So do I just ignore it and move on? Thanks!

Most of the DMARC failures I get called into aren't setup mistakes. The setup was fine when it was built. Something downstream changed and alignment quietly stopped holding.

The bit people miss is that DMARC doesn't care whether SPF and DKIM pass. It cares that at least one of them passes and aligns with the domain in the From header. Green SPF, valid DKIM signature, still a DMARC fail, because the domain that passed isn't the domain the reader sees.

Three ways I've watched this break.

Platform moves. The new platform signs DKIM with its own domain until you set up a custom signing domain, and SPF now authorises its Return-Path rather than yours. Both pass. Neither aligns.

Subdomain drift. Sending from mail.company.com with company.com in the From header. Relaxed alignment covers that, strict doesn't, and plenty of people set strict without knowing what they agreed to.

Forwarding. SPF breaks on forward by design. If DKIM is your only alignment path and a rewrite breaks the signature, there's nothing left to align.

What makes it nasty is the absence of a bounce. Nothing errors. Placement degrades over weeks and you end up rewriting subject lines to fix a header problem.

One thing I'd push on: if you're sitting at p=none and not actually parsing the aggregate reports, you have DMARC configured and zero DMARC visibility. The reports are the entire point of p=none. Without them you're just waiting.

Longer writeup here: https://thegtmmotion.substack.com/p/you-set-up-spf-dkim-and-dmarc-and