How the security baseline check works
The security baseline check reads a domain's public email records and loads its homepage over HTTPS, then compares what it finds with a fixed list of rules. A domain that passes every required rule can show a badge on its own website. The badge shows the date of the last check and links back to this tool.
This page describes rubric version 2026.1. It is generated from the same rule table the checker runs.
The 8 required checks
- E1: SPF ends in -all or ~all
An SPF record is published at the domain, and its last all term is -all (reject) or ~all (mark as suspicious).
SPF lists the servers allowed to send mail for the domain. Ending in -all or ~all tells receiving servers what to do with mail from any other server. Ending in ?all or +all, or with no all term, tells them nothing.
- E2: DMARC set to quarantine or reject
A DMARC record is published with p=quarantine or p=reject, applied to all failing mail (pct absent or 100).
DMARC is the record that tells receiving servers to act on mail that fails SPF and DKIM. With p=none they deliver forged mail anyway.
- E3: DKIM key published
A DKIM signing key is published at one of 10 common selectors, or at the selector the owner names when claiming the badge. A domain that sends no mail at all (no MX record, SPF exactly v=spf1 -all, DMARC p=reject) doesn't need one.
DKIM signs outgoing mail. Forwarding breaks SPF, so a signature is what lets a forwarded message still pass DMARC.
- W1: HTTPS works with a valid certificate
The homepage loads over https:// and the certificate is accepted.
A certificate error is the one security problem every visitor sees: the browser shows a full-page warning instead of the site.
- W2: http:// redirects to https://
A visit to http:// is redirected to an https:// address.
Anyone who types the address without https:// otherwise stays on an unencrypted connection.
- W3: HSTS for at least 180 days
The homepage sends a Strict-Transport-Security header with a max-age of at least 180 days.
HSTS tells browsers to use HTTPS for the site without trying http:// first. That closes the gap in which the first unencrypted request can be intercepted.
- W4: No insecure content on the homepage
The homepage loads no images, scripts or stylesheets over http://. We read the first 256 KB of the page; on a larger page the check covers that part.
A resource loaded over http:// on an https:// page can be read or replaced in transit, and browsers flag or block it.
- W5: Every homepage cookie is Secure
Every cookie the homepage sets carries the Secure flag. A homepage that sets no cookies passes.
A cookie without Secure is also sent over http://, where it can be read in transit.
Also reported, never required
They appear in the report because they are worth fixing.
Lookalike domains are not part of the check. Other people register them, so no setting the owner controls can fix them. The Lookalike-Domain Finder looks for them separately.
- mta-sts: MTA-STS
An MTA-STS record is published at _mta-sts.
It tells other mail servers not to deliver to the domain over an unencrypted connection.
- dnssec: DNSSEC
The domain's DNS zone publishes DNSSEC keys.
Signed DNS answers are harder to forge, including the answers these checks read.
- csp: Content Security Policy
The homepage sends a Content-Security-Policy header.
It limits where scripts can load from, which contains the damage of an injected script.
- frame: Frame protection
The homepage sets X-Frame-Options or a CSP frame-ancestors directive.
It stops another site from loading yours in a hidden frame to trick visitors into clicking.
- nosniff: MIME-type sniffing
The homepage sends X-Content-Type-Options: nosniff.
It stops browsers from running a file as a different type than the server declared.
- referrer: Referrer-Policy
The homepage sends a Referrer-Policy header.
It controls how much of your page addresses other sites see when a visitor follows a link.
- permissions: Permissions-Policy
The homepage sends a Permissions-Policy header.
It switches off browser features such as the camera for pages that don't use them.
- version: Software version disclosure
The Server and X-Powered-By headers don't give an exact software version.
An exact version tells anyone scanning for a known vulnerability which sites to try first.
- cookie-flags: Cookie HttpOnly and SameSite
Every homepage cookie carries HttpOnly and a SameSite attribute.
HttpOnly keeps a cookie away from page scripts and SameSite limits cross-site use. A consent-banner cookie often needs to be readable by scripts, which is why this is reported and not required.
When a result is unknown
If a DNS lookup or the website request doesn't complete, we mark that rule unknown and never count it as a failure.
We repeat a run with no failures and at least one unknown required rule after 1 hour. It doesn't change the badge.
If a domain with a badge can't be checked for 7 days in a row, we count that as a failed check.
How often we check
We check every domain with a badge again every 7 days. The badge shows the date of the last check.
If a check fails, the badge keeps showing the last date the domain passed, the owner is emailed if they gave an address, and we check again within 24 hours. If that check fails too, at least 20 hours after the first, the badge changes to say the check failed, with its date.
The verification record, a TXT record at _sbh-verify, has to stay in place. If it is missing on 2 checks in a row, the badge lapses. Removing the record is how an owner retires the badge.
A passing check restores the badge from any of these states.
What a pass does not mean
A pass means that on the date shown, the domain's email records and its homepage met the rules on this page. It is a dated configuration test.
It is not a certification, an audit or an approval, and it is not a guarantee that the business is secure. It must not be described as any of those.
It checks only what anyone can see from outside: public DNS records, and the homepage as a logged-out visitor sees it. It doesn't look at other pages, logged-in areas, servers, devices, staff or the way the business handles data.
It says nothing about whether the business is honest. A scam site can set these records up correctly too.
Showing a badge is covered by section 5 of our Terms of Service: only on the domain it was issued for, with the code unchanged, and never described as a certification.
What we store
For each check: the domain, the rubric version, the outcome and the ids of the rules that failed. We don't keep DNS answers or page content.
For a badge: the domain, its verification record and, only if the owner gives one and confirms it, an email address. An address that isn't confirmed within 48 hours is deleted, and a confirmed one 30 days after the badge lapses. The whole record, badge and check history included, is deleted 365 days after the badge or its verification lapses, unless a pass restores it first. An owner who also ticks the newsletter box joins the newsletter when they confirm; that subscription is separate and lasts until they unsubscribe from it.
We use IP addresses to limit how often checks can run, and don't store them with results.
Published research may count a domain's results, without naming the business, only if its owner ticked the research box when claiming the badge. The box is unticked by default.
Rubric versions
A new required check means a new rubric version. We tell badge holders 30 days before we judge their domain against it.
2026.1, approved 2026-09-24: First version. Eight required checks: three for email (E1 to E3) and five for the website (W1 to W5).