¿Necesito un registro DMARC aparte para el subdominio de envío?

No para cumplir. Un receptor que no encuentra registro en el subdominio cae al dominio organizacional, así que el subdominio hereda la política del raíz o su etiqueta sp. Publicarlo de todos modos es la forma de dejar un nombre nuevo en p=none con su propia dirección de reportes mientras el raíz sigue aplicando, y de recibir los reportes de ese nombre por separado.

¿Un subdominio de envío protege la reputación de mi dominio principal?

En parte, y conviene saber en cuál parte. La vista de reputación de Gmail es por dominio firmante exacto, así que el nombre nuevo acumula su propio historial en cuanto es el dominio d= de DKIM. Pero Google cuenta el umbral de 5,000 al día por dominio principal, y el panel de estado de cumplimiento de un subdominio muestra datos de todo el dominio principal, así que los requisitos para remitentes te siguen.

¿Pueden dos plataformas compartir un mismo subdominio de envío?

Puedes publicar dos selectores DKIM en un mismo nombre, así que técnicamente funciona. También mezcla la reputación de envío de las dos plataformas en ese nombre, que es justo lo que querías evitar al crear el subdominio. Una plataforma por nombre, y un segundo nombre para la segunda.

Subdominio de envío: SPF, DKIM y DMARC paso a paso

La llamada casi siempre empieza como un reclamo por otra cosa. Digamos que una firma de doce personas manda cotizaciones y facturas desde Gmail, y un boletín al mes a través de una plataforma de correo. Un mes el boletín sale a una lista que nadie ha limpiado desde 2023, llegan las quejas, y dos semanas después las cotizaciones empiezan a caer en spam. En las cotizaciones no cambió nada. El nombre que envió el boletín y el nombre que envía las cotizaciones son el mismo nombre.

Mover el boletín a su propio nombre, algo como news.example.com, es la respuesta correcta. También es el trabajo que más seguido encontramos a medias: la plataforma muestra su palomita verde, la dirección From sigue en el dominio raíz, y la separación que creían haber comprado no existe. Esto es lo que un subdominio de envío separa de verdad, lo que no separa, y el orden en que publicamos los registros.

Qué separa un subdominio de envío y qué no

Gmail le atribuye la reputación al nombre que autenticó el mensaje. La documentación de Postmaster Tools dice que el panel de reputación de dominio solo muestra mensajes enviados desde el dominio exacto usado para la autenticación DKIM y SPF, y que reporta sobre remitentes autenticados con DKIM, cayendo al dominio SPF cuando el remitente no firma. Así que un nombre de envío nuevo empieza a construir su propio historial en el momento en que es el nombre de la etiqueta d= de DKIM y del remitente de sobre. Esa es la mitad que estás comprando, y es real.

Lo que no estás comprando es una exención de las reglas para remitentes masivos. Google cuenta el umbral de 5,000 mensajes al día por dominio principal: su propio ejemplo son 2,500 mensajes a cuentas personales de Gmail desde solarmora.com más 2,500 desde promotions.solarmora.com, lo cual te vuelve remitente masivo porque los 5,000 salieron del mismo dominio principal. Postmaster Tools sigue la misma lógica, y Google dice que agregar un subdominio todavía muestra el dominio principal completo en el panel de estado de cumplimiento. Partir el tráfico cambia a quién se le atribuye la reputación, no bajo qué reglas estás.

La tercera ganancia es el presupuesto de SPF. SPF se evalúa contra el nombre del remitente de sobre, y la sección 4.6.4 del RFC 7208 limita a diez los mecanismos que consultan DNS por evaluación, como un límite global único, y devuelve permerror si lo pasas. Un include que vive en el nombre de envío no le cuesta nada al raíz, y eso hace que delegar sea más limpio que aplanar cuando el registro raíz ya está cerca del techo. Mira el límite de diez consultas.

Qué revisamos antes de crear el nombre

