SMTP dedicado y dominios de envío

De un lado está un servicio de envío: la infraestructura de envío incluida en la propia plataforma o un proveedor externo conectado por SMTP o por API, como un proveedor de email transaccional con el que ya tienes una cuenta. Del otro lado está tu DNS: la zona donde publicas los registros que le dicen al mundo receptor qué servidores pueden enviar en tu nombre, en qué firmas confiar y qué hacer cuando algo no pasa esas pruebas. En medio está AppBO, con las plantillas, las campañas, los emails de los flujos de trabajo y el estado de supresión de cada contacto.

Esto se configura porque la entregabilidad es una propiedad del dominio, no del mensaje. Conectar un buzón toma prestada la reputación de un dominio existente y se limita a un volumen a escala humana. Un dominio de envío dedicado (normalmente un subdominio reservado para el email de marketing) te da una reputación que controlas, margen de volumen y una separación que protege tu dominio corporativo principal si una campaña sale mal. El costo es que el trabajo es tuyo: los registros de autenticación, el calentamiento, la higiene de la lista y el monitoreo ahora te tocan a ti.

La decisión que vale la pena tomar a conciencia es si envías por la infraestructura incluida en la plataforma o si traes tu propio proveedor. La incluida es más rápida para empezar y la plataforma se encarga del relay. Traer tu propio proveedor te da sus propias analíticas, listas de supresión y herramientas de reputación, y te permite mantener una sola identidad de envío en varios sistemas. En cualquiera de los dos casos el trabajo de DNS es el mismo, y en cualquiera de los dos los registros se tienen que publicar en el dominio de envío, no en el dominio que por casualidad aloja el sitio web.

1. Elige el dominio de envío. Lo habitual es un subdominio del dominio de la marca, porque su reputación queda separada del correo corporativo del que depende el equipo. Mantenlo claramente relacionado con la marca: quien lo recibe debe ver el remitente y confiar en él.
2. Confirma que controlas el DNS de ese dominio y que puedes agregar registros TXT y CNAME. Si un tercero administra la zona, consigue ese acceso antes de empezar; un dominio de envío configurado a medias envía peor que no tener dominio de envío.
3. Decide si vas a usar el envío incluido en la plataforma o a conectar tu propio proveedor. Si es tu propio proveedor, crea la cuenta, verifica el dominio ahí y genera las credenciales o la API key que le vas a dar a la plataforma.
4. En la configuración de email de la subcuenta, agrega el dominio de envío. La plataforma te va a mostrar los registros exactos que debes publicar. Usa los valores que genera en lugar de copiar ejemplos de cualquier otro lado, incluida esta página.
5. Publica el registro SPF. SPF es un registro TXT en el dominio de envío que nombra a los remitentes autorizados. Un dominio solo puede tener un registro SPF, así que combina en lugar de agregar un segundo; además, SPF tiene un límite de consultas, así que un registro que encadena muchos includes puede fallar sin avisar. Valídalo con una herramienta de verificación después de publicarlo.
6. Publica los registros DKIM tal como te los dan. Normalmente son registros CNAME o TXT en un hostname con un prefijo de selector. La cadena del selector importa y es específica de tu remitente, así que cópiala al pie de la letra.
7. Publica un registro DMARC en el dominio. Empieza en modo de monitoreo para recibir reportes sin rechazar tu propio correo, e incluye una dirección para reportes que de verdad vayas a leer.
8. Decide la configuración del sobre y del return-path. Para la alineación, el dominio del return-path debe estar alineado con el dominio del remitente visible; la plataforma o el proveedor te dirá qué registro publicar para esto, muchas veces un CNAME dedicado.
9. Agrega el registro del dominio de seguimiento si la plataforma lo ofrece. Un seguimiento de clics y aperturas que reescribe los enlaces hacia un dominio que coincide con tu dominio de envío se ve mucho menos sospechoso para los filtros que un rastreador compartido genérico.
10. Espera a que el DNS se propague y después verifica dentro de la plataforma. No te saltes el paso de verificación de la propia plataforma: un registro que resuelve públicamente igual puede rechazarse por un error de formato.
11. Verifica la autenticación por tu cuenta desde el lado receptor. Envía una prueba a una dirección que controles en uno de los proveedores grandes e inspecciona los encabezados recibidos: SPF pass, DKIM pass y alineación DMARC. Trata un resultado neutral o de soft-fail como una falla.
12. Configura la identidad del remitente: nombre del remitente, dirección del remitente en el dominio nuevo y una dirección de respuesta que llegue a un buzón que alguien revise. El correo desde una dirección que nadie revisa atrae quejas.
13. Agrega los elementos de cumplimiento antes de la primera campaña: una dirección postal física en el pie, una baja de un clic que funcione y un enlace de preferencias. Confirma que la baja de verdad se registra en el estado de supresión de la plataforma.
14. Calienta el dominio. Empieza con volúmenes pequeños hacia tus contactos más activos, aumenta poco a poco durante varias semanas y deja que el ritmo lo decida la interacción, no un calendario. Un dominio frío que envía una lista completa de una sola vez es la forma clásica de ganarse un problema de reputación duradero.
15. Configura el monitoreo: vigila la tasa de rebote, la tasa de quejas y los reportes DMARC, y regístrate en las herramientas para administradores de correo (postmaster) de los proveedores grandes donde existan, para poder ver la reputación en lugar de adivinarla.
16. Documenta qué dominio envía qué tráfico, y asigna las campañas al dominio dedicado mientras dejas el correo de conversaciones uno a uno en los buzones conectados.

