Deja de adivinar por qué tus emails caen en spam. Paga una vez, entérate.

Qué contiene realmente la auditoría

El informe no es un dump de screenshots de herramientas de terceros pegados en un PDF. Es un deliverable que tu equipo de ingeniería puede accionar línea por línea. Estructura:

Sección 1 — Resumen ejecutivo. Una página. El hallazgo único más importante, las tres cosas que van a mover la aguja más rápido, y el esfuerzo estimado para shipear cada una.

Sección 2 — DNS y autenticación. Estado exacto actual de SPF (cada include resuelto, recomendación de flattening si estás cerca del límite de 10 lookups), DKIM (rotación de selector, longitud de clave, cobertura de headers por la firma), DMARC (política, porcentaje, direcciones de reporte, muestra de reporte agregado), MTA-STS (modo y TTL), TLS-RPT, BIMI (VMC readiness), consumo y producción ARC. Cada item recibe un flag (verde / ámbar / rojo), la remediación y la justificación.

Sección 3 — rDNS e higiene de IP. Cadena PTR completa para cada IP de envío. Consistencia de hostname. Alineación HELO/EHLO. Exposición a aproximadamente sesenta RBLs y qué significa cada listing en la práctica — no todas las blacklists son iguales, y las puntuamos por impacto de receiver más que por conteo de listings. Para senders IPv6, revisamos la alineación AAAA y el setup de PTR IPv6 que un número sorprendente de proveedores hace mal.

Sección 4 — Patrón de envío y reputación. Curva de volumen 90 días, trayectoria de bounce-rate, trayectoria de queja, tendencia de engagement. Puntos de inflexión correlacionados con cambios de comportamiento (¿compraste una lista? ¿cambiaste la config del MTA? ¿cambiaste de proveedor de warmup?). Señales de reputación específicas por ISP donde podemos leerlas — Gmail Postmaster Tools, Yahoo sender hub, Microsoft SNDS.

Sección 5 — Configuración MTA. Si corres tu propio MTA, leemos la config. PowerMTA: definiciones VMTA, throttling por dominio, settings de cola, integración con feedback loops. Postfix: smtpd restrictions, header checks, TLS policy maps. MailWizz / Acelle: configuración de delivery server, bounce server, settings de lista. Cloud relay: la configuración específica de tu tenant en SendGrid/SES/Mailgun.

Sección 6 — Riesgo de contenido. Patrones de subject line flagueados por filtros spam modernos, reputación de links (chequeamos tus links contra los mismos agregadores que usa Gmail), ratio imagen/texto, peso HTML, cumplimiento de estructura HTML (74% del correo falla esto en los benchmarks 2025 — anidamiento inválido, atributos faltantes, violaciones de accesibilidad — todo afecta medibalmente al placement), estrategia del pixel de tracking, ubicación del "click here" y del "unsubscribe". Calidad del alternativo plain-text.

Sección 7 — Lista y engagement. Distribución de códigos de bounce (4xx vs 5xx, transiente vs permanente), exposición a dominios catch-all, concentración de direcciones role, profundidad de segmentación por engagement. Si puedes mandarnos una muestra (anonimizada si hace falta), corremos una pasada de calidad de lista que refleja lo que una buena herramienta de MX-hygiene haría.

Sección 8 — Hoja de ruta priorizada. La parte a la que la mayoría de auditorías nunca llega. Cada hallazgo se convierte en un ticket: qué shipear, en qué orden, con qué estimación de esfuerzo, y con el impacto esperado específico. Los escribimos para que un ingeniero competente pueda cerrar el ticket sin input adicional de nosotros.

Sección 9 — Anexo. Datos raw completos: output de checks de blacklists, JSON de inbox placement de la seed list, muestras de DMARC agregado, trazas de cadena ARC, screenshots donde sean útiles. La evidencia detrás de cada afirmación.

Los hallazgos que nuestros competidores ni siquiera buscan

Mucho de lo que sale mal con la entregabilidad en 2026 está por debajo del nivel que las herramientas de seed list pueden ver. Cinco hallazgos recurrentes de nuestro dataset de auditoría, compartidos como insight gratuito para que tu equipo los chequee mañana mismo.

