Entregabilidad de correo: Mensajes en spam — soluciones reales (SPF/DKIM/DMARC bien hechos)

enero 16, 2026 • febrero 3, 2026 • Lectura: 27 min • Views: 9

¿Te fue útil?

Enviaste el correo. Los registros SMTP dicen “250 2.0.0 OK”. Tu aplicación lo marca como “entregado”. El equipo de ventas sigue jurando que el cliente nunca lo recibió. Y cuando pides una captura de pantalla, está ahí—en la carpeta de spam—sentado entre una factura falsa y una oferta de “el CEO quiere tarjetas regalo”.

Esto no es un misterio. Es un problema de ingeniería con un sistema de reputación adjunto. SPF/DKIM/DMARC son requisitos básicos, pero la mayoría de los equipos los configuran como una casilla para marcar y luego se sorprenden cuando Gmail también los trata como una casilla.

Protocolo de diagnóstico rápido

Si estás de guardia y tu CEO acaba de reenviar “¿por qué estamos en spam?” a todo el hilo, no empieces reescribiendo tu registro SPF de memoria. Triajea como un SRE: identifica el cuello de botella rápido y luego afina.

Primero: confirma lo que vio el receptor

Obtén la fuente completa del mensaje desde el buzón del destinatario (los encabezados importan más que tus logs).
Busca Authentication-Results y encabezados Received. Te dicen los resultados de SPF/DKIM/DMARC tal como los evaluó el receptor: el único veredicto que cuenta.
Comprueba qué dominio está en el From visible: y qué dominio está en el Return-Path (dirección de rebote). DMARC es un juego de alineación.

Segundo: identifica el modo de fallo

¿SPF fail/softfail/permerror? Usualmente DNS, demasiadas búsquedas, o la IP emisora incorrecta.
¿DKIM fail? Generalmente selector incorrecto, canonicalización rota por reescritura, o la clave pública publicada es la equivocada.
¿DMARC fail? Suele ser alineación (el dominio en From no se alinea con el dominio autenticado por SPF o DKIM), o mala configuración de política/reportes.
¿Todo pasa pero sigue en spam? Entonces entras en territorio de reputación/contenido/engagement, o estás golpeando throttling/greylisting y llegando “raro”.

Tercero: comprueba tu higiene de identidad y transporte

Reverse DNS (PTR) para la IP emisora debe existir y verse sensato.
El nombre HELO/EHLO debería coincidir con un hostname válido que resuelva hacia adelante y, idealmente, alinearse con el PTR.
TLS y cifrado no son magia para la entregabilidad, pero una negociación STARTTLS rota es un olor de falta de confianza.
Rebotes y tasas de queja son tu “presión arterial”. Si están altas, ningún yoga DNS te salva.

Después: elige la vía de corrección más corta

Si SPF está roto: arregla SPF sin causar desalineación DMARC.
Si DKIM está roto: corrige la publicación del selector/clave y luego firma en el último salto de salida.
Si la alineación DMARC está rota: decide si la alineación principal será SPF o DKIM; diseña en consecuencia.
Si todo autentica: trabaja en reputación e higiene de listas; deja de enviar masivamente a listas frías desde un dominio nuevo.

Idea parafraseada de Werner Vogels: “Todo falla; construye sistemas que asuman eso y se recuperen rápido.” La entregabilidad de correo es exactamente eso, excepto que la falla es silenciosa y tus clientes no abren tickets—simplemente no compran.

Cómo deciden realmente los filtros de spam (más allá de SPF/DKIM/DMARC)

SPF, DKIM y DMARC responden a una pregunta: “¿Este mensaje está plausiblemente autorizado por el dominio en el encabezado From?” No responden: “¿Este mensaje es deseado?”

Los proveedores modernos de buzón ejecutan un sistema de puntuación por capas. Parte de ello son reglas. Mucho es reputación. Gran parte es “retroalimentación de usuario sin decírtelo”, como cuando los usuarios borran tu correo sin leerlo o lo marcan como spam. La verdad incómoda: la entregabilidad es una característica de producto que se gana y mantiene, no un fragmento de configuración.

Las señales que importan en la práctica

Autenticación + alineación: pasar SPF/DKIM no es suficiente; la alineación DMARC es el portero para muchas bandejas de entrada.
Consistencia de la infraestructura de envío: IPs estables, HELO consistente, dominios consistentes en el envelope sender.
Tasas de queja: si la gente pulsa “spam”, estás acabado por un tiempo. Los proveedores no discuten. Te limitan o te mandan a basura.
Higiene de listas: las listas viejas se pudren. Existen trampas de spam. Los rebotes duros no son “tristeza temporal”, son un impuesto a la reputación.
Patrones de contenido: lenguaje similar al phishing, HTML roto, acortadores de enlaces, texto visible que no coincide con la URL, codificaciones raras.
Engagement: aperturas y clics son imperfectos, pero “leer vs borrar” y “mover a la bandeja principal” son señales fuertes.

