tva
← Insights

Configurare una Casella Email per il Tuo Agente AI Dedicato al Progetto

Prima o poi, l'agente AI dedicato al progetto che hai costruito avrà bisogno di un indirizzo email. Il pattern con il bot Telegram che abbiamo descritto in Building a Project-Specific AI Assistant via Telegram gestisce la chat in tempo reale, ma la posta elettronica è un canale diverso — notifiche di servizio, conferme dai fornitori, reset delle password OAuth, corrispondenza di backoffice con persone che non sono su Telegram. Puoi instradare quella posta verso un indirizzo personale e convivere con il rumore, oppure dare al progetto la propria casella su un sottodominio dedicato.

Questa guida percorre la seconda strada: una casella dedicata su un sottodominio di progetto, con DKIM, SPF e DMARC configurati correttamente. Il pattern usa un provider per il DNS (Cloudflare nel nostro caso) e un provider separato per il sistema di posta (Opalstack) — che è la configurazione in cui finisce la maggior parte delle piccole operazioni: DNS dove vive già il dominio principale, posta presso il provider con un buon IMAP, accesso API ragionevole e una reputazione che sopravvive ai filtri di Gmail.

L'intera configurazione si riduce a quattro chiamate API e tre record DNS. Con la giusta preparazione preliminare, il tutto richiede circa dieci minuti dall'inizio alla fine. Mostreremo le chiamate, la verifica e i problemi che ci hanno colpito la prima volta.

Cosa Risolve Questa Guida

  • Un sottodominio di progetto (system.example.com) senza infrastruttura email collegata
  • Mail in entrata a un indirizzo dedicato al progetto che rimbalza perché non esiste un record MX
  • Mail in uscita dal progetto che fallisce i controlli DKIM su Gmail e finisce nello spam
  • Record SPF e DMARC che esistono ma non hanno nulla da autenticare
  • Un agente AI che ha bisogno di un canale email senza passare per il tuo account personale

Di Cosa Hai Bisogno

  • Un dominio principale che controlli, con DNS presso un provider che espone un'API (Cloudflare, Route53, DigitalOcean DNS, ecc.)
  • Un provider email che supporti l'aggiunta di domini via API, generi le chiavi DKIM alla creazione del dominio ed esponga endpoint IMAP/SMTP (Opalstack, Mailcow, Migadu, Fastmail, ecc.)
  • Token API per entrambi i provider, salvati in un posto da cui puoi fare chiamate da shell
  • dig, openssl s_client e un interprete Python per la verifica
  • Una quindicina di minuti

Perché il Pattern con Provider Separati

Il modello mentale predefinito è "un solo provider per tutto" — ospitare il sito, il DNS e la casella email nello stesso posto. Funziona finché uno dei tre non ha bisogno di evolvere in modo indipendente. Abbiamo analizzato il framework decisionale per scegliere tra servizi integrati e specialisti dedicati in The Self-Hosting Decision: When SaaS Costs More Than Your Own Infrastructure, e la stessa logica si applica qui su scala ridotta.

Nel nostro caso, il DNS del dominio principale è su Cloudflare perché abbiamo bisogno della risoluzione AnyCast, del proxying per i siti pubblici e dell'API per la gestione automatizzata dei record. Il sistema email è su Opalstack perché il costo per casella è trascurabile, la reputazione del loro server IMAP è solida e la loro API è una delle più pulite nel panorama dell'hosting email europeo. Non stiamo spostando il DNS per inseguire la posta, né spostiamo la posta per inseguire il DNS. Il costo di gestirli separatamente si riduce esattamente a tre record DNS e un unico modello mentale: il provider DNS dice al mondo dove va la posta; il provider email la riceve, la conserva e la firma.

Questa separazione ha un valore operativo preciso: limita il raggio d'azione dei guasti. Un'interruzione del provider DNS blocca le nuove decisioni di routing, ma la posta già in transito verso gli host MX continua ad arrivare. Un'interruzione del provider email blocca la consegna, ma le risoluzioni DNS continuano a funzionare. Se avessimo concentrato tutto su un unico provider, entrambi i livelli avrebbero ceduto insieme. La stessa logica emerge nella nostra architettura di produzione per il layering dei reverse proxy — separazione delle responsabilità, ogni livello sostituibile in isolamento.

