KomuraSoft LLC
Contáctenos
Menú

Cómo diseñar el envío masivo de correos para pymes sin depender de un proveedor específico

· Actualizado el: · · Envío de correo, Aprovechamiento de recursos existentes, Mejora del flujo de contacto, Diseño web y SEO, B2B

«Quiero enviar decenas o cientos de correos de aviso usando el dominio y el sitio existentes, sin sumar un nuevo servicio de newsletter dedicado». La respuesta realista a esta consulta no es un solo envío por Bcc, sino construir una pequeña infraestructura de envío que combine envío individual por destinatario, gestión de suscripciones, baja de suscripción y SPF / DKIM / DMARC.

Aquí, «no usar un servicio específico» no significa «no usar nada». Significa mantener del lado propio el estándar SMTP, la lista de suscriptores, las plantillas y el flujo de baja de suscripción, y dejar que solo el medio de envío pueda sustituirse más adelante.

Además, este artículo parte de la base de que se envía a destinatarios con algún tipo de relación o consentimiento previo: clientes existentes, socios, personas que solicitaron material o suscriptores de un boletín. No se trata de recopilar direcciones públicas y enviar de forma indiscriminada. El correo publicitario tiene condicionantes legales, y además esa forma de trabajar no se sostiene a largo plazo en cuanto a la calidad de entrega.12

Lo que sigue es una síntesis basada en la información pública disponible en Japón en torno a la Ley de Correo Electrónico Específico, y en las directrices para remitentes de Google, Yahoo y Outlook, a fecha de abril de 2026.12345

Público objetivo y premisas de este artículo

Elemento Contenido
Público objetivo Personas encargadas, en una pyme, de enviar realmente correos de aviso a clientes, socios o prospectos. Está escrito para que pueda leerlo tanto el responsable de sistemas como el de la web o alguien de administración general que asume esta tarea adicional
Escala prevista Decenas o cientos de destinatarios por envío. De una vez al mes a una vez por semana, aproximadamente
Entorno de correo asumido No depende de un entorno concreto. Microsoft 365, Google Workspace, un Exchange local o el SMTP de un servidor de alojamiento: el diseño es el mismo en todos los casos. La única diferencia aparece en la parte del «relé SMTP» del capítulo 4
Destinatarios asumidos Clientes existentes, socios, personas que solicitaron material o suscriptores de un boletín: alguien con quien existe algún tipo de relación o consentimiento
Permiso necesario Poder añadir registros DNS al dominio de envío (necesario para configurar SPF / DKIM / DMARC). Este es el único punto en el que a veces hace falta pedírselo al proveedor de hosting o a la empresa que administra el dominio

Abreviaturas utilizadas en este artículo

Antes de seguir, resumimos aquí los términos que aparecerán sin explicación a partir del capítulo 2.

Sigla Nombre completo En una frase
SPF Sender Policy Framework Mecanismo por el que se escribe en el DNS «estos son los orígenes autorizados a enviar correo de este dominio» y el receptor lo verifica. Se creó para impedir la suplantación del remitente6
DKIM DomainKeys Identified Mail Mecanismo por el que el emisor firma digitalmente el correo y el receptor lo verifica con una clave pública publicada en el DNS. Indica que el dominio que firmó se hace responsable de ese correo7
DMARC Domain-based Message Authentication, Reporting, and Conformance Mecanismo por el que, a partir de los resultados de SPF / DKIM, el propietario del dominio declara qué hacer con los correos que fallan la autenticación. Permite indicar tres niveles: p=none (no hacer nada), p=quarantine (poner en cuarentena) y p=reject (rechazar)8
Alignment (alineación) — Que el dominio visible en From para el destinatario coincida con el dominio verificado por SPF / DKIM. Es justamente lo que evalúa DMARC8
PTR — Registro DNS de resolución inversa que permite obtener el nombre de host a partir de una dirección IP. «Tener resolución inversa» significa que este registro está configurado
List-Unsubscribe — Mecanismo por el que se indica en la cabecera del correo el destino de la baja de suscripción. El cliente de correo del receptor lo muestra como un botón de «cancelar suscripción»
Baja de un clic (one-click unsubscribe) — Añade, junto a List-Unsubscribe, la cabecera List-Unsubscribe-Post: List-Unsubscribe=One-Click, de modo que la baja se pueda completar sin pantalla de confirmación9
opt-in — Estado en el que el receptor se ha suscrito por voluntad propia. Por el contrario, una dirección obtenida solo de una tarjeta de presentación o de una lista comprada no es opt-in
Bounce (rebote) — Que el correo no se pueda entregar (por ejemplo, por dirección inexistente) y regrese. Un fallo permanente, como una dirección que no existe, se llama hard bounce
Queja (complaint) — Que el receptor pulse el botón de «correo no deseado». Esta proporción es el spam rate
Relé SMTP — La salida por la que, desde el mecanismo de envío propio, el correo se entrega realmente a internet

