• Avanan SPF Record: How to Set Up, Fix, and Optimize Your SPF for Check Point Harmony Email

Avanan SPF Record: How to Set Up, Fix, and Optimize Your SPF for Check Point Harmony Email

by

Last Updated:
9 min read
Avanan SPF Record: How to Set Up, Fix, and Optimize Your SPF for Check Point Harmony Email

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.

ModeMail FlowSPF Change?DKIM ImpactDMARC Alignment
API / Monitor / DetectSender → M365/GWS → Inbox; Avanan scans via APINone. Mail originates from M365/GWS IPs already in SPFUnchangedPasses
Inline / Prevent (outbound)Internal → M365/GWS → Check Point HEC → External (double-hop)Required. add Check Point includePreserved if M365/GWS signs before interceptionDKIM usually aligns; SPF may softfail on Return-Path
Full MX inlineMX redirects to Check Point cloudRequired. Add Check Point IPsDepends on signing configurationVerify 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?

ScenarioRecommended ApproachWhy
You have fewer than 7 DNS lookups in your current SPFStatic include (spfa.cpmails.com)Simple, transparent, easy to audit
You are at 8–10 DNS lookups alreadyManaged SPF Macro or SPF flatteningYou need to conserve lookups. Macro is built-in; flattening is vendor-neutral
You manage 10+ client domains as an MSPSPF flattening with a centralized tool like PowerSPFRepeatable, vendor-agnostic, auditable across all clients
Auditors need to verify authorized IPs directlyStatic include or SPF flatteningMacros 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 StackApprox. LookupsStatusAction Needed
M365 + Avanan only4–5SafeNone
M365 + Avanan + Salesforce + HubSpot9–11At limitFlatten or use macros
M365 + Avanan + Salesforce + HubSpot + Mailchimp + Zendesk14–16PermErrorMust flatten; SPF fails for ALL email
Flattened record (via PowerSPF)1–2OptimalAuto-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.

FactorCheck Point SPF MacroSPF Flattening (e.g., PowerSPF)
DNS lookup countReduces Avanan’s contribution to ~1 lookupReduces ALL includes to ~1 lookup
Transparency / AuditabilityOpaque until resolved. Auditors cannot see authorized IPs in DNSFully transparent. All IPs visible directly in DNS
Vendor dependencySPF depends on checkpoint-spf.com DNS availabilitySPF depends on flattening provider infrastructure
ScopeOnly solves the Avanan portion of your SPFSolves the entire SPF record. All vendors
MSP scalabilityMust be configured per-org via Check Point portalCan be centralized across all client domains from one dashboard
PortabilityLeaving Avanan requires full SPF reconfigurationLeaving 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:

  1. Audit your current authentication posture. Check SPF, DKIM, and DMARC status using a free domain analyzer tool.
  2. Fix any existing SPF/DKIM issues. Ensure SPF is under 10 lookups and DKIM is properly signed at the email provider level.
  3. Add the Avanan SPF include (or activate managed SPF macro). Follow the steps in the section above.
  4. Validate SPF pass. Test with the SPF Checker and email header analysis.
  5. Enable Avanan inline mode. Only after SPF and DKIM are validated.
  6. Monitor DMARC reports for 72 hours. Watch for any new SPF or DKIM alignment failures.
  7. 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 / SymptomMost Likely CauseFix
spf=permerrorOver 10 DNS lookups after adding Avanan include on top of M365, Salesforce, and other servicesFlatten SPF with PowerSPF or activate Check Point’s macro-based include to reduce lookup count
spf=softfail or spf=failAvanan include missing, wrong include statement, or duplicate SPF TXT record in DNSVerify include statement matches Section 2; ensure only one SPF TXT record exists per domain
dkim=fail after enabling inlineAvanan’s inline header modifications invalidated the DKIM signatureConfigure 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 failureFix SPF and DKIM independently, then re-verify alignment before re-enabling enforcement
cpmails.com or cloud-sec-av.com appearing in DMARC reports unexpectedlyInline outbound is enabled (expected) or a previous admin added spfa.cpmails.com and it persistsAudit 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:

  1. 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.
  2. 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.
  3. 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.

Start your 15-day free trial 

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.

CTA