SPF, DKIM and DMARC contribute different evidence about an email. SPF assesses a connecting source against an evaluated domain's sending policy. DKIM verifies a domain-associated signature over covered message material. DMARC relates a passing authenticated identity to the domain in From and applies its policy framework.
They work together because no single green result answers every identity question. A useful implementation follows the message through the sending service, DNS dependencies and receiving system, preserving what each check actually established.
Give each check its own question
- Mechanism: SPF; Question answered: Does this connecting source satisfy the sending policy for the evaluated identity?; Important boundary: That identity need not be the visible From domain
- Mechanism: DKIM; Question answered: Does this domain-associated signature verify against its covered message material?; Important boundary: Verification does not establish that every part of the message or request is safe
- Mechanism: DMARC; Question answered: Does a qualifying passing identity align with From, and what assessment policy applies?; Important boundary: Receiver handling includes evidence beyond DMARC
The checks are related, but they are not three copies of the same test. A system can publish all three kinds of DNS record while an application still sends without the intended signature or domain alignment.
Follow SPF from the sending connection
For the MAIL FROM check of an ordinary message with a non-empty envelope return address, RFC 7208 §2.4 specifies that SPF evaluates the sending source using the MAIL FROM identity. The receiver consults that domain's published policy, which may refer to other policy data.
This is why the identity matters before any DNS edit. Adding a service to example.com's SPF record cannot repair an SPF evaluation that actually uses a service-controlled domain elsewhere. First establish what the message and route use.
Under RFC 7208 §2.3 and RFC 7208 §2.4, SPF can also evaluate HELO, and its specification defines handling for a null reverse-path. Those cases do not justify substituting an arbitrary domain from the message's display fields. Preserve the evaluated identity with the result.
An SPF pass does not create a signature over message content. Its evidence is about the evaluated source and identity at that receiving point.
Follow DKIM from signing to verification
A sending system applies a DKIM signature using a private key. Under RFC 6376 §3.6.2.1, verification uses public material found through that signature's signing domain and selector. The private key belongs in the authorised signing system, not public DNS.
Both signing and publication must work. A public key at the right name does not prove that the application signed its messages with it. Conversely, a present signature does not establish that its key can be retrieved or that verification succeeds after delivery.
Under RFC 6376 §3.7, DKIM protects the material covered by its defined signature calculation. A gateway that changes relevant content after signing can affect verification. The body-hash investigation guide explains how to trace a particular failure without guessing that every DKIM error needs a new key.
Use DMARC to connect evidence to From
DMARC evaluates the domain in the From address, using the applicable policy and alignment relationships. Under RFC 9989 §5.3.5, a message-level pass with an applicable policy and completed checks can come from either a passing aligned SPF identity or a passing aligned DKIM signature.
That pass condition is not a recommendation to configure only one mechanism. RFC 9989 §8 full-participation requirements include aligned SPF and DKIM, reporting and policy publication. Under RFC 9989 §7.4, domains publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures.
Mailbox providers can impose their own sender requirements as well. Google’s bulk-sender guidelines, for example, call for SPF, DKIM and DMARC. Keep a protocol's message-level result separate from compliance with a provider's entire sending policy.
Understand why the paths can survive differently
The following is a synthetic example, not an account test. A notification service produces a passing aligned SPF result and a passing aligned DKIM signature for its direct route.
Now consider two changes to that route:
- A forwarding service changes the connecting source seen by the final receiver. The earlier SPF result is not a guarantee of the later evaluation. If relevant signed content is preserved, the original aligned DKIM signature may still verify.
- A gateway alters signed content after the signing stage. DKIM may fail at the next receiver, while SPF depends on the final connecting route and evaluated identity.
Neither outcome is inevitable for every intermediary. Inspect the actual route, identities and verification results. This difference explains why the two mechanisms offer useful distinct paths without making either universally reliable through all forwarding or modification.
Keep configuration evidence separate from message evidence
A small service-level record is more useful than an unexplained domain-wide status. This fictional acceptance matrix illustrates the distinction:
- Service observation: Employee mail has a public DKIM key; Evidence still needed: Proof that the selected domain signs and verifies through its real route
- Service observation: Billing mail passes SPF for a provider domain; Evidence still needed: Its relationship with From and any aligned DKIM path
- Service observation: Marketing mail has a valid DMARC policy; Evidence still needed: Actual signing, authentication and policy-context evidence
- Service observation: A received message passes the relevant checks; Evidence still needed: Its business owner and approved use, assessed separately
For each service, retain the supported configuration, important identities and a representative original received message. Under RFC 8601 §7.1, use trusted receiving-system results; a pass assertion inserted by an untrusted sender cannot stand in for the receiver's work.
The sender inventory connects those records to owners. The DMARC record workflow joins publication to message and reporting verification.
Preserve the limits of the combined result
As the signature scope in RFC 6376 §3.7 and receiver handling in RFC 9989 §5.4 show, these checks do not encrypt the message for the recipient, establish the truth of its content or guarantee inbox placement. Transport security and protection of sensitive message content are separate concerns.
A compromised authorised service can still send authenticated mail. Likewise, a valid technical result does not establish that the organisation approved that particular application account or business request.
The useful combined outcome is therefore precise: the receiver evaluated the actual source and signature identities, found the required aligned passing path for From, and considered the relevant policy. Keep that evidence with the service and route that produced it. Three configured records are a starting dependency; verified, maintained communication is the operating result.
Preserve a bounded conclusion
In the fictional acceptance matrix, a public key only closes publication evidence. A provider-domain SPF pass still needs its relationship to From checked. For any claimed DMARC pass, retain the applicable policy and the specific aligned passing path, then keep account approval and content safety separate. No service configuration or message test was performed here.