How Do I Check Whether SPF, DKIM and DMARC Are Actually Working?

A proper authentication check has two layers

Most online checkers answer only the first layer: 'Does this domain publish an SPF, DKIM or DMARC record?' That is useful, but incomplete. The second layer is message-level verification: 'Did this specific message pass authentication using the domains and infrastructure that actually sent it?' A business needs both answers.

The difference becomes critical when several systems send for one domain. Human mail might leave through Google Workspace or Microsoft 365, invoices through an accounting platform, marketing through a campaign system, support through a ticketing tool and website notifications through an application server. Each can produce different SPF, DKIM and DMARC results.

A complete audit therefore starts with an inventory of senders and then captures at least one real message from each path. If you do not know every platform that sends as the domain, DMARC aggregate reports can help reveal additional sources before you tighten enforcement.

What does SPF actually authenticate?

SPF authorizes the IP address connecting to the receiving mail server to use the domain found in the SMTP envelope identity. It is often associated with the Return-Path that appears after delivery. SPF does not directly authenticate the visible From address in the way many users assume.

That distinction matters because a third-party platform may legitimately send on behalf of a business while using its own bounce domain. The platform can achieve SPF=pass for that bounce domain while the visible From address remains the business domain. DMARC then determines whether the authenticated SPF domain aligns with the visible From domain.

When you inspect a received message, record the SPF result and the domain against which it was evaluated. Do not stop at 'spf=pass.' A pass on a vendor domain may be technically correct while providing no aligned SPF path for the domain the recipient sees.

What should you verify in the SPF record?

Locate the TXT record that begins with v=spf1 for the relevant domain. Confirm that every mechanism is intentional and that all legitimate outbound services are represented. Then examine nested include and redirect chains rather than reading only the top-level record.

RFC 7208 requires SPF implementations to limit mechanisms and modifiers that cause DNS queries to 10 during evaluation. The include, a, mx, ptr and exists mechanisms and the redirect modifier can contribute to that total. If the evaluation exceeds the limit, the receiver must return permerror. Because includes can include other records, the visible record may look short while the real lookup count is high.

Also check the terminal policy. -all is a hard fail assertion for unmatched senders; ~all is softfail; ?all is neutral. The correct choice depends on whether the organization has fully mapped its senders and how it intends receivers to treat unauthorized infrastructure. Avoid changing the terminal qualifier merely to make a checker show green.

• Use `dig TXT example.com` or an equivalent DNS query to see the published SPF record.
• Trace every include and redirect to understand the full authorization tree.
• Count DNS-triggering terms across the evaluation path.
• Confirm there is one valid SPF policy for the domain rather than multiple competing v=spf1 records.
• Compare the authorized IPs or provider includes with the actual outbound infrastructure.

How do you verify DKIM on a real message?

Open the full source of a delivered message and find the DKIM-Signature header. RFC 6376 defines the d= tag as the signing domain and the s= tag as the selector. Those values are the key to finding the public key that the receiver used to verify the signature.

The normal DNS location is `selector._domainkey.signing-domain`. Depending on the provider, that name may publish a TXT record directly or a CNAME to a provider-managed key. The important question is not whether a DKIM record exists somewhere under the domain; it is whether the selector used on the message resolves to the correct active key.

Then read the receiving system's Authentication-Results header or equivalent. DKIM=pass means the receiver successfully verified the cryptographic signature. A missing DKIM result, fail, temperror or permerror requires different troubleshooting. If the message has multiple DKIM signatures, evaluate which one is aligned with the business's visible From domain.

• Identify `d=` and `s=` from the actual message.
• Resolve `s._domainkey.d` in DNS.
• Confirm the receiver reports DKIM=pass.
• Check whether the d= domain aligns with the visible From domain for DMARC.
• Repeat the test for every platform that sends on behalf of the domain.

How do you find the DKIM selector without guessing?

The best source is a message that the sending system actually signed. Read the s= value in DKIM-Signature. If no message is available, use the sending provider's administrative configuration or documentation. Do not assume selectors such as default, google, selector1 or s1 simply because they are common.

