Cómo autenticar un dominio de envío: guía de configuración de SPF, DKIM y DMARC

Para autenticar un dominio de envío, se publican tres registros DNS que demuestran a Gmail, Yahoo, Outlook y a cualquier otro servidor receptor que sus mensajes son realmente suyos: SPF enumera los servidores autorizados a enviar en su nombre, DKIM añade una firma criptográfica a cada mensaje y DMARC indica a los receptores qué hacer cuando esas comprobaciones fallan. Si se hace de una sola vez, suele llevar unos 30 minutos y es el paso individual más importante que puede dar para mejorar la llegada a la bandeja de entrada.

La versión resumida

1. Compruebe lo que ya existe. Consulte sus registros SPF, DKIM y DMARC actuales para editarlos en lugar de duplicarlos.
2. Publique un único registro SPF. Un solo registro TXT en la raíz del dominio que incluya todos los servicios que envían en su nombre.
3. Publique DKIM. El registro del selector que aparece en su panel, para que cada mensaje se firme.
4. Publique DMARC con p=none. Empiece en modo de monitorización con una dirección para los informes.
5. Verifique. Ejecute dig, envíe después un mensaje de prueba y lea los encabezados.
6. Aplique la política. Revise los informes y pase después a p=quarantine y p=reject.

¿Qué significa autenticar un dominio de envío?

El correo electrónico se diseñó sin ningún modo de verificar quién envió un mensaje. Cualquiera puede escribir su dirección en el campo From, y por eso el phishing y la suplantación son tan frecuentes. La autenticación cierra esa brecha con tres comprobaciones complementarias, cada una de las cuales responde a una pregunta distinta del servidor receptor:

• ¿Está este servidor autorizado a enviar en nombre de este dominio? Eso lo responde SPF (Sender Policy Framework, definido en la RFC 7208).
• ¿El mensaje procede realmente de este dominio y no se ha alterado? Eso lo responde DKIM (DomainKeys Identified Mail, RFC 6376).
• ¿Qué debe ocurrir si alguna de las dos comprobaciones falla y quién recibe el informe? Eso lo responde DMARC (RFC 7489).

Los receptores combinan las tres en una señal de confianza. Los mensajes que se autentican y se alinean con su dominio From construyen con el tiempo una reputación de dominio estable. Los que no lo hacen se filtran, se retrasan o se rechazan, y con volúmenes mayores los principales proveedores de correo los rechazan ya de plano.

SPF, DKIM y DMARC de un vistazo

	SPF	DKIM	DMARC
Qué demuestra	El servidor emisor está autorizado para el dominio	El dominio firmó el mensaje y este no se modificó en tránsito	Las comprobaciones se alinean con el dominio From visible, y define la política
Dónde reside en el DNS	Registro TXT en la raíz del dominio	TXT o CNAME en selector._domainkey	Registro TXT en _dmarc
Qué se comprueba	Dominio del Return-Path (remitente del sobre) e IP de envío	Firma en el encabezado DKIM-Signature	Dominio del encabezado From frente a los resultados de SPF y DKIM
¿Sobrevive al reenvío?	Normalmente no	Sí, si el contenido no se modifica	Pasa si DKIM pasa y se alinea
Causa principal de fallo	Falta un remitente o hay más de 10 consultas	Selector incorrecto o clave copiada con errores	Desajuste de alineación

Antes de empezar: qué necesita

• Acceso para editar el DNS del dominio (registrador, Cloudflare, cPanel o su proveedor de DNS).
• Una lista de todos los servicios que envían correo con su dominio: su cuenta de MigoSMTP, su correo de oficina (Google Workspace o Microsoft 365), su CRM y sus herramientas de facturación y soporte.
• Un buzón para recibir los informes DMARC, preferiblemente una dirección dedicada como dmarc-reports en su dominio.
• El include de SPF y los valores del registro DKIM de la página Dominios del panel de MigoSMTP.

Paso 1: Compruebe sus registros actuales

Los registros duplicados son la causa más común de que falle la autenticación. Consulte lo que ya está publicado antes de añadir nada. En macOS o Linux use dig; en Windows use nslookup.

dig +short TXT example.com
dig +short TXT _dmarc.example.com

