SPF, DKIM y DMARC explicados sin jerga técnica

Si envías correo comercial desde un dominio corporativo y no has tocado nunca estos tres registros, tu entregabilidad tiene un techo bajo aunque el contenido del email sea impecable. SPF, DKIM y DMARC no son opcionales para outreach dirigido: son la base técnica que Gmail, Outlook y el resto de proveedores usan para decidir si confían en tu dominio. Aquí van los tres explicados en orden, sin asumir que ya sabes qué es un registro TXT.

El problema que resuelven: cualquiera puede escribir tu dominio en el remitente

El protocolo de correo original no verifica quién envía en nombre de quién. Cualquier servidor puede poner "ventas@tuempresa.com" en el campo De: de un mensaje, sin permiso ni validación. Esto es lo que hace posible el phishing que suplanta bancos y proveedores, y es exactamente el motivo por el que Gmail, Outlook y Yahoo cada vez exigen más pruebas antes de meter un correo en la bandeja principal.

SPF, DKIM y DMARC son la respuesta de la industria a ese hueco: tres registros publicados en el DNS de tu dominio que le dicen al servidor receptor "así es como reconocer un correo mío de verdad". No son un capricho técnico de departamentos de TI grandes: para un equipo pequeño que manda outreach dirigido a un puñado de decisores por semana, son la diferencia entre llegar a la bandeja de entrada o desaparecer en spam sin que nadie lo note.

Lo importante es que los tres trabajan juntos pero resuelven preguntas distintas: SPF autoriza servidores, DKIM garantiza integridad del contenido, y DMARC une ambos bajo una política y te avisa cuando algo falla. Publicar solo uno deja huecos que un proveedor de correo exigente detecta enseguida.

SPF: la lista de quién puede enviar en tu nombre

SPF (Sender Policy Framework) es un registro TXT en tu DNS que lista qué servidores están autorizados a enviar correo desde tu dominio. Cuando un servidor receptor recibe un mensaje de "@tuempresa.com", consulta ese registro y comprueba si el servidor emisor está en la lista. Si no lo está, el correo queda marcado como sospechoso, aunque el contenido sea legítimo.

Un registro SPF típico se ve así: v=spf1 include:_spf.google.com include:sendgrid.net ~all. Cada include añade un proveedor autorizado — Google Workspace, tu plataforma de envío, tu CRM si manda notificaciones. El ~all final indica qué hacer con lo que no encaja en la lista: un fallo suave que no rechaza directamente pero resta puntos de confianza.

El error más común es tener varios registros SPF en el mismo dominio, uno por cada herramienta que se fue añadiendo con el tiempo sin revisar lo anterior. El estándar solo permite un único registro SPF por dominio; si hay dos, muchos servidores lo consideran inválido por completo y lo ignoran, dejándote sin protección real.

DKIM: la firma que demuestra que nadie tocó el mensaje

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada correo saliente, generada con una clave privada que solo tu servidor de envío conoce. El servidor receptor consulta la clave pública correspondiente, publicada como otro registro TXT en tu DNS, y comprueba que la firma coincide con el contenido recibido. Si algo se alteró por el camino, la firma no valida y el correo pierde confianza.

A diferencia de SPF, que autoriza servidores por IP, DKIM viaja con el propio mensaje: sigue siendo válido aunque el correo se reenvíe a través de otro servidor, algo que SPF no soporta bien. Por eso los dos se consideran complementarios y no intercambiables.

Activar DKIM casi siempre es cuestión de un botón en el panel de tu proveedor de correo o de envío — Google Workspace, Microsoft 365, tu plataforma de outreach — que genera el par de claves y te da el registro TXT exacto para pegar en el DNS. El selector (el nombre que identifica esa clave, tipo google._domainkey) lo define el propio proveedor.

DMARC: la política que une SPF y DKIM y te avisa de lo que pasa

DMARC (Domain-based Message Authentication, Reporting and Conformance) no reemplaza a SPF ni a DKIM: los usa. Le dice al servidor receptor qué hacer cuando un correo que dice venir de tu dominio falla la verificación de SPF y DKIM alineados — es decir, cuando el dominio del remitente visible no coincide con lo que esos registros autorizaron. Las opciones son none (no hacer nada, solo informar), quarantine (mandar a spam) y reject (rechazar directamente).

El campo clave es la alineación: DMARC exige que el dominio verificado por SPF o por DKIM coincida con el dominio que el destinatario ve en el De:. Esto cierra un truco habitual del phishing, donde el correo pasa SPF porque se envía desde un servidor autorizado para otro dominio distinto al que aparece en el remitente visible.

DMARC también genera informes agregados (rua) que muestran, dominio por dominio, cuánto correo se envía en tu nombre y cuánto de eso pasa o falla la verificación — una visibilidad que sin DMARC simplemente no existe. Es habitual descubrir, al activarlo, servicios olvidados que llevan meses enviando correo con tu dominio sin que nadie lo supiera.

Cómo publicarlos paso a paso en tu proveedor de DNS

El proceso es el mismo en Cloudflare, GoDaddy, Namecheap o cualquier panel de DNS: entras en la gestión de registros de tu dominio y añades entradas tipo TXT. Primero SPF, con el valor que te da tu proveedor de correo. Después DKIM, activándolo desde el panel de Google Workspace o Microsoft 365, que te entrega un registro TXT con un selector propio. Por último DMARC, en el subdominio _dmarc.tudominio.com.

Empieza siempre con una política DMARC en modo p=none. Esto activa la recolección de informes sin bloquear ni poner en cuarentena nada, así puedes ver durante dos o tres semanas qué está pasando realmente con tu correo antes de endurecer la política. Pasar directo a p=reject sin esa fase de observación es la forma más común de que un equipo se corte su propio correo legítimo por sorpresa.

• Publica primero SPF con todos los servicios que envían correo en tu nombre (Google Workspace, CRM, plataforma de outreach).
• Activa DKIM en cada servicio de envío por separado — cada uno necesita su propio registro.
• Publica DMARC en modo p=none con una dirección rua para recibir los informes agregados.
• Revisa los informes durante 2-3 semanas antes de subir a p=quarantine.
• Sube a p=reject solo cuando los informes muestren 0% de correo legítimo fallando la alineación.
• Repite la revisión cada vez que contrates una herramienta nueva que envíe correo desde tu dominio.

Errores que conviene revisar antes de escalar una campaña

El error de fondo suele ser el orden: montar la campaña de outreach primero y la autenticación después, cuando lo lógico es lo contrario. Un dominio nuevo o recién comprado, sin historial de envío ni estos tres registros, arranca con la confianza más baja posible ante cualquier proveedor de correo grande, sin importar cuánto haya costado la lista de contactos o cuánto se haya cuidado la redacción.

Otro fallo típico es dejar el registro SPF sin actualizar cuando se cambia de plataforma de envío: el proveedor anterior sigue autorizado y el nuevo no aparece, así que el correo falla la verificación aunque venga de una herramienta legítima. Revisar el SPF cada vez que se añade o se retira un servicio evita este problema por completo.

Antes de escalar el volumen de cualquier campaña dirigida conviene verificar los tres registros con una herramienta de comprobación gratuita, mandar un correo de prueba a una cuenta de control y confirmar que llega a la bandeja principal, no a spam ni a promociones. Esa comprobación de cinco minutos ahorra semanas de entregabilidad dañada.

Preguntas frecuentes