Check Point Harmony Email SPF, DKIM and DMARC setup, step by step

To authenticate mail sent through Check Point Cloud SMTP Relay, onboard the sending domain, publish the relay subdomain's account-specific MX and SPF TXT records, add all five generated DKIM records, verify the domain, and activate the intended relay source. Finish by checking a received message for a passing, aligned branded DKIM signature and a DMARC pass. This guide covers the Cloud SMTP Relay route in Harmony Email/Check Point Email Security, not every Avanan inbound-protection deployment. Check Point relay workflow

Important SPF correction: Check Point's current SPF example labels its record type “MX” while showing v=spf1 include:spfr.cpmails.com ~all. SPF belongs in a TXT record. Do not put that string in MX or replace your main mailbox MX. The protocol resolves the record-type error; your account must supply the correct owner and authorization for your deployment. Provider SPF example, RFC 7208, section 3.1

No customer account, DNS change or delivery test was performed for this guide.

On this page

• Confirm the product and prerequisites
• Map domains and DNS ownership
• Configure relay MX and SPF
• Publish all five DKIM records
• Activate the correct relay source
• Check DMARC alignment
• Verify DNS and received messages
• Troubleshooting and recovery
• Frequently asked questions

Confirm the product and prerequisites

The current Cloud SMTP Relay overview identifies the feature as Early Access, enabled through Check Point Support. Confirm entitlement and availability in your tenant before scheduling DNS or routing changes. The same overview requires TLS for SMTP submission and lists a 25 MB maximum message size including attachments. An internal sender that cannot negotiate TLS needs an approved internal relay or adapter, not a public plaintext exception. Cloud SMTP Relay overview

You need:

• An administrator who can manage Security Settings → Relay, plus an approved change window.
• Access to the authoritative DNS zones for the sending domain and any delegated subdomains.
• The application's actual submission path, its public egress IP where IP authentication is used, and its intended From address.
• A controlled external mailbox for authorized test messages and access to raw headers.
• A backup of current DNS and relay settings, an accountable rollback owner, and an inventory of other legitimate senders.

An Avanan entry in a recipient's DMARC report does not, by itself, establish that your organization uses this outbound relay. Identify the route first. If your mail originates in Microsoft 365, its separate signing configuration remains relevant; see our Microsoft 365 authentication guide.

Map domains and DNS ownership

Open Security Settings → Relay → Domains → Onboard Domain. Enter the approved sending domain, review the External type, add a useful description and onboard it. Configure a domain

Keep this identity map in the change record:

Check Point requires the SMTP envelope sender and parsed From header to belong to the same configured parent domain. It documents envelope rewriting to a managed return-path domain, preservation of the visible From header and selection of the deepest matching configured domain. Each configured domain or subdomain needs its own DNS setup. The page's examples are not consistent enough to derive a tenant's exact identities: obtain the generated records and verify the actual message, especially when both parent and child domains are configured. Sender-domain selection

For DNS input, distinguish the fully qualified owner from the editor's relative label. For example, a fictional cp1._domainkey.example.com owner becomes cp1._domainkey in an editor that appends example.com; it remains the full name in an editor requiring an FQDN. Neither label is a record to copy for your tenant. Check the resulting owner for a duplicated suffix.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

If _domainkey.example.com or the relay subdomain is already delegated with NS records, its authoritative child zone controls records beneath it. Editing the parent zone may do nothing. Do not replace that delegation or move other senders' selectors to accommodate one new service. Resolve ownership with the existing DNS administrator.

Configure relay MX and SPF

Keep relay MX separate from mailbox MX

For the selected domain, open Configure MX. Copy the exact relay-subdomain host, regional target, priority and TTL from the supported account instructions, publish them at that owner, then use Verify. Check Point explicitly limits this MX configuration to the relay subdomain. Its public regional table is not permission to choose another region or alter the root domain's inbound mail routing. Relay MX requirements

Receiving the account packet is not approval to change routing. Before publication or source activation, have the routing owner approve the exact relay-subdomain MX design and reconcile its complete owner, numeric priorities and target hostnames with the authorized routing plan. Preserve root mailbox routing and stop if the packet conflicts with that plan. At verification, compare the complete approved set, not merely the issued set, at both the authoritative DNS server and a recursive resolver; missing or unexpected entries must be resolved before activation. MX owner and preference semantics.

Publish SPF as TXT at the actual envelope owner

Open Configure SPF for the same domain. Reconcile its DNS Entry with the envelope/relay owner above. The documented Cloud SMTP Relay include is include:spfr.cpmails.com, but the public owner cpmails.example.com is illustrative. Do not substitute a different Avanan inline-security include or a managed-SPF add-on recipe. If the tenant repeats the MX label or gives an unclear owner, obtain corrected account instructions from Check Point before applying the change. Configure SPF

At the exact SPF owner:

1. Read the existing TXT records and preserve unrelated verification records.
2. If an SPF policy exists, merge the authorized service into that policy before its terminal all; do not add a second v=spf1 record.
3. Preserve other legitimate sending mechanisms and the existing ~all or -all decision unless a separately reviewed policy change is intended.
4. Evaluate the complete policy for the actual sending IP. SPF permits at most ten evaluated DNS-dependent mechanisms/modifiers, including nested include and redirect dependencies. a, mx, ptr and exists also count; ip4, ip6 and all do not. This is not simply ten top-level includes or ten raw DNS packets.
5. Publish, check authoritative DNS and use the provider's Verify control.

These safeguards follow RFC 7208. Do not flatten a provider include into an unmanaged snapshot of its current IPs: an infrastructure change can make that snapshot wrong.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Publish all five DKIM records