Dos realidades para interiorizar:

Los receptores confían en dominios e IPs, no en tus intenciones.
Los receptores optimizan por la seguridad del usuario, no por tu embudo de conversión.

Hechos interesantes y breve historia

SMTP es anterior a los filtros de spam: los protocolos de correo originales asumían usuarios cooperativos en una red amistosa. Internet no estuvo de acuerdo.
SPF nació como respuesta a remitentes de sobre falsificados: verifica el dominio en el Return-Path (MAIL FROM) por defecto, no el From visible.
DKIM surgió de experimentos de firmado de dominio en Yahoo y otros: se diseñó para sobrevivir el tránsito y demostrar que un dominio asumía responsabilidad por el contenido.
DMARC es relativamente joven: estandarizó el requisito de “alineación” que SPF y DKIM no imponían por sí solos.
“p=reject” no se volvió mainstream de la noche a la mañana: las grandes marcas hicieron rampa de none → quarantine → reject durante meses porque la desalineación rompe flujos legítimos.
Las listas de correo rompen DKIM con fama: pies de página y etiquetas de asunto modifican contenido firmado; la canonicalización ayuda, pero no siempre.
SPF tiene un límite duro de búsquedas DNS (10): si lo excedes puedes obtener permerror—la autenticación falla incluso si tu IP está autorizada en espíritu.
ARC existe porque el reenvío rompe la autenticación: es un mecanismo de cadena de custodia para “esto pasó cuando yo lo recibí”.
Los principales proveedores requieren cada vez más autenticación: con el tiempo, “sin SPF/DKIM/DMARC” pasó de “sospechoso” a “no entregable a escala”.

SPF, DKIM, DMARC: bien hechos (y alineados)

SPF: tus emisores permitidos, con aristas afiladas

SPF es un registro TXT en DNS que dice qué IPs (o qué otros registros SPF) están autorizados para enviar por un dominio. Los receptores lo evalúan contra el dominio del remitente del sobre (Return-Path / MAIL FROM) o, a veces, contra el dominio HELO.

Guía operativa:

Mantén SPF simple. Menos includes, menos búsquedas, menos sorpresas.
No uses “+all”. Eso no es “permisivo”, es “por favor suplantadme”.
Usa “~all” sólo durante migraciones. Softfail es una rueda de aprendizaje; eventualmente necesitas “-all”.
Controla tu dominio de rebote (Return-Path). Si envías mediante un proveedor pero quieres alineación DMARC, planifícalo.

DKIM: responsabilidad criptográfica, si no la rompes

DKIM firma partes del mensaje (encabezados y cuerpo) con una clave privada. La clave pública vive en DNS bajo un selector. Los receptores verifican la firma. DKIM te da una identidad estable incluso cuando las IPs cambian—siempre que la firma sobreviva las modificaciones intermedias.

Guía operativa:

Firma en el último salto de salida. Si un MTA intermedio reescribe contenido después de firmar, acabas de firmar una falsedad.
Rota selectores. No a diario. Pero trata las claves como credenciales con ciclo de vida.
Firma los encabezados correctos: From, Date, Subject, Message-ID son comunes. Evita firmar en exceso encabezados frágiles que puedan ser reescritos.
Usa claves de 2048 bits cuando sea posible. Algunos receptores tratan claves más cortas como señales débiles.

DMARC: alineación, política y la parte que no puedes falsificar

DMARC lo unifica. Dice a los receptores: si SPF y/o DKIM autentican, ¿se alinean con el dominio en el encabezado From visible? ¿Y qué debe hacer el receptor si la alineación falla?

Puntos clave que los equipos suelen pasar por alto:

DMARC trata sobre el From visible: el dominio que ven las personas. Eso es lo que los phishers falsifican.
La alineación es todo el juego: SPF puede pasar para un dominio mientras From es otro. DMARC seguirá fallando.
La política no es aplicación a menos que lo quieras: “p=none” es telemetría, no protección, y los proveedores pueden ignorarlo como “no serio”.
Los subdominios importan: decide si usas alineación con el dominio organizacional y cuán estricta la quieres (“adkim=s”, “aspf=s”).

Broma #1: SPF es como una lista de invitados. DKIM es como una pulsera. DMARC es el portero que comprueba si la pulsera coincide con el nombre en la entrada.

