Infraestructura de email
Servidores KumoMTAMTA de código abierto, Rust + Lua, sin tarifa por mensajeServidores PowerMTACon licencia, pools VirtualMTA, soporte del proveedorEntregabilidadWarm-up, alineación DMARC, feedback loopsServidores
Bare metal — AMD EPYCInquilino único Turin / Genoa, hasta 192 núcleosServidores GPU e IANVIDIA Blackwell B200 / H200, PCIe Gen5VPSInstancias por núcleo sobre los mismos hosts EPYCCloud y red
CloudInstancias por horas, snapshots, NVMe Gen5Protección DDoSAbsorción en el borde incluida en cada servidorRed y regionesÁmsterdam · Fráncfort · Londres · AshburnEntregabilidad
La ubicación en la bandeja de entrada la deciden la autenticación y la reputación, no la velocidad de envío. Configuramos SPF, DKIM y DMARC alineados, la baja en un clic y el DNS inverso para cumplir las reglas de Gmail, Yahoo y Microsoft, calentamos tus IPs en un calendario ajustado a tu volumen, y operamos los feedback loops y la vigilancia de reputación durante toda la vida de tu envío —en España y en Latinoamérica.
En breve
La bandeja la deciden la reputación y la autenticación, y la gente lo confunde con la potencia del servidor. Los proveedores de buzón —Gmail, Outlook/Hotmail y Yahoo, que concentran los destinatarios del mundo hispanohablante— puntúan la IP y el dominio desde los que envías, comprueban que SPF, DKIM y DMARC concuerden, y pesan cómo reacciona la gente durante semanas: aperturas, marcas de spam, bajas. Un MTA rápido te da los controles para gestionar todo eso, pero no gana la reputación por ti.
Por eso una IP nueva y veloz sobre una lista vieja entrega peor que un envío modesto a una lista que de verdad quiere tu correo. La entregabilidad no es un único ajuste: es la suma de la autenticación correcta, el calentamiento con calendario, la separación de flujos y la higiene de listas, sostenidas a diario. Lo demás —el diseño del email, el asunto, la cadencia— ayuda, pero descansa sobre esa base.
Conviene desmontar un mito frecuente en nuestro mercado: el idioma del correo no decide la entrega. Escribir en español no te penaliza ni te favorece ante Gmail u Outlook; lo que miran es la autenticación, la reputación y el comportamiento de tus destinatarios. Una campaña impecable en castellano, enviada desde una IP fría y sin DMARC alineado, cae en spam igual que cualquier otra. La disciplina técnica manda sobre el idioma, en España y en toda Latinoamérica.
Las reglas actuales
Los grandes proveedores se movieron con pocos meses de diferencia y la aplicación solo se ha endurecido desde entonces. Estos son los requisitos tal y como están hoy.
Umbral masivo: ≥ 5.000/día a cuentas Gmail
Umbral masivo: remitentes de gran volumen
Umbral masivo: ≥ 5.000/día
Un detalle ahorra muchos disgustos: la baja en un clic se aplica al correo de marketing y promocional, no a los mensajes transaccionales como recibos y restablecimientos de contraseña. Estos últimos siguen necesitando autenticación completa, pero quedan exentos de la regla de baja. Desde finales de 2025, Gmail ha pasado de retrasos intermitentes al rechazo directo del correo que no cumple, así que el coste de equivocarse ya no es gradual.
Ninguna de estas reglas es exótica, y ese es el punto: son la nueva línea base. La mayoría de los problemas de entregabilidad que nos piden arreglar se reducen a una de ellas rota en silencio —un subdominio sin alinear, un DNS inverso ausente, o una tasa de quejas que cruzó la raya sin que nadie lo viera.
Sí, y la alineación es la parte que más se falla. Necesitas SPF y DKIM configurados, pero DMARC solo pasa cuando el dominio visible en From: coincide con el dominio de SPF o con el de la firma DKIM. Es habitual tener SPF y DKIM técnicamente válidos y, aun así, ninguno alineado con la dirección From:, con lo que DMARC falla y el correo se trata como sospechoso. Firmamos con claves DKIM de 2048 bits, las rotamos con un calendario y confirmamos la alineación de cada flujo antes de subir volumen.
DMARC además lleva una política que dice al receptor qué hacer cuando un mensaje falla: solo monitorizar, poner en cuarentena o rechazar. Los remitentes masivos deben publicar al menos una política de monitorización, pero monitorizar no detiene a quien falsifica tu dominio. El camino correcto es empezar en monitorización, leer los informes agregados hasta tener localizada cada fuente legítima, y luego pasar a aplicación. Esa progresión es deliberada: saltar directo a reject sin leer los informes es como una empresa bloquea sin querer sus propias facturas.
Dos detalles relacionados pillan a la gente. Los subdominios caen bajo tu política DMARC de organización, así que un subdominio de marketing olvidado puede fallar en tu nombre si se deja sin alinear; por eso lo aislamos con sp=reject. Y el reenvío rompe SPF, que es para lo que sirve ARC: preserva el resultado de autenticación original cuando el correo pasa por reenviadores y listas, para que el correo legítimo reenviado no se castigue por el salto. Tenemos en cuenta ambos al mapear tus fuentes de envío.
La autenticación vive en el DNS. El primer bloque es el núcleo que necesita todo remitente: un registro SPF con los hosts autorizados, una clave pública DKIM para el selector de firma, y un DMARC mostrado aquí ya en aplicación, con alineación estricta y subdominios aislados. El segundo bloque es la capa opcional —seguridad de transporte con MTA-STS y TLS-RPT, y un registro BIMI que muestra tu logo una vez DMARC está en aplicación. Los publicamos y verificamos contigo; los valores son ilustrativos.
Los registros son pequeños, pero el orden importa. SPF y DKIM entran primero y se verifican; DMARC sigue en monitorización para poder leer los informes; y solo entonces tiene sentido el bloque opcional, porque BIMI no se mostrará y MTA-STS no sirve hasta que el núcleo esté sólido y en aplicación.
# SPF — autoriza los hosts que envían por ti
example.com. IN TXT "v=spf1 ip4:198.51.100.21 include:vvih.example -all"
# DKIM — clave pública del selector de firma de 2048 bits
s1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
# DMARC — empieza en none y pasa a aplicación con informes limpios
_dmarc.example.com. IN TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=s; aspf=s; sp=reject"# MTA-STS — exige TLS para el correo que llega A tu dominio
_mta-sts.example.com. IN TXT "v=STSv1; id=2026061701"
# política en https://mta-sts.example.com/.well-known/mta-sts.txt
# TLS-RPT — informes diarios de fallos de transporte
_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:tlsrpt@example.com"
# BIMI — tu logo en buzones compatibles (requiere DMARC en aplicación)
default._bimi.example.com. IN TXT "v=BIMI1; l=https://example.com/logo.svg; a=https://example.com/vmc.pem"Calentamiento
Un calentamiento típico va de 45 a 90 días: subes el volumen poco a poco —empezando en 20-50 correos al día con tus destinatarios más activos— hasta superar los 5.000, sin aumentar más de la mitad por día. Un dominio recién comprado conviene dejarlo sin enviar entre 24 horas y 30 días; enviar demasiado pronto puede ganarte un bloqueo temporal de SPAMHAUS.
El calendario es una prueba de reputación, no una meta de tráfico. Si Gmail acepta una subida pero Outlook empieza a diferir, mantenemos Outlook donde está y seguimos con Gmail en plan —el ritmo por proveedor es lo que separa un calentamiento limpio de un atasco. Por debajo de unos 50.000 mensajes al mes, una IP dedicada se ve inactiva entre envíos; ahí un buen pool compartido suele entregar mejor.
Una vez las IPs están calientes, el trabajo no para; cambia de forma. Cada día los feedback loops reportan quejas, el procesador de rebotes separa los fallos duros de los blandos, y las direcciones que dañan tu posición se suprimen antes de que cuesten más. La higiene de listas corre con calendario, no en crisis, porque una lista limpia que interactúa es la señal más fuerte que lee un proveedor de buzón. Las bases de datos se degradan en torno a un 25 % al año, así que podamos a los que nunca abren cada 30 a 90 días con una ruta de despedida.
La interacción es la palanca silenciosa bajo todo esto. El correo que la gente abre, lee y responde le enseña al proveedor que tus mensajes se quieren, y esa confianza aprendida es la que lleva una campaña nueva a la bandeja en su primer envío. Así que el trabajo de reputación y el de contenido son el mismo trabajo: envía correo que la gente pidió, a una lista que aún lo quiere, a un ritmo que los proveedores aceptan, y los números siguen.
Vigilamos todo esto con las herramientas que los propios proveedores exponen. Google Postmaster Tools muestra la reputación de dominio e IP, la tasa de spam y los aciertos de autenticación; los feedback loops sacan a la luz las quejas; y la vigilancia de listas negras caza un listado antes de que se extienda. Cuando un número se desvía, lo rastreamos hasta el flujo que lo causó en vez de frenarlo todo, porque un corte brusco castiga al correo que iba bien.
La pila
Cada capa cierra un hueco que deja abierto la anterior. La parte honesta es que no todo remitente necesita todas las capas, así que aquí va qué hace cada una y para quién es de verdad.
Lista en DNS las IPs autorizadas a enviar por tu dominio. Un solo registro, máximo 10 consultas; ~all (blando) o -all (duro).
Quién la necesitaTodos los remitentes.
Obligatorio de facto
Firma criptográfica de cada mensaje con tu clave; el receptor la valida con tu clave pública en DNS.
Quién la necesitaTodos los remitentes.
Obligatorio de facto
Exige que SPF o DKIM estén alineados con el From: y publica una política (none → quarantine → reject) más informes agregados.
Quién la necesitaTodos los remitentes masivos.
Obligatorio para gran volumen
Obliga a cifrar con TLS el correo entrante a tu dominio y te da informes diarios de fallos de transporte.
Quién la necesitaMarcas sensibles a la seguridad.
Recomendado
Muestra tu logo verificado junto al mensaje. Requiere DMARC en quarantine/reject y un certificado VMC (~1.200-1.500 USD/año).
Quién la necesitaMarcas que quieren visibilidad y confianza.
Opcional
Primeros pasos
Los cuatro primeros pasos son el lanzamiento; el quinto corre durante todo el tiempo que envíes. Este es el camino que seguimos con cada nuevo host de envío.
Configuramos SPF y DKIM con claves de 2048 bits, publicamos DMARC y confirmamos DNS directo e inverso y TLS, para que el dominio From: alinee y el correo pase las comprobaciones que hoy aplican todos los grandes proveedores.
Los encabezados de baja en un clic van en los flujos de marketing y se respetan en dos días; conectamos los feedback loops y los procesadores de rebotes que alimentan tu lista de supresión.
El volumen sube en un calendario ajustado a tus cifras, nunca más de la mitad por día, empezando por tus destinatarios más activos y repartido entre los pools transaccional y de marketing.
Cuando los informes agregados están limpios, movemos DMARC de p=none a quarantine y luego reject, lo que cierra la suplantación y desbloquea BIMI si quieres el logo. Aislamos los subdominios con sp=reject para que el marketing no arrastre lo transaccional.
Tasas de queja, categorías de rebote y reputación en Postmaster se vigilan durante toda la vida del servidor, y ajustamos el ritmo en cuanto un proveedor pone resistencia.
A menudo, no. Una IP dedicada solo ayuda cuando envías lo suficiente para mantenerla ocupada y caliente —en torno a cincuenta mil mensajes al mes es el suelo aproximado. Por debajo, una IP dedicada delgada parece inactiva a los proveedores entre envíos, y un pool compartido bien llevado y ya caliente colocará mejor tu correo. Para remitentes pequeños, listas de baja frecuencia y prospección muy segmentada, la reputación del dominio y la calidad de la lista hacen mucho más trabajo que poseer una dirección.
Este es el tipo de consejo que nos cuesta una línea de factura, y lo damos igualmente: empieza en compartido si tu volumen es pequeño o irregular, y pasa a dedicada cuando puedas sostener una cadencia que la mantenga caliente. Cuando ese momento llega, la IP dedicada te da control total de tu reputación —nadie más puede mancharla— a cambio de un calentamiento que hacemos contigo. Hasta entonces, te ahorramos el gasto.
Recuperar reputación es más lento que construirla, pero el camino es conocido. Primero paramos la hemorragia: pausamos las cohortes frías y enviamos solo a los que abrieron o hicieron clic en los últimos 30 a 60 días, hacemos más visible la baja y revisamos de dónde salieron los contactos. Después arreglamos la base —verificamos que SPF y DKIM pasan y alinean, aligeramos el HTML, añadimos texto plano y bajamos la frecuencia— y vigilamos Postmaster a diario hasta que la curva gira.
Lo que no hacemos es cambiar de dominio para esquivar una mala reputación: eso traslada el problema y reinicia el reloj de confianza. La industria lo tiene medido —firmas de entregabilidad documentan que migrar de p=none a p=reject con alineación correcta sube la tasa de bandeja alrededor de un 18 % en los primeros 30 días— y coincide con lo que vemos: la reputación se gana corrigiendo la lista y el contenido, y recuperándola poco a poco, no escondiéndose detrás de un dominio nuevo.
Preguntas
Lo que se pregunta antes de confiar el correo a una infraestructura.
La reputación y la autenticación, no la velocidad. Los proveedores puntúan la IP y el dominio, comprueban que SPF, DKIM y DMARC concuerden, y miden cómo reacciona la gente —aperturas, quejas, bajas— durante semanas.
De 45 a 90 días según tu volumen y los proveedores a los que llegues, subiendo poco a poco. Un dominio nuevo conviene dejarlo reposar entre 24 horas y 30 días antes del primer envío para no arriesgar un bloqueo temporal.
A menudo no. Una IP dedicada solo ayuda cuando envías lo suficiente para mantenerla caliente —en torno a 50.000/mes—. Por debajo, un buen pool compartido ya caliente entrega mejor; empieza ahí si tu volumen es pequeño o irregular.
Desde febrero de 2024, los remitentes de gran volumen (≥5.000/día) deben autenticar con SPF, DKIM y DMARC alineados, mantener las quejas por debajo del 0,3 % y ofrecer baja en un clic procesada en dos días. Desde finales de 2025, Gmail rechaza el correo que no cumple en vez de solo retrasarlo.
Sí. DMARC solo pasa cuando el dominio visible en From: coincide con el dominio de SPF o el de la firma DKIM. Es habitual tener SPF y DKIM válidos pero ninguno alineado con el From:, y entonces DMARC falla y el correo se trata como sospechoso.
Por fases: empieza en p=none, lee los informes agregados hasta tener localizadas todas tus fuentes legítimas, pasa a quarantine con pct=50, y solo entonces a reject. Aísla los subdominios con sp=reject para que un fallo en marketing no toque lo transaccional.
Las reglas técnicas son globales —las ponen Gmail, Outlook y Yahoo— y se aplican igual en España, México, Colombia, Chile, Argentina o Perú. Lo que cambia es el marco legal de consentimiento (RGPD y LSSI-CE en la UE) y, según el país, el peso de Outlook/Hotmail frente a Gmail.
La operamos. Autenticación, calentamiento, feedback loops y vigilancia de reputación forman parte de levantar y mantener un host de envío con nosotros, no un extra que se compra aparte.
Una llamada corta, una revisión de tu autenticación y reputación, y un plan honesto —incluido cuándo te conviene un pool compartido o un ESP. Sin presión.