De la plataforma al servicio de envío

• El mensaje armado: nombre y dirección del remitente, destinatario, asunto, partes en HTML y en texto plano, encabezados y archivos adjuntos.
• Los encabezados List-Unsubscribe y el enlace de baja, cuando la plataforma los genera.
• Encabezados personalizados o etiquetas que identifican la campaña o el flujo de trabajo, que después sirven para segmentar los reportes del lado del proveedor.
• Las URL de clic reescritas que apuntan al dominio de seguimiento, y el píxel de seguimiento de aperturas, cuando el seguimiento está activado.
• La dirección del destinatario, después de que la plataforma aplicó sus propias revisiones de supresión. Un contacto suprimido nunca debería llegar al relay.

Del servicio de envío a la plataforma

• La aceptación o el rechazo de cada mensaje al enviarlo.
• Eventos de entrega: entregado, diferido, rebotado, con el rebote clasificado como duro o suave.
• Notificaciones de quejas y reportes de spam, que deberían marcar al contacto como dado de baja o suprimido.
• Eventos de apertura y clic, cuando el seguimiento está activado y el proveedor los reporta de vuelta.
• Señales de baja que vienen del mecanismo de baja de un clic del propio proveedor o del proveedor del buzón.

Del DNS al mundo receptor

• SPF: qué hosts pueden enviar en nombre del dominio.
• Las llaves públicas DKIM bajo sus selectores, para que los receptores puedan verificar la firma de cada mensaje.
• La política DMARC y las direcciones para reportes.
• Los registros del return-path y del dominio de seguimiento, que dan la alineación y una ruta de clics con tu marca.

Lo que no se mueve

• La reputación. Se gana por dominio y por IP de envío, y no se puede transferir, comprar ni reiniciar cambiando de proveedor. Un dominio nuevo simplemente empieza desde cero.
• Las listas de supresión entre sistemas. Una supresión del lado del proveedor y una del lado de la plataforma son almacenes separados, a menos que la integración las sincronice de forma explícita; verifícalo en lugar de suponerlo.
• Las respuestas. Un relay de envío entrega el correo saliente; las respuestas entrantes necesitan un buzón que alguien revise o una integración de buzón conectado.
• El historial de envíos o el avance del calentamiento cuando mueves el dominio a otro proveedor.
• La revisión del contenido. Nada en el DNS ni en el relay revisa si un mensaje cumple con la ley de marketing de la jurisdicción del destinatario.

Escenario: una clínica que ya superó el envío desde buzones monta un subdominio de marketing dedicado y lo calienta durante un mes.

1. El equipo elige un subdominio de marketing del dominio de la marca de la clínica y confirma que la gerente de la clínica puede editar el DNS en el registrador.
2. Agregan el dominio de envío en la configuración de email de la subcuenta. La plataforma genera el valor SPF, dos selectores DKIM, un registro de return-path y un registro de dominio de seguimiento.
3. La gerente los publica todos. El registro SPF que ya existe en el dominio principal no se toca; el registro nuevo va en el subdominio, y así se evita tener un segundo registro SPF en un mismo nombre.
4. Se publica un registro DMARC en modo de monitoreo, con una dirección para reportes que reenvía a la bandeja de entrada de marketing.
5. Después de la propagación corren la verificación de la plataforma, que pasa, y luego envían una prueba a direcciones personales en dos proveedores de correo distintos.
6. Inspeccionan los encabezados recibidos en ambos: SPF pass, DKIM pass con el selector esperado y DMARC alineado. Al principio una prueba muestra que DKIM falla porque se perdió un carácter al final al pegar el registro; lo vuelven a publicar y prueban de nuevo.
7. Configuran la dirección del remitente en el subdominio nuevo y como dirección de respuesta el buzón de consultas de la clínica, que sí se revisa, y luego arman el pie con la dirección postal y el enlace de baja.
8. Semana uno del calentamiento: un boletín corto a los pocos cientos de contactos que abrieron algo en el último mes. La tasa de rebote es insignificante y las aperturas son altas.
9. Semana dos: la audiencia se amplía a los contactos activos en los últimos tres meses, con aproximadamente el doble de volumen. Unos cuantos rebotes duros se suprimen automáticamente.
10. Semana tres: contactos activos en el último año. La tasa de quejas sube un poco, así que mantienen el volumen igual en un segundo envío en lugar de aumentarlo.
11. Semana cuatro: la lista activa completa. Los reportes DMARC muestran que todo el correo se autentica desde las fuentes esperadas, sin ningún tercero enviando como el subdominio.
12. Después se cambia un flujo de trabajo para que los emails de recordatorio de citas también usen el subdominio, mientras las respuestas uno a uno siguen saliendo por el buzón conectado de cada profesional.
13. De forma continua: una revisión mensual de las tasas de rebote y de quejas, una revisión trimestral de los reportes DMARC y una decisión pendiente para endurecer la política DMARC de monitoreo a una configuración más estricta cuando los reportes lleven un trimestre completo limpios.