Tareas prácticas: comandos, salidas y decisiones

Esta sección es la parte que realmente ejecutas. Cada tarea incluye: un comando, cómo luce una salida realista, qué significa y la decisión que tomas.

Task 1: Pull the SPF TXT record and spot obvious footguns

cr0x@server:~$ dig +short TXT example.com
"v=spf1 ip4:198.51.100.10 include:_spf.vendor-mail.net ~all"

Qué significa: SPF existe. Autoriza una IPv4 y un include de proveedor. Termina con softfail (~all).

Decisión: Si ya terminaste la migración, cambia a -all. Si aún estás descubriendo emisores, mantén ~all brevemente, pero programa una fecha límite.

Task 2: Check SPF lookup count (the 10-DNS-lookup trap)

cr0x@server:~$ spfquery -m example.com -ip 198.51.100.10 -sender bounce@example.com -helo mail.example.com
pass (mechanism 'ip4:198.51.100.10' matched)
dns-lookup-count=7

Qué significa: SPF pasa para esta IP y se mantiene por debajo del límite de 10 búsquedas.

Decisión: Si el conteo de búsquedas está cerca de 10, aplana SPF (reduce includes anidados). Si está por encima de 10, arréglalo antes que cualquier otra cosa; permerror es un asesino de entregabilidad.

Task 3: Verify that your sending IP matches what the receiver sees

cr0x@server:~$ grep -E "postfix/smtp|status=sent" /var/log/mail.log | tail -n 2
Jan 03 10:12:08 mx1 postfix/smtp[21901]: 2F1C81234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.26]:25, delay=1.2, delays=0.1/0/0.4/0.7, dsn=2.0.0, status=sent (250 2.0.0 OK  1704276728 a1e2b3c4d5e6-200si1234567qkb.123 - gsmtp)
Jan 03 10:12:08 mx1 postfix/qmgr[1123]: 2F1C81234: removed

Qué significa: Entregaste al MX de Gmail. Pero esto no prueba la IP de origen usada externamente (existen NAT y relays).

Decisión: Confirma la IP de salida desde el servidor o mediante los encabezados en el receptor. Si envías a través de un smart host, SPF debe autorizar al smart host, no al servidor de la app.

Task 4: Confirm egress IP from the sending host

cr0x@server:~$ curl -s https://ifconfig.me
198.51.100.10

Qué significa: La IP pública aparente de este host es 198.51.100.10.

Decisión: Asegúrate de que esta IP esté en SPF y tenga PTR. Si esperabas otra IP, puede que estés en un pool NAT compartido—malo para aislar reputación.

Task 5: Check reverse DNS (PTR) for your sending IP

cr0x@server:~$ dig +short -x 198.51.100.10
mail.example.com.

Qué significa: PTR existe y apunta a mail.example.com.

Decisión: Si no hay PTR, arréglalo primero. Si PTR apunta a un default del ISP como static-10-100-51-198.isp.net, considera cambiarlo; una identidad inconsistente es un olor de confianza baja.

Task 6: Check forward DNS for the PTR hostname (FCrDNS sanity)

cr0x@server:~$ dig +short A mail.example.com
198.51.100.10

Qué significa: La resolución hacia adelante vuelve a la misma IP. A muchos receptores les gusta esta consistencia.

Decisión: Si la resolución hacia adelante no coincide, corrige DNS. Si no puedes (restricciones del proveedor cloud), usa su mapeo rDNS soportado o mueve el correo saliente a otro lugar.

Task 7: Validate the DKIM public key exists for a selector

cr0x@server:~$ dig +short TXT s2026._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtYx...snip...QIDAQAB"

Qué significa: El selector s2026 está publicado. Bien.

Decisión: Si falta, DKIM fallará. Si ves múltiples cadenas TXT por splitting en DNS, asegúrate de que se concatenen correctamente (algunos sistemas no lo manejan bien).

Task 8: Send a test message and inspect Authentication-Results

cr0x@server:~$ swaks --to you@outlook.com --from alerts@example.com --server mail.example.com --tls --header "Subject: auth test" --body "test"
=== Trying mail.example.com:25...
=== Connected to mail.example.com.
=== TLS started with cipher TLS_AES_256_GCM_SHA384
<** snip **>
<-  250 2.0.0 Ok: queued as 1234ABCD

Qué significa: El mensaje fue aceptado por tu servidor para entrega saliente. Ahora necesitas los encabezados recibidos en Outlook.

Decisión: Extrae la fuente del mensaje desde el buzón y lee los Authentication-Results. Ahí vive el veredicto real.

Task 9: Parse headers locally (quick and dirty)