Casella Dedicata, Alias di Inoltro o Inbox SaaS

Prima di creare qualsiasi cosa, scegli il livello di dedizione giusto. Le tre opzioni non sono equivalenti.

Una casella dedicata significa una vera inbox che conserva la posta, ha credenziali IMAP e può sia inviare che ricevere. Costo: da uno a tre euro al mese presso un provider email self-hosted, più il lavoro di configurazione via API. È quello che usa l'agente AI quando ha davvero bisogno di leggere la posta — per analizzare le conferme in arrivo dai fornitori, gestire le notifiche di servizio, mantenere uno scambio con un interlocutore umano su più turni.

Un alias di inoltro significa un indirizzo virtuale che reindirizza semplicemente verso una casella esistente. Costo: zero, solo configurazione. È la scelta giusta quando l'agente AI deve solo ricevere a un indirizzo con il brand del progetto, ma la lettura e l'elaborazione avvengono in una casella umana già esistente. Il compromesso è nessun accesso IMAP per l'agente, nessun filtro per progetto sul lato destinazione e nessun percorso di rollback pulito quando il progetto finisce — la pulizia degli alias viene sempre dimenticata.

Una inbox SaaS significa un servizio come Postmark, Mailgun Inbound o AWS SES con regole di ricezione. Costo: fatturazione per messaggio più il lavoro di ingegneria per collegare l'agente AI ai receiver webhook. È la scelta giusta quando l'agente deve gestire volumi elevati, instradare la posta in base a regole sugli header o attivare workflow automatizzati per ogni messaggio. Per un agente dedicato a un progetto che gestisce decine o centinaia di messaggi al mese, è eccessivo.

Per il caso d'uso descritto in the Telegram AI assistant post — un operatore umano, due collaboratori di progetto, un bot basato su Claude — la casella dedicata è la scelta giusta. L'agente ottiene un indirizzo reale che può leggere con IMAP, da cui può inviare con SMTP e che nasce e muore insieme al progetto.

Passo 1: Registra il Sottodominio nel Tuo Sistema Email

Il provider email deve sapere che il sottodominio del tuo progetto è uno dei suoi domini prima di accettare posta per esso. Questa è la chiamata che genera anche la coppia di chiavi DKIM.

POST https://my.mailhost.example/api/v1/domain/create/
Authorization: Token <YOUR_MAIL_API_TOKEN>
Content-Type: application/json

[{"name": "system.example.com"}]

La risposta contiene tre campi che ti interessano: l'UUID del dominio (necessario per la pulizia e per il mapping degli indirizzi in seguito), lo state (di solito PENDING_CREATE per qualche secondo, poi READY) e un campo dkim_record con un valore TXT già formattato, pronto da incollare nel DNS:

{
  "id": "<DOMAIN_UUID>",
  "state": "PENDING_CREATE",
  "name": "system.example.com",
  "dkim_record": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."
}

Esegui il polling finché lo state non diventa READY, poi cattura il valore di dkim_record. Lo incollerai così com'è nel provider DNS al passo successivo. Se la chiamata di creazione fallisce con un errore invalid hostname, la causa più comune è che il tuo provider email supporta solo domini di secondo livello e non accetta sottodomini a tre livelli. Apri un ticket di supporto; nella pratica non abbiamo ancora incontrato un provider che rifiutasse davvero questo.

Prima di procedere, controlla la dimensione della chiave DKIM. Un valore dkim_record sotto circa 250 byte corrisponde a una chiave RSA a 1024 bit; le chiavi a 2048 bit occupano circa 380–420 byte. Il NIST ha deprecato RSA a 1024 bit nel 2013, e Gmail, Microsoft, Yahoo e AWS SES trattano i 2048 bit come standard minimo per il 2026 — le chiavi a 1024 bit autenticano ancora ma vengono considerate un segnale debole dai filtri antispam aziendali. Se il tuo provider ti permette di scegliere la dimensione, scegli 2048; un default a soli 1024 bit è un segnale che dice qualcosa sul provider.

Passo 2: Configura i Record DNS

Tre record, tutti creati presso il tuo provider DNS per il sottodominio di progetto. Nessuno di essi può essere proxiato attraverso il perimetro di Cloudflare — i record MX e TXT devono essere DNS-only, e l'API di Cloudflare tornerà silenziosamente a DNS-only se imposti proxied: true, ma è più pulito impostarlo esplicitamente.

