Identify the Cloud SMTP Relay route
Check Point Harmony Email includes several security and mail-flow functions. This guide covers the documented Cloud SMTP Relay configuration, not the assumption that enabling inbound inspection automatically signs outbound messages. The relevant workflow uses domain configuration, DNS verification and an enabled relay source. Confirm that the tenant actually offers and uses this route before applying its instructions. Licensing, regional availability and the current account configuration have not been verified here.
The provider’s domain instructions use Security Settings, Relay and Domains. Its separate activation instructions use Relay Sources. That separation is operationally important: a verified domain and a source authorized to submit outbound messages are related controls, but they are not the same control. Do not report that the relay is ready solely because a DNS value was copied into a change request. Check Point DKIM configuration Check Point relay activation
Map each identity and its owner
Before obtaining records, identify the application or mail server that will submit through the relay. Record its responsible team, the intended visible author domain and the domain used for the SMTP envelope. Do not infer these values from an inbound mailbox setting or from the name of a security policy. The inventory should distinguish a known account configuration from an expectation awaiting confirmation.
SPF evaluates SMTP identities rather than simply the visible From field. DKIM associates a signature with a signing domain and selector. DMARC then evaluates whether a qualifying authenticated identifier aligns with the visible author domain. These protocol relationships explain why the relay’s configuration must be assessed against actual message identities, not just a branded security dashboard. RFC 7208, SMTP identities RFC 9989, identifier alignment
Assign a DNS owner and an application owner before the change. The DNS operator needs public record values and the intended fully qualified owner names. They do not need SMTP credentials, private signing material or unrelated user data. Any future account access or relay activation must follow the organization’s approval process. This manuscript performs none of those actions.
Resolve the SPF example defect rather than copying it
The provider’s August 2026 SPF page directs the operator to select the domain, open Configure SPF, add or update the record and use Verify. Its sample contains include:spfr.cpmails.com, but the table labels the record type MX while presenting an SPF text value. That is a source inconsistency, not a valid instruction to publish SPF as an MX record. Obtain the current account’s supported DNS instructions and resolve the mismatch before changing production. Check Point SPF configuration
RFC 7208 requires SPF publication in DNS TXT records. An MX record identifies mail exchangers and cannot carry an SPF policy in the way that sample suggests. Keep the documented include as a scoped provider example, not proof that it applies universally to every Harmony deployment or region. The actual owner name and full policy remain subject to account confirmation. RFC 7208, DNS resource records
Review the existing SPF policy before proposing an addition. Preserve still-authorized applications, retain one applicable policy and evaluate nested dependencies. The limit on evaluated DNS-querying terms is not simply a count of top-level include words. Do not change an existing final policy mechanism merely to make it resemble a sample. Record the intended security decision and the complete before-and-after policy separately from any provider verification result. RFC 7208, multiple records and lookup limits
Publish the entire account-provided DKIM set
The DKIM guide uses Configure DKIM in the selected domain and explicitly requires all five DKIM records to be entered in DNS. Its illustrative table shows a CNAME, but the example is not a complete five-record account configuration. Do not create only the one visible example, extrapolate the other names, or reuse an example target from another domain. Preserve the full generated set for the actual tenant and domain. Check Point DKIM configuration
For every supplied alias, review the owner name, target, record type and existing record conflicts. Confirm the editor’s handling of domain suffixes. The check should establish the resulting DNS name rather than assume that every interface expects either a relative label or a fully qualified name. A correct-looking screenshot can conceal a duplicated suffix or an entry in the wrong zone.
The provider instructs the operator to use Verify after publication and describes the domain changing to Verified. Preserve that result as evidence about the product’s validation step. It does not replace a later assessment of which signing domain and selector appear on actual mail, or whether a recipient successfully verified and aligned that signature. Check Point DKIM configuration RFC 6376, signature and key storage
Review relay-source activation separately
The November 2026 activation page says to enable the intended source, inspect the displayed relay host and port, verify the configured domain and sending IP addresses, and then activate the relay. Its default port is 25 with STARTTLS support. Use the actual displayed regional connection details rather than inventing a universal endpoint. Do not convert STARTTLS support into a claim that every downstream connection was encrypted or that a particular message completed delivery. Check Point relay activation
Treat source activation as a consequential operational change requiring the appropriate approval and rollback plan. A domain-verification task does not automatically authorize broadening relay access to additional addresses or applications. Keep the approved source list narrow and explain how each entry relates to an actual business sender. The final acceptance packet must distinguish DNS readiness, enabled-source state and successful submission evidence.
Fictional diagnosis: two shortcuts in one change
Imagine a fictional company, Birchline Repairs, preparing notifications from its service application. Its change request copies the SPF example’s MX label and includes only the single DKIM alias visible in the public table. The request then describes the whole relay as ready. This scenario is fictional and no DNS records or messages were tested.
The reviewer stops the incomplete request. The SPF policy must use TXT and be reconciled with the domain’s existing senders. The application owner must obtain the full five-record DKIM set from the correct domain configuration. The relay-source owner must separately confirm the intended submitting system and activation status. The problem is not an observed authentication outage; it is an incomplete evidence chain that would make any readiness claim premature.
Blank acceptance worksheet
- Exact Harmony product, relay route and tenant applicability: ______
- Application, submitting source and accountable owner: ______
- Visible author and actual envelope identity: ______
- Current account SPF instructions and resolution of type mismatch: ______
- Existing and proposed complete SPF policy: ______
- All five DKIM records, owners and targets: ______
- Authoritative DNS observations and timestamps: ______
- Domain verification result and limitations: ______
- Approved relay source, regional host and port: ______
- Activation approval, rollback and observed status: ______
- Received-message signing and alignment evidence: ______
Acceptance remains open
The worksheet is not filled with assumed tenant values. No records were published, source enabled, credentials handled or messages sent. Original catalogue evidence, human subject-matter review, source applicability, production routes, visual accessibility and owner release all remain open. Authentication can support identity validation, but it does not guarantee inbox placement or establish that a message’s content is harmless.