A domain can have several active selectors simultaneously. That is normal during key rotation and when different sending platforms use their own keys. A DNS enumeration tool may find some selectors but still miss the one that production mail is using. Message evidence is therefore more authoritative than guessing names.

What does DMARC actually check?

DMARC compares the domain in the visible RFC5322.From address with the domains authenticated by SPF and DKIM. Under RFC 7489, DMARC passes when at least one underlying mechanism passes and its authenticated identifier aligns with the visible From domain.

This means you can see SPF=pass and DKIM=pass but still get DMARC=fail if neither passing domain aligns with the From domain. Conversely, a forwarded message might fail SPF after the forwarding hop but still pass DMARC through an intact, aligned DKIM signature.

Read the `_dmarc.example.com` TXT record to understand the published policy and reporting addresses, but do not infer a message-level result from the record alone. The receiver's authentication result is the evidence of what happened to that message.

Relaxed and strict alignment change what counts as a match

DMARC supports relaxed and strict alignment modes for SPF and DKIM. In relaxed mode, related organizational domains can align; in strict mode, the domains must match more exactly. Most deployments use relaxed alignment unless there is a specific reason to enforce stricter identity boundaries.

This becomes important with subdomains and vendors. For example, a business may send from `sales.example.com` while a platform signs with `example.com`, or vice versa. Whether that relationship aligns depends on the organizational-domain rules and the DMARC alignment mode.

When troubleshooting, write down the exact visible From domain, SPF-authenticated domain and DKIM d= domain. Comparing those three values is more reliable than saying 'all records are installed.'

How to read Authentication-Results without being misled

A receiving server can record results such as `spf=pass`, `dkim=pass` and `dmarc=pass`, often with additional properties that identify the domains evaluated. Those properties matter. Authentication is about identities, not only pass/fail labels.

Be cautious when forwarding a message to another mailbox for analysis. The forwarding hop can change SPF evaluation and may alter the message. Whenever possible, inspect the original copy as received by the target provider or use the provider's 'show original' or message-source function.

Also distinguish between an authentication result generated by the final receiver and headers inserted by upstream systems. Trust boundaries matter. A malicious sender can write arbitrary header text, but a receiving system evaluates and records authentication at its own boundary.

What should Gmail senders verify today?

Gmail's current sender guidelines require all senders to personal Gmail accounts to use SPF or DKIM, maintain valid forward and reverse DNS for sending IPs, use TLS, follow message-format standards and keep spam rates below the required threshold. Senders above the high-volume threshold face additional requirements including both SPF and DKIM, DMARC and From-domain alignment, plus one-click unsubscribe for subscribed and marketing traffic.

Google recommends keeping Postmaster Tools spam rates below 0.10% and avoiding 0.30% or higher. It also recommends 2048-bit DKIM keys where supported and requires at least 1024 bits for mail to personal Gmail accounts. These details should be part of a production audit, especially after a migration or change in outbound infrastructure.

Why a DNS checker can say 'pass' while Gmail says 5.7.26

A checker may confirm that records exist and are syntactically plausible. Gmail evaluates the message that actually reached its infrastructure. If the message is not authenticated with the required methods, if the authenticated identities do not align as required, or if the sender violates other requirements, Gmail can reject or filter it regardless of what a generic scanner reports.

The same principle applies to other receiving providers. Always prioritize the receiver's actual error code and message-level authentication results over an abstract health score. The error tells you what the receiving system observed at delivery time.

How should a business test several sending systems?

Create a sender inventory before changing DNS. List every system allowed to send as the domain, including employee mail, CRM, accounting, marketing, support, website applications, monitoring systems and any legacy provider still in use. For each system, send a controlled message to test accounts at representative providers and capture the full headers.

Build a simple matrix with columns for visible From, Return-Path, outbound IP, SPF result and domain, DKIM result/d= and s=, DMARC result, TLS, receiving provider and final placement. The matrix quickly reveals whether one platform is the outlier.

• Employee mailbox platform
• Marketing or newsletter platform
• CRM or sales automation
• Accounting/invoicing platform
• Help desk or ticketing system
• Website/application notifications
• Monitoring/security alerts
• Any legacy sender that still appears in DMARC reports

What should you fix first when SPF fails?