1. Conclusión principal

En términos generales, la forma que una pyme debería adoptar de forma realista para el envío masivo a destinatarios externos se resume en estos 4 puntos:

  1. Enviar individualmente a cada destinatario En lugar de agrupar todo en Bcc, se organiza una cola pensada para enviar un correo a la vez.
  2. Mantener el estado de suscripción del lado propio Se gestiona con claridad, en la base de datos o el CSV propio, un estado como active, unsubscribed o bounced.
  3. Aceptar la baja de suscripción de forma automática No se convierte en una operación manual el «ya no me envíen más». Se incluye un enlace visible en el cuerpo del mensaje y, cuando sea posible, la cabecera List-Unsubscribe.345
  4. Autenticar el dominio de envío Se configuran SPF / DKIM / DMARC, la resolución inversa PTR y TLS. Aunque el envío técnicamente funcione, sin esto la entrega se dificulta.345

En resumen, no es un problema de cómo se opera el cliente de correo, sino un problema de infraestructura de envío.

Si el requisito de «quiero enviar de forma masiva» se interpreta como poner muchas direcciones en To / Cc / Bcc, el planteamiento se viene abajo. Lo que realmente hace falta es un mecanismo que responda a esto:

  • A quién se puede enviar
  • A quién ya no se debe enviar
  • Con qué propósito se obtuvo el consentimiento
  • Cómo se recibe la baja de suscripción
  • Si la configuración inspira confianza como remitente

2. Por qué un solo envío por Bcc no basta

En el envío masivo hacia el exterior, lo doloroso de Bcc es que, pese a parecer sencillo, no ofrece ningún cuerpo operativo real.

Problema Qué ocurre Qué complicación aparece más adelante
No se puede rastrear la baja de suscripción El «ya no me envíen más» llega por respuesta de correo o por teléfono Es fácil volver a enviar por error en el siguiente envío
No hay gestión de rebotes Se sigue enviando incluso a direcciones que no existen La reputación tiende a bajar
No queda registro del consentimiento No se puede explicar cuándo ni dónde se obtuvo La respuesta legal o ante reclamos es débil
Se mezclan tipos de envío El correo comercial y el correo de aviso salen de la misma bandeja Es fácil arrastrar también el correo habitual de pedidos
No se puede controlar la velocidad Es fácil enviar todo junto de una vez Es más probable sufrir límites o ser marcado como spam
Depende de la persona a cargo Todo funciona con el cliente de correo y el trabajo de una persona Es difícil de traspasar

Lo especialmente peligroso es que «se puede enviar», así que parece que el mecanismo funciona como tal. Pero en realidad, al no existir gestión de bajas, supresión de rebotes, registro de consentimiento ni registro de envíos, en cuanto el número de destinatarios crece un poco, la operación manual colapsa.

Bcc no es del todo malo. Puede funcionar para comunicaciones internas, avisos muy pequeños a un grupo cerrado de socios o comunicaciones puntuales a un grupo de contactos. Pero, como base de un mecanismo de envío continuo a clientes externos o prospectos, es débil: ese es el punto.

3. El significado práctico de «no usar un servicio específico»

Aquí el malentendido habitual es pensar que «no usar un servicio específico» equivale a «hacerlo todo a mano».

En la práctica, si se mantienen del lado propio estas 3 cosas, se evita en buena medida el bloqueo con un proveedor (vendor lock-in).

