Módulo 7 · 7.1

Español

Nederlands English Deutsch Français Español Italiano Polski

Newsletters desde su propio dominio

Módulo 7: Newsletters y correo desde su sitio web · Tiempo de lectura: 11 minutos

Objetivo de aprendizaje: Después de esta lección podrá conectar un servicio de envío de modo que su newsletter pase SPF, DKIM y DMARC en nombre de su propio dominio, y podrá comprobar en las cabeceras si lo ha conseguido.

Conceptos clave: servicio de envío, dominio From, Return-Path (dominio de bounce), dominio DKIM (d=), uitlijning (alignment), dominio de bounce propio mediante CNAME, DKIM mediante CNAME, subdominio para marketing, límite de envío, calentamiento (warm-up)

Por qué una newsletter es algo distinto del correo normal

Un correo a un cliente o compañero lo envía desde su propio buzón. Una newsletter va a cientos o miles de personas a la vez. Para destinatarios como Gmail, Outlook.com y T-Online eso es otro tipo de tráfico: correo masivo (bulkmail). Lo examinan con más severidad, porque casi todo el spam también es correo masivo.

Tres factores marcan la diferencia entre una newsletter que llega a la bandeja de entrada y una que acaba en el spam:

Técnica: el correo debe poder demostrar que procede de su dominio. Esto lo regulan SPF, DKIM y DMARC, y sobre todo la alineación (alignment) entre ellos.
Reputación: los servidores y el dominio con los que envía deben tener buena reputación (lección 5.2).
Comportamiento de sus destinatarios: ¿abren su correo, o pulsan en "Esto es spam"? Depende de su lista y del consentimiento (lección 7.2).

Esta lección trata del primer punto. La base de los registros está en el curso de DNS, lección 7.4. Aquí vemos cómo comprobar en la práctica si todo está correcto.

¿Por qué no simplemente desde su propio buzón?

Puede resultar tentador enviar una newsletter con CCO desde su programa de correo habitual, o con una lista de distribución en su paquete de alojamiento. Para una pequeña asociación de treinta socios que se conocen entre sí, una lista de distribución es perfectamente válida. Para una newsletter real no lo es, por cuatro razones:

Límites de envío. Casi todos los proveedores limitan cuánto correo puede enviar un buzón o paquete al día, para frenar el abuso. En WebOké puede ver ese límite en DirectAdmin, en las estadísticas de usuario; en otros proveedores figura en las condiciones o en el panel de cliente. Una newsletter a 2.000 personas supera ese límite con creces.
Reputación compartida. Comparte el servidor de envío con otros clientes. Si los destinatarios se quejan de su newsletter, también afecta a su correo, y viceversa.
Sin botón de baja ni gestión de bounces. Un servicio de envío añade automáticamente las cabeceras de baja en cada correo (lección 7.2), elimina de su lista las direcciones que ya no existen y procesa las quejas. Eso nunca se hace bien a mano.
Privacidad. Un solo clic erróneo y envía a todos la dirección de los demás en el campo Para.

Un servicio de envío (un servicio de newsletters como Laposta, Brevo, MailerLite o Mailchimp, o un servicio transaccional para confirmaciones y facturas) está hecho para este trabajo. Pero entonces otro envía en nombre de su dominio, y eso hay que poder demostrarlo.

Tres dominios en un solo correo

Cada correo tiene como mínimo tres lugares donde aparece un dominio. En el correo normal desde su propio buzón suelen coincidir. En un servicio de envío no coinciden automáticamente.

Lugar	Dónde se ve	Quién lo comprueba
From (remitente visible)	`From: Noticias <nieuws@example.com>`	DMARC examina este dominio
Return-Path (remitente del sobre, dirección de bounce)	`Return-Path: <bounce-8f3a@mail.sender.example>`	SPF comprueba este dominio
Dominio DKIM	`DKIM-Signature: ... d=sender.example; s=s1; ...`	DKIM comprueba la firma de este dominio

DMARC (lección 4.4) aprueba un correo si SPF o DKIM tienen éxito, y el dominio que tuvo éxito está alineado con el dominio From. Alineado significa, con la configuración estándar (relaxed), que es el mismo dominio organizativo: mail.example.com está alineado con example.com, pero sender.example no.

Sin configuración propia, una newsletter se ve así:

Return-Path: <bounce-8f3a@mail.sender.example>
From: Noticias <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mail.sender.example;
       dkim=pass header.d=sender.example;
       dmarc=fail header.from=example.com

SPF tiene éxito y DKIM tiene éxito, pero ambos para el dominio del servicio. Ninguno de los dos está alineado con example.com, por lo que DMARC falla. Si su política DMARC está en p=none, solo lo notará en sus informes (lección 4.5). Si está en quarantine o reject, su newsletter acaba en el spam o es rechazada.

La solución: autenticar el dominio en el servicio

Todo servicio de envío serio tiene un paso llamado "autenticar dominio", "verificar dominio" o "configurar dominio de envío". El servicio le da entonces unos registros para incluir en su DNS. Normalmente son estos:

DKIM mediante CNAME, por ejemplo s1._domainkey.example.com hacia un nombre del servicio. A partir de entonces el servicio firma su correo con d=example.com. Este es el registro más importante: con él DMARC tiene éxito a través de DKIM.
Un dominio de bounce propio, a menudo un CNAME en un subdominio, por ejemplo bounce.example.com hacia el servicio. Entonces el Return-Path pasa a ser ...@bounce.example.com. El SPF de ese subdominio apunta mediante el CNAME al servicio, y entonces SPF también queda alineado. No todos los servicios lo ofrecen; solo con DKIM ya es suficiente para DMARC.
A veces un include de SPF en su propio registro, si el servicio usa su dominio principal como Return-Path. Hágalo solo si el servicio se lo pide, y siempre dentro de su registro SPF existente (lección 4.2).
A veces un TXT de verificación para demostrar que el dominio es suyo.

Con la configuración correcta, la misma newsletter se ve así:

Return-Path: <bounce-8f3a@bounce.example.com>
From: Noticias <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Copie siempre literalmente los nombres y destinos del panel de su servicio. Varían según el servicio y a veces incluso según la cuenta.

¿Un subdominio aparte para marketing?

Los grandes remitentes suelen usar un subdominio propio para newsletters, como nieuws.example.com o info.example.com, con remitente nieuwsbrief@nieuws.example.com. La idea: la reputación de su correo de marketing queda así separada de su correo normal. Si una campaña sale mal, su correo diario con clientes sufre menos.

Para quien envía una newsletter un par de veces al mes, no es necesario. Además complica la gestión: el subdominio necesita su propio DKIM, y su política DMARC para subdominios (sp=) debe encajar con ello. Considérelo si envía mucho volumen o si, además de newsletters, también tiene mucho correo transaccional (pedidos, contraseñas). Ese correo nunca debería verse afectado por una acción fallida.

Importante: no ponga en un subdominio de envío ningún registro MX hacia el servicio si no lo necesita, y nunca modifique el MX de su dominio principal por una newsletter. El MX determina dónde entra el correo; las respuestas a su newsletter deben llegar simplemente a su propio buzón.

Calentamiento: no empezar de golpe con todo

¿Envía por primera vez con un servicio nuevo o un dominio nuevo, o de pronto envía diez veces más de lo habitual? Entonces los destinatarios todavía no le conocen. Los grandes proveedores frenan a los remitentes desconocidos (en Microsoft verá entonces rechazos temporales como 451 4.7.500, lección 6.4). Empiece por ello en pequeño: primero sus lectores más activos, después, cada vez, una parte mayor. Esto se llama calentamiento (warm-up). Con un servicio de envío compartido, el servicio hace gran parte de esto por usted, pero también ahí cuenta la reputación de su dominio.

En la práctica: así se ve en un panel

Los registros del servicio se añaden en la administración de DNS de su dominio. En WebOké es la pestaña DNS en Mi WebOké o Administración de DNS en DirectAdmin; en otros proveedores se llama administración de DNS, administración de zona o registros DNS, y funciona de forma parecida. Preste atención a los dos errores clásicos: el nombre de dominio duplicado en el nombre (s1._domainkey.example.com.example.com), y crear un registro TXT donde el servicio pide un CNAME.

¿Listo? Envíese a usted mismo una newsletter de prueba a una dirección propia de Gmail u Outlook.com y abra las cabeceras (lección 1.5). Busque en Authentication-Results: dkim=pass con header.d= su dominio, y dmarc=pass.

Resumen

Una newsletter es correo masivo: los destinatarios lo examinan con más severidad. Use un servicio de envío, no su buzón habitual.
En cada correo hay tres dominios: From (DMARC), Return-Path (SPF) y el dominio DKIM d=.
DMARC solo tiene éxito si SPF o DKIM tienen éxito para un dominio alineado con el dominio From.
Autentique su dominio en el servicio: el DKIM mediante CNAME es lo más importante, un dominio de bounce propio es un plus.
Compruébelo con un correo de prueba: dkim=pass header.d=<su dominio> y dmarc=pass. Empiece en pequeño con un servicio nuevo.

Cuestionario

Ejercicio

Ejercicio Z7.1: Comprobar la alineación de un boletín. Envíese a sí mismo una newsletter desde su propio servicio de envío (o use el archivo de ejemplo nieuwsbrief-kopregels-1.txt del curso) y pegue las cabeceras. Indique: el dominio From, el dominio Return-Path, el dominio DKIM (d=) y si, según usted, DMARC tiene éxito (sí/no) y por qué vía (SPF, DKIM, ambos o ninguno). El programa analiza las cabeceras automáticamente, comprueba en vivo el selector DKIM en el DNS y el registro DMARC del dominio From, y compara su resultado con el suyo.

Ejercicio Z7.1: Comprobar la alineación de un boletín

Archivo de este ejercicio: nieuwsbrief-kopregels-1.txt, nieuwsbrief-kopregels-2.txt, kopregels-1.txt

Pegue las cabeceras de un boletín que envíe usted mismo, o elija un archivo de ejemplo. El servidor analiza las cabeceras por su cuenta (solo en memoria) y, si son cabeceras reales, busca la clave DKIM y el registro DMARC.

¿Qué cabeceras?

Cabeceras pegadas (opcional)

Dominio de From

Dominio de Return-Path

Dominio DKIM (d=)

¿Supera DMARC?

¿Por qué vía?

No guardamos lo que escriba ni lo que encontremos. Su navegador recuerda sus respuestas y si ha superado el ejercicio. Si ha iniciado sesión, en Mis cursos solo guardamos que el ejercicio estaba (casi) correcto; allí también puede eliminarlo.

Para saber más

Los pasos de estos artículos son válidos para los paneles de WebOké; en otros proveedores funciona de forma parecida.

Cookies en WebOké

Ajustes de cookies

Necesarias

Marketing