Cuál plataforma, y si va a ser la única que envíe desde ahí. Una por nombre, porque dos plataformas firmando en un mismo nombre vuelven a mezclar las reputaciones que pagaste por separar.
Qué identidad puede autenticar la plataforma de verdad. La documentación de SendGrid en Twilio te dice que ingreses el dominio del que van a salir tus mensajes, y por separado dice que los subdominios no heredan los permisos de autenticación de su dominio padre. Lee las dos frases juntas: si la dirección From va a vivir en el subdominio, el subdominio es la identidad que hay que autenticar, y una palomita verde en el raíz no prueba nada sobre él.
Cuántas consultas gasta el SPF del raíz y qué dice su registro DMARC, incluyendo si lleva una etiqueta sp, porque esa es la política que el nombre nuevo hereda desde el primer día. La mecánica está en nuestro artículo sobre política de subdominio y delegación.
Si el nombre ya existe en DNS. Con un registro de dirección y sin MX, la sección 5.1 del RFC 5321 indica a los remitentes tratar ese host como un MX implícito con preferencia 0, así que un nombre que creías que solo servía una landing ya es un destino de correo.

Los registros, en el orden que mantiene el correo fluyendo

Elige un nombre que diga qué carga: news., mail., send. Que no sea nada que sirva un sitio web ni reciba correo, y decídelo antes de publicar, porque cambiarlo después significa calentar un nombre nuevo desde cero. Luego publica en este orden. Nada se rompe a medio camino, porque el nombre no carga tráfico real hasta que apuntas la plataforma hacia él.

1. DKIM en el nombre de envío

Es el registro que más importa, porque es el que Gmail usa para atribuir reputación. Un verificador toma el selector s= y el dominio d= de la firma y consulta selector._domainkey.dominio, la búsqueda que define el RFC 6376, así que un selector s1 en news.example.com vive en s1._domainkey.news.example.com.

Las plataformas te lo entregan de dos formas: un registro TXT con la llave pública, que pegas y es tuyo, o un CNAME apuntando a un nombre que controla la plataforma, para que pueda rotar la llave sin tocar tu zona. El modelo CNAME es más fácil hasta que tu proveedor de DNS no acepta guiones bajos en nombres CNAME. Twilio documenta ese caso y dice que ahí no puedes usar la seguridad automatizada de SendGrid.

2. La ruta de retorno

Dos modelos, y lo elige la plataforma, no tú. La seguridad automatizada de SendGrid genera ella misma el host de envío y maneja SPF y DKIM con CNAMEs, por eso sus registros se ven como un host tipo em1234 más s1._domainkey y s2._domainkey. Amazon SES te devuelve el trabajo. Su función de MAIL FROM personalizado reemplaza el remitente de sobre amazonses.com por defecto con un nombre bajo un dominio tuyo, y ese nombre debe estar bajo el dominio padre de una identidad verificada y no debe ser un subdominio desde el que envíes o en el que recibas correo, así que un montaje con SES puede terminar con dos nombres. Ahí publicas un registro MX para que te lleguen los avisos de rebote y de queja, más un registro TXT de SPF, y eliges qué hace SES cuando ese MX está mal: regresar al dominio por defecto, o rechazar con un error MailFromDomainNotVerified. El destino del MX sigue un patrón por región y la consola imprime los valores exactos.

3. SPF en el nombre de envío, no en el raíz

Un registro TXT en el nombre, con el include de la plataforma y nada más. Dos registros SPF en un mismo nombre son un error permanente, no una redundancia. Algunos paneles de DNS quieren el valor TXT entre comillas y otros las agregan por ti, un detalle que la documentación de SES menciona, así que copia la convención de los registros que ya están ahí.

4. DMARC en el nombre de envío

Un receptor busca política en el dominio del From y solo cae al dominio organizacional cuando no encuentra ninguna, la secuencia de descubrimiento del RFC 7489. Eso te da algo útil: publica p=none con una dirección rua en _dmarc.news.example.com mientras el nombre es nuevo, y el raíz conserva la aplicación que ya tenía. Los reportes del nombre nuevo llegan por separado, y así ves qué está haciendo la plataforma antes de apretar nada.

s1._domainkey.news.example.com.  CNAME  <valor de tu plataforma>
s2._domainkey.news.example.com.  CNAME  <valor de tu plataforma>
news.example.com.                TXT    "v=spf1 include:<plataforma> -all"
bounce.example.com.              MX     10 <host de rebotes de tu plataforma>
_dmarc.news.example.com.         TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Compruébalo antes de la primera campaña

