> ## Documentation Index
> Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Dominios de envío y deliverability

> Cuando esto se entregue, el correo de un tenant sale desde su propio dominio, y la mala lista de uno no puede dañar la reputación de los demás.

> Traducción. Autoritativo: [`fs-msg-0008-sender-domains.md`](/modules/messaging/features/fs-msg-0008-sender-domains).

## 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_domains` con 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)*

1. 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.
2. 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.
3. 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.
4. 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.
5. 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ó.
6. 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.
7. Las tasas de rebote y queja son visibles para el tenant en la consola, por dominio, en el tiempo.
8. 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)*

| Tabla                              | Invariantes clave                                                                                                                                                                                             |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `messaging.sender_domains`         | `tenant_id`; `domain` único globalmente (un dominio pertenece a un tenant); `spf_verified`, `dkim_verified`, `dmarc_status`; `warmup_stage`, `warmup_started_at`; `is_paused`, `paused_reason`; `verified_at` |
| `messaging.deliverability_metrics` | (`domain_id`, `window_start`); enviados, entregados, rebotados, quejas; append-only; particionada mensualmente                                                                                                |

`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)*

| Endpoint                                        | Clase      | Permiso                            | Presupuesto |
| ----------------------------------------------- | ---------- | ---------------------------------- | ----------- |
| `GET/POST /v1/messaging/sender-domains`         | Management | `messaging.domains.{read\|create}` | p95 \<1 s   |
| `POST /v1/messaging/sender-domains/{id}/verify` | Management | `messaging.domains.verify`         | p95 \<5 s   |
| `GET /v1/messaging/deliverability`              | Management | `messaging.deliverability.read`    | p95 \<1 s   |

## Eventos *(normativo)*

Ninguno en el outbox. Los cambios de verificación y pausa notifican al tenant por el propio
`messaging`, como mensajes de categoría `product`.

## Criterios de aceptación *(normativo)*

1. La configuración emite registros DNS que verifican contra un proveedor real, y reporta cuáles
   faltan.
2. Un dominio sin verificar no bloquea el envío; el correo sale por el subdominio compartido.
3. Los límites de warm-up se imponen: exceder el tope diario encola en vez de enviar.
4. Un rebote sobre 2% durante el warm-up lo aborta y nombra el número.
5. Un incumplimiento sostenido pausa marketing y deja fluir transaccional.
6. Un dominio ya reclamado por otro tenant no se puede agregar.
7. Las tasas de rebote y queja son visibles por dominio en el tiempo.
8. **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`](/es/runbooks/deliverability).

## Preguntas abiertas

| # | Pregunta                                                                                                | Decide | Para                            |
| - | ------------------------------------------------------------------------------------------------------- | ------ | ------------------------------- |
| 1 | Umbrales que pausan a un tenant — ¿2% de rebote y 0,1% de quejas, o más estrictos? (pregunta 1 del PRD) | Daniel | antes de aprobar                |
| 2 | ¿El add-on de dominio propio es por dominio o por tenant?                                               | Daniel | antes del lanzamiento comercial |

## Changelog

| Versión | Fecha      | Cambio           | Por qué | Autor                  |
| ------- | ---------- | ---------------- | ------- | ---------------------- |
| 0.1.0   | 2026-08-17 | Borrador inicial | —       | daniel + claude-opus-5 |

## Registro de entrega

*Aún no implementado.*