SPF vs DKIM vs DMARC: records, signatures, and alignment

Three mechanisms answer different questions

These mechanisms do not certify a sender’s honesty. They establish narrower facts about domains and message authentication. An authenticated message can still contain a deceptive request.

SPF: start with the actual sending path

SPF evaluates the connecting IP against the policy for the SMTP envelope identity, with HELO handling in relevant cases. It does not directly authenticate the human-readable From address. A domain should publish a single SPF policy record; multiple SPF records cause an error. The specification limits DNS-querying terms during evaluation, so long include chains need review. A tool’s static lookup estimate is not a full evaluation of every sending path. See RFC 7208.

For an investigation, list every legitimate sender first: ordinary mailboxes, newsletters, support software, and application notifications. Ask each provider for its current configuration instructions. Do not copy another organization’s record or add every mail server you can find; inbound MX servers are not necessarily the outbound senders.

DKIM: use the selector from a real message

A DKIM signature identifies a signing domain with d= and a selector with s=. A verifier retrieves the public key at selector._domainkey.signing-domain and checks the signature over the signed data. Publishing a key alone does not prove that messages are signed or that a signature passes. Changes to signed content can invalidate a signature. See RFC 6376.

Use a recent original message from each sending service. Enter its actual selector and signing domain in Email DNS Checker. If common-selector probing finds nothing, that means no key was found at the tested names; it does not establish that the domain has no DKIM configuration. Confirm signing in the receiver’s result too.

Worked example: both pass, but alignment fails

Consider this fictional message:

Visible From: [email protected]
SPF: pass for bounce.vendor.example
DKIM: pass for d=vendor.example

Neither passing identity aligns with example.com, so these results do not produce a DMARC pass. Now configure the service to sign with d=example.com. If that signature passes, the aligned DKIM identity can satisfy DMARC even when SPF does not align. Relaxed alignment permits the same organizational domain; strict alignment requires identical domains.

The current core specification is RFC 9989, published May 2026, which supersedes RFC 7489. DMARC policy discovery and organizational-domain determination use defined rules; do not implement alignment by simply comparing the final two labels of a domain name.

Roll out a policy with evidence

1. Inventory every legitimate sending service and capture a test message from each.
2. Confirm the intended SPF configuration and enable DKIM with each provider’s prescribed DNS records.
3. Check trusted receiver results and alignment for each message stream, including forwarding scenarios used by your organization.
4. Start monitoring with a reporting setup you control and review aggregate reports. A policy of p=none requests no DMARC enforcement; it does not make the underlying checks pass.
5. Resolve legitimate failures before requesting quarantine or rejection. Keep change records and a recovery plan for affected services.

For example, v=DMARC1; p=none illustrates a monitoring policy, but by itself supplies no reporting destination. Arrange reporting according to your provider and the applicable specification. Do not paste illustrative addresses or placeholder keys into production DNS.

Interpret the checker’s score carefully

Utiliverse’s DNS score summarizes the records it discovers. It is not a deliverability percentage, a phishing verdict, or proof that any message passed. The checker is not a complete RFC 9989 receiver: direct record checks and selector probes do not reproduce full policy discovery, alignment, and message evaluation. Use actual receiver results alongside DNS evidence.

Forwarding may change the IP evaluated by SPF, and message edits can affect DKIM. Diagnose the real path before blaming a sender or tightening policy. Successful authentication also does not guarantee inbox placement; receiving systems apply additional filtering and local policy.

Sources and review

• RFC 7208: SPF
• RFC 6376: DKIM
• RFC 9989: current DMARC core
• RFC 9990: aggregate reporting

Examples are illustrative. Reviewed September 28, 2026 against the sources above and the related tool interfaces. Editorial methodology · Report a correction.