Sender Authentication Package: el playbook de setup
El Sender Authentication Package (SAP) es el setup fundacional de MC que determina lo que ve el destinatario: From name branded, dominio de envío custom, dirección de reply, firma DKIM. Sin él, cada email sale desde el default genérico del tenant. La secuencia de setup, los registros DNS, los checks de verificación, y las formas de falla que muerden durante un primer rollout.
El Sender Authentication Package (SAP) es el setup fundacional de Marketing Cloud que determina lo que el destinatario efectivamente ve en su inbox: tu From name branded, un dominio de envío que resuelve a tu empresa en vez de *.exacttargetapps.com, una dirección de reply que rutea de vuelta a tu equipo, una firma DKIM que dice que el email efectivamente viene de vos, y la alineación SPF / DMARC que mantiene a los proveedores de mailbox alejados de filtrarte a spam. Sin SAP configurado, cada email sale desde los defaults genéricos del tenant — los filtros de spam los aman, los destinatarios aprenden a ignorarlos, y tu techo de deliverability es una fracción de lo que podría ser.
Esta página es el playbook de setup anclado a los rollouts que Cleon hizo a lo largo de implementaciones multi-tenant de Marketing Cloud. La secuencia funciona igual en un tenant fresco y en una migración desde otro ESP. Cada paso está seguido del check de verificación que confirma que aterrizó, más la forma de falla que más seguido se manifiesta en sends de producción después de que el SAP supuestamente está "hecho".
Qué bundlea efectivamente el SAP
[ Sender Authentication Package ]
├── Dominio de envío custom (ej. mail.yourbrand.com)
├── From Name branded (visible a nivel inbox)
├── Reply Mail Management (RMM) — a dónde van los replies
├── Firma DKIM (prueba criptográfica de que el mail vino de vos)
├── Alineación SPF (qué IPs están autorizadas a enviar por tu dominio)
├── Alineación DMARC (la política que ata DKIM + SPF)
└── Account-Level Personalization (el sender profile default)No configurás cada componente independientemente — configurás el SAP como una unidad, y MC propaga las elecciones a las superficies correctas. La secuencia abajo trata al SAP como un rollout durable en vez de siete tareas separadas.
Prerequisitos
Antes de abrir el wizard de SAP en MC, juntá:
| Prereq | De dónde viene | |---|---| | Acceso de edición de DNS para el dominio de envío | Tu proveedor de DNS / hosting (Cloudflare, Route53, GoDaddy, equipo interno de DNS) | | Rol de MC Administrator en la BU donde va a vivir el SAP | MC Setup → Users; verificá antes de arrancar | | Decisiones de branding: el dominio de envío, el From name, la dirección de reply | Marketing + Legal — son visibles a cada destinatario | | Una lista de las IPs desde las que MC va a enviar | MC Setup → Sender Authentication → IP Addresses (los valores que agregarás al SPF) | | Un inbox de prueba que controlás (preferentemente uno por proveedor mayor — Gmail, Outlook, corporativo) | Para los sends de verificación post-rollout |
La forma de falla del hand-off: el wizard de SAP pide registros DNS a mitad de camino, la persona corriendo el wizard no tiene acceso a DNS, y el SAP a medio hacer queda en un estado "pending verification" por días. Confirmá acceso a DNS antes de abrir el wizard.
Paso 1 — Elegí el dominio de envío
El dominio de envío es lo que muestra después del @ en la dirección From. La convención Cleon: usá un subdominio dedicado de tu dominio principal de marca, no el dominio apex.
| Patrón | Ejemplo | Uso |
|---|---|---|
| Dominio apex | from@yourbrand.com | Evitar — acopla deliverability a tu dominio principal |
| Subdominio de marketing | from@mail.yourbrand.com | Default — aísla la reputación del email |
| Subdominio transaccional | from@transactional.yourbrand.com | Cuando los volúmenes de marketing + transaccional difieren lo suficiente como para justificar reputaciones separadas |
| Subdominio por producto | from@news.yourbrand.com, from@offers.yourbrand.com | Programas grandes donde bouncear un producto no debería afectar a los otros |
Por qué un subdominio dedicado:
- Una queja de spam a escala en @mail.yourbrand.com no contamina
@yourbrand.com para mail transaccional (resets de password, recibos).
- Podés migrar entre ESPs re-apuntando un subdominio sin tocar
el apex.
- El enforcement de DMARC en el apex puede ser más estricto que lo
que necesitan los programas de marketing; los subdominios pueden
tener su propia política DMARC.Decidí el subdominio antes de abrir el wizard de MC. Una vez ingresado, es tedioso cambiarlo — el SAP se reconstruye, y cualquier Send Definition en vuelo referenciando el dominio viejo se rompe.
Paso 2 — Agregá los registros DNS
El wizard de MC produce tres categorías de registros DNS que tenés que agregar en el proveedor DNS para tu dominio de envío. Los registros son específicos al dominio; MC los genera después del paso 1.
Registros DNS mandados por el SAP:
1. CNAMEs para el dominio de envío
- Usado para que MC reclame el subdominio
- Ejemplo: mail.yourbrand.com → cnames.exacttarget.com
2. CNAMEs para tracking de imágenes/links (el subdominio "RMM")
- Ejemplo: reply.yourbrand.com → mta.exacttargetapps.com
- Esto es lo que hace que RMM funcione end-to-end
3. Registros TXT para SPF, DKIM, DMARC
- SPF: un solo registro TXT listando todos los senders autorizados
- DKIM: registros TXT conteniendo la clave pública para firmar
- DMARC: registro TXT en _dmarc.yourbrand.com definiendo la políticaDespués de agregar los registros, esperá la propagación DNS antes de seguir. El paso de verificación en MC pinga el DNS y falla si los registros no se propagaron todavía. Convención Cleon: 24 horas de espera después de que entran las ediciones DNS, después corré la verificación. Intentar verificar muy temprano es la demora más común de rollout de SAP.
Usá dig o un checker online para confirmar propagación:
# Confirmar resolución de CNAME
dig mail.yourbrand.com CNAME
# Confirmar SPF (buscá el registro v=spf1)
dig yourbrand.com TXT | grep spf1
# Confirmar DKIM (el selector que MC te dio — ej. selector1._domainkey)
dig selector1._domainkey.yourbrand.com TXT
# Confirmar DMARC
dig _dmarc.yourbrand.com TXTSi cualquiera de los cuatro no devuelve nada, el registro no se propagó o no está donde lo esperás. No sigas al próximo paso hasta que los cuatro resuelvan.
SPF flattening: el gotcha que muerde a organizaciones multi-ESP
SPF tiene un límite duro de 10 lookups DNS por evaluación. Cada include: en tu registro SPF cuenta como un lookup. Si tu organización usa Marketing Cloud + Google Workspace + un ESP transaccional + una plataforma de marketing automation, fácilmente podés pasar de 10.
# SPF naive (probablemente exceda 10 lookups):
v=spf1 include:_spf.google.com include:spf.protection.outlook.com
include:exacttarget.com include:sendgrid.net
include:mailchimp.com -all
# Cuando SPF excede 10 lookups, los proveedores de mailbox devuelven
# PermError — y tu alineación DMARC falla, aunque tu DKIM esté bien.
# El send igual sale, pero el filtrado de spam y el inbox placement
# se degradan en silencio.La defensa es SPF flattening — usar un servicio de terceros (o un registro TXT mantenido manualmente) que resuelve todas las directivas include: en una sola lista estática de IPs. Si estás corriendo el setup de SAP para una org con más de dos senders en el mismo dominio, auditá el conteo de lookups de SPF antes de entregarlo.
Paso 3 — Configurá Reply Mail Management (RMM)
RMM es lo que hace que reply@mail.yourbrand.com rutee a tu equipo en vez de perderse en la infraestructura send-only de MC. Dos cosas para configurar:
- El subdominio de reply: típicamente
reply.yourbrand.com(CNAMEd al MTA de MC en el paso 2). Cuando un destinatario hace Reply, el email va a<token>@reply.yourbrand.com. - La regla de forwarding: MC rutea los replies inbound a una de:
- Un mailbox real que controlás (
replies@yourbrand.com) - Una integración de ticketing RMM (Salesforce Service Cloud, Zendesk, etc.)
- Un agujero negro (raro, solo para sends de una sola vía — confirmá con el equipo que es intencional)
- Un mailbox real que controlás (
La convención Cleon: nunca black-holees los replies en programas customer-facing. Hasta las direcciones no-reply deberían rutear a un mailbox monitoreado que atrapa los replies "mandamos lo equivocado" y la ocasional notificación de bounce que no clasificó bien.
Paso 4 — Configurá el From Name y la dirección de Reply
El From Name es el "¿De quién es esto?" visible a nivel inbox. Dos opciones de configuración:
- Sender Profile: default por-send (la Send Activity lo usa salvo que se override)
- Account-Level Defaults: aplicado a cada BU salvo que se override a nivel de BU
La convención Cleon:
- Un Sender Profile por *persona de marca* (no por programa).
"YourBrand", "YourBrand Newsletter", "YourBrand Support" — no
"Q1 Promo", "Winter Sale", "Welcome Email".
- El From Name debería matchear la marca que los destinatarios
reconocen. No testees con "Marketing Team" y entregues con
"Acme Inc." — los destinatarios pegan Marcar como Spam con
From Names desconocidos.
- La dirección de Reply tiene que matchear la configuración de RMM.
Si RMM forwardea reply.yourbrand.com → support@yourbrand.com pero
el Sender Profile dice reply-to es help@yourbrand.com, los replies
desaparecen.Paso 5 — Activá el SAP en MC Setup
Una vez verificado el DNS, configurado el RMM, y seteado el Sender Profile, activá el SAP vía MC Setup → Email Studio → Email → Sender Authentication. La activación:
- Cambia todos los sends de la BU para usar el nuevo dominio de envío
- Empieza a firmar con DKIM el mail outbound con la key configurada
- Habilita el ruteo RMM para el subdominio de reply
- Aplica el nuevo Sender Profile a las Send Definitions existentes salvo que explícitamente lo overrideen
La activación no es reversible en silencio — una vez activa, las Send Definitions en vuelo que estaban configuradas para el dominio viejo (default) se van a romper. Planeá la activación para una ventana tranquila (sin sends scheduleados en las próximas 24 horas), y re-testeá todas las Send Definitions de producción inmediatamente después.
Paso 6 — Verificá con un test send
La única verificación concluyente es un test send real a un inbox real que controlás, examinado por:
| Check | Qué mirar |
|---|---|
| El From name se muestra correcto | La columna del sender del inbox lee tu nombre branded, no exacttargetapps.com |
| La dirección From usa el dominio de envío | Abrí el email; "From: Name <from@mail.yourbrand.com>" |
| Reply funciona end-to-end | Pegale Reply; verificá que el mensaje aterrice en el mailbox de reply configurado |
| DKIM pasa | Ver original / mostrar source; buscá header DKIM-Signature + dkim=pass |
| SPF pasa | Misma vista de headers; buscá spf=pass |
| DMARC alinea | dmarc=pass y header.from alinea con el dominio de SPF/DKIM |
| Los links rutean por el subdominio de tracking | Inspeccioná cualquier link en el email — href debería ser https://click.mail.yourbrand.com/... no *.exacttargetapps.com |
| El píxel de tracking carga desde el dominio correcto | Inspeccioná el source del email; las URLs de imagen deberían estar en el dominio SAP-eado |
Si cualquier check falla, el SAP no está hecho — andá hacia atrás por los pasos para encontrar dónde se rompió. Más seguido es un registro DNS que no propagó completamente (un proveedor devuelve el registro, otro no), o un Sender Profile que no se actualizó después de la activación.
Repetí el test send en al menos tres proveedores de mailbox (Gmail, Outlook, y un mailbox corporativo al que tengas acceso). Cada proveedor puede interpretar SPF / DKIM / DMARC ligeramente distinto; que pasen los tres es el listón.
Gotchas comunes durante un primer rollout de SAP
| Gotcha | Síntoma | Fix |
|---|---|---|
| La verificación DNS falla en el paso 5 | El wizard de MC queda colgado en "Pending Verification" | Esperá 24 horas después de las ediciones de DNS; usá dig para confirmar propagación antes de reintentar |
| SPF excede 10 lookups | El test send muestra spf=permerror | SPF flattening; sacá directivas include: no usadas |
| DKIM firma pero DMARC falla la alineación | dkim=pass pero dmarc=fail | El dominio d= de DKIM no matchea el dominio From; reconfigurá DKIM en el subdominio correcto |
| Los replies RMM no llegan a ningún lado | El test de reply no llega | El CNAME del subdominio de reply no propagó, o la regla de forwarding de RMM no está configurada |
| Las Send Definitions viejas se rompen después de la activación | La Send Activity tira error "sender domain not valid" | Editá las Send Definitions afectadas para usar el nuevo Sender Profile |
| Los links de tracking siguen apuntando a *.exacttargetapps.com | La inspección del link muestra el dominio viejo | El CNAME del subdominio de click-tracking no propagó, o la Send Definition referencia el dominio de click viejo |
| El test send funciona en Gmail pero falla en Outlook | DKIM/DMARC pasan en un proveedor, fallan en otro | Outlook es más estricto sobre alineación DMARC; usualmente un mismatch de d= o un problema de SPF flattening |
| El From name branded se revierte a "Marketing Cloud" | El inbox del destinatario muestra el From name equivocado | El Sender Profile no se activó, o la BU está overrideando con Account-Level Defaults |
Checklist post-rollout
Después de que el SAP está activado y los test sends verifican:
- [ ] Todas las Send Definitions de producción re-testeadas con el nuevo Sender Profile
- [ ] Monitoreo de reportes DMARC seteado (usá un servicio tipo Postmark / dmarcian / valimail; el primer reporte llega dentro de 48 horas)
- [ ] Registros DNS documentados en el runbook de infraestructura del equipo (TTLs, qué hace cada registro, quién tiene acceso de edición DNS)
- [ ] Procedimiento de rollback documentado (qué registros DNS revertir si el SAP necesita deshacerse)
- [ ] Ruteo de tickets RMM testeado con un reply real que llegue al equipo de soporte
- [ ] Overrides a nivel BU auditados (qué BUs usan intencionalmente un Sender Profile distinto)
- [ ] El primer send de producción después de la activación reviewado por métricas de deliverability (% entregado, % bounce, complaint rate vs el baseline antes del SAP)
Relacionado
- Principios de Marketing Cloud desde producción — las meta-reglas que aplican a decisiones de setup
- Style Guide de MC SQL — la referencia de convención para los DEs
de_log_*a los que el trabajo de auditoría relacionado al SAP escribe - MC AMPscript — funciones Cloud-write — los Cloud-writes dependen de que el SAP esté correctamente configurado en la BU corriendo el send
Progreso del catálogo: con esta página, la subcategoría Config abre con su primer artículo. Siguiendo la forma del catálogo SQL/SSJS/AMPscript, las próximas piezas apuntan a decisiones de arquitectura de Business Unit, Send Classifications, patrones de arquitectura de Data Extension, y un Style Guide de Config atando la disciplina de setup.