Cómo configurar SPF, DKIM y DMARC desde Panamá, paso a paso.

Guía práctica · Nivel técnico · Última actualización: febrero de 2026

Autenticar el dominio de envío con SPF, DKIM y DMARC dejó de ser una optimización avanzada para volverse un requisito básico. Desde 2024, Gmail y Yahoo exigen estas tres cosas a quienes envían correo en volumen, y un dominio sin autenticar entrega cada vez peor o directamente no llega. Esta guía explica qué es cada uno, cómo configurarlos, cómo verificar que funcionan, y cómo llegar a la protección completa sin romper su correo legítimo en el camino.

Por qué esto dejó de ser opcional

Durante años, la autenticación de correo fue algo que los remitentes serios hacían y el resto ignoraba sin demasiada consecuencia. Eso terminó. En febrero de 2024, Gmail y Yahoo empezaron a exigir autenticación a los remitentes que envían volumen, y Microsoft siguió con requisitos similares en 2025. Hoy, un dominio que envía correo sin SPF, DKIM y DMARC bien configurados entrega a spam, o no entrega, sin importar qué tan legítimo sea su contenido.

Hay dos razones por las que esto importa, y conviene tener ambas claras. La primera es de entregabilidad: sin autenticación, sus correos —incluidos los críticos, como confirmaciones y códigos— tienen muchas más probabilidades de no llegar a la bandeja. La segunda es de seguridad: sin DMARC, su dominio queda expuesto a la suplantación, lo que significa que cualquiera puede enviar correos que parezcan venir de usted, estafando a sus clientes a su nombre. La autenticación protege su entregabilidad y su marca a la vez.

Cubrimos el contexto completo del cambio de 2024 en nuestro artículo sobre los requisitos de Gmail y Yahoo desde Panamá. Esta guía es la parte práctica: cómo configurar efectivamente los tres registros que esos requisitos exigen.

Los tres registros, explicados sin jerga

SPF, DKIM y DMARC trabajan juntos pero hacen cosas distintas. Entender qué hace cada uno antes de configurarlos evita la confusión más común, que es tratarlos como una sola cosa.

SPF (Sender Policy Framework) es una lista de quién tiene permiso para enviar correo en nombre de su dominio. Cuando un servidor de correo recibe un mensaje que dice venir de su dominio, consulta su registro SPF para ver si el servidor que lo envió está autorizado. Es como una lista de invitados: si el remitente no está en la lista, sospecha.

DKIM (DomainKeys Identified Mail) es una firma criptográfica que se agrega a cada correo. Prueba dos cosas: que el correo de verdad salió de su dominio, y que nadie lo alteró en el camino. Es como un sello de cera: si está intacto, el mensaje es auténtico y no fue manipulado.

DMARC (Domain-based Message Authentication) es la política que une a los otros dos. Le dice a los servidores receptores qué hacer cuando un correo falla SPF y DKIM (nada, mandarlo a spam, o rechazarlo), y —esto es clave— le envía reportes de quién está enviando en nombre de su dominio. Es el supervisor que define las consecuencias y le informa de lo que pasa.

El orden importa: SPF y DKIM son los mecanismos de autenticación; DMARC es la política que se apoya en ellos. Por eso se configuran SPF y DKIM primero, y DMARC después, una vez que los dos primeros funcionan.

Paso 0: inventariar quién envía por su dominio

Antes de tocar un solo registro, haga este paso o se va a arrepentir. La causa número uno de correo legítimo que deja de llegar tras configurar autenticación es haber olvidado una fuente de envío. Si endurece DMARC sin haber incluido todas las fuentes legítimas, las que olvidó empiezan a fallar y sus correos no llegan.

Liste todo lo que envía correo en nombre de su dominio. La lista típica de una empresa panameña es más larga de lo que cree:

• El servidor de correo principal (Google Workspace, Microsoft 365, o el que use)
• La plataforma de email marketing (su ESP, sea propio o un Mailchimp)
• La plataforma de correo transaccional, si es distinta
• El sistema de facturación o ERP que manda facturas por correo
• El CRM que envía notificaciones
• El sistema del sitio web que manda formularios de contacto
• Cualquier herramienta de soporte, agendamiento o terceros que envíe a su nombre

