← Blog

Envío de correo electrónico desde los dominios de sus clientes

August 14, 2026 by Correo Para Llevar
Construir un servicio de soporte, CRM o plataforma que envía en nombre de los dominios de tus clientes? Cómo elegir entre enviar desde tu propio dominio y provisionar DKIM para el de ellos, y cómo evitar el rechazo 550 el remitente es inaceptable.

Si estás construyendo una aplicación multiinquilino (un helpdesk, CRM, o cualquier plataforma que envíe correo en nombre de tus clientes), eventualmente te enfrentas a una pregunta: ¿debe el correo salir desde tu dominio o desde el suyo? Si te equivocas, los mensajes rebotan con 550 sender is unacceptable. Aquí está el modelo que funciona en MailerToGo.

Los dos enfoques

1. Remitente de la plataforma (punto de partida recomendado)

Envía desde tu propio dominio (por ejemplo support@tuapp.com) y coloca la dirección del cliente en Reply-To. Funciona inmediatamente, no requiere configuración de DNS del cliente, y mantienes la entregabilidad completamente bajo tu control. Esto es lo que hacen Zendesk, Intercom y la mayoría de helpdesks SaaS por defecto.

2. Dominio del cliente (mejor marca y entregabilidad)

Aprovisiona una clave DKIM para el dominio del cliente para que el correo esté firmado como suyo. Esto requiere que el cliente agregue registros DNS, pero proporciona consistencia de marca y, una vez que DKIM y DMARC se alinean en su propio dominio, mejor entregabilidad.

La mayoría de las plataformas ofrecen ambas: comienza cada inquilino en el remitente de la plataforma, y deja que los clientes actualicen a su propio dominio cuando estén listos.

Qué sucede si omites el aprovisionamiento de DKIM

Esta es la trampa. Si tu aplicación envía desde un dominio del cliente que no tiene una clave DKIM aprovisionada en MailerToGo, una de dos cosas sucede: el mensaje es rechazado (550 sender is unacceptable), o el remitente de la envoltura es reescrito a tu dominio predeterminado como respaldo.

Ninguna de las dos es algo en lo que construir. Un rechazo significa correo de cliente descartado. Una reescritura silenciosa de la envoltura significa que tu alineación de DMARC se rompe silenciosamente. Hemos visto este fallo exacto en la práctica: una aplicación enviando como info@dominiodelcliente.com sin DKIM aprovisionado, y cada mensaje rebotando 550 sender is unacceptable.

No confíes en el respaldo. Decide el remitente en tu propio código.

El patrón recomendado: elige el remitente tú mismo

Rastrear, por cliente, si su dominio de envío está verificado en MTG. Elige MAIL FROM en consecuencia, y usa como respaldo tu dominio de plataforma cuando no esté verificado:

# Ruby
PLATFORM_DOMAIN = "tuapp.com"

def sender_for(customer)
  if customer.sending_domain_verified?
    { from: "support@#{customer.domain}" }                 # firmado como suyo
  else
    { from: "support@#{PLATFORM_DOMAIN}",                  # tu dominio
      reply_to: customer.support_address }                 # las respuestas aún llegan a ellos
  end
end

// Node
const PLATFORM_DOMAIN = "tuapp.com";

function senderFor(customer) {
  return customer.sendingDomainVerified
    ? { from: `support@${customer.domain}` }
    : { from: `support@${PLATFORM_DOMAIN}`, replyTo: customer.supportAddress };
}

Hay algunas cosas que debes hacer bien:

Aprovisionar el dominio de un cliente

Cuando un cliente quiere que el correo se envíe como su propio dominio:

  1. Agrega un subdominio de envío en MailerToGo. Usa un subdominio dedicado como mtg.dominiodelcliente.com en lugar del dominio raíz. Aísla la reputación de envío y es el patrón en torno al cual MTG está construido. Consulta Por qué MailerToGo envía desde mtg.tudominio.com.
  2. Que el cliente publique los registros DNS. El camino más simple es un único registro NS delegado: MTG entonces administra SPF, DKIM, y DMARC para ese subdominio por ellos. La ruta manual, publicando tú mismo los registros TXT de SPF, DKIM, y DMARC, también es compatible si el cliente prefiere poseer los registros. Consulta Usa un subdominio para enviar correo.
  3. Verifica, luego activa la bandera. Una vez que MTG reporta el dominio verificado, establece sending_domain_verified = true para ese cliente y comienza a enviar como su dominio.

Hasta que se complete el paso 3, mantén al cliente en tu remitente de plataforma. Los nuevos inquilinos pueden enviar desde el primer día, y actualizar a su propio dominio con cero tiempo de inactividad.

Resumen