Identifica todos los servicios emisores
Antes de cambiar DNS, enumera los sistemas que envían utilizando el dominio. Incluye buzones, formulario de contacto, proveedor transaccional, boletines, facturación y soporte. La web y el correo pueden pertenecer a proveedores diferentes. Trasladar la web no traslada necesariamente el sistema que envía o firma los mensajes.
Para cada servicio, anota dominio visible en From, dominio del sobre para devoluciones, dominio de firma DKIM e instrucciones actuales del proveedor. Este inventario evita añadir valores sugeridos sin contexto. Eliminar un include antiguo o sustituir un selector sin comprobar su emisor puede romper mensajes que funcionaban correctamente.
Separa configuración y autenticación
Un comprobador recupera configuración publicada. Puede mostrar SPF, una clave DKIM o una política DMARC en un nombre concreto. Es un paso diagnóstico, pero no demuestra que un mensaje real saliera de la IP correcta, tuviera una firma válida o cumpliera la alineación.
La herramienta de Savvy Toolkit inspecciona los nombres exactos introducidos. No envía correo, no lee buzones, no verifica cuerpos de mensajes, no recorre todas las dependencias SPF ni afirma descubrir políticas DMARC heredadas. Interpreta cada respuesta según ese alcance. Un registro ausente, un aviso de sintaxis y un tiempo de espera DNS son problemas distintos, no tres formas equivalentes de autenticación fallida.
Registros y autenticación del mensaje son distintos
Publica una política SPF en el nombre correcto
SPF declara los sistemas autorizados para enviar con la identidad de sobre correspondiente. El TXT empieza por v=spf1. Dos registros SPF independientes en un nombre provocan un problema; no debes conservar ambos esperando que el receptor elija. Combina únicamente los mecanismos que necesitan los emisores activos, siguiendo las instrucciones de sus proveedores.
Una interfaz DNS puede dividir un TXT largo en varias cadenas entre comillas. Concatenadas forman un registro y no equivalen a dos registros independientes. Comprueba además el nombre consultado: un subdominio de devoluciones puede tener otra política que el dominio visible. Copiar la política principal en un nombre equivocado no corrige esa relación.
Comprende mecanismos y límites SPF
ip4 e ip6 autorizan rangos de direcciones. include consulta otra política y redirect delega la evaluación según sus reglas. No son atajos intercambiables. El mecanismo all y su calificador indican el resultado de emisores que no coincidieron antes; elige su configuración con el inventario completo.
La evaluación tiene límites. SPF permite diez términos que provocan consultas DNS, contando dependencias anidadas. Entre ellos están include, a, mx, ptr, exists y redirect; no se cuentan todos los caracteres ni todos los rangos IP. Contar palabras include visibles no evalúa todo el recorrido. No sustituyas registros gestionados por listas estáticas de IP sin un proceso fiable de actualización.
Encuentra el selector DKIM real
Una firma DKIM indica el dominio con d= y el selector con s=. La clave se publica normalmente en selector._domainkey.dominio-de-firma. El emisor elige el selector y puede cambiarlo durante una rotación. No encontrar default, por ejemplo, no demuestra que el dominio no firme.
Consulta un mensaje legítimo recibido o la pantalla de configuración del proveedor. Utiliza el d= de esa firma, aunque difiera del remitente visible. Algunos proveedores publican un CNAME hacia la clave que gestionan. Guarda el nombre pedido y cualquier alias devuelto para distinguir delegación de datos ausentes al solicitar soporte.
Un error práctico es pegar el nombre DKIM completo donde solo se pide el selector. Para mail2026._domainkey.example.com, el selector es mail2026 y el dominio de firma es example.com. Mantén separados esos valores. Compara también el nombre consultado con el que indica el proveedor antes de editar nada. Una errata en la consulta puede explicar una respuesta ausente sin que exista un problema en la zona DNS ni sea necesario cambiar un servicio que ya funciona.
Una clave pública no verifica el mensaje
El registro DNS publica información para verificar firmas. El sistema emisor debe poseer la clave privada y firmar correctamente las partes pertinentes. Las modificaciones durante el tránsito pueden afectar a la validación. Leer la clave no autentica un cuerpo, asunto o remitente concreto.
Un p= vacío puede revocar una clave DKIM. También puede sustituirse una clave que funcionaba durante la rotación: conserva selectores anteriores durante el solapamiento recomendado, sin borrarlos inmediatamente. Las claves privadas pertenecen al sistema emisor, nunca a un TXT público, formulario de navegador o captura de soporte.
Lee DMARC junto con la alineación
DMARC vincula la autenticación con el dominio visible en From. Un SPF correcto de un dominio de devoluciones ajeno no basta. Una firma DKIM válida de un dominio no relacionado tampoco está automáticamente alineada. Un mensaje puede superar DMARC mediante SPF válido y alineado o DKIM válido y alineado.
none, quarantine y reject describen el tratamiento solicitado para mensajes que no superan DMARC. p=none es una decisión de monitorización y no significa que el correo legítimo falle. Una política más estricta puede perjudicar emisores aún mal configurados. Revisa inventario y mensajes antes de endurecerla. El receptor conserva además decisiones locales de tratamiento.
Utiliza la especificación DMARC actual
RFC 9989 sustituye la descripción central anterior de RFC 7489. El descubrimiento de políticas ahora describe un recorrido DNS acotado, en lugar de depender únicamente de una lista de sufijos públicos. También incorpora t para pruebas y elimina pct del formato central. Receptores y herramientas antiguos pueden seguir interpretando el modelo previo.
No copies un ejemplo antiguo de despliegue gradual sin revisar las instrucciones actuales. Esta herramienta muestra el nombre _dmarc exacto consultado, no todas las políticas heredadas ni una alineación calculada a partir del dominio. Los informes agregados se describen en RFC 9990. Un destino de informes de otro dominio también necesita la autorización correspondiente.
Comprueba DNS y envía correo real
Guarda los valores anteriores y cambia una parte cada vez. Revisa cuenta DNS autoritativa, nombre, tipo y valor antes de guardar. Un campo de host que añade automáticamente la zona puede duplicar el dominio cuando pegas el nombre completo. El panel puede parecer correcto mientras publica en otro nombre.
Después, compara respuestas públicas y considera las cachés según la duración del registro anterior. Envía un mensaje legítimo de cada emisor a una cuenta que controlas. Examina la autenticación del receptor y compara dominio del sobre, d= y s= de DKIM y From visible. Una consulta DNS no reemplaza esta comprobación.
Investiga la entrega sin prometer bandeja de entrada
SPF, DKIM y DMARC forman parte de la entrega, pero no son una puntuación completa de reputación. Los receptores también valoran comportamiento de envío, quejas, formato, TLS, DNS inverso y políticas propias. Lee el código de devolución y los requisitos actuales del receptor antes de atribuir cualquier rechazo a un TXT.
Un informe útil incluye dominio, selector, nombres consultados, registros observados, horas y autenticación redactada de un mensaje controlado. No publiques el buzón completo ni claves privadas. Corrige la discrepancia identificada, vuelve a probar cada emisor y limita la conclusión: esos registros y mensajes funcionaron como se documentó; no garantizan todo el correo futuro.