Tres controles del dominio ayudan a que otros detecten correos falsos y a que tus mensajes lleguen mejor. Esta guía los explica sin tecnicismos.
El problema: cualquiera puede intentar parecer tu empresa
El nombre visible de un correo se puede copiar con facilidad. Un delincuente puede escribir “Cobranza JN” aunque el mensaje no salió de tu empresa. Por eso los servidores revisan señales técnicas del dominio. SPF, DKIM y DMARC trabajan juntos para responder tres preguntas: ¿este servidor tenía permiso?, ¿el mensaje conserva una firma válida?, ¿qué debe hacer el receptor cuando algo no coincide? No eliminan todo fraude, pero reducen la suplantación directa de tu dominio.
Piensa en un paquete. SPF es la lista de mensajerías autorizadas. DKIM es un sello que permite detectar cambios. DMARC compara el remitente visible con esas pruebas y publica una instrucción. Los tres viven en registros DNS, que son como el directorio público de tu dominio. Un error puede afectar entregas legítimas. Por eso debes configurar con inventario, pruebas y avance gradual, no copiar un texto encontrado en internet.
SPF: la lista de servidores autorizados
SPF permite que el dueño de un dominio publique qué servidores pueden enviar correo en su nombre. La norma técnica vigente para SPF está documentada en RFC 7208. Tu registro puede incluir Microsoft 365, Google Workspace, una plataforma de newsletter, tu sistema de facturación y otros servicios. Solo debe existir un registro SPF por dominio. Si creas varios, la evaluación puede fallar. Consolida todas las autorizaciones en una sola política.
No agregues proveedores por si acaso. Cada autorización amplía quién puede enviar. Primero pregunta qué dominios realmente usan. Revisa también el límite de consultas DNS que establece SPF. Un árbol de includes demasiado grande puede producir un error permanente. Si una aplicación envía desde un subdominio, considera separarla, por ejemplo avisos.tuempresa.mx. Así reduces el impacto cuando un proveedor cambia o necesita una política distinta.
DKIM: una firma que el receptor puede comprobar
DKIM agrega una firma criptográfica al mensaje. El servidor receptor busca una clave pública en DNS y comprueba la firma. RFC 6376 define este mecanismo. La clave privada permanece con tu proveedor de correo. Tú publicas la parte pública mediante un selector. Si usas varias plataformas, cada una puede tener su selector. Activa DKIM en el panel del proveedor y confirma con una prueba real; crear el registro DNS sin activar la firma no basta.
Las claves deben rotarse cuando el proveedor lo recomienda o si existe una sospecha de exposición. No compartas una clave privada por correo o chat. En servicios administrados, normalmente no necesitas verla. El proveedor entrega registros CNAME o TXT y conserva el secreto. Documenta quién puede modificar DNS, qué selector pertenece a cada sistema y cuándo fue probado. Esa lista simplifica una migración futura.
DMARC: alineación, reportes y una regla común
DMARC revisa si el dominio visible en From está alineado con SPF o DKIM. También permite pedir reportes y declarar una política: none para observar, quarantine para tratar el mensaje como sospechoso o reject para rechazarlo. En mayo de 2026, RFC 9989 publicó la especificación actual de DMARC y reemplazó RFC 7489. El cambio confirma que el control sigue vigente, pero no convierte una política estricta en un botón seguro para todos.
Empieza con p=none y una dirección dedicada para reportes agregados. Esa etapa no pide al receptor bloquear mensajes, pero te muestra quién intenta usar tu dominio. Lee los reportes con una herramienta confiable o con apoyo técnico. Identifica remitentes legítimos que todavía fallan. Corrige su SPF, DKIM o alineación. Después aplica una política más fuerte a un porcentaje pequeño y observa resultados antes de avanzar.
Etapa
Objetivo
Señal para avanzar
Inventario
Listar todos los sistemas que envían
Cada área reconoce sus servicios
SPF y DKIM
Autorizar y firmar mensajes reales
Las pruebas pasan en cada proveedor
DMARC p=none
Observar reportes sin pedir bloqueo
Los remitentes legítimos están alineados
Quarantine o reject
Reducir la suplantación directa
No aparecen pérdidas legítimas relevantes
Caso práctico: una distribuidora con cuatro remitentes
Configuración segura en ocho pasos
Lista todas las aplicaciones que envían correos con tu dominio.
Confirma quién administra DNS y crea un respaldo de los registros actuales.
Consolida un solo SPF con únicamente los proveedores necesarios.
Activa DKIM en cada servicio y envía mensajes de prueba.
Publica DMARC con p=none y un buzón para reportes.
Observa fallas, identifica remitentes y corrige alineación.
Prueba quarantine con un porcentaje pequeño y monitorea soporte.
Llega a reject cuando el flujo legítimo permanezca estable.
Prueba hacia cuentas de proveedores distintos. Revisa encabezados para confirmar SPF, DKIM y DMARC. Incluye correos normales, facturas, recuperaciones de contraseña, campañas y respuestas desde soporte. También prueba reenvíos, porque pueden alterar SPF. Una firma DKIM alineada ayuda en esos casos. No uses una herramienta pública como única evidencia. La prueba completa debe recorrer el mismo sistema que utiliza un cliente real.
Checklist de operación y mantenimiento
Existe un solo registro SPF por dominio.
Cada remitente autorizado tiene dueño interno.
DKIM firma mensajes reales de todos los proveedores.
Los selectores y fechas de prueba están documentados.
DMARC recibe reportes en un buzón controlado.
La política avanza después de revisar fallas legítimas.
Bajas de proveedores incluyen retirar sus permisos.
Los cambios DNS tienen respaldo y responsable.
Lo que este escudo no resuelve
Un atacante todavía puede registrar un dominio parecido, comprometer una cuenta real o engañar por teléfono. Complementa la autenticación con doble factor, alertas de acceso, capacitación y un proceso para verificar cambios de cuenta bancaria. SPF, DKIM y DMARC protegen una parte concreta: el uso no autorizado de tu dominio en correo. Bien configurados mejoran confianza y entregabilidad. Mal configurados pueden silenciar mensajes reales. La disciplina de inventariar y probar es tan importante como los registros.
Guía operativa para que una pyme mexicana despliegue y verifique la actualización de Chrome publicada el 6 de agosto de 2026 sin confundir una corrección crítica con evidencia de ataque.
Guía práctica para que una pyme mexicana configure el consentimiento explícito de Google Meet, pruebe clientes y dispositivos, controle archivos y no confunda un botón con toda su obligación de privacidad.