cr0x@server:~$ sed -n '1,80p' message.eml
Authentication-Results: mx.microsoft.com;
 spf=pass (sender IP is 198.51.100.10) smtp.mailfrom=example.com;
 dkim=pass (signature was verified) header.d=example.com;
 dmarc=pass action=none header.from=example.com
Received: from mail.example.com (mail.example.com [198.51.100.10])
 by NAM11-MW2-obe.outbound.protection.outlook.com with ESMTPS id 123...
From: alerts@example.com
Return-Path: <bounce@example.com>

Qué significa: SPF, DKIM, DMARC pasan y se alinean (header.from es example.com; smtp.mailfrom es example.com; DKIM d=example.com).

Decisión: Si aún caes en spam con todo pasando, deja de retocar DNS y comienza a investigar reputación, contenido y engagement.

Task 10: Detect DMARC alignment failure (the common “everything passes but DMARC fails” trap)

cr0x@server:~$ grep -E "Authentication-Results|From:|Return-Path:" -n message.eml | head -n 20
1:Authentication-Results: mx.google.com;
2: spf=pass (google.com: domain of bounce@vendor-mail.net designates 203.0.113.44 as permitted sender) smtp.mailfrom=bounce@vendor-mail.net;
3: dkim=pass header.d=vendor-mail.net;
4: dmarc=fail (p=quarantine sp=quarantine dis=none) header.from=example.com
12:From: Billing <billing@example.com>
13:Return-Path: <bounce@vendor-mail.net>

Qué significa: SPF y DKIM pasan, pero para vendor-mail.net. DMARC evalúa alineación contra example.com en el From visible. La alineación falla; DMARC falla.

Decisión: O configura al proveedor para firmar con d=example.com (preferido), o usa una funcionalidad del proveedor para usar un dominio de rebote personalizado alineado a example.com, o cambia el From a un dominio que controles y que se alinee con la identidad autenticada.

Task 11: Check your DMARC record

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=quarantine; rua=mailto:dmarc-rua@example.com; ruf=mailto:dmarc-ruf@example.com; adkim=s; aspf=s; fo=1; pct=100"

Qué significa: DMARC existe, política de quarantine, alineación estricta para DKIM y SPF.

Decisión: La alineación estricta está bien si tus sistemas son disciplinados. Si tienes muchos emisores de terceros y aún estás estabilizando, considera relajar a adkim=r; aspf=r mientras solucionas la alineación. No lo dejes relajado para siempre.

Task 12: Confirm you publish a working MX and you’re not accidentally “parked”

cr0x@server:~$ dig +short MX example.com
10 mx1.example.com.
20 mx2.example.com.

Qué significa: El dominio tiene registros MX; no es una zona muerta.

Decisión: MX faltantes o raros pueden afectar la percepción y el manejo de rebotes. Asegúrate de que puedas recibir rebotes como mínimo.

Task 13: Check your SPF for multiple TXT records (silent breakage)

cr0x@server:~$ dig TXT example.com +noall +answer
example.com. 3600 IN TXT "v=spf1 ip4:198.51.100.10 -all"
example.com. 3600 IN TXT "google-site-verification=abc123"

Qué significa: Esto está bien: un registro SPF más un TXT no relacionado.

Decisión: Si ves dos registros SPF (dos TXT que empiezan con v=spf1), la evaluación SPF se vuelve permerror. Fusiónalos. No “añadas otro más”.

Task 14: Confirm Postfix is presenting a sane HELO name

cr0x@server:~$ postconf -n | grep -E "myhostname|smtp_helo_name"
myhostname = mail.example.com
smtp_helo_name = mail.example.com

Qué significa: HELO es consistente con el hostname.

Decisión: Si HELO es algo como localhost o un nombre interno, arréglalo. Muchos receptores puntúan eso como “energía de botnet”.

Task 15: Make sure you’re not an open relay (yes, still happens)

cr0x@server:~$ swaks --server mail.example.com --to victim@external.com --from attacker@external.com --auth-user bogus --auth-password bogus
=== Trying mail.example.com:25...
<-  220 mail.example.com ESMTP Postfix
-> EHLO test
<-  250-mail.example.com
-> MAIL FROM:<attacker@external.com>
<-  554 5.7.1 <attacker@external.com>: Relay access denied

Qué significa: Relay denegado. Bien.

Decisión: Si esto tiene éxito sin autenticación desde Internet, serás incluido en listas negras antes del almuerzo. Restringe el relay inmediatamente.

Task 16: Spot greylisting/throttling in logs