Si tiene dudas sobre qué está enviando, el propio DMARC en modo monitoreo (paso 3) se lo va a revelar: los reportes muestran todas las fuentes que envían por su dominio, incluidas las que no sabía. Por eso el orden seguro empieza monitoreando antes de endurecer. Pero arrancar con un inventario propio hace todo más rápido.

Paso 1: publicar el registro SPF

El registro SPF es un registro TXT en el DNS de su dominio que enumera las fuentes autorizadas. Se ve así:

Desglosado: v=spf1 indica que es un registro SPF. Cada include: agrega una fuente autorizada —en el ejemplo, Google Workspace y un ESP— y debe usar el valor exacto que cada proveedor le indica en su documentación. ~all al final (softfail) le dice a los receptores que traten con sospecha lo que no esté en la lista, sin rechazarlo de plano. Una vez con DMARC maduro, se puede pasar a -all (hardfail), más estricto.

La regla más importante del SPF, y el error que más rompe la autenticación: debe haber un solo registro SPF por dominio. Si tiene dos registros TXT que empiezan con v=spf1, ambos fallan y su SPF deja de funcionar. Todas las fuentes deben combinarse en un único registro con varios include:. Cuando agregue una plataforma nueva, no cree otro registro SPF: agregue su include: al existente.

Hay un segundo límite técnico que vale conocer: SPF permite un máximo de diez consultas DNS. Cada include: puede generar varias, y si se pasa de diez, el SPF falla. Empresas con muchas plataformas a veces chocan con esto; la solución es consolidar o usar técnicas de aplanamiento que un técnico puede aplicar. Para la mayoría de los casos panameños, con dos o tres fuentes, no es un problema.

Paso 2: activar DKIM

DKIM no se escribe a mano como SPF: se genera en cada plataforma de envío, que le da un registro para publicar. El proceso es el mismo en todas, aunque la ubicación del botón cambie: en la configuración de la plataforma (Google Workspace, su ESP, etc.) busca la opción de autenticación o DKIM, la activa, y la plataforma le entrega uno o más registros para agregar a su DNS.

El detalle clave del DKIM: cada plataforma que envía por su dominio necesita su propio DKIM. Su servidor de correo principal tiene el suyo, su ESP tiene el suyo, su sistema transaccional el suyo. Cada uno usa un selector distinto (la parte antes de ._domainkey), lo que permite que convivan sin chocar. Activar DKIM solo en una plataforma y olvidar las demás deja a esas otras sin autenticar.

El valor de DKIM, esa clave pública larga, debe copiarse exacto, sin espacios ni saltos de línea que algunos paneles de DNS introducen. Un DKIM mal copiado falla silenciosamente. Tras publicarlo, la mayoría de plataformas tienen un botón de "verificar" que confirma si lo detecta correctamente; úselo antes de dar por hecho que quedó.

Paso 3: publicar DMARC en modo monitoreo

Con SPF y DKIM funcionando, llega DMARC. Y aquí está la decisión más importante de toda la guía: empiece siempre en modo monitoreo, con p=none. Este modo no afecta la entrega de nada; solo observa y le envía reportes. Es lo que le permite descubrir qué fuentes envían por su dominio y si todas pasan autenticación, antes de imponer consecuencias.

Desglosado: p=none es la política en modo monitoreo (no hace nada, solo observa). rua=mailto: es la dirección donde quiere recibir los reportes agregados —use una bandeja que vaya a revisar, o una herramienta que los procese—. fo=1 pide reportes de fallos detallados. Hay más etiquetas opcionales (porcentaje, subdominios, alineación), pero este registro básico es el punto de partida correcto para la mayoría.

Una advertencia importante que conviene subrayar:

Paso 4: leer los reportes y corregir

Con DMARC en p=none, empezará a recibir reportes agregados (los receptores los envían, normalmente a diario). Estos reportes son archivos XML que listan, por cada fuente que envió en nombre de su dominio, cuántos correos mandó y si pasaron SPF y DKIM. En crudo son difíciles de leer; hay herramientas gratuitas y de pago que los convierten en algo legible, y vale usarlas.

Lo que busca en los reportes es simple: que todas sus fuentes legítimas estén pasando autenticación, y detectar fuentes que no reconoce. Va a encontrar tres situaciones. Fuentes legítimas que pasan: perfecto, esas ya están bien. Fuentes legítimas que fallan: hay que arreglarlas, casi siempre activando su DKIM o agregándolas al SPF, porque las olvidó en el inventario. Y fuentes que no reconoce: pueden ser un servicio legítimo que no sabía que enviaba, o —importante— intentos de suplantación de su dominio, que es justamente lo que DMARC ayuda a detectar.

