The gap that matters most
Almost every state has published a DMARC record — 47 of 51. That is genuine, and it took real work.
But publishing a DMARC record is not the same as enforcing one. A record with p=none asks mail providers to reporton spoofed mail, not to block it. Someone can still send mail that appears to come from that state's domain, and the state gets a report about it afterwards.
Only 15 of 51 portals publish p=reject, which is the setting that actually stops the forgery. Another 11 sit at p=quarantine, which routes suspicious mail to spam. That leaves 71% with no enforcement at all: 21 at p=none and 4 with no DMARC record.
The fix is one word in a DNS record. Moving from p=none to p=reject is a text edit — the work is in the weeks beforehand, reading the reports to find out which systems are sending legitimate mail on your behalf. That is why the step gets skipped, and it is a reason rather than an excuse.
What good looks like
These states are running the full stack on their public portal: DMARC enforced at p=reject with SPF ending in -all. This is the configuration worth copying.
AlabamaHawaiiMinnesotaMontanaNebraskaNew JerseyPennsylvaniaTexasWest Virginia
Email: the rest of the picture
- 51 of 51 publish an SPF record.
- 27 end it in
-all(hard fail, the strongest setting). 24 use a weaker ending, and 0 publish no SPF record at all. - A soft or neutral SPF ending is often deliberate during a migration. It is also the state that persists when nobody goes back to finish the job.
The bare domain is the weak spot
Two portals have exactly the same shape of problem: the www host is configured correctly and the bare domain is not. Both are easy to miss, because both look fine in a browser.
Wyoming does not complete a TLS handshake on the bare domain at all — only on www. Someone typing the domain without www gets a plaintext redirect before reaching the secure site, and that first hop is the one an attacker on the same network can interfere with.
Virginia serves an incomplete certificate chain on the bare domain: it sends its own certificate but omits the intermediate, so the chain cannot be verified on its own. Most browsers quietly fetch the missing intermediate and hide this entirely — which is why it survives. It still breaks strict clients, older Android devices and plenty of command-line tooling. The same domain over www sends the full chain correctly, which is how we know it is a configuration gap and not a broken certificate.
Both fixes are small: make the apex answer on port 443 the way the www host already does, and make sure the intermediate certificate is served on every hostname the certificate covers.
TLS and DNS
- 50 of 51 portals present a certificate chain that validates on its own — the exception being Virginia, described above, where the
wwwhost validates and the bare domain does not. That is a genuinely good result: expired or self-signed certificates are the most common TLS finding in surveys like this, and there are none here. - 34 of 51 negotiate TLS 1.3, the current standard. The other 17 stop at TLS 1.2, which is not broken, just older.
- 13 of 51 have a DNSSEC chain that validates end to end. DNSSEC is the one item on this list with no partial credit — it either validates or it does not.
- 9 of 51 are reachable over IPv6. The other 42 have no
AAAArecord. This is the widest gap in the study, and the least urgent — but it is also the one that will keep mattering more each year.
The full results
Every portal, in alphabetical order. Deliberately not ranked — the point of this table is to be complete, not to sort anyone to the top or bottom.