3.1 Lo que debe mantener la propia empresa

  • Datos de suscriptores
    • Dirección de correo
    • Fecha y hora del consentimiento
    • Origen del consentimiento
    • Categoría de envío
    • Estado de baja de suscripción
  • Reglas de envío
    • Qué se envía a quién
    • A qué velocidad se envía
    • Cómo se reflejan los rebotes y las bajas
  • Identidad del remitente
    • Dominio de envío
    • SPF / DKIM / DMARC
    • Dirección de correo que recibe respuestas
    • URL de baja de suscripción

3.2 Lo que se puede sustituir

  • El relé SMTP que realmente hace el envío
  • La forma de implementar el panel de administración
  • Dónde se implementa la cola de envío
  • Dónde se almacenan los registros

En definitiva, la esencia de «no usar un servicio» es no dejar por completo en manos de un tercero las reglas y el estado del envío.

  • La lista de destinatarios está en la base de datos propia
  • La URL de baja de suscripción está bajo el dominio propio
  • El asunto y las plantillas del cuerpo del mensaje los mantiene la propia empresa
  • Solo la salida SMTP puede sustituirse más adelante

Con esta forma, se puede empezar usando la infraestructura de correo existente y, más adelante, migrar a otro medio de envío.

4. Una arquitectura realista para pymes

4.1 Piezas mínimas

A una escala de decenas o cientos de envíos por tanda, no hace falta desde el principio un mecanismo grandioso. Aun así, conviene mantener separado, como mínimo, lo siguiente para que sea estable.

  1. Tabla de suscriptores
  2. Tabla de supresión
    • Baja de suscripción
    • hard bounce
    • Queja
  3. Plantilla de envío
    • Asunto
    • Cuerpo (HTML / texto)
    • Categoría de envío
  4. Cola de envío
    • Estado por destinatario
    • Resultado del envío
    • Número de reintentos
  5. Relé SMTP
    • Usar la infraestructura de correo existente
    • Usar un servidor propio
  6. Registro (log)
    • Cuándo se envió a quién
    • Éxito / fallo
    • Reflejo de baja / bounce

Una medición avanzada de tasa de apertura o de clics no es imprescindible desde el inicio. Lo primero que hace falta es poder enviar con seguridad, poder detener el envío y poder explicarlo.

4.2 Campos que debe tener la tabla de destinatarios

Como mínimo, estos son los campos habituales.

Campo Ejemplo Motivo
email user@example.com El destinatario en sí
status active / unsubscribed / bounced Para determinar si es un destinatario válido
consent_at 2026-03-20 12:34:56 Para dejar constancia de cuándo se obtuvo el consentimiento
consent_source Formulario / feria / contrato existente / entrada manual Para poder explicar de dónde vino
consent_purpose Boletín / aviso de seminario / información de mantenimiento Para dejar constancia de para qué envío se dio el consentimiento
unsubscribed_at 2026-03-29 09:10:11 Evidencia de la baja de suscripción
last_bounce_at 2026-03-30 08:00:00 Necesario para decidir la supresión de reenvíos
notes Vía comercial / cliente existente Información complementaria

Aunque el maestro inicial sea Excel o el libro de clientes existente, conviene mantener al menos esta separación. Lo especialmente importante es que la información de supresión tenga siempre prioridad.

Por ejemplo: aunque la dirección de esa persona siga en el registro comercial, si en la tabla de supresión figura como unsubscribed, no se envía. Sin esta regla, después de una baja de suscripción, la persona puede volver a entrar por otro camino y provocar un incidente.

4.3 Diagrama de arquitectura

Arquitectura de envío masivo de correoMuestra cómo el sitio web y los registros existentes alimentan la tabla de suscriptores, cómo la cola de envío combina la tabla de suscriptores, la tabla de supresión y la plantilla de envío, cómo el relé SMTP entrega el correo con SPF/DKIM/DMARC/PTR/TLS, y cómo las bajas, rebotes y quejas del destinatario retroalimentan la tabla de supresiónSitio web / formulario de suscripciónTabla de suscriptoresRegistro de clientes existentes / registro de sociosPlantilla de envíoAsunto / HTML / textoCola de envíoTabla de supresiónBaja / bounce / complaintRelé SMTPInfraestructura de correo existente o relé propioDestinatarioURL de bajaRespuestaBounce / quejaPunto de contacto operativoSPF / DKIM / DMARC / PTR / TLS