Quédese en p=none el tiempo necesario para que todas las fuentes legítimas pasen y usted entienda quién envía por su dominio. Para una empresa simple pueden ser una o dos semanas; para una con muchas fuentes, más. No hay prisa: el modo monitoreo no le hace daño a nada, y apurarse a endurecer antes de tiempo es justamente lo que causa los problemas. Endurezca solo cuando los reportes estén limpios.

Paso 5: endurecer la política gradualmente

Cuando los reportes confirman que todas sus fuentes legítimas pasan autenticación, llega el momento de endurecer, y se hace por escalones, no de golpe. El camino es p=none → p=quarantine → p=reject.

El primer paso es a p=quarantine, que envía a la carpeta de spam los correos que fallan autenticación. Es el primer nivel de protección real: lo que se hace pasar por su dominio sin autenticar termina en spam, no en la bandeja. Puede combinarse con el parámetro de porcentaje (pct=) para aplicarlo gradualmente solo a una fracción del tráfico al inicio, aunque para la mayoría de los casos, si los reportes ya están limpios, el salto directo funciona bien. Observe los reportes una o dos semanas más en quarantine.

El paso final es a p=reject, que rechaza por completo los correos que fallan autenticación. Es la protección máxima: nadie puede entregar correo a nombre de su dominio sin estar autenticado. Es el objetivo al que conviene llegar, porque es lo que de verdad protege su marca contra la suplantación, y lo que los proveedores de correo más valoran de un remitente. Pero se llega aquí solo después de haber confirmado, en quarantine y con reportes limpios, que nada legítimo se rompe.

Llegar a p=reject es la meta, pero no hay que apurarse a llegar. Un dominio en p=quarantine con reportes limpios ya está mucho mejor protegido que el noventa por ciento de los dominios panameños, que siguen en p=none o sin DMARC. Avance al ritmo que le permita verificar cada paso.

Cómo verificar que todo quedó bien

Después de cada cambio, verifique antes de seguir. No confíe en que "lo publiqué, así que funciona": confírmelo. Hay varias formas.

• Herramientas en línea de verificación de SPF, DKIM y DMARC que consultan su dominio y le dicen si los registros están bien formados y son visibles.
• Enviar un correo de prueba a una cuenta de Gmail, abrir el mensaje, ver el origen o los detalles, y confirmar que SPF, DKIM y DMARC aparecen como "pass".
• Las herramientas de Postmaster de Google, que muestran cómo ve Google la autenticación y la reputación de su dominio en el tiempo.
• Los propios reportes DMARC, que son la confirmación continua de que todo sigue pasando.

La verificación no es un paso de una sola vez: la autenticación puede romperse después si alguien cambia un registro, si agrega una plataforma nueva sin incluirla, o si una clave expira. Por eso DMARC con reportes es valioso de forma permanente: es el monitoreo continuo que le avisa si algo dejó de pasar, antes de que se traduzca en correo que no llega.

Los errores que más vemos

Dos registros SPF. El más común y el que rompe todo en silencio. Debe haber uno solo, con todas las fuentes combinadas. Dos registros hacen que ambos fallen.

Empezar DMARC en reject. Imponer la política estricta antes de verificar las fuentes legítimas. Resultado: correo importante que deja de llegar. Siempre empiece en p=none.

Olvidar una fuente de envío. Configurar para el ESP y olvidar el sistema de facturación o el CRM. Esas fuentes fallan al endurecer. El inventario y los reportes lo previenen.

DKIM solo en una plataforma. Activar DKIM en el correo principal y olvidar el ESP o el transaccional. Cada plataforma necesita su propio DKIM con su selector.

Copiar mal la clave DKIM. Espacios o saltos de línea que el panel de DNS introduce y rompen la clave. Copiar exacto y verificar con el botón de la plataforma.

Poner una dirección de reportes que nadie revisa. El rua apunta a una bandeja que nadie abre, y los reportes —que son el valor de DMARC— se pierden. Use una bandeja revisada o una herramienta que los procese.

Preguntas frecuentes