Get Consultation
img

Why cloud-sec-av.com Is Appearing in Your DMARC Reports (And Why It’s Probably Fine)

If you’re monitoring DMARC for your domain and you’ve noticed failed authentication from cloud-sec-av.com or related hostnames like au.cloud-sec-av.com, us.cloud-sec-av.com, or eu.cloud-sec-av.com, you’re not alone. This is one of the more common sources of confusion for people reviewing their DMARC aggregate reports.

Here’s what’s happening, and why you probably don’t need to worry about it.

What Is cloud-sec-av.com?

The cloud-sec-av.com domain belongs to Check Point Harmony Email & Collaboration, an email security platform formerly known as Avanan. Check Point acquired Avanan in 2021 and rebranded it as part of their Harmony security suite.

Check Point Harmony provides cloud-based email security for organizations using Microsoft 365 and Google Workspace. When deployed in “inline mode,” it scans both inbound and outbound email traffic for threats like phishing, malware, and business email compromise.

Why It’s Showing Up in Your Reports

Here’s the key point: you don’t need to be using Check Point Harmony yourself for it to appear in your DMARC reports. These entries typically appear because some of your recipients use Check Point Harmony for their email security.

The pattern works something like this:

  1. You send an email from your domain
  2. The email arrives at a recipient whose organization uses Check Point Harmony
  3. The recipient’s Exchange Online Protection (EOP) hands the email to Check Point for inline scanning
  4. Check Point processes the email and re-injects it back into the mail flow
  5. The message is re-evaluated by the recipient’s mail system, producing DMARC report entries that reflect the post-processing sender IP
  6. Since Check Point’s IP isn’t in your SPF record (nor should it be), and the DKIM signature may not survive the processing, the evaluation fails
  7. A DMARC aggregate report gets generated showing the failure

The result: you see cloud-sec-av.com in your reports with 0% SPF alignment and often 0% DKIM alignment as well.

Advertise Here Your brand could be here

Why Both SPF and DKIM Fail

You might expect that even if SPF fails (because the IP changed), DKIM should still pass; the signature is in the message headers, after all. This is how traditional email forwarding typically behaves.

However, the message often fails DKIM alignment because the original signature is altered or replaced during scanning, and any new DKIM signature is not aligned with the original sending domain. Whether this is due to header modifications, body alterations during scanning, or something else in their processing pipeline isn’t entirely clear. The exact mechanics remain something of a black box.

In fact, if you dig into this topic, you’ll find that even people working at DMARC vendors don’t have complete answers. Neither Microsoft nor Check Point has published clear documentation explaining exactly what happens during this re-injection flow and why DKIM fails to survive. (Frustrating, I know.)

How to Identify This Pattern in Your Reports

In a typical DMARC aggregate report (like those from Postmark, Google, or other providers), you’ll see cloud-sec-av.com categorized as an “unknown” or “other” source (not as a forwarded source).

The telltale signs:

  • Small percentage of total volume: If you were using Check Point yourself, 100% of your mail would flow through their infrastructure. Seeing only a small percentage (say, 2-5%) indicates it’s recipient-side.
  • 0% alignment on both SPF and DKIM: Unlike traditional forwarding, which typically preserves DKIM, these entries fail both checks.
  • IP addresses in AWS ranges: Check Point Harmony runs on AWS infrastructure, so the IPs will typically belong to Amazon.

Compare this to legitimate forwarding (like Gmail or other providers), which usually shows 0% SPF but 100% DKIM because the DKIM signature survives intact through the forward.

Does This Affect Email Delivery?

This is the critical question, especially if you’re considering moving from p=none to p=quarantine or p=reject.

The best available evidence suggests: no, this doesn’t affect delivery.

The working theory is that DMARC enforcement happens at the initial point of delivery…when your email first arrives at the recipient’s mail server. At that point, your email passes DMARC because it’s coming from M365’s IPs (which are in your SPF) with a valid DKIM signature.

The Check Point re-injection and subsequent DMARC failure happens after the email has already been accepted. It’s an internal processing step within the recipient’s infrastructure, and the failed DMARC evaluation at that stage doesn’t result in the email being rejected or quarantined.

If this were causing delivery problems for domains running DMARC enforcement, you’d expect widespread complaints from the many organizations using p=reject. The fact that the general consensus is “treat this like forwarding noise” suggests enforcement isn’t breaking delivery to recipients who use Check Point.

That said, this is based on observed behavior and community knowledge rather than official documentation from Microsoft or Check Point. There’s some inherent uncertainty here.

What Should You Do About It?

For most organizations, the answer is: nothing.

  • Don’t add Check Point’s IPs or includes to your SPF record. These entries aren’t your sending infrastructure (they’re your recipients’ security infrastructure). Adding them would actually weaken your DMARC protection by authorizing IPs you don’t control.

  • Don’t delay DMARC enforcement because of these entries. If your legitimate sending sources (Microsoft 365, Google Workspace, your marketing platforms, etc.) are showing clean alignment, you’re ready to move to enforcement. The Check Point failures are noise, not signal.

  • Do keep an eye on the volume. If you suddenly see a massive spike in Check Point traffic, that would be worth investigating, but a consistent small percentage is normal.

  • Do focus on sources that matter. Your DMARC reports are most valuable for identifying legitimate sending sources you may have forgotten about, or actual spoofing attempts. Check Point entries are neither.

When You Might Want to Investigate Further

There are a few scenarios where these entries might warrant more attention:

  1. The volume is unusually high. If Check Point traffic represents a large percentage of your total email volume, something unusual might be happening.

  2. You’re seeing other suspicious patterns. If the Check Point entries coincide with phishing reports or other signs of abuse, dig deeper.

  3. You need forensic-level detail. DMARC aggregate reports (rua) only show summary statistics. If you need to see actual message samples to understand what’s happening, you’d need forensic reports (ruf) from a paid DMARC provider. Most organizations don’t need this level of detail for Check Point entries.

The Bottom Line

Seeing cloud-sec-av.com in your DMARC reports is a well-documented phenomenon that many email administrators encounter. It’s an artifact of how Check Point Harmony processes email for organizations that use it. It’s not an indication that your email authentication is broken or that someone is spoofing your domain.

The lack of clear documentation from Microsoft and Check Point about exactly what’s happening under the hood is frustrating, but the practical impact is minimal.

If your reports show clean alignment from your actual sending sources, you can safely proceed with your DMARC enforcement journey and treat the Check Point entries as background noise.

This article is based on community research and observed behavior across multiple organizations. If you have additional insights into Check Point Harmony’s email processing flow, contact us. We’d love to update this resource with more definitive information.

Related Reading