Gmail me mandó a spam. No una vez — sistemáticamente. Y lo hizo después de que configuré SPF, DKIM, DMARC, calenté el dominio durante semanas, y llegué al 99% de reputación en Google Postmaster Tools. Esta semana salió un hilo en HN sobre deliverability que tiene 300+ puntos y me confirmó algo que ya sospechaba: el problema no soy yo. El problema es estructural. Y probablemente no tiene solución técnica.
Pero igual les cuento todo lo que hice, porque si vas a tener una newsletter propia en 2025, necesitás saber dónde están las paredes antes de golpearte la cabeza contra ellas.
Gmail reputación email deliverability: el campo minado que nadie te cuenta
El primer batch lo mandé un martes a las 10am. Trescientos suscriptores, todos opt-in, todos de este blog. Abrà Gmail Postmaster Tools dos horas después y vi algo que no querÃa ver: tasa de spam del 0.8%. Suena bajo. No lo es. El umbral de Google para empezar a filtrar está en 0.1%. Estaba ocho veces por encima.
Lo primero que hice fue lo que harÃa cualquier arquitecto de sistemas: buscar el punto de falla. Y acá empieza el problema — con email no hay stack trace. No hay logs accesibles. No hay mensaje de error decente. Tenés Postmaster Tools, que te da cuatro métricas con resolución de 24 horas, y nada más.
Fui a lo básico:
# Verificar registros DNS — el primer paso siempre
dig TXT tudominio.com | grep -E 'spf|dkim|dmarc'
# SPF lookup — máximo 10 lookups permitidos por RFC 7208
nslookup -type=TXT tudominio.com
# DKIM — necesitás saber el selector que usa tu ESP
dig TXT selector._domainkey.tudominio.com
# DMARC
dig TXT _dmarc.tudominio.com
Todo bien. SPF estaba limpio, DKIM firmado, DMARC en p=quarantine. Técnicamente impecable. Y aun asÃ, spam.
La semana 1: el setup que creÃa que era suficiente
Revisé la configuración completa. Acá estaba mi SPF original:
# SPF ANTES — demasiados includes anidados
v=spf1 include:_spf.google.com include:sendgrid.net include:mailchimp.com ~all
# El problema: cada include agrega lookups
# Google + SendGrid + Mailchimp = potencialmente +8 lookups
# Si superás 10, el registro falla silenciosamente
Lo simplifiqué:
# SPF DESPUÉS — solo lo que realmente uso
v=spf1 include:_spf.resend.com ip4:xxx.xxx.xxx.xxx ~all
# Resend usa menos includes anidados
# Agregué la IP directa del servidor de envÃo
# ~all en vez de -all para no ser demasiado estricto al inicio
DKIM ya estaba configurado con clave de 2048 bits — el estándar mÃnimo aceptable hoy. Si tenés 1024, cambiala ahora mismo, no después.
DMARC lo movà de p=none (solo monitoreo) a p=quarantine con rua para reportes:
# DMARC con reporte agregado
_dmarc.tudominio.com TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@tudominio.com; pct=100; adkim=s; aspf=s"
# adkim=s y aspf=s = modo estricto
# Significa que el dominio del From debe matchear exactamente
# Más seguro pero más exigente
La semana 2: calentamiento de dominio y el teatro del volumen
Agregué list-unsubscribe headers. Tanto la versión mailto como la versión HTTP con one-click (RFC 8058). Google lo requiere explÃcitamente para senders de alto volumen desde 2024:
# Headers que Gmail exige ver en cada email
List-Unsubscribe: <https://tudominio.com/unsubscribe?token=xxx>, <mailto:unsub@tudominio.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
# Sin esto, Gmail puede penalizarte directamente
# No importa que técnicamente no seas "alto volumen"
# El algoritmo no sabe si mandás 300 o 300.000
El calentamiento de dominio lo hice a mano porque tenÃa el control del stack. Empecé con 50 emails el dÃa 1, 100 el dÃa 3, 200 el dÃa 7, 300 el dÃa 14. Seguà todas las guÃas. Llegué al 99% de reputación de dominio en Postmaster Tools.
Y en el tercer batch, el 15% todavÃa fue a spam en cuentas Gmail.
La semana 3: la revelación incómoda
Empecé a leer los DMARC reports que me llegaban. XML crudo, muy amigable:
<!-- Fragmento de un reporte DMARC real -->
<record>
<row>
<source_ip>xxx.xxx.xxx.xxx</source_ip>
<count>47</count>
<policy_evaluated>
<!-- Todo pasa ✓ -->
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<!-- SPF y DKIM pasan. DMARC pasa.
Y aun asà van a spam. ¿Por qué?
Porque Google tiene otra capa encima de todo esto
que no está documentada en ningún RFC -->
</record>
Ahà está el problema en crudo: DMARC pass no implica inbox placement. Los estándares técnicos son condición necesaria pero no suficiente. Google tiene su propio sistema de reputación que funciona como una caja negra encima de todo el stack de autenticación.
Los errores que cometà (y que vas a cometer vos también)
Error 1: Asumir que 99% de reputación en Postmaster Tools = inbox
Postmaster Tools mide reputación de dominio según lo que Google ya recibió. No predice deliverability futura. Un dominio puede tener 99% de reputación y aun asà activar filtros de contenido, filtros de engagement, o simplemente el algoritmo decide que tu segmento de usuarios no abre emails y empieza a filtrar.
Error 2: Ignorar la reputación de IP
Postmaster Tools tiene dos métricas separadas: reputación de dominio y reputación de IP. Yo tenÃa 99% en dominio y MEDIUM en IP. Eso importa. Si usás un ESP como Resend, Postmark o SendGrid, compartÃs IPs con otros senders. Si alguien en ese pool manda spam, tu reputación de IP baja aunque vos no hayas mandado nada.
Solución parcial: IPs dedicadas. Costo adicional. Y aun asà no es garantÃa.
Error 3: DMARC en p=quarantine demasiado rápido
Fui de p=none a p=quarantine en una semana. Lo correcto era quedarse en p=none monitoreando durante al menos 30 dÃas, verificar que todos los flujos legÃtimos pasaran, y recién después subir. Me perdà de detectar que mi plataforma de transaccionales usaba un from-address que no matcheaba el dominio principal — esos emails empezaron a rebotar silenciosamente.
Error 4: No separar dominio transaccional de dominio de marketing
Todo salÃa desde el mismo dominio. Un mail de "resetear contraseña" y un newsletter compartÃan reputación. Hoy uso subdominios separados:
# Separación de dominios — buena práctica
mail.tudominio.com → emails transaccionales (alta prioridad)
news.tudominio.com → newsletter (reputación independiente)
# Si el newsletter daña reputación, no arrastra al transaccional
# Los filtros de Gmail también los tratan diferente
Esta separación también la aplico mentalmente cuando trabajo en arquitecturas con múltiples servicios — el principio de separar concerns no es solo para código. Lo vi claramente después de debuggear esos PRs con credenciales hardcodeadas donde el problema era exactamente ese: todo mezclado en un mismo contexto.
Error 5: Confiar en que "siguiendo los estándares" alcanza
Este es el error más filosófico y el más costoso. SPF, DKIM y DMARC son estándares abiertos definidos por RFCs. Los implementé correctamente. Pero Google tiene capas propias de filtrado que no están documentadas, no son auditables, y no tienen mecanismo de apelación efectivo. Es la misma tensión que discutà en el post sobre contribuir al kernel de Linux con IA — hay sistemas donde el estándar técnico y el poder real están completamente desacoplados.
El problema estructural que el hilo de HN expuso
El thread que saltó esta semana tenÃa un comentario que me quedó dando vueltas: "Gmail no es un servicio de email. Es un filtro de email que también recibe email."
Es hiperbólico pero captura algo real. Google procesa el 40-60% del email mundial dependiendo de la fuente que mires. Eso les da un poder de decisión unilateral sobre qué llega y qué no. Y ese poder no está regulado por ningún estándar técnico, ningún RFC, ninguna authority de internet.
Los RFC 7208 (SPF), 6376 (DKIM) y 7489 (DMARC) son acuerdos de la comunidad. Google los respeta a nivel técnico — no te va a aceptar emails que fallen DMARC. Pero los usa como piso, no como techo. Por encima del piso construyó su propio edificio y no te deja ver los planos.
Esto me recuerda a algo que escribà sobre los benchmarks de agentes de IA que están rotos: cuando el sistema de evaluación es opaco y está controlado por un solo actor, los resultados dejan de medir lo que creés que miden. Con email es igual. El "99% de reputación" mide algo, pero no exactamente lo que necesitás.
FAQ: Gmail, deliverability y el infierno del email propio
¿SPF, DKIM y DMARC configurados correctamente garantizan que no voy a spam en Gmail?
No. Son condición necesaria para no ir a spam, pero no suficiente para ir al inbox. Google tiene capas adicionales de filtrado basadas en engagement (aperturas, clics, marcaciones como spam por usuarios), reputación de IP del servidor de envÃo, historial del dominio, y factores de contenido que no están documentados públicamente. Podés tener los tres protocolos perfectos y aun asà quedar en spam si tu engagement es bajo o si tu IP tiene historial negativo.
¿Cuánto tiempo lleva calentar un dominio nuevo para email?
El consenso de la industria es entre 4 y 8 semanas de calentamiento gradual. Empezar con volúmenes pequeños (50-100 emails), ir duplicando cada 3-5 dÃas, y mantener métricas de engagement altas en ese perÃodo inicial. El problema es que en esas primeras semanas vas a tener deliverability baja de todas formas, y si mandás a usuarios que no abren, dañás la reputación que estás intentando construir. Es un problema de bootstrapping que no tiene solución elegante.
¿Vale la pena tener IPs dedicadas para newsletters chicas?
Generalmente no, hasta los 50.000-100.000 emails mensuales. Con menos volumen, una IP dedicada sin historial es peor que una IP compartida con buena reputación que usan ESPs grandes. El razonamiento: Google confÃa en IPs que mandan mucho email limpio. Una IP nueva sin historial genera desconfianza. Con bajo volumen, no tenés suficiente señal para construir esa confianza rápido.
¿Qué es Google Postmaster Tools y cómo lo uso para diagnosticar problemas?
Es una herramienta gratuita de Google (postmaster.google.com) que te da métricas de cómo Gmail ve tu dominio de envÃo. Muestra reputación de dominio, reputación de IP, tasa de spam reportado por usuarios, errores de autenticación, y tasa de entrega. Para usarlo necesitás verificar la propiedad de tu dominio. La limitación grande es que los datos tienen 24-48 horas de latencia y solo ves promedios, no emails individuales. Es útil para tendencias, inútil para debugging en tiempo real.
¿Tiene sentido tener newsletter propio en 2025 o mejor usar Substack/Beehiiv?
Depende de qué priorizás. Substack y Beehiiv tienen reputación de dominio e IP construida durante años con millones de senders. Tu email sale desde sus dominios con su historial — eso te da deliverability mucho mejor desde el dÃa uno. El costo es que no controlás la infraestructura, estás sujeto a sus términos, y si ellos tienen un problema de reputación, te arrastra. Para newsletters chicas (bajo 5.000 suscriptores), yo hoy recomendarÃa empezar en Beehiiv o Substack y migrar a dominio propio cuando tengas masa crÃtica y puedas sostener el calentamiento. Aprendà esto de la forma cara.
¿El one-click unsubscribe es realmente obligatorio para Gmail?
Desde febrero 2024, Google lo exige para senders que mandan más de 5.000 emails diarios a cuentas Gmail. Para volúmenes menores es técnicamente opcional pero altamente recomendado. El header List-Unsubscribe-Post: List-Unsubscribe=One-Click (RFC 8058) le dice a Gmail que puede procesar la baja automáticamente sin abrir el email. Si no lo tenés, los usuarios que quieren darse de baja van a marcar como spam en vez de buscar el link de unsubscribe — y eso destruye tu reputación mucho más rápido que cualquier problema técnico.
Entonces, ¿qué harÃa diferente?
Lo que aprendà en tres semanas de debugging es que el problema de email deliverability tiene dos capas completamente distintas: la capa técnica (SPF/DKIM/DMARC) que podés controlar, y la capa de reputación/engagement que está parcialmente en manos de Google y que cambia las reglas sin avisarte.
En la capa técnica, está todo al dÃa: subdominios separados para transaccional y marketing, DMARC en p=reject después de 60 dÃas de monitoreo, one-click unsubscribe implementado, list headers completos. Eso lo puedo controlar, lo controlo.
En la capa de reputación, aprendà a jugar defensivo: segmentar la lista y mandar primero a los más engaged, limpiar bounces y aperturas nulas cada 90 dÃas, y aceptar que un porcentaje de usuarios Gmail van a vivir en spam sin importar lo que haga. No es una falla de implementación — es una feature del monopolio.
La pregunta incómoda con la que empecé — ¿tiene sentido tener newsletter propio en 2025? — la respondo asÃ: tiene sentido si entendés que estás construyendo infraestructura propia con todos los costos de mantenimiento que eso implica. No es plug-and-play. Es lo mismo que decidir hostear tu propia base de datos versus usar un SaaS gestionado. Podés hacerlo, pero sabé por qué lo estás haciendo.
Lo mismo que aprendà cuando la bailarina con ALS controló una performance con ondas cerebrales: el control total sobre la infraestructura tiene un costo real, y a veces la abstracción correcta es dejar que otro maneje la capa difÃcil.
Yo sigo con dominio propio. Pero ahora sé exactamente con qué estoy lidiando.
¿Vos tenés newsletter propio? ¿Cómo estás manejando el deliverability en Gmail? Dejame saber en los comentarios — tengo curiosidad si encontraron algo que yo no probé.
