Cómo configurar DMARC, DKIM y SPF para tu dominio

Si tu dominio no tiene SPF, DKIM y DMARC configurados, tus emails ya están cayendo en spam. O peor, alguien más está enviando email como si fuera tú.

Google y Yahoo hicieron obligatoria la autenticación para remitentes masivos en febrero de 2024. Desde entonces, los requisitos solo se han vuelto más estrictos. A principios de 2026, los dominios sin autenticación adecuada enfrentan rechazo directo — no solo colocación en la carpeta de spam, sino hard bounces. Microsoft siguió con una aplicación similar en los dominios de Outlook y Hotmail.

Esto ya no es opcional. Así es cómo configurar los tres registros correctamente.

Qué hacen realmente estos tres registros

SPF, DKIM y DMARC son mecanismos de autenticación basados en DNS. Cada uno hace algo diferente:

• SPF le dice a los servidores receptores qué direcciones IP están permitidas para enviar email por tu dominio.
• DKIM adjunta una firma criptográfica a cada email saliente, demostrando que no fue manipulado en tránsito.
• DMARC une SPF y DKIM con una política que le dice a los receptores qué hacer cuando la autenticación falla.

Funcionan como un sistema. SPF solo no te salvará. DKIM solo tampoco. Necesitas los tres.

SPF: autoriza a tus remitentes

SPF (Sender Policy Framework) es un registro TXT en tu dominio que lista cada servidor autorizado a enviar correo en tu nombre.

El registro DNS

Agrega un registro TXT en tu dominio raíz (yourdomain.com):

v=spf1 include:sendkit.dev include:_spf.google.com ~all

Desglosándolo:

• v=spf1 — declara que este es un registro SPF.
• include:sendkit.dev — autoriza los servidores de correo de Sendkit.
• include:_spf.google.com — autoriza Google Workspace (si lo usas).
• ~all — soft-fail de cualquier cosa no listada. Usa -all para un fallo duro una vez que confíes en tu configuración.

El límite de 10 lookups

SPF tiene un límite estricto de 10 lookups DNS. Cada mecanismo include:, a:, mx: y redirect= cuenta como un lookup. Los includes anidados también cuentan — si include:sendkit.dev a su vez referencia otros dos dominios, son tres lookups en total.

Si excedes 10, todo tu registro SPF se vuelve inválido. Los receptores lo tratan como si no tuvieras SPF.

Esto pilla por sorpresa a los equipos que usan múltiples herramientas SaaS para email. Tu proveedor transaccional, tu herramienta de marketing, tu helpdesk, tu CRM — cada uno agrega directivas include:. Se acumula rápido.

Cómo mantenerte por debajo del límite:

• Audita tu registro SPF trimestralmente. Elimina los servicios que ya no usas.
• Usa ip4: y ip6: para IPs estáticas en vez de include: — los mecanismos IP no cuentan para el límite de lookups.
• Considera herramientas de SPF flattening si realmente necesitas más de 10 servicios (aunque esto introduce su propia carga de mantenimiento).

Errores comunes de SPF

Múltiples registros SPF. Solo puedes tener un registro TXT SPF por dominio. Si agregas un segundo, ambos son inválidos. Fusiónalos en un solo registro.

Usar +all. Esto le dice a los receptores que literalmente cualquiera puede enviar como tu dominio. Nunca hagas esto.

Olvidar los subdominios. Los registros SPF no se heredan. Si envías desde mail.yourdomain.com, necesita su propio registro SPF.

DKIM: firma tus emails

DKIM (DomainKeys Identified Mail) usa criptografía de clave pública. Tu servidor de envío firma cada mensaje saliente con una clave privada. El servidor receptor busca la clave pública en tu DNS y verifica la firma.

Si la firma es válida, el receptor sabe que el email realmente vino de tu infraestructura y no fue modificado después del envío.

El registro DNS

Los registros DKIM son registros TXT publicados en un subdominio específico:

selector._domainkey.yourdomain.com

El selector es una etiqueta elegida por tu proveedor de email. Te permite tener múltiples claves DKIM para diferentes servicios. Un registro típico se ve así:

