Entregabilidad de correo para anuncios de adultos: por qué el código de verificación nunca llega

El fallo del que nadie recibe una alerta

Un usuario nuevo se registra, introduce una dirección de correo y espera el código de seis dígitos que le permite completar la verificación de edad. No llega en el minuto que debería. Puede que aparezca en la carpeta de spam diez minutos después, mucho después de que el usuario se haya rendido y haya cerrado la pestaña. Puede que el servidor de correo receptor lo rechace directamente en el momento del envío, con un mensaje de rebote que pasa desapercibido en un registro que nadie está mirando. En cualquier caso, nada en la experiencia le dice al operador que algo ha ido mal. El embudo de registro simplemente muestra un visitante más que introdujo una dirección de correo y nunca volvió, indistinguible de alguien que simplemente cambió de opinión.

Esa ambigüedad es el verdadero problema, más que cualquier causa técnica concreta. La mayoría de los sitios controla si un correo se envió, una marca verde en un panel, no si realmente llegó ante una persona. Son dos eventos distintos, y la brecha entre ambos es exactamente donde un problema de entregabilidad se esconde durante meses. Un operador que nunca ha tenido una caída de hosting o un bloqueo del procesador de pagos puede seguir perdiendo una parte real de registros nuevos por un problema de correo que no tiene forma de notar, porque no hay incidente, no hay ticket de soporte, no hay panel que se ponga en rojo.

Este es un tipo de riesgo de proveedor distinto al de aquel que cierra una cuenta de hosting con un aviso que cita una cláusula que nadie ha vuelto a leer desde que la firmó. Un host suspendido es ruidoso: el sitio se apaga, y el operador se entera en minutos porque los clientes lo dicen y el panel también. Un problema de entregabilidad es silencioso por diseño. La cuenta de envío sigue abierta, la factura mensual sigue llegando, y el único síntoma visible es un embudo de registro que pierde gente en el último paso por razones que, desde el lado del operador, parecen abandono normal y no un fallo técnico solucionable.

La causa de fondo sigue siendo el mismo tipo de fricción de categoría que aparece con hosts, bancos y procesadores de pago. Los proveedores de bandeja de entrada y los servicios de envío de correo puntúan esta categoría como de mayor riesgo que la mayoría, algunos de forma explícita y por nombre, y un dominio nuevo sin historial de envío empieza cada mensaje con una desventaja que no tiene nada que ver con lo que dice realmente el mensaje.

Por qué esta categoría se filtra más que la mayoría

Los filtros de spam y los proveedores de servicio de correo no tratan todos los sectores igual, y merece la pena leer las diferencias antes de darse de alta que después de que una cuenta sea marcada. La política publicada por SendGrid sobre contenido prohibido enumera, como puntos separados, «pornografía o contenido sexualmente explícito» y, de forma distinta, «servicios de acompañantes, búsqueda de novias o cónyuges por correspondencia, agencias matrimoniales internacionales y servicios similares». Esa segunda categoría no trata de lo que contiene el correo. Nombra el propio negocio como motivo de exclusión, lo que significa que un código de verificación en texto plano enviado por un directorio de acompañantes puede quedar fuera de la política solo por la categoría, sin importar lo sobrio que sea el mensaje.

La política de uso aceptable de Mailgun traza la línea en otro sitio completamente distinto. Su sección de contenido prohibido se limita a material que constituye o promueve la explotación infantil, la bestialidad o actos no consentidos, sin una cláusula separada que nombre los negocios para adultos o los servicios de acompañantes como categoría. Es una restricción bastante más estrecha que la de SendGrid, dirigida a lo que es ilegal en lugar de a qué sector está enviando. Dos proveedores grandes y generalistas, accesibles con el mismo tipo de formulario de alta, trazan la línea en lugares realmente distintos, y un operador que elige uno sin leer más allá de la página de precios no tiene forma de saber en qué lado de esa línea queda su cuenta hasta que una revisión la marca.

Es el mismo vacío de diligencia debida que sorprende a los operadores con una cláusula de rescisión de hosting o CDN que nunca leyeron, un nivel más abajo en la pila. La pregunta que hay que hacerse antes de elegir un proveedor de correo no es si técnicamente permite enviar correo para este tipo de negocio en general. Es si la política escrita del proveedor nombra específicamente la categoría del negocio, por escrito, antes de que salga el primer código de verificación, no después de que una revisión de abusos lo descubra.

