¿Qué debería evaluar un equipo de producto al elegir un servicio SMTP gratuito?

Defina «gratuito» a partir del contrato vigente

La palabra «gratuito» puede describir una asignación permanente, una prueba por tiempo limitado, créditos de introducción, pruebas con destinatarios verificados o un plan de pago con créditos temporales. Lea los precios y las condiciones actuales del proveedor el día de la evaluación. Registre la moneda, la región, los impuestos, si se exige tarjeta de pago, el vencimiento de la prueba, las unidades incluidas, el comportamiento de los excedentes, el comportamiento ante una suspensión y qué funciones desaparecen al bajar de plan. No se base en fragmentos de búsqueda, comparativas antiguas, capturas de pantalla o un chat de ventas sin una referencia contractual duradera. AWS SES, Resend y Mailgun publican en sus páginas oficiales modelos de precios y capacidades incluidas actuales que son distintos; no debe suponerse que ninguno sea intercambiable. Vincule a la decisión la URL de la página revisada y la fecha de captura, y programe una nueva comprobación antes del lanzamiento, porque las ofertas de los proveedores pueden cambiar. Un costo de adquisición gratuito no elimina los costos de ingeniería, DNS, monitoreo, privacidad, incidentes ni migración.

Modele la carga de trabajo en unidades facturables y operativas

Estime los mensajes, destinatarios, adjuntos, bytes, solicitudes de API o SMTP, entregas de eventos, correo entrante, contenido almacenado, retención de registros, dominios, miembros del equipo y entornos. Un mensaje con varios destinatarios puede consumir cuota de forma distinta que una transacción con un solo destinatario. Los reintentos, el tráfico de prueba, el calentamiento, los rebotes y las repeticiones de webhooks pueden sumar volumen. Calcule la demanda media, del minuto pico, de la hora pico, diaria, mensual y estacional, además del margen para el crecimiento y los incidentes. Mantenga los controles de frecuencia de la aplicación por debajo de los topes del proveedor y proteja a los inquilinos entre sí. Pregunte qué ocurre cuando quedan cero unidades: rechazo definitivo, aplazamiento, facturación automática, funciones degradadas o pérdida silenciosa de registros. Un nivel gratuito que cubre las llamadas de envío pero excluye un historial de eventos utilizable, el soporte o la exportación de supresiones puede resultar operativamente más caro que un plan de pago pequeño. Valide los contadores observados de la cuenta con tráfico controlado antes de pasar a producción.

Exija un envío SMTP seguro

Un servicio SMTP de producción debería documentar el envío protegido, los puertos admitidos, el comportamiento de TLS, los mecanismos de autenticación, los requisitos de certificados, el alcance de las credenciales y su rotación. Prefiera TLS obligatorio y falle de forma cerrada ante la ausencia de STARTTLS, un fallo de certificado, una discrepancia en el nombre de host o un protocolo no admitido. Guarde las credenciales en un sistema de secretos gestionado, nunca en código del navegador, aplicaciones móviles, código fuente, imágenes, registros, URL, analíticas, tickets o prompts. Separe la autoridad de producción, de pruebas, de los inquilinos y de administración. Confirme si el nivel gratuito restringe las credenciales, las IP de origen, los dominios, las regiones o las conexiones simultáneas. RFC 8314 recomienda abandonar los protocolos en texto claro en favor de TLS para el envío y el acceso, mientras que RFC 4954 define la autenticación SMTP como una extensión del protocolo, no como una autorización del producto. La aplicación sigue teniendo que autorizar el evento de negocio, el remitente, el inquilino, el destinatario, la plantilla y la clase de mensaje antes de abrir la conexión SMTP.

Verifique la identidad del remitente y la propiedad del DNS

