Supongamos que un proveedor recibe un mail que aparenta venir del gerente financiero de una empresa cliente, informando un cambio de cuenta bancaria para los cobros. El mail viene del dominio correcto (@miempresa.com.ar), con firma, logo y tono habituales. El proveedor actualiza la cuenta y empieza a depositar los siguientes pagos en una cuenta distinta. Semanas después, la empresa descubre que le falta cobrar varios millones de pesos.
Esa estafa se llama BEC (Business Email Compromise) y es una de las más frecuentes en el mundo corporativo hoy. El truco es: el atacante no necesita hackear el correo de la empresa. Le alcanza con falsificar el remitente (envío desde un servidor externo haciéndose pasar por un dominio ajeno). Si el dominio víctima no tiene configurados tres registros DNS específicos, esa falsificación pasa los filtros anti-spam como si fuera legítima.
La solución es técnica, bien conocida y barata: configurar SPF, DKIM y DMARC en el dominio. Lleva unas horas, se paga solo con evitar un incidente, y la mayoría de las PyMEs argentinas todavía no lo tiene.
Qué hacen SPF, DKIM y DMARC
Los tres registros cumplen funciones distintas pero complementarias.
SPF (Sender Policy Framework). Es un registro DNS donde se declara: “los servidores autorizados a enviar mail con este dominio son estos”. Cuando otro servidor de correo recibe un mail que dice venir de @miempresa.com.ar, consulta el SPF y verifica si el servidor de origen está autorizado. Si no lo está, puede marcar el mail como sospechoso o rechazarlo.
DKIM (DomainKeys Identified Mail). Es una firma digital que cada mail enviado lleva en su cabecera, firmada con una clave privada que solo el servidor autorizado tiene. El receptor consulta la clave pública (publicada también en DNS) y verifica la firma. Si es válida, el mail efectivamente salió de un servidor con acceso a la clave privada. Si no, es sospechoso.
DMARC (Domain-based Message Authentication, Reporting and Conformance). Es la política que le dice al receptor qué hacer cuando un mail falla SPF o DKIM: aceptarlo igual, mandarlo a spam, rechazarlo directamente. También habilita reportes automáticos: el receptor envía informes al dominio víctima contándole qué mails dijeron venir del dominio y con qué resultado de validación.
Los tres juntos permiten al dominio víctima: decir quién puede enviar (SPF), demostrar que un mail efectivamente salió de quien dice (DKIM) y decidir qué pasa con los mails falsos (DMARC).
Cómo se configuran
El detalle exacto depende del proveedor de correo y del sistema DNS donde esté registrado el dominio, pero el esquema es siempre similar.
SPF es un registro TXT en el dominio raíz:
“
v=spf1 include:_spf.google.com -all
Ese ejemplo dice: “los mails de miempresa.com.ar solo deben venir de los servidores que Google autoriza (porque usamos Google Workspace); cualquier otro servidor, rechazar (-all)”.
Si se usa Microsoft 365, el include es spf.protection.outlook.com. Si se usa un proveedor de mail como Zoho, MailerLite para marketing, o un servidor propio, hay que incluirlo también.
DKIM se configura generando el par de claves en el proveedor de correo (Google, Microsoft, etc.) y copiando la clave pública al DNS como registro TXT o CNAME. Los proveedores grandes lo guían paso a paso desde su panel.
DMARC es otro registro TXT:
“
v=DMARC1; p=quarantine; rua=mailto:reportes@miempresa.com.ar
El p=quarantine dice “enviar a spam los que fallan SPF/DKIM”; p=reject es más estricto. Se suele arrancar con p=none durante 2-4 semanas (solo para ver reportes sin bloquear nada) y luego pasar a quarantine o reject cuando los números son estables.
Con los tres configurados correctamente, el dominio queda protegido: cualquiera que intente mandar un mail haciéndose pasar por @miempresa.com.ar desde un servidor no autorizado va a ver sus mails rechazados o marcados como spam en la mayoría de los destinatarios.
Los errores más comunes al configurar
Cinco errores aparecen seguido en diagnósticos:
Más de un registro SPF. El RFC dice que debe haber uno solo. Tener dos SPFs genera comportamiento indefinido. Si hay varios proveedores (correo principal + MailerLite + Salesforce, por ejemplo), se combinan todos en un único registro.
SPF con ~all o ?all en lugar de -all. Los primeros dos son “softfail” (marca pero no rechaza). Empezar con ~all durante la fase de prueba está bien; dejar esa configuración permanente no aprovecha la protección.
DKIM sin DMARC. Sin DMARC que defina la política, muchos receptores son laxos con los fallos. Los tres van juntos.
DMARC muy estricto de entrada. Arrancar con p=reject sin haber verificado que todos los servidores legítimos pasen las validaciones puede bloquear mails propios legítimos. Mejor empezar con p=none, ver reportes durante un par de semanas, corregir lo que haga falta y después endurecer.
No procesar los reportes DMARC. Los reportes que llegan al mail configurado en rua= son oro: muestran quién está intentando enviar en nombre del dominio y desde qué IPs. Herramientas gratuitas como Postmark DMARC Digests o dmarcian procesan esos reportes y los vuelven legibles.
Por qué importa más de lo que parece
Más allá del caso BEC (la estafa del “cambio de cuenta”), tener SPF/DKIM/DMARC bien configurados beneficia al dominio de varias formas:
– Entregabilidad mejor. Los mails legítimos llegan a la bandeja de entrada del destinatario, no a spam. Los filtros anti-spam de Gmail, Outlook y Yahoo bonifican los dominios bien configurados.
– Reputación del dominio protegida. Si alguien usa tu dominio para spam, tu reputación cae y tus propios mails empiezan a ir a spam. Con SPF/DKIM/DMARC, los receptores pueden distinguir los mails auténticos de los falsificados.
– Requisito para envíos masivos. Desde 2024, Google y Yahoo exigen DMARC configurado en dominios que envíen más de 5.000 mails por día. Si la empresa tiene un newsletter, está obligado.
– Cumplimiento. Normas como PCI-DSS, ISO 27001 y ciertas regulaciones del rubro financiero recomiendan o exigen estas configuraciones.
Qué hacer hoy
Un plan de 3 horas para una PyME que todavía no tiene esto configurado:
1. Auditar el estado actual del dominio usando herramientas gratuitas: mxtoolbox.com, dmarcian.com, mail-tester.com. Muestran qué hay y qué falta.
2. Configurar SPF para incluir al proveedor de correo actual y cualquier servicio externo que envíe mails en nombre del dominio (MailerLite, Mailchimp, Amazon SES, etc.).
3. Activar DKIM en el proveedor de correo y publicar la clave pública en DNS.
4. Publicar DMARC con p=none y un mail para recibir reportes.
5. Monitorear reportes por 2 semanas y ajustar SPF o DKIM si aparecen envíos legítimos que fallan.
6. Endurecer DMARC a quarantine y luego, si todo va bien, a reject.
Es un proyecto técnico pequeño, con pasos claros, que cualquier proveedor IT serio puede ejecutar en pocas horas de trabajo.
¿Hoy tu dominio puede ser usado por un tercero para enviar mails haciéndose pasar por tu empresa? Si nadie puede responder con certeza, conviene hacer el test en mxtoolbox.com. Tarda dos minutos, es gratuito, y te dice exactamente en qué estás.
