Entregabilidad de email en 2026: los estándares, el warm-up y el feedback loop.

§1 · Definición

Qué es realmente la entregabilidad de email.

La entregabilidad es la tasa a la que sus mensajes enviados llegan a la bandeja de entrada principal del destinatario: distinta de la entrega (el mensaje fue aceptado por el servidor de correo del destinatario) y del envío (usted lo entregó al pipeline de envío). Un mensaje puede enviarse con éxito, entregarse al servidor de correo del destinatario y acabar en la carpeta de spam: eso es éxito de entrega y fracaso de entregabilidad. Las cifras que le importan a la gente (tasa de apertura, tasa de clics, conversión) dependen de la entregabilidad, no de la entrega.

Los proveedores de buzón (Gmail, Outlook, Yahoo, Apple iCloud Mail, Proton y los grandes proveedores regionales) ejecutan cada uno un pipeline de puntuación de varias etapas sobre cada mensaje entrante. Las etapas son aproximadamente las mismas entre proveedores, con diferencias de peso:

1. Comprobaciones en el momento de conexión. DNS inverso, sanidad del HELO/EHLO, soporte TLS, listado de la IP en RBLs (Spamhaus, SpamCop, etc.).
2. Comprobaciones de autenticación. SPF pass/fail (RFC 7208), validación de la firma DKIM (RFC 6376), alineación DMARC (RFC 7489). Los tres deben pasar limpiamente para obtener la puntuación más permisiva aguas abajo.
3. Puntuación de contenido. Densidad de palabras clave de spam, reputación de los enlaces, ratio imagen-texto, si el nombre del From coincide con la dirección del From.
4. Consulta de reputación. El registro interno del proveedor sobre su IP de envío y su dominio From: tasa histórica de rebotes, tasa de quejas e interacción en envíos anteriores.
5. Señal de interacción. ¿Abrió o hizo clic el destinatario (o los destinatarios de su cohorte) en mensajes parecidos suyos anteriormente? La interacción reciente es la señal positiva individual más fuerte.
6. Disposición. Bandeja de entrada, pestaña Promociones (Gmail), carpeta de spam o rechazo. La disposición se realimenta en la reputación.

Las cinco secciones siguientes abordan las etapas 2 (autenticación) y 4 (reputación). La etapa 1 es sobre todo trabajo del relay de envío; las etapas 3 y 5 son decisiones de contenido y audiencia que están fuera del alcance de una guía de entregabilidad. La etapa 6 es la salida. Para un remitente comercial típico, hacer bien las etapas 2 y 4 le lleva de un 60–80% de bandeja de entrada a un 95%+.

Esta guía está escrita para operadores autoalojados, porque usted es quien ajusta los mandos. En SaaS la plataforma abstrae la mayoría de esto; en autoalojado usted es dueño del registro SPF, del par de claves DKIM, de la política DMARC y del calendario de warm-up de IP. La buena noticia: los estándares son públicos y estables. La mala: no hay atajos.

§2 · SPF

SPF — Sender Policy Framework.

SPF (RFC 7208) es una lista pública de direcciones IP autorizadas a enviar email en nombre de su dominio. La publica como un único registro TXT en su dominio de envío. Cuando un proveedor de buzón recibe un mensaje que dice provenir de @yourcompany.com, consulta el registro SPF de yourcompany.com y pregunta: ¿ha llegado este mensaje desde una de las IPs listadas? Si la respuesta es sí, SPF pasa. Si es no, SPF falla.

La sintaxis

v=spf1 include:amazonses.com ~all

Se lee como: «SPF versión 1, autoriza todo lo que autoriza Amazon SES, soft-fail cualquier otra cosa». El ~all del final es la cláusula comodín. ~all = soft-fail (marca sospechoso pero acepta), -all = hard-fail (rechaza), ?all = neutral (sin opinión). Use ~all hasta que DMARC esté sano y luego apriete a -all.

