adbtd vs i soliti noti.
dove ci collochiamo davvero.

Mailgun è l’ESP transazionale multi-tenant per antonomasia. Paghi per messaggio ($35/mese per 50k, poi $0.80/1k) e stai su un pool di invio condiviso — la tua reputazione è la media di tutti gli altri clienti Mailgun che quel giorno condividono il tuo IP. adbtd ribalta entrambe le scelte: prezzo flat per casella invece del conteggio per messaggio, e un IP dedicato dal momento in cui ti registri.

La differenza negli header è concreta. Un tipico messaggio Mailgun con il tracked domain di default mostra Return-Path: <bounces+...@mg.your-domain.com> e un DKIM d=mg.your-domain.com — i destinatari (e i classificatori di inbox placement come quello di Gmail) vedono il sottodominio mg. come un’identità gestita da Mailgun. Con adbtd lo stesso messaggio parte con Return-Path: <...@your-domain.com> e d=your-domain.com, nessun sottodominio dell’operatore da nessuna parte.

Conti a tre volumi indicativi — 50k/mese: Mailgun $35 + IP dedicato $59 = $94 vs adbtd 1 IP + 1 casella = $20.99. 200k/mese: Mailgun $155 + IP = $214 vs adbtd sempre $20.99. 500k/mese: Mailgun ~$395 + IP = $454 vs adbtd invariato. Il punto in cui Mailgun diventa più economico di adbtd è "mai" se gestisci un solo dominio di invio — adbtd non conta gli invii.

Mailgun ha senso se ti servono i loro strumenti di event-webhook e non ti interessa l’isolamento della reputazione. adbtd ha senso non appena la deliverability fa la differenza, o non appena vuoi header che sembrino di un mailserver gestito da te.

Postmark è il meglio della categoria per la posta transazionale e il primo posto dove manderemmo chiunque gestisca un flusso continuo di eventi account di un SaaS. Vietano rigorosamente il cold outreach e separano gli stream transazionali da quelli broadcast. adbtd non compete nel transazionale puro — Postmark vince sul flusso ricevute-e-reset-password di un SaaS.

La fuga di identità più visibile di Postmark è il CNAME di bounce. Postmark richiede di pubblicare pm-bounces.your-domain.com come CNAME verso pm.mtasv.net; quel sottodominio compare poi nel Return-Path di ogni messaggio. I destinatari vedono pm-bounces. e deducono Postmark; i classificatori di spam vedono un MTA di terze parti nel percorso di bounce. Il return-path di adbtd è semplicemente @your-domain.com, senza sottodominio dell’operatore.

La policy di Postmark sul cold outreach è esplicita: la loro content policy elenca la "posta non sollecitata" tra i motivi di chiusura dell’account, e gli stream broadcast hanno limiti di frequenza e revisioni separati. Se il tuo caso d’uso è l’outbound in stile agenzia per i clienti, non puoi realisticamente farlo passare da Postmark — ogni campagna rischia una revisione dell’account. adbtd supervisiona la reputazione, non il contenuto.

Conti: il transazionale Postmark parte da $15/mese per 10k messaggi e un IP dedicato costa $50/mese in più (solo stream transazionale — gli stream broadcast non possono avere un IP dedicato). 100k/mese fanno $115 + $50 = $165 prima di qualsiasi volume broadcast. adbtd allo stesso volume costa $20.99/mese flat, con l’IP dedicato utilizzabile su ogni dominio che possiedi.

Dove adbtd si distingue: cold outreach a volume (vietato su Postmark), isolamento dell’IP per cliente per le agenzie che fanno outbound per conto terzi, caselle IMAP in cui puoi anche leggere (Postmark è solo invio), e prezzo per casella invece che per messaggio.

SendGrid (ora Twilio SendGrid) è l’ESP storico con la matrice di integrazioni più profonda — se ogni form "registrati con l’email" che hai visto ha un ESP di default, è SendGrid. Il prezzo è un pool di invio condiviso per default, un IP dedicato solo sul piano Pro ($89+ /mese più il costo dell’IP a $80–90/mese), e header che rivelano l’identità SendGrid in più punti.

La superficie di fuga di SendGrid è più ampia di quella di Mailgun o Postmark. I messaggi di default portano gli header X-SG-EID e X-SG-ID (id di event tracking legati all’account SendGrid), il percorso di bounce finisce su bounces.sendgrid.net a meno che la Sender Authentication non sia configurata per intero, e i link di click-tracking vengono riscritti tramite u#######.ct.sendgrid.net. Ognuno di questi è un indizio. adbtd non ne ha nessuno — nessun header dell’operatore, nessun host di bounce dell’operatore, nessun dominio di click-tracking dell’operatore.

