Validate your domain's email authentication by checking MX records, SPF, DKIM, and DMARC. Proper email authentication prevents spoofing, improves inbox placement, and protects your domain reputation from phishing. This validator produces a 0–100 score and actionable recommendations to improve deliverability and security. It is most useful when you are diagnosing real mail problems: messages landing in spam, outbound mail failing after DNS changes, missing domain authentication, or sending IPs that still look suspicious even after SPF and DKIM were added.
Email Validator
Troubleshooting guides
Use these guides to troubleshoot email authentication, spam placement, DNS propagation, and sender reputation issues.
Mail Goes to Spam Even With SPF and DKIM
What to check after SPF and DKIM pass, including DMARC, reverse DNS, and blacklist status.
DNS Changed but Email Still Fails: Full Checklist
A practical sequence for checking MX, SPF, DKIM, DMARC, propagation, and sender reputation.
Why Reverse DNS and SPF Are Both Needed for Email
Understand why domain authorization and server identity are both required for better delivery.
How to use the email validator
- Enter your domain (avoid http:// or www).
- Run validation to check MX, SPF, DKIM, DMARC, and reverse DNS signals.
- Use the recommendations to fix weak policies (e.g., SPF ~all → -all, DMARC none/quarantine → reject).
- If you make DNS changes, confirm propagation using DNS Propagation Checker.
Understanding your score
Your score reflects both completeness and strength of authentication policies. A domain with records present but weak policies (like DMARC p=none) can still score lower than an enforced configuration.
What each result means
MX missing: receiving mail for the domain will fail or route incorrectly. If the domain should receive email, MX is the first thing to fix.
SPF missing or weak: providers have less trust in your outbound mail. A soft policy like ~all is often acceptable during rollout, but long term you should move toward a deliberate policy based on your real senders.
DKIM missing: recipients cannot verify message integrity and domain alignment properly. This often hurts inbox placement even when SPF exists.
DMARC missing: your domain lacks an enforcement/reporting layer. That means spoofing protection is incomplete even if SPF and DKIM are configured.
Reverse DNS warning: the sending IP may not map cleanly to a hostname. For mail servers, missing or generic PTR often damages reputation and can trigger filtering.
What each record does
- MX: where email for your domain should be delivered.
- SPF: which servers are allowed to send mail for your domain.
- DKIM: cryptographic signatures proving messages weren't modified.
- DMARC: policy for failures + reporting visibility.
Recommended troubleshooting flow
- Confirm the domain has the correct MX records and they point to the intended mail provider.
- Check SPF and make sure only real senders are included.
- Verify DKIM selectors actually exist and signatures can be validated.
- Confirm DMARC is present and not stuck permanently at p=none.
- If sending still fails, verify reverse DNS using Reverse DNS Lookup.
- If mail still lands in spam, check the sending IP with IP Blacklist Checker.
- After making DNS changes, confirm propagation with DNS Propagation Checker.
Why SPF passes but mail still goes to spam
This is one of the most common misunderstandings in deliverability. SPF passing only proves that the sending server was allowed to send for the domain. It does not prove the message is trustworthy enough for inbox placement.
- DKIM is missing or not aligned with the From domain.
- DMARC is missing, weak, or not aligned.
- The sending IP has poor reputation or appears on a DNSBL.
- PTR/rDNS is missing or looks generic.
- Content, links, or engagement signals still look spammy to the receiver.
In practice, if SPF is green but delivery is still poor, the next checks should usually be rDNS and blacklist status.
Real-world validation scenarios
Scenario 1: New domain with MX but no DMARC
Mail can still flow, but spoofing protection is incomplete and reporting visibility is missing. Add a DMARC record early, even if you start with monitoring mode before moving to enforcement.
Scenario 2: SPF and DKIM pass, but Gmail still filters
Authentication is only part of the picture. Check sending IP reputation, PTR consistency, complaint rates, and whether the domain is new or low-trust.
Scenario 3: DNS records were updated today
If results look inconsistent, you may simply be inside the propagation window. Verify with DNS Propagation Checker before assuming the records are wrong.
What to do next after validation
- If MX is wrong, fix mail routing first before touching anything else.
- If SPF is bloated or inconsistent, simplify authorized senders and avoid unnecessary includes.
- If DKIM is missing, generate selectors in your mail platform and publish the matching DNS records.
- If DMARC is absent, add monitoring first, then tighten policy once you trust your senders.
- If authentication looks good but delivery is still poor, validate sending IP reputation and reverse DNS.
Frequently Asked Questions
What does an email validator check?
This tool checks a domain’s email authentication and routing: MX records (mail routing), SPF (authorized senders), DKIM (cryptographic signatures), DMARC (policy + reporting), and reverse DNS signals.
Why do SPF, DKIM, and DMARC matter?
They prevent spoofing and improve deliverability. Without them, attackers can impersonate your domain and providers are more likely to mark your mail as spam.
Why does SPF pass but emails still go to spam?
Deliverability also depends on reputation, content, and engagement. A valid SPF record is necessary but not sufficient—DKIM/DMARC alignment and clean sending IP reputation matter too.
Do I need DMARC if I already have SPF and DKIM?
Yes. DMARC tells receivers what to do when authentication fails and enables reporting. It’s the enforcement layer that ties SPF/DKIM together.
What’s a good email configuration score?
In general, 90–100 is excellent, 75–89 is good, 60–74 needs improvement, and below 60 indicates missing or risky configuration that can hurt deliverability and security.
How long do DNS changes take to apply?
DNS propagation depends on TTL and caching. Changes can appear quickly but may take up to 24–48 hours globally. You can monitor propagation while waiting.
Related tools
- DNS Records Lookup — inspect MX/SPF/DKIM/DMARC records
- IP Blacklist Checker — diagnose sending IP reputation issues
- Reverse DNS Lookup — verify PTR records for mail IPs
- DNS Propagation Checker — verify that new mail records are visible globally