Error de DKIM: qué significa cada error y cómo solucionarlo

El protocolo DomainKeys Identified Mail (DKIM) es uno de los pilares fundamentales de la autenticación del correo electrónico. Al adjuntar una firma criptográfica a los mensajes salientes, DKIM permite a los servidores de correo receptores verificar que un correo electrónico ha sido autorizado efectivamente por el propietario del dominio y que su contenido no ha sido alterado durante el tránsito.

Sin embargo, cuando un servidor receptor examina un correo electrónico entrante y encuentra un estado «dkim=fail» en el encabezado, la autenticación falla. Un fallo de DKIM indica a las pasarelas receptoras, como Google Workspace, Microsoft 365 o Apple Mail, que el cuerpo del mensaje se ha modificado tras salir del remitente, que no se ha podido recuperar la clave pública del DNS o que la propia firma criptográfica no es válida.

Dependiendo de la política DMARC de tu dominio y de la configuración de seguridad del destinatario, los errores de DKIM pueden provocar que los correos electrónicos comerciales legítimos acaben en las carpetas de spam o sean rechazados por completo. Esta guía sirve como referencia explícita de mensajes de error para ayudarte a diagnosticar el texto exacto del error en las cabeceras de tus correos electrónicos, identificar la causa raíz y resolver el problema rápidamente.

Razones comunes del fallo de DKIM

Aunque los errores de validación de DKIM se deben, en última instancia, a una discrepancia en el hash o a un fallo en la recuperación de la clave, las causas operativas reales suelen clasificarse en varias categorías predecibles. Si cruzas estas causas subyacentes con el mensaje de error específico que aparece en los encabezados de tu correo electrónico, encontrarás directamente la solución.

1. Modificaciones de los mensajes realizadas por las pasarelas de correo electrónico y los dispositivos de seguridad

La causa más frecuente de fallos en DKIM en entornos corporativos es que un servicio intermedio modifique el contenido del mensaje después de que ya se haya aplicado la firma DKIM. Los dispositivos de seguridad, las pasarelas de salida, los filtros antispam y las herramientas de prevención de pérdida de datos (DLP) suelen alterar los mensajes salientes añadiendo pies de página corporativos, insertando enlaces de seguimiento, recodificando conjuntos de caracteres o modificando los límites MIME. 

Si la firma se realiza en el servidor de correo principal antes de que el mensaje pase por estos dispositivos, el hash del cuerpo del mensaje calculado por el destinatario no coincidirá con la firma original, lo que provocará un error «dkim=fail» (el hash del cuerpo del mensaje no se ha verificado).

2. Listas de correo y reenvío automático de correos electrónicos

Cuando se envía un correo electrónico a una lista de distribución o se reenvía automáticamente a través de agentes de transferencia de correo (MTA) intermedios, el servidor de reenvío suele modificar los encabezados del mensaje (como «Asunto» o «Para») o añadir pies de página de gestión de la lista de distribución (como enlaces para darse de baja o avisos legales de la lista). Dado que la firma criptográfica abarca estos componentes, cualquier cambio posterior a la firma invalida la comprobación de verificación. 

Aunque los protocolos modernos, como Authenticated Received Chain (ARC), ayudan a los reenviadores a mantener el estado de autenticación, las comprobaciones DKIM sin procesar de los mensajes reenviados suelen fallar.

3. Registros TXT de DNS que faltan, están mal configurados o están truncados

Los servidores de correo receptores deben obtener tu clave pública a partir de un registro TXT de DNS específico ubicado en selector._domainkey.tudominio.com. Si este registro de DNS no existe, se ha publicado con un nombre de selector incorrecto o se retrasa debido a la propagación del DNS, el receptor no podrá recuperar la clave, lo que provocará un error «dkim=fail» (no hay clave para la firma).

Además, se produce un problema específico y habitual con las claves RSA de 2048 bits. Según la RFC 1035, una cadena individual dentro de un registro TXT del DNS tiene un límite de 255 bytes. Una clave RSA de 2048 bits codificada en Base64 tiene una longitud aproximada de 392 caracteres. Si tu proveedor de DNS o administrador introduce una clave de 2048 bits como una única cadena sin comillas, es posible que las herramientas de gestión de DNS más antiguas trunquen el contenido de la clave, lo que daría lugar a una clave pública incompleta en el DNS y provocaría un error «dkim=fail» (la firma no se ha verificado).