Host: sendkit._domainkey.yourdomain.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2pmMpTj...

El valor p= es tu clave pública, codificada en base64. Será larga — a menudo 400+ caracteres para una clave de 2048 bits.

El tamaño de la clave importa

Usa claves de 2048 bits como mínimo. Algunas guías antiguas aún hacen referencia a claves de 1024 bits, pero estas se consideran débiles según los estándares actuales y algunos receptores están empezando a marcarlas. La mayoría de los proveedores, Sendkit incluido, generan claves de 2048 bits por defecto.

Cómo maneja Sendkit el DKIM

Cuando agregas un dominio en Sendkit, genera un par único de claves DKIM para ti. Obtendrás un registro CNAME para agregar a tu DNS — Sendkit aloja la clave pública, por lo que la rotación de claves ocurre automáticamente sin que tengas que tocar DNS de nuevo.

El enfoque CNAME se ve así:

Host: sendkit._domainkey.yourdomain.com
Type: CNAME
Value: sendkit._domainkey.sendkit.dev

Esto es más limpio que pegar claves públicas en bruto en registros TXT y significa que Sendkit puede rotar claves en un calendario sin romper tu configuración.

Errores comunes de DKIM

Saltos de línea en el registro TXT. Algunos proveedores de DNS no manejan bien los valores TXT largos. Si tu registro DKIM no se valida, revisa si tu proveedor dividió el valor en múltiples cadenas de forma incorrecta.

Selector incorrecto. Cada proveedor usa un selector diferente. Asegúrate de publicar la clave en el subdominio exacto que tu proveedor especifica.

No firmar todo el correo saliente. Si tienes múltiples servicios de envío y solo uno tiene DKIM configurado, los mensajes sin firmar fallarán la alineación DMARC (más sobre eso ahora).

DMARC: define tu política

DMARC (Domain-based Message Authentication, Reporting & Conformance) hace dos cosas: le dice a los receptores cómo manejar mensajes que fallan las comprobaciones SPF y DKIM, y te envía informes sobre los resultados de autenticación.

El registro DNS

Agrega un registro TXT en _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]

Los parámetros clave:

• v=DMARC1 — versión del protocolo.
• p= — la política. ¿Qué deberían hacer los receptores con los mensajes que fallan?
• rua= — a dónde enviar los informes agregados (archivos XML con estadísticas de autenticación).

Niveles de política

DMARC tiene tres niveles de política. Empieza permisivo y endurece con el tiempo:

p=none — Solo monitorear. Los mensajes que fallan aún se entregan normalmente. Recibes informes que muestran qué pasa y qué falla. Empieza aquí.

p=quarantine — Los mensajes que fallan van a spam. Pasa a esto una vez que tus informes muestren que el correo legítimo está pasando consistentemente.

p=reject — Los mensajes que fallan son rechazados directamente. Este es el objetivo. Evita que alguien haga spoofing de tu dominio.

Un cronograma de despliegue realista:

1. Despliega p=none y monitorea los informes durante 2-4 semanas.
2. Revisa los informes. Arregla cualquier remitente legítimo que no esté alineado.
3. Pasa a p=quarantine por otras 2-4 semanas.
4. Una vez limpio, cambia a p=reject.

Alineación DMARC

Aquí está la parte que la mayoría pasa por alto. DMARC no solo verifica que SPF y DKIM pasen — verifica la alineación. El dominio en el header From: debe coincidir con el dominio que pasó SPF o DKIM.

Si tu dirección From: es [email protected] pero SPF pasa para bounce.sendkit.dev, eso es un pase SPF pero un fallo de alineación DMARC. Necesitas que SPF o DKIM (o ambos) se alineen con el dominio From: para que DMARC pase.

Esta es exactamente la razón por la que DKIM importa tanto para los proveedores de email transaccional. Sendkit firma los mensajes con la clave DKIM de tu dominio, por lo que la alineación DKIM pasa incluso cuando el remitente del envelope difiere.

Un registro DMARC más completo

Una vez que hayas pasado la fase de monitoreo:

v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=s; pct=100

