Come inviare email dalla tua app (e farle arrivare in posta in arrivo)

Per inviare email dalla tua app in modo affidabile, usa un provider di invio email invece della tua casella personale, invia da un indirizzo del tuo dominio e aggiungi i record DNS forniti dal provider in modo che SPF, DKIM e DMARC risultino tutti validi. Tieni separate le email transazionali — reset della password, ricevute, conferme — dalle email di marketing, invia ciascuna solo a chi se l’aspetta e gestisci i bounce e le cancellazioni. Prima di tutto sistema l’autenticazione: è il motivo più comune per cui le email delle app finiscono nello spam.

Email transazionali e di marketing

I due tipi di email sembrano simili nel codice, ma i provider di posta e la legge li trattano in modo molto diverso.

Tienile separate. Se una campagna di marketing riceve segnalazioni di spam, non vuoi che ne risentano anche i reset della password inviati dallo stesso flusso. Un approccio comune è usare sottodomini distinti — per esempio mail.esempio.it per le email dell’account e news.esempio.it per le newsletter — e alcuni provider separano già i due flussi internamente. Postmark, per esempio, descrive i suoi «message stream» transazionali e broadcast come infrastrutture di invio separate, a settembre 2026.

Scegliere un provider

La tua app non dovrebbe inviare email direttamente dal proprio server. I provider di invio si occupano dell’infrastruttura, della reputazione degli IP, dei tentativi di nuovo invio e della gestione dei bounce. Tra le opzioni più note ci sono Postmark, Resend, SendGrid, Amazon SES e Mailgun; ognuno offre un’API HTTP e l’accesso SMTP. Prezzi e piani cambiano, quindi confrontali sui rispettivi siti.

Cosa confrontare:

• Focus. Alcuni provider si concentrano sul transazionale, altri combinano transazionale e marketing.
• Esperienza di sviluppo. API chiara, librerie ufficiali per il tuo linguaggio, log utili che mostrano se ogni messaggio è stato consegnato, respinto o segnalato come spam.
• Webhook per bounce, reclami e consegne, così la tua app può reagire.
• Template — salvati presso il provider oppure nel tuo codice. Tenerli nel codice li rende versionati e testabili.
• Regione e trattamento dei dati, se hai requisiti su dove vengono elaborati i dati.
• Costo al tuo volume, incluso cosa succede quando superi il piano gratuito.

Per le newsletter verso una lista, uno strumento dedicato di newsletter o email marketing è spesso più adatto che costruire funzioni di campagna dentro la tua app.

Configura il dominio mittente

Invia dal tuo dominio — ciao@esempio.it, non da un indirizzo Gmail o Outlook. La posta da una casella gratuita inviata tramite un servizio di terze parti non supera i controlli di autenticazione e rischia di essere filtrata.

Valuta un sottodominio dedicato solo all’invio. Resend, per esempio, consiglia di inviare da sottodomini come aggiornamenti.esempio.it per isolare la reputazione di invio (a settembre 2026). Così i record DNS dell’email restano separati da quelli del tuo sito principale.

Il provider ti fornirà poi i record DNS da aggiungere presso il gestore del DNS del tuo dominio. Se il DNS ti è nuovo, come funzionano domini e DNS spiega prima i record.

SPF

SPF (Sender Policy Framework) è un record TXT che elenca i server autorizzati a inviare email per il tuo dominio. Chi riceve verifica se il server mittente è nell’elenco.

• Un dominio dovrebbe avere un solo record SPF. Se aggiungi un provider, unisci la sua voce nel record esistente invece di aggiungerne un secondo.
• SPF consente al massimo 10 ricerche DNS durante la valutazione; catene lunghe di voci include: possono superare il limite e causare errori.
• Molti provider impostano SPF su un sottodominio di return-path che ti chiedono di creare, quindi potresti non toccare affatto il tuo record SPF principale.

DKIM

DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica a ogni messaggio. Il provider firma con una chiave privata; tu pubblichi la chiave pubblica corrispondente come record DNS (TXT o CNAME, a seconda del provider). Chi riceve controlla la firma per confermare che il messaggio arrivi da un mittente autorizzato e non sia stato alterato lungo il percorso.

DKIM è soprattutto ciò che riguarda il passaggio «verifica dominio» del provider. Non saltarlo.

DMARC

DMARC collega gli altri due. È un record TXT su _dmarc.tuodominio.it che dice a chi riceve:

• Allineamento: il dominio nell’indirizzo From visibile deve corrispondere al dominio che ha superato SPF o DKIM.
• Policy: cosa fare con la posta che fallisce — p=none (solo segnalare), p=quarantine (trattarla come sospetta, spesso spam) oppure p=reject.
• Report: dove inviare i report aggregati (rua=), così vedi chi invia come il tuo dominio.

Un percorso sensato è partire con p=none e un indirizzo per i report, verificare che la posta legittima superi i controlli, poi passare a quarantine e infine a reject. Una policy rigorosa rende anche molto più difficile per altri impersonare il tuo dominio.

Cosa richiede Gmail

Da settembre 2026, le linee guida di Google per i mittenti dicono:

• Tutti i mittenti verso account Gmail personali devono avere SPF o DKIM, DNS diretto e inverso validi per i server di invio, TLS e un tasso di spam in Postmaster Tools inferiore allo 0,3%.
• I mittenti in blocco (più di 5.000 messaggi al giorno verso Gmail) devono avere SPF e DKIM, un record DMARC (è ammessa una policy p=none), allineamento del dominio From e la cancellazione con un clic, più un link di cancellazione visibile su marketing e messaggi di abbonamento.