Un dominio de envío nuevo agrava esto por encima de lo que permita el proveedor. Los filtros valoran mucho el historial y el patrón de volumen de un dominio, y un dominio que apareció hace poco y empezó de inmediato a enviar códigos automáticos a volumen se parece, para un filtro sin otra señal, al patrón de una cuenta creada para un propósito estrecho y abandonada al ser marcada. No es un juicio sobre el negocio; es una coincidencia de patrón que dispara cualquier dominio recién creado, sean o no anuncios de adultos, y solo se desvanece con el tiempo y un comportamiento de envío constante.

El mínimo técnico que todo proveedor de bandeja de entrada exige ya

Incluso un proveedor cuya política acoge la cuenta sin reservas no puede por sí solo hacer que un correo llegue a la bandeja de entrada. Desde el 1 de febrero de 2024, Google exige a todo remitente que envía correo a direcciones de Gmail, sin importar el volumen, cumplir una base documentada: como mínimo, SPF o DKIM configurados correctamente en el dominio de envío. SPF enumera qué servidores están autorizados a enviar en nombre del dominio; DKIM firma cada mensaje para que el servidor receptor pueda confirmar que no fue alterado en tránsito. Los remitentes que alcanzan 5.000 mensajes al día a direcciones de Gmail específicamente se enfrentan a un listón más alto: SPF y DKIM juntos, más DMARC publicado en el dominio, como mínimo en modo de monitorización. Un sitio de anuncios que envía códigos de verificación de edad, restablecimientos de contraseña y recibos de pago a una escala real cruza rápido ese umbral de 5.000 mensajes, ya que cada uno de ellos cuenta para el total.

Las propias directrices publicadas por Google fijan un número concreto por encima de la autenticación: los remitentes de cualquier tamaño deben mantener la tasa de quejas reportada a través de Postmaster Tools de Google por debajo del 0,30 por ciento, y las mismas directrices recomiendan quedarse por debajo del 0,10 por ciento como margen de seguridad real, en lugar de tratar el 0,30 por ciento como un objetivo cómodo al que acercarse. El incumplimiento se traduce en dos fallos distintos y documentados por separado, no en una penalización vaga. El correo que falla SPF, DKIM o DMARC puede marcarse como spam o rechazarse directamente con el error SMTP 5.7.26. Los remitentes que superan la cuota de envío que Google les permite chocan con un muro distinto, un error de limitación 4.7.28. Ninguno de los dos anuncia «este sector no es bienvenido aquí». Ambos parecen, desde el panel de un desarrollador, un fallo técnico corriente, y por eso precisamente tienden a notarse semanas después en lugar de arreglarse el día en que empiezan.

Yahoo, cuya infraestructura también da servicio a las direcciones de AOL, publica de forma independiente el mismo tipo de requisito: SPF y DKIM, una política DMARC de al menos p=none que debe pasar la verificación, y el mismo techo del 0,30 por ciento en la tasa de quejas, en vigor con el mismo calendario desde febrero de 2024. Un operador que resuelve esto para Gmail y asume que Yahoo y AOL seguirán el mismo camino suele acertar en la mecánica, ya que los dos proveedores han convergido en cifras casi idénticas, pero los dos sistemas siguen midiendo y aplicando las reglas por separado, así que un dominio en regla con uno no está automáticamente en regla con el otro.

Un requisito de este conjunto está escrito de forma deliberadamente estrecha. La baja con un clic, mediante la cabecera List-Unsubscribe, se aplica específicamente a mensajes de marketing y mensajes suscritos, según las propias palabras de Google. Un código de verificación o un recibo de pago no son ni una cosa ni la otra, así que no es a eso a lo que apunta esa línea en concreto. Los requisitos de autenticación y reputación por encima de ella, SPF, DKIM, DMARC y el techo de quejas, no están limitados de esa manera: se aplican a todo mensaje que envíe un dominio, transaccional incluido.

El error que arrastra hacia abajo también al correo importante

