Inicio › Guías

Cómo configurar SPF, DKIM y DMARC: registros, errores y comprobación

Publicado 2026-11-03 ／ Actualizado 2026-11-03 ／ Por Yuki Nakazawa

Una configuración de SPF, DKIM y DMARC ya no es opcional si envía correo desde su propio dominio. Hágala en este orden: publique un único registro SPF, active la firma DKIM con una clave de 2048 bits y, después, publique un registro DMARC que empiece en p=none con los informes activados. De paso, asegúrese de que la dirección IP que envía su correo tiene un DNS inverso (PTR) coincidente.

Esta guía sirve tanto si envía desde un hosting compartido como desde su propio VPS, Google Workspace, Microsoft 365 o un servicio de envío masivo. Incluye registros que puede adaptar, los errores que con más frecuencia rompen la autenticación y cómo confirmar que todo funciona a partir del encabezado de un mensaje real.

Los datos que siguen se han contrastado con los RFC y con las páginas oficiales de Google, Yahoo y Microsoft en noviembre de 2026. Los requisitos de los proveedores de correo cambian, así que sus páginas son la referencia definitiva.

Qué demuestra cada uno de SPF, DKIM y DMARC, y en qué orden configurarlos

SPF (Sender Policy Framework) permite a un dominio indicar en el DNS qué servidores están autorizados a enviar su correo. El servidor receptor mira el remitente del sobre (la dirección SMTP MAIL FROM, que luego aparece como Return-Path), obtiene el registro SPF de ese dominio y comprueba si la dirección IP que se conecta figura en la lista. Por sí solo, SPF no dice nada sobre la dirección From que ve el lector.

DKIM (DomainKeys Identified Mail) añade una firma criptográfica a cada mensaje. El sistema de envío firma con una clave privada y los receptores verifican la firma con una clave pública publicada en el DNS. Una firma válida demuestra que el dominio firmante (el valor d=) asumió la responsabilidad del mensaje y que los encabezados firmados y el cuerpo no se alteraron por el camino.

DMARC (Domain-based Message Authentication, Reporting and Conformance) vincula ambos al dominio From visible. Un mensaje supera DMARC solo cuando SPF o DKIM lo superan y el dominio autenticado está alineado con el dominio From. El registro DMARC también indica a los receptores qué desea que hagan con los fallos (nada, cuarentena o rechazo) y adónde enviar los informes agregados, que es como se descubren fuentes de envío olvidadas.

Orden de configuración

1. Haga una lista de todos los sistemas que envían correo en nombre de su dominio: su propio servidor, Google Workspace o Microsoft 365, los servicios de boletines y de correo transaccional, los formularios web y las herramientas de facturación y de soporte (help desk).
2. Publique un único registro SPF que los abarque a todos.
3. Active DKIM en cada sistema de envío y publique su clave pública.
4. Publique DMARC con p=none y una dirección de informes rua. Google sugiere esperar 48 horas después de configurar SPF y DKIM antes de añadir DMARC.
5. Lea los informes, corrija las fuentes que fallen y pase después a p=quarantine y, finalmente, a p=reject.

Configuración de SPF: un registro, diez consultas

SPF es un registro TXT en el propio dominio. Este es el de un dominio que envía desde su propio servidor por IPv4 e IPv6 y que además usa Google Workspace:

example.com.  3600  IN  TXT  "v=spf1 ip4:203.0.113.10 ip6:2001:db8::10 include:_spf.google.com ~all"

En la mayoría de los paneles de control de DNS se deja vacío el campo de host (o se escribe @), se elige TXT y se pega el valor a partir de v=spf1. Componentes habituales:

Errores frecuentes con SPF