Para los entornos donde no se muestre el diagrama, aquí está el mismo contenido en forma de texto.

  • Entrada: el formulario de suscripción del sitio web y el registro de clientes existentes o de socios. Ambos convergen en la tabla de suscriptores.
  • Centro: en la cola de envío entran tres elementos: la tabla de suscriptores (a quién enviar), la tabla de supresión (a quién no se debe enviar) y la plantilla de envío (asunto, HTML, texto).
  • Salida: desde la cola de envío se pasa al relé SMTP (infraestructura de correo existente o relé propio), y desde ahí llega al destinatario. Del relé SMTP dependen las configuraciones de SPF / DKIM / DMARC / PTR / TLS.
  • Retorno: del destinatario vuelven reacciones en tres direcciones. La URL de baja de suscripción y los rebotes o quejas vuelven a la tabla de supresión, y las respuestas las recibe la persona del punto de contacto operativo.

El punto clave de este diagrama es que el medio de envío no es el centro. El centro son la tabla de suscriptores, la tabla de supresión y la cola de envío.

El relé SMTP es solo una salida. Si esta separación se mantiene, aunque en el futuro se cambie el medio de envío, no se pierde el historial de bajas ni el historial de consentimiento.

4.4 Cómo elegir la salida y el motor de envío

Después de separar «lo que mantiene la propia empresa» de «lo que se puede sustituir», al llegar al momento de ponerse manos a la obra, lo siguiente que hay que investigar son estos dos puntos.

1. Qué usar como salida (relé SMTP)

En muchos casos, la infraestructura de correo que ya se está usando puede servir tal cual como salida. Por ejemplo, en el caso de Microsoft 365, existe documentación oficial que ordena los métodos para enviar correo desde dispositivos o aplicaciones que no tienen buzón propio: el Client SMTP submission autenticado, el SMTP relay mediante conector, el Direct Send sin autenticación y el High Volume Email orientado al envío masivo interno, comparados junto con sus límites de envío y el TLS o el puerto necesarios.10 Si se dispone de un servidor de correo local (como Exchange Server), también se indica que puede resultar más sencillo recibir la retransmisión (relay) desde ahí.10

Al elegir, en general hay que fijarse en estos 4 puntos.

Qué revisar Por qué revisarlo
Límite de envío diario / por minuto Si al enviar cientos de correos de golpe se produce un atasco
Método de autenticación (usuario / certificado / IP fija) Si se puede operar sin tener que compartir contraseñas
Si se puede enviar a destinatarios externos Imprescindible si se envía a clientes fuera de la empresa
Cómo se declara en SPF Si se cambia la salida, también hay que corregir el SPF

2. Construir el motor de envío o apoyarse en un OSS existente

Construir por completo la tabla de suscriptores, la tabla de supresión, la cola de envío y la página de baja de suscripción cuesta más trabajo del que parece. Existen soluciones OSS autoalojadas con esta misma estructura, así que lo más rápido es comprobar primero si alguna de ellas ya es suficiente. Por ejemplo, listmonk es un software de envío de newsletters autoalojado bajo licencia AGPLv3, que incluye gestión de listas de suscriptores con opt-in simple o doble, agregación de resultados de campañas y rebotes, y una cola que puede usar varios servidores SMTP.11

La orientación para decidir sería esta.

Situación Elección realista
Se quiere una integración estrecha con el libro de clientes existente Construirlo a medida, pero al menos la tabla de supresión y la página de baja de suscripción deben crearse desde el principio
Solo se necesita la función de envío de correo Levantar un OSS autoalojado y apuntar solo el relé SMTP hacia el propio
No se quiere mantener un servidor propio Usar un servicio de envío, pero manteniendo los datos de suscriptores y la URL de baja también del lado del dominio propio

En cualquiera de los casos, el principio de mantener del lado propio los datos de suscriptores, los datos de supresión y la URL de baja no cambia. Mientras se respete esto, tanto la salida como el motor de envío se pueden sustituir más adelante.