I due record MX indicano ai mittenti dove consegnare la posta. La maggior parte dei provider email gestisce due o più host MX con priorità uguale per il failover round-robin:

POST https://api.dnsprovider.example/zones/<ZONE_ID>/dns_records

{"type":"MX","name":"system.example.com",
 "content":"mx1.de.mailhost.example","priority":10,
 "ttl":3600,"proxied":false}

{"type":"MX","name":"system.example.com",
 "content":"mx2.de.mailhost.example","priority":10,
 "ttl":3600,"proxied":false}

Il record TXT DKIM usa il valore dkim_record del Passo 1, posizionato su dkim._domainkey.<sottodominio>:

{"type":"TXT",
 "name":"dkim._domainkey.system.example.com",
 "content":"v=DKIM1; k=rsa; p=MIGfMA0G...",
 "ttl":3600,"proxied":false}

Se la chiave pubblica DKIM è più lunga di 255 byte (come nel caso delle chiavi RSA a 2048 bit), dovrai suddividerla in più blocchi tra virgolette: "blocco1" "blocco2". La maggior parte dei provider DNS gestisce la suddivisione automaticamente via API; se il tuo non lo fa, la suddivisione deve avvenire dalla tua parte.

I record SPF e DMARC si impostano una volta sola, sul sottodominio stesso e su _dmarc.<sottodominio>. SPF indica ai destinatari quali IP sono autorizzati a inviare per questo dominio; DMARC indica loro cosa fare quando SPF o DKIM falliscono:

{"type":"TXT","name":"system.example.com",
 "content":"v=spf1 include:spf.mailhost.example ~all",
 "ttl":3600,"proxied":false}

{"type":"TXT","name":"_dmarc.system.example.com",
 "content":"v=DMARC1; p=none; rua=mailto:[email protected]; aspf=r; adkim=r",
 "ttl":3600,"proxied":false}

Inizia DMARC con p=none. Questa è la modalità di monitoraggio — i destinatari inviano report aggregati all'indirizzo rua, ma nessuna posta viene rifiutata in base alla policy. Il rollout standard prevede da due a sei settimane con p=none finché i report aggregati mostrano almeno il 98% di conformità per la posta legittima, poi un incremento graduale tramite il tag pct= — ad esempio p=quarantine; pct=25 per due settimane, poi pct=75, poi pct=100, e infine p=reject. Saltare l'incremento graduale e passare direttamente a p=reject su un dominio appena creato è un modo sicuro per perdere la tua stessa posta legittima prima di aver validato il percorso di firma DKIM.

Passo 3: Crea la Casella e il Mapping degli Indirizzi

