Traducción. Autoritativo: fs-msg-0008-sender-domains.md.
Contexto
La deliverability es la parte del correo en la que nadie piensa hasta que el correo deja de llegar, y para entonces el daño es reputacional y lento de revertir. Dos problemas. Reputación compartida: en un subdominio compartido, un tenant con una lista comprada arrastra la entrega de todos los demás. Dominios fríos: un dominio nuevo enviando 50 000 correos el primer día se va directo a spam, y el tenant nos culpa. Las respuestas son un dominio propio como add-on pago (DEC-F4) —que es a la vez línea de ingreso y aislamiento de reputación— y un warm-up impuesto, impopular precisamente porque funciona.Alcance (normativo)
messaging.sender_domainscon verificación de SPF, DKIM y DMARC.- Una configuración guiada que emite los registros DNS exactos a publicar.
- Calendario de warm-up impuesto para un dominio nuevo.
messaging.deliverability_metrics: tasas de rebote y queja por dominio.- Pausa automática al exceder umbrales.
- Fallback al subdominio compartido hasta que el dominio propio verifique.
Fuera de alcance (normativo)
- Comprar u hospedar DNS. Le decimos al tenant qué publicar; él lo publica.
- Pruebas de inbox placement entre proveedores — un servicio especializado.
- Reparación de reputación. Si un dominio queda en lista negra, el remedio es la conducta de envío del tenant.
Comportamiento (normativo)
- El default es un subdominio compartido por tenant (
{tenant}.softcrum.com), funcionando de inmediato. Un dominio propio es add-on (DEC-F4), incluido en enterprise. - La configuración muestra los registros DNS exactos, los verifica automáticamente y muestra cuáles faltan. “Configure SPF y DKIM” como instrucción es donde los tenants se rinden.
- Hasta que un dominio propio verifique, el envío sigue por el subdominio compartido. Un tenant nunca queda bloqueado por un cambio de DNS incompleto.
- Un dominio recién verificado entra en warm-up impuesto: semana 1 ≤200/día, semana 2 ≤1 000, semana 3 ≤5 000, semana 4 normal. Transaccional primero, marketing al final. El límite se impone, no se sugiere — un warm-up sugerido es uno que nadie sigue.
- El warm-up se aborta si el rebote supera 2% o las quejas 0,1%, y se le dice al tenant qué número lo gatilló.
- Los incumplimientos sostenidos pausan el envío de marketing del dominio mientras el transaccional sigue. El marketing es lo que daña la reputación; los comprobantes son lo que los clientes necesitan.
- Las tasas de rebote y queja son visibles para el tenant en la consola, por dominio, en el tiempo.
- La alineación DMARC se verifica y se reporta; no se exige, porque muchos tenants no pueden cambiar su política DMARC organizacional rápido.
Datos (normativo)
domain es la única restricción de unicidad de la plataforma que es global y no por tenant
(standards/data.md §2b), y por una razón física: el DNS es global, y dos tenants no pueden ambos ser
dueños de acme.com. La verificación es lo que prueba la afirmación.
API (normativo)
Eventos (normativo)
Ninguno en el outbox. Los cambios de verificación y pausa notifican al tenant por el propiomessaging, como mensajes de categoría product.
Criterios de aceptación (normativo)
- La configuración emite registros DNS que verifican contra un proveedor real, y reporta cuáles faltan.
- Un dominio sin verificar no bloquea el envío; el correo sale por el subdominio compartido.
- Los límites de warm-up se imponen: exceder el tope diario encola en vez de enviar.
- Un rebote sobre 2% durante el warm-up lo aborta y nombra el número.
- Un incumplimiento sostenido pausa marketing y deja fluir transaccional.
- Un dominio ya reclamado por otro tenant no se puede agregar.
- Las tasas de rebote y queja son visibles por dominio en el tiempo.
- Negativo: ningún camino envía desde un dominio propio sin verificar.
Ejecución
Un solo slice, comando síncrono, más un poll programado de verificación. Runbook:../../../runbooks/deliverability.md.