Para varios remitentes (p. ej. Google Workspace para el correo saliente + SES para marketing + Mailgun para transaccional), encadene varios mecanismos include::

v=spf1 include:_spf.google.com include:amazonses.com include:mailgun.org ~all

El límite de 10 consultas DNS. El RFC 7208 §4.6.4 limita la resolución de SPF a 10 consultas DNS en total. Cada include: cuenta como una. Un fallo habitual: encadenar 5 o más proveedores y rebasar el límite, tras lo cual SPF resuelve a permerror y se trata como fallo. Audite con dig TXT yourcompany.com + un flattener de SPF si está cerca del límite.

SPF en AcelleMail

El modelo SendingDomain de AcelleMail expone getSpf() en app/Model/SendingDomain.php:154, que lee el ajuste global spf_record y renderiza el valor del registro TXT. El método verifySpf(string $ipOrHostname) en la línea 363 envuelve la librería Mika56\SPFCheck: consulta el DNS en vivo en tiempo de ejecución y verifica RESULT_PASS. La superficie de verificación en la UI de administración se pone verde cuando el registro está presente y autoriza la IP de envío, y roja en caso contrario.

Truco práctico: SPF solo autentica el remitente del sobre (el MAIL FROM a nivel SMTP), no la cabecera From visible. Esa distinción es lo que la alineación DMARC corrige: vea §4.

§3 · DKIM

DKIM — DomainKeys Identified Mail.

DKIM (RFC 6376) adjunta una firma criptográfica a cada mensaje saliente. El servidor receptor obtiene su clave pública desde un registro TXT en el DNS, verifica la firma contra cabeceras específicas y el cuerpo del mensaje, y acepta el mensaje como auténtico si las matemáticas cuadran. SPF dice «esta IP está autorizada a enviar por nosotros»; DKIM dice «este cuerpo de mensaje y esta cabecera From no han sido manipulados desde que los firmamos».

El mecanismo

1. Genere un par de claves RSA (mínimo 1024 bits, recomendado 2048 bits para configuraciones nuevas).
2. La clave pública va al DNS como un registro TXT en {selector}._domainkey.{yourdomain}. El selector es una cadena arbitraria (p. ej. k1, mail, 20251208) que usted elige para permitir rotar claves sin romper los mensajes en vuelo.
3. La clave privada permanece en su servidor de envío. El MTA (o el relay de envío) firma cada mensaje saliente con ella, añadiendo una cabecera DKIM-Signature.
4. El servidor de correo del destinatario lee los valores d= (dominio) y s= (selector) de la cabecera de firma, consulta {s}._domainkey.{d}, obtiene la clave pública y verifica.

DKIM en AcelleMail

SendingDomain::generateDkimKeys() en app/Model/SendingDomain.php:221 genera un par de claves RSA de 1024 bits mediante los bindings OpenSSL de PHP, guarda la mitad privada en dkim_private y la pública en dkim_public. El selector se lee de dkim_selector en el modelo, con fallback al ajuste global dkim_selector. El valor del registro DNS se renderiza vía $this->getDomain()->getDkimDnsRecord() (línea 270) y se muestra al operador con un botón de copia junto a «el valor a publicar».

El patrón de generación de claves (de generateDkimKeys()):

$config = [
    'digest_alg' => 'sha256',
    'private_key_bits' => 1024,
    'private_key_type' => OPENSSL_KEYTYPE_RSA,
];
$res = openssl_pkey_new($config);
openssl_pkey_export($res, $privKey);
$pubKey = openssl_pkey_get_details($res)['key'];

Verificación: $this->getDomain()->verifyDkim() consulta el DNS en {selector}._domainkey.{domain} y compara la clave pública publicada con el valor almacenado localmente. El método completo verify() del modelo orquesta las comprobaciones de identidad + DKIM + SPF + DMARC en una sola llamada (línea 300).

DKIM gestionado por el proveedor

