Si envía correos en frío desde su propio dominio, tres registros DNS deciden si los servidores receptores creen que el correo realmente es suyo: SPF, DKIM y DMARC. Sin ellos, incluso un primer correo bien redactado puede ser filtrado antes de que alguien lo lea.
Esta guía está dirigida a fundadores y equipos de ventas que envían correos de prospección desde una dirección como you@yourcompany.com, normalmente a través de Google Workspace. Nosotros (Outreach) recorremos cada registro en el orden en que conviene configurarlo, mostramos los formatos de registro tal como los publican las páginas de ayuda de Google y las RFC, y señalamos los errores que hacen que un registro parezca correcto mientras falla en silencio.
No necesita ser un experto en DNS. Necesita acceso a la configuración DNS de su dominio (en su registrador o su proveedor de DNS) y, para DKIM, acceso de administrador a Google Workspace.
¿Qué son SPF, DKIM y DMARC, en una frase cada uno?
SPF enumera los servidores autorizados a enviar correo en nombre de su dominio, DKIM añade una firma criptográfica que demuestra que un mensaje no fue falsificado ni alterado, y DMARC le indica a quien recibe el correo qué hacer cuando un mensaje no pasa esas verificaciones. Los tres se publican como registros TXT en el DNS de su dominio.
| Registro | Dónde se publica | Qué responde |
|---|---|---|
| SPF | yourcompany.com (host @) |
«¿Está autorizado este servidor a enviar correo para este dominio?» |
| DKIM | google._domainkey.yourcompany.com |
«¿Firmó el dominio este mensaje y no ha cambiado?» |
| DMARC | _dmarc.yourcompany.com |
«Si falla una verificación, ¿qué quiere el titular del dominio que se haga?» |
Funcionan en conjunto. SPF y DKIM demuestran cada uno algo muy concreto; DMARC vincula esas pruebas con la dirección que las personas ven realmente en el campo «De» (From).
¿Son realmente obligatorios estos registros para el correo en frío?
Sí: Gmail y Yahoo exigen al menos SPF o DKIM a todos los remitentes, y los remitentes masivos necesitan los tres. No es una recomendación de buenas prácticas; figura en las normas para remitentes que publican ambos proveedores.
Las pautas para remitentes de correo electrónico de Google establecen que todos los remitentes deben «Configurar la autenticación de correo mediante SPF o DKIM en sus dominios de envío.» Los remitentes de «más de 5.000 mensajes al día a cuentas de Gmail» también deben «Configurar SPF y DKIM», además de la «autenticación de correo mediante DMARC en su dominio de envío», y el dominio del campo «De» debe estar alineado con el dominio de SPF o DKIM. Estas normas entraron en vigor el 1 de febrero de 2024.
Las prácticas recomendadas de Sender Hub de Yahoo coinciden: todos los remitentes deben «Implementar SPF o DKIM como mínimo», y los remitentes masivos deben «Implementar tanto SPF como DKIM» y «Publicar una política DMARC válida con al menos p=none.»
Un programa pequeño de correo en frío quizá nunca llegue a 5.000 mensajes al día. Aun así, configure los tres: no cuesta nada, lleva una tarde y significa que nunca tendrá que averiguar dónde está el límite.
¿Cómo se configura SPF?
Añada un registro TXT en su dominio raíz que empiece por v=spf1, enumere todos los servicios que envían correo en su nombre y termine en ~all. Para un dominio que envía únicamente a través de Google Workspace, la página de configuración de SPF de Google ofrece exactamente este registro:
v=spf1 include:_spf.google.com ~all
Pasos:
- Inicie sesión en la configuración DNS de su proveedor de dominio.
- Cree un registro TXT. En el campo de host o nombre, Google indica que debe escribir
@si lo agrega al dominio raíz y no a un subdominio. - Pegue el registro como valor y guarde.
- Espere. Google señala que «La autenticación de SPF puede tardar hasta 48 horas en comenzar a funcionar.»
Si otros servicios también envían correo desde su dominio (una herramienta de boletines, un CRM, un servicio de correo transaccional), cada uno necesita su propio include: en el mismo registro. La página de Google ofrece estos ejemplos combinados:
v=spf1 include:_spf.google.com include:amazonses.com ~all
v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all
v=spf1 include:_spf.google.com include:_spf.salesforce.com ~all
Use el valor de include que documenta cada servicio de envío; no lo adivine.
¿Debe el registro SPF terminar en ~all o en -all?
La guía de configuración de Google usa ~all, y es la opción predeterminada más segura mientras todavía está descubriendo todos los servicios que envían correo en su nombre. Los dos finales significan cosas distintas en la RFC 7208, el estándar de SPF:
~all(softfail) es «Una declaración débil del ADMD que publica el registro de que probablemente el host no está autorizado.»-all(fail) es «Una declaración explícita de que el cliente no está autorizado a usar el dominio en la identidad indicada.»
Con -all, un servicio de envío que olvidó incluir recibe un fallo estricto. Cuando DMARC ya está implantado y sus informes muestran que todas las fuentes legítimas pasan la verificación, el final del registro SPF importa menos, porque la política de DMARC pasa a ser la instrucción que siguen los receptores.
¿Por qué SPF falla cuando hay demasiados include?
Porque una verificación SPF puede activar como máximo 10 consultas DNS; si se supera ese número, todo el resultado se convierte en un error. La RFC 7208, sección 4.6.4 establece que las implementaciones «DEBEN limitar a 10 el número total de esos términos durante la evaluación de SPF» y que «Si se supera este límite, la implementación DEBE devolver “permerror”.»
Los términos que cuentan son include, a, mx, ptr, exists y el modificador redirect. Lo fundamental es que el recuento abarca toda la evaluación, así que un include: que a su vez contiene más include consume varios de sus 10. La propia página de Google lo expresa como «Un registro SPF puede tener hasta 10 etiquetas include:»; la RFC es la lectura más estricta porque las consultas anidadas también cuentan.
Si a lo largo de los años ha añadido varias herramientas de ventas y marketing, elimine las que ya no utiliza antes de añadir nuevos include.
¿Qué ocurre si un dominio tiene dos registros SPF?
SPF falla con un error: dos registros se tratan como una configuración rota, no como dos listas que se combinan. La RFC 7208 indica que, cuando existe más de un registro v=spf1 para un dominio, la verificación «produce el resultado “permerror”.»
Esto suele ocurrir así: alguien añade un segundo registro TXT para una herramienta nueva en lugar de editar el existente. La solución es fusionarlos en un solo registro con varios términos include:, como en los ejemplos anteriores.
¿Cómo se activa DKIM en Google Workspace?
Genere una clave en la Consola del administrador, publíquela como registro TXT en google._domainkey y luego haga clic en «Iniciar la autenticación». La página de configuración de DKIM de Google detalla el recorrido:
- En la Consola del administrador de Google, vaya a Apps > Google Workspace > Gmail > Autenticar correo electrónico. (Necesita el privilegio de administrador de configuración de Gmail.)
- Elija el dominio y genere un registro nuevo.
- Elija la longitud de la clave. Google indica que se elija 2048 «Si su proveedor de dominio admite claves de 2048 bits» porque «Las claves más largas son más seguras que las más cortas», y 1024 solo «Si el host de su dominio no admite claves de 2048 bits».
- Mantenga el prefijo selector predeterminado,
google: Google lo llama «la opción recomendada» para Workspace. - Google le muestra un nombre de host DNS,
google._domainkey, y un valor TXT que empieza porv=DKIM1. Copie ambos en un nuevo registro TXT en su proveedor de DNS. - De vuelta en la Consola del administrador, haga clic en Iniciar la autenticación.
El valor TXT que genera Google tiene esta forma (la clave en sí es una cadena larga exclusiva de su dominio):
v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(your public key continues)
Plazos: Google indica que «el funcionamiento de la autenticación DKIM puede demorar hasta 48 horas» después de añadir la clave. Si acaba de configurar Gmail para un dominio nuevo, Google señala que «debe esperar entre 24 y 72 horas» antes de que la clave DKIM esté siquiera disponible en la Consola del administrador.
Si otro servicio envía correo en su nombre, le dará su propio registro DKIM con su propio selector. Publíquelo también: varias claves DKIM con selectores distintos pueden coexistir, a diferencia de SPF.
¿Cómo se configura DMARC sin bloquear su propio correo?
Publique primero un registro TXT en _dmarc.yourcompany.com con p=none, lea los informes y solo entonces endurezca la política. La página de configuración de DMARC de Google dice: «Cuando comience a usar DMARC, le recomendamos que configure la opción de política (p) en none.» También le aconseja «Esperar 48 horas después de configurar SPF o DKIM antes de configurar DMARC.»
La página de Google ofrece este registro de ejemplo completo:
v=DMARC1; p=reject; rua=mailto:postmaster@example.com, mailto:dmarc@example.com; pct=100; adkim=s; aspf=s
Ese ejemplo muestra el estado final y más estricto. Para un primer registro basta con el mismo formato con una política de supervisión y una sola dirección para los informes, por ejemplo v=DMARC1; p=none; rua=mailto:dmarc@yourcompany.com. La etiqueta rua envía informes agregados a ese buzón; Google recomienda un buzón o un grupo dedicado, porque los informes pueden llegar en gran cantidad.
Los tres valores de política, tal como los define la especificación de DMARC:
| Política | Qué les pide a los receptores que hagan |
|---|---|
p=none |
Ninguna acción concreta: solo informar |
p=quarantine |
Tratar los fallos como sospechosos (por ejemplo, enviarlos a la carpeta de spam) |
p=reject |
Rechazar el correo que no pasa la verificación DMARC |
Un dominio tiene un registro DMARC. Según la RFC 9989, si se devuelven varios registros DMARC, «se descartan todos», lo que significa que no se aplica ninguna política.
¿Qué significa «alineación» y por qué falla DMARC cuando SPF pasa?
DMARC solo pasa cuando SPF o DKIM pasan para un dominio que coincide con la dirección «De» que ven las personas. SPF puede pasar para el dominio propio de su servicio de envío mientras el campo «De» muestra el suyo, y entonces DMARC sigue fallando, porque el dominio que pasa no está alineado.
La especificación de DMARC establece que un mensaje pasa cuando al menos un método de autenticación produce un resultado positivo «basado en un identificador que está alineado» (RFC 7489, que ahora continúa en la RFC 9989). Por defecto, la alineación es relajada (adkim y aspf tienen r como valor predeterminado): mail.yourcompany.com y yourcompany.com cuentan como coincidentes porque comparten el mismo dominio organizativo. El modo estricto (s), como en el ejemplo de Google, exige una coincidencia exacta.
En la práctica, por eso DKIM importa tanto en el correo en frío: cuando su servicio de envío firma con su dominio, la alineación de DKIM pasa aunque la de SPF no lo haga.
¿Cambió el estándar DMARC en 2026?
Sí. La RFC 9989, publicada en mayo de 2026 como documento de la vía de estándares (Standards Track), deja obsoleta la RFC 7489 original y elimina la etiqueta pct. Los registros v=DMARC1 existentes siguen funcionando.
El cambio principal que notará la mayoría de los remitentes: pct (aplicar la política solo a un porcentaje del correo que falla) desaparece. La RFC explica que «La experiencia operativa demostró que la etiqueta “pct” normalmente no se aplicaba con precisión, salvo que el valor especificado fuera 0 o 100.» En su lugar hay un indicador de prueba, t=y, que pide a los receptores que no apliquen la política que usted indicó mientras la está probando.
La página de ayuda de Google sigue mostrando pct=100 en su ejemplo. Eso no rompe nada: la RFC 9989 dice que «las etiquetas desconocidas DEBEN ignorarse», así que un pct sobrante simplemente se omite. Cuando vuelva a editar su registro, puede eliminarlo.
¿Cómo se comprueba que todo funciona?
Consulte los registros que publicó y luego envíe un mensaje real a una dirección de Gmail y lea sus resultados de autenticación. Dos comprobaciones rápidas:
- Consulte los registros DNS. Nuestro verificador gratuito busca los registros SPF, DKIM y DMARC del dominio de la dirección que usted escriba, sin necesidad de registrarse. Comprueba el selector DKIM predeterminado de Google (
google._domainkey); si su servicio de envío usa un selector distinto, el verificador informará de que DKIM no está confirmado aunque esté configurado. La herramienta está disponible en inglés y coreano; escriba su dirección de correo electrónico de envío. - Compruebe un mensaje real. Envíe un correo electrónico a una cuenta de Gmail que usted controle, ábralo, elija «Mostrar original» y busque
SPF: PASS,DKIM: PASSyDMARC: PASS.
Después deje pasar una o dos semanas para recibir los informes de DMARC. Cuando todas las fuentes legítimas que usa muestren PASS, pase de p=none a p=quarantine y, más adelante, a p=reject si quiere la máxima protección contra la suplantación de identidad.
¿Qué errores rompen la autenticación con más frecuencia?
Dos registros SPF, demasiadas consultas SPF, DKIM generado pero nunca iniciado, y DMARC publicado antes de que SPF y DKIM hayan tenido tiempo de funcionar. Una lista de comprobación:
- Un solo registro SPF, con cada remitente como un
include:dentro de él, y no más de 10 términos de consulta. - Haga clic en «Iniciar la autenticación» después de publicar la clave DKIM: el registro DNS por sí solo no basta.
- Espere unas 48 horas después de SPF y DKIM antes de añadir DMARC, y publíquelo en
_dmarc, no en la raíz. - Envíe desde un dominio que usted controle. No puede publicar DMARC para una dirección
@gmail.com.
La autenticación hace que su correo sea tenido en cuenta; no hace que los destinatarios quieran recibirlo. Las quejas por spam siguen contando: Google y Yahoo indican que debe mantener su tasa de spam por debajo del 0.3%, como explicamos en por qué el correo en frío acaba en spam. Y enviar a direcciones que no existen genera rebotes, por eso recomendamos verificar las direcciones antes de enviar.
En resumen
- Google y Yahoo exigen SPF o DKIM a todos los remitentes, y los tres más la alineación a los remitentes masivos (más de 5.000 mensajes al día a Gmail).
- SPF: un registro TXT en
@, por ejemplov=spf1 include:_spf.google.com ~all; no supere los 10 términos de consulta DNS. - DKIM: clave de 2048 bits, selector
google, TXT engoogle._domainkeyy luego Iniciar la autenticación. - DMARC: un registro TXT en
_dmarc, empiece conp=noney una dirección para los informes, y endurezca la política más adelante. La RFC 9989 (mayo de 2026) reemplazópctport=y. - Compruebe sus registros con nuestro verificador gratuito de autenticación de correo y confírmelo después con un mensaje real.
