Email Authentication Checker

Check SPF, DKIM, DMARC, and MX DNS records for a domain to identify email authentication, alignment, and deliverability issues.

Check a domain

How to use this email authentication checker

Use this checker before sending from a new domain, changing email platforms, or troubleshooting deliverability warnings.

  1. Enter the domain used in your email From address.
  2. Add a DKIM selector from your email platform if you want to test a specific DKIM key.
  3. Review SPF, DMARC, DKIM, and MX results in priority order.
  4. Update DNS records with your domain registrar, DNS host, or email service provider.

Email Authentication Checker features

  • Check SPF records for missing, duplicate, permissive, and high-lookup configurations.
  • Check DMARC records for missing policies, duplicate records, monitor-only policies, and enforcement.
  • Verify a DKIM selector when your email provider gives you one.
  • Show MX records as context for reply, bounce, and report routing.
  • Explain what each DNS record does, why it matters, and how to fix common issues.

Why email authentication matters

SPF, DKIM, and DMARC help mailbox providers verify that messages using your domain are legitimate. Good authentication can reduce spoofing risk and helps newsletters, campaigns, and transactional email meet modern sender requirements.

SPF lists which mail servers are allowed to send for a domain. DKIM adds a cryptographic signature that a mailbox provider can verify with a public DNS key. DMARC ties SPF and DKIM alignment to the visible From domain and tells receivers what to do when authentication fails.

Authentication does not guarantee inbox placement by itself. Reputation, complaint rates, bounce rates, content, list quality, sending volume, and mailbox-provider rules still matter. Clean DNS records are the foundation, not the whole deliverability strategy.

How the checker works

The checker looks up public DNS records for the domain, evaluates SPF and DMARC records on the expected hosts, optionally checks one DKIM selector, and reports the records it found without sending any email.

DNS changes can take time to propagate, so a new or edited record may not appear immediately from every resolver. If a provider asks you to add several records, publish them exactly as shown, then recheck after the provider's recommended waiting period.

A DKIM check requires the correct selector because DKIM keys are stored at selector-specific DNS names. If the selector is blank or wrong, SPF and DMARC can still be checked, but the DKIM result may not represent your actual sending setup.

The checker's terminology and selected configuration checks are based on the IETF specifications for SPF, DKIM, and DMARC. It identifies common DNS configuration problems rather than performing a complete RFC conformance test.

Email authentication FAQ

What domain should I check?
Check the domain after the @ sign in the From address your subscribers or customers see, such as example.com for hello@example.com.
Where do I find my DKIM selector?
Your email service provider usually shows the selector next to its DKIM setup instructions. Common examples are selector1, google, k1, default, or a provider-specific value.
Does this send a test email?
No. This checker inspects DNS records only. A real inbox placement test can still be useful after your DNS records are correct.
Why does my provider say DKIM is valid when this checker does not?
The most common reason is a selector mismatch or DNS propagation delay. Confirm the selector from your provider and recheck after DNS changes have had time to update.
Is a monitor-only DMARC policy enough?
A p=none policy is useful for collecting reports and validating setup, but it does not ask receivers to quarantine or reject failing mail.

Use DNS findings to plan a careful mail change

SPF, DKIM, and DMARC solve related but different problems. SPF authorizes sending infrastructure for an envelope domain. DKIM adds a cryptographic signature tied to a signing domain. DMARC checks alignment with the visible From domain and publishes policy and reporting preferences. Passing one does not mean the others are configured correctly.

SPF is specified in RFC 7208. A domain should publish one SPF record, and evaluation has a DNS-lookup limit. Do not solve a failure by stacking records or adding broad providers without knowing who sends mail. Inventory transactional systems, marketing platforms, support tools, forwarders, and on-premises services first.

DKIM verification depends on the selector used by a real message. A DNS checker cannot guess every selector or confirm that a sender is signing outgoing mail. Obtain a delivered header, identify its d= domain and s= selector, then confirm verification and key rotation with the provider.

DMARC is defined in RFC 7489. Start with reporting and review legitimate sources before moving toward quarantine or reject. Alignment, subdomain policy, percentage rollout, forwarding, and mailing lists can affect outcomes. A strict policy deployed without observation can block wanted mail.

DNS answers vary during propagation and can differ by resolver, cache, split-horizon configuration, or DNSSEC state. Record the queried name, record type, resolver, and time. Check authoritative DNS when a recent change looks inconsistent, and lower TTL before a planned migration rather than expecting caches to disappear immediately.

Do not copy a suggested record directly into production without matching the DNS provider's input format. Some interfaces add the zone name or quotation marks automatically. Keep a rollback value, use change review, and send tests through every legitimate service after publishing. Monitor DMARC aggregate reports and delivery logs for several normal sending cycles.

Pre-publish checklist

  • Inventory every legitimate sender and its envelope domain, visible From domain, DKIM signing domain, selector, return path, and forwarding behavior.
  • Publish one intentional SPF record, stay within evaluation limits, and remove obsolete providers rather than granting broad authorization.
  • Verify DKIM from real delivered headers and plan selector rotation; DNS presence alone does not prove outgoing messages are signed.
  • Collect and review DMARC aggregate reports before increasing enforcement, including legitimate forwarders, lists, subdomains, and third parties.
  • Record the authoritative DNS answer, TTL, resolver, query time, and expected propagation window for every change.
  • Use the DNS provider's exact host and value format, obtain review, keep a rollback, and avoid exposing private keys.
  • Send tests through every approved service and inspect receiver authentication results, alignment, spam placement, and bounces.
  • Continue monitoring after a passing check because providers, selectors, IP ranges, DNS records, and sending practices change.

Built and maintained by utilkit. Updated . Found an issue? Send corrections to contact@utilkit.com