CISA BOD 22-01

What this directive changes about email trust

CISA BOD 22-01 is about restoring trust in government email by making spoofing harder to succeed at scale. The practical security change is that messages claiming to come from a U.S. civilian agency should be validated against DMARC, SPF, and DKIM signals instead of being accepted on appearance alone.

That matters because email remains one of the easiest ways to borrow a trusted brand, impersonate leadership, or steer a recipient into approving a fraudulent request. Strong domain authentication reduces the chance that an external sender can convincingly masquerade as an official government address.

Why SPF, DKIM, and DMARC work together

SPF helps receiving systems check whether a sending host is allowed to send mail for a domain. DKIM adds a cryptographic signature that helps prove the message has not been altered and is associated with the domain that signed it. DMARC ties those signals together and tells receivers what to do when a message fails alignment.

Used together, the three controls reduce the gap between “looks legitimate” and “can be verified as legitimate.” For a directive like BOD 22-01, the objective is not only technical authentication, but consistent enforcement so domain impersonation becomes operationally expensive for attackers.

Why the directive focuses on impersonation risk

Email spoofing is dangerous because it turns trust in an organisation’s domain into a delivery mechanism for phishing, fraudulent instructions, and credential theft. Once a recipient believes a message is authoritative, the attacker may not need malware at all, only a convincing prompt to click, reply, transfer funds, or approve access.

Government environments are especially sensitive because one compromised mailbox, one trusted-looking notice, or one forged directive can create downstream compromise across staff, contractors, and external partners.

How organisations usually measure compliance and exposure

The operational question is not just whether DMARC exists, but whether the domain’s mail stream is inventoried, aligned, and protected across legitimate senders. Organisations typically validate sending sources, review vendor mail services, check alignment outcomes, and confirm that enforcement is actually active rather than left in monitoring mode.

That review often belongs alongside broader mail-security and remediation work. NHIMG’s Patch Management Guide is relevant because the same discipline that tracks assets, exceptions, and remediation timelines also helps organisations close security gaps created by unmanaged services and legacy mail paths.

For programme-level prioritisation, the Vulnerability Management Guide is useful where email authentication failures are treated as part of a broader exposure-management workflow, especially when teams need to track affected systems, owners, and remediation status.

When the problem involves bad actors already abusing trusted channels, the attack path often resembles credential theft and impersonation scenarios covered in Sisense breach 2024, where exposure of trusted material led to a need for decisive reset and containment.

What remediation looks like when enforcement is incomplete

When a domain is not yet ready for full rejection, organisations usually start by identifying every legitimate sender, fixing alignment problems, and reviewing forwarding, subdomain, and third-party mail use before moving policy from monitoring to quarantine or reject. The main challenge is not the policy syntax, but avoiding breakage while still eliminating spoofing opportunities.

That is why mail-authentication work often pairs with vendor oversight, change control, and security release discipline. The safest outcome is a stable sender inventory, clear ownership for each mail source, and a policy that reflects actual production mail flows rather than assumed ones.

External reference points can help teams verify the expected control intent. CISA Known Exploited Vulnerabilities Catalog is relevant as a prioritisation model, while CISA cyber threat advisories provide context for why email impersonation remains a persistent operational threat.

For organisations that want the broader security-design principle behind the directive, CISA Secure by Design captures the same philosophy: make abuse harder by default instead of relying on users to detect deception.

Risk and Threat Considerations

When domain authentication is weak or inconsistently enforced, attackers can exploit trusted branding to deliver phishing, bypass basic suspicion, and increase the chance of successful account compromise. The risk is not limited to message spoofing, because forged email can also support business email compromise, credential harvesting, and fraudulent approvals.

Failure mechanism: If legitimate sending systems are not fully inventoried or aligned, receivers may accept mail that appears to come from a trusted domain even when it was sent by an unauthorised source.

Impact: Recipients may disclose credentials, approve malicious requests, or trust false instructions, creating account takeover risk and broader organisational fraud exposure.

Practitioner Guidance

Why practitioners should care: This directive is less about a single configuration change and more about proving that your organisation can speak with one authentic email voice. If different teams, vendors, or legacy services send mail on behalf of the same domain, the governance problem is as important as the DNS record problem.

Practitioner note: Treat enforcement readiness as a mail-ecosystem exercise, not a one-time technical toggle. The teams that succeed usually know every sender, every exception, and every domain relationship before they tighten policy.

Related resources from NHI Mgmt Group

• How should federal agencies structure vulnerability management to comply with CISA BOD 22-01?
• CISA BOD 25-01
• What breaks when agencies rely on traditional pentesting for Directive 22-01 compliance?
• Binding Operational Directive 22-01