Desde que Gmail, Yahoo y Microsoft aplican con rigor sus reglas de autenticación, los correos de un dominio mal configurado ya no solo acaban en spam: pueden ser rechazados sin más. La buena noticia es que cPanel reúne ahora SPF, DKIM y DMARC en una sola página. Esta guía le acompaña desde el primer diagnóstico hasta una política DMARC en p=reject, con los informes como respaldo.
Lo que exigen Gmail, Yahoo y Microsoft en 2026
Los tres grandes proveedores de correo distinguen entre las reglas para todos los remitentes y las reservadas a los envíos masivos. Este es el resumen, basado en su documentación oficial vigente en octubre de 2026.
| Requisito | Gmail | Yahoo | Outlook.com / Hotmail |
|---|---|---|---|
| Todos los remitentes | SPF o DKIM, DNS directo e inverso (PTR) válidos, TLS, tasa de spam < 0,3 % | SPF o DKIM, DNS directo e inverso válidos, tasa de spam < 0,3 % | Buenas prácticas recomendadas |
| Umbral de envío masivo | Unos 5000 mensajes al día a cuentas de Gmail | Sin cifra publicada («volumen significativo») | 5000 mensajes o más a los servicios de consumo de Microsoft |
| Envío masivo: autenticación | SPF y DKIM, DMARC como mínimo p=none, alineación del dominio From | SPF y DKIM, DMARC como mínimo p=none, se acepta alineación relajada | SPF y DKIM superados, DMARC publicado y superado |
| Baja | En un clic (cabeceras List-Unsubscribe) y enlace visible | En un clic, aplicada en 2 días | Recomendada |
| Consecuencia | Rechazos temporales o permanentes, o carpeta de spam | Filtrado o rechazo | Rechazo con el error 550 5.7.515 |
Google indica en sus preguntas frecuentes que, a partir de noviembre de 2025, Gmail reforzó la aplicación de estas reglas: los mensajes que no cumplen sufren ahora rechazos temporales y permanentes. Gmail también recomienda una clave DKIM de al menos 1024 bits, idealmente 2048, y una tasa de spam idealmente inferior al 0,1 %.
Por qué también afecta a las webs pequeñas
¿No envía 5000 mensajes al día? Las reglas para todos los remitentes se aplican igualmente, y un dominio sin DMARC es un blanco fácil para la suplantación: cualquiera puede enviar un correo falso en su nombre. Los formularios de contacto de WordPress, las confirmaciones de pedido de PrestaShop y los boletines pasan por los mismos filtros que su correo personal. Configurar los tres registros lleva menos de una hora y le protege a largo plazo.
SPF, DKIM y DMARC: qué hace cada uno
- SPF enumera los servidores autorizados a enviar en nombre de su dominio. Se comprueba sobre la dirección de sobre (Return-Path), no sobre la dirección visible.
- DKIM añade una firma criptográfica a cada mensaje. El destinatario la verifica con la clave pública publicada en su DNS.
- DMARC vincula ambos con la dirección visible (el dominio del campo From). Un mensaje supera DMARC si SPF o DKIM se superan y el dominio verificado coincide con el mostrado: es la alineación. DMARC indica además qué hacer en caso de fallo y adónde enviar los informes.
La trampa más habitual: un SPF válido no basta si el Return-Path pertenece a otro dominio, por ejemplo el de su servicio de boletines. Sin DKIM firmado con su propio dominio, DMARC falla.
Paso 1: hacer un diagnóstico en cPanel
- Inicie sesión en cPanel, abra la sección Correo electrónico y después Email Deliverability (Capacidad de entrega del correo).
- La tabla muestra sus dominios con una columna de estado de entrega. Un dominio con problemas tiene un fallo en DKIM, SPF, DMARC o DNS inverso.
- Haga clic en Manage (Administrar) para ver el detalle: cada registro se compara con el que sugiere cPanel.
El botón Repair (Reparar) corrige automáticamente los registros no válidos tras su confirmación. Solo está disponible si el servidor gestiona la zona DNS del dominio. Si sus servidores de nombres están en otro lugar (en su registrador o en un servicio CDN), copie los registros sugeridos y añádalos allí.
La sección DMARC de esta página está presente en las versiones recientes de cPanel (versión 130 y posteriores). En una versión más antigua, añada el registro DMARC a mano en el Editor de zona.
Paso 2: configurar SPF
En la sección SPF de la página Manage, cPanel propone un registro adaptado a su servidor. Para un dominio que solo envía desde su alojamiento, tiene este aspecto:
tudominio.es. 14400 IN TXT "v=spf1 +a +mx +ip4:203.0.113.10 ~all"
Si también utiliza un servicio externo (herramienta de boletines, suite colaborativa), pulse Customize para añadir el include que le facilite ese servicio y luego Install a Customized SPF Record:
tudominio.es. 14400 IN TXT "v=spf1 +a +mx +ip4:203.0.113.10 include:_spf.servicio-ejemplo.com ~all"
Tres reglas que respetar:
- Un solo registro SPF por dominio. Dos registros
v=spf1invalidan SPF. - Diez consultas DNS como máximo. Cada
include,aomxconsume una; por encima, SPF devuelve un error. - ¿
~allo-all? cPanel propone~all(fallo leve) por defecto. Con DMARC activo, es DMARC quien decide el destino de los mensajes:~allsigue siendo la opción prudente mientras no esté seguro de haber incluido todas sus fuentes.
Paso 3: activar y publicar DKIM
En la sección DKIM, haga clic en Generate Local DKIM Key si no existe ninguna clave. cPanel firmará entonces el correo saliente de su alojamiento con el selector default. El registro público tiene esta forma:
default._domainkey.tudominio.es. 14400 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"
Si su DNS se gestiona en otro lugar, use Copy y pegue el valor en su proveedor DNS (el formato «Split» divide una clave larga en varias cadenas si su interfaz lo exige). No publique nunca la clave privada: cPanel permite mostrarla, pero debe quedarse en el servidor.
Cada servicio externo que envíe en su nombre debe firmar también con su dominio, mediante su propio selector (por ejemplo s1._domainkey). A diferencia de SPF, varios selectores DKIM conviven sin problema.
Paso 4: publicar DMARC en modo observación
Antes de nada, cree en cPanel una dirección de correo reservada para recibir los informes, por ejemplo [email protected]: recibirá varios al día. Después, en la sección DMARC, instale el registro sugerido o ajústelo en el Editor de zona:
_dmarc.tudominio.es. 14400 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"
p=none: ninguna acción sobre los mensajes que fallan, solo observa.rua: la dirección que recibe los informes agregados diarios.adkim=ryaspf=r: alineación relajada, que acepta subdominios (un Return-Path enbounce.tudominio.essigue alineado).
cPanel recuerda que DMARC solo está plenamente activo si SPF y DKIM ya son válidos: complete los pasos 2 y 3 antes de este.
Paso 5: leer los informes DMARC
Los informes agregados llegan como adjunto comprimido (.zip o .gz) que contiene un archivo XML. Cada proveedor (Google, Yahoo, Microsoft…) envía el suyo, normalmente una vez al día. Este es el fragmento que importa:
<record>
<row>
<source_ip>198.51.100.25</source_ip>
<count>137</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>tudominio.es</header_from>
</identifiers>
</record>
Léalo así: 137 mensajes con su dominio salieron de la dirección IP 198.51.100.25. SPF está alineado, DKIM no, así que DMARC se supera gracias a SPF. Para cada IP de origen, hágase tres preguntas:
- ¿Reconozco esta fuente? Su servidor cPanel, su herramienta de boletines, su software de facturación… Si es así, es un envío legítimo que hay que corregir.
- Si es legítima, ¿qué falla? Sin DKIM: active la firma con su dominio en ese servicio. SPF no alineado: añada su
includeo configure un Return-Path en su dominio. - Si es desconocida, ¿es suplantación? Los volúmenes desde IP desconocidas que fallan en SPF y DKIM son justo lo que
p=rejectbloqueará.
Leer XML a mano se vuelve tedioso enseguida: muchos analizadores de informes DMARC, gratuitos o de pago, convierten estos archivos en tablas por fuente. Lo esencial es revisarlos cada semana durante la transición.
Paso 6: pasar de p=none a p=reject sin sobresaltos
Endurecer la política demasiado pronto hace desaparecer sus propios correos legítimos. Avance por etapas:
| Etapa | Registro | Duración aconsejada | Condición para avanzar |
|---|---|---|---|
| 1. Observación | p=none | 2 a 4 semanas | Todas las fuentes legítimas identificadas y alineadas |
| 2. Cuarentena | p=quarantine | 2 a 4 semanas | Sin quejas de correos legítimos en spam, informes estables |
| 3. Rechazo | p=reject | Permanente | Revisión mensual de los informes |
; Etapa 2
_dmarc.tudominio.es. 14400 IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"
; Etapa 3
_dmarc.tudominio.es. 14400 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; adkim=r; aspf=r"
El parámetro sp=reject aplica la misma regla a los subdominios, que los suplantadores aprovechan con gusto cuando quedan desprotegidos. El parámetro pct, antiguo truco para una implantación gradual, ya no figura en la nueva versión del estándar DMARC (RFC 9989, publicada en 2026): confíe en etapas completas y periodos de observación suficientes.
Comprobar con un mensaje real
Envíe un correo desde su buzón de cPanel a una dirección de Gmail, ábralo y elija Mostrar original. Gmail muestra SPF, DKIM y DMARC con PASS o FAIL. En las cabeceras completas, busque la línea Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass [email protected] header.s=default;
spf=pass smtp.mailfrom=tudominio.es;
dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=tudominio.es
Haga la misma prueba desde su web: formulario de contacto, restablecimiento de contraseña, pedido de prueba. Los correos enviados por PHP sin autenticación salen a veces con una dirección de sobre ligada a la cuenta de alojamiento en lugar de a su dominio. Configure su CMS para enviar por SMTP autenticado con una dirección real de su dominio: SPF y DKIM quedarán alineados.
Los errores de rechazo más frecuentes
5.7.26en Gmail: el mensaje no está autenticado (ni SPF ni DKIM válidos y alineados). Vuelva al diagnóstico del paso 1.550 5.7.515en Microsoft: el dominio remitente no alcanza el nivel de autenticación exigido a los envíos masivos. SPF y DKIM deben superarse ambos, y DMARC debe estar publicado y superarse.- DMARC falla aunque SPF pase: el Return-Path pertenece al dominio de un proveedor. Active DKIM con su dominio en ese proveedor.
- DKIM falla tras una migración: la clave se regeneró en el nuevo servidor, pero el valor antiguo sigue publicado en el DNS externo.
- PTR ausente o incoherente: la sección Reverse DNS de la página Manage lo indica. Este registro depende del propietario de la dirección IP, es decir, de su proveedor de alojamiento.
Preguntas frecuentes
¿Basta con DMARC en p=none para Gmail y Outlook?
En sentido estricto, sí: Gmail, Yahoo y Microsoft aceptan p=none como mínimo. Pero esa política no protege su dominio contra la suplantación. Apunte a p=reject cuando sus envíos legítimos estén alineados.
¿Cuánto tardan en aplicarse los cambios?
La página Email Deliverability vuelve a comprobar los registros en pocos minutos tras una reparación. Del lado de los destinatarios, cuente con que expire el TTL de sus registros DNS, normalmente unas horas.
¿Qué hago si no aparece el botón Repair?
Su zona DNS no la gestiona el servidor cPanel. Copie los registros sugeridos y añádalos en el proveedor que gestiona sus servidores de nombres.
¿Necesito un registro DMARC para cada subdominio?
No. El registro del dominio principal se aplica a los subdominios, y el parámetro sp permite darles una política propia.
¿Los informes DMARC contienen el texto de mis correos?
No. Los informes agregados (rua) solo contienen estadísticas: direcciones IP, volúmenes y resultados de SPF, DKIM y DMARC.