Autenticación del correo de selección: lista de comprobación

Para comprobar la autenticación del correo de selección, envía un mensaje de prueba con datos de un candidato ficticio desde cada servicio que utilices. Revisa los resultados de SPF, DKIM y DMARC en el buzón receptor, comprueba la alineación de dominios y confirma dónde llegan las respuestas. Que el envío se complete no demuestra que el mensaje llegue a la bandeja de entrada, se lea o reciba una respuesta del candidato.

El debate en Hacker News sobre la guía de autenticación de Mailfully vuelve a poner sobre la mesa un problema conocido de configuración. El buzón de tu fundador, el ATS y el servicio de programación de entrevistas pueden mostrar el nombre de tu empresa aunque envíen desde infraestructuras distintas. Que uno funcione dice poco sobre los demás.

Lleva un pequeño registro de las pruebas de cada vía de envío. Así puedes prepararlo sin sustituir registros DNS que funcionan ni atribuir a un indicador verde de configuración más garantías de las que ofrece.

¿Qué servicios envían correo de selección desde tu dominio?

Haz un inventario de los servicios que envían mensajes a candidatos antes de cambiar el DNS. Cada vía de envío necesita su propia prueba, aunque todos los mensajes parezcan salir de [email protected].

Empieza por el buzón habitual de tu reclutador o fundador. Añade después la vía del ATS para los acuses de recibo de candidaturas y las respuestas a candidatos, el servicio que envía las invitaciones a entrevistas y cualquier otro que utilices para ofertas o evaluaciones. Anota quién administra cada servicio y qué dominio debe utilizar.

Esta separación responde al funcionamiento de la autenticación del correo. Los estándares evalúan la infraestructura de envío y las identidades de dominio, que pueden diferir aunque la dirección visible del remitente sea la misma. Es una razón operativa para probar cada vía, no una prueba de que todos los ATS tengan problemas de entrega.

Incluye en el inventario suficientes detalles para detectar una suposición equivocada:

Utiliza datos de candidatos ficticios y buzones que controle tu equipo. Puedes comprobar si la respuesta llega a la candidatura correcta sin contactar con un candidato real ni compartir su conversación con un servicio de diagnóstico.

Separa esta prueba técnica del compromiso con las personas. Nuestro plan de respuesta para contratar en Hacker News explica quién revisa las candidaturas y cuándo reciben noticias los candidatos. La autenticación puede ayudar a ese proceso, pero no puede asignar un evaluador ni hacer que responda.

¿Qué verifican realmente SPF, DKIM y DMARC?

SPF autoriza la infraestructura de envío para una identidad del sobre SMTP. DKIM verifica una firma asociada a un dominio firmante. DMARC comprueba si un resultado válido está alineado con el dominio de la dirección From que ve el destinatario.

Es fácil confundir estas identidades porque tu aplicación de correo suele mostrar una sola dirección. El mensaje contiene varias:

La especificación de SPF distingue la identidad del sobre de la cabecera From visible. La especificación de DKIM describe la firma del dominio. Ni un nombre de remitente conocido ni una dirección Reply-To útil establecen la alineación de DMARC.

Imagina este mensaje directo ficticio:

From: Hiring Team <[email protected]>
Envelope sender: [email protected]
DKIM signing domain: example.com

El resultado de SPF del proveedor podría ser válido para vendor.example.net sin estar alineado con example.com. Una firma DKIM válida para example.com puede aportar el resultado válido y alineado que necesita DMARC. DMARC no exige que ambos mecanismos superen la comprobación y estén alineados; basta con que al menos uno la supere y esté alineado para cumplir su prueba de autenticación. El RFC 9989 explica esta regla.

La alineación también tiene modos. La alineación relajada puede aceptar dominios que compartan un dominio organizativo; la estricta exige una coincidencia exacta. Por tanto, un subdominio de envío no constituye automáticamente un fallo. Anota los dominios y la política reales en lugar de marcar cualquier diferencia como un defecto.

Esto verifica el uso del dominio, no la legitimidad de una oferta de empleo ni las intenciones de quien la envía. Para ese otro problema, consulta nuestro artículo sobre suplantación de reclutadores y confianza de los candidatos.

¿Cómo añades un remitente sin romper el correo existente?

Consigue las instrucciones actuales del nuevo servicio para configurar el dominio y compáralas con los registros ya publicados. Los valores DNS de ejemplo sirven para explicar, no para configurar tu propio dominio.

Primero aclara si vas a configurar la autenticación de salida, el encaminamiento de entrada o ambos. Un registro MX dirige el correo entrante. Cambiarlo puede desviar las respuestas de empleados o candidatos a otro servicio; no autoriza el envío de correo. Si tu dominio principal ya recibe el correo de los empleados en otro proveedor, un subdominio dedicado al correo de selección puede mantener separada esa decisión de encaminamiento.

En SPF, conserva los remitentes legítimos que ya utilizas. Añadir un ATS no debería eliminar sin avisar la autorización que necesita el buzón de tus empleados. Tampoco es seguro publicar una segunda política SPF para evitar editar la primera: la selección de registros SPF devuelve un error permanente cuando encuentra varios registros seleccionables.

