83 million domains are three records away from a C

Your scan came back F with thirty-four findings and no order to work them in. Do these three, in this order: publish a DMARC record with a policy of quarantine or reject, make your SPF record end in a fail, and send a Strict-Transport-Security header from your website. If your domain sits in the top band of F, where more domains sit than in any other band, those three are the shortest honest route to a C, because no single record carries enough weight to get you over the line.

Where the cliff is

F is the biggest grade by a distance: 234,955,475 domains, 74.2% of every domain the September 2026 census graded or found dead. A share that size doesn’t tell you where your own domain sits inside the grade, and the split by score does.

Split F by score and the population piles up at the top. The 50 to 59 band holds 83,218,623 of the 234,955,475 domains graded F, 35.42% of them, more than any other band in the grade. That band is the cliff edge: the largest single group of failing domains, with the C line directly above them.

There’s nothing above them inside F. No F-graded domain in this edition scores above that band, so there’s no thin layer of near misses waiting a point or two short of the next grade. If you’re an F with a score in the fifties, you’re already standing at the top of the grade.

Which checks put you in the band

The score is a sum. The scanner runs its named checks against your domain, each check carries a fixed weight, and the ones that fail take their weight off the total. Which named checks fail decides your band, and each one carries a severity, which is where the fixing order comes from.

One of them is different. dmarc-policy is the only check the scanner labels critical, and it fails in 94.4% of F-graded domains. Four checks sit outside that comparison. cdn-waf-detection and hosting-provider show 100%, and both are info-level detection checks that record what you run. The census table leaves tls-compression and ocsp-stapling out as well. Read past those and the widest-failing security check in the whole F grade is the DMARC policy.

hsts-header and spf-policy-strength fail almost as widely, and the three together are why this page picks three records out of the thirty-four. The severity column on your own result is the thing to read before you read the count.

Why one record won’t get you there

One record away would be the neater claim, and it isn’t true for this band. A domain in the 50 to 59 band has to clear the C line, and no single check the census scores carries enough weight on its own to lift a domain from that band over it. Publishing one record moves the score and leaves the grade where it was.

Each check’s weight is small next to the gap between the top of F and the bottom of C, so the climb takes several checks turning from fail to pass together. Set the detection checks aside and the three that fail most widely in F each carry real weight, enough between them to cover that gap, which is where the three on this page come from.

The first record is a DMARC policy that acts

Look up the TXT record at _dmarc.example.com, with your own domain in place of the example. There are three outcomes. There’s no record, and the check fails outright. There’s a record that reads v=DMARC1; p=none and then a reporting address, which monitors and blocks nothing, and the check fails that too. Or there’s a record with p=quarantine or p=reject, which passes.

The record to publish is a single TXT at that name:

v=DMARC1; p=quarantine; rua=mailto:[email protected]

p=quarantine passes the check and tells receivers to put mail that fails authentication into spam. p=reject scores higher and tells them to refuse it. If you’ve sat at p=none for months because you were afraid of losing legitimate mail, the reports arriving at your rua address are what tell you whether that fear is grounded. If you never set a rua address, you’ve been parked at none and collecting nothing, and quarantine is the move that costs least while you find out. The DMARC guide covers the tags, the reporting address, and the path from quarantine to reject.

The second record is SPF that ends in a fail

Your SPF record is the TXT at the apex of your domain that starts v=spf1. The spf-policy-strength check reads its last term, the all mechanism, and the qualifier in front of it decides the result. -all is a hard fail and passes on its own. ~all is a soft fail, and the scanner passes it only when your DMARC policy enforces; with p=none or no DMARC record at all, ~all fails the check. ?all is neutral and fails. +all authorises the whole internet to send as you and fails hardest.

That is the second reason to publish DMARC before you touch SPF: if your record already ends ~all, the policy from the section above turns this check from fail to pass on its own. If your record ends ?all or +all, or has no all term, you’ll need to edit it. The safe edit is to list the services that send mail for you and close with a hard fail:

v=spf1 include:<your mail provider's include> ip4:<your own sending server> -all

Get the sender list wrong and -all bounces the mail you forgot about, which is the one real cost of a hard fail, so check the list against your DMARC reports before you tighten it. The SPF guide walks through building the record and the lookup limit that breaks it.

The third record is one header from your web server

HSTS is a response header, so you set it in your web server or CDN configuration; DNS plays no part in it. The hsts-header check reads the response from your site over HTTPS and passes when the header is present with a max-age long enough to matter. A year is the value that scores in full:

Strict-Transport-Security: max-age=31536000; includeSubDomains

It tells a browser that has seen your site once to refuse plain HTTP to it for that long, which closes the window where a first request over HTTP can be intercepted and rewritten. It only works if your site is already reachable over HTTPS with a valid certificate; if it isn’t, that comes before this header, and the scan will have said so. Set it in the server block, the CDN’s header rules, or the platform’s security settings, whichever answers your requests. The HSTS guide has the exact line for the common servers and the preload question.

After the third record

None of the three costs anything to publish. DNS records take minutes to propagate and a header change shows the moment the server reloads, so run the free scan again once the third one is live. What you should see is the grade move and the list underneath it shrink. What’s left in that list is now ordered the way the first pass wasn’t: the severity column separates the findings that still carry weight from the informational detection checks that were never going to move the score.

Then work what’s left by severity, one record at a time, and rescan between each change so you can see which one did what.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.