• Un solo registro SPF por nombre. RFC 7208 prohíbe tener varios registros SPF para el mismo dominio; los receptores devuelven permerror y SPF falla para todo. Al añadir un servicio, edite el registro existente y agregue su include: en lugar de crear un segundo registro v=spf1.
• El límite de 10 consultas. Los mecanismos include, a, mx, ptr y exists, y el modificador redirect, generan consultas DNS, y el total de toda la evaluación, incluidas las consultas dentro de includes anidados, no debe superar 10. Si se supera, el resultado es permerror. ip4:, ip6: y all no cuentan. RFC 7208 indica también que los receptores deberían detenerse tras dos consultas que no devuelvan respuesta, así que elimine los includes de servicios que ya no use.
• ~all frente a -all. -all significa que las fuentes no incluidas no están autorizadas (fail); ~all significa que probablemente no lo están (softfail). Google recomienda ~all para los dominios de Workspace; Microsoft recomienda -all para los dominios de Microsoft 365 que también usan DKIM y DMARC. Si aún no está seguro de haber localizado todos los remitentes, empiece con ~all y deje que DMARC se encargue de la aplicación.
• Los subdominios necesitan su propio registro. El registro SPF de example.com no cubre news.example.com. Colocar un servicio de envío masivo en su propio subdominio le da además un presupuesto independiente de 10 consultas y mantiene su reputación separada del correo del personal.
• Errores de sintaxis. Microsoft enumera los habituales: include= en lugar de include:, un espacio después de los dos puntos y un punto final tras el dominio incluido.

Para los dominios que nunca envían correo, publique v=spf1 -all para que sea más difícil suplantarlos.

Configuración de DKIM: claves de 2048 bits y selectores

DKIM tiene dos mitades: el sistema de envío firma con una clave privada y el DNS publica la clave pública correspondiente. Con Google Workspace, Microsoft 365, la mayoría de los paneles de control de hosting y la mayoría de los servicios de correo, la clave se genera en la consola de administración y se copia el valor DNS que esta muestra.

Longitud de la clave y selectores

Use una clave RSA de 2048 bits. RFC 8301 fija 1024 bits como mínimo e indica que los firmantes deberían usar al menos 2048 bits; también prohíbe rsa-sha1. Las indicaciones de Google coinciden: elija 2048 bits si su proveedor de DNS lo admite y recurra a 1024 solo si no es así.

El selector es una etiqueta que identifica qué clave firmó un mensaje, de modo que un dominio puede tener varias claves a la vez, una por servicio de envío o una por periodo de rotación. La clave pública se encuentra en selector._domainkey.yourdomain. Google Workspace usa google como selector predeterminado. Microsoft 365 usa dos registros CNAME, selector1._domainkey y selector2._domainkey, que apuntan a claves alojadas por Microsoft; tome los destinos exactos del portal de Defender o de Get-DkimSigningConfig, porque el formato varía según el inquilino (tenant).

Cómo publicar una clave pública larga

Una clave pública de 2048 bits supera los 255 caracteres permitidos en una sola cadena de caracteres DNS, así que, en formato de archivo de zona, se escribe como varias cadenas entre comillas dentro de un mismo registro TXT:

selector1._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA(first part of your key)"
    "(rest of your key)IDAQAB" )

Sustituya las partes entre paréntesis por su clave real. Los receptores unen las cadenas sin espacios intermedios, así que puede dividirla en cualquier punto de la clave. Muchos paneles de control dividen automáticamente los valores largos: pegue primero el valor completo y divídalo usted solo si el panel lo rechaza. Asegúrese de que no se pierde nada al copiar; un p= vacío significa que la clave se ha revocado.

En su propio VPS con Postfix u otro MTA similar, un milter de firma como OpenDKIM puede crear el par de claves, por ejemplo opendkim-genkey -b 2048 -s selector1 -d example.com. Publique el contenido del archivo de clave pública generado tal como se muestra arriba.

Compruebe que los mensajes se firman de verdad

Abra un mensaje que haya enviado y busque un encabezado DKIM-Signature:. Su etiqueta d= debe ser su dominio, y s=, el selector que publicó. Muchos servicios de correo firman por defecto con su propio dominio; eso supera DKIM, pero no está alineado con su dominio From, así que no ayuda con DMARC. Active la autenticación con dominio personalizado del servicio para que d= pase a ser su dominio.

Configuración de DMARC: empezar en p=none y luego aplicar