cr0x@server:~$ grep -iE "deferred|throttl|try again|4\.7\." /var/log/mail.log | tail -n 5
Jan 03 10:18:22 mx1 postfix/smtp[22555]: 9ABCD1234: to=<user@gmail.com>, relay=gmail-smtp-in.l.google.com[142.250.102.27]:25, delay=120, delays=0.1/0/110/9.9, dsn=4.7.0, status=deferred (host gmail-smtp-in.l.google.com[142.250.102.27] said: 421 4.7.0 Temporary System Problem. Try again later (in reply to end of DATA command))

Qué significa: Diferimiento temporal. Puede que te estén limitando o que estés alcanzando límites de reputación, especialmente desde IPs/dominios nuevos.

Decisión: Reduce velocidad de envío, calienta las IPs, disminuye la concurrencia y mejora la higiene de listas. Trata patrones 4xx como “el receptor no confía en ti todavía”, no como “fallo de red”.

Reenvío, listas de correo y ARC: donde el buen correo muere

El reenvío de correo es la casa encantada de la entregabilidad. Un mensaje que pasa SPF y DKIM en el receptor original puede fallar corriente abajo después del reenvío porque:

SPF falla: el reenviador envía desde su propia IP, que no está autorizada en el SPF del dominio original.
DKIM se rompe: el reenviador o la lista modifica el cuerpo o los encabezados (añade pies de página, cambia MIME, reescribe asunto).
DMARC falla: la alineación no puede cumplirse si tanto SPF como DKIM ya no validan para el dominio From.

ARC (Authenticated Received Chain) existe para añadir una “cadena de custodia”. Un reenviador puede decir: “Cuando recibí este mensaje, SPF/DKIM/DMARC pasaron.” Los receptores pueden usar eso como señal de confianza. No todos los receptores ponderan ARC por igual, pero ayuda en la zona intermedia donde el reenvío legítimo es común.

Qué deberías hacer:

Si operas infraestructura de reenvío, considera implementar firmado ARC.
Si dependes de listas de correo, sé realista: políticas DMARC como p=reject pueden causar problemas de entrega en listas a menos que la lista reescriba el From o soporte mitigaciones DMARC.
Para correo transaccional, evita rutas que reescriban contenido después de la firma DKIM. Firma al final.

Reputación: IP, dominio, contenido y señales de engagement

Una vez que la autenticación es correcta y está alineada, la entregabilidad se convierte en un trabajo lento de construcción de confianza.

Reputación de IP: el vecindario importa

Una IP dedicada te da control sobre tu propia reputación. Una IP compartida implica que heredas el comportamiento de extraños. A veces los extraños están bien. A veces son un proyecto de arte performativo sobre ignorar enlaces de baja prioridad.

Guía práctica:

Calienta IPs nuevas: comienza con bajo volumen, escala gradualmente y prioriza destinatarios comprometidos.
Separa tipos de tráfico: transaccional y marketing no deberían compartir identidad si puedes evitarlo. Cuando marketing recibe quejas, lo transaccional no debería pagar por ello.
Sé consistente: picos súbitos, nuevos hosts de envío y cambios en remitentes de sobre se ven como compromiso.

Reputación de dominio: lenta de ganar, rápida de perder

La reputación de dominio sigue a tu dominio From, tu dominio de firma DKIM y a veces a tus dominios de enlaces. Si rotas dominios para evadir filtros, estás enseñando a los proveedores que te comportas como spammers. No se impresionan con tu creatividad.

Contenido: no es “evitar palabras de spam”, sino evitar comportamiento de spam

Los filtros no solo buscan palabras clave como “dinero gratis”. Buscan patrones correlacionados con abuso:

Acortadores de enlaces y cadenas de redirección
Texto visible que no coincide con el destino real del enlace
Emails basados fuertemente en imágenes con poco texto
HTML malformado y estructuras MIME extrañas
Adjuntos de identidades desconocidas (especialmente ejecutables, documentos con macros o archivos comprimidos inesperados)

Engagement: la parte que tu stack de marketing rara vez te cuenta con veracidad

La “tasa de apertura” se degrada por protecciones de privacidad y proxies de imágenes. Pero los proveedores aún tienen señales de engagement que no ves: tiempo de lectura, comportamiento de respuesta, mover mensajes fuera de spam y eliminar sin leer.

Implicación para ingeniería: deja de enviar a personas que no interactúan. Estás pagando por envenenar tu propia reputación.

Broma #2: Si sigues enviando a gente que nunca abre, el proveedor de buzón asume que eres o un spammer o un optimista. Ninguno es una clase protegida.

Tres mini-historias corporativas desde el frente

Mini-historia 1: El incidente causado por una suposición errónea