5. Hasta dónde construir según la escala

5.1 Una vez al mes, decenas de destinatarios

A esta escala, en muchos casos basta con la configuración mínima.

  • Plantilla de combinación de correspondencia dedicada al envío
  • Envío individual por destinatario
  • URL de baja de suscripción
  • Almacenamiento de registros de envío
  • Configuración de SPF / DKIM / DMARC

El punto clave aquí es no volver a Bcc aunque el número de destinatarios sea pequeño. Incluso con 50 destinatarios o menos, si es un envío continuo hacia el exterior, conviene adoptar desde ya la forma de envío individual + gestión de estado; a la larga resulta más cómodo.

5.2 Varias veces al mes, cientos de destinatarios

Al llegar a esta etapa, conviene añadir algunas cosas para ganar estabilidad.

  • Cola de envío
  • Control de la velocidad de envío
  • Reflejo de rebotes
  • Reflejo inmediato de la baja de suscripción
  • Subdominio dedicado al envío
  • Flujo de aprobación
    • Envío de prueba
    • Envío en producción
    • Verificación de resultados

Además, es importante separar el correo humano habitual del correo comercial o de aviso. Google plantea el criterio de separar la dirección From o la IP según el tipo de mensaje, y Yahoo también recomienda no mezclar el correo bulk / marketing con el transactional / alerts en la misma IP o el mismo dominio de DKIM.34

Por ejemplo, con solo separar las direcciones por uso, la operación se ordena bastante.345

  • Confirmación de pedidos, facturación: billing@example.com
  • Aviso de incidencias, información de mantenimiento: notice@example.com
  • Boletín, avisos: news@example.com

5.3 Al acercarse a miles de mensajes diarios

Al llegar a este punto, es fácil que «no usar un servicio específico» se convierta en un fin en sí mismo.

Google exige explícitamente a los remitentes de Gmail que superan los 5.000 mensajes diarios requisitos como SPF / DKIM / DMARC, alineación del dominio From y baja de un clic, entre otros. Outlook también exige SPF / DKIM / DMARC a los dominios que superan los 5.000 mensajes diarios, e indica que los mensajes que no cumplan estos requisitos pueden ser enviados a spam o rechazados.35

A esta escala, el tema central de la operación también cambia.

  • Reputación de IP
  • Tasa de quejas
  • Tasa de rebotes
  • Procesamiento de bajas de suscripción
  • Cómo aumentar el volumen
  • Monitoreo

En esta etapa, en muchos casos resulta más económico usar un servicio especializado.

En definitiva, la conclusión de este artículo no es «hacerlo todo por cuenta propia sin importar la escala», sino que a una escala de decenas o cientos de destinatarios, una pequeña infraestructura de envío con el estado y las reglas del lado propio es justo lo adecuado.

6.1 Consentimiento

Los correos publicitarios o promocionales requieren, en principio, consentimiento previo. Según la clasificación del Centro de Consultas sobre Correo No Deseado, enviar correo publicitario sin autorización previa está, en principio, prohibido.2

Además, tanto Google como Yahoo exigen enviar únicamente correos que el receptor haya solicitado explícitamente, no usar listas compradas y evitar el opt-in con casillas premarcadas.34

En la práctica, lo mínimo que conviene conservar es lo siguiente.

  • Fecha y hora del consentimiento
  • Origen del consentimiento
  • Qué envío se autorizó
  • Texto explicativo
  • Pantalla o texto donde se obtuvo el consentimiento

Cabe señalar que, legalmente, existe una excepción para el envío a direcciones de uso empresarial publicadas en un sitio web. Sin embargo, no se recomienda apoyar la infraestructura de envío en esa excepción. Ya sea por reclamos, tasa de entrega, reputación o tasa de respuesta real, es difícil sostenerlo a largo plazo.2

6.2 Obligación de identificación y baja de suscripción