SPF también limita los mecanismos y modificadores evaluados que generan consultas DNS. El límite es de diez términos de ese tipo, incluidos los que aportan las inclusiones anidadas. No es un recuento de todas las solicitudes DNS que realiza tu resolutor. Si tu política acumula proveedores, revisa su evaluación en lugar de contar las palabras del registro TXT. Los detalles están en los límites de evaluación del RFC 7208.

En DKIM, publica el selector y la clave o delegación que facilite tu proveedor de envío. Un registro para el selector del buzón de empleados no configura automáticamente el ATS. Anota qué servicio utiliza cada selector para que, al retirar un proveedor más adelante, no elimines la firma que sigue funcionando para otro servicio.

En DMARC, revisa la política existente antes de sustituirla por el ejemplo de un tutorial. Puede que alguien ya recopile informes o aplique una política más estricta. Presenta al responsable del dominio el cambio completo antes de aplicarlo, incluidos los remitentes que se conservarán y el destino previsto para los informes.

¿Cómo pruebas la vía real del correo a candidatos?

Envía desde el flujo real, revisa los resultados del receptor y responde al mensaje. Una prueba desde el buzón de un administrador no comprueba la configuración de salida del ATS.

Para cada fila del inventario, utiliza un asunto reconocible y un buzón que controles en el proveedor receptor que quieras examinar. En el ATS, crea una candidatura ficticia y utiliza la misma acción de respuesta que usaría un reclutador. En el servicio de programación, activa el flujo real de invitación en lugar de reproducir su texto manualmente.

Abre las cabeceras completas o la vista del mensaje original en el correo recibido. Anota el remitente visible, el dominio del sobre que aparece tras la entrega y el dominio firmante de DKIM. Busca después los resultados de autenticación añadidos por el servicio receptor. Utiliza los resultados fiables de ese servicio; una línea que un remitente anterior haya incluido en el mensaje no demuestra lo mismo.

Tu hoja de aceptación puede ser breve:

Incluye la fecha, la configuración de envío, el proveedor receptor y el responsable. Anota por separado si la prueba apareció en la bandeja de entrada o en la carpeta de mensajes basura. Guarda suficientes pruebas para investigar un fallo, sin publicar cabeceras privadas ni contenido de candidatos en una incidencia pública.

Por último, pulsa Responder y envía una respuesta breve. Confirma que llega al buzón o a la conversación del candidato previstos y que la persona adecuada del equipo puede verla. Un servicio de programación puede utilizar deliberadamente otra vía de respuesta; documenta ese comportamiento en lugar de dar por hecho que toda invitación vuelve al ATS.

Una fila aprobada demuestra algo útil sobre ese mensaje, esa vía, esa configuración y ese receptor. Repite la prueba con otro proveedor receptor importante si hace falta. Los mensajes reenviados y las listas de correo introducen otros comportamientos de autenticación. Investígalos por separado antes de interpretar un fallo de SPF como prueba de un remitente no autorizado.

¿Qué exigen Gmail y Yahoo a tu dominio de envío?

Ambos proveedores publican requisitos para los remitentes y obligaciones adicionales para quienes envían correo masivo. Determina a qué proveedor receptor, volumen de envío y propósito del mensaje se aplica cada requisito antes de incorporarlo a tu lista de comprobación.

Las directrices de Google para remitentes se aplican a mensajes enviados a cuentas personales de Gmail. Todos los remitentes necesitan SPF o DKIM, DNS directo e inverso válidos, TLS, un formato conforme a los estándares y pocas denuncias de mensajes basura. Los remitentes de correo masivo necesitan SPF, DKIM, DMARC y alineación, además de los demás requisitos indicados.

Las preguntas frecuentes de Google para remitentes sitúan la clasificación de envío masivo en torno a 5 000 mensajes diarios a cuentas personales de Gmail. Google suma los envíos de los subdominios bajo el dominio principal y señala que esa clasificación se mantiene una vez asignada. Cuenta la actividad de envío pertinente de todo el dominio, no solo los mensajes diarios de tu reclutador. Estas reglas se aplican a destinatarios con cuentas personales de Gmail, no a cuentas receptoras de Google Workspace.

Los requisitos de Yahoo también exigen SPF o DKIM a todos los remitentes, y ambos mecanismos junto con un resultado válido de DMARC a quienes envían correo masivo. Yahoo admite una política mínima de p=none y alineación relajada. Sus preguntas frecuentes no fijan deliberadamente un umbral numérico de envío masivo, por lo que la cifra de Google no es una regla de Yahoo.

Aplica los requisitos de baja a la categoría de mensaje correspondiente. Google excluye los mensajes transaccionales de su requisito de baja con un clic, pero eso no convierte en transaccional cualquier mensaje enviado por un reclutador. Una respuesta a un candidato y un boletín promocional de empleo tienen propósitos distintos. Revisa el mensaje concreto y las directrices del proveedor.

