How to Check SPF, DKIM and DMARC Using Message Evidence

SPF, DKIM and DMARC help authenticate email, but a delivery problem is not automatically a DNS problem. Account restrictions, credentials, queues, receiver policy, message content and reputation can also matter. Start with an actual message and its delivery evidence, not a guessed DNS selector or a promise that one record guarantees inbox placement.

What each mechanism establishes

• SPF: checks the connecting server against the envelope sender or applicable HELO identity. That identity can differ from the visible From domain.
• DKIM: verifies a signature using the signing domain and selector in the message. It does not encrypt the message or prove the human sender’s identity.
• DMARC: checks alignment with the visible From domain. An aligned SPF pass or an aligned DKIM pass can satisfy it; a failure in one mechanism alone does not necessarily mean DMARC fails.

Collect evidence from a real message

1. Use a controlled message from the affected legitimate sending route. Preserve its full headers and any delivery-status response privately; redact personal data before sharing them.
2. Identify the visible From domain, envelope sender and trusted receiver’s Authentication-Results. Do not trust an arbitrary header inserted earlier in the message path as the receiving system’s verdict.
3. For each relevant DKIM-Signature, read the actual d= signing domain and s= selector. Messages may contain more than one signature.
4. Compare authentication results and alignment. Forwarding can affect SPF, and message transformations can affect DKIM. A DMARC policy request and the receiver’s final disposition are different observations.

Query the relevant public records

These read-only shell templates require dig. Replace all example values using the domain and an actual message’s signature. The signing domain may differ from the visible From domain. Inspect any provider-documented CNAME delegation and its target as well as the requested TXT record.

DOMAIN=example.com
DKIM_DOMAIN=example.com
SELECTOR=replace-with-selector-from-message
dig +noall +answer "$DOMAIN" TXT
dig +noall +answer "$SELECTOR._domainkey.$DKIM_DOMAIN" TXT
dig +noall +answer "_dmarc.$DOMAIN" TXT

An empty abbreviated answer is not a complete diagnosis. Repeat the query with normal full output to inspect status, authority information and errors; check the authoritative servers if publication is in doubt. A TXT lookup is not a cryptographic signature-verification test or a complete evaluation of a nested SPF policy.

Interpret the results without overclaiming

For SPF, check that exactly one applicable policy exists and that the actual sending route is authorized within the protocol’s lookup limits. -all expresses fail and ~all expresses softfail; neither forces every receiver to reject or accept a message. See the SPF/DKIM reference for mechanisms and limits.

For DKIM, a missing guessed selector such as default or selector1 does not demonstrate that all mail from a domain is unsigned. Use the actual selector and sending-provider configuration. Signing must be configured on the relevant service; message volume alone does not enable it. Protect private keys wherever the signing system stores them.

This replaces an earlier interpretation of guessed selectors and public records as a definitive assessment of InterServer or another company’s mail. That evidence did not establish whether all messages were signed or what a domain owner’s rollout intentions were. No current domain-wide authentication verdict is made here.

DMARC policy and reporting

Review all legitimate sending streams before changing enforcement. A none policy requests no DMARC policy-based enforcement; quarantine or reject expresses stronger handling requests for failures, subject to receiver behavior. Aggregate reports require the appropriate destination and authorization; absent reports are not proof that every legitimate sender has been covered.

The current DMARC specification, RFC 9989 from May 2026, removed the legacy pct tag and introduced a testing tag. Older implementations and examples can differ. A historical pct=10 value is neither proof of an owner’s intentions nor a measurement showing that exactly 90% of spoofed messages reach inboxes. Legacy failure-report tags also depend on applicable reporting specifications, support and privacy review; fo=1 alone does not create a working report channel.

Use a representative sending cycle, actual receiver results, provider guidance and a recovery plan to decide when to tighten policy. Do not prescribe a universal one-week rollout or downgrade an existing strict policy just to copy an example. For panel-specific steps, see DMARC in cPanel and DMARC in Cloudflare.

References: SPF, DKIM and current DMARC.

Reviewed October 15, 2026. Shell syntax and synthetic DNS query behavior were checked in an isolated lab. No real-message signature, production policy, customer route or inbox-placement test is claimed.