4. Discrepancias en las claves, rotación de claves sin previo aviso y migraciones de proveedores

Para que la verificación DKIM se realice con éxito, la clave privada que utiliza el servidor de correo remitente para generar la firma debe coincidir matemáticamente con la clave pública publicada en tu DNS. Se produce una discrepancia criptográfica si:

• El servidor de correo de firma genera una nueva clave privada, pero el registro DNS no se actualiza al mismo tiempo.
• Un proveedor de servicios de correo electrónico (ESP) renueva sus claves de firma sin actualizar tu registro TXT publicado ni el destino del CNAME.
• Se migra un dominio a una nueva plataforma de alojamiento, mientras que el servidor de correo electrónico sigue firmando con un selector antiguo o un par de claves retirado.

5. Errores sintácticos en los registros DNS y configuraciones de canonización estricta

Pequeños errores de formato en el registro de la clave pública (como la falta de puntos y comas, espacios sobrantes dentro del contenido de la clave en base64 o nombres de etiquetas incorrectos) hacen que los MTA receptores no puedan analizar la clave pública. 

Del mismo modo, si tu servidor de firma utiliza la canonicización simple para los encabezados o el contenido del cuerpo (c=simple/simple), incluso las conversiones más insignificantes de los finales de línea (CRLF frente a LF) o los ajustes de espacios en blanco al final de las líneas introducidos por los servidores de retransmisión de tránsito impedirán la verificación.

Revisión Sintaxis del registro DKIM.

6. No has configurado DKIM para tus proveedores de correo electrónico externos

Si utilizas varios proveedores de correo electrónico externos para enviar mensajes en nombre de tu organización, debes ponerte en contacto con ellos para que te indiquen cómo activar DKIM para tus mensajes salientes. Si utilizas tus propios dominios personalizados o subdominios registrados en este servicio externo para enviar mensajes a tus clientes, asegúrate de solicitar a tu proveedor que se encargue de la configuración de DKIM por ti.

Lo ideal sería que, si tu proveedor externo te ayuda a externalizar tu gestión del correo electrónico, configurara tu dominio publicando un registro DKIM en su DNS utilizando un selector DKIM que sea exclusivo para ti, sin que tengas que intervenir.

O, 

Puedes generar un par de claves DKIM y facilitar la clave privada a tu proveedor de correo electrónico, al tiempo que publicas la clave pública en tu propio DNS. 

Las configuraciones incorrectas en el mismo pueden provocar un fallo de DKIM, por lo que debe comunicarse abiertamente con su proveedor de servicios en relación con su configuración de DKIM. 

Nota: Algunos servidores de correo de terceros insertan pies de página formateados en el cuerpo del mensaje. Si estos servidores actúan como servidores intermedios en un proceso de reenvío de correo electrónico, el pie de página combinado puede ser un factor que contribuya al fallo de DKIM. 

7. Problemas en la comunicación con el servidor

En determinadas situaciones, es posible que el correo electrónico se envíe desde un servidor en el que DKIM esté desactivado. En tales casos, DKIM dará un error para ese correo electrónico, incluso si el resto de servidores de tu infraestructura están configurados correctamente. Es importante asegurarse de que todas las partes implicadas en la comunicación tengan DKIM correctamente activado. 

8. Interrupción del servicio DNS / Tiempo de inactividad del DNS

Esta es una razón común para los fallos de DKIM. La caída de DNS puede ocurrir debido a una variedad de razones, incluyendo ataques de denegación de servicio. El mantenimiento rutinario de su servidor de nombres también puede ser la razón de una caída de DNS. Durante este periodo de tiempo (normalmente breve), los servidores de destinatarios no pueden realizar consultas DNS. 

Como sabemos que DKIM existe en su DNS como un registro TXT/CNAME, el cliente-servidor realiza una búsqueda para consultar el DNS del remitente para la clave pública durante la autenticación. Durante una interrupción, se considera que esto no es posible y por lo tanto puede romper DKIM. 

9. Uso de OpenDKIM

OpenDKIM es una implementación de DKIM de código abierto que se puede instalar en tu propio servidor de correo para firmar y verificar los correos electrónicos salientes. Cuando se utiliza una configuración de OpenDKIM autohospedada, el servicio suele comunicarse con el servidor de correo a través del puerto 8891.