La forma más común en que un operador daña sus propios correos de verificación es enviar correo de marketing desde el mismo dominio que envía los códigos de verificación y los recibos de pago. La reputación se mide sobre todo a nivel de dominio y subdominio de envío, por lo que separar los flujos ayuda, pero el aislamiento entre subdominios no es absoluto: un pico de quejas en un subdominio puede seguir registrándose en el dominio principal, sobre todo si ambos flujos comparten la misma identidad de firma DKIM entre bastidores. Un correo promocional que anuncia una nueva función o una oferta de temporada, enviado a una lista que ya está desactualizada, produce exactamente el tipo de pico de quejas que puede hundir la reputación de un dominio compartido, y parte de ese daño alcanza al código de verificación que un usuario recién registrado está esperando justo ahora, un mensaje que no tiene nada que ver con el envío de marketing que causó el problema.

Es también aquí donde la disciplina operativa construida en torno a la verificación de edad se entrelaza con un problema puramente técnico de entrega de correo de una forma fácil de pasar por alto. Un flujo de verificación que depende de que un código llegue a una bandeja de entrada es tan fiable como lo sea la reputación del dominio de envío el día en que ese código sale, y la reputación es un recurso compartido entre todo tipo de mensaje que usa infraestructura relacionada, a menos que el operador los mantenga deliberadamente separados.

La solución es estructural, no un ajuste que se cambia después de que ya ha ocurrido un pico de quejas. Envía el correo transaccional, códigos de verificación, confirmaciones de pago, restablecimientos de contraseña, desde un subdominio dedicado que no se use para nada más, por ejemplo mail.ejemplo.com en lugar del dominio desnudo o de un subdominio de marketing compartido, y fírmalo con su propia clave DKIM en lugar de una reutilizada en todos los flujos. Envía el contenido de marketing o boletines desde un subdominio completamente distinto, como news.ejemplo.com, con sus propios registros de autenticación y su propia reputación, capaz de absorber una mala semana de quejas sin arrastrar consigo el correo que tiene que llegar sí o sí. Los dos flujos pueden pasar por la misma cuenta del proveedor, pero necesitan parecer, y estar firmados, como remitentes claramente distintos a ojos del servidor de correo receptor.

Qué comprobar de verdad esta semana

Empieza sacando la política de uso aceptable de cualquier servicio que esté enviando ahora mismo el correo transaccional del sitio, y averigua, por escrito, si nombra específicamente la categoría del negocio, del mismo modo en que funcionó antes la comprobación de los contratos de hosting y CDN para los proveedores de infraestructura. Un proveedor cuya política ya excluye la categoría por nombre no es un proveedor sobre el que construir un flujo de verificación, por fiable que haya sido hasta ahora, porque una revisión de cuenta puede acabar con esa fiabilidad sin ningún aviso previo.

Comprueba que SPF, DKIM y DMARC estén de verdad publicados y pasando la verificación en el dominio que envía ahora mismo los correos de verificación y de recibo, en lugar de darlo por hecho porque alguien los configuró una vez, hace años. Un registro DNS que era correcto cuando se escribió puede quedar obsoleto tras una migración de proveedor, y un dominio sin autenticación empieza cada mensaje con una posibilidad real de rechazo bajo las reglas que Google y Yahoo aplican desde febrero de 2024, sea cual sea el contenido del mensaje.

Separa el correo transaccional y el de marketing en subdominios distintos con claves de firma distintas si aún no lo están, y trátalo como trabajo de infraestructura y no como una decisión del equipo de marketing, ya que hacerlo mal cuesta una verificación de identidad fallida, no una venta perdida.

Vigila la tasa real de quejas a través de los propios informes del proveedor o de Postmaster Tools de Google con un calendario fijo, y trata cualquier acercamiento al 0,10 por ciento como el punto en el que investigar, no el 0,30 por ciento, ya que el 0,30 por ciento está más cerca del punto en el que el correo empieza a rechazarse que del punto en el que empieza un problema. Y de vez en cuando envía un registro de prueba real a una dirección personal de Gmail y otra de Yahoo, y cronometra cuánto tarda el código en llegar y dónde llega, porque un panel que informa de un envío correcto está informando de lo que salió del servidor, no de lo que realmente vio un usuario.