• ruf= — informes forenses (detalles de fallo por mensaje). No todos los proveedores envían estos.
• adkim=s — alineación estricta de DKIM (coincidencia exacta de dominio, sin subdominios).
• aspf=s — alineación estricta de SPF.
• pct=100 — aplica la política al 100% de los mensajes. Puedes ir subiendo esto gradualmente, p. ej., pct=25 para empezar.

Verifica tu configuración

No confíes en que tus cambios de DNS se propagaron correctamente. Verifica.

Usando dig

Verifica SPF:

dig +short TXT yourdomain.com | grep spf

Verifica DKIM (reemplaza sendkit con tu selector):

dig +short TXT sendkit._domainkey.yourdomain.com

Verifica DMARC:

dig +short TXT _dmarc.yourdomain.com

Usando nslookup (Windows)

nslookup -type=TXT yourdomain.com
nslookup -type=TXT sendkit._domainkey.yourdomain.com
nslookup -type=TXT _dmarc.yourdomain.com

Herramientas online

Algunas herramientas gratuitas que vale la pena guardar:

• MXToolbox (mxtoolbox.com/SuperTool) — verifica SPF, DKIM y DMARC de una sola vez.
• Google Admin Toolbox (toolbox.googleapps.com/apps/checkmx) — bueno para verificar configuración específica de Google.
• Mail Tester (mail-tester.com) — envía un email de prueba y obtén una puntuación de entregabilidad con resultados específicos de autenticación.

Envía un email de prueba real después de configurar todo. Revisa los headers sin procesar del mensaje recibido — busca los headers Authentication-Results mostrando spf=pass, dkim=pass y dmarc=pass.

Errores comunes y cómo arreglarlos

El registro SPF excede el límite de 10 lookups. Ejecuta tu SPF a través de un contador de lookups (MXToolbox hace esto). Elimina includes no usados. Aplana si es necesario.

Registro DKIM no encontrado. Revisa el nombre del selector y el subdominio exacto. La propagación DNS puede tomar hasta 48 horas, pero la mayoría de los cambios aparecen en minutos. Verifica también que tu proveedor DNS no esté truncando silenciosamente valores TXT largos.

Los informes DMARC van a un dominio diferente. Si tu dirección rua está en un dominio diferente al que publica el registro DMARC, el dominio receptor necesita un registro DNS especial para autorizarlo: yourdomain.com._report._dmarc.reportdomain.com TXT "v=DMARC1".

El correo del subdominio falla DMARC. Las políticas DMARC se aplican a subdominios vía la etiqueta sp=. Si no la configuras, los subdominios heredan la política del padre. Si envías desde notifications.yourdomain.com, asegúrate de que tenga su propio SPF y DKIM o que tu registro DMARC lo tenga en cuenta.

Usar p=reject demasiado pronto. Bloquearás emails legítimos. Siempre empieza con p=none, lee los informes, arregla los problemas de alineación y luego escala. Saltarse la fase de monitoreo es la causa más común de daño auto-infligido a la entregabilidad.

Olvidar autenticar a todos los remitentes. Audita cada servicio que envía email como tu dominio. Plataformas de marketing, herramientas de helpdesk, sistemas de facturación, alertas de monitoreo — cada uno necesita estar cubierto por SPF e idealmente firmando con DKIM con tu dominio.

Cerrando

Configurar correctamente SPF, DKIM y DMARC es una configuración única que paga permanentemente. Tus emails caen en bandejas de entrada en vez de spam. Nadie puede hacer spoofing de tu dominio. Y cumples con los requisitos de autenticación que los principales proveedores ahora hacen cumplir.

El orden importa: configura SPF primero, luego DKIM, luego DMARC en modo monitor. Date unas semanas de datos de informes antes de endurecer la política DMARC. Apurarse a p=reject sin esos datos es buscarse problemas.

Si usas Sendkit para email transaccional, la mayor parte del trabajo pesado está manejado por ti — las claves DKIM se generan y rotan automáticamente, y los registros DNS que necesitas se proporcionan en el dashboard. Solo necesitas agregarlos a tu DNS y verificar.