First determine whether the sender is legitimate. If it is unauthorized, do not add it to SPF just to make the test pass. If it is legitimate, identify the precise outbound service and its documented authorization method. Then update the SPF policy without exceeding lookup limits or accidentally removing existing senders.

After DNS changes propagate, send a new message through that exact system and verify the result at the receiver. Do not treat the DNS edit itself as proof of repair.

What should you fix first when DKIM fails?

Confirm that the sending platform is signing, then compare its d= and s= values with DNS. A missing DNS record, stale public key, mismatched private key, revoked key, malformed record or message modification can all produce failure. The remedy depends on which layer is wrong.

If a platform supports key rotation, use a controlled rotation process. Publish the new public key, confirm the platform is ready to sign with the new selector, switch signing, verify live messages and keep the old selector available long enough for in-flight or queued messages to clear.

What should you fix first when DMARC fails?

Identify whether aligned SPF, aligned DKIM, or both are supposed to carry the message. Then correct the legitimate sender's identity path. Do not weaken DMARC policy blindly or change the visible From address without understanding the commercial and operational consequences.

If the domain is still in a discovery phase, aggregate reports can help map legitimate sources. A p=none monitoring policy is useful while building that inventory, but the long-term objective should be a correctly authenticated environment rather than permanent dependence on monitoring-only policy.

Safe command-line checks

On a Linux or macOS system with DNS tools, `dig TXT example.com` can retrieve SPF-related TXT data, `dig TXT _dmarc.example.com` can retrieve DMARC, and `dig TXT selector._domainkey.example.com` can retrieve a DKIM public key when TXT is used. If the selector publishes a CNAME, query the CNAME target as well.

These commands reveal DNS. They do not sign a message, verify a body hash or prove DMARC alignment. Pair them with message headers. If you manage your own SMTP server, also verify the outbound IP, EHLO hostname, PTR record and TLS path because authentication is only one part of deliverability.

What a professional authentication audit should deliver

A useful audit should leave the business with an authoritative sender inventory, current DNS state, message-level test evidence for every sending path, identified alignment failures, SPF lookup analysis, DKIM selector/key mapping, DMARC reporting posture and a prioritized remediation plan.

It should also identify change risk. Authentication changes can interrupt payroll notifications, invoices, password resets, CRM mail or marketing systems that nobody remembered were still active. A provider should have backups, rollback steps and post-change tests rather than editing production DNS interactively until a checker turns green.

DayneDillon's published Email Deliverability & Authentication Remediation service starts at $1,500. That type of engagement is most appropriate when mail is already failing, several platforms are involved, or the business cannot safely map and change production authentication on its own.

Frequently asked: is SPF alone enough for a small business?

Gmail's baseline requirement allows SPF or DKIM for all senders, but Google recommends configuring SPF, DKIM and DMARC for sending domains. Operationally, using all three gives a business stronger identity controls and visibility than relying on SPF alone. DMARC also creates a framework for alignment and reporting that SPF by itself does not provide.

Frequently asked: does DMARC p=reject improve deliverability?

It can strengthen anti-spoofing protection once the legitimate sending environment is correctly authenticated and aligned, but it should not be marketed as a direct inbox-placement switch. Reputation, complaints, content, infrastructure and recipient behavior still influence delivery. A misconfigured p=reject policy can also reject legitimate mail.

Sources and verification

These references support the factual claims used in this guide. DayneDillon separates published source material from observations that require investigation of an individual business.

• RFC 7208: Sender Policy Framework (SPF) ↗
• RFC 6376: DomainKeys Identified Mail (DKIM) ↗
• RFC 7489: DMARC ↗
• Google Gmail: Email sender guidelines ↗
• Google Gmail: SMTP errors and codes ↗
• Google Gmail: Postmaster Tools dashboards ↗
• Yahoo Sender Hub: Sender requirements and best practices ↗
• DayneDillon: Current email deliverability pricing ↗

Related DayneDillon resources

• How Do I Find My DKIM Selector? ↗
• Why Are My Emails Still Going to Spam With SPF, DKIM and DMARC? ↗
• Email Deliverability & Authentication ↗

Continue this investigation

• How do I find my DKIM selector? ↗
• How do I check email domain reputation? ↗