Si está enviando a través de Amazon SES, SendGrid, Mailgun o cualquier otro proveedor que firma en su extremo, publica el selector + la clave pública del proveedor en lugar de generar las suyas. La capability SignsDkimOnServer a nivel de driver de AcelleMail (vea app/SendingServers/Capabilities/SignsDkimOnServer.php) marca los drivers que gestionan DKIM de forma remota; la UI muestra entonces los registros CNAME del proveedor a publicar en lugar de generar un par de claves local. SES usa tres CNAMEs que delegan _domainkey a amazonses.com: configúrelos una vez y SES rota la clave subyacente por usted.

§4 · DMARC

DMARC — alineación, política y reporting.

DMARC (RFC 7489) se sitúa por encima de SPF y DKIM. Hace tres cosas que SPF y DKIM, por separado, no hacen:

1. Alineación. Exige que el dominio del sobre validado por SPF o el dominio que firma con DKIM coincida con el dominio de la cabecera From visible. Sin alineación, SPF y DKIM pueden pasar para un dominio distinto del que ve el destinatario: el hueco que explota el phishing.
2. Política. Le dice a los servidores receptores qué hacer cuando la alineación falla: none (no hagas nada, solo informa), quarantine (entrega a spam), reject (rechaza el mensaje en SMTP).
3. Reporting. Informes agregados (RUA: informes XML diarios de todos los envíos desde su dominio) e informes forenses (RUF: informes individuales por fallo) enviados a direcciones que usted especifica. Los informes le dan visibilidad sobre quién está enviando correo diciendo ser usted.

La sintaxis

_dmarc.yourcompany.com.    TXT    "v=DMARC1; p=quarantine; rua=mailto:dmarc@yourcompany.com; pct=100; aspf=s; adkim=s"

Se lee como: «DMARC versión 1, pon en cuarentena los mensajes que fallen la alineación, envía los informes agregados a dmarc@yourcompany.com, aplica la política al 100% de los mensajes que fallen, exige alineación estricta tanto para SPF como para DKIM».

El despliegue estándar

1. Día 0: publique p=none con rua= apuntando a un buzón monitorizado. Acepte informes durante 7–14 días. Esto es solo observación: ningún mensaje se rechaza.
2. Día 14: revise los informes. Identifique los remitentes legítimos (su propio SES, las IPs de envío de su CRM, los proveedores transaccionales) y póngalos a todos en alineación con SPF + DKIM.
3. Día 30: apriete a p=quarantine; pct=10. El correo desalineado va a spam para el 10% de los destinatarios. Observe los informes durante dos semanas.
4. Día 45: escale a pct=50 y luego a pct=100 a lo largo de 2–4 semanas.
5. Día 60–90: apriete a p=reject. Ahora el correo desalineado rebota en SMTP: los phishers que usen su dominio reciben rechazos directos.

No se salte el despliegue. Pasar directamente de sin DMARC a p=reject es la causa más común de los desastres de entregabilidad autoinfligidos: un remitente transaccional olvidado (su CRM, su herramienta de soporte, su sistema de facturación) empieza a hard-bounce en el momento en que p=reject se propaga.

Exigencias de los proveedores de buzón

Desde febrero de 2024, Gmail y Yahoo exigen DMARC para cualquier remitente que envíe > 5.000 mensajes al día a sus dominios, además de SPF o DKIM alineado y List-Unsubscribe con un clic (RFC 8058). Microsoft 365 se ha alineado con el mismo estándar en el momento de escribir esto. El listón para «envío comercial» se ha movido de forma permanente: DMARC ya no es opcional para ninguna lista por encima de ~1.000 contactos. Configúrelo pronto, aunque su lista aún sea pequeña.

§5 · BIMI

BIMI — el bonus del logo de marca.

BIMI (Brand Indicators for Message Identification) muestra el logo de su marca junto a sus mensajes en la bandeja de entrada del destinatario. Gmail, Yahoo, Apple Mail y Fastmail lo admiten a fecha de 2025. Es una función adyacente a la entregabilidad —no autenticación en sí misma— pero requiere DMARC en p=quarantine o p=reject como prerrequisito, motivo por el cual vive en esta guía.

