How we score
Every score comes from 24 checks that anyone can repeat from their own computer. No logins, no hacking, no scanning for weak spots. We only look at what a government already shows the whole internet.
The score
Each check is worth points. A county gets the points for every check it passes, part of the points for some checks it partly passes, and none for checks it fails. The score is the points it earned out of the points that were possible, on a scale of 0 to 100.
The same math gives each of the three areas its own score: email, website and domain.
- A90 and up
- B80 and up
- C70 and up
- D60 and up
- FUnder 60
Fair rules
- A check that can't run never counts against anyone. If a website blocks our checker or a lookup times out, that check is left out of the score instead of failed.
- One bad day doesn't sink a score. If a check fails to run, we keep its last good result for up to 7 days.
- We check the domains the government really uses. Website and email addresses come from the Minnesota Secretary of State's county election office list, then we follow the website's redirects to wherever it actually lands.
- Everyone is checked the same way, every day, from a home internet connection like the one residents use.
- Ties share a rank. Two counties with the same score are listed by email score, then website score, then name.
What the score can't see
This is an outside view. It can't see passwords, backups, patching, staff training or anything inside a government's network. A high score doesn't mean a government is safe, and a low score doesn't mean it has been hacked. The checks here are the basic settings that federal guidance, such as CISA's Binding Operational Directive 18-01, asks agencies to get right.
Stops people from sending fake email that looks like it came from the county.
| Check | Points |
|---|---|
| Fake email gets blocked (DMARC) A DMARC policy tells Gmail, Outlook and every other mail service what to do with email that claims to be from the county but isn't. With p=reject the fake mail is thrown away. With p=quarantine it goes to spam. With p=none nothing happens to it. Fix: Publish a TXT record at _dmarc.example.gov. Start with v=DMARC1; p=none; rua=mailto:dmarc@example.gov and read the reports for a few weeks. Once every real sender passes, change p=none to p=quarantine, then to p=reject. |
20 |
| Made-up subdomains are covered too Scammers can send from addresses like billing.example.gov that the county never set up. The DMARC record decides what happens to that mail with its sp= setting. Fix: Subdomains follow the main p= policy unless the record says otherwise. Move p= to quarantine or reject, and leave out sp=none (or set sp=reject). |
3 |
| The county gets DMARC reports Reports show every server sending mail in the county's name, real or fake. They are how the county knows it is safe to turn on blocking. Fix: Add rua=mailto:dmarc@example.gov (or a reporting service's address) to the DMARC record. |
3 |
| Approved mail servers are listed (SPF) SPF lists the servers allowed to send the county's email. Ending it with -all tells receivers that every other server is fake. Fix: Publish one TXT record on example.gov that starts with v=spf1, lists each service that sends your mail (for Microsoft 365, include:spf.protection.outlook.com) and ends with -all. |
8 |
| SPF stays under the 10 lookup limit Mail services stop reading an SPF record after 10 lookups. Past that, the whole record counts as broken and stops protecting anything. Fix: Remove includes for services you no longer use. If you still need more than 10, ask your mail provider about a shorter include. |
2 |
| Outgoing mail is signed (DKIM) DKIM adds a signature to every message, so receivers can tell it really came from the county and wasn't changed on the way. Keys live under names the county picks, so this check only looks at the common ones. Not finding a key never lowers the score. Fix: Turn on DKIM signing in your mail service and publish the keys it gives you. In Microsoft 365 that is the selector1 and selector2 CNAME records under Email authentication settings. |
3 |
| Incoming mail must be encrypted (MTA-STS) Without MTA-STS, someone in the middle of the network can quietly strip the encryption off mail sent to the county and read it. MTA-STS in enforce mode tells sending servers to refuse that. Fix: Host a policy file at https://mta-sts.example.gov/.well-known/mta-sts.txt with mode: enforce and your MX hosts, then publish TXT _mta-sts.example.gov "v=STSv1; id=1". Start with mode: testing if you want to watch first. |
4 |
| The county hears about failed encrypted delivery TLS reports tell the county when other servers could not deliver mail to it securely, which can mean a broken certificate or an attack. Fix: Publish TXT _smtp._tls.example.gov "v=TLSRPTv1; rua=mailto:tlsrpt@example.gov". |
2 |
Website
Keeps visits to the county website private and hard to tamper with.
| Check | Points |
|---|---|
| The website uses HTTPS with a valid certificate HTTPS keeps what visitors read and type on the site private, and proves they reached the real county site. A broken or expired certificate shows people a scary warning. Fix: Install a certificate from a trusted provider (Let's Encrypt is free) that covers every name the site uses, and set it to renew automatically. |
10 |
| http:// visitors are sent to https:// People still type addresses without https. If the plain version of the site loads, those visits travel unprotected. Fix: Set the web server to answer every http:// request with a permanent (301) redirect to the same https:// address. |
4 |
| Browsers are told to always use HTTPS (HSTS) HSTS makes browsers remember to use the secure site, so nobody on public Wi-Fi can trick them into the insecure one first. Fix: Send the header Strict-Transport-Security: max-age=31536000 on every HTTPS page. Add includeSubDomains once every county subdomain supports HTTPS. |
5 |
| The newest encryption (TLS 1.3) works TLS 1.3 is faster and drops the weak options older versions allowed. Fix: Turn on TLS 1.3 in the web server, load balancer or CDN settings. Most current servers support it. |
3 |
| Retired encryption (TLS 1.0 and 1.1) is turned off TLS 1.0 and 1.1 have known weaknesses and every major browser dropped them in 2020. Leaving them on only helps attackers. Fix: Set the server to accept TLS 1.2 and 1.3 only. |
4 |
| The certificate isn't about to expire When a certificate expires, every visitor sees a security warning and many can't reach the site at all. Fix: Renew the certificate, and set up automatic renewal so it never gets this close again. |
2 |
| Scripts are limited (Content Security Policy) A Content Security Policy lists where scripts on the site may come from. If an attacker slips code into a page, the browser refuses to run it. Fix: Send a Content-Security-Policy header. Many CMS vendors document one that fits their platform. |
2 |
| Browsers don't guess file types Without this header a browser may run an uploaded file as a script just because it looks like one. Fix: Send the header X-Content-Type-Options: nosniff. |
1 |
| Other sites can't frame the county site A fake site can load the real county site in a hidden frame and trick people into clicking buttons they can't see. Fix: Send X-Frame-Options: SAMEORIGIN, or frame-ancestors 'self' in the Content-Security-Policy. |
1 |
| Visitors' page addresses aren't shared with other sites A referrer policy stops the full address of the page someone was on, which can include search terms or case numbers, from being sent to other sites. Fix: Send the header Referrer-Policy: strict-origin-when-cross-origin. |
1 |
| Security problems can be reported (security.txt) A security.txt file tells people who find a problem with the county's systems exactly who to tell. Without it, many reports never arrive. Fix: Publish https://www.example.gov/.well-known/security.txt with a Contact: line (an email address or form) and an Expires: date. |
2 |
Domain
Protects the county's internet address itself.
| Check | Points |
|---|---|
| Uses a .gov domain Only real US government bodies can get a .gov address, and it is free for them. People can trust a .gov address in a way they can't trust a .us or .com one. Fix: Request a .gov domain from get.gov (run by CISA), then move the website and email to it. |
6 |
| DNS answers are signed (DNSSEC) DNSSEC signs the county's DNS records, so nobody can send visitors or email to a fake server by forging the answers. Fix: Turn on DNSSEC with your DNS host, then add the DS record it gives you at your registrar (for .gov, in the get.gov dashboard). |
6 |
| Only chosen companies can issue certificates (CAA) A CAA record lists the certificate companies the county uses. Every other company must refuse to issue a certificate for the county's domain. Fix: Add a CAA record such as 0 issue "letsencrypt.org" (or your certificate provider) to the domain. |
3 |
| Name servers in more than one address block If all of a domain's name servers sit on one network, one outage takes the website and email offline together. Fix: Use a DNS host with name servers on separate networks, or add a secondary DNS provider. |
2 |
| The website works over IPv6 Many phone networks and newer internet connections use IPv6. A site with an IPv6 address is reachable over them directly. Fix: Ask your hosting provider or CDN to turn on IPv6 and publish an AAAA record for the site. |
3 |
Partial points
- DMARC: reject earns 20, quarantine 15 and none 5. A policy that only covers part of the mail (pct under 100) loses 5.
- SPF: -all earns 8, ~all 6, and ?all or no ending at all 2.
- HTTPS: a site that loads over HTTPS but sends visitors through an http:// address on the way earns 7.
- HSTS: under a year earns 2.
- MTA-STS: testing mode earns 2.
- .gov, DNSSEC and CAA: when the website and email use different domains, each domain counts for half.