Email Spoofing Protection Checker

Evaluate your domain's resilience against envelope and header spoofing by deeply validating SPF, DKIM, and DMARC alignments in accordance with RFC 7208, RFC 6376, and RFC 7489. Pinpoint policy gaps, cryptographic failures, and identifier misalignments to prevent exact-domain impersonation attacks.

No signup

Instant results

100% free

What Is Email Spoofing Protection

Why It Matters

Threat actors routinely exploit the SMTP protocol's inherent lack of sender authentication (RFC 5321) by manipulating the MailFrom envelope sender and the RFC 5322 From header. Implementing SPF provides path-based authorization, while DKIM provides cryptographic non-repudiation of message bodies and headers via RSA or Ed25519 signatures. However, true anti-spoofing requires DMARC (RFC 7489) to bind the authenticated identity from SPF or DKIM to the visible From header. Without a comprehensive, strictly enforced DMARC policy (p=reject or p=quarantine), organizations remain vulnerable to Business Email Compromise (BEC), spear-phishing, and domain reputation degradation, fundamentally undermining zero-trust email architectures.

Common Mistakes

Permissive DMARC Policies: Deploying DMARC with a 'p=none' policy perpetually without migrating to enforcement, neutralizing actual spoofing protection.

SMTP_TRANSACTION

RFC_5321_MAILFROM

RFC_5322_FROM

SPF_DNS_QUERY

ENGINE_V2

DKIM_PUBLIC_KEY_RETRIEVAL

How It Works

Step 1

DNS Record Resolution: We perform deep DNS lookups to extract TXT records associated with SPF, DMARC, and DKIM selectors for the specified domain.

Step 2

Syntax and Policy Validation: Each record is parsed against its respective RFC standard (e.g., RFC 7208 for SPF, RFC 7489 for DMARC) to identify syntax errors, unknown modifiers, or policy weaknesses.

Step 3

Alignment Verification: We simulate the authentication process, evaluating strict (adkim=s, aspf=s) versus relaxed alignment between the envelope/signing domains and the visible header domain.

Step 4

Cryptographic Key Assessment: If a DKIM selector is provided, we fetch the public key, validating its length, type (RSA/Ed25519), and revocation status.

Comprehensive DMARC Policy Analysis

Evaluates domain-level DMARC records for enforcement policies (p=, sp=), strict/relaxed alignment tags (adkim, aspf), and reporting configurations (rua, ruf) to ensure RFC 7489 compliance.

SPF Lookup Limit & Syntax Validation

Parses the SPF macro language to recursively count DNS lookups, ensuring the critical 10-lookup threshold (RFC 7208) is not exceeded, while checking for obsolete mechanisms like ptr.

DKIM Cryptographic Auditing

Inspects published DKIM public keys for cryptographic strength, identifying weak 1024-bit RSA keys and validating syntax for both RSA and Ed25519 (RFC 8463) algorithms.

BIMI Readiness Assessment

Verifies that the prerequisite authenticated foundation (DMARC at enforcement) is established before Brand Indicators for Message Identification (BIMI) can be successfully implemented.

Identifier Alignment Simulation

Simulates the binding process between authenticated domains (from SPF and DKIM) and the author domain (RFC 5322 From) to detect structural misalignments.

Subdomain Policy Inheritance Checking

Analyzes the explicit or implicit subdomain policies (sp=) to ensure organizational domains do not inadvertently expose unauthenticated subdomains to threat actors.

Frequently Asked Questions

Why is a DMARC 'p=none' policy insufficient for spoofing protection?

A policy of 'p=none' instructs the receiving Mail Transfer Agent (MTA) to perform no specific action on messages that fail DMARC authentication. While useful for initial monitoring and data collection via aggregate reports (rua), it provides zero mitigation against active spoofing. Organizations must transition to 'p=quarantine' or 'p=reject' to actively protect their domain reputation.

What happens when my SPF record exceeds 10 DNS lookups?

According to RFC 7208, an SPF evaluator must abort and return a PermError if the evaluation requires more than 10 DNS lookups (e.g., via include, a, mx, ptr mechanisms). A PermError causes the SPF check to fail, which can subsequently cause DMARC to fail if the message relies solely on SPF for alignment, leading to message rejection or quarantine.

Does SPF alone prevent email spoofing?

No. SPF (RFC 7208) only authenticates the domain in the SMTP envelope (RFC 5321 MailFrom) or the HELO/EHLO command. It does not authenticate the domain displayed in the email client (RFC 5322 From header). Threat actors exploit this by using a domain they control for the envelope while spoofing a legitimate domain in the From header. DMARC bridges this gap by requiring alignment.

How does DKIM alignment differ from DKIM authentication?

DKIM authentication merely verifies that the cryptographic signature in the DKIM-Signature header is valid for the domain listed in the d= tag. DKIM alignment (a requirement of DMARC) ensures that the domain in the DKIM d= tag matches the domain in the RFC 5322 From header. A message can pass DKIM authentication but fail DKIM alignment if signed by a third-party domain.

Why should I upgrade my DKIM keys to Ed25519?

RFC 8463 introduces Ed25519 as a public-key algorithm for DKIM. Ed25519 provides equivalent or greater cryptographic strength compared to 2048-bit RSA but with significantly shorter key lengths, which fit easily within a single UDP DNS packet (avoiding TCP truncation issues). It is faster to generate and verify, offering robust protection against modern cryptanalysis.

What is the difference between strict (s) and relaxed (r) DMARC alignment?

In strict alignment (adkim=s or aspf=s), the authenticated domain must exactly match the RFC 5322 From domain. In relaxed alignment, the authenticated domain and the From domain can have different subdomains, provided they share the same Organizational Domain (e.g., auth.example.com aligns with marketing.example.com under relaxed, but fails under strict).

Can I protect a domain that never sends email?

Yes. Defensive registration is highly recommended. For non-sending domains, you should publish an SPF record (v=spf1 -all), an empty DKIM record (v=DKIM1; p=), and a strict DMARC record (v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s). This explicitly instructs receivers to reject all emails purporting to originate from that domain.