SPF and DKIM Records: Mechanisms, Results and Alignment

SPF and DKIM authenticate different aspects of email. SPF checks whether a connecting server is authorized for an envelope identity; DKIM verifies a cryptographic signature associated with a signing domain. Neither alone proves that a message’s visible From address is legitimate, safe or entitled to inbox placement. DMARC adds alignment with that visible address.

SPF identity, record and evaluation

SPF normally evaluates the SMTP MAIL FROM domain and also defines HELO checking, including handling of an empty reverse path. That identity is not necessarily the visible From address. Publish one SPF policy as TXT at the appropriate owner name, starting with v=spf1. Multiple applicable SPF records cause an error; the old dedicated SPF resource-record type is deprecated.

Evaluate the actual legitimate sending routes before publishing a policy. A documentation-only example is v=spf1 ip4:192.0.2.20 -all. It authorizes only that reserved example IPv4 address and ends with a fail result for other sources. Do not deploy it, a guessed provider include or copied IP ranges on a real domain.

Mechanisms and modifiers

Term	Meaning and cautions
ip4 / ip6	Match the connecting address against the specified network. Without a prefix length, the defaults are /32 for IPv4 and /128 for IPv6. For example, ip4:192.0.2.0/24 and ip6:2001:db8::/32 describe different documentation networks, not interchangeable address ranges.
a	Checks the relevant A or AAAA addresses for the selected domain against the connecting address. Authorizing a website address is useful only if it really sends the domain’s mail.
mx	Checks addresses of the selected domain’s mail exchangers. Receiving mail does not imply those systems should send your mail; MX preference is not an SPF authorization ranking.
include	Evaluates another domain’s SPF policy. A nested pass makes the mechanism match; it does not paste arbitrary TXT text into your policy. Nested errors can propagate. An included domain with no policy is not a successful authorization.
exists	Tests whether the specified expanded domain has an A answer. It is an advanced mechanism often involving macros, not a general proof of ownership or mail legitimacy.
ptr	Reverse-name matching is discouraged by the specification. Do not add it as a routine requirement or substitute for correct sending authorization.
all	Always matches and is normally the final mechanism. Later mechanisms cannot rescue an earlier all match. A policy containing +all authorizes every source and is not a protective configuration.
redirect=	Delegates policy evaluation when no mechanism has matched. It is not a DNS CNAME and does not act as a fallback after a matching all mechanism.
exp=	Can supply a failure explanation under the specification’s rules. It does not control delivery or guarantee that a recipient displays that text.

Mechanism qualifiers are + pass, – fail, ~ softfail and ? neutral; an omitted qualifier defaults to +. Do not prefix an intended authorizing include with ? and assume it still produces a pass. Modifiers such as redirect and exp have their own syntax and must not be duplicated.

The SPF DNS-lookup budget concerns lookup-causing terms, including nested evaluation and redirect, not simply ten packets or ten top-level includes. There are also additional limits, including guidance on void lookups. ip4, ip6 and all do not cause the same DNS lookups as a, mx or include. Review the expanded policy instead of adding records until it appears to work.

Results include none, neutral, pass, fail, softfail, temperror and permerror. Receiver policy decides delivery; -all does not compel every receiver to reject, and ~all does not guarantee acceptance.

How DKIM differs

A signing system uses a private key to sign selected headers and a body hash under specified canonicalization rules. The receiving verifier uses the public key associated with the signature’s d= domain and s= selector, queried at selector._domainkey.signing-domain. DKIM is a digital-signature system, not encryption that hides message contents.

Use the selector from an actual message or the signing provider’s configuration. Missing answers for guessed names do not prove a domain never signs mail. Keep private keys private; only publish the required public DNS material or documented delegation. Rotate keys using the provider’s procedure and account for in-flight messages.

A successful signature covers the signed data under its rules; it is not proof of every possible header, every later transformation, a human author’s identity or a harmless attachment. A third-party service can sign with its own domain without aligning with your visible From domain. For DMARC, an aligned pass from SPF or DKIM can be sufficient; both mechanisms do not have to pass.

Apply this to a hosted mailbox

Use the actual provider-generated records and authoritative DNS. See cPanel SPF/DKIM setup, the MailBaby SPF guidance where that sending route applies, and authentication diagnosis for message-header checks.

References: SPF specification, DKIM specification and current DMARC specification.

Reviewed October 15, 2026 against protocol specifications. Documentation network examples were checked; no production SPF evaluation, DKIM signing or inbox-placement test is claimed.