In Relay → Domains, select the domain and open Configure DKIM. Capture the entire generated DNS Entry set. Check Point requires five records; the single CNAME in its public table is only an example. Do not invent the remaining four names, copy another tenant's targets or shorten the set to the selector currently visible in one message. Configure DKIM

For each supplied record, preserve its type, complete owner, target/value and TTL. Publish CNAMEs as DNS-only aliases, not proxied web records or flattened A/AAAA answers. Do not place a CNAME beside a TXT, A or another conflicting record at the same owner. Stop and investigate any collision rather than deleting another service's key. Publish only the public values; private keys and SMTP passwords never belong in DNS. DNS alias rules

If Cloudflare hosts a required DKIM alias, check DNS only, turn that record's Flatten option off where available, and check the zone-wide CNAME flattening for all CNAME records setting. DNS-only by itself does not prevent flattening. Coordinate any shared zone-setting change with its DNS owner so other services are not disrupted, and preserve a valid child-zone or _domainkey NS delegation by publishing with its actual operator. Cloudflare CNAME verification troubleshooting, Cloudflare flattening settings

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

After the entire set resolves, select Verify and confirm the domain shows Verified. This confirms the provider's DNS check, not a recipient's DKIM result. Allow for cache expiry, but investigate an incorrect authoritative answer immediately rather than waiting blindly for the documented detection allowance of up to 72 hours. DNS detection guidance

Activate the correct relay source

Under Relay Sources, add or select the approved submitting application. Current documentation supports IP-based authentication, Basic SMTP Authentication or both. When both are configured, both must pass. Use an approved secret store for the generated credentials and keep the permitted source scope narrow. DNS authentication does not grant an application relay access. Add a relay source

Choose Enable source, review the displayed regional relay hostname and port, confirm the source/domain settings, and activate only that intended source. Configure the application to submit to those account-issued connection details. Domain verification and source activation are distinct checkpoints. Do not infer a working encrypted connection from a port number or a green DNS status; confirm TLS and submission in the application's and relay's logs. Activate Cloud Email Relay

Check DMARC alignment

DMARC passes when SPF passes with an aligned envelope domain, or DKIM passes with an aligned signing domain. Relaxed alignment compares organizational domains; strict alignment requires exact domain equality. Thus d=example.com and visible From alerts.example.com may align under relaxed DKIM alignment but not strict adkim=s. A branded Reply-To or successful SMTP login does not establish alignment. Current DMARC specification, RFC 9989

Retain the applicable DMARC policy, including inherited parent policy, while adding this sender. Do not reset an enforcing domain to p=none. For a domain with no effective policy, a deliberately monitored first policy can use p=none at _dmarc.<from-domain>; it still requires an owned reporting destination and a plan to assess every legitimate sender before enforcement. Do not use obsolete pct percentage-rollout recipes.

For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. An illustrative first-policy value is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Replace the placeholder with an approved, functioning report address; do not copy it unchanged.

If adding aggregate reporting, use only the approved rua mailbox or service. An external report destination can require authorization at the receiving service's DNS; obtain its exact instructions. Reports expose operational metadata, so review access and retention. Avoid enabling failure-report destinations casually. Aggregate reporting, RFC 9990

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify DNS and received messages

The following are reader-run diagnostic templates, not commands already executed. Replace every capitalized token with the relevant fully qualified name or authoritative server:

dig +trace RELAY_OWNER TXT
dig @AUTHORITATIVE_NS RELAY_OWNER MX +noall +answer
dig RELAY_OWNER MX +noall +answer
dig @AUTHORITATIVE_NS RELAY_OWNER TXT +noall +answer
dig @AUTHORITATIVE_NS DKIM_OWNER CNAME +noall +answer
dig +short TXT DKIM_CNAME_TARGET
dig +short TXT _dmarc.FROM_DOMAIN

Use the authoritative server discovered for each owner, not one server assumed to control every zone. Repeat the DKIM checks for all five records, follow any CNAME chain and compare a normal recursive-resolver answer. For relay MX, compare the complete fully qualified owner and every issued numeric priority/target pair at both the authoritative server and a recursive resolver. A nonempty answer, a correct target under the wrong owner or an incomplete regional target set is not acceptance. Expected DNS evidence also includes the exact full alias set and one valid SPF policy at its intended owner, with reachable DKIM public keys. An empty DKIM p= is a revoked key, not a successful setup. DKIM key retrieval

Then send an authorized message from each in-scope application through the activated source. Include a message that exercises normal disclaimers, links or other transformations. Obtain raw headers at a controlled external recipient and record:

• Visible From, receiver-observed envelope domain/Return-Path and recipient-facing sending IP.
• Every DKIM d= and s=, identifying which signature belongs to this relay.
• SPF result and authenticated domain, DKIM result, alignment mode and DMARC result.
• Relay/source evidence showing the message took the intended route.

Use receiver-controlled diagnostics or have the receiving administrator establish which Authentication-Results field the destination generated and how externally supplied fields are removed or separated. A familiar authserv-id or a header's position alone cannot establish provenance. When that boundary is unclear, obtain the receiver's authenticated mail trace instead of accepting an upstream header as proof. Authentication-Results trust boundary

Commissioning gate: the intended branded DKIM signature must show dkim=pass and align with the visible From domain, and the trusted receiver must show dmarc=pass. A DMARC pass achieved only by SPF does not prove this DKIM setup works. Diagnose SPF failures/errors separately even when aligned DKIM saves DMARC. Confirm other established senders still authenticate before closing the change.

Troubleshooting and recovery

If rollout damages existing mail, pause the new application route and restore the approved prior routing/DNS configuration, coordinating both owners. Keep old DKIM keys available while queued mail can still use them. Do not delete the domain, discard all five aliases or weaken DMARC as a first diagnostic step. Recommission after the smallest demonstrated defect is corrected.