Avanan is showing up in your DMARC reports because a receiver, relay, or configured mail path is presenting a Check Point or Avanan source IP in the DMARC aggregate data. It does not automatically mean you have an Avanan app installed in Microsoft 365, and it does not automatically mean Avanan sends mail for your domain.
The common fix is to verify the source IP, check whether your SPF record authorizes Check Point or Avanan, then remove that SPF include unless Avanan is a real approved outbound sender. If DKIM is passing with your Microsoft 365 selector, the original Microsoft 365 signature survived the trip. DMARC only needs SPF or DKIM to pass the same-domain check, so a row can look fully compliant even when one part of the path is not a sender you intended to authorize.
I would treat this as a source attribution problem first, not a DNS change request. The dangerous move is adding every visible DMARC source to SPF. That can turn a reporting clue into an authorized mail path.
The short answer
Do not add Avanan or Check Point to SPF just because it appears as a DMARC source. Add an SPF include only when that service is deliberately sending outbound mail for your domain and you have a documented owner for that mail stream.
- Source label: Avanan in a report often means the reporting receiver saw a Check Point mail security hop.
- SPF clue: If SPF passes for a Check Point IP, your SPF record authorizes that IP somewhere.
- DKIM clue: If the DKIM selector is your Microsoft 365 selector, the message was signed before that hop.
- Fix path: Confirm, remove accidental SPF authorization, then monitor the next reporting window.
Avanan is now part of Check Point Harmony Email & Collaboration, so DMARC tools and raw reports can show Avanan, Check Point, cpmails.com, or a Check Point-owned IP depending on how the source is named. The Check Point DMARC guide is useful when Avanan is intentionally managing DMARC for a tenant, but the presence of a source row alone is not proof that the service is active in your tenant.
In Suped's DMARC monitoring, this is the exact workflow I want visible: which IP sent the mail, which organizational domain passed, which DKIM selector signed it, and whether the source is verified or unverified. That is more useful than a single green pass percentage.
Why Avanan can appear without an obvious Microsoft 365 config
The confusing part is that DMARC aggregate reports are receiver-generated. A row can identify the IP that reached the receiver or the security layer that processed the message. That row is not the same thing as a Microsoft 365 enterprise app, connector, or transport rule.
When the message was originally sent through Microsoft 365, Microsoft can sign it with DKIM. If a downstream Check Point system relays or scans that message without changing the signed headers, DKIM still passes with the Microsoft selector. If your SPF record also includes a Check Point SPF source such as spfa.cpmails.com, SPF can pass too.
Four-part path showing how Microsoft DKIM and a Check Point hop can appear in DMARC data.
What it usually means
- Recipient gateway: A recipient uses Check Point or Avanan, and its system appears in the report.
- Old SPF include: Someone added Check Point to SPF after seeing it in a DMARC dashboard.
- Mail reroute: Outbound mail is being routed through a security service before final delivery.
- Shadow IT: A trial, reseller purchase, or add-in exists outside normal IT records.
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 be authorized to send mail.
- Connector proof: No visible connector does not rule out recipient-side handling.
- DNS approval: DMARC visibility is not a request to add another SPF include.
Read the DMARC row before changing DNS
Start with the raw facts in the DMARC aggregate row. The fields that matter are the source IP, count, header-from domain, envelope-from domain, SPF result, DKIM domain, DKIM selector, and reporter. I also check the date range because a row with a count of three is handled differently from a source sending thousands of messages per day.
|
|
|
|---|---|---|
DKIM selector |  Microsoft 365 signed the message | Compare with message trace |
SPF passes | Your SPF authorizes that IP | Find the SPF include |
 Check Point IP | Avanan handled the path | Confirm owner or remove |