Pasos de configuración (una vez DMARC esté en quarantine o más estricto):

1. Cree una versión SVG de su logo siguiendo la spec BIMI SVG Tiny PS: cuadrada, sin texto fuera de la marca, trazados simples.
2. Aloje el SVG en una URL HTTPS de acceso público.
3. Opcionalmente, obtenga un Verified Mark Certificate (VMC) de una CA: requerido por Gmail para mostrar el distintivo con un check azul, ~$1.500/año. Los Common Mark Certificates (CMC) son una alternativa más barata para marcas no registradas.
4. Publique el registro BIMI: default._bimi.yourcompany.com TXT "v=BIMI1; l=https://yourcdn/logo.svg; a=https://yourcdn/vmc.pem"

El impacto de BIMI en la entregabilidad es indirecto pero medible: los logos de marca en la bandeja de entrada suben las tasas de apertura entre un 5 y un 20% en los casos de estudio publicados (datos piloto de Yahoo Mail, informe BIMI de Mailchimp). También es una función catalizadora fuerte: no se puede activar BIMI sin endurecer primero DMARC, así que los equipos lo usan como zanahoria para una limpieza de autenticación.

§6 · Reputación

Reputación — qué puntúan realmente los proveedores de buzón.

La autenticación es binaria: un registro o resuelve y se alinea, o no. La reputación es continua: una puntuación de 0 a 100 mantenida por cada proveedor de buzón, contra su IP de envío y su dominio From por separado. Las dos puntuaciones se combinan en la decisión de enrutamiento (bandeja de entrada vs. Promociones vs. spam vs. rechazo).

Las señales

Dónde leer su puntuación de reputación

• Google Postmaster Tools (postmaster.google.com): reputación de IP y dominio según la visión de Gmail, además del cumplimiento de autenticación, la tasa de cifrado y la tasa de spam. Gratis.
• Microsoft SNDS (postmaster.live.com/snds/): datos a nivel de IP de Outlook.com y clasificaciones de reputación del remitente. Gratis, requiere registro.
• Yahoo Sender Hub: más nuevo, registros a través de la página de Yahoo Postmaster. Estadísticas agregadas por dominio.
• Paneles de los proveedores: el Reputation Dashboard de Amazon SES muestra las tasas de rebote y queja con umbrales. SparkPost, Mailgun y SendGrid tienen paneles similares.

Revise al menos uno semanalmente. Los indicadores adelantados (tendencia de tasa de spam, caída de la reputación de la IP) aparecen días antes que los efectos aguas abajo (caída de la tasa de apertura): cuando note que una campaña rinde mal, el problema de reputación ya tiene dos semanas.

§7 · Warm-up de IP

Warm-up de IP — el calendario de 6 semanas.

Una IP de envío recién creada empieza con reputación cero. Los proveedores de buzón aplican throttling a volúmenes altos desde IPs nuevas por diseño: es la principal defensa contra los spammers tipo snowshoe que levantan instancias en la nube y disparan envíos. El warm-up es la práctica de aumentar gradualmente el volumen de envío a lo largo de 4–6 semanas, manteniéndose dentro de los límites de throttling por día y por hora, para construir reputación de forma orgánica.

Esto solo se hace una vez por IP. La mayoría de los equipos nunca lo hacen porque las IPs compartidas de Amazon SES, SendGrid y Mailgun vienen ya calientes. Los casos en los que el warm-up importa: IP dedicada en SES (normalmente > 1M de envíos al mes la justifica), Postal MTA autoalojado en una instancia en la nube nueva, migración de un ESP a otro con cambio de dominio.

El calendario

Calendario basado en las recomendaciones de warm-up publicadas por SparkPost / Postmark / SES, consolidadas en una sola tabla semana a semana. Suba más despacio que esto si ve la tasa de quejas con tendencia al alza; suba más rápido solo si tiene luz verde de reputación confirmada por el proveedor en cada paso.

