Why cloud-sec-av.com Shows Up in Your DMARC Reports (Avanan Explained)

If you publish a DMARC record and review your aggregate reports, you may notice a steady stream of mail failing authentication from hostnames like cloud-sec-av.com, us.cloud-sec-av.com, eu.cloud-sec-av.com, or au.cloud-sec-av.com. The volume can look alarming, sometimes hundreds or thousands of messages, all marked as DMARC failures. The natural reaction is to assume someone is spoofing your domain.

In almost every case, this is not an attack and it is not a delivery problem. It is the normal side effect of a recipient running a third-party email security service inside their Microsoft 365 tenant. This guide explains exactly what cloud-sec-av.com is, why it generates failures in your reports, and why the correct response is usually to do nothing.

What cloud-sec-av.com actually is

cloud-sec-av.com is the scanning infrastructure for Check Point Harmony Email & Collaboration, the product previously known as Avanan. It is a cloud-based email security service that organizations bolt onto Microsoft 365 to add malware scanning, phishing detection, URL rewriting, and data loss prevention (DLP) on top of what Microsoft already provides.

The key point: these IPs do not belong to you, and they do not belong to a sender you control. They belong to a security vendor sitting inside the inbox of someone you sent mail to. You are seeing their infrastructure in your reports because of how DMARC reporting works, not because of anything happening on your side.

Why it ends up in your DMARC reports

The confusion comes down to one design choice: how Avanan inserts itself into the mail flow. In its most common inbound configuration, called Protect (Inline) Mode, Avanan does not change the recipient’s MX record. Microsoft 365 stays the public MX. Instead, Avanan plugs into Exchange Online internally using connectors and transport rules.

Here is what happens to a single message you send:

1. Your message is delivered to the recipient’s MX, which is Microsoft 365. At this point delivery has already succeeded. Microsoft runs the inbound authentication checks (SPF, DKIM, DMARC) it is configured to run.
2. A transport rule routes the message out of the recipient’s tenant to Avanan’s scanning infrastructure for malware, phishing, and DLP analysis.
3. Avanan inspects and often modifies the message. It may rewrite URLs, strip or detonate attachments, or inject warning banners. Any of these changes alter the message body.
4. Avanan releases the modified message back into the recipient’s Microsoft 365 tenant from its own IP ranges (*.cloud-sec-av.com). Microsoft receives the message a second time and re-runs SPF, DKIM, and DMARC against this re-entry.

That second authentication pass is what you see in your reports. Microsoft generates a DMARC record for the re-entry, sees that it arrived from an IP that has nothing to do with your domain, and reports a failure.

Why the message fails DMARC on the second pass

DMARC passes when SPF or DKIM passes and is aligned with the domain in the From header. On Avanan’s re-entry, both fail for predictable reasons:

• SPF does not align. The message now comes from an Avanan IP. Your SPF record does not (and should not) list that IP, so SPF either fails or passes for the wrong domain.
• DKIM alignment breaks. When Avanan rewrites URLs, strips attachments, or injects a banner, it changes the body. That invalidates your original DKIM signature, because DKIM signs the content. Any new signature Avanan applies is aligned to Avanan, not to your From domain. Body modification is one of the most common reasons a DKIM signature stops verifying.

With neither identifier aligned, DMARC fails. This is the same mechanism behind classic forwarding failures, just happening inside a single tenant rather than between two providers.

The part that confuses everyone: it failed but it was delivered

Here is the genuinely misleading bit. Microsoft reports these as DMARC failures, but the mail is delivered to the recipient anyway. Two things are happening at once:

• Avanan’s IPs are trusted at the connection level inside the recipient’s tenant, so the second pass is allowed through regardless of the DMARC result.
• Microsoft still evaluates DMARC and still reports what the disposition would have been under your published policy, as if the trust override were not there.

In practice you may also see signals like compauth=none or an SCL:-1 (Spam Confidence Level) in the recipient’s headers, both indicating that a tenant-level trust rule, not your DMARC policy, decided the outcome. The frustrating detail is that Microsoft does not populate the “Override Reason” and “Override Comment” fields in the DMARC aggregate report that exist precisely to explain this situation. So the report shows a scary policy_evaluated disposition with no note explaining that the message was actually delivered. The data is technically accurate and practically misleading.

What you should do about it: nothing

If you do not operate Avanan yourself, the correct response is to take no action. Specifically:

• Do not add Avanan IPs to your SPF record. They are not your sender. Authorizing another organization’s security scanner to send as your domain is wrong, it bloats your record toward the 10-lookup SPF limit, and it weakens your real protection.
• Do not loosen your DMARC policy. There is no genuine failure to accommodate. Dropping from p=reject or p=quarantine back to a permissive policy to make these entries “pass” would only reduce your protection against actual spoofing.
• Do not contact the recipient. Their mail is arriving. Nothing is being rejected on their end.

There is simply no lever available to you, as the sending domain owner, that improves this. The behavior lives entirely inside someone else’s tenant.

How to keep this noise from drowning real threats

The legitimate concern is not the Avanan traffic itself. It is that this noise can bury the failures that actually matter, the unauthorized sources genuinely trying to spoof your domain. If every failing line looks the same, it is easy to either panic at harmless scanner traffic or grow numb and miss a real attack.

This is exactly the problem DMARCReport is built to solve. Rather than handing you raw XML, it normalizes reports across every receiver, resolves third-party sources back to recognizable services, and separates known indirect mail flow (security scanners, forwarders, mailing lists) from suspicious unaligned sources. A burst from cloud-sec-av.com shows up identified as a recipient-side security scanner instead of an anonymous wall of red, so you can dismiss it in seconds and spend your attention on the sources that warrant investigation.

