How can I best help customers with DMARC failures caused by Check Point Harmony Email & Collaboration?
Updated on 17 Oct 2026: We added trusted ARC sealer checks and clarified when Check Point-related DMARC failures require recipient-side fixes or a temporary policy change.
The best way to help customers with DMARC failures involving Check Point Email Security, formerly Harmony Email & Collaboration and Avanan, is to separate delivery risk from reporting noise. Confirm the tenant's routing topology and whether the message reached the mailbox, then document where Check Point handled the message before Microsoft produced the DMARC result.
Adding 35.174.145.124/32 to a customer's SPF record is usually the wrong primary fix. This is one address in Check Point's region-specific Microsoft 365 footprint, not a universal sender identity. SPF only helps DMARC when the authenticated SPF domain matches the visible From domain under the customer's DMARC matching mode.
The practical path is to verify the route, compare original and final authentication results, confirm whether signed content changed, and ask the recipient administrator to validate the current Check Point and Microsoft 365 configuration. Keep the customer's DMARC policy unchanged unless message traces show legitimate mail is being blocked. Suped, our DMARC reporting and email authentication platform, helps support teams group the source and compare SPF, DKIM, and DMARC domain matching in one investigation.
Why Check Point handling can cause DMARC failures
Check Point Email Security can scan mail through Microsoft 365 mail-flow rules and connectors instead of owning the recipient's MX path. In inline Microsoft 365 deployments, Microsoft can receive the original message, redirect it to Check Point for inspection, and receive it again through a Check Point connector. The last connection can therefore show a Check Point address even though Check Point was not the original sender.
The failure pattern often comes from message modification or last-hop evaluation. If the security service changes the body, rewrites links, adds a warning banner, or alters an attachment, the original DKIM signature can fail. SPF can also fail or authenticate the relay instead of the original sender when Microsoft evaluates the Check Point hop. DMARC still passes if either SPF or a valid DKIM signature satisfies its domain-matching requirements; both paths must be unavailable for DMARC to fail.
A DMARC failure does not prove non-delivery
A Microsoft aggregate report can record DMARC failure while local policy accepts the mail. Look at the reported disposition and any override reason such as local_policy, then confirm the outcome with a message trace. A disposition of none means no DMARC-specific action was reported, not proof of inbox placement. If the row reports reject, do not classify it as harmless reporting noise without delivery evidence.
Flowchart showing how Check Point scanning can break authentication before Microsoft reports DMARC failure.
Check Point's email security overview describes deployment without changing MX records. Confirm the active protection mode and affected user group: Monitor only and Detect and Remediate are different paths from inline inspection, so a Check Point subscription alone does not establish that this relay caused the failure.
What to check first
Collect a small evidence pack before asking customers to edit DNS. Include the aggregate report row, source IP, reporting organization, policy override reason, header sample, message trace, and current DMARC record. Record the test message's Message-ID, UTC timestamp, sender, and recipient so the recipient administrator can correlate the evidence. Compare delivery to an affected mailbox with a control mailbox outside the Check Point route.
- Confirm the source: Group rows where Microsoft is the reporting organization and the source looks like Check Point, Avanan, Cloud-Sec-Av, or a related relay identity. Verify the source IP against the vendor's current regional connector addresses rather than relying on a source label alone.
- Read the disposition and override: Compare policy_evaluated.disposition with any reason element. A local_policy or other override can explain acceptance despite failed authentication, while aggregate data still cannot identify one recipient's outcome.
- Compare authentication stages: Check Authentication-Results, Authentication-Results-Original, ARC headers, and the Received chain for a pass before inspection and a fail after the Check Point hop. Use results added by trusted receiving infrastructure and corroborate them with the trace; a copied header alone is not proof of an earlier pass.
- Verify tenant configuration: Ask the recipient administrator to confirm the vendor-created connector, transport rules, Tenant Allow/Block List entries, trusted ARC sealers, and routing order are current for the tenant's deployment mode and region.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
In Suped, treat this as a source-level investigation. The issue view shows verified and unverified sources, authentication pass rates, and affected domains. That helps a support team avoid telling one customer that their DNS is broken when the same pattern appears across unrelated tenants.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Use Suped's domain health checker to check for DNS configuration issues before diagnosing the Check Point path. Verify the DKIM selector used by the test message separately. A valid DNS record does not prove that the message passed authentication or met DMARC's domain-matching requirements.
Match the fix to the routing topology
Enhanced Filtering for Connectors, also called skip listing, is useful when internet mail passes through a third-party gateway before its first Microsoft 365 evaluation. It lets Microsoft recover the original source information instead of treating the gateway as the sender. It is not intended for a non-Microsoft service that scans mail after Microsoft 365 and then returns it to Microsoft 365.
|
|
|
|---|---|---|
Internet > Check Point > Microsoft 365 | Enhanced Filtering for Connectors, only for a supported gateway route | Confirm the deployment supports this route, skip all trusted public gateway hops, and test with a small recipient group |
Internet > Microsoft 365 > Check Point > Microsoft 365 | Check Point-managed Microsoft 365 footprint | Connector, transport rule, allow entry, trusted ARC sealer, exclusions, and return path |
Choose connector work only after confirming the route in Received headers.
Do not enable skip listing blindly
Confirm the route before changing Enhanced Filtering or an SCL -1 rule. Check Point automatic deployments can maintain Microsoft 365 objects for the tenant, while manually onboarded tenants can require current vendor instructions. For a supported gateway route, Microsoft requires disabling SCL -1 bypass rules associated with that connector after enabling Enhanced Filtering. Never add Microsoft 365 IP addresses to the skip list. A hard-coded IP copied from another region can break the route or trust the wrong source.
After a supported change, send a controlled message and inspect X-MS-Exchange-ExternalOriginalInternetSender and X-MS-Exchange-SkipListedInternetSender when skip listing applies. For inline redirection, compare the original authentication result with the result after the Check Point return hop and retain the Microsoft message trace.
Verify Check Point's trusted ARC sealer
ARC (Authenticated Received Chain) preserves earlier authentication evidence so a receiver can assess mail after an intermediary modifies it. Check Point's Email Security Administration Guide documents checkpointcloudsec.com as a trusted ARC sealer added to its Microsoft 365 footprint. Confirm the actual signing domain and tenant configuration rather than assuming onboarding completed correctly.
- Inspect ARC-Seal and ARC-Message-Signature in a fresh test message. Check their d= signing domain against the tenant's trusted sealers, and inspect ARC-Authentication-Results for the original authentication result.
- Run Get-ArcConfig in Exchange Online PowerShell to inspect configured sealers. If a correction is needed, preserve existing trusted entries when changing the list.
- In Microsoft's latest ARC-Authentication-Results, arc=pass with oda=1 indicates a validated, trusted sealer. In the final Authentication-Results, compauth=pass with reason=130 identifies an ARC override of a DMARC failure.
- If ARC headers are missing or validation fails, provide the complete message and trace to the recipient administrator or Check Point support. Adding a trusted domain does not create a missing ARC chain or repair an invalid one.
Microsoft's 'Configure trusted ARC sealers' documentation explains that trusted ARC can support an override while the final dmarc=fail result remains. ARC does not guarantee inbox delivery. If trusted ARC is working but the message is quarantined or marked Unverified in Outlook, investigate Microsoft's composite authentication result and the applicable filtering policy before changing sender DNS.
Why adding a Check Point IP to SPF rarely helps
The tempting workaround is to add a Check Point or Avanan relay IP to SPF. That helps only when the final SPF check authenticates a domain that matches the visible From domain under the customer's DMARC matching mode. If the envelope sender belongs to an unrelated relay domain, DMARC still fails even when SPF passes and no matching DKIM signature survives.
Adding a relay IP to SPF
- Works only when domains match: SPF must pass for the envelope sender domain. Relaxed matching permits the same organizational domain as the visible From domain; strict matching requires an exact domain match.
- Adds DNS risk: Include mechanisms count toward SPF's limit of 10 DNS-lookup terms during evaluation, including nested terms. IP4 and IP6 mechanisms do not count toward that limit, but they lengthen the record.
- Can age badly: Check Point publishes different addresses by region and changes its cloud footprint.
Fixing the mail path
- Matches the cause: The correct connector treatment depends on whether Check Point scans before or after Microsoft.
- Keeps policy stable: Customers do not need a policy rollback when message traces confirm legitimate delivery.
- Improves support quality: Known relay behavior can be classified without hiding unrelated authentication failures.
SPF change to avoid unless domain matching is provenDNS
v=spf1 include:_spf.example-sender.net ip4:35.174.145.124 -all
That example is a caution. The IP is one current US-region Check Point address used in its Microsoft 365 footprint. Authorizing it in the sender's SPF record still does not repair DKIM or make an unrelated envelope domain match the From domain. If Check Point handles the customer's outbound mail, follow its supported SPF setup for that sending path instead of copying an inbound relay IP.
|
|
|
|---|---|---|
SPF passes and its domain matches | SPF can satisfy DMARC | A DKIM failure alone does not make DMARC fail |
SPF domain is unrelated | SPF does not satisfy DMARC | Check whether a valid DKIM signature meets domain matching |
DKIM body hash mismatch | The signed body no longer verifies | Compare copies before and after inspection; investigate modifications and ARC evidence |
Local policy override | Receiver departed from the requested DMARC action | Confirm the actual outcome with message trace |
Use this table to decide whether SPF work is relevant.
How to support customers
Customer guidance should be direct. This receiving-side security path can break or obscure authentication after the sender has handed off the message. The support task is to identify which failures require sender changes, which require recipient configuration, and which are confirmed local-policy overrides.
- Explain the chain: Tell the customer where Microsoft first evaluated the message and where Check Point inspected or returned it.
- Confirm real delivery: Ask for a controlled mailbox test, message trace, and full headers before changing the sender's DMARC policy.
- Protect policy progress: Do not lower an established policy only because of one known middleware source when legitimate mail is reaching users.
- Escalate the right request: Ask the recipient team or Check Point support to verify routing order, vendor-created Microsoft 365 objects, DKIM preservation, and ARC handling.
- Tag the source: Track this source separately in DMARC monitoring so it does not hide failures from other legitimate senders.
Customer-ready explanation
We are seeing DMARC failures reported by Microsoft after Check Point Email Security processed the message. This can happen when the security layer modifies signed content or changes the source Microsoft evaluates. Confirm the routing topology, mailbox delivery, and tenant configuration before changing your domain's DMARC policy.
Microsoft Exchange admin center connector settings for trusted mail flow.
The recipient side matters because the sender normally cannot change this routing. If the recipient organization uses Check Point with Microsoft 365, its administrator controls the connector, mail-flow rules, allow entries, and inspection mode. The sender can supply evidence and preserve its own DKIM, but the recipient side controls the durable routing fix.
For a broader investigation process, the related guide on troubleshooting DMARC failures is useful when the Check Point row is only one of several failing sources.
When to change the customer's DMARC policy
Do not immediately lower every affected customer from p=reject to p=quarantine because of one Check Point row. Consider a temporary policy change only when legitimate mail is blocked and recipient-side remediation cannot restore delivery promptly. RFC 9989 also discourages p=reject for general-purpose email domains, particularly domains whose users post to mailing lists, so each domain's approved policy should reflect its mail use and tested risk.
Policy response by delivery evidence
Use the customer-approved policy that the delivery evidence supports.
Monitor
Keep policy
No proven user-facing delivery issue
Stabilize
Consider temporary change
Delivery issue tied to one known path
Reassess
Review policy
Multiple legitimate sources blocked
For a temporary policy change, set a review date and a return condition. Fix the routing or authentication issue, then restore the approved policy after testing. A less restrictive DMARC policy does not repair signatures or guarantee delivery because the receiver still applies its own filtering policies.
Example for a domain approved for rejectDNS
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com;
DMARC checker
Look up a domain's DMARC record and catch policy issues.
?/7tests passed
Use Suped's DMARC checker before and after any DNS change to validate the record syntax and configured reporting address. Separately confirm that reports reach the intended destination; external reporting destinations require authorization. These checks do not resolve the Check Point routing issue.
How Suped fits the workflow
Suped is our DMARC reporting and email authentication platform. In this workflow, support teams can group Check Point source rows, compare domain-matching results across customer domains, and investigate the pattern before recommending a policy change. Aggregate reports alone cannot establish which recipient tenant or mailbox received a message, so corroborate the pattern with customer traces.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
- Source grouping: Suped groups repeated Check Point failures so support teams can classify the route once and review affected domains.
- Authentication comparison: SPF, DKIM, and DMARC results appear together, which helps separate a sender problem from recipient-side handling.
- Report-driven alerts: Review Suped alerts against the documented source history to distinguish a new authentication break from an established aggregate-report pattern.
- Policy staging: Hosted DMARC supports a documented temporary change when mailbox evidence proves a delivery incident.
- Multi-domain workflow: The MSP view helps teams apply the same evidence standard when the pattern appears across customer domains.
For teams managing many domains, DMARC monitoring should show the raw authentication result and the source-level story. A flat list of failures is not enough when one middleware route creates a large share of reported failures.
If a customer needs staged policy control, hosted DMARC can reduce the delay caused by separate DNS access. Hosted control should support a written incident plan, not become a reason to weaken policy whenever a noisy source appears.
Customer response template
A consistent template acknowledges the failure without overstating the customer's responsibility. Use wording like this when the evidence points to Check Point handling.
Support reply templatetext
We found DMARC failures reported by Microsoft after the message passed through Check Point Email Security, formerly Harmony Email & Collaboration and Avanan. This can happen when the security layer changes signed content or when Microsoft evaluates the Check Point return hop instead of the original source. A local-policy override can allow delivery even though DMARC fails. Please ask the recipient's Microsoft 365 administrator to confirm: 1. Message trace and full headers show the delivery outcome. 2. The Received chain shows the exact Check Point routing topology. 3. Vendor-created connectors, rules, and allow entries are current. 4. Original DKIM is preserved or a valid ARC chain is trusted by Microsoft. Please include the Message-ID, UTC timestamp, sender, and recipient in the escalation. Do not add a relay IP to SPF unless it is an approved sender and the SPF-authenticated domain meets DMARC's domain-matching requirements.
That last sentence matters. A source IP in an aggregate report invites a DNS edit, but the failure can come from the receiving-side security path changing the authentication evidence after sender handoff.
Best path forward
- Keep the approved policy when safe: Do not lower policy when traces confirm delivery and failures are isolated to the Check Point path.
- Preserve authentication evidence: Keep signed content unchanged or preserve earlier results through a valid ARC chain trusted by the receiver; re-sign only for a domain that satisfies DMARC for the visible From domain.
- Document the source: Classify the known route in the reporting process without suppressing new failures.
- Limit temporary policy changes: Consider a less restrictive policy only when mailbox evidence shows legitimate mail is being blocked, and document the review date.
Views from the trenches
Best practices
Confirm recipient delivery before lowering DMARC policy because reports can show final-hop noise.
Track Check Point rows as a source pattern so one relay path does not hide new sender issues.
Verify the routing topology and vendor-managed Microsoft 365 objects before changing DNS.
Common pitfalls
Adding one observed relay IP to SPF creates debt and rarely fixes domain matching by itself.
Treating every Microsoft RUA reject as non-delivery can lead to needless policy rollbacks.
Assuming every DKIM failure proves message modification overlooks key and DNS errors.
Expert tips
Keep the approved policy when mailbox traces confirm delivery on the middleware route.
Verify ARC chain validation and receiver trust when inspection changes the original message.
Use a written support template so customers get consistent advice across affected domains.
Marketer view
Marketer from Email Geeks says Check Point can create false-positive DMARC warnings because its handling path changes what the final receiver reports.
2025-09-15 - Email Geeks
Marketer view
Marketer from Email Geeks says delivery can be addressed through Microsoft 365 connector configuration, but RUA reports can still contain noisy failures.
2025-09-15 - Email Geeks
