Security check

DMARC check: stop anyone from forging your email

Without a correct DMARC policy, anyone can send mail that looks like it comes from your domain. We check your DMARC, SPF and DKIM and give you a prioritised fix list.

Run a free domain scan All checks →
Relates to: NIS2 · art. 21 — secure communications ISO 27001 · A.5.14 information transfer DMARC · RFC 7489

What we check

We read your domain's DNS and verify that a DMARC record exists, that the policy is p=quarantine or p=reject (not just p=none), that SPF and DKIM exist and that alignment works — what actually determines whether spoofed mail is stopped.

Why it matters

Forged senders are the most common way in for BEC fraud and phishing against your customers. A domain without p=reject protects neither you nor your recipients. It's also an explicit requirement in NIS2 and ISO 27001's secure-communication controls.

How Security Guru tests it

Common mistakes

  • p=none left in production — monitors but blocks nothing
  • SPF with ~all (soft fail) instead of -all
  • No DKIM at all, so DMARC rests on SPF alone
  • SPF record exceeds the 10-lookup limit and fails silently

What you get in the report

  • Current DMARC/SPF/DKIM status per record
  • Exactly what's missing and the DNS record you need to add
  • Prioritisation: what blocks the most risk first
  • Mapping to NIS2/ISO 27001 requirements

FAQ

Is SPF enough?

No. SPF alone doesn't protect the From address the user sees, and it breaks when mail is forwarded. DMARC on top of SPF + DKIM is what actually stops spoofing.

Is p=none enough?

Only as an initial monitoring step. p=none blocks nothing — forged mail gets through. The goal is p=quarantine and then p=reject.

Do you send test emails?

No. The check is passive and only reads public DNS records — no code or email leaves your environment.

Want to know your status?

Run a free scan or order a full Security Assessment — prioritised, not noise.

Run a free domain scan