Incluso cuando se envía a alguien que dio su consentimiento, el remitente tiene una obligación de identificación. Según la clasificación del Centro de Consultas sobre Correo No Deseado, se necesita como mínimo la siguiente información.2

  • Nombre o razón social del remitente
  • Dirección de correo o URL para recibir la notificación de rechazo de recepción
  • Indicación de que se puede rechazar la recepción
  • Domicilio del remitente
  • Contacto para quejas o consultas

En otras palabras, el pie del correo debe incluir como mínimo esto:

Remitente: Empresa ○○, S.A.
Baja de suscripción: https://example.com/unsubscribe/xxxxx
Si desea darse de baja, hágalo desde la URL anterior.
Dirección: Tokio...
Contacto: support@example.com

Además, los principales receptores dan bastante importancia a la facilidad para darse de baja.

  • Google: exige unsubscribe de un clic a los remitentes de gran volumen3
  • Yahoo: exige o recomienda List-Unsubscribe y un enlace en el cuerpo del mensaje, con reflejo en un plazo de 2 días4
  • Outlook: recomienda un unsubscribe fácil de encontrar y que funcione5

Por eso, lo natural es incluir como mínimo un enlace visible en el cuerpo del mensaje y, cuando sea posible, las siguientes cabeceras.34

List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe/xxxxx>

6.3 Autenticación y tasa de entrega

Los principales receptores ya no dan por sentado «que se pueda enviar», sino «que esté autenticado».

Las directrices públicas de Google exigen lo siguiente.3

  • Todos los remitentes: SPF o DKIM, PTR (coherencia entre resolución directa e inversa), TLS
  • Remitentes de gran volumen: SPF + DKIM + DMARC, alineación del dominio From
  • Tasa de quejas baja
  • Unsubscribe de un clic para remitentes de gran volumen

Los requisitos de Yahoo son estos.4

  • SPF / DKIM / DMARC
  • Alineación DMARC
  • DNS directo / inverso válido
  • Unsubscribe
  • Tasa de quejas inferior al 0,3 %
  • Opt-in
  • Separación entre bulk y transactional

Outlook también publica requisitos para remitentes de gran volumen.5

  • SPF pass
  • DKIM pass
  • DMARC (al menos p=none, alineado con SPF o DKIM)
  • From / Reply-To real
  • Unsubscribe
  • Higiene de la lista (list hygiene)

Si se convierte en tabla la revisión operativa mínima, queda así.

Elemento Mínimo a hacer Objetivo
Dominio de envío Configurar SPF / DKIM / DMARC Evitar la suplantación, mejorar la tasa de entrega
Servidor de envío Usar un entorno estable con resolución PTR, usar TLS No perder la confianza del receptor
From / Reply-To Que sea una dirección real que pueda recibir respuestas Poder recibir quejas o solicitudes de baja
Baja de suscripción Enlace en el cuerpo + List-Unsubscribe Reducir la tasa de quejas
Calidad de la lista Solo opt-in, eliminar direcciones inválidas Proteger la reputación
Velocidad de envío No aumentar de golpe, enviar a un ritmo constante Evitar límites o el marcado como spam
Monitoreo Vigilar bounces / spam rate / complaints Detener a tiempo cualquier deterioro

Google recomienda que, al aumentar el volumen de envío, se empiece desde un volumen bajo, con destinatarios que responden bien, a un ritmo constante. Un pico repentino o duplicar de golpe el volumen tiende a provocar límites o una caída en la reputación.3

7. Cómo avanzar con la implementación

