Email Authentication Checker: Test SPF, DKIM, and DMARC Correctly

An email authentication checker helps you answer two different questions: are your domain’s DNS records published correctly, and do messages actually pass authentication when they reach a recipient mailbox? You need both checks to prevent spoofing and give legitimate mail the best chance of being trusted.

What an email authentication checker actually checks

Email authentication is not a login mechanism and it does not validate whether an individual recipient address exists. It is a set of standards that lets a receiving mail server evaluate whether a message is authorized to use a domain in its visible sender identity.

The three core standards are:

• SPF (Sender Policy Framework): checks whether the server that transmitted the email is authorized by the envelope-sender domain.
• DKIM (DomainKeys Identified Mail): verifies a cryptographic signature added to selected message headers and body content.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): applies a domain owner’s policy and requires SPF or DKIM to pass and align with the visible From: domain.

A useful checker therefore does more than tell you whether a TXT record exists. It should identify duplicate or malformed records, recursively evaluate SPF includes, find DKIM selectors, parse the DMARC policy, and—ideally—show authentication results from an actual delivered email.

There is a fourth control worth checking: reverse DNS, also called a PTR record. Receiving systems commonly evaluate whether the sending IP address has a sensible reverse DNS name and whether that name resolves forward again. PTR is not part of DMARC, but a poor or missing PTR can hurt mail acceptance or reputation.

Authentication is not the same as address verification

An email authentication checker evaluates a sending domain and message path. An email verifier evaluates whether a recipient address is syntactically valid and plausibly able to receive mail. Those are complementary jobs, not substitutes. An authenticated campaign can still bounce if its list contains invalid addresses; a valid recipient address does not make a spoofed message authentic.

The records you should expect to find in DNS

The DNS record syntax matters. Most authentication failures trace back to an incorrect hostname, an unintended duplicate TXT record, or a third-party sender that was never authorized.

SPF: one TXT record at the root domain

SPF is published as a TXT record at the domain that appears in the SMTP envelope sender, often called MAIL FROM, Return-Path, or bounce domain. A simple example for a domain that sends only through one provider may look like this:

example.com.  TXT  "v=spf1 include:spf.example-mail-provider.net -all"

Important SPF mechanisms include:

• ip4:198.51.100.24 authorizes one IPv4 address.
• ip6:2001:db8::/32 authorizes an IPv6 range.
• include:provider.example imports an external provider’s SPF policy.
• a authorizes IP addresses returned by the domain’s A and AAAA records.
• mx authorizes IP addresses used by the domain’s MX hosts.
• -all is a hard fail for all other senders.
• ~all is a soft fail, often used temporarily while inventorying senders.

SPF has a significant operational limit: an evaluation may cause no more than 10 DNS lookups across mechanisms such as include, a, mx, exists, redirect, and ptr. Exceeding that limit returns a permerror, not a pass. A checker that expands includes is especially valuable for detecting this before a mailbox provider does.

Publish one SPF TXT record per applicable domain. Splitting v=spf1 across separate TXT records does not combine policies; it can cause SPF to return permerror. DNS interfaces may display one long SPF record as several quoted strings, which is valid DNS record formatting when it represents one TXT record—not multiple SPF records.

DKIM: a selector-specific public key

DKIM uses a selector so that a domain can operate multiple signing keys and rotate them without breaking every sender. The receiving server reads the d= and s= values from the message’s DKIM-Signature header and queries:

selector._domainkey.domain.example

A simplified RSA DKIM public-key record looks like this:

s2026._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The long p= value is a public key, not a secret. Never publish a private DKIM key. Your email platform retains the private key and signs mail; DNS holds the public key that recipients use to verify it.

Some providers use CNAME records for DKIM rather than asking you to paste a TXT key. For example:

s1._domainkey.example.com. CNAME s1.example.provider-dkim.net.

That can be valid, but only if the platform specifically tells you to create the CNAME. Do not replace a required CNAME with a TXT record or vice versa. Also confirm that your DNS provider supports the record type and does not flatten or proxy it in a way that breaks lookup.

DKIM can technically verify even if its signing domain differs from the visible sender domain. DMARC determines whether that pass is useful by evaluating alignment, explained below.

DMARC: policy and reporting at _dmarc

DMARC is published at _dmarc.yourdomain. A starting policy can be:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100"

The important tags are:

