Puntos clave
- 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.
- La incorporación del SPF de Avanan es el paso que, con mayor frecuencia, hace que las organizaciones superen el límite de 10 consultas DNS establecido en el RFC 7208, lo que provoca un error «SPF PermError» e impide el envío de todo el correo saliente.
- Las implementaciones solo mediante API (modo Monitor / Detect) no alteran el flujo de correo y no requieren ninguna modificación del SPF. Solo las implementaciones en modo inline (Prevent) y las implementaciones en puerta de enlace MX requieren la inclusión.
- El modo de implementación en línea de Avanan también puede alterar la alineación de DKIM si la firma DKIM no está configurada a nivel del proveedor de correo electrónico (Microsoft 365 o Google Workspace), y no dentro de Avanan.
- Aplanamiento de SPF mediante una herramienta como PowerSPF o el mecanismo de macros SPF integrado de Check Point resuelve el límite de consultas de forma permanente y mantiene intacta tu política DMARC.
Si implementa Check Point Harmony Email & Collaboration (antes Avanan) en modo en línea, debe añadir una inclusión SPF a su DNS; de lo contrario, su correo saliente no superará las comprobaciones SPF y correrá el riesgo de ser rechazado por Gmail, Yahoo y Microsoft Outlook.
Desde Google comenzó a rechazar de forma permanente el correo masivo no conforme a finales de 2025 y Microsoft empezó a devolver errores 550; 5.7.515 a partir de mayo de 2025, la configuración de SPF es un requisito operativo imprescindible.
Esta guía aborda las dos sintaxis válidas para la inclusión de SPF, las decisiones entre el modo en línea y el modo API, la configuración de DKIM, la alineación con DMARC, el límite de 10 consultas, la resolución de problemas y los patrones multitenant para MSP.
Tanto si eres un administrador de TI que implementa Avanan por primera vez, un proveedor de servicios gestionados (MSP) que lo gestiona en decenas de entornos de clientes, o un responsable de seguridad de la información (CISO) que se asegura de que tu sistema de autenticación supere una auditoría, a continuación se abordan todos los casos.
¿Qué es Avanan (ahora Check Point Email Security)?
Check Point Software Technologies adquirió Avanan en agosto de 2021 y le cambió el nombre a Harmony Email & Collaboration. En 2025, Check Point volvió a cambiar el nombre del producto a Check Point Email Security, alineándolo con la estrategia general de la empresa basada en la inteligencia artificial.
A pesar de haber cambiado de marca en dos ocasiones, la mayoría de los administradores de TI, las plataformas de reseñas y los foros de la comunidad siguen utilizando el nombre «Avanan», y Check Point sigue manteniendo un portal con la marca Avanan que ofrece una ruta de migración bajo demanda a la nueva interfaz.
La arquitectura del producto se basa en el enfoque «API-first». Se conecta a Microsoft 365 o Google Workspace a través de una API para analizar el correo electrónico entrante una vez entregado. Cuando los administradores activan el modo en línea (también denominado «Prevent»), Avanan intercepta el correo saliente en el canal de transporte y lo analiza a través de la infraestructura en la nube de Check Point antes de reenviarlo al destinatario.
Esta interceptación en línea es lo que da lugar al requisito del SPF: el correo electrónico saliente se envía ahora desde las direcciones IP de Check Point, que deben estar autorizadas en su registro SPF.
Para obtener más información sobre cómo interactúan las pasarelas de seguridad de correo electrónico con los protocolos de autenticación, consulta SPF, DKIM y DMARC: cómo funcionan conjuntamente.
¿Es necesario cambiar el registro SPF para Avanan?
Si estás ejecutando Avanan en modo «solo API» (Monitor o Detect), no sigas leyendo, ya que no es necesario que modifiques tu registro SPF. El correo seguirá llegando desde las direcciones IP de Microsoft 365 o Google Workspace que ya están autorizadas en tu DNS.
| Modo | Flujo de correo | ¿Cambiar el factor de protección solar? | Repercusiones de DKIM | Alineación DMARC |
|---|---|---|---|---|
| API / Supervisar / Detectar | Remitente → M365/GWS → Bandeja de entrada; Avanan realiza el análisis a través de la API | Ninguna. El correo procede de direcciones IP de M365/GWS que ya figuran en el SPF | Sin cambios | Pases |
| En línea / Prevenir (saliente) | Interno → M365/GWS → Check Point HEC → Externo (dos saltos) | Obligatorio. Añadir la inclusión de Check Point | Se conserva si M365/GWS firma antes de la interceptación | El DKIM suele coincidir; el SPF puede dar un error leve en el campo «Return-Path» |
| MX completo en línea | MX redirige a la nube de Check Point | Obligatorio. Añadir direcciones IP de Check Point | Depende de la configuración de la firma | Comprueba que tanto el SPF como el DKIM estén correctamente configurados |
Avanan SPF Include: ¿Cuál necesitas? (Referencia 2026)
Existen dos métodos válidos para incluir el SPF en Check Point Harmony Email. Son los siguientes:
Inclusión heredada (estática): include:spfa.cpmails.com
Esta es la inclusión SPF original y estática que Check Point introdujo en julio de 2023, en la que se consolidaron las listas de IP anteriores, organizadas por regiones, en una única entrada. Al añadir «include:spfa.cpmails.com» a tu registro SPF, se resuelve en aproximadamente 21 entradas IPv4 que abarcan las regiones de AWS en América del Norte, Europa, Asia-Pacífico, Reino Unido, India, Canadá y Emiratos Árabes Unidos.
Dado que los mecanismos IPv4 no cuentan para el límite de 10 consultas, la propia instrucción «include» consume exactamente una consulta DNS de tu cupo.
Utiliza esta opción si no dispones de licencia para el complemento de gestión de DMARC de Check Point o si prefieres un registro transparente e independiente del proveedor que cualquier auditor pueda consultar directamente en el DNS.
Managed SPF Macro Include: include:{code}.spf.checkpoint-spf.com
Esta es la nueva función de gestión de SPF de Check Point, descrita en la guía de administración de Harmony Email y que se activa desde el portal en DMARC → Gestión de SPF. Utiliza la expansión de macros SPF (según el RFC 7208, apartado 5.7) a través de un código único por cliente. La sintaxis es:
v=spf1 include:{your-org-code}.spf.checkpoint-spf.com include:spf.protection.outlook.com -all
Donde {your-org-code} es un identificador único que se encuentra en el portal de administración de Check Point Email Security. El mecanismo requiere una sola consulta, pero se enruta a través de una zona DNS dinámica y específica para cada cliente que gestiona Check Point. Está diseñado para reducir el espacio que ocupan los registros SPF cuando se utilizan varios servicios de salida de Check Point.
¿Cuál debe utilizar?
| Escenario | Enfoque recomendado | ¿Por qué? |
|---|---|---|
| Tu SPF actual tiene menos de 7 consultas DNS | Inclusión estática (spfa.cpmails.com) | Sencillo, transparente y fácil de auditar |
| Ya llevas entre 8 y 10 consultas DNS | Macro SPF gestionada o aplanamiento de SPF | Debes optimizar las consultas. Las macros están integradas; la simplificación es independiente del proveedor. |
| Como proveedor de servicios gestionados (MSP), gestionas más de 10 dominios de clientes | Unificación de SPF con una herramienta centralizada como PowerSPF | Repetible, independiente del proveedor y auditable para todos los clientes |
| Los auditores deben verificar directamente las direcciones IP autorizadas | Inclusión estática o aplanamiento de SPF | Las macros permanecen ocultas hasta que se resuelven; los auditores no pueden identificar fácilmente las direcciones IP autorizadas |
Importante: No utilices ambas inclusiones simultáneamente. Añadir ambas crea autorizaciones duplicadas, desperdicia consultas DNS y complica las auditorías. Elige un enfoque y aplícalo de forma coherente.
Sugerencia de imagen: Tarjeta comparativa de las dos opciones, con sus ventajas y desventajas.
Texto alternativo: «Comparación entre la inclusión SPF tradicional de Avanan (spfa.cpmails.com) y la inclusión basada en macros (checkpoint-spf.com), en la que se destacan las diferencias en cuanto a transparencia, coste de consulta y auditabilidad».
Cómo añadir el registro SPF de Avanan a tu dominio (paso a paso)
Antes de modificar cualquier registro DNS, empieza por comprobar tu registro SPF actual y el número de consultas. Utiliza un comprobador de SPF gratuito para ver cuántas consultas DNS consume actualmente tu dominio. Si tienes 8 o más, lee la sección de resolución de problemas que aparece a continuación antes de añadir nuevas declaraciones «include».
Paso 1: Confirma tu modo de implementación
Inicie sesión en el portal de administración de Check Point Email Security. Acceda a su política de seguridad de salida. Si está utilizando únicamente el modo API/Monitor, no es necesario realizar cambios en el SPF. Si tiene activado el modo Prevent (en línea) o el análisis de salida de DLP, continúe con el paso 2.
Paso 2: Accede a tu proveedor de DNS
Inicia sesión en la consola de gestión de DNS de tu dominio (GoDaddy, Cloudflare, AWS Route 53, Azure DNS, Namecheap o cualquier otro proveedor que aloje tu dominio). Busca el registro TXT de SPF existente para tu dominio. Empieza por «v=spf1». Si no hay ningún registro SPF, puedes crear uno.
Paso 3: Añade el código de Avanan a tu registro SPF
Incorpora el archivo «include» de Avanan a tu registro actual. No crees un segundo registro TXT SPF. El DNS solo permite uno por dominio. A continuación te mostramos un ejemplo del antes y el después para un entorno de Microsoft 365:
Antes:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com ~all
Después:
v=spf1 include:spf.protection.outlook.com include:_spf.salesforce.com include:spfa.cpmails.com ~all
Paso 4: Validar el registro actualizado
Una vez guardado el cambio en el DNS, espera a que se propague (por lo general, entre 15 minutos y 48 horas, dependiendo de tu configuración de TTL). A continuación, utiliza el verificador SPF de PowerDMARC para verificar que la sintaxis del registro es válida, que el total de consultas DNS no supera las 10 y que no se detecta ningún PermError.
Paso 5: Envía un correo electrónico de prueba y supervisa los informes DMARC
Envía un correo electrónico de prueba desde una cuenta de usuario que se procese a través del modo en línea de Avanan. Comprueba que los encabezados del correo electrónico incluyan «spf=pass» utilizando un analizador de encabezados de correo electrónico. A continuación, supervise sus informes agregados de DMARC durante 48-72 horas para confirmar que ninguna fuente de envío legítima incumple ahora la alineación.
El límite de 10 consultas: por qué la incorporación de Avanan afecta al funcionamiento de tu correo electrónico
El RFC 7208 establece un límite máximo de 10 consultas de mecanismos DNS por cada evaluación SPF. Los mecanismos que consumen consultas son «include», «a», «mx», «ptr», «exists» y «redirect». Cada «include» también activa consultas recursivas para cualquier «include» anidado en su interior. Mecanismos como «ip4», «ip6» y «all» no consumen consultas.
Si se superan las 10 consultas, se produce un PermError, y el servidor de correo receptor debe tratar el SPF como si hubiera fallado por completo, no solo para el correo enrutado por Avanan, sino para todo el correo saliente de su dominio.
Así es como se distribuyen las consultas en una pila empresarial típica: Microsoft 365 consume aproximadamente 3 consultas, Salesforce suma 3, HubSpot suma 2, Mailchimp suma 1, Zendesk suma 2 y Avanan suma 1. El total es de 12 consultas, lo que supone dos por encima del límite. Más información sobre SPF y el límite de consultas.
Ejemplos prácticos de consulta de SPF con Avanan
| Pila de registros SPF | Número aproximado de consultas | Estado | Se requiere actuar |
|---|---|---|---|
| Solo M365 + Avanan | 4–5 | Seguro | Ninguno |
| M365 + Avanan + Salesforce + HubSpot | 9–11 | En el límite | Aplanar o utilizar macros |
| M365 + Avanan + Salesforce + HubSpot + Mailchimp + Zendesk | 14-16 | PermError | Hay que aplanarlo; el SPF falla para TODOS los correos electrónicos |
| Registro simplificado (a través de PowerSPF) | 1–2 | Óptimo | Mantenimiento automático; no requiere intervención manual en el DNS |
| ¿Ya has superado el límite de 10 consultas? PowerDMARC’s PowerSPF de PowerDMARC simplifica automáticamente tu registro SPF y lo mantiene por debajo del límite, incluso cuando añades nuevos servicios como Avanan. Empieza tu prueba gratuita de 15 días |
SPF Macro de Avanan frente a SPF Flattening: comparación
La gestión de SPF a gran escala suele consistir en mantenerse dentro de los límites de consulta sin afectar a las fuentes de envío legítimas. A medida que los registros se vuelven más complejos, se recurre a métodos como el «SPF flattening» y las macros SPF para controlar esa complejidad, aunque resuelven el problema de formas muy diferentes.
Antes de decidir cuál elegir, es importante comprender cómo funciona cada enfoque, qué ventajas e inconvenientes conlleva y cuál es su lugar en entornos de correo electrónico reales.
Cómo funciona la macro SPF de Check Point:
Al activar la gestión de SPF en el portal de administración, se sustituyen tus archivos de inclusión estándar por un único archivo de inclusión basado en macros que resuelve dinámicamente las direcciones IP autorizadas en el momento de la consulta. Check Point se encarga de gestionar la zona DNS. Ya no tendrás que volver a tocar el DNS para la parte de Avanan.
Cómo funciona el alisado SPF:
La simplificación convierte todos los mecanismos de inclusión en direcciones IPv4/IPv6 fijas, lo que reduce las consultas a prácticamente cero. La simplificación manual deja de funcionar cuando los proveedores cambian las direcciones IP. Los servicios automatizados como PowerSPF gestionan automáticamente los cambios continuos de IP, por lo que tu registro sigue siendo válido.
| Factor | Macro SPF de Check Point | Aplanamiento de SPF (p. ej., PowerSPF) |
|---|---|---|
| Número de consultas DNS | Reduce la contribución de Avanan a aproximadamente una consulta | Reduce TODAS las llamadas a «INCLUDE» a aproximadamente una sola consulta |
| Transparencia / Verificabilidad | Sin resolver. Los auditores no pueden ver las direcciones IP autorizadas en el DNS | Totalmente transparente. Todas las direcciones IP se pueden ver directamente en el DNS |
| Dependencia de un proveedor | El SPF depende de la disponibilidad del DNS de checkpoint-spf.com | El SPF depende de la simplificación de la infraestructura del proveedor |
| Alcance | Solo resuelve la parte de Avanan de tu SPF | Resuelve el registro SPF completo. Todos los proveedores |
| Escalabilidad de MSP | Debe configurarse por organización a través del portal de Check Point | Se puede gestionar de forma centralizada en todos los dominios de los clientes desde un único panel de control |
| Portabilidad | Para salir de Avanan es necesario reconfigurar completamente el SPF | Al salir del proveedor de aplanamiento, podrás exportar el registro aplanado |
Cómo afecta el modo en línea de Avanan a la alineación de DKIM y DMARC
Check Point ofrece DKIM gestionado mediante delegación de registros NS, un servicio mediante el cual los administradores delegan subdominios selectores DKIM específicos a Check Point para la gestión y rotación automatizadas de claves.
La firma DKIM nativa en Microsoft 365 o Google Workspace también se conserva en el modo en línea, siempre que la firma se realice antes de que Avanan intercepte el mensaje.
El riesgo real es sutil. El modo en línea de Avanan intercepta los correos electrónicos en el flujo de correo y puede modificar los encabezados, lo que podría invalidar las firmas DKIM que dependen de valores específicos de los encabezados y el cuerpo del mensaje.
A diferencia de las soluciones basadas exclusivamente en API, que analizan el correo electrónico tras su entrega sin intervenir en la cadena de autenticación, el modo en línea redirige activamente el mensaje a través de la infraestructura de Check Point.
La trampa de la alineación DMARC:
DMARC requiere SPF o DKIM para que coincida con el dominio «De». Si el modo en línea interrumpe DKIM, DMARC se basa únicamente en la coincidencia de SPF. Si SPF también está mal configurado (el problema de inclusión descrito anteriormente), DMARC falla por completo.
El peor de los casos: los administradores rebajan la configuración de DMARC de «p=reject» a «p=none» para evitar que se bloqueen los correos electrónicos legítimos, justo lo contrario de lo que debería lograr la implementación de una herramienta de seguridad.
Cómo evitarlo:
Configura SPF correctamente antes de habilitar el modo en línea. Asegúrate de que la firma DKIM se realice a nivel del proveedor de correo electrónico (Microsoft 365 o Google Workspace), y no dentro de Avanan. Verifica la alineación DMARC con un comprobador de DMARC antes y después de la implementación. Solo entonces habilite el escaneo en línea.
Para una supervisión en tiempo real de todas las fuentes de envío, el servicio Hosted DMARC de PowerDMARC detecta los fallos de autenticación en el momento en que se producen.
Orden de implementación: DMARC + Avanan sin comprometer la seguridad
El error más común es activar el modo en línea de Avanan antes de que la infraestructura de autenticación esté lista. En su lugar, sigue estos pasos:
- Evalúa tu estado actual de autenticación. Comprueba el estado de SPF, DKIM y DMARC utilizando una herramienta gratuita de análisis de dominios.
- Soluciona cualquier problema existente con SPF/DKIM. Asegúrate de que el número de consultas de SPF sea inferior a 10 y de que DKIM esté correctamente firmado a nivel del proveedor de correo electrónico.
- Añade la inclusión SPF de Avanan (o activa la macro SPF gestionada). Sigue los pasos indicados en la sección anterior.
- Comprueba que el SPF sea válido. Realiza la prueba con el verificador de SPF y el análisis de encabezados de correo electrónico.
- Activa el modo en línea de Avanan. Solo después de que se hayan validado SPF y DKIM.
- Supervisa los informes DMARC durante 72 horas. Presta atención a cualquier nuevo fallo de alineación de SPF o DKIM.
- Endurezca la política DMARC solo tras una supervisión satisfactoria (si se pasa de p=none a p=quarantine o p=reject).
Solución de problemas relacionados con el SPF y los errores de autenticación de Avanan
Estos son los cinco problemas más habituales tras la implementación, extraídos de la comunidad CheckMates de Check Point, los foros de dmarcian, las opiniones de los usuarios en G2 y Capterra, y los debates entre administradores de TI. Cada uno de ellos tiene una solución concreta.
| Error / Síntoma | Causa más probable | Fijar |
|---|---|---|
| spf=permerror | Más de 10 consultas de DNS tras añadir Avanan, además de M365, Salesforce y otros servicios | Simplifica el SPF con PowerSPF o activa la inclusión basada en macros de Check Point para reducir el número de consultas |
| spf=softfail o spf=fail | Avanan: falta una declaración «include», la declaración «include» es incorrecta o hay un registro TXT de SPF duplicado en el DNS | Comprueba que la declaración «include» se ajuste a lo establecido en la sección 2; asegúrate de que solo exista un registro TXT de SPF por dominio |
| dkim=fail tras habilitar la verificación en línea | Las modificaciones del encabezado en línea de Avanan invalidaron la firma DKIM | Configurar la firma DKIM a nivel de M365/Google Workspace (no en Avanan); verificar la delegación de los nombres de dominio (NS) de DKIM gestionados |
| dmarc=fallo (tanto SPF como DKIM) | El error permanente de SPF y la interrupción de DKIM en el modo en línea provocan un error de doble alineación | Corregir el SPF y el DKIM por separado y, a continuación, volver a comprobar la alineación antes de reactivar la aplicación de las reglas |
| cpmails.com o cloud-sec-av.com aparecen de forma inesperada en los informes DMARC | La salida en línea está habilitada (como era de esperar) o un administrador anterior añadió spfa.cpmails.com y sigue ahí | Comprueba si hay entradas huérfanas en el registro SPF; si se pretende que sea «inline», se trata de un comportamiento normal |
Para realizar un diagnóstico más detallado a nivel de encabezado, pega el encabezado del mensaje rechazado en el Analizador de encabezados de correo electrónico de PowerDMARC para rastrear exactamente dónde falló SPF o DKIM en la cadena de entrega.
Avanan SPF para MSP: gestión de la autenticación multitenant a gran escala
Es aquí donde la brecha operativa es mayor. Treinta o más dominios de clientes, cada uno alojado en un proveedor de DNS diferente, cada uno con una pila de SaaS distinta y cada uno con un número diferente de consultas SPF. Implementar Avanan en todos ellos implica revisar cada registro SPF, verificar cada recuento de consultas y supervisar cada informe DMARC, por cliente y por dominio.
Las tres estrategias específicas para MSP que evitan el caos en la implementación:
- Audita el registro SPF de cada cliente antes de su incorporación: Utilice una herramienta de búsqueda automatizada (no nslookup manual) para comprobar el registro SPF actual de cada dominio, contar las consultas y marcar cualquier dominio que ya haya alcanzado o se acerque al límite de 10 consultas. La API de PowerDMARC admite comprobaciones masivas de dominios en toda su cartera de clientes.
- Estandarizar el uso de un único proveedor de simplificación de registros SPF para todos los clientes: La macro SPF de Check Point debe configurarse por inquilino dentro del portal de Check Point. Una solución centralizada de simplificación de SPF como PowerSPF le permite gestionar los registros de todos los clientes desde un único panel de control, independientemente de la puerta de enlace de seguridad que utilicen.
- Genera informes DMARC de marca blanca para las reuniones trimestrales de resultados (QBR): A los clientes les importan los resultados, no el XML sin procesar. El programa de socios MSP/MSSP de PowerDMARC ofrece paneles de control multitenant, portales de marca blanca y gestión de SPF basada en API para todos los clientes protegidos por Check Point, lo que convierte la supervisión de DMARC en ingresos recurrentes para su negocio.
Mantén limpio tu SPF tras la implementación de Avanan
La configuración del SPF de Avanan no es complicada si se tiene en cuenta el límite de consultas, se elige el método de inclusión adecuado para el modo de implementación y se comprueba la alineación de DKIM y DMARC antes de la puesta en marcha. El verdadero reto no es Avanan en sí mismo, sino que la mayoría de las organizaciones ya se encuentran cerca del límite máximo de consultas SPF antes incluso de incorporar ninguna herramienta nueva.
La configuración del SPF no es algo que se haga una sola vez. Cada nueva herramienta SaaS, plataforma de marketing o servicio de correo electrónico que adopte tu organización supone una nueva consulta. La gestión continua del SPF es la única forma de evitar que se repita el mismo problema con el próximo proveedor que incorpores.
| Toma el control de tu factor de protección solar de forma definitiva. La plataforma de PowerDMARC te ofrece la simplificación automatizada de SPF, la supervisión de DMARC en tiempo real y una visibilidad completa de todos los dominios, por lo que añadir la próxima herramienta nunca volverá a afectar al funcionamiento de tu correo electrónico. |
Preguntas frecuentes
¿Cuál es la versión actual de SPF para 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 es compatible con DKIM?
Sí. Check Point ofrece ahora DKIM gestionado mediante delegación de registros NS, y la firma DKIM nativa de M365/Google Workspace se conserva mediante el modo en línea. Algunas páginas de referencia antiguas de terceros siguen indicando que Avanan no es compatible con DKIM, pero esa información está desactualizada.
¿Cuántas consultas DNS añade la función «Incluir SPF» de Avanan?
La inclusión estática (spfa.cpmails.com) añade exactamente una consulta DNS. Se resuelve en aproximadamente 21 entradas IPv4, que no consumen consultas adicionales. La macro SPF gestionada añade, de igual modo, una consulta.
¿Puedo utilizar a la vez la inclusión estática de Avanan y la inclusión mediante macro?
No. Utilizar ambos da lugar a autorizaciones duplicadas, supone un desperdicio de consultas y complica las auditorías. Elige un enfoque en función de tu entorno y tus licencias.
¿Tengo que cambiar mi SPF si ejecuto Avanan en modo «solo API»?
No. En los modos API, Monitor y Detect, el correo se redirige a través de las direcciones IP de Microsoft 365 o Google Workspace que ya están autorizadas en tu SPF. Solo el modo inline (Prevent) y las implementaciones MX completas requieren la inclusión.
¿Qué es cpmails.com? ¿Qué es checkpoint-spf.com?
cpmails.com es el dominio SPF de Check Point para el flujo de salida estático heredado. checkpoint-spf.com es el dominio basado en macros y específico para cada cliente que utiliza el nuevo complemento de gestión de SPF de Check Point. Ambos forman parte de la infraestructura legítima de Check Point.
¿Debo usar «~all» o «-all» con Avanan?
Check Point recomienda utilizar -all (hardfail) una vez que estés seguro de que se han incluido todos los remitentes legítimos. Utiliza ~all (softfail) durante la implementación inicial por motivos de seguridad. Nunca utilices +all.
- Registro SPF de Avanan: cómo configurar, corregir y optimizar tu SPF para Check Point Harmony Email - 7 de mayo de 2026
- Registro SPF de DNS: cómo funciona y cómo configurarlo - 6 de mayo de 2026
- ¿Qué es v=spf1? ¿Para qué sirve? - 5 de mayo de 2026