Low count | Limited event or test | Match dates to trace |
Use this table to decide what the Avanan row means before editing SPF.
If the row says SPF and DKIM both pass, still inspect the mechanism details. A clean DMARC pass only means the message met DMARC's rule. It does not answer whether the path is authorized by policy, procurement, or security review.
For a focused DNS check, run the domain through a DMARC checker and then inspect SPF separately. That catches syntax and policy problems, but the source decision still comes from the report row plus mail trace.
The SPF mistake that makes Avanan look valid
The most common self-inflicted problem is adding a Check Point SPF include after seeing Avanan in a DMARC source list. For example, if a flattened SPF record contains spfa.cpmails.com, and that include expands to the same IP in the DMARC row, SPF has been authorized by your DNS.
Example SPF cleanuptext
Current SPF that authorizes Check Point IPs: v=spf1 include:spf.protection.outlook.com include:spfa.cpmails.com -all Cleaner SPF when Avanan is not an approved sender: v=spf1 include:spf.protection.outlook.com -all
After removing the accidental include, wait for new aggregate reports. DMARC reports are not instant, and many receivers send them daily. The source can remain visible for a reporting cycle after the DNS change, so judge the result by new date ranges.
Use a broad domain health check after the cleanup. The point is to verify DMARC, SPF, and DKIM together instead of treating SPF as a standalone text record.
0.0
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If Avanan is a real sender, do not simply leave the include in place and move on. Document the owner, sender purpose, bounce domain, DKIM behavior, and expected volume. Then keep it in SPF only if there is no better vendor-specific return-path setup.
If your SPF record is already near the lookup limit, moving routine DNS management into Hosted DMARC can reduce fragile manual changes. Suped also has Hosted SPF for sender management and SPF flattening when SPF is the actual constraint.
How to confirm the real source
The investigation should answer one question: did your organization intentionally send through Avanan, or did a receiver-side Check Point system appear in the report? I use this sequence because it separates DNS authorization from mail flow ownership.
- Pull raw data: Export the raw DMARC aggregate row with source IP, reporter, count, SPF domain, and DKIM selector.
- Map the IP: Confirm whether the IP belongs to Check Point, Microsoft, or another network.
- Search SPF: Look for cpmails.com, Check Point includes, or flattened IPs copied into your record.
- Match trace: Compare report dates and counts with Microsoft 365 message trace exports.
- Check ownership: Ask finance, procurement, security, and the MSP about Avanan or Check Point invoices.
- Fix DNS: Remove accidental authorization, or keep it only with a documented business owner.
Also check Outlook add-ins, OAuth consent, mail flow rules, connectors, and any journaling or security routing. If a plugin sends through Microsoft 365, the sending IP usually remains Microsoft. If the final source IP belongs to Check Point, look harder at recipient handling or outbound rerouting.
Flowchart for tracing an Avanan DMARC row back to SPF, DKIM, and message trace evidence.
The raw report matters because some dashboards compress the detail into a pass rate. If one mechanism passes the same-domain check, DMARC passes. That is correct protocol behavior, but it can hide the operational question: should this source exist?
For a deeper authentication breakdown, the troubleshooting pattern is similar to DMARC failures: separate SPF, DKIM, and the header-from domain before deciding what changed.
What the Avanan admin view can show
If the customer really uses Avanan or Check Point Harmony Email & Collaboration, the admin portal should show a tenant, protected domains, DMARC module configuration, or mail flow setup. That is different from seeing Check Point as a source in an aggregate report.
Screenshot-style view of Check Point Harmony Email & Collaboration DMARC settings.
If nobody can access that portal, do not assume the row is harmless. Ask whether a reseller, MSP, or prior security project added the DNS record. The important evidence is not who remembers the tool. The important evidence is whether your DNS still authorizes the sending IP.
Where Suped fits in the cleanup
Suped is the best overall practical DMARC platform for this kind of cleanup because it keeps the investigation tied to actions: source verification, authentication results, SPF and DKIM diagnostics, blocklist (blacklist) monitoring, and alerts when a source changes. That matters when the same customer has Microsoft 365, a security gateway, historic SPF edits, and low-volume edge cases.
DMARC records drawer showing filters, record rows, authentication results, and CSV export
The workflow I want is simple: identify the row, open the source details, confirm SPF and DKIM behavior, then mark the source as approved or unapproved. Suped's issue detection and steps to fix are built around that process, so the person making the DNS change sees why the change is needed.
Manual spreadsheet workflow
- Slow source review: Raw XML, flattened SPF, and message trace are compared by hand.
- Easy DNS drift: Old SPF includes stay in place because nobody owns them.
- Weak follow-up: A source disappears for one day and the cleanup is assumed complete.
Suped workflow
- Clear source state: Verified and unverified senders are separated in one view.
- DNS guidance: DMARC, SPF, DKIM, Hosted SPF, and Hosted MTA-STS sit together.
- Operational alerts: Real-time alerts catch source changes before they become policy failures.
Views from the trenches
Best practices
Confirm reporter, source IP, envelope domain, and DKIM selector before editing DNS.
Remove Check Point SPF entries when no approved outbound service uses those IPs.
Match low-volume rows against message trace dates before treating a source as active.
Common pitfalls
Adding every visible DMARC source to SPF authorizes mail paths that do not send for you.
Reading a 100 percent DMARC pass as full proof can hide the actual path evidence.
Stopping at connector checks misses add-ins, resellers, and old security trials.
Expert tips
A DKIM pass with the Microsoft selector points back to original Microsoft 365 signing.
SPF only passes for Check Point when the envelope domain authorizes its sending IP.
Treat Avanan rows as evidence to verify, not an instruction to add another include.
Expert from Email Geeks says Avanan usually means Check Point handled the message path or the recipient-side report named the Check Point IP.
2024-11-11 - Email Geeks
Marketer from Email Geeks says a finance or reseller invoice search often finds a trial, add-in, or security service that IT did not document.
2024-11-12 - Email Geeks
The clean fix
The fix is not "find Avanan in Microsoft 365". The fix is to prove whether Avanan is an approved sender. If it is not, remove the Check Point or Avanan SPF authorization, keep Microsoft 365 DKIM signing healthy, and watch the next DMARC reports for the source to drop away.
If the source remains after cleanup, look for outbound rerouting, a reseller-managed security tenant, or a recipient-side reporting pattern. If DMARC passes because DKIM survives, the source can still be visible. Visibility is evidence to investigate, not proof that the vendor belongs in your SPF record.
Minimal DMARC record while investigatingtext
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1
Once the source inventory is clean, move policy in stages. A sudden jump to quarantine or reject without source ownership creates avoidable failures. If that happens, the next diagnostic step is checking why DMARC authentication fails even when one mechanism appears to pass.
