Website Security Check: What the A+ to F Grade Really Means

A grade is quick to read and quick to misunderstand. The free TOMORIS Website Security Check combines seven test areas into an overall grade from A+ to F: security headers, SSL/TLS, email security, DNS, cookies, embedded content, and security.txt. This article explains how the grade is calculated, what it proves, where its limits are, and which gaps pull it down the most.

How the overall grade is calculated

Each of the seven areas is a separate check with its own grade. Within an area, each individual test has a weight: a pass earns the full points, a warning half, a critical finding none. Purely informational items do not count. This produces a score from 0 to 100 per area.

The overall grade averages these scores, weighted by their impact on visitors and businesses:

• Security headers: 25%
• SSL/TLS: 20%
• Email security: 20%
• DNS security, cookies, and embedded content: 10% each
• security.txt: 5%

The weighted score determines the grade: A+ from 95 points, A from 85, B from 70, C from 55, D from 40, E from 25, and F below that.

Three rules that go beyond the points

• Critical findings cap the grade. A critical failure in one of the six core areas, such as an invalid certificate or a missing DMARC record, caps the overall grade at C, even if the points would be enough for more. security.txt is the exception: its absence alone should not push any website down to C.
• A+ only without a failure. If any finding has failed, A is the best achievable grade.
• What could not be tested does not count. If an area does not respond in time, it appears as “not tested” in the report and is excluded from the score. A good grade with gaps in coverage therefore says less than a complete one.

What the grade says and what it does not

The grade describes how your website and your domain are configured as seen from the outside, measured at a specific point in time. The test is passive, meaning no attacks and no load: the response headers of the tested page, the certificate and TLS protocols, the DNS records for domain and email, the cookies on the first visit, the content embedded on the page, and the security.txt file.

These points are easy to measure and have a direct effect. A browser that receives a Content Security Policy blocks injected scripts. A mail server that knows your DMARC record can reject emails with a forged sender.

Not covered, on the other hand:

• vulnerabilities in the application itself, for example in forms, logins, or CMS extensions
• the patch level of the server, CMS, and plugins
• internal systems, user accounts, permissions, and backups
• processes such as emergency planning, reporting channels, and training

The check therefore does not replace a penetration test or consulting. A grade of A means: the basic configuration visible from the outside is clean. A grade of C or D means: there are concrete gaps, usually quick to fix, that make the job easier for attackers and fraudsters.

Five gaps that pull the grade down the most

How strongly a finding counts follows from the weighting and the rules. These five have the greatest leverage.

1. No DMARC record for the domain

DMARC tells receiving mail servers what to do with emails that carry your domain as the sender but pass neither SPF nor DKIM in alignment (RFC 9989). If the record is missing, this is a critical finding in the email security area and caps the overall grade at C, even if the website is configured in an exemplary way. Domains that send no email at all also need a record: with v=DMARC1; p=reject you declare every email with this sender domain as not genuine.

The guide Email Security: SPF, DKIM, and DMARC in Five Steps shows the setup step by step; for Microsoft 365, see the article SPF, DKIM, and DMARC in Exchange Online.

2. No Content Security Policy and no HSTS

These are the two heaviest individual tests in the header area, which in turn counts the most. Without a Content Security Policy (CSP), any injected script may run in your visitors’ browsers; the CSP is the most important protection against cross-site scripting. Without HSTS (Strict-Transport-Security, RFC 6797), the first request over unencrypted HTTP can be intercepted and redirected. A duration of one year is recommended, that is, max-age=31536000.

It is best to introduce a CSP in Report-Only mode first, evaluate the reports, and then enforce it. The CSP Generator and the Security Header Generator provide ready-made configurations for nginx, Apache, IIS, and other platforms. The Security Header Cheat Sheet summarizes the recommended values.

3. Certificate and TLS problems

An expired or untrusted certificate, or one that does not match the domain, is critical: browsers then show a warning instead of your website. What also counts is which protocols the server supports. TLS 1.0 and 1.1 have been officially deprecated since RFC 8996 from 2021; the check expects them to be disabled. Among the protocol tests, TLS 1.3 carries the most weight. The assessment follows the BSI Technical Guideline TR-02102-2 and the guidelines of TLSRef (formerly Mozilla). The SSL/TLS Check shows the details.

4. Cookies without protective attributes

Cookies should be set with Secure so that they are only transmitted over HTTPS, and session cookies also with HttpOnly so that scripts cannot read them. Browsers discard a cookie with SameSite=None but without Secure entirely. If these attributes are missing on session cookies, the Cookie Check rates this as critical. It also shows whether the server sets known analytics or advertising cookies on the very first visit, before visitors were able to consent. In Austria, such cookies are only permitted with consent (§ 165 para. 3 TKG 2021, Austrian Telecommunications Act 2021).

5. Active mixed content and third-party scripts without integrity checks

If an HTTPS page loads scripts, stylesheets, or frames over unencrypted HTTP, this undermines the protection of the entire page. Browsers block such content, and the page then often no longer works properly. For scripts from third-party servers, Subresource Integrity is also recommended: a hash in the integrity attribute ensures that the browser executes only the exact file expected. The Mixed Content and SRI Check tests both.

From the grade to an action plan

1. Critical findings first. They cap the grade and usually represent the greatest risks.
2. Prioritize by weight. Email protection and headers bring the most points, security.txt the fewest. The file, however, takes only a few minutes to create (RFC 9116); the security.txt Check creates it directly in the browser.
3. Introduce changes one at a time. Observe CSP and DMARC first (Report-Only and p=none respectively), then enforce them.
4. Test again after every change. The grade is a snapshot: certificates expire, and new plugins bring new scripts.
5. Clarify responsibilities. DNS, the web server, and email delivery may be handled by three different service providers. Document who maintains which record.

Frequently asked questions

Is a B grade bad?

No. B means 70 to 84 points without a critical failure in a core area: a solid foundation with gaps that can be closed in a targeted way. The report lists the findings for each area, with an explanation and a sample configuration.

Why is my website at C even though the points are enough for B?

Then there is at least one critical finding in a core area, for example a missing DMARC record or a certificate problem. The report lists it under “Critical findings.”

Will my website be attacked during the check?

No. The check retrieves the page the way a visitor does and queries public DNS records. It sends no attacks and creates no load. You do not need an account.

If you would like to go through the findings together or have them implemented, the TOMORIS EXPERTS for Cyber Security can help.

Sources

• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), May 2026
• RFC 6797: HTTP Strict Transport Security (HSTS)
• W3C: Content Security Policy Level 3
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• BSI TR-02102-2: Cryptographic Mechanisms, Use of TLS
• TLSRef Configurator (formerly Mozilla SSL Configuration Generator)
• MDN: Set-Cookie
• OWASP Session Management Cheat Sheet
• § 165 TKG 2021 in the RIS
• W3C: Mixed Content
• W3C: Subresource Integrity
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (security.txt)