SPF/DKIM refers to two email authentication controls used to verify that a message was sent from an authorised mail source and that its contents were not altered in transit. SPF checks which servers may send mail for a domain, while DKIM uses a cryptographic signature on the message headers and body. Together they support anti-spoofing and mail trust decisions.
How SPF and DKIM work together
SPF and DKIM solve different parts of the same email trust problem. SPF checks whether the sending server is authorised for the domain in the envelope path, while DKIM adds a cryptographic signature that can survive routing changes and prove the message was signed by the domain owner.
Used together, they reduce spoofing in ways that either control cannot achieve alone. SPF is strongest when the message arrives directly from an expected sender, and DKIM is strongest when you need a content-linked proof that follows the message across relays, forwarding, or mailing infrastructure.
What SPF validates and where it breaks down
SPF is an allow-list mechanism for sending sources. A receiving system compares the connecting server against the domain's published policy, which helps stop forged return paths and unauthorised mail hosts from impersonating the domain.
Its weakness is that it depends on the visible sending path. Forwarding, shared mail platforms, and legitimate relays can cause SPF to fail even when the mail is authentic. That is why SPF is useful for source control, but not sufficient as a standalone trust decision.
Operationally, SPF also has a practical boundary: domain owners must keep DNS records accurate and within lookup limits, or evaluation becomes brittle. In practice, teams should treat SPF as one input to mail authentication, not as proof that the message content itself is intact.
What DKIM proves and why signature handling matters
DKIM signs selected message headers and the body with a domain key published in DNS. A valid signature shows that the signing domain approved the message content at the time of sending, which makes DKIM valuable for integrity and domain accountability.
Because the signature is tied to the message, DKIM is often more resilient than SPF when mail passes through intermediaries. However, it only helps when the signer controls key management well, selects stable headers, and rotates keys safely. Weak signing practices can create false confidence even when the mechanism itself is sound.
DKIM also needs careful alignment with downstream policy. A passing signature does not automatically mean the message is trustworthy to the recipient, only that it was signed by a domain that claims responsibility for it.
Why SPF and DKIM are foundational to email trust
SPF and DKIM sit at the front line of anti-spoofing because they influence whether a recipient can connect a message to an authorised sender. They support mailbox protection, payment fraud reduction, brand trust, and the broader controls that decide whether mail is delivered, quarantined, or rejected.
Their real value emerges when they are paired with domain alignment and policy enforcement. Without that, both controls can be present but ineffective, especially where attackers rely on lookalike domains, compromised mail infrastructure, or legitimate third-party sending services.
For defenders, the important idea is that these mechanisms help establish sender legitimacy, but they do not by themselves prove the user's intent or the safety of any link, attachment, or request inside the email.
Risk and Threat Considerations
SPF and DKIM reduce spoofing, but they do not eliminate email abuse. Attackers still exploit misconfigured DNS, weak sender governance, forwarding edge cases, and compromised mail systems to make malicious mail look legitimate enough to pass through filtering or user trust checks.
Failure mechanism: If SPF records are incomplete, overly broad, or brittle, unauthorised infrastructure can send mail that appears to come from the domain, while DKIM abuse or key compromise can let forged or tampered messages inherit a trusted signature.
Impact: The result can be phishing, invoice fraud, brand impersonation, and compromised mailbox trust, especially when recipients treat authentication results as a substitute for content verification or business-process checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Covers lifecycle control of email authentication secrets and keys used by DKIM. |
| SC-23 — Session Authenticity | Supports integrity and authenticity checks for transmitted content, analogous to DKIM message integrity. | |
| Recommendation — Manage DKIM keys with controlled issuance, rotation, and revocation. Verify message authenticity and integrity checks on inbound email flows. | ||
| CIS Controls v8 | CIS-5 — Account Management | Supports governance of authorised external sending sources and service accounts tied to mail delivery. |
| Recommendation — Inventory and review authorised mail senders and third-party relay accounts. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Email authentication failures are a direct authentication abuse pattern with spoofing consequences. |
| Recommendation — Treat failed sender authentication as a control break and investigate spoofing paths. | ||
| MITRE ATT&CK | T1566 — Phishing | SPF and DKIM are anti-spoofing controls that help blunt phishing delivery and trust abuse. |
| Recommendation — Map spoofed-mail detections to phishing techniques and tune mail controls accordingly. | ||
Practitioner Guidance
Why practitioners should care: SPF and DKIM are only useful when they are managed as operational controls, not one-time DNS settings. They need ownership, monitoring, and periodic review because sender inventories, mail vendors, and signing keys change over time.
What to watch for: Watch for third-party senders not reflected in SPF, DKIM selectors that are never rotated, and mail flows that break authentication after forwarding or migration. The most common failure mode is partial deployment, where records exist but do not match real sending behaviour.
Practitioner takeaway: Treat authentication results as a gate for delivery and triage, then pair them with user-awareness and payment-verification controls for any mail that can trigger business action.
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 November 3, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org