Exija un dominio From que sea propiedad de la organización y un proceso documentado de verificación de dominios. Haga un inventario del SMTP MAIL FROM o return path, el From visible, el dominio d= y el selector de DKIM, las IP de envío y el manejo de las respuestas. Publique una única política SPF válida que incluya la ruta real, configure la firma DKIM con claves protegidas y evalúe la alineación DMARC con el dominio From visible. La verificación del proveedor es evidencia de que se superó una comprobación de configuración; no demuestra el consentimiento del destinatario, un enrutamiento de producción correcto, la reputación ni la llegada a la bandeja de entrada. Entienda qué registros DNS controla el proveedor y cuáles permanecen en la zona autoritativa de la organización. Conserve los valores anteriores y los pasos de reversión. Evite un dominio From exclusivo del proveedor como identidad de producción, porque debilita la portabilidad y puede hacer que la alineación DMARC o la continuidad de la marca dependan del proveedor. Pruebe los mensajes recibidos sin procesar en cada flujo y cada entorno.

Exija resultados útiles por destinatario

El servicio debe distinguir la aceptación SMTP o por API, el rechazo por destinatario, el aplazamiento temporal, el fallo permanente, el rebote posterior, la queja, la baja y la supresión por parte del proveedor. Verifique cómo se entregan, autentican, reintentan, ordenan, conservan y exportan esos resultados en el nivel gratuito. Autentique los webhooks antes de analizarlos, aplique controles de vigencia y de repetición, capture los eventos de forma duradera antes de acusar recibo y correlaciónelos con los intentos propios de la aplicación. Guarde por separado los conjuntos de destinatarios aceptados y rechazados. Reintente los fallos temporales que lo permitan con backoff acotado, jitter, un máximo de intentos y límites de antigüedad en la cola. Detenga los envíos automáticos tras un fallo permanente de la dirección, una queja o una baja en el ámbito correspondiente. Un panel sin evidencia exportable genera dependencia operativa. Un evento «delivered» del proveedor suele describir la aceptación por el servidor de destino, no la carpeta final del buzón. Las aperturas y los clics son instrumentación de interacción y pueden verse distorsionados por las tecnologías de privacidad.

Revise los límites que aparecen fuera de la página de precios

Las páginas de precios rara vez contienen todo el contrato operativo. Revise la documentación actual sobre el número de destinatarios, el tamaño de los mensajes, el tamaño de los adjuntos, la tasa de conexiones, las sesiones simultáneas, el límite de frecuencia de la API, los dominios DNS, las plantillas, los intentos de webhook, la retención de eventos, la capacidad de supresión y las restricciones de destinatarios durante la prueba. Determine si el soporte, los registros de auditoría, las IP dedicadas, el procesamiento regional, las rutas de correo entrante o las funciones de cumplimiento normativo requieren planes de pago. Pruebe la cuenta real, porque las cuentas nuevas o de prueba pueden tener límites más bajos o revisión manual. Registre cada límite con la URL de la fuente y la fecha de observación. No diseñe justo en el máximo; deje margen para los cambios del proveedor, los reintentos y la recuperación ante incidentes. Si una aplicación puede superar un límite en silencio mediante arrays de destinatarios o adjuntos proporcionados por el usuario, aplique primero un límite más estricto en el producto. Trate los límites no documentados o poco claros como un riesgo, no como capacidad ilimitada.

Evalúe los controles de privacidad, seguridad y abuso

Mapee el contenido de los mensajes, los datos de los destinatarios, los encabezados, los payloads de eventos, las direcciones IP, los registros, el acceso del soporte, las copias de seguridad y los subencargados en las distintas regiones. Minimice los metadatos personalizados y evite secretos o datos personales innecesarios en etiquetas y encabezados. Confirme el comportamiento de retención y eliminación de las cuentas gratuitas, incluso después de la cancelación. Verifique el aislamiento entre inquilinos, el acceso basado en roles, la MFA, el historial de auditoría, la rotación de credenciales, la firma de webhooks, la autorización de supresiones y la notificación de incidentes. Pruebe la inyección de encabezados, la selección arbitraria del remitente, el exceso de destinatarios, el abuso de adjuntos, la consulta de eventos entre inquilinos y la repetición. Los niveles gratuitos son objetivos habituales de abuso, por lo que los proveedores pueden imponer revisiones automatizadas o suspensiones rápidas; el producto necesita una cola duradera y una forma segura de pausar. Nunca eluda los controles contra el abuso rotando cuentas, dominios, credenciales o IP. Conserve el estado de consentimiento y supresión fuera del proveedor, para que una suspensión o una migración no puedan eliminar las protecciones de los destinatarios.

