SMTP vs API de email: cuál deberías usar

Necesitas enviar email desde tu aplicación. Tal vez son reseteos de contraseña, tal vez son confirmaciones de orden, tal vez es una mezcla de todo. En algún punto te vas a enfrentar a la pregunta: ¿uso SMTP o un API de email?

La respuesta corta: si estás empezando desde cero, usa un API. Si te estás enchufando a algo que ya habla SMTP, usa SMTP. Pero los detalles importan, y hay trade-offs que vale la pena entender antes de comprometerte.

Cómo funciona SMTP

SMTP (Simple Mail Transfer Protocol) existe desde 1982. Es un protocolo basado en texto donde tu aplicación abre una conexión TCP a un servidor de correo, intercambia una serie de comandos (EHLO, MAIL FROM, RCPT TO, DATA) y transfiere el mensaje. El servidor responde con códigos de estado en cada paso.

En la práctica, la mayoría de los desarrolladores no escriben comandos SMTP en crudo. Usas una librería como Nodemailer (Node.js), PHPMailer (PHP) o smtplib (Python) que maneja la conexión y el protocolo por ti. Configuras un host, puerto y credenciales, luego llamas a un método de envío.

Así se ve enviar a través del relay SMTP de Sendkit con Nodemailer:

import nodemailer from 'nodemailer';

const transport = nodemailer.createTransport({
  host: 'smtp.sendkit.dev',
  port: 587,
  auth: {
    user: 'sendkit',
    pass: 'sk_live_your_api_key',
  },
});

const sendViaSMTP = async () => {
  const info = await transport.sendMail({
    from: '[email protected]',
    to: '[email protected]',
    subject: 'Your order has shipped',
    text: 'Track your package at https://example.com/track/12345',
    html: '<p>Track your package at <a href="https://example.com/track/12345">this link</a>.</p>',
  });

  console.log(info.messageId);
};

sendViaSMTP();

Esto funciona. Va a seguir funcionando. No hay nada mal con ello si tu sistema ya está conectado así.

Cómo funciona un API de email

Un API de email es un endpoint HTTP. Envías una petición POST con JSON (o form data), y recibes una respuesta JSON de vuelta. Sin handshake de protocolo, sin intercambio de comandos en múltiples pasos. Una petición, una respuesta.

Aquí está el mismo email enviado a través del API de Sendkit:

import { Sendkit } from '@sendkitdev/sdk';

const sendkit = new Sendkit('sk_live_your_api_key');

const sendViaAPI = async () => {
  const { data, error } = await sendkit.emails.send({
    from: '[email protected]',
    to: '[email protected]',
    subject: 'Your order has shipped',
    text: 'Track your package at https://example.com/track/12345',
    html: '<p>Track your package at <a href="https://example.com/track/12345">this link</a>.</p>',
  });

  if (error) {
    console.error(error.name); // e.g. 'validation_error'
    console.error(error.message); // e.g. 'The to field is required.'
    console.error(error.statusCode); // e.g. 422
    return;
  }

  console.log(data.id); // msg_7a3b...
};

sendViaAPI();

Ambos enfoques logran que el email se envíe. Las diferencias aparecen cuando haces zoom.

Velocidad

SMTP requiere una conexión TCP, un handshake TLS y múltiples comandos de ida y vuelta antes de que tu mensaje siquiera sea transmitido. Cada paso espera una respuesta del servidor. Con una red rápida esto toma tal vez 200-500ms, pero se suma cuando estás enviando en lotes.

Una llamada al API es una sola petición HTTPS. El handshake TLS pasa una vez (y se reutiliza con conexiones keep-alive). El round-trip total es típicamente 50-150ms.

Si estás enviando un email en un form submission, no notarás la diferencia. Si estás enviando 500 emails en un loop, sí lo harás. Y con el API, puedes usar endpoints de batch para enviar múltiples mensajes en una sola petición, lo cual no es posible con SMTP.

Funciones

SMTP es un protocolo de transporte. Mueve bytes del punto A al punto B. Eso es para lo que fue diseñado, y lo hace bien.

Un API puede hacer más porque no está restringido por la especificación de un protocolo de 40 años:

• Tagging y metadata. Adjunta tags personalizadas a los mensajes para filtrar analytics después. Con SMTP, tendrías que meter la metadata en headers personalizados (como X-Tag) y esperar que tu proveedor los parse.
• Envío en lote. Envía a múltiples destinatarios con personalización por destinatario en una sola llamada al API.
• Renderizado de plantillas. Pasa IDs de plantilla y variables en vez de construir HTML tú mismo. El API renderiza la plantilla del lado del servidor.
• Envío programado. Pone un mensaje en cola para entregar en un tiempo específico.
• Datos de respuesta inline. La respuesta del API inmediatamente te da un ID de mensaje, resultados de validación y estado. Con SMTP, obtienes un código de estado y tienes que esperar a eventos de webhook para todo lo demás.

Sendkit soporta tracking de aperturas, tracking de clics y manejo de bounces a través de SMTP y API. Pero el API te da más control sobre cómo fluyen esos datos.

Complejidad

SMTP tiene una barrera de entrada más baja si tu framework ya tiene un mailer integrado. Rails tiene ActionMailer. Django tiene django.core.mail. Laravel tiene Mail. Intercambia las credenciales SMTP, y listo.

La integración del API toma un poco más de trabajo al inicio. Instalas un SDK o escribes llamadas HTTP, configuras autenticación y manejas respuestas. Pero el código con el que terminas es más limpio, porque estás llamando a una función con un objeto en vez de configurar una capa de transporte.