DMARC es un registro TXT en _dmarc bajo su dominio. Empiece en modo de supervisión, que pide a los receptores que no cambien la forma de tratar su correo, y solicite informes agregados:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Los informes agregados son resúmenes legibles por máquina de qué direcciones IP enviaron correo en nombre de su dominio y de si lo superaron; Google sugiere un buzón o un grupo dedicado para recibirlos. Cuando los informes muestren que todas las fuentes legítimas pasan con alineación, endurezca la política editando el mismo registro en lugar de añadir otro:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

La alineación, en pocas palabras

Para superar DMARC, al menos uno de SPF o DKIM tiene que pasar para un dominio que coincida con el dominio From. En modo flexible (relaxed) deben coincidir los dominios organizativos, de modo que una firma DKIM con d=example.com está alineada con el correo de alerts@news.example.com. El modo estricto (strict) exige una coincidencia exacta. Los servicios de correo suelen usar su propio dominio en el Return-Path, así que SPF no estará alineado aunque pase; un DKIM alineado es la forma práctica de que esos mensajes superen DMARC.

Si quiere una política distinta para los subdominios, añada sp=. Por ejemplo, p=reject; sp=quarantine rechaza el correo que falla del dominio principal y solo pone en cuarentena los fallos de los subdominios.

Una nota sobre el estándar actualizado

En mayo de 2026, DMARC se volvió a publicar como RFC 9989, que deja obsoleto a RFC 7489. Los registros existentes siguen funcionando y siguen empezando por v=DMARC1. El nuevo estándar elimina la etiqueta pct, que rara vez se aplicaba con precisión salvo con 0 o 100, y añade etiquetas como t=y (modo de prueba) y np (política para subdominios inexistentes). Algunas páginas de ayuda de proveedores todavía muestran pct, por lo que la forma menos ambigua de introducir la aplicación es avanzar por los valores de p=.

DNS inverso (PTR) de la IP de envío

El DNS inverso asocia una dirección IP con un nombre de host. Google exige a todos los que envían a cuentas personales de Gmail tener un registro PTR cuyo nombre de host resuelva de nuevo a la misma IP de envío, y Yahoo exige DNS directo e inverso válidos para las IP de envío y recomienda un registro PTR significativo y no genérico.

203.0.113.10       PTR  mail.example.com.
mail.example.com.  A    203.0.113.10

El registro PTR no está en la zona de su dominio. Lo controla quien es titular de la dirección IP, así que en un VPS se configura en el panel de control del proveedor (a menudo llamado DNS inverso o rDNS) y, después, se crea un registro A coincidente (AAAA para IPv6) en su propio DNS. Si envía por IPv6, la dirección IPv6 necesita el mismo tratamiento. Con Google Workspace, Microsoft 365, los servicios de correo y la mayoría de los hostings compartidos, el proveedor gestiona por usted las IP de envío y su DNS inverso.

Cómo verificar la configuración

Lea Authentication-Results

Envíe un mensaje de prueba a un buzón externo y consulte los encabezados completos. En Gmail, abra el mensaje y elija Mostrar original. La ayuda de Google sobre DKIM indica que conviene enviarlo a otro usuario y no a uno mismo. Busque un encabezado como este:

Authentication-Results: mx.example.net;
       dkim=pass header.i=@example.com header.s=selector1;
       spf=pass smtp.mailfrom=example.com;
       dmarc=pass header.from=example.com

La disposición exacta varía según el receptor. Lo importante es spf=pass, dkim=pass y dmarc=pass, con su propio dominio en header.i o header.d y en header.from. Si SPF pasa para el dominio de un servicio pero DKIM muestra otro dominio, DMARC fallará: corrija primero la alineación de DKIM.

Consulte el DNS directamente

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short -x 203.0.113.10

En Windows, nslookup -type=TXT _dmarc.example.com hace lo mismo. Los cambios de DNS pueden tardar en propagarse; Google indica que SPF y DKIM pueden tardar cada uno hasta 48 horas en empezar a funcionar. Los comprobadores en línea gratuitos también pueden analizar sus registros y contar por usted las consultas de SPF.