Para empezar con lo mínimo, el orden realista sería más o menos este.

  1. Separar los tipos de correo que se van a enviar
    • Correo de notificación
    • Boletín
    • Aviso de seminario
    • Aviso para clientes existentes
  2. Crear un formulario de suscripción o un flujo de captación del consentimiento Debe poder obtenerse en el sitio web junto con un texto explicativo. Es importante que el texto deje claro «qué llegará y con qué frecuencia».4
  3. Separar la tabla de suscriptores de la tabla de supresión Si se separan desde el principio, la operación no se desmorona por mucho que se cambie de herramienta más adelante.
  4. Definir un dominio o subdominio exclusivo para el envío Por ejemplo, news.example.com o mail.example.com. Como mínimo, hay que evitar mezclar la responsabilidad con los pedidos habituales o el buzón de correo personal.34
  5. Configurar SPF / DKIM / DMARC / PTR / TLS Si el envío es propio, esto es la prioridad absoluta. No convertir en infraestructura de envío un entorno que no puede obtener resolución inversa.34
  6. Crear un panel de administración, aunque sea pequeño No hace falta una interfaz lujosa; hacen falta estas funciones:
    • Edición del asunto
    • Edición del cuerpo del mensaje
    • Envío de prueba
    • Envío en producción
    • Vista previa de los destinatarios
    • Configuración del tamaño del lote
    • Verificación de resultados
  7. Empezar enviando poco al principio Limitarse a clientes existentes o suscriptores que responden bien, y salir a un ritmo constante. Si no hay problemas, se amplía el alcance.3
  8. Dar máxima prioridad a reflejar la baja de suscripción y los rebotes Antes que la tasa de apertura, hay que confirmar que esto funciona.

Con este orden se puede llegar a una forma de «poder seguir sin incidentes», no solo «poder enviar por ahora».

7.1 Palabras clave que conviene investigar a continuación

Aquí quedan, por etapas, palabras que se pueden usar tal cual como término de búsqueda al investigar internamente o al consultar con un proveedor.

Etapa Palabras a investigar
Configuración de autenticación configuración de registro SPF, activar firma DKIM, iniciar DMARC con p=none, cómo leer los informes DMARC, verificar PTR de resolución inversa
Elección de la salida conector de relé SMTP en Microsoft 365, envío con SMTP AUTH, relay anónimo en Exchange Server, subdominio dedicado al envío
Mecanismo de envío newsletter OSS autoalojado, doble opt-in, baja de suscripción de un clic, cabecera List-Unsubscribe
Monitoreo operativo procesamiento de rebotes hard y soft, spam rate 0.3%, Google Postmaster Tools, volumen de envío en el calentamiento (warm-up)

De todo esto, lo primero que hay que abordar es la configuración de la autenticación. Si esto no está resuelto, por muy cuidadoso que se sea con el resto del trabajo, el correo no llegará.

Si se quiere revisar también el diseño del formulario de suscripción, el texto de consentimiento y la página de baja de suscripción, conviene ordenarlo junto con el diseño de sitios web. En cambio, si la premisa es conectar con el libro de clientes existente, los sistemas internos o herramientas de Windows, es más seguro definir primero la separación de responsabilidades mediante una consultoría técnica y revisión de diseño.

8. Errores frecuentes

Los más habituales suelen ser estos.

  • Enviar el correo humano habitual y el correo comercial o de aviso desde el mismo remitente
  • Gestionar el consentimiento solo con una nota de texto libre
  • Convertir la baja de suscripción en un trámite manual por respuesta de correo
  • Volcar de golpe una lista antigua de tarjetas de presentación
  • Empezar a enviar de repente con el mayor volumen histórico
  • Mezclar texto promocional en el correo de notificación
  • Dar por terminado el resultado del envío con «la API de envío respondió éxito»
  • Que la tabla de supresión sea más débil que el libro de clientes existente

El último punto en particular es realmente propenso a incidentes.

La dirección de esa persona sigue en el Excel del área comercial. Pero esa persona ya dio de baja el boletín. Si en este caso no se establece la regla de que la información de baja siempre gana, se le puede volver a enviar una y otra vez por otro camino.

9. Resumen

Si una pyme quiere enviar correo a un número relativamente grande de destinatarios sin usar un servicio específico, lo que hay que pensar no es «qué botón pulsar».

Lo que realmente hace falta son estos 5 puntos:

  • No un solo envío por Bcc, sino envío individual por destinatario
  • Tabla de suscriptores y tabla de supresión
  • Un flujo que reciba la baja de suscripción de forma automática
  • SPF / DKIM / DMARC / PTR / TLS
  • Una operación que separe lo notificacional de lo promocional

En definitiva, tener las reglas de envío es más importante que tener el medio de envío, y va primero.

A una escala de decenas o cientos de destinatarios por tanda, se puede operar perfectamente bien sin un servicio dedicado. Aun así, el camino más corto no es «enviar todo junto desde el cliente de correo», sino diseñarlo como una pequeña infraestructura de envío.

