FREE TOOL
Is this domain set up to stop email spoofing?
This free tool checks a domain’s SPF, DMARC, DKIM, DNSSEC, CAA, MTA-STS, TLS-RPT, MX and HTTPS/HSTS records in about ten seconds, with no sign-up. It tells you whether the domain can be spoofed in email, whether its DNS can be forged, and whether it forces encrypted connections, each mapped to a CyFun control and a NIS2 duty.
What does this tool check on a domain?
- SPF
- Lists which mail servers may send email as this domain.
- Missing or broken SPF means anyone can send email that looks like it comes from this domain. RFC 7208 [1] also caps SPF at 10 DNS lookups; past that, receivers hard-fail it regardless of content.
- DMARC
- Tells receiving mail servers what to do with email that fails authentication.
- No DMARC policy (RFC 7489 [2]) means spoofed email still reaches the inbox even when SPF or DKIM exist.
- DKIM
- A cryptographic signature (RFC 6376 [3]) on outgoing mail, checked under five common provider selector names.
- This only rules out the most common selectors, not every DKIM setup. A different selector name is a false alarm, not a real gap.
- DNSSEC
- Cryptographically signs DNS answers for the domain (RFC 4035 [4]).
- Without it, a network-level attacker can feed forged DNS answers to a domain’s visitors.
- CAA
- Restricts which certificate authorities may issue a TLS certificate for this domain (RFC 8659 [5]).
- Without it, any public certificate authority can issue a certificate for the domain.
- MTA-STS
- Tells other mail servers to require an encrypted, authenticated connection when delivering mail here (RFC 8461 [6]).
- Without it, incoming mail can be silently downgraded to plaintext.
- TLS-RPT
- Asks for a report whenever another mail server fails to negotiate TLS to this domain (RFC 8460 [7]).
- Without it, a broken mail-encryption setup can go unnoticed indefinitely.
- MX
- The mail servers that handle email for this domain.
- Missing MX means the domain cannot receive mail at all. That is expected for a domain that only sends through another one.
- HTTPS (apex and www)
- Whether the site answers securely at both the bare domain and its www. address.
- A domain that does not answer over HTTPS cannot be reached securely by visitors.
- HTTP → HTTPS redirect and HSTS
- Whether plain http:// is redirected to https://, and whether the site sends a long-enough Strict-Transport-Security header (RFC 6797 [8]).
- Without both, a visitor can stay on, or be forced back onto, an unencrypted connection.
- security.txt
- A standard file (RFC 9116 [9]) telling security researchers how to report a vulnerability.
- Without it, someone who finds a flaw has no official channel to report it responsibly.
No single CyFun control covers SPF, DMARC or DKIM, and none covers DNSSEC [10]. Published SPF, DMARC and DKIM records are supporting evidence for PR.PS-05.1 (web and e-mail filters installed and used). The encryption-in-transit checks (HTTPS, HSTS, MTA-STS, TLS-RPT, CAA) map to GV.PO-01.2, whose policy must cover cryptography and encryption.
The full control catalogue is on the CyFun controls page, and what the law asks in detail is on the NIS2 requirements page.
What does a typical result look like?
A domain that sends newsletters through a marketing platform but has never touched its DNS beyond the original MX record typically fails SPF, DMARC and DKIM outright (nothing was ever published), passes MX (mail still arrives), and often passes HTTPS because the hosting platform forces it by default. That combination, modern hosting with no email-authentication records, is the single most common pattern this tool surfaces.
For MSPs: every finding here is something to show a prospect on screen, in under a minute, with nothing to install on their side: a way to open a NIS2 or CyFun conversation, or a quick sanity check before a managed-mail or managed-DNS engagement.
Running this across an MSP’s whole client base?
ECP runs the full CyFun assessment, under a conformity assessment body’s review, for every client an MSP manages, of which this domain check is one small slice.
See how ECP works for MSPs →Can I put this on my own site?
An embeddable, chrome-free version of this tool is available for MSPs to place on their own website, so a visitor runs the check without leaving the page.
Copy this into your page:
<iframe src="https://easycyberprotection.com/embed/domain-check?lang=en" style="width:100%;max-width:640px;height:720px;border:0" loading="lazy" title="Email and website security check for your domain (SPF, DMARC, DKIM, DNSSEC, HTTPS)"></iframe> This is how it looks on your website (a live preview, try it):
Frequently asked questions
- Does my company need to pass every check here under NIS2?
- NIS2 (Directive (EU) 2022/2555, Article 21(2) [11]) does not name SPF, DMARC or DNSSEC specifically. It requires risk-based cybersecurity measures, and most CCB CyberFundamentals control sets expect encryption-in-transit (which HTTPS, HSTS, MTA-STS and CAA cover) and a vulnerability-disclosure channel (what security.txt is for).
- Is this a full security audit?
- No. It checks a specific set of public DNS and HTTPS records and headers, one slice of a CyFun or NIS2 conformity assessment, not the whole thing. A pass on every check here does not mean the domain, or the organisation behind it, is compliant.
- Why does DKIM say "fail" when mail actually has a working signature?
- The DKIM check only looks under five common selector names (google, selector1, selector2, default, k1). A mail provider using a different selector shows as a fail here even though DKIM is correctly configured. This is noted directly in the result.
- Does this store the domains people check?
- No. The result is cached briefly to avoid re-running the same lookups, and each call is logged against the caller’s IP address for rate-limiting only. No domain, email address or result is kept beyond that.
- Can I check someone else’s domain, like a prospect’s?
- Yes. Every check here reads only public DNS and HTTP responses, the same information any browser or mail server already sees, so there is nothing to authorise.
- What happens if the CCB changes the CyFun catalogue or NIS2 is amended?
- The CyFun control ids here are checked against the CCB’s own catalogue (packages/api/src/frameworks/cyfun/controls.yaml) and the NIS2 Art. 21(2) letters against Directive (EU) 2022/2555 [11] directly, both re-verified whenever either source changes, not hand-typed once and left to drift.
Related free tools
- CyFun readiness quiz 19 plain questions covering the 34 controls of CyberFundamentals (CyFun) 2025 Basic. A score and a fix-first list, no email needed.
- NIS2 fine calculator Pick what the Belgian NIS2 law makes your company and enter your group turnover. See the highest fine it allows.
CyFun control catalogue · What NIS2 Art. 21(2) requires · Email security basics
2026-11-03
Computed with the free tool at https://easycyberprotection.com/learn/tools/domain-check/, by Easy Cyber Protection.
#CYBERLEARN
Train the team: Foundation
See the course →Sources
- RFC 7208: Sender Policy Framework (SPF)
- RFC 7489: DMARC
- RFC 6376: DomainKeys Identified Mail (DKIM)
- RFC 4035: DNSSEC protocol modifications
- RFC 8659: DNS Certification Authority Authorization (CAA)
- RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
- RFC 8460: SMTP TLS Reporting (TLS-RPT)
- RFC 6797: HTTP Strict Transport Security (HSTS)
- RFC 9116: security.txt
- CCB: CyberFundamentals (CyFun) control catalogue
- Directive (EU) 2022/2555 (NIS2), Art. 21(2)