Cómo configurar SPF, DKIM y DMARC sin romper el correo del sitio

Autentica todos los servicios que envían correo para tu sitio antes de endurecer la política de rechazo del dominio. Eso incluye recibos, restablecimientos de contraseña, respuestas de soporte y cualquier otro sistema legítimo de envío. Un solo remitente olvidado puede hacer que una mejora de seguridad parezca un fallo inexplicable en la entrega de mensajes importantes.

SPF, DKIM y DMARC son controles relacionados, no tres distintivos intercambiables. Aborda primero el trabajo como un ejercicio de inventario y verificación. Copiar un registro de otro sitio es especialmente arriesgado porque tu dominio puede utilizar proveedores distintos, otros subdominios de envío y una ruta diferente para el correo devuelto.

Identifica los remitentes reales antes de editar DNS

Enumera cada tipo de mensaje, el servicio que lo envía, la dirección visible en From y la persona responsable de la cuenta. Envía una prueba autorizada por cada recorrido y conserva sus cabeceras de forma privada. Un mensaje enviado manualmente desde tu buzón no prueba el servicio de recibos o restablecimiento de contraseñas de la aplicación.

SPF autoriza sistemas de envío para el dominio del remitente del sobre utilizado durante la entrega del correo. DKIM añade a un mensaje la firma criptográfica de un dominio. DMARC evalúa después si un dominio autenticado se alinea con el dominio que el destinatario ve en From. Estas distinciones se describen en la especificación de DMARC.

Un sitio hipotético podría enviar respuestas de soporte mediante su proveedor de correo y recibos de compras mediante un servicio comercial separado. Ambos mensajes pueden mostrar la misma marca y seguir rutas técnicas distintas. Verifica las dos en lugar de asumir que las instrucciones DNS del proveedor de correo cubren todo lo que envía la empresa.

Registra los valores DNS actuales y quién puede restaurarlos antes de hacer cambios. Cuando los proveedores requieran registros de verificación, utiliza los valores exactos que suministren para tu dominio. No sobrescribas registros de enrutamiento de correo ajenos al problema al corregir la autenticación saliente; el correo entrante y la autenticación del remitente son asuntos separados.

Añade autenticación sin interrumpir un remitente existente

La especificación de SPF no permite varios registros SPF para el mismo nombre de dominio. Cuando un segundo proveedor necesite autorización, actualiza deliberadamente la política existente en lugar de añadir otro registro v=spf1 independiente. Varios registros TXT no relacionados son normales; el problema son varias políticas SPF que compiten entre sí.

La evaluación de SPF también tiene un límite de 10 mecanismos y modificadores que realizan consultas DNS. Las inclusiones anidadas pueden consumir ese margen, por lo que contar los nombres visibles de proveedores no basta. Pide al administrador de correo que evalúe la política completa en vez de seguir añadiendo inclusiones hasta que el panel de un proveedor se ponga verde.

Para DKIM, sigue las instrucciones de claves y selectores de cada remitente y después verifica un mensaje realmente enviado por ese servicio. Publicar una clave no demuestra por sí solo que el servicio haya empezado a firmar con ella. Mantén privadas las claves privadas; solo el material DNS público indicado por el proveedor debe ir en un registro de configuración compartido.

No elimines un antiguo proveedor de envío hasta comprobar si lo siguen utilizando tareas programadas u otro equipo. Una zona DNS aparentemente limpia puede ocultar una facturación mensual averiada. Retira la autorización solo después de eliminar la dependencia operativa y probar la sustitución.

Utiliza los informes DMARC antes de imponer el rechazo

Empieza observando cuando todavía no conozcas a todos los remitentes legítimos. Una política DMARC p=none no solicita cuarentena ni rechazo basados en DMARC, mientras que los informes pueden ayudar a detectar problemas de autenticación y alineación. Es una fase de seguimiento, no una prueba de que el correo suplantado esté siendo bloqueado.

Para superar DMARC se necesita SPF alineado o DKIM alineado, no simplemente una autenticación correcta de cualquier dominio ajeno. Inspecciona los dominios autenticados en un mensaje de prueba entregado. El nombre de marca visible no constituye la comprobación de alineación, y una entrega satisfactoria en una ocasión no prueba que la política sea correcta.

Asigna a alguien la revisión de los informes agregados y la investigación de fuentes desconocidas antes de modificar la política. Protege el destino de los informes y limita el acceso a los datos operativos. Una dirección de informes que nadie lee añade configuración sin crear un control útil.

Pasa a un tratamiento más estricto solo cuando las rutas legítimas superen las comprobaciones y tengas un plan de reversión documentado. Vuelve a probar después de cambiar un proveedor, un dominio From o la configuración de firma. El objetivo es rechazar la suplantación sin convertir los mensajes normales de clientes en daños colaterales.

Comprueba los requisitos del destinatario y la entrega real

Las directrices de Gmail para remitentes exigen SPF o DKIM a todos los que envían a cuentas personales de Gmail, y SPF, DKIM y DMARC a los remitentes masivos. Google también aborda la alineación, la seguridad del transporte y otras prácticas de entrega. La autenticación es una base necesaria, no una garantía de llegar a la bandeja de entrada.

No apliques a ciegas una regla destinada a promociones masivas a todos los mensajes transaccionales. Identifica la audiencia, la finalidad del mensaje y los requisitos aplicables del destinatario. Mantén los recibos y avisos de cuenta separados del marketing para que la resolución de problemas de entrega no se mezcle con comportamientos promocionales ajenos.

Tras el despliegue, verifica mensajes de cada remitente inventariado e inspecciona los avisos de rechazo. Guarda las marcas de tiempo y los detalles de error, pero evita publicar credenciales o contenido privado de clientes en un gestor público de incidencias. Compara los fallos con el cambio concreto en lugar de editar repetidamente varios registros DNS a la vez.

Añade la revisión de remitentes a tu rutina de mantenimiento web e inclúyela siempre que los cambios de alojamiento o infraestructura afecten al correo. La meta no son tres registros en DNS. Es una lista probada de remitentes legítimos, una política observada y un responsable claro del siguiente cambio.