Empiece por un inventario completo de remitentes
¿Quién puede enviar correos con el dominio de su empresa? Resuelva esta cuestión con contabilidad, ventas e informática. Además de los buzones habituales, pueden intervenir el programa de facturación, una plataforma de boletines, el formulario de contacto, un sistema de incidencias o escáneres. Pregunte qué servicios se utilizan realmente, más allá de las licencias contratadas oficialmente.
Anote para cada servicio su finalidad, la dirección de remitente visible, el proveedor y un responsable del área que lo utiliza. Identifique también quién puede modificar los registros DNS y dónde se documentan los cambios. El inventario servirá para definir el encargo y, posteriormente, para incorporar o retirar servicios.
Incluya los demás dominios de la empresa. Un dominio registrado que nunca deba enviar correo también necesita una configuración contra la suplantación. El NCSC recomienda tener en cuenta todos los dominios de la organización. [5]
Qué comprueba cada mecanismo
SPF comprueba si el servidor emisor está autorizado para el dominio técnico del sobre SMTP. Este puede diferir del dominio del remitente visible. Los servidores permitidos se indican mediante DNS.
DKIM vincula un dominio de firma al mensaje. El destinatario verifica la firma criptográfica mediante una clave pública en DNS. Abarca determinadas partes del mensaje; no cifra el correo ni confirma la identidad de una persona concreta.
DMARC se supera si SPF o DKIM se supera y el dominio autenticado se alinea con el del campo From visible. La alineación estricta exige dominios idénticos; la relajada admite el mismo dominio organizativo. Un resultado SPF o DKIM positivo sin alineación no basta. [1] [2] [3]
Elija la política de forma consciente
p=none no solicita un tratamiento especial ante fallos DMARC. p=quarantine pide tratar el mensaje como sospechoso; p=reject pide rechazarlo. El servicio receptor decide el tratamiento efectivo. Ninguna opción garantiza la entrega del correo legítimo.
Acuerde con informática un periodo de observación y la revisión de los informes solicitados. Debe abarcar las facturas mensuales y los envíos poco frecuentes. Una semana tranquila aportaría poca información sobre esos procesos. Pida que se investiguen los servicios de envío desconocidos antes de autorizarlos o desactivarlos. [4]
Las pruebas que debe entregar el proveedor
Nuestra propuesta de lista de comprobación relaciona la configuración con el trabajo diario. Solicite un registro breve de resultados para cada servicio de envío. Una captura con tres indicadores verdes no demuestra que el programa de facturación o el formulario de contacto envíen correctamente.
- Un inventario actualizado de servicios de envío, dominios y responsables de cada área.
- Un mensaje real de prueba por servicio, con los resultados SPF, DKIM y DMARC registrados en recepción.
- Los dominios comprobados y la evidencia de su alineación, más allá de una simple indicación de aprobado.
- Pruebas específicas para los reenvíos y las listas de distribución necesarios, con los problemas documentados.
- Una política objetivo justificada, una fecha de cambio y un plan concreto de reversión si surgen problemas de entrega.
- Un responsable de los informes, las cuestiones pendientes y las nuevas comprobaciones tras cambiar de proveedor.
Qué ataques siguen siendo posibles
Un dominio parecido al suyo puede superar sus propias comprobaciones SPF, DKIM y DMARC. Un nombre visible conocido tampoco demuestra la identidad. La autenticación no convierte el contenido del mensaje en información fiable.
DMARC tampoco evita que un buzón legítimo sea comprometido. El atacante puede entonces utilizar un servicio de envío autorizado. Compruebe las instrucciones inusuales de pago o de cambio de datos bancarios mediante un canal independiente que ya conozca. [6] [7]
Incluya el mantenimiento en el encargo
Asigne un responsable antes de cerrar el proyecto. Un nuevo programa de marketing, un cambio de proveedor web o la sustitución del sistema contable deben activar una revisión del inventario. Documente qué servicio se ha añadido o retirado, qué se ha probado y qué cuestiones siguen abiertas. Así, la configuración seguirá siendo comprensible cuando cambien los interlocutores.
Lecturas relacionadas
Fuentes y lecturas
- IETF · RFC 7208: Sender Policy Framework (SPF)
- IETF · RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
- IETF · RFC 9989: DMARC, May 2026
- Microsoft Learn · DMARC policy and deployment
- NCSC · Email security and anti-spoofing
- Microsoft Learn · Spoofing and impersonation
- Microsoft Learn · Limits of anti-spoofing protection
Publicado el:
Fuentes primarias verificadas el 29.09.2026.
Las fuentes y los límites se indican en el artículo.