Il modello dati del provider email ha di solito due risorse separate: un mailuser (l'account IMAP con credenziali e quota) e un address (la stringa local@domain che instrada la posta verso un mailuser). Sono separate perché lo stesso mailuser può essere la destinazione di diversi indirizzi sullo stesso dominio o su domini diversi.

Genera una password robusta e crea il mailuser. La convenzione di naming varia per provider; il pattern comune è <local>_<dominio-con-underscore>. Attenzione al limite di lunghezza — la maggior parte dei provider limita i nomi mailuser a 32 caratteri, soglia facile da superare con un sottodominio più lungo:

import secrets, string
alphabet = string.ascii_letters + string.digits + "!@#%^&*-_=+"
password = ''.join(secrets.choice(alphabet) for _ in range(32))

# Then:
POST /api/v1/mailuser/create/
[{"name": "bot_system_example_com",
  "imap_server": "<IMAP_SERVER_UUID>",
  "password": password}]

Una volta che il mailuser è READY, crea il mapping dell'indirizzo che collega local@sottodominio ad esso:

POST /api/v1/address/create/
[{"source": "[email protected]",
  "destinations": ["<MAILUSER_UUID>"],
  "forwards": []}]

L'array forwards è per gli indirizzi esterni aggiuntivi che devono ricevere una copia. Lascialo vuoto a meno che tu non voglia davvero che la casella inoltri in parallelo a una casella umana — un pattern utile durante la fase di passaggio del progetto, ma disordinato nel lungo termine.

Passo 4: Verifica la Configurazione End-to-End

Quattro verifiche, nell'ordine. Non saltare quella del loopback — è l'unico test che conferma che il routing in entrata raggiunga effettivamente la casella.

Propagazione DNS. I provider AnyCast come Cloudflare di solito propagano in meno di un minuto. Esegui il loop finché non compaiono entrambi i record:

for i in $(seq 1 36); do
  mx=$(dig +short system.example.com MX)
  dkim=$(dig +short dkim._domainkey.system.example.com TXT)
  if [ -n "$mx" ] && [ -n "$dkim" ]; then break; fi
  sleep 5
done
echo "MX: $mx"
echo "DKIM: $dkim"

Login IMAP. Conferma che le credenziali funzionino e che la casella sia effettivamente supportata da una inbox:

openssl s_client -crlf -connect imap.mailhost.example:993 -quiet
a1 LOGIN bot_system_example_com <password>
a2 SELECT INBOX

Risposta attesa: a1 OK Logged in seguita dal SELECT che conferma EXISTS 0 su una casella nuova.

Self-loopback. Il miglior test end-to-end: invia una mail dal nuovo indirizzo a sé stesso e verifica che arrivi in IMAP. Questo valida l'intero percorso — autenticazione SMTP, firma DKIM, risoluzione MX, accettazione della mail, consegna alla casella, visibilità IMAP — senza dipendere dalla cooperazione del filtro antispam di alcun provider esterno:

import smtplib, ssl, imaplib, time
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "[email protected]"
msg["To"]   = "[email protected]"
msg["Subject"] = "loopback test"
msg.set_content("hello self")

with smtplib.SMTP("smtp.mailhost.example", 587) as s:
    s.starttls(context=ssl.create_default_context())
    s.login("bot_system_example_com", "<password>")
    s.send_message(msg)

time.sleep(10)
imap = imaplib.IMAP4_SSL("imap.mailhost.example", 993)
imap.login("bot_system_example_com", "<password>")
imap.select("INBOX")
typ, search = imap.search(None, "ALL")
print("inbox count:", len(search[0].split()))

Negli header della mail consegnata, cerca la riga Authentication-Results. Una configurazione corretta mostra spf=pass con il giusto smtp.mailfrom e un header DKIM-Signature con d=<il tuo sottodominio> e s=dkim. Se questi sono presenti, ogni parte della catena funziona; l'unica variabile rimanente è come i destinatari esterni si sentono nei tuoi confronti, e i report DMARC te lo diranno nei giorni successivi.

Invio esterno. Invia una mail a un indirizzo esterno che puoi verificare — una Gmail personale, una casella di lavoro separata, qualcosa fuori dal sistema. Conferma che arrivi nella inbox, non nello spam. Se finisce nello spam al primissimo invio da un dominio nuovo, la causa più comune è una reputazione del dominio mittente che non esiste ancora; il riscaldamento è graduale, ma una singola mail di test dovrebbe passare senza problemi perché il destinatario valuta DKIM e SPF per i loro meriti intrinseci, non per il volume storico degli invii.

Problemi Comuni

Il limite di 32 caratteri per il nome mailuser colpisce ogni volta che il sottodominio più la parte locale è più lungo del previsto. backoffice_dashboard_system_example_com arriva a trentanove caratteri e viene rifiutato; bo_dashboard_system_example_com sta in trentuno. Scegli le abbreviazioni consapevolmente piuttosto che lasciare che sia l'API a importele a metà del deploy.

La trappola del proxy Cloudflare. L'interfaccia di Cloudflare ti permette di attivare il proxy arancione per qualsiasi record. Per A/AAAA su un'origine web lo vuoi quasi sempre attivo. Per i record MX è sempre disattivato — Cloudflare non fa da proxy per la posta. La trappola scatta quando abiliti il proxying in massa tramite uno script e includi accidentalmente i record MX. Cloudflare elimina silenziosamente il flag proxy per i tipi non supportati, quindi sembra che abbia funzionato, ma perdi minuti a debuggare qualcosa che in apparenza va bene.

Greylisting al primo messaggio in entrata. I sistemi di posta a volte mettono in greylisting il primo messaggio da un mittente sconosciuto — risposta 4xx temporanea, chiede al mittente di riprovare tra qualche minuto. Gmail riprova automaticamente. Se il tuo primo smoke test in entrata sembra fallire, aspetta quindici minuti prima di dichiararlo rotto.

Il tetto di lookup DNS per SPF. SPF ha un limite rigido di dieci lookup DNS durante la valutazione (RFC 7208 §4.6.4). Un singolo include:spf.mailhost.example conta come un lookup anche se quell'include si risolve internamente in decine di IP. Il tetto si raggiunge solo se si inizia a concatenare più mittenti — ad esempio aggiungendo in seguito include:_spf.resend.com per una pipeline marketing. Pianifica il record SPF per la lista di mittenti a lungo termine, non solo per il primo.

dkim_privkey vuoto lato provider email. Alcuni provider espongono un endpoint di creazione dominio che ha successo ma non genera effettivamente la chiave DKIM, richiedendo una chiamata separata di "attivazione DKIM". Verifica che il campo dkim_record nella risposta di creazione non sia vuoto prima di procedere. Se è vuoto, consulta la documentazione del provider per la chiamata secondaria.

Monitoraggio superficiale del deployment. Se gestisci decine di domini, un record DKIM non sano o una destinazione DMARC scaduta per i report non emergeranno nel monitoraggio di routine a meno che tu non li controlli attivamente. La nostra routine mensile di health check per i servizi self-hosted include proprio per questo motivo un passaggio di verifica dei record email.

Trascurare MTA-STS dove disponibile. MTA-STS pubblica una policy che forza i mittenti a usare TLS verso i tuoi host MX e a validarne il certificato. Gmail, Microsoft 365 e Yahoo la controllano; l'adozione globale è ancora sotto l'uno percento, quindi una policy valida è un piccolo segnale di reputazione. Il compromesso è operativo: una policy che punta a host MX con TLS non funzionante blocca la posta legittima in entrata. Se il tuo provider supporta MTA-STS, abilitalo dopo che DKIM e DMARC sono stabili.

Percorso di Rollback

Se la verifica fallisce o decidi che il progetto non ha bisogno di una propria casella, la pulizia è idempotente e richiede cinque minuti:

  1. POST /api/v1/address/delete/ con l'UUID dell'indirizzo
  2. POST /api/v1/mailuser/delete/ con l'UUID del mailuser
  3. POST /api/v1/domain/delete/ con l'UUID del dominio nel sistema email (questo elimina anche le chiavi DKIM)
  4. DELETE /zones/<zone>/dns_records/<id> per ciascuno dei tre record DNS

L'ordine è importante perché alcuni provider rifiutano di eliminare il dominio se ci sono ancora indirizzi collegati. L'ordine inverso ti dà anche un punto sensato in cui fermarsi e ispezionare — se il Passo 1 fallisce perché c'è posta nella casella che hai dimenticato, non hai ancora rotto il routing a livello DNS.

Lasciare i record SPF e DMARC sul sottodominio dopo un rollback è innocuo. Autenticano contro nulla, ma comunicano ai futuri destinatari che questo sottodominio non invia esplicitamente posta legittima — il che è un piccolo beneficio anti-spoofing. Li trattiamo come attivi per default una volta che esistono. Questo tipo di ragionamento sui "residui sicuri" è la stessa logica che applichiamo al disaster recovery per i servizi self-hosted: il pattern di cleanup-after conta quanto il pattern di install.

Conclusioni

Una casella dedicata al progetto non è infrastruttura; è un piccolo primitivo operativo che permette a un agente AI — o a qualsiasi altro processo automatizzato — di diventare un partecipante di prima classe nei workflow basati su email. Il pattern con quattro chiamate API descritto sopra si trasferisce agevolmente tra provider email; i record DNS si trasferiscono agevolmente tra provider DNS. Quello che vale la pena fare bene è il confine tra i due sistemi: quale record vive dove, come si presentano i failure mode e come verificare end-to-end senza dipendere dal comportamento del filtro antispam di alcun interlocutore esterno.

Se vuoi aiuto per progettare uno stack dedicato al progetto — agente Telegram, casella email, acquisizione documenti e tutto il resto — tva può aiutarti.

Approfondimenti Correlati

Articoli correlati

Costruire un assistente AI dedicato a un progetto via Telegram

Ottimizzare un Agente in Stile Hermes che Cresce con il Progetto

Costruire Skill per Agenti AI per Flussi di Lavoro Aziendali Specifici del Dominio