Seguimiento del warm-up en AcelleMail

El modelo SendingServer de AcelleMail tiene estado de warm-up de primera clase. warmup_enabled, warmup_strategy_id y warmup_started_at viven en la tabla sending_servers; isWarmupEnabled() en app/Model/SendingServer.php:333 controla las decisiones en el momento del envío. La tabla compañera SendingServerWarmupLog registra cada envío durante la ventana de warm-up con fecha, estado y un payload meta serializado: vea app/Model/SendingServerWarmupLog.php.

El patrón: asigne una WarmupStrategy (una fila que define la curva de volumen diario) a un servidor de envío, ponga warmup_enabled = true y warmup_started_at = now(). SendingServerWarmupUsage en el pipeline de envío lleva la cuenta de hoy y se niega a despachar más allá del techo diario de la estrategia. Cuando el techo del día N de la estrategia supera su volumen diario completo, el servidor se gradúa y el modo warm-up se desactiva automáticamente.

Las clases DynamicRateTracker e InMemoryRateTracker (app/Library/) gestionan el límite de frecuencia por minuto / por hora en la capa SMTP: incluso fuera del warm-up, AcelleMail respeta los topes de frecuencia publicados por el relay para que un pico de cola no dispare el throttling del proveedor.

§8 · Rebotes y quejas

Rebotes, quejas y el feedback loop.

Rebotes duros vs. blandos

Un rebote duro es un fallo permanente, normalmente un código SMTP 5xx: la dirección no existe, el dominio no resuelve, el buzón del destinatario está deshabilitado de forma permanente. El modelo BounceLog de AcelleMail define las constantes HARD y SOFT en app/Model/BounceLog.php:33; un rebote duro suprime la dirección de inmediato. Un rebote blando es transitorio, un código 4xx: buzón lleno, servidor temporalmente no disponible, mensaje demasiado grande. Los rebotes blandos se reintentan con backoff; las direcciones que rebotan en blando repetidamente entre envíos acaban degradándose a duro.

El mapa de clasificación para las notificaciones de rebote de AWS SES (la fuente que cita la documentación de BounceLog.php:32 de AcelleMail): los tipos de rebote incluyen Permanent (duro) con subtipos General / NoEmail / Suppressed / OnAccountSuppressionList; Transient (blando) con subtipos General / MailboxFull / MessageTooLarge / ContentRejected / AttachmentRejected; más Undetermined (tratar como blando, reintentar).

Quejas

Una queja es un destinatario que pulsa «reportar como spam» en su cliente de email. Las quejas llegan por Feedback Loops (FBLs): un canal de notificación por proveedor por el que los ISPs le reenvían los mensajes reportados como abuso. El FeedbackLoopHandler de AcelleMail en app/Model/FeedbackLoopHandler.php procesa los mensajes FBL entrantes por IMAP/POP y parsea las cabeceras del Abuse Reporting Format (ARF, RFC 5965) para extraer el ID del mensaje original y el tipo de feedback.

Los tipos de feedback ARF que gestiona AcelleMail (según FeedbackLoopHandler::FEEDBACK_TYPES en la línea 35):

• abuse: el destinatario marcó explícitamente como spam. Suprima de inmediato.
• fraud: el destinatario marcó como phishing. Suprima y registre para revisión de seguridad.
• virus: el antivirus del destinatario detectó un payload. Suprima y audite el contenido.
• other: queja genérica. Suprima.
• not-spam: reporte explícito de «esto no es spam» (raro). Excluido de la supresión: vea EXCLUDED_FEEDBACK_TYPES.

Grandes proveedores de buzón participantes en FBLs: AOL, Yahoo, Microsoft (vía JMRP), Comcast, BlueTie. Gmail no ofrece un FBL público: entrega el feedback de «marcado como spam» a través del panel de Postmaster Tools y de los informes agregados de DMARC.

Reglas de supresión

