I punti chiave da prendere in considerazione
- 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.
- L'aggiunta dell'inclusione SPF di Avanan è l'operazione che più spesso porta le organizzazioni a superare il limite di 10 ricerche DNS previsto dalla RFC 7208, causando un errore SPF PermError e compromettendo la consegna di tutta la posta in uscita.
- Le implementazioni solo API (modalità Monitor / Detect) non modificano il flusso di posta e non richiedono alcuna modifica dell'SPF. Solo le implementazioni in modalità inline (Prevent) e quelle su gateway MX richiedono l'inserimento.
- La modalità di implementazione in linea di Avanan può inoltre compromettere l'allineamento DKIM se la firma DKIM non è configurata a livello del provider di posta elettronica (Microsoft 365 o Google Workspace), anziché all'interno di Avanan.
- Appiattimento SPF tramite uno strumento come PowerSPF o il meccanismo di macro SPF integrato di Check Point risolve definitivamente il limite di ricerca e mantiene intatta la tua politica DMARC.
Se si implementa Check Point Harmony Email & Collaboration (precedentemente Avanan) in modalità inline, è necessario aggiungere un record SPF "include" al proprio DNS; in caso contrario, la posta in uscita non supererà i controlli SPF e rischia di essere respinta da Gmail, Yahoo e Microsoft Outlook.
Da quando Google ha iniziato a respingere definitivamente la posta in massa non conforme alla fine del 2025 e Microsoft ha iniziato a restituire errori 550; 5.7.515 a partire da maggio 2025, la configurazione SPF è un requisito operativo imprescindibile.
Questa guida illustra le due sintassi valide per l'inclusione di SPF, le scelte relative alla modalità inline o API, la configurazione di DKIM, l'allineamento DMARC, il limite di 10 query, la risoluzione dei problemi e i modelli multi-tenant per gli MSP.
Che tu sia un amministratore IT che implementa Avanan per la prima volta, un MSP che lo gestisce per decine di tenant dei propri clienti o un CISO che deve garantire la conformità del proprio sistema di autenticazione in vista di un audit, di seguito troverai una soluzione per ogni scenario.
Cos'è Avanan (ora Check Point Email Security)?
Avanan è stata acquisita da Check Point Software Technologies nell'agosto 2021 e ha cambiato nome in Harmony Email & Collaboration. Nel 2025, Check Point ha ribattezzato nuovamente il prodotto Check Point Email Security, allineandolo alla più ampia strategia aziendale basata sull'intelligenza artificiale.
Nonostante due cambi di marchio, la maggior parte degli amministratori IT, delle piattaforme di recensioni e dei forum online continua a utilizzare il nome «Avanan», e Check Point continua a gestire un portale a marchio Avanan che offre un percorso di migrazione su richiesta verso la nuova interfaccia.
L'architettura del prodotto è di tipo "API-first". Si collega a Microsoft 365 o Google Workspace tramite API per eseguire la scansione delle e-mail in entrata dopo la consegna. Quando gli amministratori attivano la modalità inline (nota anche come "Prevent"), Avanan intercetta la posta in uscita nella pipeline di trasporto, sottoponendola a scansione attraverso l'infrastruttura cloud di Check Point prima di inoltrarla al destinatario.
È proprio questo tipo di intercettazione in linea a rendere necessario l'SPF: le e-mail in uscita partono ora dagli indirizzi IP di Check Point, che devono essere autorizzati nel vostro record SPF.
Per ulteriori informazioni su come i gateway di sicurezza e-mail interagiscono con i protocolli di autenticazione, consultare SPF, DKIM e DMARC: come funzionano insieme.
È davvero necessario modificare il record SPF per Avanan?
Se stai utilizzando Avanan in modalità solo API (Monitor o Detect), fermati qui perché non è necessario modificare il tuo record SPF. La posta continuerà a passare dagli indirizzi IP di Microsoft 365 o Google Workspace già autorizzati nel tuo DNS.
| Modo | Flusso della posta | Cambiare il fattore di protezione solare? | Impatto del DKIM | Allineamento DMARC |
|---|---|---|---|---|
| API / Monitoraggio / Rilevamento | Mittente → M365/GWS → Posta in arrivo; scansione di Avanan tramite API | Nessuno. Le e-mail provengono da indirizzi IP di M365/GWS già presenti nell'SPF | Senza modifiche | Abbonamenti |
| In linea / Prevenzione (in uscita) | Interno → M365/GWS → Check Point HEC → Esterno (doppio salto) | Obbligatorio. Aggiungere l'include di Check Point | Rimane in vigore se M365/GWS firma prima dell'intercettazione | Il DKIM di solito funziona correttamente; l'SPF potrebbe generare un "soft fail" nel campo Return-Path |
| MX completo in linea | MX reindirizza al cloud di Check Point | Obbligatorio. Aggiungere gli indirizzi IP di Check Point | Dipende dalla configurazione della firma | Verificare la conformità sia dell'SPF che del DKIM |
Avanan SPF Include: quale ti serve? (Riferimento 2026)
Esistono due metodi validi per l'inclusione degli SPF in Check Point Harmony Email. Essi sono i seguenti:
Inclusione legacy (statica): include:spfa.cpmails.com
Si tratta dell'inclusione SPF statica originale introdotta da Check Point nel luglio 2023, che riunisce in un'unica voce gli elenchi di indirizzi IP precedenti, suddivisi per regione. Quando si aggiunge include:spfa.cpmails.com al proprio record SPF, questo viene risolto in circa 21 voci IPv4 che coprono le regioni AWS in Nord America, Europa, APAC, Regno Unito, India, Canada ed Emirati Arabi Uniti.
Poiché i meccanismi IPv4 non vengono conteggiati ai fini del limite di 10 ricerche, l'inclusione stessa consuma esattamente una ricerca DNS del tuo budget.
Utilizza questa opzione se non disponi di una licenza per il componente aggiuntivo DMARC Management di Check Point o se preferisci un record trasparente e indipendente dal fornitore che qualsiasi revisore possa controllare direttamente nel DNS.
Managed SPF Macro Include: include:{code}.spf.checkpoint-spf.com
Si tratta della nuova funzionalità di gestione SPF di Check Point, descritta nella guida amministrativa di Harmony Email e attivabile dal portale alla voce DMARC → Gestione SPF. Utilizza l'espansione delle macro SPF (secondo RFC 7208 §5.7) tramite un codice univoco per ogni tenant. La sintassi è:
v=spf1 include:{your-org-code}.spf.checkpoint-spf.com include:spf.protection.outlook.com -all
Dove {your-org-code} è un identificatore univoco presente nel portale di amministrazione di Check Point Email Security. Il meccanismo richiede una sola ricerca, ma il traffico viene instradato attraverso una zona DNS dinamica e specifica per ogni tenant gestita da Check Point. È progettato per ridurre l'impronta dei record SPF quando si utilizzano più servizi in uscita di Check Point.
Quale utilizzare?
| Scenario | Approccio raccomandato | Perché |
|---|---|---|
| Nel tuo attuale record SPF sono presenti meno di 7 risoluzioni DNS | Inclusione statica (spfa.cpmails.com) | Semplice, trasparente, di facile verifica |
| Hai già effettuato 8-10 ricerche DNS | Macro SPF gestita o appiattimento SPF | È necessario ridurre il numero di ricerche. La macro è integrata; l'appiattimento è indipendente dal fornitore |
| In qualità di MSP, gestisci oltre 10 domini dei clienti | Uniformazione degli SPF con uno strumento centralizzato come PowerSPF | Ripetibile, indipendente dal fornitore, verificabile per tutti i clienti |
| I revisori devono verificare direttamente gli indirizzi IP autorizzati | Inclusione statica o appiattimento SPF | Le macro rimangono oscure finché non vengono risolte; i revisori non riescono a individuare facilmente gli indirizzi IP autorizzati |
Importante: Non utilizzare entrambi gli include contemporaneamente. Aggiungerli entrambi crea autorizzazioni duplicate, spreca ricerche DNS e complica gli audit. Scegli un approccio e applicalo in modo coerente.
Suggerimento per l'immagine: Scheda di confronto affiancato dei due prodotti con pro e contro.
Testo alternativo: «Confronto tra l'include SPF tradizionale di Avanan (spfa.cpmails.com) e l'include basato su macro (checkpoint-spf.com), con particolare attenzione alle differenze in termini di trasparenza, costi di ricerca e verificabilità.»
Come aggiungere il record SPF di Avanan al proprio dominio (procedura dettagliata)
Prima di modificare qualsiasi record DNS, verifica innanzitutto il tuo attuale record SPF e il numero di query. Utilizza un strumento gratuito di verifica SPF per vedere quante ricerche DNS consuma attualmente il tuo dominio. Se sei a 8 o più, leggi la sezione sulla risoluzione dei problemi qui sotto prima di aggiungere qualsiasi nuova istruzione include.
Passaggio 1: Verifica la modalità di distribuzione
Accedi al portale di amministrazione di Check Point Email Security. Accedi alla tua politica di sicurezza in uscita. Se stai utilizzando esclusivamente la modalità API/Monitor, non è necessario apportare modifiche all'SPF. Se è abilitata la modalità Prevent (inline) o la scansione DLP in uscita, passa al passaggio 2.
Passaggio 2: Accedi al tuo provider DNS
Accedi alla console di gestione DNS del tuo dominio (GoDaddy, Cloudflare, AWS Route 53, Azure DNS, Namecheap o qualsiasi altro provider che ospita il tuo dominio). Individua il record TXT SPF esistente per il tuo dominio. Inizia con v=spf1. Se non esiste alcun record SPF, puoi crearne uno.
Passaggio 3: aggiungi l'Include di Avanan al tuo record SPF
Inserisci l'include di Avanan nel tuo record esistente. Non creare un secondo record TXT SPF: il DNS ne consente solo uno per dominio. Ecco un esempio di come appare la situazione prima e dopo in un ambiente Microsoft 365:
Prima:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com ~all
Dopo:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:spfa.cpmails.com ~all
Passaggio 4: Verifica del record aggiornato
Dopo aver salvato la modifica al DNS, attendere la propagazione (in genere da 15 minuti a 48 ore, a seconda dell'impostazione del TTL). Quindi utilizzare lo SPF Checker di PowerDMARC per verificare che la sintassi del record sia valida, che il numero totale di ricerche DNS rimanga inferiore a 10 e che non venga rilevato alcun PermError.
Passaggio 5: inviare un'e-mail di prova e monitorare i rapporti DMARC
Invia un'e-mail di prova da un account utente che passa attraverso la modalità inline di Avanan. Verifica che nelle intestazioni dell'e-mail sia presente spf=pass utilizzando un strumento di analisi delle intestazioni. Quindi monitora i tuoi report aggregati DMARC per 48–72 ore per confermare che nessuna fonte di invio legittima risulti ora non conforme all'allineamento.
Il limite di 10 ricerche: perché l'aggiunta di Avanan compromette il funzionamento della tua posta elettronica
La RFC 7208 specifica un limite massimo di 10 ricerche DNS per ogni valutazione SPF. I meccanismi che consumano ricerche includono include, a, mx, ptr, exists e redirect. Ogni comando include attiva inoltre ricerche ricorsive per eventuali comandi include annidati al suo interno. Meccanismi come ip4, ip6 e all non consumano ricerche.
Se il numero di consultazioni supera 10, viene generato un PermError e il server di posta ricevente deve considerare l'SPF come se fosse fallito completamente, non solo per la posta instradata da Avanan, ma per tutte le e-mail in uscita dal proprio dominio.
Ecco come si ripartiscono le ricerche in un tipico stack aziendale: Microsoft 365 consuma circa 3 ricerche, Salesforce ne aggiunge 3, HubSpot ne aggiunge 2, Mailchimp ne aggiunge 1, Zendesk ne aggiunge 2 e Avanan ne aggiunge 1. Il totale è di 12 ricerche, con due in eccesso rispetto al limite. Scopri di più su SPF e sul limite di lookup.
Esempi pratici di ricerca SPF con Avanan
| Pila dei record SPF | Circa [numero] ricerche | Stato | È necessario intervenire |
|---|---|---|---|
| Solo M365 + Avanan | 4–5 | Sicuro | Nessuno |
| M365 + Avanan + Salesforce + HubSpot | 9–11 | al limite | Appiattire o utilizzare le macro |
| M365 + Avanan + Salesforce + HubSpot + Mailchimp + Zendesk | 14–16 | Errore permanente | È necessario appiattire; l'SPF non funziona per TUTTE le e-mail |
| Dati appiattiti (tramite PowerSPF) | 1–2 | Ottimale | Gestione automatica; nessuna operazione manuale sul DNS |
| Hai già superato il limite di 10 ricerche? PowerDMARC PowerSPF di PowerDMARC appiattisce automaticamente il tuo record SPF e lo mantiene entro il limite, anche quando aggiungi nuovi servizi come Avanan. Inizia la tua prova gratuita di 15 giorni |
SPF Macro di Avanan vs. SPF Flattening: confronto
La gestione dell'SPF su larga scala spesso si riduce al rispetto dei limiti di ricerca senza compromettere le fonti di invio legittime. Man mano che i record diventano più complessi, si ricorre ad approcci come l'appiattimento SPF e le macro SPF per gestirne la complessità, ma questi risolvono il problema in modi molto diversi.
Prima di scegliere tra le due opzioni, è importante capire come funziona ciascun approccio, quali compromessi comportano e come si inseriscono negli ambienti di posta elettronica reali.
Come funziona la macro SPF di Check Point:
Quando si attiva la gestione SPF nel portale di amministrazione, questa sostituisce i file di inclusione standard con un unico file di inclusione basato su macro che risolve dinamicamente gli indirizzi IP autorizzati al momento della richiesta. Check Point gestisce la zona DNS. Non sarà più necessario intervenire sul DNS per la parte relativa ad Avanan.
Come funziona l'effetto lisciante di SPF:
L'appiattimento risolve tutti i meccanismi di inclusione in indirizzi IPv4/IPv6 fissi, riducendo i tempi di ricerca quasi a zero. L'appiattimento manuale smette di funzionare quando i fornitori cambiano gli indirizzi IP. Servizi automatizzati come PowerSPF gestiscono automaticamente i continui cambiamenti di IP, in modo che il tuo record rimanga valido.
| Fattore | Macro SPF di Check Point | Appiattimento SPF (ad es. PowerSPF) |
|---|---|---|
| Numero di ricerche DNS | Riduce il carico di Avanan a circa 1 ricerca | Riduce TUTTI gli include a circa 1 ricerca |
| Trasparenza / Verificabilità | Informazioni non disponibili fino a risoluzione del problema. I revisori non riescono a visualizzare gli indirizzi IP autorizzati nel DNS | Completamente trasparente. Tutti gli indirizzi IP sono visibili direttamente nel DNS |
| Dipendenza dal fornitore | L'SPF dipende dalla disponibilità del DNS di checkpoint-spf.com | L'SPF dipende dall'infrastruttura di smistamento del provider |
| Portata | Risolve solo la parte relativa ad Avanan del tuo SPF | Risolve l'intero record SPF. Tutti i fornitori |
| Scalabilità di MSP | Deve essere configurato per ogni organizzazione tramite il portale Check Point | Può essere gestito in modo centralizzato per tutti i domini dei clienti da un'unica dashboard |
| Portabilità | L'uscita da Avanan richiede una riconfigurazione completa dell'SPF | Disattivando il provider di appiattimento è possibile esportare il record appiattito |
In che modo la modalità inline di Avanan influisce sull'allineamento DKIM e DMARC
Check Point offre il servizio DKIM gestito tramite delega dei record NS, grazie al quale gli amministratori delegano a Check Point specifici sottodomini selettori DKIM per la gestione automatizzata e la rotazione delle chiavi.
La firma DKIM nativa in Microsoft 365 o Google Workspace viene mantenuta anche in modalità inline, a condizione che la firma avvenga prima che Avanan intercetti il messaggio.
Il vero rischio è sottile. La modalità inline di Avanan intercetta le e-mail nel flusso di posta e può modificare le intestazioni, il che potrebbe invalidare le firme DKIM che si basano su valori specifici delle intestazioni e del corpo del messaggio.
A differenza delle soluzioni basate esclusivamente su API, che analizzano le e-mail dopo la consegna senza intervenire sulla catena di autenticazione, la modalità inline reindirizza attivamente il messaggio attraverso l'infrastruttura di Check Point.
La trappola dell'allineamento DMARC:
DMARC richiede l'uso di SPF o DKIM per l'allineamento con il dominio "Da". Se la modalità inline compromette DKIM, DMARC si affida esclusivamente all'allineamento SPF. Se anche SPF è configurato in modo errato (il problema dell'inclusione descritto sopra), DMARC fallisce completamente.
Lo scenario peggiore: gli amministratori indeboliscono il DMARC passando da p=reject a p=none per evitare che le e-mail legittime vengano bloccate, ottenendo esattamente l'opposto di ciò che dovrebbe garantire l'implementazione di uno strumento di sicurezza.
Come evitarlo:
Configurare correttamente l'SPF prima di abilitare la modalità inline. Assicurarsi che la firma DKIM avvenga a livello del provider di posta elettronica (Microsoft 365 o Google Workspace), non all'interno di Avanan. Verificare l'allineamento DMARC con un strumento di verifica DMARC prima e dopo l'implementazione. Solo allora abilita la scansione in linea.
Per il monitoraggio in tempo reale di tutte le fonti di invio, Hosted DMARC di PowerDMARC rileva le violazioni dell'autenticazione nel momento stesso in cui si verificano.
Ordine di implementazione delle operazioni: DMARC + Avanan senza compromettere la sicurezza
L'errore più comune è quello di abilitare la modalità inline di Avanan prima che l'infrastruttura di autenticazione sia pronta. Segui invece questa procedura:
- Verifica lo stato attuale delle tue misure di autenticazione. Controlla lo stato di SPF, DKIM e DMARC utilizzando uno strumento gratuito di analisi dei domini.
- Risolvi eventuali problemi relativi a SPF/DKIM. Assicurati che il numero di lookups SPF sia inferiore a 10 e che DKIM sia correttamente firmato a livello del provider di posta elettronica.
- Aggiungere l'inclusione SPF di Avanan (o attivare la macro SPF gestita). Seguire i passaggi indicati nella sezione precedente.
- Verifica la validità del certificato SPF. Esegui il test con lo strumento SPF Checker e l'analisi delle intestazioni delle e-mail.
- Abilita la modalità inline di Avanan. Solo dopo la convalida di SPF e DKIM.
- Controlla i rapporti DMARC per 72 ore. Verifica se ci sono nuovi errori di allineamento SPF o DKIM.
- Inasprire la politica DMARC solo dopo aver verificato il corretto funzionamento del monitoraggio (nel caso in cui si passi da p=none a p=quarantine o p=reject).
Risoluzione dei problemi relativi all'SPF di Avanan e agli errori di autenticazione
Questi sono i cinque problemi più comuni riscontrati dopo l'implementazione, individuati sulla base dei contributi della comunità CheckMates di Check Point, dei forum dmarcian, delle recensioni degli utenti su G2 e Capterra e delle discussioni tra amministratori IT. A ciascuno di essi corrisponde una soluzione concreta.
| Errore / Sintomo | Causa più probabile | Fissare |
|---|---|---|
| spf=errore permanente | Oltre 10 query DNS dopo l'aggiunta di Avanan, oltre a M365, Salesforce e altri servizi | Appiattire l'SPF con PowerSPF oppure attivare l'include basato su macro di Check Point per ridurre il numero di ricerche |
| spf=softfail oppure spf=fail | Avanan: inclusione mancante, istruzione di inclusione errata o record TXT SPF duplicato nel DNS | Verificare che la dichiarazione «include» corrisponda alla Sezione 2; assicurarsi che esista un solo record TXT SPF per dominio |
| dkim=fail dopo l'abilitazione di inline | Le modifiche apportate da Avanan all'intestazione in linea hanno invalidato la firma DKIM | Configurare la firma DKIM a livello di M365/Google Workspace (non in Avanan); verificare la delega NS DKIM gestita |
| dmarc=fail (sia SPF che DKIM) | L'errore permanente SPF e l'interruzione di DKIM dalla modalità inline causano un doppio errore di allineamento | Correggere SPF e DKIM separatamente, quindi ricontrollare l'allineamento prima di riattivare l'applicazione |
| cpmails.com o cloud-sec-av.com compaiono inaspettatamente nei rapporti DMARC | La funzione "Inline outbound" è abilitata (come previsto) oppure un amministratore precedente ha aggiunto spfa.cpmails.com e l'impostazione è rimasta attiva | Verifica la presenza di voci orfane nel record SPF; se l'uso inline è previsto, si tratta di un comportamento normale |
Per una diagnosi più approfondita a livello di intestazione, incolla l'intestazione di un messaggio non recapitato in Analizzatore di intestazioni e-mail di PowerDMARC per individuare esattamente dove SPF o DKIM hanno fallito nella catena di consegna.
Avanan SPF per MSP: gestione dell'autenticazione multi-tenant su larga scala
È qui che il divario operativo è più ampio. 30 o più domini dei clienti, ciascuno ospitato su un provider DNS diverso, ciascuno con uno stack SaaS diverso, ciascuno che effettua un numero diverso di ricerche SPF. Implementare Avanan su tutti questi domini significa intervenire su ogni record SPF, verificare ogni conteggio delle ricerche e monitorare ogni report DMARC, per ogni cliente e per ogni dominio.
Le tre strategie specifiche per gli MSP che evitano il caos nell'implementazione:
- Verifica l'SPF di ogni cliente prima dell'onboarding: utilizza uno strumento di ricerca automatizzato (non nslookup manuale) per verificare il record SPF attuale di ciascun dominio, contare le ricerche e segnalare qualsiasi dominio che abbia già raggiunto o si avvicini al limite di 10 ricerche. L'API di PowerDMARC supporta controlli di dominio in blocco su tutto il tuo portafoglio clienti.
- Standardizzare l'utilizzo di un unico fornitore di servizi di appiattimento SPF per tutti i tenant: La macro SPF di Check Point deve essere configurata per ogni tenant all'interno del portale Check Point. Una soluzione centralizzata di appiattimento SPF come PowerSPF consente di gestire i record di ogni cliente da un'unica dashboard, indipendentemente dal gateway di sicurezza utilizzato.
- Genera report DMARC in white label per i QBR: Ai clienti interessano i risultati, non il codice XML grezzo. Il programma partner MSP/MSSP di PowerDMARC offre dashboard multi-tenant, portali con marchio white-label e gestione SPF basata su API per ogni tenant protetto da Check Point, trasformando il monitoraggio DMARC in entrate ricorrenti per la tua attività.
Mantieni pulito il tuo SPF dopo l'implementazione di Avanan
La configurazione dell'SPF di Avanan non è complessa se si tiene conto del limite di query, si sceglie l'approccio di inclusione più adatto alla propria modalità di implementazione e si verifica l'allineamento DKIM e DMARC prima di passare alla produzione. La vera sfida non è Avanan in sé, bensì il fatto che la maggior parte delle organizzazioni si trova già vicina al limite massimo di query SPF prima ancora di aggiungere qualsiasi nuovo strumento.
La configurazione SPF non è un'operazione una tantum. Ogni nuovo strumento SaaS, piattaforma di marketing o servizio di posta elettronica adottato dalla vostra organizzazione comporta un'ulteriore consultazione. Una gestione continua dell'SPF è l'unico modo per evitare che lo stesso problema si ripeta con il prossimo fornitore che integrerete nel vostro sistema.
| Prendi il controllo del tuo SPF una volta per tutte. La piattaforma PowerDMARC offre l'appiattimento SPF automatizzato, il monitoraggio DMARC in tempo reale e una visibilità completa su ogni dominio, così l'aggiunta di un nuovo strumento non causerà mai più interruzioni nella tua posta elettronica. |
Domande frequenti
Qual è l'attuale versione di SPF inclusa in 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.
Avanan supporta il protocollo DKIM?
Sì. Check Point offre ora il servizio DKIM gestito tramite delega dei record NS, e la firma DKIM nativa di M365/Google Workspace viene mantenuta grazie alla modalità inline. Alcune pagine di riferimento di terze parti risalenti a tempi passati indicano ancora che Avanan non supporta il DKIM: si tratta di informazioni obsolete.
Quante ricerche DNS comporta l'aggiunta dell'SPF di Avanan?
L'include statico (spfa.cpmails.com) comporta esattamente una ricerca DNS. Questo si traduce in circa 21 voci IPv4, che non richiedono ulteriori ricerche. Anche la macro SPF gestita comporta una sola ricerca.
Posso utilizzare contemporaneamente sia l'include statico di Avanan che l'include macro?
No. L'uso di entrambi comporta autorizzazioni duplicate, sprechi nelle operazioni di ricerca e complica le attività di controllo. Scegliete un unico approccio in base al vostro ambiente e alle vostre licenze.
Devo modificare il mio SPF se eseguo Avanan in modalità solo API?
No. Le modalità API, Monitor e Detect instradano la posta tramite gli indirizzi IP di Microsoft 365 o Google Workspace già autorizzati nel tuo record SPF. Solo la modalità inline (Prevent) e le implementazioni MX complete richiedono l'inclusione.
Cos'è cpmails.com? Cos'è checkpoint-spf.com?
cpmails.com è il dominio SPF di Check Point per il flusso in uscita statico legacy. checkpoint-spf.com è il dominio basato su macro e specifico per ogni tenant utilizzato dal più recente componente aggiuntivo SPF Management di Check Point. Entrambi fanno parte dell'infrastruttura ufficiale di Check Point.
È meglio usare ~all o -all con Avanan?
Check Point consiglia di utilizzare -all (hardfail) solo dopo essersi assicurati che tutti i mittenti legittimi siano inclusi. Per motivi di sicurezza, utilizzare ~all (softfail) durante la fase iniziale di implementazione. Non utilizzare mai +all.


