[ Sending-service guides ]

Authenticate email sent through Forcepoint Email Security Cloud: configuration and verification

Create and enable Forcepoint Email Security Cloud signing rules with the account-specific CNAME pair, then test rule coverage and DMARC alignment.

By the EmailAuth research team · 4 min read

[ Key points ]

  • Publish both account-specific aliases for managed rotation.
  • A new signing rule stays OFF until checked and enabled.
  • Treat included and excluded sender-recipient combinations separately.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Treat included and excluded sender-recipient combinations separately.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Verify the complete sending route

The product panel, DNS and receiving mailbox establish different facts.

Next steps

  1. Preserve the exact generated values and prior DNS state.
  2. Inspect a received message from gateway-routed business mail.
  3. Record From, envelope domain, DKIM d=/s= and receiver results.

CISO / SecOps

Keep authority and recovery explicit

A signing delegation authorizes use of a domain identity; its scope needs review.

Next steps

  1. Approve the service and signing domain before delegation.
  2. Retain a tested recovery route for gateway-routed business mail.
  3. Require human review before stronger enforcement or removing old records.

Founder / Non-technical

Protect gateway-routed business mail

Authentication is part of a controlled service change, not an inbox-placement guarantee.

Next steps

  1. Name the business owner of gateway-routed business mail.
  2. Approve the intended sender and reply identities.
  3. Require a successful workflow test before broad rollout.

[ FAQs ]

Frequently asked questions

Is this the on-premises Forcepoint procedure?

No. It covers the Email Security Cloud policy portal. Verify the deployed product before using its menus.

Forcepoint Email Security Cloud: Adding a DKIM signing rule

Where do the DKIM aliases come from?

Use the CNAME section of Email > Settings > DNS Records & Service IPs for the actual account.

Forcepoint Email Security Cloud: DNS records and service IP addresses

Why publish two aliases?

They support the provider-managed key rotation scheme. Do not omit the secondary record simply because the first signature works.

Forcepoint Email Security Cloud: DNS records and service IP addresses

Does adding a rule turn signing on?

No. A new rule is OFF until its DNS check passes and you enable and save it.

Forcepoint Email Security Cloud: Enabling a DKIM signing rule

Can one sender domain appear in several signing rules?

The cloud documentation restricts it to one. Review existing coverage before adding a rule.

Forcepoint Email Security Cloud: Adding a DKIM signing rule

Can I exclude a sender-recipient combination?

Granular rule options support that scope. Test excluded traffic and document its remaining authentication path.

Forcepoint Email Security Cloud: Adding a DKIM signing rule

Does a successful CNAME check prove DMARC?

No. It proves a DNS prerequisite. Inspect a received message for authentication and alignment.

Should I remove the aliases to stop signing?

Use the documented rule state control with an approved recovery plan. Deleting DNS can also break delayed messages or other dependencies.

Forcepoint Email Security Cloud: Enabling a DKIM signing rule

[ Sources ]

Sources

  1. Forcepoint Email Security Cloud: DNS records and service IP addresses

    Sections CNAME records; two account-specific aliases and managed rotation

  2. Forcepoint Email Security Cloud: Adding a DKIM signing rule

    Sections Steps1–10: scope and granular combinations

  3. Forcepoint Email Security Cloud: Enabling a DKIM signing rule

    Sections Initially OFF; CNAME check; ON and Save; Recheck

  4. RFC 7208 SPF

    Sections §2.4 Checking authorization · §3.2 Multiple DNS records · §4.6.4 DNS lookup limits

  5. RFC 6376 DKIM

    Sections §3.5 DKIM-Signature header · §3.6.2 DNS binding · §6 Verifier actions

  6. RFC 9989 DMARC

    Sections §4.4 Identifier alignment · §4.10 DNS tree walk · §5.3.5 Determine DMARC pass or fail

[ Glossary ]

Glossary

DKIM
A signature mechanism that associates signed message data with a signing domain.
SPF
A mechanism by which an envelope domain authorizes sending hosts.
DMARC alignment
The relationship required between the visible From domain and a successfully authenticated SPF or DKIM domain.
Selector
The label used with a DKIM signing domain to locate its public key.
Authoritative DNS
The DNS servers responsible for the published data of a zone.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base