How the test works

Domain Check reads a domain's public DNS records, the ones every mail server looks up when it receives an email in that domain's name. It does not connect to any mail server and sends no email.

In your browser. Queries go from your browser over DNS-over-HTTPS to Cloudflare's public resolver (cloudflare-dns.com). Google's resolver (dns.google) takes over in the event of a network error, an invalid HTTP response or a timeout.
Bounded timeouts. 5 seconds at most per query and 25 seconds for the whole analysis. A check that has not completed in time is marked "not verifiable" (timeout).
A domain that exists. The tool first queries the domain's SOA and NS records. If DNS replies that the domain does not exist, the analysis stops there.
Five checks. MX, SPF, DKIM, DMARC and blacklists. Each one receives a score out of 100 and findings ranked by severity: Critical, To fix, Information or Pass.

Within each check, when several situations apply, the starting score is that of the most serious one (the lowest in the table). Adjustments are then applied, without going below 0.

How the overall score is calculated

The overall score is the average of the check scores, weighted according to their role in protecting the domain:

Score = round( Σ (weight × check score) ÷ Σ (weights of the verifiable checks) )

Weight of each check
Check	What it protects	Weight
DMARC	The instruction given to recipients when your domain is spoofed	30
SPF	The list of servers allowed to send	25
DKIM	The signature on emails	25
MX	Receiving email	10
Blacklists	The reputation of the sending IP addresses	10

Cap at 49. An SPF record ending in +all, or a blacklisted IP address, limits the overall score to 49, whatever the other scores. Either of these two flaws is enough to compromise your email.
Partial score. A check that cannot be verified is left out of the calculation and the weights of the others are recalculated. The score is then flagged as partial, with the list of excluded checks. A check that does not apply is excluded in the same way, without making the score partial.

Overall score levels
Score	Level
80 and above	Good
50 to 79	Needs improvement
Below 50	Critical

A worked example

Take exemple.nc: correct MX records (100), an SPF record ending in ~all (80), a 2048-bit DKIM key (100), DMARC at p=none with reports (30) and no blacklisted IP address (100).

Check	Weight × score
MX	10 × 100 = 1,000
SPF	25 × 80 = 2,000
DKIM	25 × 100 = 2,500
DMARC	30 × 30 = 900
Blacklists	10 × 100 = 1,000
Overall score	7,400 ÷ 100 = 74, needs improvement

Moving DMARC to p=reject raises DMARC to 100, and the ~all SPF record to 100 as well, since DMARC now rejects spoofed emails: the overall score reaches 100. If the domain's IP addresses belong to a shared provider, the blacklist check does not apply and the total is divided by 90 instead of 100.

"Not applicable" or "not verifiable"

A check may receive no score for two very different reasons, which the tool always keeps apart:

Not applicable: the check does not apply. DKIM and blacklists for a domain that sends no email, or blacklists when the sending addresses are shared by a large provider (Microsoft 365, Google Workspace…).
Not verifiable: the check applies, but the tool could not reach a conclusion. DNS did not respond, the timeout was exceeded, the DKIM key uses a selector specific to your account, or no blacklist responded correctly.

A DNS error is never an absence. If DNS cannot be reached (both resolvers failing or timing out) or if it replies with an error (SERVFAIL, REFUSED…), the point is "not verifiable". The tool never concludes "no SPF" or "no DMARC" from a query that did not succeed. Only a valid DNS response, empty or "name does not exist", can show that a record is missing.

The "domain without email" profile

Many domains send no email at all: names registered to guard against typosquatting, former brands, brochure websites. They must say so, otherwise anyone can use them to impersonate you.

A domain is non-sending if its SPF record is exactly v=spf1 -all, with no other mechanism.
It is non-receiving if it publishes a null MX: a single MX record with priority 0 pointing to the target ..

The profile is shown at the top of the result. For a non-sending domain:

the -all SPF record scores 100;
DKIM and blacklists do not apply;
DMARC scores 100 with reject, 70 with quarantine, 20 with none and 0 if it is missing. The recommended record is v=DMARC1; p=reject;.

Mail servers (MX), weight 10

The tool reads the domain's MX records, processes 10 at most (in order of priority), then looks up the IPv4 address (A), or failing that the IPv6 address (AAAA), of each server. It also identifies the receiving provider from the server names: Microsoft 365, Google Workspace, OVHcloud, filtering gateways, operators in New Caledonia and French Polynesia…

Situation	Score	Severity
MX records present, all resolving to an IP address	100	Pass
Null MX (`0 .`): the domain receives no email	100	Information
MX pointing to an IP address or to an alias (CNAME), which RFC 5321 forbids	70	To fix
At least one MX cannot be found	50	To fix
No MX: senders fall back to the website's address	30	To fix
No MX resolves	0	Critical
DNS does not respond for the MX records	not verifiable	Information

