SPF, DKIM, and DMARC are email authentication controls that help prove whether a message really came from the claimed sender. They work together to reduce spoofing, improve domain reputation, and give receivers policy signals about how to handle suspicious mail. For tax communications, they are an important baseline against phishing.
What these email authentication controls do
SPF, DKIM and DMARC are not interchangeable, they solve different parts of the same trust problem. SPF checks whether a sending host is allowed to send for a domain, DKIM checks whether the message was signed by an approved key, and DMARC ties those signals to the visible From domain so receivers can make a policy decision.
Taken together, they reduce spoofing and make it harder for attackers to impersonate a brand or department. That matters because many phishing and invoice-fraud campaigns do not need to break encryption or malware defenses, they only need a message that looks legitimate enough to reach a mailbox.
How the mechanisms work together
SPF and DKIM each answer a different question, which is why DMARC needs both. SPF is evaluated against the envelope sender and the sending infrastructure, while DKIM validates message integrity and signing domain. DMARC then asks whether one or both of those checks align with the header From domain that the user actually sees.
This alignment step is the key governance feature. A message can technically pass SPF or DKIM and still fail DMARC if it is being sent by an unauthorised third party on behalf of the domain. That is why organisations often treat DMARC as the policy layer, not just another validation check.
For implementation detail, the rollout usually starts with monitoring and moves toward enforcement as confidence increases. NHIMG’s DMARC, SPF and DKIM Guide covers the alignment model, report types and the staged move from p=none to p=reject.
Operational considerations and visibility
These controls only work well when organisations understand every system that legitimately sends mail for their domains. That includes marketing platforms, support desks, payroll systems, ticketing tools and any outsourced sender that uses the brand domain. Missed inventory is one of the most common reasons legitimate messages fail or enforcement is delayed.
DMARC reporting is the main operational feedback loop. Aggregate reports show which sources are sending as the domain, while forensic reporting can help in deeper investigation where it is enabled and supported. That visibility is useful not only for blocking spoofing, but also for finding forgotten senders and shadow email services.
Receiver policy also matters. A domain that publishes DMARC but leaves policy at monitoring forever is giving itself only partial protection. The practical value comes from using the signals to clean up sending paths, then moving toward quarantine or reject when the environment is stable.
NHIMG’s Email Security Guide places SPF, DKIM and DMARC in the wider mail-security architecture, including routing, TLS and remediation.
Why spoofing still succeeds when deployment is weak
Attackers rarely need to defeat the cryptography itself. They often exploit organisations that have incomplete DNS records, broken alignment, unmanaged third-party senders or a policy that does not enforce action on failures. In that situation, receivers may still accept spoofed mail or users may still see convincing lookalike messages that appear to come from the right domain.
Another failure mode is key and record drift. DKIM keys expire, selectors change, mail vendors get added without being documented, or SPF records become too complex and hit practical lookup constraints. Each of those can create either delivery failures or gaps that attackers can exploit by sending through paths the organisation did not intend to trust.
For that reason, SPF, DKIM and DMARC are best understood as a baseline, not a full anti-phishing programme. They reduce impersonation risk, but they do not remove the need for user verification, mailbox protections, payment controls or incident response when a message still gets through.
Risk and Threat Considerations
Weak or misconfigured SPF, DKIM and DMARC create a direct spoofing and business email compromise exposure. If receiving systems cannot distinguish authorised mail from forged mail, an attacker can impersonate executives, vendors or finance contacts and use that trust to push fraudulent requests, credential theft or invoice diversion.
Failure mechanism: The attacker relies on unauthorised sending paths, missing domain alignment, or permissive receiver handling so that spoofed mail survives delivery and appears credible to the recipient.
Impact: The result can be phishing success, brand damage, fraudulent payments, compromised accounts, or broader loss of trust in the domain's mail reputation.
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, CIS Controls v8, NIST CSF 2.0 and OWASP ASVS 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 authenticators and keys used to validate mail identity. |
| IA-9 — Service Identification and Authentication | Applies when email systems authenticate services and sending systems to each other. | |
| Recommendation — Manage DKIM keys and related authenticators with defined issuance, rotation and revocation. Authenticate mail-sending services and verify trusted sending paths before accepting messages. | ||
| CIS Controls v8 | CIS-9 — Email and Web Browser Protections | Addresses email-borne phishing and spoofing controls that depend on mail authentication. |
| Recommendation — Deploy email protections that reduce spoofing and validate sender authenticity. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity and Access Management | Supports authentication controls that establish trust in message-sending domains. |
| Recommendation — Enforce authenticated mail-sending paths and align domain policy with receiver handling. | ||
| OWASP ASVS | V10 — OAuth and OIDC | Included because email identity abuse often couples with account takeover and mail access abuse. |
| Recommendation — Protect adjacent account-authentication paths so mail authentication is not undermined by account compromise. | ||
Practitioner Guidance
Why practitioners should care: Treat these controls as a domain-level trust boundary, not a one-time DNS task. Ownership needs to sit with whoever can inventory senders, review reports and coordinate changes across email, security and communications teams.
What to watch for: Watch for unknown sending sources, third-party services that were never documented, and any policy that remains in monitoring mode long after the environment is understood. Those are usually the signs that a domain is not ready for enforcement.
Practitioner takeaway: The strongest deployments are the ones that combine DNS policy with sender inventory, reporting review and deliberate enforcement, rather than assuming that published records alone stop spoofing.
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 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org