El purgatorio DMARC p=none

Aproximadamente el 62% de los senders B2B que auditamos tenían un registro DMARC publicado pero con p=none — es decir, le decían a los ISP "observa pero no apliques". Muchos de esos registros llevan más de dos años en p=none, que es donde se esconde el problema. Un DMARC no aplicado te da reportes pero no protección, y cada mes que se mantiene en ese estado, tu dominio le parece a los filtros spam sofisticados un sender que puso DMARC como checkbox y luego se olvidó. Esa señal reputacional es sutil y acumulativa. Pasar a p=quarantine pct=10, luego pct=50, luego p=reject en una ventana de seis semanas es el cambio de mayor ROI en la mayoría de auditorías. La data 2025 confirma cuán raro es el enforcement DMARC adecuado: solo el 7,6% de los top 10 millones de dominios tenían p=quarantine o p=reject configurado.

Drift de cadena PTR a lo largo del bloque de IPs

Cuando agregas IPs al pool de envío a lo largo del tiempo, es común que el PTR de la primera IP esté configurado correctamente (mail1.example.com con confirmación forward/reverse) mientras que las últimas tres IPs del bloque no tienen PTR o tienen el default genérico del ISP (1-2-3-4.provider.net). Gmail y Microsoft penalizan PTR no alineado agresivamente — el diagrama de la sección anterior muestra los cuatro patrones de ruptura comunes. El fix es cinco minutos por IP; el punto ciego es que nadie chequea el bloque entero a la vez.

Nesting SPF contra el muro de 10 lookups

Cada lookup DNS en tu cadena de includes SPF cuenta contra un tope duro de 10 (RFC 7208 §4.6.4). La mayoría de senders cruza ese tope cuando agrega un tercero nuevo (una herramienta de encuestas, un proveedor transaccional, un nuevo proveedor de payroll) sin auditar los includes existentes. Una vez cruzado, la evaluación SPF falla silenciosamente — devolviendo permerror — que los receivers interpretan como "este sender no puede autenticarse". Puedes estar en ese estado semanas antes de que alguien note la bajada de reputación. Nuestra auditoría cuenta lookups recursivamente, identifica el include responsable de tirarte por encima, y recomienda flattening SPF (reemplazar el include con los rangos IP resueltos) donde aplica. También flagueamos el segundo modo de fallo silencioso: temperror, donde uno de tus includes hizo timeout, que los receivers tratan como inconcluso y que infla tu spam score durante el tiempo del outage.

Mismatch de política MTA-STS

Los senders que publican una política MTA-STS a menudo configuran mal el modo. Correr MTA-STS en testing está bien; correrlo en enforce con una política que no matchea tus MX reales hace que el correo legítimo sea rebotado por receivers que honran el estándar. Vemos esto con más frecuencia después de migraciones donde el MX se cambió pero la política MTA-STS no se actualizó, o donde se añadió un balanceador sin incluir el nuevo hostname en el archivo de política MTA-STS. El camino del fix importa: no puedes simplemente flippear de testing a enforce de la noche a la mañana por la propagación TLS-RPT; el patrón estándar es testing por 30 días vigilando los reportes TLS-RPT, luego enforce.

Corrupción de cadena ARC en correo reenviado

Este es el hallazgo que la mayoría de competidores no buscan. ARC (Authenticated Received Chain, RFC 8617) es el protocolo que permite al correo sobrevivir el reenvío a través de listas de distribución, gateways de seguridad, sistemas de tickets y alias de grupo sin romper SPF y DKIM. Si publicas enforcement DMARC (p=quarantine o p=reject) sin antes verificar que tu dominio consume cabeceras ARC adecuadamente, el correo legítimo reenviado empieza a ser cuarentenado por los receivers — y a ti te culpan por la pérdida. Verificamos si tu ruta de correo entrante valida cadenas ARC correctamente cuando están presentes, y si tu ruta de envío produce cabeceras ARC cuando relayas para otros. La mala configuración ARC es una razón silenciosa de "implementamos enforcement DMARC y nuestros reply rates cayeron" — el tipo de hallazgo que paga la auditoría diez veces porque la alternativa es revertir el enforcement DMARC entero y perder la ganancia de reputación.