With no MX, the tool recommends publishing one, or a null MX if the domain receives nothing.

SPF, weight 25

The tool looks among the domain's TXT records for those starting with v=spf1. It evaluates the record the way a receiving server would, following each include and redirect:

it counts the DNS lookups (include, a, mx, ptr, exists, redirect), limited to 10 by the standard (RFC 7208);
it counts the lookups that return no answer (name does not exist, or no record), limited to 2;
it detects include loops;
it notes the recognised sending services in the include tree (Microsoft 365, Google Workspace, Brevo, Mailchimp…).

Situation	Score	Severity
Ends in `-all`	100	Pass
`~all` with a DMARC `p=reject` policy applied to 100% of emails	100	Pass
`~all` in all other cases	80	To fix
`?all`, or neither `all` nor `redirect`	30	To fix
Ends in `+all`: overall score capped at 49	0	Critical
No SPF	0	Critical
Several SPF records on the same name	0	Critical
Unknown mechanism, invalid `ip4` or `ip6`, syntax error	0	Critical
More than 10 DNS lookups	0	Critical
More than 2 lookups returning no answer	0	Critical
`include` or `redirect` to a name with no SPF	0	Critical
Include loop	0	Critical
DNS does not respond for the domain's SPF or for the target of a `redirect`, or the final policy depends on a macro	not verifiable	Information

All the situations scoring 0 make the SPF record invalid in the eyes of recipients (permanent error, "permerror"). Adjustments, applied afterwards:

ptr mechanism in one of your domain's records, discouraged by the standard (one found in the include of a host or sending service is not penalised, as you cannot fix it): −10, To fix;
8 to 10 DNS lookups, close to the limit: −5, Information.

If DNS does not respond for an include or for an a or mx mechanism, the point is reported as information, with no penalty.

DKIM, weight 25

A DKIM key is published under a name of the form <selector>._domainkey.exemple.nc. DNS offers no way to list a domain's selectors, so the tool queries 57 common selectors: those of Microsoft 365 (selector1, selector2), Google Workspace (google), Zoho, Proton, Fastmail, iCloud+, Gandi, Mailchimp, SendGrid, Brevo, HubSpot…, plus up to 10 selectors that you enter yourself.

A record is taken into account if it contains v=DKIM1 or a p= tag.
The length of an RSA key is measured exactly, by reading the public key itself. An Ed25519 key is considered strong.
A revoked key (empty p=) is reported as information and does not count as a valid key.
The Microsoft 365 case. If selector1 or selector2 is an alias (CNAME) pointing to Microsoft but no key is published at the end of it, the records are in place but signing has not been enabled in Microsoft 365.

Situation	Score	Severity
Best key: RSA of 2048 bits or more, or Ed25519	100	Pass
Best key: RSA of 1024 to 2047 bits	70	To fix
Best key: RSA of less than 1024 bits	20	Critical
Microsoft 365: records published, signing not enabled	20	Critical
No key, although the provider uses known selectors (Microsoft 365, Google Workspace, Zoho, Proton, Fastmail, iCloud+, Gandi)	0	Critical
No key, unknown provider or one with selectors specific to each customer (OVHcloud, Amazon SES, Postmark…)	not verifiable	Information
Domain that sends no email	not applicable	Information
DNS does not respond for any selector	not verifiable	Information

Adjustment: if all the keys found are in test mode (t=y), −20, To fix. When the check is not verifiable, the "Custom selector" field is brought forward: it re-runs DKIM only and recalculates the score.

DMARC, weight 30

The tool looks on the name _dmarc.exemple.nc for the TXT record starting with v=DMARC1, then reads the p, sp, np, adkim, aspf, pct, rua, ruf and fo tags. Invalid values are reported.

Subdomains. If a subdomain such as mail.exemple.nc has no DMARC record of its own, the tool moves up towards the parent domain, one label at a time, without going as far as the extension (.nc). It then applies the parent's sp policy, or failing that its p policy, and reports this as information.

Situation	Score	Severity
`p=reject` applied to 100% of emails	100	Pass
`p=reject` with `pct` below 100	80	To fix
`p=quarantine` applied to 100% of emails (next step: `reject`)	80	Pass
`p=quarantine` with `pct` below 100	60	To fix
`p=none`: monitoring only	30	To fix
No DMARC	0	Critical
Several DMARC records	0	Critical
`p` tag missing or invalid	0	Critical
DNS does not respond	not verifiable	Information

Adjustments, applied afterwards (without going below 0):

no rua report address: −10, To fix;
reports sent to an external domain that has published no authorisation (a v=DMARC1 TXT record on exemple.nc._report._dmarc.<external-domain>): −5, To fix;
sp=none while the main policy is stricter: −10, To fix.

For a domain that sends no email, the scale of the domain without email profile applies, without these adjustments.

