Why is Avanan showing up in my DMARC reports and how do I fix it?
Updated on 10 Oct 2026: We clarified Avanan source attribution, reported DMARC disposition, and when Check Point SPF authorization is required.
Avanan can appear as the reporting organization or as a label for a Check Point source IP in your DMARC reports. Check which field contains the name: the reporter generated the report, while source_ip identifies the connecting mail server. Neither entry alone proves that you have an Avanan app installed in Microsoft 365 or that Avanan is an approved sender for your domain.
Start by deciding whether the source row came from recipient-side processing or your own outbound route. Do not add or remove an SPF include until the report fields and message trace show which organization controls that path. Recipient-side Check Point processing often needs no sender DNS change. If your organization enabled Avanan Protect (Inline) Outgoing Traffic, Check Point instructs customers to authorize include:spfa.cpmails.com; removing required authorization can cause SPF failures.
Should you change SPF for Avanan?
Do not add or remove Avanan or Check Point SPF authorization just because the name appears in a DMARC report. Change SPF only after confirming that your organization controls the outbound path and whether that path is still approved.
- Source label: An Avanan or cloud-sec-av.com source label indicates Check Point infrastructure; verify the underlying IP and mail path.
- SPF clue: An SPF pass shows that the checked domain authorizes the IP. Check the MAIL FROM domain and its DMARC alignment with your visible From domain.
- DKIM clue: A passing signature for your configured Microsoft 365 DKIM domain shows that the signature remained valid after the later hop.
- Fix path: Classify the path, keep required authorization, remove only accidental authorization, then monitor new report dates.
Avanan is part of Check Point's email security service. Source identification can show Check Point, cpmails.com, or a regional cloud-sec-av.com hostname. A source row alone does not prove that the service is active in your tenant.
Suped's DMARC monitoring keeps the source IP, authentication domains, DKIM selector, reporter, volume, and verified or unverified source state in one workflow. Those fields are more useful for this investigation than a single green pass percentage.
Why Avanan appears without a Microsoft 365 connector
DMARC aggregate reports are generated by receivers. A row identifies the connecting IP observed by the reporting receiver, which can belong to a security service that processed or re-injected a message inside the recipient's mail path. That row does not identify an enterprise app, connector, or transport rule in your Microsoft 365 tenant.
When Microsoft 365 originally sends and signs the message, a downstream Check Point system can preserve the Microsoft DKIM signature or invalidate it by changing signed headers or body content. That is why recipient-side rows can show a Microsoft DKIM pass, or failures for both SPF and DKIM. If your own tenant routes outbound mail through Avanan Protect (Inline), the Check Point hop is sender-controlled and its SPF authorization can be required. For an outbound path that fails DKIM, compare full headers to identify signed-content changes. Check supported options to preserve the original signature or apply an aligned signature after the final modification, then test at an external recipient.
Microsoft 365 email passing through a Check Point hop before DMARC reporting.
What it usually means
- Recipient gateway: A recipient uses Check Point, and its internal processing appears in a receiver's report.
- Outbound inline route: Your tenant deliberately sends protected outbound mail through Avanan.
- Avanan-generated mail: A configured digest, notification, encryption flow, or relay sends using your domain.
- Historic authorization: An old deployment left SPF authorization; the include itself does not create a DMARC report row.
What it does not prove
- Tenant app: A source row does not prove an Avanan enterprise app exists in Microsoft 365.
- Valid sender: A passing row does not prove Avanan should send mail for your domain.
- Connector proof: No connector in your tenant does not rule out recipient-side handling.
- DNS approval: DMARC visibility is not a request to add another SPF include.
Separate recipient-side processing from your outbound route
The same Avanan label can describe two operationally different paths. Recipient-side processing happens after your legitimate sender reaches an organization that uses Check Point. Sender-side processing happens because your organization enabled outbound inline protection, a Check Point relay, or an Avanan-generated message flow. The fix depends on which organization controls the hop.
|
|
|
|---|---|---|
Small share of total mail, cloud-sec-av.com or Check Point source, SPF and DKIM fail | Recipient-side processing is one explanation; low volume alone is inconclusive | Correlate reporter data with recipient headers or logs; do not change SPF from this row alone |
Most outbound volume plus an Avanan inline policy or connector in your tenant | Your organization controls the outbound route | Keep required authorization and test SPF, DKIM, and DMARC alignment |
Microsoft 365 DKIM passes while SPF fails or is not aligned | The reported signature remained valid after a later hop | Keep DKIM healthy; change SPF only if you own that hop |
SPF passes for your domain and is aligned at a Check Point source IP | Your domain authorizes that path | Find the matching mechanism and confirm its owner and purpose |
Use several signals together. No single source label proves who controls the route.
A stable, low-volume pattern is a clue, not proof that failures are harmless. Confirm recipient-side processing and check whether legitimate messages are rejected or quarantined. Once delivery is confirmed, monitor the pattern for volume or reporter changes.
Read the DMARC row before changing DNS
Start with the raw fields in the aggregate row: source IP, count, header-from domain, envelope-from domain when available, policy-evaluated SPF and DKIM results, auth_results domains, DKIM selector, reporter, and UTC date range. The policy-evaluated results show whether a passing mechanism met DMARC alignment; auth_results contains the underlying authentication results.
|
|
|
|---|---|---|
Passing DKIM signature matching your Microsoft 365 configuration | Confirm the signing domain and selector, then compare headers and message trace | |
SPF pass for the reported authentication domain | That domain authorizes the source IP | Compare it with header-from and alignment |
Avanan handled part of the path | Determine which organization controls the hop | |
Low count or narrow reporter set, with corroborating trace or headers | Recipient-side processing or a limited test is more likely | Compare source share, UTC dates, and recipient-side evidence |
Use this table to decide what the Avanan row means before editing SPF.
If SPF and DKIM both pass in auth_results, still check the authenticated domains against header-from. Relaxed alignment requires the same organizational domain; strict alignment requires an exact domain match. A DMARC pass does not prove that the mail path has an approved owner.
Aggregate reports group messages and do not include full recipient addresses, message bodies, or per-message IDs. The optional envelope_to field identifies a recipient domain, while the reporter identifies the reporting organization. Obtain a recipient's full headers and trace logs to investigate a specific message. These identifiers are defined in the aggregate report schema.
If legitimate mail fails after recipient-side processing, ask the recipient's administrator to compare Received and Authentication-Results headers before and after the Check Point hop and check Authenticated Received Chain (ARC) validation. A trusted ARC chain can support a local policy override without changing the underlying DMARC failure. The receiving administrator must verify the required intermediary and its sealing domain; see Microsoft's trusted ARC guidance.
For a focused DNS check, use Suped's DMARC checker and inspect SPF separately. That catches syntax and policy problems, but the source decision still comes from the raw report fields, mail trace, and ownership evidence.
Check disposition before assuming mail was rejected
The published policy records your requested handling. The row's policy_evaluated/disposition records the receiver's reported DMARC handling. "Disposition: Reject" is therefore more than a copy of p=reject. The fields are defined in RFC 9990.
|
|
|---|---|
reject | The receiver reports marking the messages for rejection. |
quarantine | The receiver reports marking the messages for quarantine. |
none | No DMARC action was taken; inspect SPF and DKIM results. |
pass | RFC 9990 explicitly records a DMARC pass under an enforcing policy. |
Legacy reports use none for passing messages too; read the authentication results alongside disposition.
When failures have disposition none despite quarantine or reject policy, inspect override reasons such as local_policy or trusted_forwarder. ARC is one possible basis for a receiver's override. Disposition describes DMARC handling, not final inbox placement; confirm a specific delivery failure with a bounce or recipient trace.
If the mail is unapproved spoofing, keep enforcement and monitor changes rather than authorizing the IP in SPF. If the mail is legitimate, investigate the failed hop even when the overall pass rate is high.
When the Avanan SPF include belongs, and when it does not
Check Point's outbound SPF instructions require include:spfa.cpmails.com when a Microsoft 365 tenant enables Avanan Protect (Inline) Outgoing Traffic. The include also supports configured Check Point-generated mail when that function's instructions require it. It does not belong in SPF merely because a recipient's Check Point infrastructure appears in your aggregate reports.
SPF examples for Microsoft 365 with or without Avanantext
Microsoft 365 plus approved Avanan outbound inline protection: v=spf1 include:spf.protection.outlook.com include:spfa.cpmails.com -all Microsoft 365 only, with no approved Avanan outbound path: v=spf1 include:spf.protection.outlook.com -all
These examples assume Microsoft 365 is your only other approved sender. Edit the existing SPF record for the MAIL FROM domain, preserve every required sender mechanism, and publish only one SPF record at that DNS name. Adding an include to your visible From domain does not fix SPF for a different Return-Path domain.
Remove the Avanan include only after confirming that outbound inline protection, Check Point relay traffic, custom-domain notifications, and other approved Avanan sending functions are disabled or do not use the domain. Allow for DNS caching, then review report windows after the change across several reporting cycles. Many receivers report daily, and historical rows remain visible.
Use Suped's domain health check after an authorized change. Verify DMARC, SPF, and DKIM together instead of treating SPF as a standalone text record.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If Avanan is an approved sender, document the owner, sender purpose, envelope domain, DKIM behavior, expected volume, and the policy or relay that requires it. That record makes later cleanup safer when a connector or Check Point feature is retired.
If your SPF record is near the limit of ten DNS-querying terms per evaluation, remove retired sources and count evaluated include, a, mx, exists, ptr, and redirect terms, including nested evaluations. Exceeding the limit produces permerror; ip4, ip6, and all do not count toward it. This limit is defined in RFC 7208. Suped's Hosted SPF can manage approved sender mechanisms and flatten the record when lookup pressure is the constraint.
How to trace an Avanan source
The investigation should answer one question: did your organization intentionally route or generate outbound mail through Avanan, or did a recipient-side Check Point system appear in the report? This sequence separates DNS authorization from mail flow ownership.
- Pull raw data: Export the source IP, reporter, count, UTC report window, disposition, override reasons, authentication domains, and DKIM selector.
- Map the IP: Confirm whether the IP or hostname is associated with Check Point, Microsoft, or another network.
- Measure the pattern: Compare Avanan volume with total mail and note whether the rows cluster around a small set of reporters.
- Search SPF: Look for spfa.cpmails.com or flattened Check Point IPs, then confirm which approved feature requires them.
- Match trace: Correlate UTC report windows and volume with Microsoft 365 message trace and outbound connector activity; a grouped row is not a one-to-one message match.
- Check ownership: Check finance, procurement, security, and MSP records for an Avanan tenant, policy, relay, or custom sender.
- Apply the result: Keep required authorization, remove only confirmed stale authorization, or make no DNS change for recipient-side processing.
Also check Avanan protection mode, outgoing threat or DLP policies, Microsoft 365 mail flow rules and connectors, relay settings, custom notification senders, OAuth consent, and journaling. An API integration alone does not prove that outbound mail is sent from a Check Point IP. A configured inline or relay path is stronger evidence.
Avanan DMARC troubleshooting using source IP, SPF, DKIM selector, and message trace.
Some dashboards compress the row into a pass rate. DMARC passes when at least one authentication mechanism passes and its domain is aligned with the header-from domain. That protocol result can still leave an operational question: who controls this source, and should it exist?
For a deeper authentication breakdown, use the same method applied to DMARC failures: separate SPF authentication, SPF alignment, DKIM authentication, DKIM alignment, and the header-from domain before deciding what changed.
What the Avanan admin view can show
If your organization uses Check Point's Avanan, the admin portal and Microsoft 365 configuration can show protected domains, Protect (Inline) Outgoing Traffic policies, connectors, relay settings, or custom senders. Report collection does not by itself prove that outbound mail routes through Avanan. Check the active protection policy and mail flow configuration.
AI-generated illustration of Check Point Harmony Email & Collaboration DMARC settings.
If nobody can access the portal, continue with DNS history, Microsoft 365 configuration, procurement records, and report patterns. A reseller or MSP can own the tenant, and a prior deployment can leave SPF authorization behind. The deciding evidence is whether your organization controls an active mail path that requires the Check Point source.
Where Suped fits in the cleanup
Suped's DMARC reporting brings source verification, SPF and DKIM results, DMARC alignment, volume, and reporter data into one review. Compare those fields with your mail configuration and message trace to distinguish a recipient-side Check Point row from an approved outbound path.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
In Suped, open the source details, compare authentication domains and alignment, and review volume and reporters. Record who owns the path and whether it is approved before changing source verification. A verified label in Suped does not authorize an IP in DNS or change DMARC results.
Records to compare
- Compare raw aggregate XML with the current SPF record and Microsoft 365 message trace.
- Check DNS history and the owner of each Check Point sending function.
- Obtain recipient headers or delivery logs for legitimate messages that failed.
Follow-up in Suped
- Record the verification decision for each source after confirming mail flow ownership.
- Compare source IP, reporter, and authentication results in the same review.
- Monitor new report windows and investigate source or volume changes after cleanup.
Fix the confirmed Avanan mail path
Classify the path before editing DNS. For confirmed recipient-side Check Point processing, leave sender SPF unchanged and ask the recipient's administrator to investigate delivery failures. For an approved outbound Avanan path, keep required SPF authorization and confirm that at least one mechanism passes with DMARC alignment at the final receiver. For a retired or unauthorized sender-side path, disable the route, remove its authorization, and watch new DMARC reports.
If the source remains after a confirmed sender-side cleanup, compare its reporter set and share of total volume. A small pattern tied to recipient infrastructure can remain because recipients continue to process your mail through Check Point. A broad pattern across your outbound mail points back to routing or sender configuration under your control.
Monitoring record example for a domain not yet enforcingtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com
Publish this example at _dmarc.example.com only for a domain that is not enforcing, and replace the reporting mailbox with your configured address. The rua tag requests aggregate reports. The fo tag controls failure-report options when ruf is configured, so it is unnecessary for aggregate monitoring.
Do not lower an existing quarantine or reject policy just to investigate an Avanan row. Evaluate representative legitimate traffic and recipient delivery evidence before tightening enforcement; a low failure percentage alone is insufficient. When a legitimate sender fails, check why DMARC authentication fails even when an underlying SPF or DKIM result appears to pass.