Taxonomía de blacklists: qué RBLs realmente importan, y cuáles son ruido

Si chequeas tu IP en MXToolbox vas a ver una lista de unas ochenta blacklists, con quizás dos o tres mostrando "listed". Pánico. La realidad es que esas ochenta RBLs no son equivalentes — tienen metodologías, tasas de adopción de receiver y impacto operacional drásticamente distintos. Un listing en Spamhaus SBL es un evento que termina con tu programa; un listing en UCEPROTECT-3 es un evento informativo en el que ningún receiver mayor actúa. Confundir los dos es una de las maneras más comunes de que los clientes pasen dos semanas en pánico por un no-problema mientras uno real se pudre.

Parte de cada auditoría es contextualizar tu exposición a blacklists. Separamos los listings en "shipear fix esta semana", "vigilar esto" e "ignorar — el dashboard es alarmista". Este es el tipo de juicio que distingue a un ingeniero senior de una herramienta que cuenta listings: un listing en Spamhaus SBL en una de tus IPs es una conversación distinta a doce listings UCEPROTECT-3 desparramados por tu pool de envío, y los dashboards que reportan ambos con la misma exclamación roja no te están haciendo ningún favor.

Tres tipos de auditoría que vemos repetidamente en LATAM

El paisaje de email en español tiene patrones que cambian las prioridades del informe. Tres ejemplos representativos de auditorías reales en mercado hispano (anonimizados; los números son típicos de cada caso, no de un cliente específico).

Caso A — Empresa colombiana de servicios públicos enviando facturas electrónicas DIAN. Volumen: 280.000 envíos al mes (factura electrónica + recordatorios de pago). Síntoma: los clientes finales reclamaban no recibir la factura, el call center se inundaba el tercer día de cada mes. Hallazgos: PowerMTA tenía VMTAs separados pero el throttling estaba pegado en valores conservadores de 2018, no actualizados a las exigencias de Gmail/Outlook 2025. Adicional, MTA-STS publicada en modo enforce con política que apuntaba al MX viejo tras una migración. Los receivers que honran MTA-STS estaban rechazando silenciosamente entre 12% y 18% de los envíos. Fix: actualizar política MTA-STS a los MX vigentes, recalibrar throttling por VMTA según placement real por ISP. Tiempo de remediación: 2 días. Reducción de reclamos al call center: superior al 70% en el siguiente ciclo de facturación.

Caso B — Fintech mexicana enviando notificaciones transaccionales y promocionales mezcladas. Volumen: 1,2M envíos mensuales. Síntoma: las notificaciones de cargo (críticas, esperadas por el usuario) caían a Promociones de Gmail México con frecuencia creciente. Hallazgos: las IPs transaccionales y las marketing compartían pool. Una campaña promocional con engagement bajo arrastró la reputación de IP del pool entero a un nivel donde Gmail latam empezó a clasificar todo el tráfico como promotional. Fix: separación dura de pools (transaccional dedicado + marketing dedicado), DKIM con selectores distintos por propósito, From/Reply-To de subdominios separados (alertas.dominio.com vs promo.dominio.com). Tiempo: 5 días incluyendo planning de DNS. Recuperación de placement transaccional al inbox principal: 3 semanas.

Caso C — Agencia de outbound B2B argentina con 22 clientes. Volumen agregado: 80.000 cold emails al mes. Síntoma: el reply rate cayó del 4,2% al 1,8% en seis semanas pese a que los copies y las listas no habían cambiado. Hallazgos: la agencia compartía pool de buzones entre clientes. Un cliente nuevo cargó una lista mal segmentada con 6% de bounces, generó quejas y la reputación del pool entero cayó. Microsoft empezó a aplicar 421-4.7.32 a buzones del pool. Fix: separación de buzones por cliente, retiro del cliente problemático del pool compartido a uno aislado, warm-up de recuperación para los buzones afectados. Tiempo: 12 días. Reply rate volvió al 4,1% en cuatro semanas, perdieron 0 clientes finales en el proceso.

