Se acabó el plan gratuito de SendGrid: guía de migración en 30 minutos

El fin del plan gratuito para siempre

Si dependía del plan gratuito de SendGrid para un proyecto paralelo de bajo volumen o para un producto nuevo, probablemente notó el cambio: el plan gratuito ahora es una prueba de 60 días. Cuando esa prueba vence, debe pasar a un plan de pago; Essentials empieza en 19.95 USD al mes (precios de SendGrid). Para migrar, necesita exportar sus supresiones, actualizar sus registros DNS y cambiar su integración con la API. Este proceso lleva unos 30 minutos si sus plantillas son sencillas.

Evaluar las alternativas

Al elegir un reemplazo, debe distinguir entre la aceptación del proveedor (la API acepta su solicitud), la entrega (el servidor receptor acepta el correo) y la llegada a la bandeja de entrada (el correo no acaba en la carpeta de spam). Ningún proveedor puede garantizar esto último, ya que depende de la reputación del remitente y del contenido.

El panorama de costos (septiembre de 2026)

Para el correo transaccional de bajo volumen, la diferencia de precio es considerable. Enviar 50.000 correos cuesta unos 5 USD con Amazon SES en modalidad de pago por uso, frente a aproximadamente 66 USD con los niveles de Postmark.

• Amazon SES: cuesta 0.10 USD por cada 1.000 correos en modalidad de pago por uso (precios de AWS SES). Los nuevos planes por niveles, introducidos el 21 de julio de 2026, incluyen Essentials (0.16 USD por cada 1.000), Pro (0.22 USD por cada 1.000 más 105 USD al mes por región) y Enterprise (0.23 USD por cada 1.000 más 500 USD al mes).
• Resend: ofrece un plan gratuito de 3.000 correos al mes, con un máximo de 100 al día. El plan Pro cuesta 20 USD al mes por 50.000 correos, con excedentes a 0.90 USD por cada 1.000 (precios de Resend).
• Mailgun: desde 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.10 USD por cada 1.000 (precios de Mailgun).
• Postmark: desde 15 USD al mes por 10.000 correos, con excedentes de entre 1.80 y 1.20 USD por cada 1.000 (precios de Postmark).
• SendHQ: ofrece una alternativa moderna para equipos de producto y agentes de IA, centrada en una telemetría con datos minimizados alojada solo en la UE y en claves de API con alcance por espacio de trabajo.

Paso 1: exportación de datos y listas de supresión

No migre su lista sin exportar sus supresiones. Si envía a una dirección que antes rebotó o se dio de baja, se arriesga a dañar su reputación con el nuevo proveedor.

SendGrid le permite exportar su lista de supresión desde la interfaz o mediante la API. Recibirá un CSV con los correos a los que no se debe escribir. Al importarlos en un nuevo proveedor, asegúrese de asignar correctamente el «motivo» (rebote o baja) para seguir cumpliendo leyes como el RGPD o CAN-SPAM.

Paso 2: DNS y autenticación

Aquí es donde fallan la mayoría de las migraciones. No basta con cambiar la clave de API; debe demostrar al nuevo proveedor que el dominio es suyo.

DKIM, SPF y DMARC

Tendrá que agregar nuevos registros CNAME o TXT en su proveedor de DNS. Si se pasa a SendHQ, puede usar el Verificador de DNS de correo para comprobar su configuración actual antes de hacer cambios.

1. SPF: actualice su registro SPF para incluir al nuevo proveedor. Si usa varios proveedores, recuerde que no puede tener varios registros TXT de SPF. Debe combinarlos en uno solo (p. ej., v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). Para profundizar, consulte la entrada del glosario sobre SPF.
2. DKIM: genere nuevas claves DKIM en el panel de su nuevo proveedor y agregue los registros CNAME resultantes a su DNS. Así el servidor receptor puede verificar que el correo no se alteró en tránsito.
3. DMARC: su política DMARC no cambia sea cual sea el proveedor, ya que es una política a nivel de dominio. Sin embargo, asegúrese de que su nuevo proveedor esté alineado con su política DMARC para evitar que se rechacen los correos. Consulte la guía de DKIM, SPF y DMARC para ver los detalles de implementación.

Paso 3: migración del código

La mayoría de los proveedores usan una API REST. Si usaba las plantillas dinámicas de SendGrid, tendrá que migrar esos diseños HTML/CSS al motor de plantillas del nuevo proveedor.

Ejemplo: de SendGrid a una API REST genérica

SendGrid usa una estructura JSON específica para personalizations. La mayoría de las API modernas, incluida SendHQ, prefieren una estructura más plana para facilitar la lectura.

Payload de SendGrid:

{ "personalizations": [ { "to": [{"email": "user@example.com"}], "dynamic_template_data": { "first_name": "Alice" } } ], "from": {"email": "noreply@yourdomain.com"}, "template_id": "d-12345" }