Límites de uso

Hay tres topes que se suman. La plataforma limita qué tan rápido le entrega los mensajes al relay, el proveedor limita los envíos según tu plan y cada proveedor de buzones receptor frena a los remitentes desconocidos de forma independiente de los otros dos. El tercero es el que duele: un proveedor receptor prefiere diferir que rechazar, así que una campaña parece enviarse y después avanza a paso de tortuga. Consulta los límites de envío que publica tu proveedor y las guías para administradores de correo de los proveedores receptores en lugar de suponer cifras, y baja el ritmo a propósito durante el calentamiento en lugar de que te lo bajen sin querer.

Reintentos e idempotencia

El relay reintenta los rebotes suaves y los diferidos durante un periodo; los rebotes duros no se reintentan y tienen que suprimir la dirección de inmediato. El riesgo de duplicado es un envío que se agota por tiempo después de ser aceptado, así que nunca vuelvas a correr una campaña para recuperarte de una falla ambigua: primero revisa qué se entregó de verdad. Los envíos desde flujos de trabajo necesitan la misma disciplina que cualquier otro: ánclalos a un solo disparador y protégelos con una etiqueta, porque un flujo que se vuelve a ejecutar sobre una lista activa es a la vez un duplicado y un generador de quejas.

Trampas al mapear campos

El dominio del remitente visible y el dominio del return-path tienen que estar alineados para que DMARC pase, y es perfectamente posible que SPF y DKIM pasen los dos mientras la alineación falla; por eso lees los encabezados en lugar de confiar en una palomita verde. Un solo registro SPF por nombre, y el límite de consultas es real: encadenar includes de varios proveedores puede romper SPF para todos. Los selectores DKIM son específicos de cada remitente, así que un registro de ejemplo copiado no autentica nada. Los campos de combinación vacíos se muestran como texto de marcador literal en los asuntos, que es donde más se notan.

Creación de duplicados

Los envíos duplicados vienen de un mismo contacto que está en dos segmentos de una campaña, de un registro de contacto duplicado por un formulario que relaciona por otro campo y de correr una campaña dos veces después de una falla parcial. El estado de supresión duplicado es el problema más sutil: un contacto dado de baja en el proveedor pero todavía activo en la plataforma se va a seguir enviando y se va a seguir descartando, lo que infla tu volumen aparente y esconde la señal real de quejas.

Pruebas contra producción

La mayoría de los proveedores ofrece un modo de prueba o un entorno de pruebas que acepta mensajes sin entregarlos, lo cual sirve para comprobar la conexión con el relay y no sirve para comprobar la entregabilidad. La reputación solo se construye en producción. Mantén un dominio de prueba aparte para armar los flujos de trabajo, y nunca calientes un dominio con tráfico de prueba hacia listas semilla. Así es como un dominio nuevo queda bloqueado antes de su primera campaña real.

Vencimiento de la autenticación

Las credenciales SMTP y las API keys se pueden rotar o revocar en el proveedor, y una llave rotada por buenas razones de seguridad deja de enviar sin ningún aviso dentro de la plataforma. El DNS es el otro riesgo de vencimiento: una migración de zona, un cambio de registrador o una limpieza bien intencionada eliminan los registros DKIM, y el correo empieza a fallar la autenticación aunque se siga aceptando. Mantén un inventario de los registros y vuelve a verificar después de cualquier trabajo en el DNS.

Lo que se rompe con más frecuencia

• Un segundo registro SPF agregado para una herramienta nueva, que invalida SPF para todo.
• Un registro DKIM truncado por una interfaz de DNS que divide mal los valores TXT largos.
• DMARC endurecido a una política estricta antes de que los reportes estuvieran limpios, lo que rechaza el propio correo del negocio.
• Enviar una lista comprada o extraída de internet desde un dominio nuevo, lo que acaba con la utilidad del dominio en una sola campaña.
• Un dominio de seguimiento que apunta al host equivocado, lo que rompe todos los enlaces de todos los emails a la vez.
• Enlaces de baja que no se registran en la supresión, así que los contactos dados de baja siguen recibiendo correo y empiezan a quejarse.
• Una dirección de respuesta que se revisaba y que sin que nadie lo note deja de revisarse después de un cambio en el equipo.
• Imágenes y enlaces alojados en un dominio sin relación con el remitente, algo que algunos filtros cuentan en tu contra.