• v=DMARC1 identifies the record version and must come first.
• p=none, p=quarantine, or p=reject states the requested treatment for mail that fails DMARC.
• rua=mailto:... requests aggregate XML reports.
• ruf=mailto:... requests failure reports, though many receivers do not send them and privacy rules can limit their contents.
• adkim=r or s sets relaxed or strict DKIM alignment.
• aspf=r or s sets relaxed or strict SPF alignment.
• pct=100 applies policy to all messages; a lower percentage can stage enforcement.
• sp= supplies a policy for subdomains when it differs from p=.

A DMARC record with p=none is monitoring, not enforcement. It asks receivers to send reports but does not request quarantine or rejection of unauthenticated, non-aligned mail. It is useful while discovering all legitimate systems that send as your domain, but it does not by itself stop impersonation.

How to use an email authentication checker: a repeatable process

The best workflow combines a public DNS inspection with a mailbox-header test. DNS tells you what you intended to authorize. A delivered message tells you what actually happened.

1. Decide which sending domains to test

List every domain visible in a From: address and every domain used for bounces or return paths. Include subdomains. Marketing and transactional systems are often separated, for example:

• example.com for employee mail
• updates.example.com for product updates
• mail.example.com for receipts and password resets

Test each separately. A valid DMARC record at example.com can govern a subdomain in some circumstances, but separate subdomain records and explicit sp= policy may change the result. Do not assume one root-domain check covers every mail stream.

2. Look up the DNS records

A web-based email authentication checker can query the records for you. For an independent check, use dig on macOS or Linux, or nslookup/PowerShell equivalents on Windows.

dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short TXT s2026._domainkey.example.com

Look for exactly one SPF policy beginning with v=spf1, a DMARC record beginning with v=DMARC1, and the exact DKIM selector your mail service says it uses. Do not rely on a DNS dashboard’s “verified” badge alone: query public DNS after publishing changes.

DNS propagation depends on caching and the TTL configured for the record. A resolver may retain a prior answer until its cached TTL expires, so check with more than one resolver if results look inconsistent. Changing records repeatedly during that period makes diagnosis harder.

3. Send a real message to a test inbox

Send from the same application, provider, and From: address used in production. Do not test only a provider’s built-in “send test” feature if production mail uses another custom domain, subdomain, or route.

Use a mailbox that exposes full message headers. In Gmail, open the message menu and select Show original. Other clients offer names such as “View source,” “View message details,” or “View raw message.” Find an Authentication-Results: header similar to this:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounces.mail.example.com;
       dkim=pass header.i=@mail.example.com header.s=s2026;
       dmarc=pass header.from=example.com

The exact labels and formatting vary by receiver. What matters is the result: SPF and/or DKIM must pass, and at least one passing identifier must align with header.from for DMARC to pass.

4. Read alignment, not just pass/fail badges

DMARC alignment is the point most basic checkers miss. It protects the domain people see in the From: field rather than accepting an unrelated authenticated domain.

With relaxed alignment, news.example.com aligns with example.com because both share the same organizational domain. With strict alignment, they must match exactly. The same concept applies to SPF’s envelope sender domain and DKIM’s d= signing domain.

For example, this can pass SPF but fail DMARC:

From: Example Store <offers@example.com>
Return-Path: <bounce@mailer-vendor.example>
Authentication-Results: ... spf=pass smtp.mailfrom=mailer-vendor.example;
    dmarc=fail header.from=example.com

The vendor’s domain passed SPF, but it is not aligned with example.com. If the vendor also signs as d=example.com or d=mail.example.com, and relaxed DKIM alignment applies, DKIM may allow DMARC to pass. Otherwise, configure a custom bounce domain and/or custom DKIM domain with that provider.

5. Check the policy, then monitor reports

Once real mail reliably passes, start DMARC monitoring with p=none and an rua address you can process. Aggregate reports arrive as compressed XML files from participating receivers. They show source IPs, volume, SPF and DKIM results, and the receiver’s DMARC disposition.

Reports are evidence, not a real-time alert feed. They can reveal forgotten systems such as a CRM, help desk, accounting platform, web host, or copier that sends invoices or scan-to-email messages using your domain.

After you identify and authenticate legitimate senders, advance deliberately to p=quarantine and ultimately p=reject where appropriate. The DMARC specification defines these policy values, but individual receiving systems retain discretion over final filtering and delivery decisions.

Worked example: checking a transactional sending domain

Assume a SaaS company sends password resets from no-reply@mail.acme.test through an email API provider. The visible domain is mail.acme.test, while the company’s employee mail continues to use acme.test.

