SMTP o API email: quale usare per la tua app?

Prima o poi ogni prodotto deve inviare email, e la prima domanda è come il tuo codice debba comunicare con il sistema di posta. Le risposte sono due: parlare direttamente SMTP oppure chiamare un’API email tramite HTTPS.

Funzionano entrambe. Però impongono requisiti molto diversi alla tua applicazione, e la scelta giusta dipende da dove gira il tuo codice e da quanta infrastruttura di posta vuoi gestire in prima persona.

In cosa SMTP eccelle

SMTP (Simple Mail Transfer Protocol) è il modo in cui i server di posta si scambiano email dai primi anni ’80. Ogni provider di caselle lo supporta, e quasi ogni framework ha un mailer SMTP integrato: Nodemailer, send_mail di Django, Laravel Mail, Action Mailer di Rails.

Punti di forza:

• Universale. Ogni account email e ogni linguaggio lo supportano.
• Nessun vendor lock-in. Cambi provider cambiando un nome host e una password.
• Il tuo dominio e la tua reputazione. Le email partono da un server che controlli o noleggi, da indirizzi sul tuo dominio.

Dove SMTP crea problemi in un’app

SMTP è un protocollo prolisso e con stato. Per inviare un messaggio, la tua app apre una connessione TCP, saluta il server, passa a TLS, si autentica e poi attraversa una serie di comandi e risposte per il mittente, il destinatario e i dati. Ogni passaggio è un round trip di rete.

In pratica questo comporta:

• Richieste lente. Un handshake con un server lontano può richiedere centinaia di millisecondi prima ancora che il messaggio inizi.
• Porte bloccate. Molte piattaforme cloud e runtime serverless limitano le porte in uscita 25, 465 e 587 per contrastare lo spam. HTTPS sulla porta 443 non è quasi mai bloccato.
• Credenziali ovunque. Ogni servizio che invia email ha bisogno della password della casella. Cambiarla significa ridistribuire tutti i servizi.
• Poca visibilità. Quando qualcosa non funziona, l’errore resta nei log di un singolo servizio, sempre che sia stato registrato.

Cosa cambia con un’API email

Un’API email racchiude l’invio in una singola richiesta HTTPS con un corpo JSON. Il tuo codice esegue una POST e riceve in risposta un codice di stato. Il servizio API gestisce la connessione SMTP e le credenziali.

Punti di forza:

• Una sola richiesta veloce sulla porta 443, da qualsiasi ambiente: container, funzioni serverless, runtime edge, job di CI.
• Chiavi al posto delle password. Ogni servizio ha la propria chiave API con permessi limitati, e puoi revocarne o ruotarne una senza toccare le altre.
• Visibilità centralizzata. Chiamate API e risultati del recapito sono tracciati in un unico posto.
• Errori HTTP semplici. Un 401 o un 429 è molto più facile da gestire di un codice di risposta SMTP sepolto in uno stack trace.

Il compromesso: con la maggior parte delle API email, i messaggi partono dai loro server, quindi adotti la loro configurazione del dominio di invio e la loro reputazione IP, e cambiare fornitore in seguito significa rifare tutte le verifiche altrove.

Inbixio: un’API davanti al tuo server SMTP

Inbixio nasce da un’idea semplice: mantenere la parte di SMTP che ha valore, cioè il tuo server di posta e la tua identità di mittente, e sostituire la parte che crea problemi nelle applicazioni.

1. Colleghi il tuo server SMTP una sola volta nella dashboard: host, porta, nome utente e password.
2. I tuoi servizi chiamano POST /api/send-email/ con una chiave API di Inbixio.
3. Inbixio accede al tuo server SMTP tramite TLS e recapita il messaggio dal tuo indirizzo.
4. La dashboard mostra il numero di email inviate, la percentuale di recapiti non riusciti e la latenza di recapito, oltre a un log di ogni chiamata API.

curl -X POST https://backend.inbixio.com/api/send-email/ \
  -H "X-API-Key: $INBIXIO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"to_email":"user@example.com","subject":"Welcome!","message":"<h1>Hello</h1>"}'

Cosa ottieni:

• La password SMTP è conservata in un solo posto. I tuoi servizi vedono solo chiavi API.
• Le chiavi possono essere associate a un server specifico, così il servizio di fatturazione invia da billing@ e quello di autenticazione da security@.
• I permessi di ogni chiave sono espliciti, e una chiave può essere rinnovata o eliminata senza toccare il server di posta.
• Mantieni il tuo dominio mittente, il tuo provider e la tua reputazione. Se cambi provider di posta, aggiorni la voce di un solo server e il tuo codice resta invariato.

A confronto

Quindi, quale usare?

• Usa SMTP direttamente per una singola piccola app su un server in cui l’SMTP in uscita è consentito e ti va bene gestire lì le credenziali.
• Usa un’API email quando gestisci più servizi, distribuisci su piattaforme che bloccano le porte SMTP, vuoi log centralizzati o vuoi smettere di far circolare le password delle caselle.
• Usa Inbixio quando vuoi i vantaggi di un’API ma vuoi anche che le email continuino a passare dal tuo server di posta e dal tuo dominio.

Vuoi provarlo? La guida rapida in cinque minuti ti porta dalla registrazione a un’email recapitata.