Configurar SPF, DKIM y DMARC para Evitar que los Correos Caigan en Spam
Guía técnica para configurar SPF, DKIM y DMARC en el DNS de tu VPS y dejar de caer en spam en Gmail y Outlook. Comandos, ejemplos y verificación real.
Los correos enviados desde una VPS recién provisionada caen en spam en Gmail y Outlook por defecto. El motivo rara vez es el contenido del mensaje — es la falta de los tres registros DNS de autenticación que los proveedores grandes esperan encontrar: SPF, DKIM y DMARC. Sin ellos, el servidor de destino trata el correo como “anónimo” y aplica la regla más restrictiva de la política antispam.
Esta guía muestra cómo configurar los tres registros desde cero en una VPS Ubuntu 24.04 LTS corriendo Postfix, con clave DKIM real generada vía OpenDKIM. El foco es dejar la configuración en producción, validada por herramientas públicas, y con política DMARC progresiva para no bloquear correos legítimos durante la transición. Tiempo estimado: 30 a 45 minutos contando la propagación DNS.
La persona aquí es el sysadmin que ya tiene Postfix instalado y enviando correos — solo que esos correos están yendo a la carpeta de spam. Si estás montando el servidor de correo desde cero, el mismo procedimiento aplica después de que Postfix esté recibiendo y enviando.
Prerrequisitos
VPS Ubuntu 24.04 LTS con acceso root vía SSH. Postfix instalado y configurado para enviar correos. Dominio propio con acceso al panel de DNS del registrador (Registro.br, Cloudflare, etc). PTR inverso ya configurado en la IP de la VPS apuntando al hostname del servidor. Puerto 25 outbound liberado en el proveedor.
Ubuntu 24.04 LTS Postfix 3.8+ OpenDKIM 2.11 25 (outbound) Antes de tocar el DNS, confirma que Postfix esté enviando mensajes. Ejecuta echo "prueba" | mail -s "prueba" [email protected] y verifica la cabecera recibida — verás spf=none, dkim=none y dmarc=none en Authentication-Results. Es exactamente eso lo que vamos a resolver.
Configurar el registro SPF
SPF (Sender Policy Framework) es el registro más simple de los tres. Dice qué servidores están autorizados a enviar correos en nombre de tu dominio. El servidor de destino consulta el registro SPF del envelope-from y lo compara con la IP que originó la conexión.
Identifica la IP pública de tu VPS:
curl -s https://api.ipify.orgAnota el valor — lo vas a usar en el registro SPF y al validar.
En el panel DNS de tu dominio, crea un registro TXT en la raíz (@ o el propio dominio) con el siguiente contenido:
v=spf1 ip4:TU.IP.AQUI.123 -allEl -all al final es un hard fail: instruye al destinatario a rechazar correos de cualquier otra IP. Si usas servicios externos (Mailgun, Google Workspace), usa include: antes del -all:
v=spf1 ip4:TU.IP.AQUI.123 include:_spf.google.com -allSi ya tienes un registro TXT que comienza con v=spf1, edita el existente — no crees otro. Múltiples registros SPF causan PermError y la autenticación falla por completo, aun con todo correcto.
Espera la propagación (generalmente 5-15 minutos) y valida:
dig +short TXT tudominio.com | grep spf1La salida debe devolver exactamente el registro que creaste.
Instalar y configurar OpenDKIM
DKIM (DomainKeys Identified Mail) firma cada correo con una clave privada almacenada en el servidor. La clave pública queda en un registro DNS — el destinatario la usa para verificar la firma. Esto protege contra la modificación del contenido en tránsito y prueba que el correo salió realmente de tu dominio.
Instala OpenDKIM y las utilidades:
sudo apt update
sudo apt install -y opendkim opendkim-toolsCrea la estructura de directorios y genera la clave de 2048 bits:
sudo mkdir -p /etc/opendkim/keys/tudominio.com
cd /etc/opendkim/keys/tudominio.com
sudo opendkim-genkey -b 2048 -d tudominio.com -s mail
sudo chown -R opendkim:opendkim /etc/opendkim
sudo chmod 600 /etc/opendkim/keys/tudominio.com/mail.privateEl comando genera dos archivos: mail.private (clave privada, queda en el servidor) y mail.txt (clave pública, va al DNS). El selector mail es arbitrario — cualquier string sirve, pero usa algo descriptivo si vas a tener múltiples selectores en el futuro.
Edita /etc/opendkim.conf con la configuración mínima funcional:
Domain tudominio.com
KeyFile /etc/opendkim/keys/tudominio.com/mail.private
Selector mail
Socket inet:8891@localhost
Mode sv
SubDomains no
AutoRestart yes
UMask 002
Syslog yesIntegra OpenDKIM con Postfix editando /etc/postfix/main.cf:
milter_protocol = 6
milter_default_action = accept
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891Reinicia ambos servicios:
sudo systemctl restart opendkim
sudo systemctl restart postfix
sudo systemctl enable opendkimObtén el contenido de la clave pública para ponerlo en el DNS:
sudo cat /etc/opendkim/keys/tudominio.com/mail.txtLa salida tiene el formato mail._domainkey IN TXT ( "v=DKIM1; ..." ). Copia solo el contenido entre comillas — todo lo que empieza en v=DKIM1; y sigue hasta el final. Algunas claves vienen partidas en dos strings entre paréntesis — concaténalas mentalmente, eliminando las comillas internas y los saltos de línea.
En el panel DNS, crea un registro TXT con:
- Nombre:
mail._domainkey - Valor: el contenido completo de la clave (
v=DKIM1; k=rsa; p=MIIBIjANBgkqh...)
Si el panel se queja de que el valor es demasiado grande (por encima de 255 caracteres), la clave necesita dividirse en strings quoted concatenadas. La mayoría de los proveedores modernos acepta pegar el valor entero y lo divide automáticamente — Cloudflare, Route53 y Registro.br lo hacen. Si el tuyo no, divídelo manualmente en trozos de 200 caracteres entre comillas, separados por espacio.
Publicar la política DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ata SPF y DKIM al nombre del dominio visible para el usuario (el From: de la cabecera) y le dice al destinatario qué hacer cuando la autenticación falla. Sin DMARC, SPF y DKIM son meramente informativos — el destinatario elige la política por su cuenta.
En el DNS, crea un registro TXT en el subdominio _dmarc:
- Nombre:
_dmarc - Valor:
v=DMARC1; p=none; rua=mailto:[email protected]; fo=1
La política p=none es el punto de partida obligatorio: recibes informes diarios por correo pero no se toma ninguna acción. Esto permite identificar fuentes legítimas que aún no están configuradas antes de subir la política.
Después de 2 a 4 semanas con p=none y los informes analizados, sube a cuarentena:
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1El pct=25 aplica la política solo al 25% de los correos que fallen — útil para detectar problemas sin impacto total. Tras 1-2 semanas más sin incidentes, sube a pct=100 y luego a p=reject.
Subir de p=none directo a p=reject antes de verificar los informes DMARC frecuentemente tira correos legítimos de sistemas terceros que firman en nombre de tu dominio (CRM, facturación, monitoreo). Los informes muestran exactamente qué IPs necesitan ser autorizadas.
Verificar la entrega real
La configuración en el DNS no garantiza que los correos lleguen a la bandeja de entrada. La verificación tiene que hacerse con mensajes reales entregados a proveedores reales.
Envía un correo de prueba a una dirección Gmail y abre el mensaje recibido. Haz clic en “Mostrar original” en el menú de Gmail y busca la sección Authentication-Results:
Authentication-Results: mx.google.com;
dkim=pass [email protected]
spf=pass [email protected]
dmarc=pass header.from=tudominio.comLos tres deben mostrar pass. Si alguno muestra fail, softfail o none, vuelve y revisa el registro correspondiente.
Usa la herramienta mail-tester.com para una evaluación completa: envía un correo a la dirección generada por la herramienta y accede al informe. La nota mínima aceptable es 9/10 — por debajo de eso hay ajustes pendientes.
Resolución de problemas comunes
DKIM pasa en pruebas pero falla en Gmail
Casi siempre es una discrepancia entre el selector configurado en OpenDKIM y el publicado en el DNS. Confirma con dig +short TXT mail._domainkey.tudominio.com — el valor devuelto debe coincidir exactamente con el contenido de mail.txt. Otro motivo frecuente: la clave fue pegada con saltos de línea que el panel DNS no eliminó.
SPF devuelve PermError
Indica múltiples registros TXT comenzando con v=spf1 en el mismo dominio. Lista con dig +short TXT tudominio.com y elimina duplicados consolidando todo en un único registro.
Los correos siguen cayendo en spam aunque todo pase
Verifica la reputación de la IP en mxtoolbox.com/blacklists.aspx. Las IPs nuevas o recién salidas de blacklist necesitan calentamiento — empieza con volumen bajo (5-10 correos/día a contactos engaged) y sube gradualmente a lo largo de 4-6 semanas.
Próximos pasos
- Configura informes DMARC agregados en un parser dedicado (postmark, dmarcian) para visualizar fuentes no autorizadas de forma estructurada
- Agrega un selector DKIM secundario rotativo cada 6 meses para mantener higiene criptográfica
- Implementa MTA-STS y TLS Reporting para garantizar entrega vía TLS estricto en proveedores compatibles
- Configura BIMI después de que
p=quarantineop=rejectesté estable por 30+ días — muestra tu logo en la bandeja de entrada de Gmail y Yahoo
Si estás poniendo correo transaccional en producción, una VPS Hostini ya viene con PTR inverso editable desde el panel y puerto 25 liberado por defecto — dos barreras comunes que las VPS de otros proveedores dejan cerradas.
Preguntas frecuentes
¿Puedo tener más de un registro SPF para el mismo dominio?
No. La RFC 7208 prohíbe múltiples registros TXT que comiencen con v=spf1 en el mismo dominio — los proveedores lo tratan como PermError y todo el SPF falla. Si necesitas autorizar varias fuentes (VPS propia + Mailgun + Google Workspace), únelo todo en un único registro con varios mecanismos include.
¿Cuál es el tamaño ideal de la clave DKIM, 1024 o 2048 bits?
2048 bits es el estándar actual y lo que Gmail y Yahoo exigen desde 2024 para remitentes que envían más de 5 mil correos por día. Las claves de 1024 todavía funcionan técnicamente, pero se consideran débiles. La única limitación práctica es que algunos proveedores DNS truncan registros TXT por encima de 255 caracteres — casi todos hoy aceptan quoted strings concatenadas, así que no hay motivo para quedarse en 1024.
¿Cuánto tarda DMARC en empezar a impactar la entrega?
El registro DNS propaga en minutos a algunas horas, pero el efecto real depende de la política. Con p=none solo recibes informes — nada cambia en la entrega. Con p=quarantine o p=reject, los proveedores empiezan a aplicar inmediatamente después de leer el registro. Se recomienda correr p=none durante 2 a 4 semanas antes de subir a quarantine, para analizar los informes y descubrir todas las fuentes legítimas que envían por tu dominio.
¿Necesito PTR inverso configurado en la IP de la VPS?
Sí. Gmail, Outlook y la mayoría de los antispam corporativos rechazan o marcan como spam correos provenientes de IPs sin PTR válido, o con PTR genérico del proveedor (tipo 187-45-x-x.cloud.proveedor.com). El PTR debe resolver a un hostname que apunte de vuelta a la misma IP (forward-confirmed reverse DNS). En VPS de Hostini configuras el PTR desde el panel.
¿Por qué mis correos caen en spam aun con SPF, DKIM y DMARC todos pasando?
Autenticación no es reputación. Si la IP de la VPS es nueva o ya fue usada para spam antes, los proveedores empiezan desconfiando independientemente de la configuración DNS. Verifica la IP en mxtoolbox.com/blacklists.aspx, haz calentamiento gradual del volumen (pocos correos por día subiendo lentamente) y mantén la tasa de bounce baja. El contenido del correo también cuenta — adjuntos sospechosos, enlaces acortados y exceso de imágenes perjudican.
¿DMARC con p=reject rompe los correos reenviados (forward)?
Puede romperse cuando el servidor que reenvía modifica headers o el envelope sin volver a firmar con DKIM. SPF casi siempre falla en forward (la IP del servidor que reenvió no está autorizada en el dominio original). DMARC pasa si DKIM pasa, así que mantén la clave DKIM fuerte. Para listas de discusión que reescriben el From, configura ARC o acepta que parte del tráfico será afectada.