The intended configuration

The provider asks Acme to create these records:

mail.acme.test. TXT "v=spf1 include:spf.provider.example -all"
mail.acme.test. TXT "v=DMARC1; p=none; rua=mailto:dmarc@acme.test; adkim=r; aspf=r"
p1._domainkey.mail.acme.test. CNAME p1.acme.provider-dkim.example.
p2._domainkey.mail.acme.test. CNAME p2.acme.provider-dkim.example.

The provider also configures its envelope sender as bounce@mail.acme.test and signs mail using d=mail.acme.test. That design gives Acme two aligned routes to DMARC success:

1. SPF can pass for bounce@mail.acme.test, which aligns with From: ...@mail.acme.test under relaxed alignment.
2. DKIM can pass with d=mail.acme.test, which exactly aligns with the visible From domain.

The check

First, query the records:

dig +short TXT mail.acme.test
dig +short TXT _dmarc.mail.acme.test
dig +short CNAME p1._domainkey.mail.acme.test

Then send a password-reset test and inspect its raw headers. A successful result could include:

From: Acme Security <no-reply@mail.acme.test>
Return-Path: <bounces+abc123@bounce.mail.acme.test>
Authentication-Results: receiver.example;
    spf=pass smtp.mailfrom=bounce.mail.acme.test;
    dkim=pass header.d=mail.acme.test header.s=p1;
    dmarc=pass header.from=mail.acme.test

This worked because the SPF domain is a subdomain of mail.acme.test, the DKIM domain exactly matches, and the receiver reports dmarc=pass. Acme should retain this message as a baseline for future provider or DNS changes.

A likely failure and the fix

Suppose the test instead shows:

spf=pass smtp.mailfrom=provider.example;
dkim=pass header.d=provider.example;
dmarc=fail header.from=mail.acme.test

The provider authenticated its own identity, but neither SPF nor DKIM aligns with Acme’s visible From domain. Adding the provider’s generic SPF include alone will not solve DMARC alignment if the envelope sender remains provider.example.

The fix is provider-specific: enable its custom return-path/bounce domain, publish its custom DKIM records, or both. Then send a new message and confirm dmarc=pass in the recipient’s headers. Do not change DMARC to p=none as a workaround; that masks the underlying identity mismatch.

Common email authentication checker errors and how to fix them

“No SPF record found” when a record exists

Check the exact envelope sender domain, not only the visible From domain. A platform may use bounce.example.com, mg.example.com, or a provider-owned domain. Also ensure the record is a public DNS TXT record, not an SPF-type DNS record left over from obsolete tooling.

SPF permerror or too many lookups

Audit all include: chains. Marketing tools often nest multiple includes, and each can trigger more DNS queries. Remove inactive vendors, use the provider’s documented consolidated include when available, and avoid unofficial SPF “flattening” services unless you understand how they maintain changing provider IP ranges.

DKIM key not found

Verify the selector character-for-character. s1._domainkey.example.com and s01._domainkey.example.com are different names. If the provider gave two or three selector records, publish all of them; it may rotate among them.

Also check whether your DNS manager appended the domain automatically. Entering the full hostname into a UI that appends example.com can accidentally create s1._domainkey.example.com.example.com.

DKIM body hash or signature failure

A body-hash failure can occur when a forwarding or security system modifies the message after signing, for example by adding a footer or rewriting content. It can also result from a broken signing integration. Compare headers from mail sent directly by the provider with headers after it passes through any relay, gateway, or forwarding service.

DMARC record syntax is invalid

DMARC requires a valid record at _dmarc.domain. Start with v=DMARC1; p=none. Be careful with semicolons, tag spelling, and the email URI in rua. If reports go to an external domain, DMARC requires additional authorization at that report destination domain; this is a frequent source of missing reports.

You pass authentication but still land in spam

Authentication is necessary infrastructure, not a delivery guarantee. Spam placement also depends on sending reputation, complaint rates, content, engagement, list quality, IP history, and recipient-side filtering. Passing SPF, DKIM, and DMARC means the identity check succeeded; it does not certify that a campaign is wanted.

Choosing a checker: DNS lookup, header analyzer, or DMARC platform

Different tools answer different questions. Use the simplest one that exposes the failure you need to diagnose.

For a small sender, a DNS checker plus test emails to a few major mailbox providers is often enough to establish a baseline. For a company with multiple SaaS senders, several domains, or high-value brand impersonation risk, DMARC aggregate reporting becomes essential because it exposes traffic that no one remembered to test.

