Cada día, los atacantes envían miles de millones de emails haciéndose pasar por marcas que no son. Facturas falsificadas, restablecimientos de contraseña falsos, solicitudes de CEO fraudulentas — todos funcionan porque, por defecto, cualquiera puede poner cualquier dirección en el campo De de un email. SPF, DKIM y DMARC existen para cerrar ese vacío. Juntos permiten que los proveedores de bandeja de entrada verifiquen que un mensaje realmente proviene del dominio que dice representar, y silenciosamente se han convertido en el precio de entrada a la bandeja: desde febrero de 2024, Gmail y Yahoo exigen autenticación de todo remitente y SPF, DKIM y DMARC completos de los remitentes masivos. Esta guía recorre cómo funciona cada protocolo, los registros DNS exactos que necesitas, los errores que los rompen silenciosamente y un plan de implementación que puedes seguir esta semana.
Punto Clave
SPF, DKIM y DMARC ya no son opcionales. Gmail y Yahoo exigen autenticación a todos los remitentes y aplican SPF, DKIM y DMARC a quien envía 5.000+ mensajes al día. El correo no autenticado se rechaza cada vez más antes de que se evalúe siquiera el contenido — y la autenticación solo rinde al máximo cuando se combina con una lista limpia y validada.
Por Qué Importa la Autenticación de Email
El problema central es que el SMTP, el protocolo que mueve el correo por internet, se diseñó en una era de confianza. No realiza ninguna verificación de identidad sobre la dirección De visible. Ese único hueco de diseño alimenta el phishing y el compromiso de correo corporativo (BEC) a escala industrial: el Internet Crime Complaint Center del FBI atribuyó cerca de 2.900 millones de dólares en pérdidas reportadas por BEC solo en 2023. Cuando los delincuentes suplantan tu dominio, tus clientes son estafados y tu entregabilidad sufre — los proveedores de bandeja de entrada no pueden distinguir tus campañas reales de las falsificaciones.
La autenticación soluciona esto con tres protocolos complementarios basados en DNS:
- SPF declara qué servidores están autorizados a enviar correo en nombre de tu dominio
- DKIM firma criptográficamente cada mensaje para que la manipulación y la falsificación sean detectables
- DMARC conecta ambos con la dirección De visible y dice a los receptores qué hacer cuando las verificaciones fallan
El Mandato de Gmail y Yahoo
En febrero de 2024, Google y Yahoo convirtieron una práctica recomendada de larga data en un requisito estricto. Todos los remitentes deben autenticarse con al menos SPF o DKIM. Los remitentes que superan aproximadamente 5.000 mensajes al día a un proveedor deben tener tanto SPF como DKIM, además de una política DMARC (mínimo p=none), un dominio De alineado con la autenticación, cancelación de suscripción en un clic respetada en un plazo de dos días, y una tasa de quejas de spam por debajo del 0,3%. El correo no conforme primero se ralentiza con errores temporales, y luego se rechaza por completo. Microsoft anunció requisitos equivalentes para remitentes de alto volumen de Outlook.com en 2025, así que la dirección de la industria es inequívoca.
La adopción va en aumento, pero está lejos de ser universal: el análisis de EasyDMARC sobre los 1,8 millones de dominios más importantes del mundo encontró que el 47,7% tenía un registro DMARC en 2025 — y los estudios del sector muestran de forma consistente que una gran parte de los registros publicados sigue en la política de solo monitoreo p=none, sin ofrecer protección real contra el spoofing. Hacerlo bien sigue siendo una ventaja competitiva.
SPF: Sender Policy Framework
Cómo Funciona el SPF
SPF es un registro DNS TXT que lista todos los servidores autorizados a enviar correo en nombre de tu dominio. Cuando un servidor receptor acepta una conexión, examina el dominio del Return-Path (también llamado envelope from o dirección MAIL FROM — no el encabezado De que ven tus destinatarios), obtiene el registro SPF de ese dominio y comprueba si la IP conectada está en la lista. Si lo está, el SPF pasa; si no, el SPF falla o falla parcialmente (soft-fail), según tu política.
Recorrido por la Sintaxis del Registro
Un registro SPF típico para una empresa que usa Google Workspace, una plataforma de marketing y una IP de envío dedicada se ve así:
yourdomain.com. IN TXT "v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:203.0.113.10 ~all"Leyéndolo de izquierda a derecha:
- v=spf1 — la etiqueta de versión; todo registro SPF empieza con ella
- include:_spf.google.com — autoriza a los servidores de envío de Google Workspace haciendo referencia al propio registro SPF de Google
- include:servers.mcsv.net — autoriza a una plataforma de marketing (Mailchimp, en este ejemplo)
- ip4:203.0.113.10 — autoriza una dirección IPv4 específica, por ejemplo tu propio servidor SMTP
- ~all — el catch-all: cualquier servidor no listado debe fallar parcialmente. El calificador importa:
-alles un fallo total (recomendado una vez que tu registro esté completo),~alles un fallo parcial, y+allautoriza a toda internet — nunca lo uses
El Límite de 10 Consultas DNS
La RFC 7208 limita la evaluación de SPF a 10 consultas DNS. Cada mecanismo include, a, mx, ptr y exists cuenta — y los includes cuentan de forma recursiva, así que el include de una sola plataforma de marketing puede consumir tres o cuatro consultas él solo. Si superas el límite, los receptores devuelven permerror, que muchos proveedores tratan como un fallo de SPF. Los mecanismos simples ip4 e ip6 no cuestan nada, así que prefiérelos cuando sea posible, elimina servicios que ya no uses y considera el aplanamiento (flattening) de SPF si de verdad necesitas muchos proveedores.
Errores Comunes de SPF
- Publicar varios registros SPF. Un dominio debe tener exactamente un registro que empiece con
v=spf1. Dos registros producen un error permanente, que hace fallar la validación. Combina todos los mecanismos en un único registro. - Usar +all. Le dice al mundo que cualquier servidor puede enviar como si fuera tú — desactivando el SPF en la práctica y marcando tu dominio como mal configurado.
- Olvidar un servicio de envío. Tu helpdesk, tu sistema de facturación y tu CRM envían correo. Si no están en el registro, sus mensajes fallan parcialmente.
- Dejar que el registro se pudra. Los servicios dados de baja dejan includes colgando que desperdician consultas y pueden crear exposición de seguridad.
- Asumir que el SPF cubre el De visible. Solo verifica el Return-Path. La alineación con el encabezado De es trabajo del DMARC, y por eso el SPF por sí solo detiene muy poco spoofing.
DKIM: DomainKeys Identified Mail
Cómo Funciona la Firma DKIM
DKIM añade una firma criptográfica a cada mensaje saliente. Tu servidor de envío guarda una clave privada y firma un hash del cuerpo del mensaje más ciertos encabezados (De, Asunto, Fecha y otros). La clave pública correspondiente se publica en tu DNS, y el servidor receptor la usa para verificar la firma. Una firma válida demuestra dos cosas: el mensaje fue autorizado por el dominio que lo firmó, y el contenido firmado no fue modificado en tránsito. A diferencia del SPF, una firma DKIM sobrevive al reenvío, lo que la convierte en el mecanismo más resiliente de los dos.
Selectores y el Registro DNS
La clave pública vive en un nombre DNS construido a partir de un selector: selector._domainkey.tudominio.com. Los selectores permiten que coexistan varias claves — una por servicio de envío, o claves antiguas y nuevas durante la rotación. Un registro de clave publicado se ve así:
s1._domainkey.yourdomain.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Zx8...IDAQAB"Y cada mensaje firmado lleva un encabezado que lo referencia:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=s1;
h=from:subject:date:to:mime-version; bh=Kx9c1...; b=HqTf3...
La etiqueta d= nombra el dominio firmante y la etiqueta s= nombra el selector — juntas, le dicen al receptor exactamente dónde buscar la clave pública.
Longitud de Clave y Rotación
- Usa claves RSA de 2048 bits. Las claves de 1024 bits se consideran débiles y algunos proveedores las penalizan; 2048 bits es el estándar actual y lo que recomienda Google.
- Rota las claves regularmente. La mejor práctica de M3AAWG es rotar las claves DKIM al menos cada seis meses. Publica la nueva clave bajo un nuevo selector, cambia la firma y luego retira el registro antiguo tras unos días.
- Firma con tu propio dominio. Muchas plataformas firman con su propio dominio por defecto (lo cual autentica el correo pero no se alinea con tu dirección De). Completa la configuración de DKIM con dominio personalizado de la plataforma para que
d=coincida con tu dominio.
DMARC: Política, Informes y Alineación
SPF y DKIM verifican, cada uno, algo, pero ninguno de los dos comprueba la dirección que tus destinatarios realmente ven. DMARC cierra ese círculo: un mensaje pasa DMARC solo si SPF o DKIM pasan y el dominio que pasó se alinea con el dominio De visible. DMARC también te permite publicar una política que indica a los receptores qué hacer con los fallos, y te da informes para que veas quién está enviando como si fuera tu dominio — de forma legítima o no.
El Registro DMARC y la Progresión de la Política
DMARC es un registro TXT en _dmarc.tudominio.com. Un registro inicial sensato:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r; pct=100"
La etiqueta p= es el corazón del registro, y está diseñada para endurecerse por etapas:
- p=none — solo monitoreo. El correo que falla se entrega con normalidad, pero recibes informes. Todo despliegue empieza aquí.
- p=quarantine — el correo que falla va a spam. Usa
pct=para aumentar gradualmente, por ejemplop=quarantine; pct=25aplica la política a una cuarta parte de los mensajes que fallan. - p=reject — el correo que falla se rechaza por completo. Este es el destino final: protección total contra el spoofing, y un requisito previo para BIMI.
Un registro en aplicación (enforcement) termina viéndose así:
_dmarc.yourdomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]; sp=reject; adkim=s; aspf=s"Informes rua y ruf
La etiqueta rua= solicita informes agregados: resúmenes XML diarios de cada proveedor receptor que muestran qué IPs enviaron como si fueran tu dominio, qué pasó y qué falló. No contienen contenido de los mensajes y son la herramienta principal para descubrir servicios de envío olvidados. La etiqueta ruf= solicita informes de fallos (forenses) — muestras de fallos por mensaje. Pocos proveedores los envían, y pueden contener datos personales, así que la mayoría de los equipos se apoya solo en el rua, procesado mediante una herramienta de informes DMARC en lugar de leerlo en crudo.
Alineación: Relajada vs Estricta
La alineación es donde ocurren la mayoría de los fallos reales de DMARC. Las etiquetas aspf= y adkim= controlan cuán de cerca debe coincidir el dominio autenticado con el dominio De. En modo relajado (r, el predeterminado), una coincidencia de subdominio pasa — el correo de news.tudominio.com se alinea con tudominio.com. En modo estricto (s), los dominios deben coincidir exactamente. Empieza en modo relajado; pasa a estricto solo cuando tus informes muestren que no romperá correo legítimo. Recuerda: la alineación de SPF compara el dominio del Return-Path, la alineación de DKIM compara el dominio d=, y solo uno de los dos necesita pasar con alineación para que DMARC pase.
Los Tres Protocolos de un Vistazo
| Protocolo | Qué demuestra | Registro DNS | Cuándo falla |
|---|---|---|---|
| SPF | El servidor de envío está autorizado para el dominio del Return-Path | TXT en la raíz del dominio, empieza con v=spf1 | IP no listada, más de 10 consultas, reenvío, múltiples registros |
| DKIM | El mensaje fue firmado por el dominio y no fue alterado en tránsito | TXT en selector._domainkey, empieza con v=DKIM1 | Clave ausente o incorrecta, contenido modificado, clave débil o expirada |
| DMARC | El dominio De visible coincide con lo que autenticó SPF o DKIM | TXT en _dmarc, empieza con v=DMARC1 | Ni SPF ni DKIM pasan con alineación al dominio De |
Plan de Implementación Paso a Paso
- Audita cada servicio de envío (semana 1). Haz un inventario de todo lo que envía como si fuera tu dominio: suite de correo, plataforma de marketing, CRM, helpdesk, facturación, alertas de monitoreo. Olvida uno y romperás su correo más adelante.
- Publica o corrige el SPF (semana 1). Un solo registro, todas las fuentes legítimas, menos de 10 consultas, terminando en
~all(endurécelo a-allmás adelante). - Activa DKIM en todas partes (semanas 1-2). Habilita la firma DKIM con dominio personalizado y claves de 2048 bits en cada plataforma de tu inventario, y verifica cada una con un mensaje de prueba.
- Publica DMARC en p=none con informes rua (semana 2). Sin impacto en la entrega — solo estás recopilando datos.
- Monitorea durante 4-6 semanas. Revisa los informes agregados semanalmente. Corrige toda fuente legítima que falle en la alineación; lo que siga fallando es spoofing.
- Endurece gradualmente. Pasa a
p=quarantine; pct=25, incrementa hastapct=100, mantenlo así un par de semanas y luego pasa ap=reject. Sigue monitoreando — seguirán apareciendo nuevas herramientas y proveedores.
Más Allá de DMARC: Una Palabra sobre BIMI
Una vez que alcanzas la aplicación (enforcement), BIMI (Brand Indicators for Message Identification) permite que los proveedores de bandeja de entrada participantes muestren tu logo verificado junto a tus mensajes. Requiere DMARC en p=quarantine o p=reject con pct=100, un logo en SVG y — para la marca de verificación azul de Gmail — un Verified Mark Certificate vinculado a una marca registrada (Google también acepta Common Mark Certificates para mostrar el logo). BIMI no cambia directamente el filtrado, pero la marca de confianza visible ayuda de forma medible al reconocimiento y al engagement, y es una recompensa agradable por completar el recorrido de DMARC.
Autenticación + Validación de Listas: La Stack Completa
Aquí está la parte que muchas guías se saltan: la autenticación demuestra quién eres, no que tu correo es deseado. Los proveedores de bandeja de entrada combinan ambas señales. Un remitente perfectamente autenticado que dispara correo a una lista desactualizada sigue generando rebotes y quejas de spam, y el umbral de quejas del 0,3% del propio Gmail se aplica sin importar tu política DMARC. Las tasas altas de rebote dañan precisamente la reputación del remitente que la autenticación debería proteger.
Por eso la autenticación y la higiene de listas son las dos mitades de una sola estrategia de entregabilidad. AT Valid ejecuta más de 20 verificaciones — sintaxis, MX, SMTP, detección de desechables y catch-all entre ellas — con un 99,5% de precisión, para que cada mensaje que firmas con DKIM tenga de verdad una bandeja de entrada real esperándolo. Valida en el momento de la captura mediante la API, o limpia listas existentes en lote con integraciones nativas para Salesforce, HubSpot, Mailchimp, RD Station, Pipedrive, Zapier y webhooks. Nuestra guía completa de entregabilidad de email explica cómo se refuerzan mutuamente ambas disciplinas.
Ventaja AT Valid
Dominio autenticado más lista validada es la combinación de entregabilidad más fuerte disponible. Crea una cuenta gratuita en AT Valid y obtén 200 créditos gratis para limpiar tu lista mientras llegan tus informes DMARC.
Conclusión
SPF, DKIM y DMARC forman un sistema de identidad por capas: SPF autoriza servidores, DKIM firma contenido, DMARC alinea ambos con la dirección que ven tus destinatarios y aplica el resultado. Desde el mandato de Gmail y Yahoo, son requisitos básicos, no opciones avanzadas — y el camino está bien señalizado: audita tus remitentes, publica el SPF, activa DKIM de 2048 bits, monitorea en p=none y luego endurece hasta p=reject.
Hazlo junto con la validación continua de listas y cubrirás las dos preguntas que se hace un proveedor de bandeja de entrada: ¿es genuino este remitente?, ¿es deseado este correo? ¿Listo para completar tu stack de entregabilidad? Empieza con 200 créditos de validación gratis y comprueba la diferencia que marca un correo autenticado y validado.