Conti: SendGrid Pro a 100k/mese costa $89 base + ~$80 di IP dedicato ≈ $169/mese prima di qualsiasi overhead di warm-up dell’IP. adbtd allo stesso volume su 1 IP costa $20.99/mese flat. SendGrid vince sopra ~1M/mese se altrimenti gestiresti più IP e ti serve il loro fanout di event-webhook; sotto, adbtd è sensibilmente più economico e isolato.

I nuovi account SendGrid passano anche per una revisione manuale, e il cold outreach porta spesso alla revisione e all’espulsione dalla piattaforma. adbtd salta la coda di revisione: hai un IP dedicato dal primo minuto e invii con header che dicono il tuo dominio e solo il tuo dominio.

SES è l’opzione seria più economica su larga scala ($0.10/1k in uscita, $0.12/MB di allegati, i primi 62k/mese gratis se inviati da EC2) e la più grezza — gli strumenti di deliverability li gestisci tu. Sandbox per default, l’accesso in produzione richiede un ticket di supporto (~24h), nessuna UI per il warm-up, nessuna rotazione DKIM gestita, nessuna registrazione integrata ai feedback loop di Yahoo / AOL / Outlook.com / Comcast.

L’impegno operativo per far girare SES "bene" è lavoro vero. Configuri un dominio MAIL FROM personalizzato per evitare che amazonses.com compaia nel Return-Path, crei e gestisci i tuoi topic SNS per bounce / reclami, ti registri a mano ai feedback loop degli ISP, scrivi la tua logica di rampa di warm-up, monitori la reputazione di invio nella dashboard SES e tieni allineati _dmarc + spf su più identità di invio. Il bring-your-own-IP è supportato ma passa dal processo di autorizzazione BYOIP di AWS e non è banale dal punto di vista operativo.

Conti a 1M/mese: SES fa circa $100 + $24.95 di IP dedicato = $125 vs adbtd $20.99. Sotto 1M/mese lo scarto assoluto è così piccolo che domina il tempo dell’operatore; sopra 5M/mese, SES è il pavimento di costo e nessuno si avvicina.

adbtd è la risposta gestita per i team che altrimenti costruirebbero da soli il wrapping di SES: emissione dell’IP dedicato, pubblicazione automatica di SPF / DKIM / DMARC, rampa di warm-up, gestione FBL, provisioning dei contatti postmaster. SES vince sul costo puro su larga scala; adbtd vince sul tempo per essere operativi e sulla multi-tenancy in stile agenzia (ogni cliente con il proprio stack isolato invece di un account SES condiviso).

Resend è l’opzione moderna API-first. Prodotto disegnato benissimo, onboarding rapido, integrazione React-Email, focus transazionale-e-marketing, ToS che vietano il cold outreach. Al momento solo in uscita — niente IMAP, niente posta in entrata in una casella vera, niente identità per casella. Il modello mentale è "chiave API dentro, messaggio fuori", non "gestire un mailserver".

La fuga di identità di Resend è la più discreta del gruppo — nel piano Free i messaggi in uscita portano un footer "Sent via Resend", rimovibile su Pro+ ($20/mese) insieme al loro dominio di click-tracking. Il d= DKIM è allineato al tuo dominio di invio su qualsiasi piano a pagamento. L’IP dedicato è solo su Pro+ a $30/mese in più; i piani Free e Hobby condividono gli IP. adbtd fa partire tutti su un IP dedicato, con il dominio del cliente in ogni header dal primo giorno.

Dove Resend è nettamente migliore: ergonomia per sviluppatori sulla posta transazionale, fanout di event-webhook, rendering di template React-Email, integrazione Vercel / Next.js. Se sei una startup Next.js che invia reset password e conferme d’ordine, Resend è probabilmente la scelta giusta.

Dove adbtd si distingue: veri Postfix + Dovecot + Rspamd in container su cui puoi leggere la posta, IP dedicato dall’inizio invece che solo sul piano Pro, nessun conteggio per messaggio, e cold outreach consentito su infrastruttura dedicata che gestisci tu. adbtd è la scelta giusta per un’agenzia o un operatore che ha bisogno di una inbox per cliente e di header che non dicano "via Resend".