Use vendor documentation for the exact hostnames, selector names, and CNAME-versus-TXT setup required by your sending platform. The standards are shared; the onboarding records are not.

A safe path from monitoring to DMARC enforcement

The goal of DMARC is not merely a green checker score. The goal is to let recipients reject forged mail while your legitimate streams continue to work.

A cautious rollout looks like this:

1. Publish valid SPF and DKIM for every known sender.
2. Publish DMARC with p=none and a working aggregate-report address.
3. Review reports until every meaningful legitimate source is authenticated and aligned.
4. Fix or retire unknown sources rather than automatically authorizing them.
5. Move to p=quarantine, optionally using pct= to stage application.
6. Monitor both reports and real business mail flows.
7. Move to p=reject when unauthorized traffic is understood and legitimate traffic consistently passes.

Do not interpret a source IP in a DMARC report as automatically legitimate. Attackers can generate mail that claims to be from your domain, and reports may include those attempts. Match legitimate sources to known vendors, account configurations, and expected traffic patterns before adding any authorization.

Subdomains deserve an explicit decision. If your organization never sends from arbitrary subdomains, an sp=reject policy can help prevent abuse of names such as billing.example.com. Test intentionally used subdomains first, because a parent policy can affect them.

Beyond SPF, DKIM, and DMARC

Modern mailbox providers may impose their own sender requirements, especially for higher-volume mail. Google’s sender guidance, for example, describes expectations around authentication and spam controls for Gmail delivery. Review the current Gmail sender guidelines alongside the documentation for your mail provider, because requirements can vary by sending volume and recipient system.

Other helpful controls include:

• TLS for SMTP transport: encrypts mail in transit between servers when supported; it is distinct from sender authentication.
• MTA-STS and TLS reporting: let a domain state that receiving mail servers should use authenticated TLS under a published policy.
• BIMI: can associate a brand indicator with authenticated mail, but it depends on a strong DMARC enforcement posture and may involve additional trademark and certificate requirements depending on the ecosystem.
• Dedicated sending subdomains: isolate transactional and marketing identities, simplify vendor alignment, and reduce the blast radius of a configuration mistake.

These controls do not replace the core three. Start with SPF, DKIM, and DMARC, verify them against real messages, then add transport and brand-trust layers where they fit your program.

How to know your setup is working

A successful email authentication check has objective evidence. You should be able to show all of the following:

• Public DNS returns one valid SPF record for each applicable envelope-sender domain.
• The SPF evaluation stays within the 10-lookup limit and returns pass for authorized sending infrastructure.
• Every active sending platform applies DKIM signatures that verify successfully.
• The DKIM d= domain and/or SPF envelope sender aligns with the visible From: domain.
• Test messages received at major mailbox providers show dmarc=pass.
• DMARC aggregate reports show expected sources, with legitimate traffic passing under the intended policy.
• Your DMARC policy has progressed beyond monitoring when your inventory is complete and the business can tolerate enforcement.

Save raw-header examples from each sender after a successful configuration. They make future incidents dramatically easier to investigate: compare a failing message’s From, Return-Path, DKIM-Signature, and Authentication-Results fields to the known-good baseline.

FAQ

What is the best email authentication checker?

The best approach combines a DNS checker that parses SPF, DKIM, and DMARC with a raw-header test from a real recipient mailbox. DNS confirms publication; headers confirm that a live message passed and aligned at the receiver.

Can SPF pass while DMARC fails?

Yes. SPF can pass for a provider-owned envelope sender such as bounce@vendor.example, while the visible From: address uses yourdomain.com. DMARC fails unless the SPF domain aligns with the From domain or aligned DKIM passes.

Do I need SPF, DKIM, and DMARC?

Use all three. DMARC relies on SPF and/or DKIM results, and DKIM provides resilience when SPF breaks during forwarding. Using both authentication methods gives DMARC two possible aligned paths to pass.

How long does DNS authentication setup take to work?

Record visibility depends on DNS caching and TTL values. After records are publicly resolvable, send a fresh message and inspect its headers; do not judge a new configuration from an email sent before the records were published.

Does DMARC reject every spoofed email automatically?

No. p=none only monitors, and recipient servers make the final handling decision. A properly configured p=reject asks receivers to reject mail that fails DMARC, but it does not control every destination’s implementation or stop lookalike domains that do not use your exact domain.