Gmail, SPF, DKIM, DMARC y 3 semanas de infierno: el 99% de reputación no alcanza

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:[email protected]; 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:[email protected]?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é.