Comprobación de entregabilidad de correo
Antes que la reputación, antes que el contenido, los receptores se hacen una sola pregunta: ¿puede este dominio demostrar que el correo es realmente suyo? Esta comprobación lee la prueba —registros MX, la lista de remitentes SPF (expandida y contada como la cuenta un receptor), la política DMARC en _dmarc y las claves DKIM bajo los selectores habituales— y devuelve hallazgos en lenguaje sencillo, ordenados como los corregiría un operador.
¿Quieres vigilarlo de forma continua? Vigílalo gratis con myeventwatch — alertas de caducidad y caídas, sin tarjeta.
Qué mide la comprobación
El filtrado de spam empieza por la identidad porque la identidad se puede comprobar en milisegundos. Cuando llega un correo que dice ser de un dominio, el servidor receptor consulta las reglas publicadas de ese dominio. SPF nombra los servidores autorizados a enviar. DKIM ofrece una firma para verificarla contra una clave publicada. DMARC exige que el dominio From visible se alinee con una de esas dos pruebas y establece la penalización —ninguna, cuarentena, rechazo— para el correo que no tenga ninguna. La página llama a GET /api/check/email-auth en el servidor de sysosx, que lee los mismos registros a través de los analizadores DNS que usa la comprobación de salud, y los traduce en hallazgos: cada protocolo, cada problema, una gravedad, en el orden en que conviene corregirlos.
Dos de los hallazgos merecen una palabra sobre honestidad, porque ambos son lugares donde los comprobadores suelen fingir precisión. El recuento de consultas SPF es real: el comprobador expande las cadenas de include y redirect término a término con las mismas reglas que aplica un receptor, así que el número que informa es el que calcularía un receptor estricto —incluido cuando el registro se ha desviado en silencio por encima del límite de diez consultas a medida que los proveedores cambiaban sus propios registros—. Y el resultado de DKIM es un sondeo, no un censo: las claves se publican bajo nombres de selector que elige el propietario, la comprobación prueba los habituales, y no encontrar ninguno no demuestra que DKIM esté ausente —una clave bajo cualquier otro selector es invisible desde fuera, y el resultado lo dice claramente en lugar de declarar un dominio sin firma—. La única prueba completa de DKIM sigue siendo un mensaje real y su cabecera Authentication-Results.
Cómo leer un resultado
Empieza por los fallos; son las causas favoritas de la carpeta de spam. Sin MX significa que el dominio no puede recibir correo en absoluto. Sin SPF, o un registro SPF que termina en +all, significa que cualquiera puede decir que es tú —lo segundo es peor, porque la afirmación está oficialmente permitida—. Varios registros SPF anulan en silencio la evaluación de SPF por completo. Un registro DMARC ausente significa que el correo que falla no tiene penalización declarada y, igual de costoso, nadie está recogiendo los informes agregados que muestran quién envía como tu dominio —esos informes son la forma en que suelen descubrirse las campañas de suplantación—. Cuando los informes llegan, lo hacen como XML en bruto; el analizador de informes DMARC abre los archivos .xml, .gz y .zip en local y los convierte en una tabla por origen de quién superó, quién falló y qué corregir. Las advertencias son el estado intermedio: p=none es un buen lugar para empezar DMARC y un mal lugar para quedarse; ~all es modo de prueba, no un destino. Después toma la otra mitad del cuadro: la autenticación demuestra la identidad, mientras que el comprobador de listas negras DNS mide la reputación —ejecuta ambos, porque un dominio perfectamente autenticado en una IP listada sigue cayendo en spam, y una IP limpia con SPF roto también—. La guía que lo une todo es por qué tu correo cae en spam.
Preguntas frecuentes
¿Qué son SPF, DKIM y DMARC, y cómo encajan?
Son tres respuestas publicadas en DNS a la pregunta «¿este correo es realmente del dominio que dice ser?». SPF enumera los servidores autorizados a enviar por un dominio. DKIM permite que un dominio firme criptográficamente los mensajes, para que un receptor pueda verificar la firma contra una clave publicada en DNS. DMARC los une: exige que el dominio remitente de la cabecera From visible se alinee con el resultado de SPF o de DKIM, y dice a los receptores qué hacer —supervisar, poner en cuarentena o rechazar— cuando ninguno se alinea. SPF sin DMARC es una sugerencia sin firmar; DMARC es lo que convierte a los otros dos en una política.
Mi correo sigue cayendo en spam aunque los tres superan. ¿Por qué?
Porque la autenticación es el billete de entrada, no la asignación de asientos. Superar SPF, DKIM y DMARC significa que los receptores creen que el correo es genuinamente tuyo —después de eso, la ubicación depende de la reputación y el contenido: inclusiones en listas negras (compruébalas con el comprobador de listas negras de este sitio), la interacción de los destinatarios, las tasas de quejas, los patrones de volumen de envío y el propio mensaje—. Los fallos de autenticación son la causa reparable más común de la ubicación en spam, por eso esta comprobación va primero, pero un resultado limpio aquí más una ubicación persistente en spam significa que el problema vive en la reputación o el contenido, no en la identidad.
La comprobación dice que no se encontró ninguna clave DKIM. ¿Significa eso que mi dominio no firma?
No —y el resultado lo dice con esas mismas palabras—. Las claves DKIM viven bajo nombres de selector que elige el propietario del dominio, y no hay forma de enumerar los selectores de un dominio desde fuera. Esta comprobación sondea los selectores habituales que usan los grandes proveedores (default, google, selector1, selector2, mail, dkim, s1, s2, k1, mandrill y algunos más). Una clave bajo cualquier otro nombre es invisible para el sondeo. La prueba definitiva es un mensaje real: envía correo a un buzón que controles e inspecciona la cabecera Authentication-Results, que informa del selector usado y de si la firma se verificó.
¿Por qué la comprobación cuenta las consultas SPF, y por qué el límite es 10?
Evaluar un registro SPF puede requerir más consultas DNS —cada término include, a, mx, ptr, exists y redirect cuesta una—. La RFC 7208 limita el total a 10; por encima, los receptores devuelven un error permanente y el resultado SPF queda anulado, lo que puede ser peor que un registro modesto que se evalúa limpiamente. Los registros acumulan consultas en silencio a medida que se añaden proveedores (cada include trae sus propios términos), así que un registro que era legal al configurarse puede desviarse por encima del límite a medida que los proveedores cambian sus registros. Esta comprobación expande el registro como lo haría un receptor e informa del recuento real, para que la desviación sea visible antes de que anule tu autenticación.
¿Qué debo corregir primero si varios hallazgos son fallos?
En orden: varios registros SPF (fusiónalos en uno —todo lo demás es poco fiable hasta que eso esté corregido—), un registro SPF ausente o con +all (publica la lista real de remitentes, terminada en -all), un registro DMARC ausente (empieza en p=none con una dirección de informes, para poder ver quién envía como tú antes de aplicar), y después subir DMARC de p=none hacia p=reject a medida que los informes llegan limpios. Las inclusiones en listas negras, si las hay, son trabajo en paralelo —corrige su causa y solicita la retirada mientras se reparan los registros—. Nuestra guía recorre el orden con el razonamiento: por qué tu correo cae en spam.