Para proyectos nuevos, elegiría el API cada vez. La configuración inicial es quizás 10 minutos más larga, y todo después es más fácil.

Debugging

Debuggear problemas de SMTP es doloroso. Timeouts de conexión, fallos de negociación TLS, errores de autenticación que aparecen como códigos de estado crípticos ("535 5.7.8 Authentication failed"). Si la conexión se cae a mitad de la transferencia, podrías no saber si el mensaje fue aceptado o no.

Los errores de SMTP tienden a ser vagos. "550 Requested action not taken: mailbox unavailable" podría significar que la dirección no existe, el buzón está lleno o al servidor simplemente no le caes bien.

Los errores del API son estructurados. Obtienes códigos de estado HTTP con cuerpos de error en JSON que te dicen exactamente qué salió mal:

{
  "name": "validation_error",
  "message": "The 'to' field contains an invalid email address"
}

Puedes loguear estos, alertar sobre ellos y construir lógica de reintentos alrededor de tipos de error específicos. Intenta hacer eso con códigos de respuesta SMTP.

Tracking y analytics

Tanto SMTP como API soportan tracking de aperturas, tracking de clics, recibos de entrega y notificaciones de bounce cuando estás usando un proveedor como Sendkit. El tracking pasa a nivel del proveedor sin importar cómo enviaste el mensaje.

La diferencia está en lo que obtienes de vuelta al momento del envío. Con el API, la respuesta incluye un ID de mensaje y estado inicial de validación. Puedes inmediatamente almacenar esto y correlacionarlo con eventos de webhook más tarde. Con SMTP, obtienes un ID de mensaje de la respuesta 250 del servidor, pero eso es todo.

Si necesitas analytics detallado por mensaje, el API lo hace más fácil de conectar. Revisa los docs de Sendkit para la lista completa de eventos de webhook a los que puedes escuchar.

Seguridad

Ambos enfoques usan cifrado TLS en tránsito. El SMTP de Sendkit soporta el puerto 465 (TLS implícito) y el puerto 587 (STARTTLS). El API usa HTTPS exclusivamente.

La autenticación difiere. SMTP usa tu API key como la contraseña (con "sendkit" como username). El API usa la misma key como Bearer token o vía el constructor del SDK. Misma key, distinto transporte.

Una ventaja del API: puedes restringir las API keys a endpoints y permisos específicos. Una credencial SMTP es todo o nada. Si puede autenticar, puede enviar. Las API keys pueden tener scope para que una key usada por tu servicio de facturación solo pueda enviar email, mientras que una key usada por tu dashboard de analytics solo pueda leer datos.

Cuándo usar cuál

Usa el API de email cuando:

• Estás construyendo una aplicación o servicio nuevo desde cero
• Necesitas envío en lote, plantillas o entrega programada
• Quieres respuestas de error estructuradas y debugging más fácil
• Estás construyendo algo que necesita escalar (los APIs manejan la concurrencia mejor)
• Quieres permisos de API key granulares

Usa SMTP cuando:

• Tu framework o CMS ya tiene SMTP integrado (WordPress, apps Rails legacy, etc.)
• Estás reemplazando un proveedor SMTP existente y no quieres reescribir el código de envío
• Estás trabajando con un sistema que no puedes modificar (algunas herramientas empresariales solo soportan SMTP)
• Necesitas un cambio rápido sin cambios de código más allá de actualizar credenciales

No hay una decisión equivocada aquí. Sendkit te da ambos, y puedes mezclarlos en la misma cuenta. Usa el API para tu aplicación principal y SMTP para un formulario de contacto de WordPress en tu sitio de marketing. Ambos usan la misma API key, la misma verificación de dominio y la misma infraestructura de tracking.

Migrando de SMTP al API

Si estás en SMTP y quieres mudarte al API, no hay mucho que hacer. Tu configuración de dominio, registros DNS y configuración de webhooks se quedan iguales. Solo instala el SDK y empieza a enviar:

npm install @sendkitdev/sdk

Luego reemplaza tus llamadas a Nodemailer:

// Before (SMTP)
const transport = nodemailer.createTransport({
  host: 'smtp.sendkit.dev',
  port: 587,
  auth: { user: 'sendkit', pass: 'sk_live_your_api_key' },
});

const sendEmail = async (to, subject, html) => {
  await transport.sendMail({ from: '[email protected]', to, subject, html });
};

// After (API)
import { Sendkit } from '@sendkitdev/sdk';
const sendkit = new Sendkit('sk_live_your_api_key');

const sendEmail = async (to, subject, html) => {
  const { data, error } = await sendkit.emails.send({
    from: '[email protected]',
    to,
    subject,
    html,
  });
  if (error) {
    console.error(error.name, error.message);
    return;
  }
  console.log(data.id);
};

La firma de la función se queda igual. Lo principal que ganas son respuestas de error estructuradas en vez de códigos de estado SMTP. Puedes migrar un tipo de email a la vez si quieres ir con cuidado.

Para un recorrido más completo de envío con el SDK, mira cómo enviar email transaccional con Node.js.

La conclusión

SMTP es un protocolo sólido y probado. Funciona en todos lados. Si tu sistema ya lo usa, no hay razón urgente para arrancarlo.

Pero si estás escribiendo código de envío nuevo hoy, ve con el API. Obtienes respuestas más rápidas, errores estructurados y funciones que SMTP simplemente no puede ofrecer por cómo funciona el protocolo. SMTP fue construido para servidores hablando con servidores en 1982. Tu app merece algo que fue construido para apps.

Sendkit soporta ambos, así que no estás atado. Usa lo que se ajuste a tu setup ahora mismo, y cambia después si lo necesitas.