Resuelve cada registro desde fuera de tu propia red primero, porque Twilio recomienda dar hasta 48 horas para que el DNS valide y darle clic a verificar antes de eso no te dice nada.

dig +short TXT s1._domainkey.news.example.com
dig +short TXT news.example.com
dig +short MX  bounce.example.com
dig +short TXT _dmarc.news.example.com

Después manda un mensaje real a una dirección tuya y lee las cabeceras en lugar del panel. Tres cosas: una línea Authentication-Results con SPF y DKIM en pass, un d= igual al nombre de envío, y un Return-Path bajo tu dominio y no el de la plataforma. Si alguna está mal, los registros están publicados pero la plataforma todavía no los tomó, y eso no es un problema de DNS. Nuestra guía para leer cabeceras de correo muestra dónde está cada una.

Las trampas que seguimos encontrando

Un CNAME que reemplaza algo en silencio. Twilio lo dice sin rodeos: si tu CNAME de ruta de retorno coincide con un registro CNAME que ya existe, el que agregas sobrescribe al anterior. Revisa primero que el nombre esté libre.
Alineación estricta en el raíz. Con aspf=s o adkim=s los nombres deben coincidir exactamente y un remitente en subdominio falla. Google dice que la alineación estricta puede mandar a spam o hacer que se rechace el correo de subdominios asociados, y la recomienda solo en casos específicos, como correo enviado por tu dominio desde un subdominio fuera de tu control.
Dejar el include viejo en el raíz. Cuando la plataforma ya envía desde el subdominio, su include en el raíz es una consulta que pagas y una autorización que sigues dando.

Calienta el nombre, porque arranca desde cero

Un nombre de envío nuevo no tiene historial en ninguna parte, y un dominio raíz fuerte no se lo presta. La guía de Google para correo masivo es empezar con volumen bajo hacia destinatarios comprometidos y subir despacio, con un paso diario de entre 25% y 100%, y señala que cuanto más envías, más lento deberías subir. El ritmo cuenta tanto como el volumen: Google compara mandar 60 mensajes lo más rápido posible y luego esperar un minuto con mandar uno por segundo de forma constante, y recomienda lo segundo. Ante un diferimiento, su recuperación sugerida es esperar 15 minutos y luego enviar por debajo del volumen que lo provocó durante un día.

Dos números para tener presentes. Google pide mantener la tasa de spam reportada por usuarios debajo de 0.1% y nunca dejar que llegue a 0.3%, y define un dominio nuevo como uno que no ha enviado más de 5,000 mensajes al día a cuentas personales de Gmail desde el 1 de enero de 2024, con una aplicación acelerada para dominios nuevos. Un subdominio creado esta semana es exactamente esa definición, y ese es el argumento contra pasar la lista completa un lunes. Las dos cifras vienen de las directrices para remitentes de Google y de sus preguntas frecuentes, consultadas el 8 de octubre de 2026. Agrega el nombre nuevo a Postmaster Tools igual que agregaste el dominio principal: Google dice que los subdominios de un dominio principal ya verificado no necesitan verificación aparte.

Qué vigilamos el primer mes

La tasa de spam propia del nombre de envío y sus filas de autenticación, aparte de las del raíz.
Los reportes agregados de DMARC del subdominio, que muestran toda fuente que usa ese nombre, no solo la que montaste.
Que los rebotes le lleguen a la plataforma. Un flujo de rebotes silencioso es una lista que dejó de limpiarse.

Después sube la política del subdominio para que empate con la del raíz. Empezar en p=none era para ver el tráfico, no para dejar un nombre sin aplicación debajo de un dominio que sí la tiene.

Cómo ayuda Guanacos Tech

Tomamos esto como un solo trabajo acotado: decidir el nombre, publicar los registros, comprobar que el primer mensaje autentica con la identidad nueva, calentarlo con un calendario, y entregarte una zona que otra persona pueda leer sin llamarnos. Equivocarse nunca es dramático, y por eso se queda así durante años: el correo sigue llegando, un poco peor cada trimestre. En cómo trabajamos está la forma en que corre un proyecto, y nuestra página de consultoría de entregabilidad de correo es el lugar para empezar. Una llamada de 30 minutos alcanza para decirte si tu montaje actual separa algo o nada.

Un subdominio de envío para una sola plataforma: el orden correcto de los registros