Para asegurarte de que OpenDKIM funciona correctamente, puedes utilizar una herramienta de comprobación de puertos en línea para verificar que el puerto 8891 está abierto y es accesible en tu servidor. También debes comprobar que los permisos necesarios estén configurados correctamente. Unos permisos incorrectos pueden impedir que OpenDKIM acceda a su socket o se conecte a él correctamente.

Comprueba la configuración del servidor y el directorio que contiene el socket de OpenDKIM para asegurarte de que el directorio existe y tiene los propietarios y permisos adecuados.

10. Comprobación de DKIM para detectar errores de alineación

Si tienes DMARC configurado para su dominio además de DKIM, durante la comprobación DKIM, el valor del dominio en el campo d= de la firma DKIM en el encabezado del correo electrónico debe coincidir con el dominio que se encuentra en la dirección del remitente. Puede ser una coincidencia estricta, en la que los dos dominios deben coincidir exactamente, o una coincidencia flexible, que permite que una coincidencia organizativa supere la comprobación. 

Puede producirse un error de DKIM si el dominio del encabezado de la firma DKIM no coincide con el dominio que figura en el encabezado «De», lo que podría ser un caso típico de suplantación de dominio o un ataque de suplantación de identidad. 

Explicación de los errores de DKIM (por mensaje de error)

Busca a continuación el error concreto que te ha aparecido para saber qué problema ha detectado el servidor receptor y cómo solucionarlo.

dkim=fail (el hash del cuerpo del mensaje no se ha verificado)

El error «dkim=fail» (el hash del cuerpo no se ha verificado) indica que la clave pública se ha recuperado correctamente del DNS y que el encabezado de la firma en su conjunto tiene el formato correcto, pero que el hash criptográfico del cuerpo del mensaje calculado por el destinatario no coincide con el valor del hash almacenado en la etiqueta «bh=» de la firma.

En pocas palabras, el cuerpo del correo electrónico se modificó después de que el servidor de envío lo firmara.

Causas principales:

• Las pasarelas de seguridad de salida, las herramientas de exención de responsabilidad o los complementos de CRM añadían avisos legales, pies de página promocionales o píxeles de seguimiento tras la fase de firma.
• Los relés intermedios modificaban los saltos de línea, los conjuntos de caracteres o los espacios en blanco durante la transmisión.
• El software de reenvío de correo electrónico o de listas de distribución modificó el contenido del mensaje.

Cómo solucionarlo:

1. Reorganiza el flujo de correo saliente de modo que la firma DKIM se realice como último paso antes de que el mensaje salga de tu infraestructura de red, asegurándote de que todos los pies de página y enlaces de seguimiento se apliquen antes de la firma.
2. Asegúrate de que tu servidor de correo utilice la canonicización relajada del cuerpo del mensaje (c=relaxed/relaxed o c=relaxed/simple), que tolera pequeñas variaciones en los espacios en blanco y los finales de línea durante la transmisión.
3. Si utilizas una etiqueta «l=» (longitud) en tus encabezados DKIM, elimínala. La etiqueta «l=» limita la cantidad de texto del cuerpo que se firma y genera vulnerabilidades de seguridad, al tiempo que no resuelve los problemas relacionados con la modificación del cuerpo del mensaje.

dkim=fallo (no hay clave para la firma)

El error «dkim=fail» (no hay clave para la firma) se produce cuando el servidor receptor extrae el dominio (d=) y el selector (s=) del encabezado «DKIM-Signature» del correo electrónico e intenta consultar el DNS en s=._domainkey.d=, pero no consigue recuperar un registro de clave pública válido.

Este error delimita el problema específicamente a la configuración del DNS o a desajustes en los selectores.

Causas principales:

• El nombre del selector especificado por tu aplicación de envío no coincide con el prefijo del selector publicado en el DNS.
• El registro TXT o CNAME nunca se publicó en el servidor DNS de referencia.
• El registro DKIM se publicó hace poco y aún no se ha propagado por completo entre los resolutores DNS de todo el mundo.
• El registro de la clave pública se borró por error durante una migración de dominio o una limpieza de claves.

Cómo solucionarlo:

1. Revisa el encabezado sin procesar del correo electrónico para identificar la cadena de selector exacta en la etiqueta «s=».
2. Comprueba que existe un registro DNS TXT o CNAME en selector._domainkey.tudominio.com (para obtener instrucciones sobre cómo localizar las cadenas de selector, consulta nuestra guía detallada sobre cómo encontrar tu selector DKIM).
3. Comprueba que el registro DNS incluya las etiquetas obligatorias «v=DKIM1;» y «k=rsa;» (o «k=ed25519;»), junto con la carga útil de la clave pública «p=».

dkim=fail (la firma no se ha verificado)

A diferencia de un error de hash del cuerpo del mensaje, el error «dkim=fail» (la firma no se ha verificado) significa que ha fallado la evaluación criptográfica de la cadena de firma principal (la etiqueta «b=»). El destinatario ha obtenido una clave pública del DNS, pero dicha clave no ha podido descifrar ni verificar la carga útil de la firma del encabezado.

Este error indica directamente que el par de claves no es válido o que se han modificado los campos de la cabecera.

Causas principales:

• Discrepancia entre el par de claves: La clave privada utilizada por el servidor remitente para firmar el mensaje no coincide con la clave pública publicada en el DNS bajo ese selector.
• Clave DNS truncada: Se publicó incorrectamente una clave de 2048 bits como una única cadena de más de 255 bytes, lo que provocó que el servidor DNS truncara los datos de la clave pública.
• Modificación de los encabezados: Un servidor de correo intermedio o una pasarela modificó los encabezados incluidos explícitamente en la etiqueta «h=» de la firma (como «From», «To», «Subject» o «Date») después de que se generara la firma.

Cómo solucionarlo:

1. Comprueba si tu registro de clave pública de 2048 bits en el DNS se ha dividido correctamente en varias cadenas entre comillas de menos de 255 bytes cada una.
2. Comprueba que tu clave privada en el servidor de correo se corresponda con la clave pública publicada. Si tienes dudas, genera un nuevo par de claves, actualiza el DNS y comprueba que coincidan.
3. Asegúrate de que los dispositivos de seguridad intermedios no modifiquen los campos de encabezado firmados durante la transmisión.

Error leve de DKIM

En la autenticación del correo electrónico, el «soft fail» no es un estado nativo del protocolo DKIM. Mientras que SPF define explícitamente un resultado «SoftFail» (~all), la RFC 6376 define los resultados de DKIM estrictamente como «pass», «fail», «policy», «neutral», «temperror» o «permerror».

Cuando los administradores o las herramientas de seguridad del correo electrónico informan de un «error leve de DKIM», normalmente se refieren a uno de estos dos casos:

1. Evaluación de DMARC con p=none: Un mensaje no supera la autenticación DKIM, pero, dado que la política DMARC del propietario del dominio está configurada en modo de supervisión (p=none), el proveedor del buzón de correo de destino entrega el correo electrónico en la bandeja de entrada y marca el estado de la evaluación interna como un fallo leve.
2. Clasificación específica de la pasarela: Las pasarelas de seguridad de correo electrónico (como Cisco Secure Email o Mimecast) a veces generan etiquetas de diagnóstico internas como «soft fail» cuando un correo electrónico no supera la verificación DKIM, pero supera la SPF con una alineación DMARC adecuada, lo que significa que se permite la entrega del mensaje en su conjunto.

Si encuentras la etiqueta «soft fail» en los registros, trátala como un error DKIM estándar y comprueba tus encabezados para identificar la cadena de error RFC subyacente (el hash del cuerpo no se ha verificado o no hay clave para la firma).

Otros errores de DKIM que pueden aparecer

Los servidores de correo de recepción también pueden mostrar los siguientes códigos de diagnóstico DKIM estandarizados en sus encabezados «Authentication-Results»:

El DKIM falla, pero el SPF se supera (y otros resultados dispares)

Al revisar los informes de entregabilidad del correo electrónico, es frecuente encontrar casos en los que los resultados de los protocolos entran en conflicto. Comprender cómo evalúan las pasarelas receptoras estas combinaciones es fundamental para la resolución de problemas.

Según las especificaciones de DMARC (RFC 7489), un correo electrónico supera la validación general de DMARC siempre que al menos uno de los protocolos subyacentes (SPF o DKIM) arroje un estado «PASS» y esté correctamente alineado con el dominio que aparece en el encabezado visible «De:».

