Validate your domain's email authentication stack in one scan. Checks SPF, DKIM, DMARC policy, and MX records — the four pillars that protect your domain from email spoofing, phishing, and delivery failures.
This tool checks one area. The full scan covers SSL, open ports, HTTP headers, breach exposure, subdomain enumeration, compliance mapping, and more — free, no login required.
Email authentication is a collection of DNS-based protocols that verify whether an email message genuinely originates from the domain it claims to represent. Without authentication, anyone can send email that appears to come from your domain — a technique known as email spoofing that powers the vast majority of phishing attacks.
Three protocols work together to form a complete email authentication framework: SPF (Sender Policy Framework) verifies the sending server's IP address, DKIM (DomainKeys Identified Mail) adds a cryptographic signature to verify message integrity, and DMARC (Domain-based Message Authentication, Reporting, and Conformance) ties them together with a policy that tells receiving servers what to do when authentication fails.
This email security checker validates all four components — SPF, DKIM, DMARC, and MX records — in a single scan, giving you a complete picture of your domain's email security posture.
| Protocol | Function | DNS Record | Protects Against |
|---|---|---|---|
| SPF | Authorizes sending IP addresses | v=spf1 ... TXT record | Unauthorized servers sending as your domain |
| DKIM | Signs messages cryptographically | selector._domainkey TXT record | Message tampering in transit |
| DMARC | Enforces policy on auth failures | _dmarc TXT record | Email spoofing and phishing |
| MX | Routes inbound email | MX record | Mail delivery failures, dangling records |
SPF is a DNS TXT record published at your domain's root that lists every IP address and server authorized to send email on behalf of your domain. When a receiving server gets an email, it checks the sending IP against your SPF record to determine whether the server is allowed to send as your domain.
A common mistake is exceeding the 10-DNS-lookup limit specified in the SPF standard. Each include: mechanism triggers a lookup, and exceeding the limit causes the entire SPF check to fail — meaning legitimate email gets rejected. Use our SPF Record Validator to check your lookup count.
v=spf1 include:_spf.google.com include:mail.zendesk.com ip4:203.0.113.0/24 -all
DKIM adds a cryptographic signature to every outgoing email. The sending server signs the message headers and body with a private key, and publishes the corresponding public key as a DNS TXT record. The receiving server retrieves the public key and uses it to verify that the message has not been modified in transit.
DKIM is critical for DMARC alignment. Even if SPF fails — which is common when email is forwarded — DKIM can still pass because the signature travels with the message regardless of which server delivers it. This makes DKIM the more reliable alignment mechanism for DMARC.
DMARC is the policy layer that makes SPF and DKIM actionable. It tells receiving servers what to do when authentication fails: monitor only (p=none), quarantine to spam (p=quarantine), or reject entirely (p=reject).
Critically, DMARC also adds an alignment requirement. Even if SPF or DKIM passes on its own, DMARC requires that the authenticated domain matches the From header domain that the recipient sees. This prevents attackers from using their own authenticated domain while spoofing yours in the visible From address.
Domains with no SPF, DKIM, or DMARC records are completely unprotected. Any attacker can send email as your domain, and receiving servers have no way to detect the spoofing. This is the most dangerous configuration and is increasingly flagged by cyber insurance underwriters as a disqualifying risk.
SPF alone only tells receivers which IPs are authorized — it does not tell them what to do with unauthorized messages. Without DMARC, a failed SPF check has no enforced consequence. Attackers can still spoof your domain, and the receiving server may still deliver the message.
A DMARC record with p=none provides visibility through aggregate reports but no protection. It is an acceptable starting point for monitoring, but organizations should plan to move to p=quarantine or p=reject within weeks. Compliance frameworks and cyber insurers increasingly require active enforcement.
SPF records are limited to 10 DNS lookups. Each include:, a:, mx:, and redirect= mechanism counts toward this limit. Exceeding it causes the SPF check to permerror, which most receivers treat as a fail. Consolidate your SPF record by replacing include mechanisms with direct IP ranges where possible.
Every service that sends email as your domain — marketing platforms, CRMs, helpdesks, transactional email providers — needs its own DKIM signing configuration. Without it, messages from these services will fail DKIM checks and, if SPF also fails alignment, will fail DMARC. Configure DKIM signing in each service's dashboard and add the required DNS records.
When you enter a domain, this tool queries your DNS records and analyzes all four components of email authentication in a single scan:
For a broader security assessment covering SSL/TLS certificates, HTTP security headers, open ports, breach exposure, and compliance mapping across 17 modules, run a full security scan.
Email authentication is a set of DNS-based protocols — SPF, DKIM, and DMARC — that verify a sender's identity and prevent unauthorized use of your domain in email. Together, they form a chain of trust that lets receiving mail servers confirm that a message actually came from your organization.
Yes. Each protocol addresses a different aspect of email security. SPF verifies the sending server's IP address. DKIM verifies message integrity with cryptographic signatures. DMARC ties them together with a policy that tells receivers what to do when checks fail. Without all three, there are gaps that attackers can exploit.
Not if done correctly. Start with DMARC set to p=none (monitor mode) and review aggregate reports to identify all legitimate email sources. Once every source passes SPF or DKIM alignment, gradually move to p=quarantine and then p=reject. The monitoring phase typically takes 2-4 weeks.
Third-party services like marketing platforms, CRMs, and helpdesks send email on your behalf. Each one needs to be authorized in your SPF record and configured with DKIM signing using your domain. Most major email service providers offer documentation for setting this up. Without proper configuration, legitimate email from these services will fail DMARC alignment.
Increasingly, yes. Most cyber insurance underwriters now check for SPF, DKIM, and DMARC as part of their external attack surface assessment. Domains without enforced DMARC (quarantine or reject) may face higher premiums, coverage exclusions, or outright denial. PCI DSS v4.0, SOC 2, and NIST 800-177 also recommend or require email authentication.
MX (Mail Exchange) records specify which servers handle email for your domain. Missing or misconfigured MX records cause email delivery failures. From a security perspective, MX records should point to servers you control, and domains that don't send email should have a null MX record to explicitly reject mail delivery.