Introduce un dominio y un selector DKIM para consultar el registro TXT de clave pública publicado en <selector>._domainkey.<domain> y leer sus etiquetas. Es gratis, funciona al instante en tu navegador sobre DNS-over-HTTPS, sin registro y sin guardar nada.
Crea una cuenta gratuita de Unspam para guardar tus resultados y repetir estas comprobaciones cuando quieras, así detectas una configuración rota antes de que te cueste caro. Sin tarjeta de crédito.
DKIM (DomainKeys Identified Mail) permite que un servidor de envío adjunte una firma criptográfica a cada mensaje. La clave pública correspondiente se publica en DNS como un registro TXT en <selector>._domainkey.<domain>, donde el selector es una etiqueta que elige el remitente para poder usar varias claves a la vez. El servidor receptor lee el selector en la cabecera DKIM-Signature del mensaje, obtiene esa clave pública y verifica la firma para confirmar que el mensaje no se alteró en tránsito y que procede realmente del dominio firmante. Una firma DKIM válida es también una de las formas en que un mensaje puede alinearse con DMARC y superarlo. Proveedores de correo como Gmail y Yahoo esperan que los remitentes masivos se autentiquen con DKIM, así que tener un registro publicado y correcto forma parte de llegar a la bandeja de entrada.
DKIM se publica por selector, no por dominio, así que tienes que indicar uno. Búscalo en un mensaje que hayas recibido del dominio: abre las cabeceras en crudo y lee la etiqueta s= dentro de la línea DKIM-Signature. Si no puedes ver ninguna cabecera, prueba con selectores habituales como google (Google Workspace), selector1 y selector2 (Microsoft 365), k1 (Mailgun), s1 y s2 (SendGrid), k1, k2 y k3 (Mailchimp), default o dkim.
La etiqueta de versión. Debe indicar v=DKIM1 y, cuando aparece, tiene que ser la primera etiqueta del registro. Cualquier otra cosa significa que el registro no es un registro de clave DKIM válido.
El tipo de clave. La mayoría de los registros usan k=rsa; algunas configuraciones modernas usan k=ed25519. Si se omite k=, el valor por defecto es rsa, así que es normal que falte la etiqueta k.
La clave pública codificada en base64. Es el núcleo del registro. Los espacios en blanco dentro de ella son legales, porque el RFC 6376 permite plegar el base64 y quien verifica los elimina antes de decodificar; un carácter que no sea base64 no lo es. El RFC 8301 fija un mínimo de 1024 bits para RSA, y hoy lo recomendado son 2048 bits.
Si el registro existe pero p= está vacía (p=), la clave se ha revocado de forma deliberada según RFC 6376. No es lo mismo que no tener ningún registro: una p= vacía indica a los comprobadores que traten como no válida cualquier firma que use ese selector.
La consulta no devuelve nada porque el selector es incorrecto o la clave nunca se publicó. Confirma el selector exacto en la etiqueta s= de una cabecera DKIM-Signature real y vuelve a comprobarlo. Cada selector es independiente, así que la clave correcta puede estar bajo otro selector.
El registro existe, pero el valor de p= está en blanco, algo que RFC 6376 define como clave revocada. Los servidores receptores darán por no válida cualquier firma realizada con ese selector. Vuelve a publicar el registro con la clave pública actual, o apunta tu plataforma de envío a un selector que aún tenga un valor de p= válido.
El valor de p= se pegó repartido en varias cadenas o tiene espacios y saltos de línea sueltos. Eso es legal: el RFC 6376, sección 3.6.1, permite plegar el base64, y quien verifica elimina los espacios antes de decodificarlo. Lo que sí rompe una clave es un carácter que no es base64, o un valor que tu proveedor de DNS ha recortado sin avisar, y ambos se leen aquí como una clave corrupta y no como una clave ausente. Dividir un registro TXT largo en fragmentos entre comillas tampoco es problema.
Si el registro no empieza por v=DKIM1, los analizadores pueden rechazarlo. Asegúrate de que la etiqueta de versión esté presente y aparezca la primera, con las etiquetas separadas por punto y coma.
Una clave RSA de 1024 bits cumple el mínimo del RFC 8301, pero hoy lo recomendado son 2048 bits, y una etiqueta t=y le dice a quien recibe que trate el correo firmado con esta clave como si no estuviera firmado, no solo que sea indulgente con los fallos, así que DKIM no puede alinear para DMARC mientras esté ahí. Para el correo en producción, usa una clave de 2048 bits y elimina t=y en cuanto hayas confirmado que la firma funciona.
Cuando rotas las claves, el correo que ya va en camino sigue firmado con el selector anterior. Si borras ese registro de inmediato, esos mensajes fallan la verificación, así que mantén publicado el selector antiguo hasta que se vacíe la cola.
Todas las fechas y cifras que Unspam publica sobre los requisitos para remitentes se guardan aquí, contrastadas con la documentación de cada proveedor. Última lectura: 16 de agosto de 2026.
| Proveedor | Qué | Valor | Se aplica a |
|---|---|---|---|
| Reglas para remitentes masivos vigentes desde fuente | febrero de 2024 obligatorio | correo a direcciones personales de Gmail | |
| Endurecimiento de la aplicación desde fuente | noviembre de 2025 observado Google lo describe como gradual y progresivo, no como un interruptor que se activó en una fecha. | correo a direcciones personales de Gmail | |
| Cuenta como remitente masivo a partir de fuente | 5.000 obligatorio Esta es la cifra de Google. Yahoo se niega a publicar ninguna. | correo a direcciones personales de Gmail | |
| Techo de la tasa de quejas de spam fuente | 0,3% obligatorio Google describe el efecto como gradual, no como un corte: por encima de la cifra recomendada la entrada en bandeja ya se resiente, y en el techo se resiente más. | todos los remitentes a Gmail, no solo los masivos | |
| Tasa de quejas de spam recomendada fuente | 0,1% recomendado Postmaster Tools no divide las quejas entre todo lo que enviaste. Las mide sobre los mensajes firmados con DKIM que llegaron a la bandeja de un destinatario activo, así que un remitente ya filtrado puede ver una tasa artificialmente baja. | todos los remitentes a Gmail, no solo los masivos | |
| Yahoo | Reglas para remitentes masivos vigentes desde fuente | febrero de 2024 obligatorio | correo a Yahoo, AOL y los demás buzones de Yahoo |
| Cuenta como remitente masivo a partir de fuente | no publicado Yahoo afirma que no especificará un umbral de volumen, así que no se le puede atribuir ninguna cifra. | correo a Yahoo, AOL y los demás buzones de Yahoo | |
| Techo de la tasa de quejas de spam fuente | 0,3% obligatorio | correo a Yahoo, AOL y los demás buzones de Yahoo | |
| Outlook.com | Reglas para remitentes masivos vigentes desde fuente | mayo de 2025 obligatorio | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 |
| Cuenta como remitente masivo a partir de fuente | 5.000 obligatorio La regla se aplica a cualquier dominio que haya superado el umbral alguna vez, así que sigue aplicándose en un día de menos volumen. | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 | |
| Qué pasa con el correo que falla fuente | 550 5.7.515 observado El correo que no cumple se rechaza durante la conversación SMTP en lugar de archivarse en la carpeta de spam. La página de políticas para postmasters de Microsoft sigue describiendo la carpeta de spam como primer paso, así que un remitente puede ver cualquiera de las dos cosas, pero conviene planificar para el rebote. | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 | |
| SPF y DKIM deben superarse ambos, no solo DMARC fuente | obligatorio Más estricto que DMARC por sí solo. DMARC se supera cuando se alinea SPF o DKIM, y Outlook.com pide además que ambas comprobaciones se superen. | Outlook.com y los demás buzones de consumo de Microsoft, nunca un inquilino de Microsoft 365 | |
| Apple | Reglas para remitentes masivos vigentes desde fuente | febrero de 2025 obligatorio | correo a iCloud Mail, me.com y mac.com |
| Cabeceras ARC en el correo reenviado fuente | obligatorio Apple es el único de los cuatro que lo pide, que es la razón honesta para fijarse en ARC. | correo a iCloud Mail, me.com y mac.com |
Unspam lee todo esto solo a partir de tu nombre de dominio.
Ninguna consulta DNS llega a esto. Requiere un mensaje real o un historial de envíos real, que es para lo que sirve una prueba de entrega en bandeja.
