Skip to main content

Send Classifications — Commercial vs Transactional

Send Classifications son cómo Marketing Cloud distingue mail Commercial (reglas CAN-SPAM, unsubscribe, footer de dirección física) de mail Transactional (saltea eso). Los tres componentes — Sender Profile + Delivery Profile + clasificación CAN-SPAM — bundleados. Las reglas default, las reglas de override, y el costo de compliance de equivocarse.

Referencia·Actualizado 2026-05-19·Escrito por Lira · Editado por German Medina

Send Classifications es el mecanismo de Marketing Cloud para declarar qué tipo de mail estás enviando: Commercial (un mensaje de marketing sujeto a CAN-SPAM, CASL, reglas de consent de GDPR) o Transactional (un mensaje generado por sistema que el destinatario razonablemente está esperando — reset de password, confirmación de orden, verificación de cuenta). La clasificación determina si MC anexa un link de unsubscribe, si agrega un footer de dirección física, si honra el opt-out global del destinatario, y si el send respeta la lista de unsubscribe de All Subscribers.

Acertá la clasificación y tus sends cumplen los regímenes regulatorios que aplican. Equivocate y o violás CAN-SPAM (un send de marketing taggeado Transactional saltea el link de unsubscribe que los destinatarios tienen derecho legal a tener) o rompés la confiabilidad transaccional (un send transaccional verdadero taggeado Commercial significa que los destinatarios pueden hacer unsubscribe de sus propios emails de reset de password).

Esta página es la referencia de la estructura y los defaults. Las opiniones sobre cuándo usar cuál viven en Gotchas de Config — #4.

Qué es efectivamente una Send Classification

Una Send Classification en MC bundlea tres cosas:

| Componente | Qué controla | |---|---| | Sender Profile | El From Name + From Address + Reply Address visibles. Configurado al nivel BU. | | Delivery Profile | El pool de IP desde el que enviar y las reglas de bounce-handling de headers. Raramente customizado; el default por BU suele ser correcto. | | Clasificación CAN-SPAM | La flag legal/compliance: Commercial o Transactional. Determina el comportamiento de unsubscribe, footer, y opt-out. |

El wizard en MC Setup → Email Studio → Email Send Management → Send Classifications crea el bundle. Las Send Activities y Send Definitions referencian una Send Classification por nombre; los tres componentes disparan juntos.

Flujo de configuración:

1. Creá el Sender Profile (o usá uno existente) — ver setup de SAP.
2. Confirmá que el Delivery Profile default es apropiado (usualmente lo es).
3. Creá una Send Classification que bundlea Profile A + Delivery B +
   la flag CAN-SPAM correcta.
4. Referenciá la Send Classification desde cada Send Definition que
   debería usar ese bundle.

Referencia:

Lo que sobrevive en producción

Commercial vs Transactional — qué habilita cada uno efectivamente

La flag Commercial / Transactional es la parte de la Send Classification con dientes regulatorios. Cada flag cambia el comportamiento de la plataforma:

| Comportamiento | Commercial | Transactional | |---|---|---| | Anexa un link de unsubscribe por default | ✓ | ✗ | | Anexa un footer de dirección física | ✓ | ✗ | | Honra la lista de unsubscribe global de All Subscribers | ✓ | ✗ | | Honra la lista de unsubscribe a nivel BU | ✓ | ✗ | | Saltea destinatarios que pegaron Marcar como Spam previamente | ✓ | parcial | | Envía a destinatarios flageados como "Held" por historial de complaints | ✗ | ✓ | | Bypassea las reglas de Send Throttling | ✗ | ✓ (entrega más rápido) | | Cuenta contra la cuota mensual de send de MC | ✓ | ✓ (sin diferencia acá) |

La flag transactional es un privilegio: te deja alcanzar destinatarios que no pueden ser alcanzados comercialmente (se dieron de baja; quejaron; están en una lista de supresión). Eso es intencional — un reset de password tiene que llegar al destinatario incluso si está harto de tus emails de marketing. Mal-usarla como una manera de "entregar mejor" para sends de marketing es una violación de CAN-SPAM.

El Sender Profile es per-BU; clonar entre BUs no preserva todos los settings

Los Sender Profiles están atados a una BU específica. Crear un Sender Profile "Welcome" en BU A y un Sender Profile "Welcome" en BU B requiere crear cada uno explícitamente — los nombres pueden matchear, pero las configuraciones son independientes. Clonar un Sender Profile a otra BU copia los settings visibles (From Name, From Address) pero no propaga la configuración relacionada al SAP (dominio de envío custom, key de firma DKIM, dominio de tracking de links). El clon defaultea de vuelta al SAP de la BU destino.

La falla del hand-off:

1. BU A tiene un Sender Profile + SAP completamente configurados para
   mail.acme.com.
2. El equipo necesita el mismo setup en BU B (una sub-BU nueva).
3. "Clonan" el Sender Profile de A a B.
4. El clon muestra el From Name correcto en la UI.
5. Pero el SAP de B no está configurado todavía — los sends reales
   desde B usan *.exacttargetapps.com para el From Address, tracking
   de links, y hosting de imágenes.
6. El clon le dio al equipo confianza falsa de que B estaba "seteado".

La convención Cleon: clonar un Sender Profile es un punto de partida, no una tarea completada. El próximo paso es verificar el SAP de B por separado y correr el procedimiento de test-send de setup de SAP — Paso 6.

Los defaults del Delivery Profile suelen estar bien — pero los tenants multi-IP-pool necesitan atención