La compañía: SaaS mediana, crecimiento estable, un flujo de correo saliente para todo—restablecimientos de contraseña, facturas y boletines semanales. Migraron los envíos de marketing a un proveedor nuevo para “mejorar la entregabilidad”. El plan de migración fue, con benevolencia, una invitación de calendario.

La suposición errónea fue simple: “Si SPF y DKIM pasan, DMARC también pasará.” El proveedor ofreció un include SPF y firmado DKIM para vendor-mail.net. El equipo mantuvo su From visible como billing@example.com, porque la consistencia de marca es sagrada.

En horas, las facturas empezaron a caer en spam para un subconjunto de clientes—principalmente clientes empresariales con filtros más estrictos y aplicación de DMARC. Llegaron tickets de soporte en goteo. Finanzas escaló. El SRE de guardia miró los logs de Postfix y vio 250s limpios, que es el equivalente en email de “funciona en mi máquina”.

El avance vino al extraer los encabezados crudos del buzón de un cliente. Authentication-Results mostraba SPF=pass, DKIM=pass, DMARC=fail. La política DMARC en example.com era p=quarantine con alineación estricta. SPF autenticó vendor-mail.net (dominio del Return-Path), DKIM autenticó vendor-mail.net (d=), y ninguno se alineó con el From example.com.

La solución no fue “relajar DMARC porque está rompiendo cosas.” La solución fue configurar al proveedor para usar un DKIM personalizado con d=example.com y un dominio de rebote personalizado bajo example.com para que la alineación SPF también funcionara. Lo implementaron emisor por emisor, verificaron alineación en encabezados y luego aumentaron el tráfico. La entregabilidad se recuperó. Finanzas dejó de pasear.

Mini-historia 2: La optimización que salió mal

La compañía: plataforma B2C con picos estacionales. Gestionaban su propia flota MTA y querían reducir costes. Alguien notó que el tráfico saliente era “explosivo” y propuso consolidar a menos servidores con más throughput, apoyado por una nueva puerta NAT brillante. Genial: menos instancias, ops más simples, factura más baja.

El revés: la reputación de IP colapsó. Antes, el correo saliente salía desde varias IPs estáticas con PTRs estables. Tras la consolidación, el correo salía por un pool NAT que cambiaba durante eventos de escalado. SPF seguía autorizando al relay, DKIM seguía pasando, DMARC seguía pasando. Y sin embargo la colocación en spam aumentó y los diferimientos se dispararon.

El equipo persiguió cambios de contenido, luego reintentó “calentamiento” (sin controlar qué IP se calentaba). Añadieron más reintentos (lo que aumentó el volumen durante el throttling), y eso empeoró los diferimientos. Bucle de realimentación positiva clásico, excepto que el resultado es “todo el correo llega tarde y sospechoso”.

La resolución requirió admitir que la optimización era el problema. Movieron el correo saliente de vuelta a un pequeño conjunto de IPs de egreso dedicadas y estables con PTR y HELO consistentes, y controlaron la concurrencia. Los costes subieron un poco. La entregabilidad y la latencia mejoraron dramáticamente. La lección quedó: el email es un sistema de reputación; la imprevisibilidad es cara.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

La compañía: vendedor de software empresarial. Tenían varios equipos enviando correo: notificaciones de producto, mesa de soporte y marketing. Hace años, alguien con gusto por la “gobernanza” insistió en un inventario central de identidades de correo: cada emisor, cada dominio, cada proveedor, cada selector DKIM y los mecanismos SPF exactos requeridos. Vivía en control de versiones. La gente se quejaba.

Luego un proveedor sufrió una brecha y seguridad preguntó: “¿Estamos usando alguno de estos emisores?” Lo estaban. Peor, ese proveedor podía enviar con un From que parecía pertenecer a la compañía, porque la integración se configuró de forma laxa durante un proyecto apresurado.

Como tenían el inventario, identificaron rápido qué flujos usaban al proveedor, qué dominios estaban afectados y cuál era la postura de autenticación. Endurecieron DMARC en un subdominio usado solo para marketing de terceros, aplicaron alineación estricta para el correo transaccional central y rotaron selectores DKIM donde correspondía.

La entregabilidad no sufrió con los cambios porque los desplegaron con cuidado, comprobaron encabezados para alineación y evitaron cambios de alto riesgo durante picos de envío. La práctica “aburrida”—propiedad documentada y cambios DNS controlados—les permitió actuar rápido sin adivinar. Nadie escribió un postmortem heroico. Ese es el punto.

Errores comunes: síntoma → causa raíz → solución

1) “SPF pass, DKIM pass, aún así DMARC fail”