Si la autenticación pasa y el correo sigue rebotando o llegando a spam, compruebe con nuestro comprobador de listas negras si su IP o dominio de envío figura en alguna DNSBL, y consulte correo no entregado por una lista negra para ver los pasos siguientes.

Requisitos para remitentes de Gmail, Yahoo y Outlook.com

Los grandes proveedores de correo ya exigen la autenticación. En noviembre de 2026, sus páginas oficiales indican lo siguiente.

• Gmail (vigente desde el 1 de febrero de 2024): todo el que envía a cuentas personales de Gmail necesita SPF o DKIM, DNS directo e inverso coincidentes, una conexión TLS y una tasa de spam inferior al 0,3% en Postmaster Tools. Quienes envían más de 5.000 mensajes al día necesitan además SPF y DKIM a la vez, un registro DMARC (p=none es aceptable), un dominio From alineado con SPF o DKIM y la baja con un solo clic en el correo de marketing. Las claves DKIM deben tener al menos 1024 bits, y se recomiendan 2048.
• Yahoo (aplicación desde febrero de 2024): todos los remitentes necesitan SPF o DKIM, DNS directo e inverso válidos y una tasa de spam inferior al 0,3%. Los remitentes masivos necesitan SPF y DKIM a la vez, una política DMARC de al menos p=none que se supere, alineación del From (la flexible es suficiente), una baja con un solo clic que funcione y DNS directo e inverso válidos para las IP de envío.
• Outlook.com (el servicio de consumo detrás de outlook.com, hotmail.com y live.com): los dominios que envían más de 5.000 correos al día deben superar SPF y DKIM y publicar DMARC de al menos p=none, alineado con SPF o DKIM. Microsoft anunció que, a partir del 5 de mayo de 2025, los mensajes que no cumplieran se rechazarían con el error 550; 5.7.515.

Puede leer el texto completo en las directrices para remitentes de correo electrónico de Google, las prácticas recomendadas para remitentes de Yahoo y el anuncio de Microsoft sobre Outlook.com. Aunque envíe muchos menos mensajes, configurar los tres ahora evita que un umbral más bajo en el futuro le pille desprevenido. Para resolver problemas específicos de Gmail, consulte Gmail no entrega su correo.

Errores habituales

• Un segundo registro SPF. Añadir un nuevo registro v=spf1 por cada servicio invalida SPF para todo el dominio. Reúnalo todo en uno.
• Demasiados includes. Los servicios antiguos que siguen en SPF consumen el presupuesto de 10 consultas. Elimine lo que ya no use y traslade el correo masivo a un subdominio.
• Clave publicada, firma sin activar. En Google Workspace todavía hay que hacer clic en Iniciar autenticación una vez que el registro DNS está activo; otras plataformas tienen un interruptor similar.
• El servicio firma con su propio dominio. SPF y DKIM pasan, pero DMARC falla. Active la firma con dominio personalizado.
• Pasar directamente a p=reject. Un formulario web o un sistema de facturación olvidado deja de entregar de la noche a la mañana. Empiece en p=none y lea los informes.
• Daños al copiar y pegar. Comillas de más dentro del valor, una clave truncada o un nombre de host que acaba siendo _dmarc.example.com.example.com porque el panel añade el dominio automáticamente. Un dig rápido detecta todos estos casos.

Preguntas frecuentes

Páginas oficiales consultadas

Los datos de este artículo se contrastaron con las páginas oficiales que se indican a continuación en el momento de su publicación. Las políticas y el funcionamiento pueden cambiar sin previo aviso, por lo que conviene consultar las páginas oficiales antes de tomar decisiones importantes.

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DKIM
• RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC)
• RFC 9989: DMARC (obsoletes RFC 7489)
• Google: Email sender guidelines
• Google Workspace: Set up SPF
• Google Workspace: Set up DKIM
• Google Workspace: Set up DMARC
• Yahoo Sender Hub: Sender Best Practices
• Microsoft Community Hub: Outlook's New Requirements for High-Volume Senders
• Microsoft Learn: Set up SPF for your Microsoft 365 domain
• Microsoft Learn: How to use DKIM for email in your custom domain

Guías relacionadas

Todas las guías →