Il piano gratuito di SendGrid non c'è più: guida alla migrazione in 30 minuti

La fine del piano gratuito per sempre

Se contavi sul piano gratuito di SendGrid per un side project a basso volume o per un nuovo prodotto, probabilmente hai notato il cambiamento: il piano gratuito ora è una prova di 60 giorni. Alla scadenza devi passare a un piano a pagamento, con Essentials a partire da 19,95 USD al mese (prezzi di SendGrid). Per migrare devi esportare le soppressioni, aggiornare i record DNS e sostituire l'integrazione API. Se i tuoi template sono semplici, il processo richiede circa 30 minuti.

Valutare le alternative

Quando scegli un sostituto, devi distinguere tra accettazione da parte del provider (l'API accetta la tua richiesta), consegna (il server ricevente accetta la posta) e arrivo in inbox (la posta evita la cartella spam). Nessun provider può garantire quest'ultimo, perché dipende dalla reputazione del mittente e dal contenuto.

Il panorama dei costi (settembre 2026)

Per la posta transazionale a basso volume la differenza di prezzo è notevole. Inviare 50.000 email costa circa 5 USD con Amazon SES a consumo, contro circa 66 USD con i piani di Postmark.

• Amazon SES: costa 0,10 USD ogni 1.000 email a consumo (prezzi di AWS SES). I nuovi piani a livelli introdotti il 21 luglio 2026 comprendono Essentials (0,16 USD ogni 1.000), Pro (0,22 USD ogni 1.000 più 105 USD al mese per regione) ed Enterprise (0,23 USD ogni 1.000 più 500 USD al mese).
• Resend: offre un piano gratuito da 3.000 email al mese con un tetto di 100 al giorno. Il piano Pro costa 20 USD al mese per 50.000 email, con eccedenze a 0,90 USD ogni 1.000 (prezzi di Resend).
• Mailgun: parte da 15 USD al mese per 10.000 email, con eccedenze da 1,80 a 1,10 USD ogni 1.000 (prezzi di Mailgun).
• Postmark: parte da 15 USD al mese per 10.000 email, con eccedenze da 1,80 a 1,20 USD ogni 1.000 (prezzi di Postmark).
• SendHQ: offre un'alternativa moderna per team di prodotto e agenti AI, con telemetria a privacy minimizzata solo nell'UE e chiavi API con ambito limitato al workspace.

Passo 1: esportazione dei dati e liste di soppressione

Non migrare la tua lista senza esportare le soppressioni. Se invii a un indirizzo che in passato ha generato un bounce o si è disiscritto, rischi di danneggiare la tua reputazione con il nuovo provider.

SendGrid ti permette di esportare la lista di soppressione dalla UI o tramite API. Riceverai un CSV di indirizzi da non contattare. Quando li importi in un nuovo provider, assicurati di mappare correttamente il "motivo" (bounce o disiscrizione) per restare conforme a leggi come il GDPR o il CAN-SPAM.

Passo 2: DNS e autenticazione

È qui che falliscono la maggior parte delle migrazioni. Non basta cambiare la chiave API: devi dimostrare al nuovo provider di essere il proprietario del dominio.

DKIM, SPF e DMARC

Dovrai aggiungere nuovi record CNAME o TXT presso il tuo provider DNS. Se passi a SendHQ, puoi usare il controllo DNS email per verificare la configurazione attuale prima di apportare modifiche.

1. SPF: aggiorna il record SPF per includere il nuovo provider. Se usi più provider, ricorda che non puoi avere più record TXT SPF: devi combinarli in uno solo (ad es. v=spf1 include:sendgrid.net include:_spf.sendhq.cc ~all). Per approfondire, consulta la voce SPF del glossario.
2. DKIM: genera nuove chiavi DKIM nella dashboard del nuovo provider e aggiungi i record CNAME risultanti al DNS. In questo modo il server ricevente può verificare che l'email non sia stata alterata durante il transito.
3. DMARC: la policy DMARC resta la stessa qualunque sia il provider, perché è una policy a livello di dominio. Assicurati però che il nuovo provider sia allineato con la tua policy DMARC, per evitare che le email vengano rifiutate. Per i dettagli di implementazione, consulta la guida a DKIM, SPF e DMARC.

Passo 3: migrazione del codice

La maggior parte dei provider usa un'API REST. Se usavi i dynamic template di SendGrid, dovrai migrare quei layout HTML/CSS nel motore di template del nuovo provider.

Esempio: da SendGrid a un'API REST generica

SendGrid usa una struttura JSON specifica per personalizations. La maggior parte delle API moderne, SendHQ compresa, preferisce una struttura più piatta e più leggibile.

Payload SendGrid:

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

Payload di un'API moderna (ad es. SendHQ):

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

Gestire la migrazione nel codice

Per evitare downtime, implementa un wrapper o uno strategy pattern. Così puoi passare da un provider all'altro con una variabile d'ambiente.

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();

Passo 4: agenti AI e idempotenza

Se usi agenti AI per attivare le email, corri un rischio specifico: l'agente può andare in loop o ritentare una richiesta più volte a causa di un timeout, e l'utente finisce per ricevere dieci email identiche.

Inviare un'email è un effetto collaterale esterno. Devi implementare l'idempotenza. Una chiave di idempotenza è un identificatore univoco inviato nell'intestazione che dice all'API: "Se hai già visto questa chiave, non inviare di nuovo l'email; restituisci solo la risposta di successo originale."

Implementazione pronta per gli agenti:

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

Inoltre, per le azioni ad alto rischio degli agenti (come l'invio di una reimpostazione della password o di un avviso di fatturazione), implementa un passaggio di approvazione human-in-the-loop o un limite di frequenza rigido per ID utente, così le allucinazioni degli agenti non inonderanno di spam i tuoi clienti.

Passo 5: test e validazione

Prima di impostare la variabile d'ambiente sul nuovo provider, completa questa checklist:

• Propagazione DNS: usa uno strumento come dig o un controllo via web per assicurarti che i nuovi record DKIM e SPF siano attivi.
• Verifica dei webhook: se ti basi sugli eventi di consegna (delivered, opened, clicked), aggiorna i tuoi endpoint webhook. Il formato degli eventi di SendGrid è diverso da quello degli altri. Assicurati che il tuo endpoint gestisca il nuovo schema JSON senza andare in crash.
• Gestione degli errori: verifica come la tua applicazione gestisce gli errori specifici del provider. Ad esempio, un 429 (Too Many Requests) dovrebbe attivare una strategia di backoff, mentre un 400 (Bad Request) di solito indica un indirizzo email malformato che andrebbe segnato come bounce nel tuo database.

Casi di errore comuni da testare

1. Formato email non valido: assicurati che l'API restituisca un errore chiaro e che il tuo codice non ritenti all'infinito.
2. Limiti di frequenza: simula un picco di email per vedere se la tua coda gestisce i limiti del provider.
3. Allegati di grandi dimensioni: verifica la dimensione massima del payload del nuovo provider. Alcuni la limitano a 10MB, altri a 25MB.

Checklist riassuntiva per la migrazione

• Esporta soppressioni: esportazione CSV da SendGrid.
• Configura record DNS: allineamento di SPF, DKIM e DMARC.
• Migra i template: converti HTML/CSS nel nuovo formato.
• Aggiorna la logica API: implementa un wrapper del provider.
• Aggiungi l'idempotenza: essenziale per i trigger degli agenti AI.
• Testa i webhook: verifica la consegna e il parsing degli eventi.
• Sposta il traffico: aggiorna la variabile ENV e monitora i log.

Considerazioni finali sulla deliverability

Cambiare provider è un ottimo momento per fare un audit delle tue abitudini di invio. Ricorda che l'accettazione da parte del provider è solo il primo ostacolo. La consegna dipende dal fatto che l'ISP ricevente (Gmail, Outlook, ecc.) accetti la connessione. L'arrivo in inbox è l'ultimo ostacolo, e lo determinano la reputazione a lungo termine del tuo dominio e i tassi di engagement dei destinatari.

Resisti alla tentazione di usare queste API per email massive non richieste. Non solo spesso è illegale, ma porterà alla sospensione del tuo account qualunque provider tu scelga. Limitati a comunicazioni transazionali e con consenso esplicito per mantenere un buon sender score.

Se il tuo team costruisce applicazioni AI-native, cerca provider che offrano funzionalità pronte per gli agenti, come server MCP e file llms.txt, per un'integrazione senza attriti. SendHQ è progettato esattamente per questo flusso e fornisce l'infrastruttura di cui hanno bisogno i team di prodotto moderni.

Scopri di più su come costruire sistemi email affidabili su https://sendhq.cc.