Síntoma: Authentication-Results muestra spf=pass, dkim=pass, pero dmarc=fail.

Causa raíz: Desalineación. SPF autenticó el dominio del Return-Path (a menudo un dominio de proveedor). DKIM autenticó d=vendor. From es tu dominio.

Solución: Configura un dominio de rebote personalizado bajo tu dominio para la alineación SPF y/o firma DKIM con d=yourdomain. Verifica la alineación en los encabezados.

2) “SPF permerror”

Síntoma: Resultado SPF es permerror, o los receptores lo tratan como fallo.

Causa raíz: Más de 10 búsquedas DNS debido a includes anidados, redirecciones o macros; o múltiples registros SPF.

Solución: Aplana SPF. Elimina includes redundantes. Fusiona a exactamente un registro SPF. Mantén el conteo de búsquedas cómodamente por debajo de 10.

3) “DKIM falla solo en algunos proveedores”

Síntoma: DKIM pasa en un proveedor de buzón pero falla en otro, o pasa a veces.

Causa raíz: Inconsistencias en propagación DNS, splitting de TXT roto, o modificación intermedia después de firmar (pies de listas, gateways de seguridad, reescrituras de CRM).

Solución: Asegura que DNS devuelva una clave estable en todas partes. Firma en el último salto de salida. Evita reescribir partes firmadas. Considera canonicalización relajada, pero no la uses como parche para reescrituras masivas.

4) “Todo pasa; aún así spam”

Síntoma: SPF/DKIM/DMARC pasan y se alinean, pero la colocación en bandeja es pobre.

Causa raíz: Reputación o engagement. Alta tasa de quejas, enviar a listas obsoletas, mal targeting, problemas de IP compartida, o picos de volumen repentinos.

Solución: Mejora higiene de listas, reduce volumen, calienta correctamente, segmenta transaccional vs marketing y deja de enviar a no comprometidos. Arregla el comportamiento del negocio, no el DNS.

5) “Mensajes desaparecen, sin rebote”

Síntoma: Logs del remitente muestran aceptación, pero los destinatarios nunca ven el mensaje (ni siquiera en spam), y no llega ningún NDR.

Causa raíz: Filtrado silencioso en el receptor, a menudo por problemas graves de reputación o bloqueos de política; o estás enviando a un sumidero (dominio con error tipográfico, buzón inválido) con comportamiento no estándar.

Solución: Usa cuentas semilla en varios proveedores para capturar encabezados y colocación. Reduce volumen, arregla autenticación/alineación y atiende la reputación. Asegura que los rebotes se enruten y procesen correctamente.

6) “El correo reenviado falla DMARC”

Síntoma: Correo enviado a un reenviador (o lista) termina rechazado o marcado como spam corriente abajo.

Causa raíz: SPF se rompe en el reenvío, DKIM se rompe con la modificación; DMARC falla.

Solución: Para tu propio reenvío, implementa ARC y evita romper DKIM. Para listas de correo, usa comportamientos amigables con DMARC (reescritura de From u otras mitigaciones) si las controlas.

Listas de verificación / plan paso a paso

Checklist A: Estabilizar autenticación y alineación (el plan “detener la hemorragia”)

Elige la identidad que realmente quieres: decide el dominio From canónico para transaccional vs marketing.
Inventario todos los emisores: servidores de app, sistemas de tickets, CRMs, plataformas de marketing, herramientas de monitorización.
Asegura un registro SPF por dominio y mantiene el conteo de búsquedas por debajo de 10.
Asegura firmado DKIM para cada flujo, preferiblemente con d= que coincida con tu dominio From (o subdominio alineado).
Despliega DMARC con telemetría primero: comienza con p=none solo el tiempo suficiente para recopilar la realidad.
Corrige fallos de alineación para cada emisor: dominios de rebote personalizados, dominios de firma DKIM personalizados o ajusta los dominios From.
Pasa a aplicación: p=quarantine, luego p=reject una vez estés seguro.
Bloquea la estrategia de subdominios: separa subdominios para marketing vs transaccional, con políticas a medida.

Checklist B: Higiene de transporte e identidad (el plan “parece un sistema de correo real”)

Establece IPs salientes estables cuando sea posible; evita pools NAT para la identidad principal de correo.
Configura PTR que coincida con tu hostname de correo; asegúrate de que el DNS hacia adelante coincida con la IP.
Configura HELO/EHLO a un hostname válido y manténlo consistente entre MTAs.
Ofrece STARTTLS correctamente; evita configuraciones TLS rotas que provoquen patrones de fallback.
Maneja rebotes: procesa DSNs, elimina rebotes duros e investiga picos.
Mantén colas de salida saludables; retrasos largos pueden disparar sospechas y quejas de usuarios (“tu correo llegó dos días tarde”).