A continuación se explica cómo se resuelven las combinaciones de protocolos habituales durante la entrega:

¿Por qué se bloquea mi mensaje debido a DKIM?

Si el SPF se supera pero tu mensaje sigue bloqueado o marcado como spam debido a un error de DKIM, puede estar ocurriendo una de estas dos cosas:

1. El SPF no está alineado: La comprobación SPF se ha superado para un dominio de servidor de terceros (por ejemplo, mail.mcsv.net), pero no coincidía con el dominio real del encabezado «From:». Dado que la alineación SPF falló y DKIM falló por completo, DMARC ha fallado.
2. Aplicación estricta por parte de los proveedores: Los principales destinatarios, como Google y Microsoft, aplican políticas de seguridad estrictas a los remitentes masivos. Si un correo electrónico presenta fallos estructurales de autenticación junto con altos indicadores de denuncias por spam, los algoritmos de los destinatarios pueden bloquear el mensaje, independientemente de que haya superado parcialmente las comprobaciones.

Para comprender cómo afecta la aplicación de la política a los correos electrónicos que no cumplen los requisitos, consulta nuestra guía sobre qué es una política DMARC y comprueba tu dominio con nuestro comprobador de registros DMARC.

Cómo interpretar los resultados de DKIM en los encabezados de tus correos electrónicos

Para identificar el mensaje de error concreto, debes consultar los encabezados de Internet sin procesar de un correo electrónico de prueba que se haya entregado.

Paso 1: Accede a los encabezados sin procesar en tu cliente de correo electrónico

• Gmail: Abre el mensaje, haz clic en los tres puntos verticales que hay junto al botón «Responder» y selecciona «Mostrar original».
• Microsoft Outlook (Web): Abre el mensaje, haz clic en los tres puntos de la barra de acciones, selecciona «Ver» y haz clic en «Ver detalles del mensaje».
• Apple Mail: Abre el correo electrónico, haz clic en «Ver» en la barra de menú superior, pasa el cursor por encima de «Mensaje» y selecciona «Código fuente sin formato».

Paso 2: Localiza el encabezado «Authentication-Results»

Desplázate por el texto sin formato del encabezado hasta encontrar el bloque «Authentication-Results». Busca la entrada «dkim=».

Una entrada típica de la cabecera que presenta un error tiene este aspecto:

Resultados de autenticación: mx.google.com;
dkim=fallido (el hash del cuerpo no se ha verificado) [email protected] header.s=s1 header.b=W8xKz2L;
spf=aprobado (google.com: el dominio de [email protected] designa a 192.0.2.1 como remitente autorizado) [email protected];
dmarc=aprobado (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Etiquetas de encabezado clave que hay que revisar:

• dkim=: Muestra el estado de verificación inmediato (aprobado, fallido, error permanente, etc.) seguido de la cadena de error explícita entre paréntesis.
• header.i=: Muestra la identidad o el dominio que ha firmado el correo electrónico.
• header.s=: Identifica el selector exacto utilizado para obtener la clave pública del DNS.
• header.d=: Indica el dominio de la organización que asume la responsabilidad de la firma.

Revisar manualmente las cabeceras sin procesar de los correos electrónicos puede resultar complejo, llevar mucho tiempo y, en general, ser un proceso engorroso. Puedes saltarte estos pasos utilizando nuestra herramienta gratuita analizador de encabezados de correo electrónico para obtener información instantánea y fácil de interpretar sobre los resultados de tus autenticaciones SPF, DKIM y DMARC. 

Cómo solucionar los fallos de DKIM y evitar que vuelvan a producirse

Sigue este proceso sistemático de corrección para resolver los problemas relacionados con DKIM en toda tu infraestructura de envío:

1. Validar la clave pública en el DNS

Utiliza una herramienta de búsqueda en línea como nuestra Búsqueda de registros DKIM para comprobar la clave pública publicada en selector._domainkey.tudominio.com.

• Asegúrate de que no haya errores de sintaxis, errores ortográficos ni dos puntos y coma dobles.
• Comprueba que la división de la clave sea correcta: si utilizas una clave de 2048 bits, asegúrate de que tu editor de DNS haya dividido la carga útil en segmentos de cadena entre comillas de menos de 255 caracteres (por ejemplo, «v=DKIM1; k=rsa; p=part1…» «part2…»). Nunca crees registros TXT separados para el mismo selector.

2. Trasladar la firma DKIM al último salto de salida

Si tu organización redirige el correo electrónico a través de pasarelas de seguridad secundarias, herramientas de exención de responsabilidad o soluciones CRM, asegúrate de que la firma DKIM se realice después de que estas herramientas hayan aplicado sus modificaciones. Si un dispositivo debe modificar el contenido, configúralo para que realice el paso final de la firma DKIM en nombre de tu dominio.

3. Actualizar la configuración de la canonicalización

Cambia la configuración de canonicalización de tu servidor de correo a «relaxed/relaxed» (o «c=relaxed/relaxed» en el encabezado DKIM). Esto indica a los servidores de correo receptores que normalicen los espacios en blanco, los espacios finales y el formato de los campos de encabezado antes de volver a calcular el hash, lo que evita falsos errores de verificación causados por modificaciones menores durante el transporte.

4. Garantizar la alineación de los pares de claves durante las rotaciones

Al rotar las claves DKIM, publica siempre primero la nueva clave pública en el DNS con un nuevo nombre de selector. Espera entre 24 y 48 horas a que se propague el DNS antes de configurar tu servidor de correo para que firme los mensajes con la nueva clave privada. Una vez completada la migración, deja el antiguo registro de la clave pública en el DNS durante varios días para que los mensajes en tránsito o en cola firmados con el antiguo selector puedan seguir verificándose.

Ten en cuenta que hemos abordado algunos mensajes de error habituales relacionados con DKIM y sus posibles causas, al tiempo que hemos ofrecido una posible solución para cada uno de ellos. No obstante, pueden surgir errores debido a diversas razones subyacentes específicas de tu dominio y tus servidores, que no se han tratado en este artículo. 

Debes adquirir los conocimientos necesarios sobre los protocolos de autenticación antes de implementarlos en tu organización o de aplicar tus políticas. Un fallo en DKIM, en SPF o en la validación de DMARC puede afectar a la capacidad de entrega de tu correo electrónico. 

Preguntas frecuentes

¿Qué significa «el hash del cuerpo no se ha verificado»?

«El hash del cuerpo no se ha verificado» significa que se ha encontrado la clave pública en el DNS y que el formato de la cabecera era válido, pero que el contenido del mensaje se modificó después de su firma. Dado que el cuerpo se modificó durante la transmisión (por avisos legales, pasarelas de seguridad, recodificación o reenvío), el hash calculado por el destinatario no coincidió con el hash original registrado en la etiqueta «bh=» de la firma.

¿Cómo puedo solucionar un error de DKIM?

Para solucionar un error de DKIM, localiza la cadena de error exacta en el encabezado «Authentication-Results» de tu correo electrónico. Si el error se debe a la falta de una clave (no hay clave para la firma), publica o corrige el registro TXT de la clave pública en el DNS bajo el selector correcto. Si el error se debe a una discrepancia en el hash del cuerpo del mensaje (el hash del cuerpo no se ha verificado), ajusta el flujo de correo para que la firma DKIM se realice como último paso, una vez añadidos todos los pies de página y enlaces, y configura la canonicización en «relaxed/relaxed».

¿Qué significa una infracción de DKIM?

Una «infracción de DKIM» es un término utilizado por determinadas pasarelas de seguridad de correo electrónico para indicar que un correo electrónico entrante no ha superado las comprobaciones de validación de DKIM. Esto suele significar que la firma criptográfica no era válida, que el mensaje fue manipulado durante el tránsito o que el remitente intentó firmar el correo electrónico utilizando un dominio que no coincide con la dirección de remitente visible.

¿Significa un error de DKIM que mi correo electrónico no se entregará?

No necesariamente. Si tu dominio tiene un registro SPF válido que supera la verificación con una alineación DMARC adecuada, el correo electrónico seguirá superando la verificación DMARC general y llegará a la bandeja de entrada en la mayoría de los casos. Sin embargo, confiar únicamente en el SPF hace que tu capacidad de entrega sea vulnerable cuando se reenvían los correos electrónicos. Además, si el DMARC falla en ambos protocolos y la política de tu dominio está configurada como p=quarantine o p=reject, el correo electrónico que no supere la verificación se enviará a la carpeta de spam o se rechazará por completo.