IT Partner? See how to deliver NIS2 audit-readiness

View partner offer →
← Free tools

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.

By · Founder, Easy Cyber Protection · · How we write this

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):

yourcompany.be/security-check
Your company

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 control catalogue · What NIS2 Art. 21(2) requires · Email security basics

Use this with your clients

#CYBERLEARN

Train the team: Foundation

See the course →

Sources

  1. RFC 7208: Sender Policy Framework (SPF)
  2. RFC 7489: DMARC
  3. RFC 6376: DomainKeys Identified Mail (DKIM)
  4. RFC 4035: DNSSEC protocol modifications
  5. RFC 8659: DNS Certification Authority Authorization (CAA)
  6. RFC 8461: SMTP MTA Strict Transport Security (MTA-STS)
  7. RFC 8460: SMTP TLS Reporting (TLS-RPT)
  8. RFC 6797: HTTP Strict Transport Security (HSTS)
  9. RFC 9116: security.txt
  10. CCB: CyberFundamentals (CyFun) control catalogue
  11. Directive (EU) 2022/2555 (NIS2), Art. 21(2)