Payload de una API moderna (p. ej., SendHQ):

{ "to": "user@example.com", "from": "noreply@yourdomain.com", "template_id": "welcome-email", "variables": { "first_name": "Alice" } }

Gestionar la migración en el código

Para evitar tiempo de inactividad, implemente un wrapper o un patrón strategy. Así puede alternar entre proveedores con una variable de entorno.

interface EmailProvider { send(payload: EmailPayload): Promise<void>; } class SendGridProvider implements EmailProvider { async send(payload: EmailPayload) { // SendGrid specific implementation } } class SendHQProvider implements EmailProvider { async send(payload: EmailPayload) { // SendHQ specific implementation } } const provider = process.env.EMAIL_PROVIDER === 'sendhq' ? new SendHQProvider() : new SendGridProvider();

Paso 4: agentes de IA e idempotencia

Si usa agentes de IA para desencadenar correos, se enfrenta a un riesgo específico: el agente puede entrar en un bucle o reintentar una solicitud varias veces por un timeout, y el usuario acaba recibiendo diez correos idénticos.

Enviar un correo es un efecto secundario externo. Debe implementar la idempotencia. Una clave de idempotencia es un identificador único que se envía en el encabezado y que le dice a la API: «Si ya ha visto esta clave, no vuelva a enviar el correo; devuelva simplemente la respuesta correcta original».

Implementación preparada para agentes:

{ "headers": { "Idempotency-Key": "order_123_welcome_email" }, "body": { "to": "customer@example.com", "template_id": "order-confirmation" } }

Además, para las acciones de agentes de alto riesgo (como enviar un restablecimiento de contraseña o una alerta de facturación), implemente un paso de aprobación con intervención humana o un límite de frecuencia estricto por ID de usuario, para evitar que las alucinaciones del agente llenen de spam a sus clientes.

Paso 5: pruebas y validación

Antes de cambiar la variable de entorno al nuevo proveedor, repase esta lista de verificación:

• Propagación de DNS: use una herramienta como dig o un verificador web para comprobar que sus nuevos registros DKIM y SPF están activos.
• Verificación de webhooks: si depende de eventos de entrega (delivered, opened, clicked), actualice sus endpoints de webhook. El formato de eventos de SendGrid difiere del de otros proveedores. Asegúrese de que su endpoint pueda procesar el nuevo esquema JSON sin fallar.
• Gestión de errores: pruebe cómo gestiona su aplicación los errores específicos del proveedor. Por ejemplo, un 429 (Too Many Requests) debería activar una estrategia de backoff, mientras que un 400 (Bad Request) suele indicar una dirección de correo mal formada que debería marcarse como rebote en su base de datos.

Casos de error habituales que conviene probar

1. Formato de correo no válido: asegúrese de que la API devuelva un error claro y de que su código no reintente indefinidamente.
2. Limitación de frecuencia: simule una ráfaga de correos para ver si su cola respeta los límites del proveedor.
3. Adjuntos grandes: verifique el tamaño máximo de payload del nuevo proveedor. Algunos lo limitan a 10MB y otros a 25MB.

Lista de verificación resumida para la migración

• Exportar supresiones: Exportación CSV desde SendGrid.
• Configurar registros DNS: Alineación de SPF, DKIM y DMARC.
• Migrar plantillas: Convierta HTML/CSS al nuevo formato.
• Actualizar la lógica de API: Implemente un wrapper de proveedor.
• Agregar idempotencia: Esencial para activadores de agentes de IA.
• Probar webhooks: Verifique la entrega y el análisis de eventos.
• Cambiar el tráfico: Actualice la variable ENV y monitoree los registros.

Reflexiones finales sobre la entregabilidad

Cambiar de proveedor es un buen momento para auditar sus hábitos de envío. Recuerde que la aceptación del proveedor es solo el primer obstáculo. La entrega depende de que el ISP receptor (Gmail, Outlook, etc.) acepte la conexión. La llegada a la bandeja de entrada es el último obstáculo, y la determinan la reputación a largo plazo de su dominio y las tasas de interacción de sus destinatarios.

Evite la tentación de usar estas API para correo masivo no solicitado. No solo suele ser ilegal, sino que hará que suspendan su cuenta sea cual sea el proveedor que elija. Cíñase a la comunicación transaccional y con consentimiento para mantener una buena puntuación de remitente.

Para los equipos que construyen aplicaciones nativas de IA, conviene buscar proveedores que ofrezcan funciones preparadas para agentes, como servidores MCP y archivos llms.txt, para que la integración sea fluida. SendHQ está diseñado exactamente para este flujo de trabajo y ofrece la infraestructura que necesitan los equipos de producto modernos.

Obtenga más información sobre cómo construir sistemas de correo confiables en https://sendhq.cc.