Calcule el costo de salida antes de enviar

Coloque los campos específicos del proveedor detrás de un único adaptador y mantenga independiente el modelo de eventos de la aplicación. Haga un inventario del host y la autenticación SMTP, los payloads de la API, las plantillas, los dominios remitentes, los return paths, los selectores DKIM, los webhooks, los nombres de eventos, los identificadores de mensajes, las etiquetas, las supresiones, las rutas de correo entrante y los registros. Exija exportaciones de las supresiones y del historial operativo en formatos que el producto pueda validar. Una migración debe preservar las claves de los eventos de negocio, el historial de intentos, el consentimiento, la seguridad de los destinatarios y la propiedad del remitente. Pruebe un segundo transporte con identidades controladas, pero no lo configure como una derivación automática para los fallos permanentes de destinatario o de política. Estime las ventanas de cambio de DNS, la rotación de credenciales, la conversión de plantillas, el procesamiento doble de webhooks, la prevención de duplicados y la retención de eventos antiguos. El nivel gratuito más barato puede ser la elección equivocada cuando salir de él implica perder evidencia, cambiar la identidad del remitente o reconstruir controles de seguridad bajo la presión de un incidente.

Haga una prueba con puntuación antes de pasar a producción

Cree una matriz de pruebas representativa: negociación TLS y fallo de certificado, autenticación y rotación, remitentes verificados y no autorizados, contenido sin formato y multipart, Unicode, adjuntos, destinatarios parciales, respuestas transitorias y permanentes, tiempo de espera después de DATA, rebotes, quejas, bajas, repetición de webhooks, eventos desordenados, agotamiento de la cuota, vencimiento del plan, exportación y cierre de la cuenta. Use destinatarios controlados dedicados y nunca listas reales de clientes. Puntúe por separado la seguridad, la corrección, la evidencia, la capacidad, la privacidad, el soporte, la portabilidad y el costo total. Bloquee el lanzamiento si falta la verificación TLS, si hay secretos compartidos sin rotación, exposición entre inquilinos, ausencia de manejo de fallos permanentes, imposibilidad de exportar las supresiones, excedentes silenciosos o una retención poco clara. Repita la prueba cuando cambie un plan de precios, una ruta de envío, un dominio o el contrato del proveedor. Un plan gratuito puede ser adecuado para una carga de trabajo acotada y de bajo riesgo solo cuando los controles y el plan de salida cumplen el mismo estándar que se esperaría de una dependencia de pago.

Evalúe los planes actuales de SendHQ

SendHQ no tiene un plan gratuito. Los nuevos espacios de trabajo reciben una prueba de integración controlada de 100 entregas al correo de la cuenta o a una dirección de simulador de AWS SES. Para conocer los precios, asignaciones y capacidades actuales de los planes de pago, consulte la página de precios de SendHQ.

Preguntas frecuentes

Fuentes

• Precios de Amazon Simple Email Service — Amazon Web Services
• Precios de Resend — Resend
• Precios de Mailgun — Mailgun
• RFC 8314: El texto sin cifrar se considera obsoleto: uso de Transport Layer Security (TLS) para envío y acceso de correo — RFC Editor
• RFC 4954: extensión del servicio SMTP para la autenticación — RFC Editor
• RFC 5321: protocolo simple de transferencia de correo (SMTP) — RFC Editor
• RFC 7489: autenticación, informes y conformidad de mensajes basados en dominios (DMARC) — RFC Editor