Metodología — los 16 puntos que revisamos en cada auditoría

El informe Standard cubre los siguientes 16 puntos de inspección, en este orden de prioridad. Algunos toman 10 minutos, otros una hora — el tiempo total promedia 6 a 8 horas de ingeniero por auditoría.

1. Cadena SPF resuelta hasta el final — cuántos lookups consume, dónde está el riesgo de PermError por superar 10, candidatos a flattening.
2. DKIM activo — selector vigente, longitud de clave (Yahoo rechaza claves bajo 1024-bit), set de headers firmados, frecuencia de rotación.
3. DMARC publicado y aplicado — política, porcentaje, alineación, dirección de reporte, lectura de los XML agregados de los últimos 30 días.
4. MTA-STS y TLS-RPT — modo (testing vs enforce), MX que la política referencia, TTL, certificados.
5. BIMI y VMC readiness — DMARC al menos en p=quarantine, registro BIMI publicado, candidatura para VMC si vale el ROI.
6. rDNS por IP — PTR completo y consistente para cada IP del bloque (no solo la primera), forward-confirmed reverse DNS, alineación HELO/EHLO.
7. Histórico de blacklists — chequeo cruzado contra ~60 RBLs públicas, contextualización del impacto real (no todas las listas pesan igual).
8. Reputación Google Postmaster Tools — domain reputation, IP reputation, spam rate, authentication rate, encryption rate.
9. Reputación Microsoft SNDS y JMRP — color de IP, complaint rate, trap hits, suscripción a JMRP activa.
10. Reputación Yahoo / Verizon Media — sender hub data, complaint feedback loop activo.
11. Configuración MTA — leemos pmta.conf, virtual MTAs, throttling por dominio, schedules de retry, clasificación de bounces, integración con FBLs.
12. Patrón de envío 90 días — curva de volumen, bounce rate, complaint rate, engagement, correlación con cambios operativos.
13. Riesgo de contenido — patrones de subject flagueados, reputación de links, ratio imagen/texto, peso HTML, calidad del plain-text alternativo.
14. Higiene de lista — distribución de bounce codes, exposición a catch-all, concentración de role addresses, segmentación por engagement.
15. Test de inbox placement — envío real desde tus IPs a una seed pool propia con cuentas en Gmail, Outlook, Yahoo, iCloud, Office 365 corporativo y proveedores LATAM relevantes.
16. Hoja de ruta priorizada — cada hallazgo se convierte en ticket con esfuerzo estimado, impacto esperado y orden de aplicación. Esto es lo que tu equipo realmente shippea.

Agencias hispanohablantes en modo white-label

Una porción significativa de nuestras auditorías llega a través de agencias de marketing digital o consultoras de email con sede en Madrid, Barcelona, Ciudad de México, Bogotá, Buenos Aires, Santiago o Lima. El modelo: la agencia diagnostica al cliente, identifica que necesita análisis técnico profundo, y subcontrata la auditoría a Blue Spirit con marca propia.

Cómo opera el white-label en la práctica. Tú (la agencia) recoges los materiales del cliente final con tu nombre. Nos los pasas; nuestros ingenieros corren la auditoría. Te entregamos el informe en formato editable con tu logotipo, tu paleta de colores y los textos de presentación a tu manera. Tú lo entregas al cliente final. El walkthrough call lo hacemos contigo presente — el cliente final no necesita saber que hay un proveedor europeo detrás, salvo que prefieras hacer la presentación tú con nuestros notes.

Pricing white-label: 20% de descuento sobre lista para 5+ auditorías al mes facturadas trimestralmente. NDAs cruzadas, presunción de confidencialidad, cero referencia pública al cliente final. Para agencias que cobran consultoría a 80-150 € la hora y necesitan respaldar afirmaciones técnicas con un informe defendible, esto cierra el cuadro.