# Windows
nslookup -type=TXT example.com

Busque cualquier registro TXT que empiece por v=spf1 (SPF) y cualquiera en _dmarc que empiece por v=DMARC1. Si existe alguno de los dos, edítelo en lugar de añadir otro.

Paso 2: Añada su registro SPF

SPF es un único registro TXT en la raíz de su dominio. Enumera los servicios autorizados a enviar correo usando su dominio como remitente del sobre (el Return-Path).

Sintaxis del registro SPF

v=spf1 include:YOUR-MIGOSMTP-INCLUDE include:_spf.google.com ~all

Parte	Significado
v=spf1	Obligatorio. Marca el registro como SPF versión 1.
include:domain	Autoriza todo lo que autoriza el propio registro SPF de ese dominio. Use el valor de su panel de MigoSMTP.
ip4:203.0.113.10	Autoriza una dirección o un rango IPv4 concretos. IPv6 usa ip6:.
a, mx	Autoriza las IP de los registros A o MX de su dominio.
~all	Soft fail: todo lo que no figure en la lista es sospechoso, pero no se rechaza de plano. Habitual mientras aún añade remitentes.
-all	Hard fail: todo lo que no figure en la lista no está autorizado. Úselo cuando esté seguro de haber incluido todos los remitentes.

El límite de 10 consultas

La evaluación de SPF puede provocar como máximo 10 consultas DNS. Cuentan todos los include, a, mx, exists y redirect, incluidas las consultas que se realizan dentro de los registros que incluya. Si se supera, los receptores devuelven un error permanente y SPF falla en todos los mensajes. Para mantener bajo el recuento, elimine los servicios que ya no use, sustituya a y mx por rangos ip4 explícitos cuando sean estables y traslade las herramientas de uso poco frecuente a su propio subdominio.

Errores comunes de SPF

• Dos registros SPF con el mismo nombre (reúnalos en uno).
• Usar +all, que autoriza a todo internet.
• Escribir el valor del include con espacios de más o sin los dos puntos.
• Olvidar un remitente, como un sistema de facturación o un servicio de asistencia, de modo que su correo falla SPF.
• Publicar SPF en un nombre incorrecto, como el host www en lugar de la raíz del dominio.

Paso 3: Publique su registro DKIM

DKIM añade una firma digital a cada mensaje. Su plataforma de envío firma el correo saliente con una clave privada que mantiene en secreto, y usted publica en el DNS la clave pública correspondiente para que los receptores puedan verificar la firma.

Selectores y dónde va el registro

Cada clave reside bajo un nombre llamado selector, con el formato selector._domainkey.yourdomain.com. El selector permite publicar varias claves a la vez y rotarlas sin tiempo de inactividad. El panel de MigoSMTP muestra el nombre y el valor exactos para su dominio.

Name:  selector1._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...(long public key)

¿TXT o CNAME?

Algunas plataformas piden publicar la clave pública directamente como registro TXT. Otras le dan un CNAME que apunta a un registro que ellas alojan, lo que les permite rotar las claves por usted. Publique exactamente el tipo que muestra su panel. No convierta uno en el otro.

Longitud de la clave y formato

• Use claves RSA de 2048 bits cuando estén disponibles. Muchos receptores aún aceptan claves de 1024 bits, pero se consideran débiles.
• Una clave de 2048 bits supera los 255 caracteres, y una sola cadena DNS no puede exceder los 255 caracteres. Su proveedor de DNS debe dividir el valor en varias cadenas entrecomilladas dentro de un único registro TXT. La mayoría de los paneles lo hacen automáticamente; si el suyo no lo hace, divídalo manualmente.
• Copie el valor sin saltos de línea añadidos ni comillas tipográficas, y no lo envuelva en comillas adicionales a menos que su proveedor de DNS lo requiera.

Rotación

Rote las claves DKIM cada seis a doce meses, o de inmediato si una clave privada pudo quedar expuesta. Publique primero el nuevo selector, cambie la firma para que lo use y elimine el selector antiguo solo cuando haya terminado de llegar el correo firmado con él.

Paso 4: Publique su registro DMARC