When you can read your DMARC reports for what they actually say, the decision becomes obvious: scanner re-entry is noise, an unknown sender blasting your exact-domain From address is signal.

Avanan is not the only one, but gateways are not the cause

It is worth being precise here, because two very different architectures get lumped together and only one of them produces the failures you are looking at. The thing that matters is whether a service re-injects your message back into the delivery path from its own IPs after the message has already reached Microsoft 365.

Post-delivery round-trip inside the tenant. This is the cause. This is the Avanan pattern, and INKY works the same way. Mail is delivered to Microsoft 365, a connector and transport rule route it back out to the scanner, the scanner modifies it (banner, URL rewrite, attachment handling) and returns it to the tenant from its own IPs, and Microsoft treats that return as a brand-new inbound message and authenticates it again. INKY documents this in nearly the same words as the Avanan case: once a message “will be sent back to your mail environment and will originate from an INKY IP address,” your mail environment “will perform a second SPF/DKIM/DMARC check on the message, and this time all three checks will ultimately fail.” INKY rightly calls this “expected behavior and nothing to be concerned with.” Any service that injects banners or rewrites links through this kind of in-tenant loop can show up the same way under its own hostnames.

Pre-delivery gateways. These are not the cause. Proofpoint, Mimecast, and Barracuda in their classic deployment are secure email gateways that sit in front of Microsoft 365 as the public MX. They receive your message, scan it, and hand it to Microsoft once. They do not pull mail back out of the tenant and re-inject it, so they do not create the second-pass failures that fill your reports with a scanner’s hostnames. A gateway can still affect alignment in forwarding or relay situations, but that is a different mechanism, and when a gateway rather than Microsoft is the MX, Microsoft frequently does not generate an aggregate report for that traffic at all.

API and journaling modes. Also not the cause. Many services scan mail through the Microsoft Graph API and a journaled copy without ever re-injecting it into the delivery stream. This includes Avanan’s own Monitor and Detect modes, as well as products like Abnormal, IRONSCALES, and Material. Because nothing is put back on the wire from a new IP, alignment is never broken and these services never appear in your reports.

The cleanest way to hold all of this: it is the deployment mode, not the brand. The very same product, Avanan, generates these failures in Protect (Inline) mode and generates none of them in Monitor mode. So the useful question is never “which vendor is this.” It is “did a service re-inject my already-delivered message from an IP that is not mine.” If yes, it is harmless indirect mail flow. If nothing like that explains the source, that is when it deserves a real look.

One category that is unrelated to all of this: phishing-simulation and awareness tools such as Phin or Cofense send training mail rather than scanning your inbound mail, so they appear in reports as their own clearly identified sending service, not as a re-injected copy of your own message.

The one exception: when you run the scanner yourself

Everything above assumes the scanner belongs to a recipient, not to you. If your own organization deploys Check Point Harmony Email & Collaboration (Avanan) or INKY in inline mode, the situation is different, because now it is part of your legitimate mail flow and you want it to authenticate cleanly.

In that case the fix is on the scanner and Microsoft side, not in your public DNS for normal outbound mail. Configure the service’s own DKIM signing and SPF authorization per the vendor’s guidance so that mail it handles on your behalf is properly aligned, and make sure your internal connectors are configured so the re-entry is recognized as trusted internal flow. INKY, for example, suggests adding its IPs to your SPF record specifically to cover receivers that misread the headers on the re-injected hop. The goal is always alignment for the traffic you actually control, never authorizing a scanner that lives in someone else’s inbox.

Frequently asked questions

Is cloud-sec-av.com a spoofing attack on my domain? Almost certainly not. It is Check Point Harmony Email & Collaboration (formerly Avanan) scanning mail inside a recipient’s Microsoft 365 tenant. The failures appear because the scanner re-injects modified messages from its own IPs, which breaks alignment on a second authentication pass.

Why does Microsoft say the email failed if it was delivered? Microsoft trusts Avanan’s IPs at the connection level so the mail goes through, but it still evaluates and reports DMARC as if that trust override were not in place. It also does not fill in the override reason fields that would explain the gap, so the report looks worse than reality.

Should I add these IPs to my SPF record? No. Unless you operate Avanan yourself, those IPs are not authorized senders for your domain. Adding them is incorrect and consumes SPF lookups you cannot spare.

Will keeping p=reject cause these messages to bounce? No. The delivery decision happens inside the recipient’s tenant, where Avanan’s traffic is trusted regardless of your policy. Keeping enforcement protects you against real spoofing without affecting this scanner traffic.

How do I tell this apart from a genuine threat? Identify the source. Recipient-side security scanners like cloud-sec-av.com are recognizable indirect mail flow. A real threat looks like an unknown IP sending from your exact From domain with no legitimate relationship to you. A reporting platform that classifies sources for you makes this distinction immediate.

Do other email security vendors cause this too, like INKY, Proofpoint, or Mimecast? INKY does, because it works like Avanan: it loops your already-delivered message out of Microsoft 365 and re-injects it from INKY IPs, which fails a second authentication check. Proofpoint and Mimecast in their standard gateway deployment do not, because they scan in front of Microsoft 365 and deliver once, rather than re-injecting after delivery. API and journaling tools such as IRONSCALES, Abnormal, and Material also do not. It comes down to the deployment mode, not the vendor name.

The takeaway

cloud-sec-av.com in your DMARC reports is the digital equivalent of a smoke alarm chirping because someone next door is cooking. It is real activity, accurately recorded, and completely harmless to you. Check Point (Avanan) is scanning a recipient’s mail, the scan breaks alignment, and Microsoft reports the failure without the context that the message was delivered fine.

Leave your SPF record, your DMARC policy, and your recipients alone. The skill worth building is not reacting to this traffic, it is reading your reports well enough to recognize it instantly and keep your focus on the failures that are actually trying to hurt you.