1. Rebote duro → suprimir permanentemente. No reintentar nunca; la dirección está muerta.
2. Queja → suprimir permanentemente. El destinatario ha pedido activamente parar. Volver a enviar es ilegal en la mayoría de jurisdicciones y arrasa la reputación.
3. Rebote blando ×3 en 30 días → degradar a duro y suprimir. Los rebotes blandos persistentes son buzones llenos o problemas de conectividad continuos: trátelos como muertos.
4. Baja → suprimir para marketing, no para transaccional. Los recibos de pedido y los restablecimientos de contraseña siguen; las campañas paran.
5. Impacto en spam-trap → escalar a investigación. Saque toda la fuente de adquisición de ese suscriptor. La lista probablemente esté contaminada con direcciones compradas o raspadas.

§9 · Higiene de lista

Higiene de lista — la disciplina que mantiene alta la reputación.

La autenticación es una configuración de una sola vez. La reputación es disciplina operativa. Los siete hábitos que mueven la aguja:

1. Doble opt-in para todas las suscripciones de marketing. Un clic de confirmación antes de que la dirección se una a la lista activa. Elimina los errores de tecleo, las direcciones de rol (info@, sales@) y las direcciones recolectadas. Añade un 10–20% de fricción al registro; resta un 50–80% del riesgo de rebote/queja.
2. Baja con un clic (RFC 8058). Cabecera List-Unsubscribe que apunta a una URL de un solo clic. Exigido por Gmail y Yahoo para los remitentes de > 5K/día a sus dominios desde febrero de 2024. Haga la baja más fácil que la queja: los destinatarios que iban a pulsar «spam» pulsan «darse de baja» en su lugar.
3. Reactivación antes de la supresión. Los suscriptores que no han abierto en 90 días reciben una campaña de «queremos seguir siendo relevantes». Si abren → quedarse. Si no abren → pasar a una cola de salida. Si no abren tras 180 días → suprimir.
4. Auto-supresión de rebotes. Procese el webhook de rebote en minutos; elimine de la lista de envío activa antes de la siguiente campaña. BounceLog::record() de AcelleMail y los manejadores de webhook de rebote estilo vbrandsync hacen esto automáticamente.
5. No importe listas compradas. Nunca. Las listas compradas están sembradas con spam-traps. Un impacto en una trampa y su dominio queda en Spamhaus durante 30+ días. Las cuentas no cuadran nunca: las listas compradas son un sumidero permanente de reputación.
6. Segmente por interacción. Envíe campañas al 50% comprometido el doble de a menudo y al 50% frío la mitad de a menudo. Esto sube la tasa de apertura global, baja la tasa de quejas y da a los proveedores de buzón una señal fuerte de «este remitente es relevante».
7. Limite la cadencia de las automatizaciones. Una serie de bienvenida + carrito abandonado + post-compra + cumpleaños + reactivación pueden producir 8 mensajes en una sola semana. Limite los mensajes totales de automatización a uno cada 48 horas por destinatario, con excepciones rígidas para lo transaccional (recibos, restablecimientos de contraseña).

§10 · Herramientas de AcelleMail

Herramientas de entregabilidad de AcelleMail — lo que entrega el código.

Extraído directamente del árbol de código bajo app/Model/ y app/Library/. Cada entrada es un modelo real, una interfaz de capability o una clase de librería: no es marketing.

§11 · Resolución de problemas

Problemas comunes de entregabilidad y sus soluciones.

§12 · FAQ

FAQ de entregabilidad de email.

Cabecera de cluster

A dónde ir después.

Dominios autenticados. Rebotes monitorizados. Reputación de nivel inbox.

AcelleMail entrega de fábrica la verificación de SPF/DKIM/DMARC, el procesamiento de feedback loop ARF, la máquina de estados del warm-up de IP y el límite de frecuencia por servidor. Cada afirmación de esta guía se mapea a una clase de app/Model/ o app/Library/ de AcelleMail en el árbol de código.