DMARC vincula SPF y DKIM con el dominio que sus destinatarios ven realmente en la línea From, e indica a los receptores qué hacer con el correo que falla. Es un registro TXT en _dmarc.yourdomain.com. Empiece en modo de monitorización para ver quién envía en su nombre antes de aplicar cualquier restricción.

Name:  _dmarc.example.com
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; fo=1

Etiqueta	Qué hace	Valor habitual
v	Versión. Debe ir primero.	DMARC1
p	Política para el correo que falla: none (monitorizar), quarantine (carpeta de spam) o reject (rechazar).	none al principio
rua	Dónde se envían los informes agregados diarios.	mailto:dmarc-reports@example.com
ruf	Dónde se envían las muestras de fallos. Pocos receptores las envían.	Opcional
pct	Porcentaje del correo fallido al que se aplica la política, usado durante un despliegue gradual.	25, 50, 100
sp	Política para los subdominios si es distinta de la del dominio principal.	Igual que p, salvo que sea necesario
adkim, aspf	Modo de alineación: r (relajada) o s (estricta).	r (relajada) es el valor predeterminado
fo	Cuándo generar informes de fallos.	1

Qué significa realmente "alineación"

DMARC pasa cuando SPF o DKIM pasan y el dominio que ha pasado se alinea con el dominio From. Con alineación relajada, un subdominio del dominio From cuenta como alineado, de modo que un Return-Path de bounce.example.com se alinea con un From de news@example.com. Con alineación estricta, los dominios deben coincidir exactamente. La causa más común de que "SPF pase pero DMARC falle" es un Return-Path o un dominio DKIM que pertenece a su plataforma de envío en lugar de a usted. Active un Return-Path personalizado y su propio dominio de firma DKIM para solucionarlo.

Paso 5: Verifique que todo funciona

Compruebe los registros en el DNS

dig +short TXT example.com
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

Cada comando debería devolver el registro que publicó. Si no devuelve nada, el registro está en un nombre incorrecto o aún no se ha propagado. Espere a que caduque el TTL y vuelva a probar.

Envíe un mensaje de prueba y lea los encabezados

1. Envíe un mensaje desde su dominio autenticado a una dirección de Gmail que controle.
2. Abra el mensaje, elija el menú de tres puntos y seleccione Mostrar original.
3. En la parte superior verá SPF, DKIM y DMARC, cada uno con un PASS o un FAIL.
4. Compruebe que el dominio que aparece junto a cada PASS coincide con su dominio From.

Despliegue seguro de DMARC: de p=none a p=reject

El objetivo es p=reject, porque es la única política que impide que otros suplanten su dominio. Pero saltar directamente a ella puede bloquear correo legítimo de herramientas que haya olvidado. Avance por etapas y deje que los informes le guíen.

Etapa	Política	Duración	Qué hacer
1. Monitorizar	p=none	2 a 4 semanas	Lea los informes agregados. Haga una lista de todas las fuentes que envían con su dominio y corrija o autorice cada una de las legítimas.
2. Cuarentena parcial	p=quarantine; pct=25	1 a 2 semanas	El correo fallido del 25 por ciento del tráfico va a spam. Esté atento a quejas por correo que no llega.
3. Cuarentena completa	p=quarantine	2 semanas	Suba pct a 100 cuando los informes muestren que solo fallan fuentes no autorizadas.
4. Rechazo	p=reject	Continuo	Pase a reject, subiendo pct por etapas si lo desea. Siga leyendo los informes cada mes.

Los informes agregados de DMARC llegan como archivos XML comprimidos y no están pensados para leerse a mano. Use un analizador de informes DMARC, gratuito o de pago, para convertirlos en una tabla con las fuentes de envío, los volúmenes y los resultados de aprobado o fallido.

Requisitos de Gmail, Yahoo y Microsoft para remitentes masivos

Desde febrero de 2024, Gmail y Yahoo empezaron a aplicar reglas de autenticación y de cancelación de suscripción a quienes envían en volumen, y Microsoft comenzó a aplicar requisitos comparables a los buzones de consumidor de Outlook.com a partir de mayo de 2025. En resumen:

Requisito	Todos los remitentes	Remitentes masivos (unos 5.000 o más mensajes al día al proveedor)
SPF o DKIM	Obligatorio	Ambos obligatorios
Registro DMARC	Recomendado	Obligatorio, al menos p=none, alineado con From
Cancelación de suscripción con un clic	No obligatorio para el correo transaccional	Obligatorio para el correo de marketing y de suscripción (encabezados RFC 8058); atender las solicitudes en un plazo de dos días
Tasa de quejas de spam	Mantenerla baja	Mantenerse por debajo del 0,10 por ciento y no llegar nunca al 0,30 por ciento (Google Postmaster Tools)
DNS directo e inverso válidos, TLS	Obligatorio	Obligatorio

Los proveedores pueden cambiar los umbrales, así que consulte sus directrices vigentes para remitentes. Los enlaces están en la lista de referencias al final de esta guía.

Separe el correo de marketing y el transaccional con subdominios

La reputación se rastrea por dominio e IP de envío. Si una campaña promocional genera quejas, no querrá que los correos de restablecimiento de contraseña acaben en spam. El patrón habitual es un subdominio por flujo:

Flujo	Dirección From de ejemplo	Por qué separarlo
Transaccional	noreply@mail.example.com	Debe llegar siempre con rapidez. Un volumen bajo y una alta interacción mantienen alta la reputación.
Marketing	hello@news.example.com	Mayor volumen y más quejas. Los problemas quedan contenidos.
Correo corporativo	name@example.com	Los buzones de sus empleados quedan a salvo del riesgo del envío masivo.

Cada subdominio necesita sus propios registros SPF y DKIM. Un registro DMARC en el dominio principal protege los subdominios por defecto; añada una etiqueta sp= o un registro independiente en el subdominio si necesita una política distinta.

Errores de autenticación comunes y cómo solucionarlos

Síntoma	Causa probable	Solución
SPF permerror o "too many DNS lookups"	Más de 10 consultas o un error de sintaxis	Elimine los include que no use, convierta a ip4 los rangos estables y traslade los remitentes poco frecuentes a un subdominio.
Multiple SPF records found	Dos registros TXT empiezan por v=spf1	Reúnalos en un único registro.
DKIM: no key for signature	Nombre del selector incorrecto o registro no publicado	Compruebe el selector en el encabezado DKIM-Signature y compárelo con su nombre en el DNS.
DKIM: body hash did not verify	El mensaje se alteró después de firmarse (pies de página, reescritura de enlaces por otro sistema)	Desactive el paso que lo modifica o muévalo antes de la firma.
DMARC falla con SPF correcto	El dominio del Return-Path no se alinea con From	Use un Return-Path personalizado en su propio dominio.
DMARC falla con DKIM correcto	El dominio d= de DKIM no se alinea con From	Firme con su propio dominio, no con el predeterminado de la plataforma.
Registro no encontrado	Nombre de host incorrecto, un punto final o el dominio añadido dos veces por su panel de DNS	Muchos paneles añaden el dominio automáticamente. Introduzca solo la parte anterior, por ejemplo selector1._domainkey.
Los registros no se actualizan	El registro antiguo está en caché	Espere a que caduque el TTL. Reduzca el TTL antes de los cambios planificados.

Lista de comprobación de la autenticación

• Un registro SPF en la raíz del dominio, con menos de 10 consultas y que termine en ~all o -all.
• Registro del selector DKIM publicado, de 2048 bits si su proveedor de DNS lo permite.
• Registro DMARC en _dmarc con p=none y una dirección rua operativa.
• Return-Path y dominio DKIM personalizados para que ambos se alineen con su dominio From.
• El mensaje de prueba muestra SPF, DKIM y DMARC como PASS.
• Informes DMARC revisados semanalmente durante el despliegue.
• Correo de marketing y transaccional separados por subdominio.
• Recordatorio en el calendario para rotar las claves DKIM.

Lecturas adicionales y fuentes

• RFC 7208: Sender Policy Framework (SPF)
• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
• RFC 7489: Domain-based Message Authentication, Reporting and Conformance (DMARC)
• RFC 8058: Signaling One-Click Functionality for List Email Headers
• Google: Email sender guidelines
• Yahoo: Sender best practices
• Guías relacionadas: Guía de calentamiento de correo y Códigos de rebote SMTP explicados.