SPF helps validate sending hosts, but it is fragile when mail is forwarded or relayed. DKIM provides a cryptographic signature that survives more of the delivery path, so the two controls complement each other. When p=reject is the target, relying on SPF alone leaves legitimate traffic exposed to avoidable failure.
Why DKIM and SPF both matter before you turn on p=reject
DMARC enforcement gets much stricter at p=reject, so the real question is not which mechanism is “better,” but whether enough legitimate mail can still authenticate after it leaves your own sending path. SPF and dkim answer different parts of that problem, and the safest migration plans assume you need both to avoid blocking valid mail and missing spoofed mail.
What SPF proves, and where it breaks down
SPF is valuable because it ties a message to approved sending infrastructure. That makes it good at catching obvious unauthorized hosts, but it only works reliably when the path between sender and recipient stays close to the original envelope sender and IP relationship. Once forwarders, mailing lists, or relays change the delivery path, SPF can fail even when the mail itself is legitimate.
That fragility matters more as you move from monitoring to enforcement. At p=reject, a domain that depends on SPF alone can end up rejecting valid traffic that was forwarded, redistributed, or sent through a service not fully reflected in the SPF record. In practice, SPF is a strong host-control signal, but it is not stable enough by itself to carry an enforcement-only posture across every delivery route.
Why DKIM is the control that preserves message trust
DKIM solves a different problem: it signs the message content and selected headers so the recipient can verify that the message was authorized by the domain that signed it, even if the delivery path changes. Because the signature travels with the message, DKIM is usually more resilient than SPF in real-world email flows that include forwarding or intermediate infrastructure.
That resilience is why DKIM and SPF complement each other instead of replacing one another. SPF helps prove the sending host, while DKIM helps prove that the message content was signed by a trusted domain. When DMARC evaluates alignment, having both gives you more chances for legitimate mail to pass, and more ways to distinguish forgery from authorized delivery. For the control model behind that combination, see Email Identity and BEC Guide and NIST SP 800-53 Rev 5 Security and Privacy Controls.
What changes operationally when the policy becomes reject
Moving to p=reject changes the control from detection to enforcement. That means the weak point is no longer only spoofed mail, but also your own ability to predict how legitimate mail behaves across vendors, forwarding chains, and user workflows. If either SPF or DKIM is missing, broken, or misaligned, the domain can reject messages that users and business processes still depend on.
That is why the migration should be treated as an authentication coverage exercise, not just a DNS change. You need enough authenticated sending paths for normal operations, plus enough resilience for forwarding and indirect delivery. The right outcome is not “SPF or DKIM,” but a mail ecosystem where legitimate messages have more than one path to satisfy DMARC alignment.
Risk and Threat Considerations
At p=reject, weak authentication coverage turns into direct delivery failure, while overly permissive mail flows still leave room for spoofing and business email compromise. The risk is not abstract: if a legitimate sender depends on forwarding, relay, or a third-party service that only satisfies SPF or only satisfies DKIM, enforcement can either block good mail or create a false sense of protection.
Failure mechanism: SPF is defeated by delivery-path changes that alter the evaluated sending source, while DKIM can fail if a downstream system modifies signed headers or body content. If one control is absent, fragile, or not aligned with the visible From domain, DMARC enforcement has no stable fallback for that message.
Impact: Legitimate messages can be rejected, spoofed messages can still slip through poorly covered paths, and users may work around failures by lowering security expectations. That combination increases both operational friction and exposure to impersonation-based fraud.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Email sender authentication hinges on verified identities and trusted access paths. |
| Recommendation — Require verified sender identities and align mail authentication controls to the systems that send on their behalf. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Mail spoofing defense depends on controlling which systems may present a trusted domain. |
| Recommendation — Restrict outbound mail systems to approved identity and authentication paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Authenticator management | DKIM and SPF are authentication controls that support trustworthy email delivery. |
| Recommendation — Manage sender authentication mechanisms so legitimate mail can authenticate after forwarding and relaying. | ||
Practitioner Guidance
What to verify: Before moving the policy to reject, validate that your highest-volume and highest-risk mail flows pass DMARC through both direct delivery and realistic forwarding scenarios. Confirm that every critical sender has a working DKIM signing path, not just an SPF authorization entry.
Decision rule: If a message class can be forwarded, relayed, or re-sent by a third party, do not rely on SPF as the only surviving control. Treat DKIM as the durability layer and make sure the signing domain aligns with the identity you want recipients to trust.
Practitioner takeaway: p=reject is only safe when your mail authentication design can survive the messy parts of email delivery, not just the ideal path through your own infrastructure.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org