Los Delivery Profiles controlan desde qué IP pool envía MC y cómo se manejan los bounces. Para la mayoría de los tenants en un solo IP pool, el Delivery Profile default funciona tal cual — el pool es el pool estándar de envío del tenant, y el bounce-handling matchea los defaults recomendados de MC.

La excepción son tenants con múltiples IP pools (ediciones Enterprise con IPs dedicadas para transactional vs marketing). En ese setup, el Delivery Profile se vuelve una elección real: taggear un send al pool de marketing vs al pool transaccional afecta deliverability y reputación. El bundleo de Sender Profile + Delivery Profile + Classification es lo que hace esto manejable — la Send Classification "Transactional" se puede bundlear con el pool transaccional, y el pool correcto se selecciona sin configuración per-Send-Definition.

Overrides de Send Classification a nivel Send Definition

Una Send Definition referencia una Send Classification, pero también puede overridear componentes específicos. El Sender Profile puede overridearse per-send (una campaña puntual que quiere un From Name custom). El Delivery Profile puede overridearse (más raro; usualmente equivocado si estás tentado). La flag CAN-SPAM no puede overridearse — está lockeada al nivel Send Classification por diseño.

La regla de override:

- Override de Sender Profile a nivel Send Definition: legítimo para
  campañas puntuales con branding custom (ej. un send de co-marketing
  con un From Name partner-branded).
- Override de Delivery Profile a nivel Send Definition: raro;
  usualmente significa que la estructura de Send Classification
  está mal.
- Override de la flag CAN-SPAM: no disponible. Para enviar una
  clasificación distinta, referenciá una Send Classification distinta.

El lockeo de la flag CAN-SPAM es intencional: fuerza que la elección Commercial vs Transactional se haga deliberadamente a nivel Send Classification, no caso-por-caso. Un equipo que quiere que una Send Definition saltee el link de unsubscribe debe switchear explícitamente la referencia de Send Classification, lo que es visible en code review.

Nombrando Send Classifications por propósito, no por contenido

Una convención de naming útil refleja para qué es la classification, no qué contenido específico la usa.

Buenos nombres de Send Classification:

  - SC_Commercial_Marketing
  - SC_Commercial_Newsletter
  - SC_Transactional_AccountVerification
  - SC_Transactional_OrderConfirmation
  - SC_Transactional_PasswordReset
  - SC_Commercial_PartnerCoBranded

Malos nombres de Send Classification:

  - SC_Q4_Promo               (campaign-specific; reusable más allá de Q4)
  - SC_Welcome                (¿qué Welcome? ¿Onboarding Commercial vs
                               verificación Transactional?)
  - SC_Custom1                (no dice nada)

La convención Cleon: SC_<Clasificación>_<Propósito> — el prefijo lo marca como una Send Classification, la clasificación deletrea Commercial vs Transactional, y el propósito nombra el tipo de send. Las Send Classifications recién agregadas se mantienen escasas — un tenant con 30 Send Classifications está sobre-clasificado; 5-10 cubre la mayoría de las operaciones.

Reply Mail Management (RMM) atado al Sender Profile

El Sender Profile atado a una Send Classification lleva la Reply Address usada por RMM (ver setup de SAP — Paso 3). La Reply Address controla a dónde rutean los replies — un mailbox real, un sistema de ticketing, o un agujero negro. La clasificación no cambia el comportamiento de RMM, pero el Sender Profile dentro de la clasificación sí.

Una falla operacional común: una Send Classification transactional se seteó con una Reply Address no-reply@yourbrand.com. Un cliente pega Reply a un email de reset de password esperando preguntar algo; el mensaje va al mailbox no-reply; nadie lo lee; el cliente queda infeliz. Los sends transaccionales no deberían usar Reply Addresses no-reply — deberían rutear a soporte o a una cola de triage explícita.

Decisión rápida

Usá una Send Classification Commercial cuando:

  • El send es contenido de marketing (promociones, newsletters, anuncios de producto, lifecycle nurtures)
  • El destinatario razonablemente podría querer hacer unsubscribe de este tipo de contenido
  • El send tiene cualquier intención de venta o promocional

Usá una Send Classification Transactional cuando:

  • El send es generado por una acción que el destinatario tomó (colocó una orden, pidió un reset de password, se registró)
  • El contenido es la confirmación o el update de estado de la acción, no promocional
  • El destinatario legítimamente necesita recibir el mensaje para continuar usando el servicio

Creá una Send Classification nueva cuando:

  • El Sender Profile difiere de los existentes (persona de marca distinta, From Name distinto)
  • El Delivery Profile necesita ser un IP pool distinto
  • Un puñado chico de programas justifica el bundle nuevo (no crees clasificaciones por-campaña)

Reusá una Send Classification existente cuando:

  • La misma combinación Sender Profile + Delivery Profile + Classification ya existe
  • El send es parte de una familia de programa existente (newsletter, promo, lifecycle)

Evitá crear una Send Classification para:

  • Una sola campaña o una sola Send Definition
  • Un test o algo puntual que no se va a repetir
  • La conveniencia de "from name distinto" cuando las clasificaciones existentes funcionan bien

Relacionado

Progreso del catálogo: con esta página, Config tiene 5 page-pairs (gotchas + arquitectura de DE + arquitectura de BU + setup de SAP + Send Classifications). Restante: estrategia de Subscriber Key (decision-framework), Style Guide de Config (decision-framework) para cerrar la sección a ~7 page-pairs.