Checklist C: Reputación y gestión de volumen (el plan “ganar confianza”)

Segmenta el tráfico: transaccional en su propia identidad y rango de IPs si puedes.
Calienta: incrementa volumen gradualmente; empieza con tus destinatarios más comprometidos.
Higiene de listas: elimina rebotes duros inmediatamente; aparta a no comprometidos.
Unsubscribe que funcione: hazlo fácil; un unsubscribe roto alimenta quejas.
Sanidad del contenido: plantillas consistentes, mínimas redirecciones de enlaces, MIME correcto y evita patrones de adjuntos sospechosos.
Mide la colocación: buzones semilla, captura encabezados, rastrea spam vs bandeja en proveedores.

Preguntas frecuentes

1) Si SPF, DKIM y DMARC son correctos, ¿por qué sigo en spam?

Porque la autenticación prueba identidad, no deseabilidad. La colocación en spam puede estar determinada por reputación (dominio/IP), tasas de queja, higiene de listas, picos de volumen y patrones de contenido.

2) ¿Debería usar DMARC p=reject de inmediato?

No, salvo que ya conozcas todos los emisores legítimos y estén alineados. Comienza con p=none brevemente para ver quién envía, corrige alineación y luego pasa a quarantine y reject.

3) ¿Qué significa realmente la alineación DMARC?

Significa que el dominio en el encabezado From visible coincide (o es subdominio, según la estricticidad) con el dominio autenticado por SPF (MAIL FROM) y/o DKIM (d=).

4) ¿Es SPF o DKIM más importante para DMARC?

DKIM suele ser más fiable porque sobrevive cambios de IP y puede sobrevivir cierto reenvío. SPF es más simple pero se rompe con el reenvío. En la práctica, apunta a ambos y asegura que al menos uno se alinee.

5) ¿Por qué el reenvío rompe SPF?

SPF comprueba si la IP emisora está autorizada para el dominio del envelope sender. Cuando un reenviador reenvía correo, la IP emisora se convierte en la IP del reenviador, que usualmente no está en el SPF del dominio original.

6) ¿Cuál es la diferencia entre Return-Path y From?

From es lo que ven los usuarios y a lo que responden. Return-Path (remitente del sobre) es donde van los rebotes. SPF autentica por defecto el Return-Path; DMARC evalúa alineación con From.

7) ¿Puedo tener múltiples registros SPF?

No. Un registro SPF por dominio. Múltiples TXT con v=spf1 normalmente causan permerror, que los receptores tratan como fallo.

8) ¿Necesito una IP dedicada?

Si envías volumen significativo y te importa la fiabilidad, una IP dedicada (o un pool bien controlado) suele merecer la pena. Las IPs compartidas pueden estar bien, hasta que no lo están—y no controlarás el “hasta que”.

9) ¿Deberían marketing y correo transaccional compartir el mismo dominio?

Puedes, pero es arriesgado. Subdominios separados (o incluso dominios separados) te permiten proteger la entregabilidad transaccional de las quejas y la decadencia de listas del marketing.

10) ¿Cuál es la ganancia más rápida si de repente estamos en spam?

Extrae encabezados de destinatarios afectados y confirma la alineación. Si la alineación está bien, reduce volumen inmediatamente, deja de enviar a destinatarios obsoletos e investiga diferimientos y señales de queja.

Conclusión: próximos pasos que realmente mueven la aguja

Si tu correo llega a spam, trátalo como un incidente: consigue evidencia del receptor, identifica el modo de fallo y arregla primero la vía más corta. La mayoría de los equipos pierde días retocando sintaxis SPF mientras la alineación DMARC falla a la vista.

Próximos pasos prácticos:

Recoge tres fuentes reales de mensajes desde buzones afectados (Gmail, Outlook y un dominio empresarial si es posible). Compara Authentication-Results y alineación.
Haz la alineación explícita: decide si dominios de rebote alineados SPF y/o dominios de firma DKIM serán tu estándar para cada emisor.
Estabiliza la identidad de infraestructura: PTR, DNS hacia adelante, HELO y IPs de salida consistentes.
Separa riesgo: divide identidades de transaccional y marketing para que una campaña mala no queme los restablecimientos de contraseña.
Higiene sobre heroísmos: deja de enviar a no comprometidos, procesa rebotes y reduce la tasa de quejas. El DNS no salvará una lista que te odia.

La entregabilidad de correo es aburrida cuando está sana, y cara cuando no lo está. Apunta a lo aburrido.