Il tuo provider gestisce la parte lato server. I record DNS e la gestione delle cancellazioni sono invece compito tuo. Anche se sei ben lontano dai 5.000 al giorno, rispettare le regole per i mittenti in blocco è il modo più semplice per stare al sicuro.

Integra l’invio nella tua app

Una volta verificato il dominio:

1. Salva la chiave API come segreto lato server — mai nel codice front-end. Vedi cosa sono le variabili d’ambiente e i segreti.
2. Invia dal server, dopo che l’azione che attiva l’email è andata a buon fine.
3. Non far aspettare l’utente per l’email. Per qualsiasi app oltre la più semplice, metti l’invio in coda e riprova in caso di errori temporanei, così una risposta lenta del provider non rallenta la registrazione.
4. Registra l’esito — l’ID del messaggio e lo stato dal provider — senza loggare la chiave o i corpi completi dei messaggi con dati personali.
5. Gestisci i webhook per bounce e reclami: smetti di inviare agli indirizzi con hard bounce o che ti segnalano come spam.

Un prompt che copre le basi:

Invia le email transazionali con [PROVIDER] usando il segreto del server [ENV_NAME], dal mittente "Acme ciao@mail.acme.com". Invia un’email di benvenuto dopo la registrazione e una conferma di prenotazione dopo il salvataggio di una prenotazione. Tieni i template nel codice, con una versione in testo semplice accanto all’HTML. Metti in coda gli invii e riprova fino a tre volte in caso di errori temporanei. Registra i fallimenti con l’errore del provider ma mai la chiave API. Aggiungi un endpoint webhook che segna gli indirizzi come non recapitabili in caso di hard bounce e reclami, e salta quegli indirizzi nei futuri invii.

Le email dell’account — link di verifica, magic link e reset della password — fanno parte del login. Come aggiungere il login alla tua app spiega come si integrano questi flussi; rendi questi link monouso e di breve durata.

Abitudini per la consegna

L’autenticazione ti fa considerare. Il comportamento ti mantiene in posta in arrivo.

• Invia solo ciò che la gente si aspetta. Registrazioni confermate, opt-in chiaro per il marketing, niente liste acquistate.
• Rendi facile la cancellazione per tutto ciò che non è strettamente transazionale, e rispettala subito.
• Scalda i domini nuovi. Un dominio appena creato che invia migliaia di messaggi il primo giorno sembra sospetto. Parti con la posta transazionale e aumenta il volume gradualmente.
• Tieni pulite le liste. Rimuovi subito gli hard bounce e valuta di rimuovere chi da molto tempo non apre nulla.
• Scrivi come una persona. Un oggetto chiaro, un nome From riconoscibile, una parte in testo semplice, poche immagini e link al tuo dominio. Evita gli accorciatori di link.
• Monitora. Registra il dominio in Google Postmaster Tools e leggi ogni tanto i report DMARC.
• Usa un reply-to reale che qualcuno legge. Le risposte sono un buon segnale e un feedback utile.

Testare senza spammare nessuno

• Usa la modalità test o sandbox del provider, dove esiste, oppure invia a indirizzi di tua proprietà.
• In sviluppo, invia a una casella di test che raccoglie tutto invece che agli utenti reali; un database popolato con indirizzi dall’aspetto reale è un modo facile per scrivere per sbaglio a sconosciuti.
• Controlla ogni template in alcuni client — Gmail web, l’app di posta sul telefono, Outlook — e anche in modalità scura.
• Guarda le intestazioni di un’email di prova: mostrano se SPF, DKIM e DMARC sono stati superati.

Aspetti legali di base

Le regole cambiano da paese a paese. In linea generale, l’email di marketing richiede in molti luoghi il consenso, deve identificare il mittente e offrire una cancellazione funzionante; l’email transazionale è trattata diversamente, ma non dovrebbe essere usata per inserire pubblicità. Se raccogli indirizzi da una pagina di waitlist, spiega cosa invierai e conserverai, e quando e come ogni persona si è iscritta. Nel dubbio, verifica le regole dove si trovano i tuoi utenti.

Checklist per l’email

• Provider di invio scelto; chiave API salvata come segreto del server
• Invio dal tuo dominio o sottodominio, non da una casella gratuita
• Record SPF, DKIM e DMARC aggiunti e validi
• Posta transazionale e di marketing separate
• Invii messi in coda e con nuovi tentativi; esiti registrati
• Webhook per bounce e reclami gestiti
• Cancellazione nella posta non transazionale, rispettata subito
• Template testati in più client; le email di prova non raggiungono mai utenti reali

Inviare email da un’app Mythex

Mythex non include un servizio di invio email integrato per le app che crei, quindi porti un provider come Resend, SendGrid o Postmark. Salva la sua chiave API come segreto del progetto — l’agente può chiederla con una scheda segreti in chat — e chiedi in parole semplici le email di cui hai bisogno. La documentazione contiene un prompt di partenza in inviare email dalla tua app. Se hai acquistato il dominio tramite Mythex con il piano Pro, puoi aggiungere i record TXT e CNAME del provider nelle impostazioni DNS del dominio; vedi domini personalizzati.

Domande