What the findings actually mean

Every one of the 405 domains publishes an SPF record. DKIM was present wherever we could test for it. Basic email authentication is table stakes in this sector, and the sector has paid it. Then 101 domains stop one step short: the DMARC record is either absent (2) or published with p=none (99). None means "tell me about forgeries, but deliver them anyway."

The part that should bother a CFO: 215 of the 405 domains route mail through a named security gateway (Mimecast, Proofpoint, AppRiver, Barracuda, Cisco), and 52 of those still sit at none. The invoice for the gateway is paid. The one setting that makes the world's mail systems reject a forgery of your name is not.

An attacker sends a message that says it is from yourcreditunion.org, using your real display names, to your members, your vendors, or your own accounting team. Gmail, Microsoft, and Yahoo all check your DMARC policy before deciding what to do with it. At none, they deliver it. Some add a faint warning. Most members never see it.

Who gets hurt: the member who moves money because "the credit union" told her to, the clerk who pays a vendor's "updated" bank details, and the institution that reimburses both. The FBI has put business email compromise losses above two billion dollars a year for several years running, and a single successful wire is routinely a six-figure event. Add the call-center surge, the card reissue, and the member who moves her accounts because the bank down the street "never sent her a scam email."

Twenty-five sites still serve something on port 80 without immediately sending the visitor to HTTPS. Twenty-two of those share one pattern: the bare domain redirects to www, but over plain HTTP, and only then to HTTPS. Two hops, the first one unencrypted.

It looks harmless in a browser because the final page has the padlock. It is not harmless. It is a guaranteed unencrypted request on every first visit.

The plain-HTTP hop is exactly the window an on-path attacker needs. They intercept the first request, answer with their own redirect, and send the member to a domain they control that looks like yours. The member typed the right name and still landed on the wrong site. No malware, no phishing email, no trace in your logs.

The cost shows up as account takeover claims, and account takeover is where the reimbursement, the regulatory reporting, and the member churn all live.

Nine domains present a certificate a browser will refuse: expired, self-signed, or issued for some other hostname. In practice this is usually the bare domain serving a certificate that only covers www, or a forgotten host that stopped auto-renewing.

Members are trained by warning screens. Once they learn that "the credit union's site always shows that warning, just click through," they will click through the attacker's warning too. A broken certificate does not just fail one visit. It teaches your members to ignore the one signal that would have saved them.

There is a second cost: an expired certificate on a host that other systems depend on (an API, a single sign-on endpoint, a vendor integration) becomes an outage, and outages during business hours cost real money in staff time and member calls.

Fourteen domains show no clientTransferProhibited status in the public registry record. The good news is that 391 do, which is one of the strongest results in the sweep. The bad news is that the lock most of them have is the weak one.

Without a transfer lock, anyone who gets into the registrar account, or convinces registrar support that they are you, can move the domain to a registrar of their choosing and change the nameservers on the way out. From that moment they answer every DNS query for your name: website, mail, certificates, everything.

Even with the standard lock, a registrar account takeover gets the same result, because the same account can remove the lock. That is why the standard lock is not what most people think it is. The real control is registry lock, where the registry itself refuses changes unless a human at the registrar completes an out-of-band verification.

Twenty primary domains did not answer a web request from either of the two locations we checked from. For most of these the cause is aggressive bot protection that blocks anything it does not recognize as a browser; for a few, the site was simply down. We did not grade web checks for these domains, because we could not see them. Their grades are built on DNS, mail, and registry data alone.

An unreachable site is not a security finding in itself. What it tells us is that nobody is watching the site the way an outsider sees it. If a security researcher cannot reach it, your uptime monitor probably can, because it is allow-listed. That is how a member-facing outage runs for hours before the call center notices, and how a defaced or hijacked page stays up because the only people testing it are inside.

Bot protection that blocks everything also blocks the good scanners: the certificate-transparency monitors, the examiners' tooling, and the free posture check you are reading about. That is a trade worth making deliberately, not by default.