Blacklists, weight 10

A blacklist (DNSBL) records the IP addresses that have sent spam. Emails from a listed address are rejected or sent to the junk folder by many recipients.

Addresses tested, 10 at most, in IPv4:

the addresses of MX servers that are not recognised as belonging to a provider (the domain's own server);
the single ip4: addresses (with no mask, or /32) written in the domain's SPF record.

The MX servers of every recognised provider are not tested, because their addresses are shared: suites (Microsoft 365, Google Workspace, Zoho, Proton, Fastmail, iCloud+, Amazon WorkMail, Yandex 360), hosting providers (OVHcloud, Gandi, Infomaniak, IONOS, Hostinger, o2switch, GoDaddy), filtering gateways (Mailinblack, Altospam, Vade, Mimecast, Proofpoint, Barracuda, Cisco Secure Email, Trend Micro, Sophos, Hornetsecurity) and local operators (Lagoon, Can'l, MLS, Nautile, Prolan). Their addresses serve many customers and the provider manages their reputation itself: without a single ip4: address in the SPF record, the check does not apply.

Lists queried (all tested on 31 October 2026 through Cloudflare and through Google)
List	Zone	"Listed" codes
SpamCop	`bl.spamcop.net`	`127.0.0.2`
PSBL	`psbl.surriel.com`	`127.0.0.2`
UCEPROTECT level 1	`dnsbl-1.uceprotect.net`	`127.0.0.2`
DroneBL	`dnsbl.dronebl.org`	`127.0.0.3` to `127.0.0.255`
0spam	`bl.0spam.org`	`127.0.0.1` to `127.0.0.254`

The "canary" check

A blacklist that refuses to answer may return a response that looks like "not listed". So that it never wrongly concludes that an address is clean, the tool first queries, for each list, its test entry 2.0.0.127.<zone>, which must always return a code. DroneBL, for example, answers 127.0.0.1 there.

The list is considered verifiable if this entry returns at least one address in 127.0.0.0/8, outside 127.255.255.0/24.
Otherwise (name does not exist, error, other code), the list is not verifiable for this analysis and is not taken into account.
For a tested address, a code outside 127.0.0.0/8, or in 127.255.255.x, is always treated as an error, never as "not listed".
An address that could not be checked on any list is reported as information ("partial check"), with no penalty.

Situation	Score	Severity
No address listed on the verifiable lists	100	Pass
At least one address listed: overall score capped at 49	0	Critical
Shared addresses of a recognised provider, or a domain that sends no email	not applicable	Information
No address to test, or no verifiable list	not verifiable	Information

Lists left out

Spamhaus refuses queries that go through public resolvers. Cloudflare returns the error code 127.255.255.254, and Google a "name does not exist" response that wrongly looks like "not listed". Its free use is, moreover, restricted to non-commercial purposes.
Barracuda requires users to register first.
Manitu does not respond to DNS-over-HTTPS queries.
Mailspike: its terms of use cannot be found on its current website, and commercial use is not confirmed.

What the tool cannot verify

DKIM selectors specific to each customer. OVHcloud, Amazon SES, Postmark and others assign a unique selector to each account. If it is not among the 57 selectors tested, DKIM is not verifiable: enter it in the "Custom selector" field. You will find it in the DKIM-Signature header of an email you have sent (the s= value).
Mailboxes behind a filtering gateway. When the MX is a gateway (Mailinblack, Vade, Mimecast…), the tool sees the gateway, not the email service behind it. Where it can, it infers that service from the other records, for example an SPF record that includes Microsoft 365.
What happens inside your email service. Accounts without multi-factor authentication, forwarding rules, spam filtering: none of this is visible in public DNS.
A snapshot. The result reflects DNS at the time of the analysis, as seen by the Cloudflare and Google resolvers. A recent change may not be visible yet.

Out of scope: MTA-STS, TLS-RPT, BIMI, DNSSEC, CAA and domain name blacklists.

Privacy

All queries go from your browser to the public DNS resolvers of Cloudflare (cloudflare-dns.com) and, as a fallback, Google (dns.google), which handle them under their own privacy policies.
The check sends nothing to SF2i: neither the domain checked nor the result.
The site sets no cookies, uses no local storage and does not measure its audience.
The PDF report is produced by your browser. The "Contact SF2i" button opens the contact form with a summary of the result, which you can edit: nothing is sent until you send it.

The details are set out in the legal notice.

Test your domain. The analysis takes a few seconds and applies exactly these rules. Run the test

Method and score calculation

How the test works

How the overall score is calculated

A worked example

"Not applicable" or "not verifiable"

The "domain without email" profile

Mail servers (MX), weight 10

SPF, weight 25

DKIM, weight 25

DMARC, weight 30

Blacklists, weight 10

The "canary" check

Lists left out

What the tool cannot verify

Privacy