Para los mensajes sujetos al requisito, Gmail exige el mecanismo POST descrito en el RFC 8058; un enlace mailto por sí solo no basta. Yahoo admite actualmente mailto, aunque recomienda POST, y exige facilitar la baja en mensajes de marketing masivo o de suscripción. No deduzcas que las reglas de implementación son idénticas porque ambos proveedores utilicen la expresión «con un clic».

¿Por qué puede acabar en mensajes basura un correo de selección autenticado?

La autenticación es uno de los factores del filtrado. Un receptor puede aceptar un mensaje autenticado y aun así enviarlo a la carpeta de mensajes basura según la reputación, las denuncias, el contenido o las preferencias del destinatario.

Las directrices de Gmail y las orientaciones de Yahoo describen esos otros factores. Ninguna convierte un resultado de autenticación válido en una garantía de llegada a la bandeja de entrada. Si tu prueba supera la autenticación pero acaba en mensajes basura, investiga ese resultado del filtrado en lugar de sustituir una y otra vez registros DNS correctos.

Distingue los fallos según dónde se produzcan:

Antes de observar qué ocurre en el buzón receptor, conviene distinguir otro paso. Una entrega aceptada por SMTP significa que el servidor receptor asume la responsabilidad en ese salto, como describe el RFC 5321. Tu aplicación entrega el correo a su servidor de envío antes de que el destinatario pueda recibirlo en su bandeja de entrada.

Distingue cuatro hechos cuando tu equipo hable del correo: entrega al servidor SMTP, ubicación observada en el buzón receptor, lectura y respuesta. Una marca de tiempo de «enviado» no demuestra los tres últimos. Tampoco la falta de respuesta permite diagnosticar un fallo de autenticación; puede deberse a la decisión del candidato o a tu mensaje.

¿Qué debes comprobar después de cambiar de proveedor?

Repite las filas de aceptación afectadas después de cambiar un remitente, dominio, configuración de firma o integración de programación. Revisa la política y los informes de DMARC con la persona responsable del dominio.

DMARC p=none no expresa ninguna preferencia de cuarentena o rechazo para los mensajes que fallen. Publicarlo no bloquea por sí solo la suplantación ni solicita informes. Para recibir informes agregados, configura por separado un destino que exista, asigna a alguien la tarea de revisarlos y comprueba si hace falta autorización para un destino externo. Las reglas de informes agregados de DMARC explican esa autorización externa.

Antes de pasar a cuarentena o rechazo, identifica los remitentes legítimos e investiga sus fallos. Confirma que el correo de empleados, las respuestas del ATS, la programación de entrevistas y cualquier otro servicio que conserves funcionan con la alineación prevista. Acuerda el cambio de política con el responsable del dominio y comprueba qué ocurre después de aplicarlo. El RFC 9989 define las políticas, aunque los receptores conservan la facultad de decidir cómo tratar los mensajes.

Trata también la retirada de un proveedor como un cambio explícito. Confirma qué autorización SPF y selector DKIM pertenecían al servicio anterior, conserva los demás y decide dónde deben llegar las respuestas antiguas. Un candidato puede responder a una invitación enviada antes de la migración; la nueva prueba de salida no demuestra que siga funcionando esa vía de entrada anterior.

Cómo gestiona Kit tu dominio de selección y las respuestas de candidatos

Un dominio de selección alojado necesita tanto una identidad de envío configurada como una conversación con el candidato que funcione. Comprueba el mensaje recibido aunque la página de configuración indique que todo está correcto.

La configuración de Startupkit Email en Kit muestra los registros MX, DKIM, SPF y DMARC para el dominio configurado. Kit genera un par de claves DKIM específico para el dominio y configura la firma en su servidor de correo. La política DMARC propuesta empieza en p=none.

El correo a candidatos que cumpla los requisitos puede utilizar tu buzón de selección configurado como remitente From visible y remitente del sobre. El envío en nombre de tu dominio exige una integración activa, claves de firma, registros de envío verificados y activación explícita. Las comprobaciones DNS y el estado de aprovisionamiento son distintos: «Activo» significa que el servicio está aprovisionado, no que todos los registros DNS se hayan propagado.

Esas comprobaciones tienen un alcance concreto. Kit comprueba el contenido esperado de la clave, su marcador de autorización SPF y un marcador de versión DMARC. Utiliza un estado de verificación almacenado en caché que actualizan las comprobaciones DNS asíncronas. No es una evaluación completa de la política SPF, un panel de análisis de informes DMARC ni una consulta DNS nueva para cada mensaje.

Kit también registra las respuestas de candidatos en la conversación de selección. Su marca de tiempo de envío correcto se registra después de que la aplicación entregue el mensaje al transporte SMTP; no demuestra la llegada a la bandeja de entrada del destinatario ni la lectura. Tu prueba en el buzón receptor permite comprobar qué ocurre después.

Empieza por una respuesta a un candidato ficticio: envíala desde la vía configurada de Kit, revisa los resultados de autenticación en el mensaje recibido y contesta para que la respuesta vuelva a la candidatura. Completa después las filas del buzón de empleados y del servicio de programación. Si estás evaluando Kit para contratación, es una tarea útil para incluir en tu prueba gratuita, con un responsable que mantenga los resultados al día.