Provider documentation checked on 8 November 2026. Account-generated values, entitlements and current support remain deployment prerequisites.
Confirm the cloud product and the signing boundary
This guide concerns Forcepoint Email Security Cloud and its cloud policy portal. An on-premises Forcepoint gateway can have different menus, key handling and tests. Do not combine the two procedures because the vendor name matches. Record the cloud account, relevant email policy, sender domains, signing domain, DNS owner and affected outbound routes before changing anything.
A security gateway can successfully inspect messages without signing them with your domain. Likewise, an inbound antispoofing check is not outbound DKIM configuration. The task here is to establish which outbound messages receive which signature, then verify that signature at a receiving mailbox. Inventory messages that bypass the gateway; a rule cannot authenticate a route it never sees.
Publish the account-specific CNAME pair
References: RFC 1034 §3.6.2.
In Email > Settings > DNS Records & Service IPs, obtain the two DKIM CNAME records for the signing domain. Forcepoint manages the keys behind those aliases. Publish both account-specific records, including the secondary one used for rotation; the example number in the documentation is not your account identifier. The documentation says rotation occurs after six months and the secondary TXT key is published then; the secondary CNAME must still exist from the outset. Distinguish a correctly published alias from whether its managed target currently exposes a key, and use the service’s CNAME check rather than deleting the secondary alias as apparently unused. Keep the MX routing entries separate from these signing entries. Source: Forcepoint, DNS records and service IP addresses.
Before publishing, compare each full owner name with existing records. A CNAME owner cannot be treated as a bucket for competing targets. If another integration already uses that name, stop and resolve ownership rather than overwriting it. Check the resulting authoritative answers, including the alias targets, and retain a timestamped comparison with the supplied values.
Add the rule and make its coverage deliberate
Open Email > Policies > the intended policy > Antispoofing, then add a DKIM Signing rule. Name it, enter its sender domains or subdomains, and choose the signing domain. A sender domain can appear in only one signing rule. Optional granular settings can include or exclude sender and recipient combinations. Submit the rule and review that scope before activation. Source: Forcepoint, Adding a DKIM signing rule.
Treat exceptions as test cases, not merely configuration text. For a synthetic example, suppose billing@example.com to a partner is intentionally excluded while ordinary customer messages are included. Test both combinations and document why the exception is acceptable. If excluded messages have no other passing aligned authentication path, the signing rule has not solved their DMARC requirement. Do not interpret a working included case as coverage of every message.
New rules start OFF. After the CNAME check passes, set the rule ON and save. If the check fails, correct the DNS records and use Recheck; repeatedly toggling the rule does not repair DNS. Disabling a rule uses OFF followed by Save. Source: Forcepoint, Enabling a DKIM signing rule.
Prove the identity at the receiving system
References: RFC 9989 §4.4, RFC 9989 §5.3.5.
Send a controlled message through each relevant outbound route. Preserve the original received message, the receiver's trusted Authentication-Results, visible From domain, envelope domain and every DKIM d= and s= value. A passing SPF result authenticates the envelope identity; it does not by itself establish alignment with From. DMARC needs at least one passing aligned SPF or DKIM path under the applicable alignment mode.
Synthetic example: From is billing@example.com, SPF passes for vendor.example.net, and a valid DKIM signature uses d=example.com. The SPF domain is unrelated to From; the exact-match DKIM signature supplies the aligned path. If the signature fails, that path is lost. This illustrates protocol reasoning, not a measured Forcepoint default. For subdomain signing, check the actual alignment mode rather than assuming the parent's signature always meets strict alignment.
Recover without weakening unrelated mail
References: RFC 6376 §3.7.
If signatures are absent, first establish whether the message used the selected policy and matched the rule, including exceptions. If signatures exist but fail, compare their selector and signing domain with DNS and investigate changes made after signing. A valid signature with poor placement is a different investigation involving reputation, content and recipient handling.
Keep prior rule settings and DNS values with the change record. Disabling this rule is a recovery mechanism only if an approved alternative keeps necessary mail working; do not simply remove the sole aligned authentication path. Do not replace the domain's whole SPF policy or lower DMARC enforcement to mask one route. Completion requires authoritative DNS, enabled-rule evidence and received-message results for all intended cases. No live account, DNS or message test was performed for this documentary guide; independent checking, human SME approval and publication remain separate gates.