Key Takeaways
- Avanan (now Check Point Email Security, formerly Harmony Email & Collaboration) requires an SPF include statement in your DNS to authenticate outbound email routed through its infrastructure. There are two valid approaches: the legacy static include:spfa.cpmails.com and the newer macro-based include:{code}.spf.checkpoint-spf.com. You use one or the other but not both.
- Adding Avanan’s SPF include is the step that most often pushes organizations past the RFC 7208 10-DNS-lookup limit, causing SPF PermError and breaking email delivery for all outbound mail.
- API-only deployments (Monitor / Detect mode) do not change the mail flow and do not require any SPF modification. Only inline (Prevent) mode and MX-gateway deployments require the include.
- Avanan’s inline deployment mode can also break DKIM alignment if DKIM signing is not configured at the email provider level (Microsoft 365 or Google Workspace), not within Avanan.
- SPF flattening via a tool like PowerSPF or Check Point’s built-in SPF macro mechanism solves the lookup limit permanently and keeps your DMARC policy intact.
If you deploy Check Point Harmony Email & Collaboration (formerly Avanan) in inline mode, you must add an SPF include to your DNS, or your outbound mail will fail SPF checks and risk rejection by Gmail, Yahoo, and Microsoft Outlook.
Since Google began permanently rejecting non-compliant bulk mail in late 2025 and Microsoft started returning 550; 5.7.515 errors from May 2025, SPF configuration is a hard operational requirement.
This guide covers the two valid SPF include syntaxes, inline versus API mode decisions, DKIM setup, DMARC alignment, the 10-lookup limit, troubleshooting, and MSP multi-tenant patterns.
Whether you are an IT admin deploying Avanan for the first time, an MSP managing it across dozens of client tenants, or a CISO ensuring your authentication posture survives an audit, every scenario is addressed below.
What Is Avanan (Now Check Point Email Security)?
Avanan was acquired by Check Point Software Technologies in August 2021 and rebranded to Harmony Email & Collaboration. In 2025, Check Point renamed the product again to Check Point Email Security, aligning it with the company’s broader AI-driven strategy.
Despite two rebrands, most IT admins, review platforms, and community forums still use the name “Avanan,” and Check Point continues to maintain an Avanan-branded portal with an on-demand migration path to the new interface.
The product’s architecture is API-first. It connects to Microsoft 365 or Google Workspace via API to scan inbound email post-delivery. When admins enable inline mode (also called “Prevent”), Avanan intercepts outbound mail in the transport pipeline, scanning it through Check Point’s cloud infrastructure before routing it to the recipient.
This inline interception is what creates the SPF requirement, outbound email now leaves from Check Point’s IP addresses, which must be authorized in your SPF record.
For more context on how email security gateways interact with authentication protocols, see SPF, DKIM, and DMARC: How They Work Together.
Do You Even Need to Change Your SPF Record for Avanan?
If you are running Avanan in API-only mode (Monitor or Detect), stop here because you do not need to touch your SPF record. Mail still flows from Microsoft 365 or Google Workspace IPs that are already authorized in your DNS.
| Mode | Mail Flow | SPF Change? | DKIM Impact | DMARC Alignment |
|---|---|---|---|---|
| API / Monitor / Detect | Sender → M365/GWS → Inbox; Avanan scans via API | None. Mail originates from M365/GWS IPs already in SPF | Unchanged | Passes |
| Inline / Prevent (outbound) | Internal → M365/GWS → Check Point HEC → External (double-hop) | Required. add Check Point include | Preserved if M365/GWS signs before interception | DKIM usually aligns; SPF may softfail on Return-Path |
| Full MX inline | MX redirects to Check Point cloud | Required. Add Check Point IPs | Depends on signing configuration | Verify both SPF and DKIM alignment |
Avanan SPF Include: Which One Do You Need? (2026 Reference)
There are two valid SPF include approaches for Check Point Harmony Email. They are as follows:
Legacy (Static) Include: include:spfa.cpmails.com
This is the original, static SPF include that Check Point introduced in July 2023, consolidating earlier per-region IP lists into a single entry. When you add include:spfa.cpmails.com to your SPF record, it resolves to approximately 21 ip4: entries covering AWS regions across North America, Europe, APAC, UK, India, Canada, and UAE.
Since ip4: mechanisms do not count against the 10-lookup limit, the include itself costs exactly one DNS lookup from your budget.
Use this when you are not licensed for Check Point’s DMARC Management add-on or when you prefer a transparent, vendor-neutral record that any auditor can inspect directly in DNS.
Managed SPF Macro Include: include:{code}.spf.checkpoint-spf.com
This is Check Point’s newer SPF Management feature, documented in the Harmony Email admin guide and activated from the portal under DMARC → SPF Management. It uses SPF macro expansion (per RFC 7208 §5.7) via a unique per-tenant code. The syntax is:
v=spf1 include:{your-org-code}.spf.checkpoint-spf.com include:spf.protection.outlook.com -all
Where {your-org-code} is a unique identifier found in the Check Point Email Security Administrator Portal. The mechanism costs one lookup but routes through a dynamic, tenant-specific DNS zone that Check Point manages. It is designed to reduce the SPF record footprint when you use multiple Check Point outbound services.
Which One Should You Use?
| Scenario | Recommended Approach | Why |
|---|---|---|
| You have fewer than 7 DNS lookups in your current SPF | Static include (spfa.cpmails.com) | Simple, transparent, easy to audit |
| You are at 8–10 DNS lookups already | Managed SPF Macro or SPF flattening | You need to conserve lookups. Macro is built-in; flattening is vendor-neutral |
| You manage 10+ client domains as an MSP | SPF flattening with a centralized tool like PowerSPF | Repeatable, vendor-agnostic, auditable across all clients |
| Auditors need to verify authorized IPs directly | Static include or SPF flattening | Macros are opaque until resolved; auditors cannot easily see authorized IPs |
Important: Do not use both includes simultaneously. Adding both creates duplicate authorization, wastes DNS lookups, and complicates audits. Choose one approach and apply it consistently.
Image suggestion: Side-by-side comparison card of the two includes pros/cons.
Alt text: “Comparison of Avanan’s legacy SPF include (spfa.cpmails.com) versus the macro-based include (checkpoint-spf.com), highlighting transparency, lookup cost, and auditability differences.”
How to Add the Avanan SPF Record to Your Domain (Step-by-Step)
Before editing any DNS records, start by checking your current SPF record and lookup count. Use a free SPF checker to see how many DNS lookups your domain currently consumes. If you are at 8 or more, read the troubleshooting section below before adding any new include statements.
Step 1: Confirm Your Deployment Mode
Log in to the Check Point Email Security Administrator Portal. Navigate to your outbound security policy. If you are running in API/Monitor mode only, you do not need SPF changes. If Prevent (inline) mode or DLP outbound scanning is enabled, proceed to Step 2.
Step 2: Access Your DNS Provider
Log in to your domain’s DNS management console (GoDaddy, Cloudflare, AWS Route 53, Azure DNS, Namecheap, or whichever provider hosts your domain). Locate the existing SPF TXT record for your domain. It starts with v=spf1. If no SPF record exists, you can create one.
Step 3: Add the Avanan Include to Your SPF Record
Merge the Avanan include into your existing record. Do not create a second TXT SPF record. DNS allows only one per domain. Here is a before-and-after example for a Microsoft 365 environment:
Before:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com ~all
After:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:spfa.cpmails.com ~all
Step 4: Validate the Updated Record
After saving the DNS change, wait for propagation (typically 15 minutes to 48 hours, depending on your TTL setting). Then use PowerDMARC’s SPF Checker to verify that the record syntax is valid, the total DNS lookups remain under 10, and no PermError is detected.
Step 5: Send a Test Email and Monitor DMARC Reports
Send a test email from a user account that routes through Avanan’s inline mode. Check the email headers for spf=pass using an email header analyzer. Then monitor your DMARC aggregate reports for 48–72 hours to confirm no legitimate sending sources are now failing alignment.
The 10-Lookup Limit: Why Adding Avanan Breaks Your Email
RFC 7208 specifies a hard limit of 10 DNS mechanism lookups per SPF evaluation. Mechanisms that consume lookups include include, a, mx, ptr, exists, and redirect. Each include also triggers recursive lookups for any nested includes inside it. Mechanisms like ip4, ip6, and all do not consume lookups.
Exceeding 10 lookups produces a PermError, and the receiving mail server must treat SPF as if it failed entirely, not just for Avanan-routed mail, but for all outbound email from your domain.
Here is how a typical enterprise stack breaks: Microsoft 365 consumes approximately 3 lookups, Salesforce adds 3, HubSpot adds 2, Mailchimp adds 1, Zendesk adds 2, and Avanan adds 1. That totals 12 lookups with two over the limit. Learn more about SPF and the lookup limit.
Real-World SPF Lookup Examples with Avanan
| SPF Record Stack | Approx. Lookups | Status | Action Needed |
|---|---|---|---|
| M365 + Avanan only | 4–5 | Safe | None |
| M365 + Avanan + Salesforce + HubSpot | 9–11 | At limit | Flatten or use macros |
| M365 + Avanan + Salesforce + HubSpot + Mailchimp + Zendesk | 14–16 | PermError | Must flatten; SPF fails for ALL email |
| Flattened record (via PowerSPF) | 1–2 | Optimal | Auto-maintained; no manual DNS work |
| Already over the 10-lookup limit? PowerDMARC’s PowerSPF automatically flattens your SPF record and keeps it under the limit, even as you add new services like Avanan. Start your 15-day free trial |
Avanan’s SPF Macro vs. SPF Flattening: Comparison
Managing SPF at scale often comes down to staying within lookup limits without breaking legitimate sending sources. As records grow more complex, approaches like SPF flattening and SPF macros are used to control that complexity but they solve the problem in very different ways.
Before choosing between them, it’s important to understand how each approach works, what trade-offs they introduce, and where they fit in real-world email environments.
How Check Point’s SPF Macro works:
When you activate SPF Management in the admin portal, it replaces your standard includes with a single macro-based include that dynamically resolves authorized IPs at query time. Check Point manages the DNS zone. You never touch DNS for the Avanan portion again.
How SPF flattening works:
Flattening resolves all include mechanisms into hardcoded ip4/ip6 addresses, reducing lookups to near-zero. Manual flattening breaks when vendors change IPs. Automated services like PowerSPF handle ongoing IP changes automatically, so your record stays valid.
| Factor | Check Point SPF Macro | SPF Flattening (e.g., PowerSPF) |
|---|---|---|
| DNS lookup count | Reduces Avanan’s contribution to ~1 lookup | Reduces ALL includes to ~1 lookup |
| Transparency / Auditability | Opaque until resolved. Auditors cannot see authorized IPs in DNS | Fully transparent. All IPs visible directly in DNS |
| Vendor dependency | SPF depends on checkpoint-spf.com DNS availability | SPF depends on flattening provider infrastructure |
| Scope | Only solves the Avanan portion of your SPF | Solves the entire SPF record. All vendors |
| MSP scalability | Must be configured per-org via Check Point portal | Can be centralized across all client domains from one dashboard |
| Portability | Leaving Avanan requires full SPF reconfiguration | Leaving the flattening provider lets you export the flat record |
How Avanan’s Inline Mode Affects DKIM and DMARC Alignment
Check Point offers Managed DKIM via NS-record delegation, where admins delegate specific DKIM selector subdomains to Check Point for automated key management and rotation.
Native DKIM signing in Microsoft 365 or Google Workspace is also preserved through inline mode, provided signing occurs before Avanan intercepts the message.
The real risk is subtle. Avanan’s inline mode intercepts email in the mail flow and can modify headers, which may invalidate DKIM signatures that rely on specific header and body values.
Unlike API-only solutions that scan email after delivery without touching the authentication chain, inline mode actively re-routes the message through Check Point’s infrastructure.
The DMARC alignment trap:
DMARC requires either SPF or DKIM to align with the From domain. If inline mode breaks DKIM, DMARC relies solely on SPF alignment. If SPF is also misconfigured (the include problem described above), DMARC fails entirely.
The worst-case scenario: admins weaken DMARC from p=reject to p=none to stop legitimate email from being blocked, the exact opposite of what deploying a security tool should achieve.
How to prevent this:
Configure SPF correctly before enabling inline mode. Ensure DKIM signing happens at the email provider level (Microsoft 365 or Google Workspace), not within Avanan. Verify DMARC alignment with a DMARC checker before and after deployment. Only then enable inline scanning.
For real-time monitoring across all sending sources, PowerDMARC’s Hosted DMARC catches authentication breaks the moment they happen.
Deployment Order of Operations: DMARC + Avanan Without Weakening Security
The most common mistake is enabling Avanan’s inline mode before the authentication infrastructure is ready. Follow this sequence instead:
- Audit your current authentication posture. Check SPF, DKIM, and DMARC status using a free domain analyzer tool.
- Fix any existing SPF/DKIM issues. Ensure SPF is under 10 lookups and DKIM is properly signed at the email provider level.
- Add the Avanan SPF include (or activate managed SPF macro). Follow the steps in the section above.
- Validate SPF pass. Test with the SPF Checker and email header analysis.
- Enable Avanan inline mode. Only after SPF and DKIM are validated.
- Monitor DMARC reports for 72 hours. Watch for any new SPF or DKIM alignment failures.
- Tighten DMARC policy only after successful monitoring (if moving from p=none to p=quarantine or p=reject).
Troubleshooting Avanan SPF and Authentication Failures
These are the five most common post-deployment issues, drawn from Check Point’s CheckMates community, dmarcian forums, G2 and Capterra user reviews, and IT admin discussions. Each maps to a concrete fix.
| Error / Symptom | Most Likely Cause | Fix |
|---|---|---|
| spf=permerror | Over 10 DNS lookups after adding Avanan include on top of M365, Salesforce, and other services | Flatten SPF with PowerSPF or activate Check Point’s macro-based include to reduce lookup count |
| spf=softfail or spf=fail | Avanan include missing, wrong include statement, or duplicate SPF TXT record in DNS | Verify include statement matches Section 2; ensure only one SPF TXT record exists per domain |
| dkim=fail after enabling inline | Avanan’s inline header modifications invalidated the DKIM signature | Configure DKIM signing at M365/Google Workspace level (not in Avanan); verify Managed DKIM NS delegation |
| dmarc=fail (both SPF and DKIM) | SPF PermError + DKIM break from inline mode create dual alignment failure | Fix SPF and DKIM independently, then re-verify alignment before re-enabling enforcement |
| cpmails.com or cloud-sec-av.com appearing in DMARC reports unexpectedly | Inline outbound is enabled (expected) or a previous admin added spfa.cpmails.com and it persists | Audit SPF record for orphaned entries; if inline is intended, this is normal behavior |
For deeper header-level diagnosis, paste a failed message header into PowerDMARC’s Email Header Analyzer to trace exactly where SPF or DKIM broke in the delivery chain.
Avanan SPF for MSPs: Managing Multi-Tenant Authentication at Scale
This is where the operational gap is widest. 30 or more client domains, each hosted on a different DNS provider, each with a different SaaS stack, each consuming a different number of SPF lookups. Deploying Avanan across all of them means touching every SPF record, verifying every lookup count, and monitoring every DMARC report, per client, per domain.
The three MSP-specific tactics that prevent deployment chaos:
- Audit every client’s SPF before onboarding: Use an automated lookup tool (not manual nslookup) to check each domain’s current SPF record, count lookups, and flag any domain already at or near the 10-lookup limit. PowerDMARC’s API supports bulk domain checks across your entire book of business.
- Standardize on a single flattening vendor across all tenants: Check Point’s SPF macro must be configured per-tenant inside the Check Point portal. A centralized SPF flattening solution like PowerSPF lets you manage every client’s record from one dashboard, regardless of which security gateway they run.
- Generate white-label DMARC reports for QBRs: Clients care about results, not raw XML. PowerDMARC’s MSP/MSSP Partner Program provides multi-tenant dashboards, white-label branded portals, and API-driven SPF management across every Check Point-protected tenant, turning DMARC monitoring into recurring revenue for your practice.
Keep Your SPF Clean After Avanan Deployment
Avanan SPF configuration is not complex when you account for the lookup limit, choose the right include approach for your deployment mode, and verify DKIM and DMARC alignment before going live. The real challenge is not Avanan itself. It is that most organizations are already near the SPF lookup ceiling before they add any new tool.
SPF is not a one-time configuration. Every new SaaS tool, marketing platform, or email service your organization adopts consumes another lookup. Ongoing SPF management is the only way to prevent the same breakage from happening again with the next vendor you onboard.
| Take control of your SPF permanently. PowerDMARC’s platform gives you automated SPF flattening, real-time DMARC monitoring, and complete visibility across every domain so adding the next tool never breaks your email again. |
Frequently Asked Questions
What is the current SPF include for Avanan?
There are two options: the static include:spfa.cpmails.com and the managed SPF macro include:{orgcode}.spf.checkpoint-spf.com. Use one or the other—not both. Your org code is found in the Check Point Email Security Administrator Portal under DMARC → SPF Management.
Does Avanan support DKIM?
Yes. Check Point now offers Managed DKIM via NS-record delegation, and the native M365/Google Workspace DKIM signature is preserved through inline mode. Older third-party reference pages still claim Avanan does not support DKIM—that information is outdated.
How many DNS lookups does the Avanan SPF include add?
The static include (spfa.cpmails.com) adds exactly one DNS lookup. It resolves to approximately 21 ip4: entries, which do not consume additional lookups. The managed SPF macro similarly adds one lookup.
Can I use both the Avanan static include and the macro include at the same time?
No. Using both creates duplicate authorization, wastes lookups, and complicates audits. Choose one approach based on your environment and licensing.
Do I need to change my SPF if I run Avanan in API-only mode?
No. API / Monitor / Detect mode routes mail through Microsoft 365 or Google Workspace IPs already authorized in your SPF. Only inline (Prevent) mode and full MX deployments require the include.
What is cpmails.com? What is checkpoint-spf.com?
cpmails.com is Check Point’s SPF domain for the legacy static outbound flow. checkpoint-spf.com is the macro-based, tenant-specific domain used by Check Point’s newer SPF Management add-on. Both are legitimate Check Point infrastructure.
Should I use ~all or -all with Avanan?
Check Point recommends -all (hardfail) once you are confident every legitimate sender is included. Use ~all (softfail) during initial rollout for safety. Never use +all.