Artículos relacionados

Referencias

  1. Agencia de Asuntos del Consumidor de Japón, Ley sobre el ajuste adecuado del envío de correo electrónico específico (Ley de Correo Electrónico Específico) ↩ ↩2

  2. Centro de Consultas sobre Correo No Deseado, Ley de Correo Electrónico Específico ↩ ↩2 ↩3 ↩4 ↩5

  3. Google Workspace Admin Help, Email sender guidelines ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14

  4. Yahoo Sender Hub, Sender Best Practices ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12

  5. Microsoft Community Hub, Strengthening Email Ecosystem: Outlook’s New Requirements for High-Volume Senders ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  6. IETF, RFC 7208 - Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 ↩

  7. IETF, RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures ↩

  8. IETF, RFC 7489 - Domain-based Message Authentication, Reporting, and Conformance (DMARC) ↩ ↩2

  9. IETF, RFC 8058 - Signaling One-Click Functionality for List Email Headers ↩

  10. Microsoft Learn, How to set up a multifunction device or application to send email using Microsoft 365 or Office 365 ↩ ↩2

  11. listmonk, listmonk - Free and open source self-hosted newsletter and mailing list manager ↩

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿No se puede enviar el correo de aviso a todos a la vez usando Bcc?
Como base de un mecanismo de envío continuo a clientes externos o prospectos, es una solución débil. Con Bcc se puede enviar, sí, pero no ofrece nada del cuerpo operativo necesario: no se puede rastrear la baja de suscripción, no hay gestión de rebotes (bounces), no queda registro del consentimiento, no se puede controlar la velocidad de envío y todo depende de la persona a cargo. En cuanto el número de destinatarios crece un poco, la operación manual colapsa. Puede funcionar para avisos internos o comunicaciones puntuales a un grupo cerrado, pero para un envío continuo a destinatarios externos se debe adoptar la forma de envío individual por destinatario con gestión de estado.
¿Se necesita consentimiento para enviar correos publicitarios o de aviso?
Los correos publicitarios o promocionales requieren, en principio, consentimiento previo. Según la clasificación del Centro de Consultas sobre Correo No Deseado, enviar correo publicitario sin autorización previa está, en principio, prohibido. Tanto Google como Yahoo exigen enviar únicamente correos que el destinatario haya solicitado explícitamente y no utilizar listas compradas. En la práctica conviene dejar constancia de la fecha y hora del consentimiento, el origen de la captación, el propósito del envío y el texto explicativo. Existe una excepción legal para las direcciones de uso empresarial publicadas en un sitio web, pero no se recomienda apoyar toda la infraestructura de envío en esa excepción.
¿Qué es lo mínimo necesario para que el correo no sea marcado como spam?
La autenticación del dominio de envío. En concreto: configurar SPF/DKIM/DMARC, un entorno de envío con PTR de resolución inversa, TLS, un From/Reply-To real que pueda recibir respuestas, un enlace de baja en el cuerpo del mensaje junto con la cabecera List-Unsubscribe, y una lista de calidad basada únicamente en opt-in. Google exige a los remitentes de Gmail que superan los 5.000 mensajes diarios contar con SPF + DKIM + DMARC y baja de un clic, y Yahoo exige, entre otras cosas, una tasa de quejas (spam rate) inferior al 0,3 %. Además, al aumentar el volumen de envío conviene empezar desde un volumen bajo y a un ritmo constante.
¿Se puede construir una infraestructura de envío propia sin usar un servicio de newsletter?
A una escala de decenas o cientos de envíos por tanda, es perfectamente posible. La clave es mantener del lado propio los datos de suscriptores, las reglas de envío y la identidad del remitente (dominio, autenticación, URL de baja), y dejar que solo el relé SMTP de salida pueda sustituirse más adelante. El centro no es el SMTP, sino la tabla de suscriptores, la tabla de supresión y la cola de envío. Ahora bien, cuando el volumen se acerca a miles de mensajes diarios, la gestión de la reputación de IP y de la tasa de quejas pasa a ser el tema principal, por lo que en muchos casos resulta más económico usar un servicio especializado.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog