Test delle email Amazon SES

Controlla prima la sandbox, perché determina se tutto questo può funzionare. Ogni nuovo account SES parte nella sandbox in ogni Region e, finché rimane lì, SES consegna i messaggi solo a indirizzi verificati, domini verificati e al proprio simulatore di caselle di posta. Si applicano inoltre i limiti di 200 messaggi ogni 24 ore e di un messaggio al secondo.

Verificare un indirizzo di Email Spam Tester non permette di aggirare il limite. SES verifica un destinatario inviandogli un'email con un link e, poiché i nostri indirizzi accettano esattamente un messaggio prima di chiudersi, l'email di verifica consumerebbe quell'unico messaggio. In pratica, devi quindi avere l'accesso alla produzione nella Region da cui invii. AWS promette una prima risposta alla richiesta entro 96 ore.

Poiché lo stato della sandbox è specifico per ogni Region, un account in produzione in eu-west-1 può essere ancora nella sandbox in us-east-1. Anche le identità sono specifiche per ogni Region e ciascuna ha i propri record DKIM.

Ottieni un indirizzo e invia un messaggio

Apri email-spam-tester.com e copia l'indirizzo mostrato. Non richiede un account né una chiave API e ha il formato test- seguito da venti caratteri su t.email-spam-tester.com. Hai un'ora e un solo messaggio, quindi prepara il comando di invio prima di ottenere l'indirizzo.

Il metodo di invio più semplice usa la CLI, adattato dall'esempio di AWS nella pagina dedicata ai tenant SES, rimuovendo i parametri per il tenant e il set di configurazione:

aws sesv2 send-email \
  --from-email-address "sender@yourdomain.com" \
  --destination "ToAddresses=test-xxxxxxxxxxxxxxxxxxxx@t.email-spam-tester.com" \
  --content "Simple={Subject={Data='Test Subject',Charset=utf-8},Body={Text={Data='Test email body',Charset=utf-8}}}"

Il mittente From deve essere un'identità verificata, anche in produzione. Un corpo di solo testo come questo è sufficiente per verificare l'autenticazione e l'IP, ma non dice quasi nulla sul contenuto. Per ottenere un responso reale, invia il messaggio effettivamente usato dalla tua applicazione, includendo la parte HTML e le intestazioni. Usa anche lo stesso percorso del codice, che sia send_email di boto3, una libreria SMTP o altro. Se gli invii in produzione usano un set di configurazione, aggiungi anche --configuration-set-name, così il test viene eseguito con le stesse impostazioni.

Il test della posta in arrivo usa lo stesso comando. Aggiungi le caselle dei provider a ToAddresses accanto all'indirizzo di test e il relativo marcatore ai dati di Subject. Una sola chiamata genera quindi due report. Il secondo indica la cartella in cui è arrivato il messaggio su Gmail, Outlook, Yahoo e altri provider. Neanche queste caselle sono verificate, quindi anche in questo caso è necessario l'accesso alla produzione.

Puoi usare anche la console. Apri Configuration > Identities, fai clic sull'identità e scegli Send test email, selezionando Raw se vuoi incollare un messaggio MIME completo con le tue intestazioni. AWS descrive la console come uno strumento che in genere si usa solo per le email di prova e la documentazione non indica alcun prefisso di test né altre modifiche al messaggio. Nella sandbox, il campo Custom recipient richiede un indirizzo verificato, riportandoti al problema descritto sopra.

Come appare una nuova identità SES nel report

DKIM. Easy DKIM è l'impostazione predefinita per le identità di dominio e firma ogni messaggio con una chiave a 2048 bit. La configurazione richiede tre record CNAME denominati token._domainkey.yourdomain.com che puntano a token.dkim.<region>.amazonses.com. Se il controllo DKIM non riesce, verifica prima due aspetti: se la propagazione DNS è terminata (AWS indica fino a 72 ore) e se il tuo host DNS ha aggiunto il dominio al nome creando token._domainkey.yourdomain.com.yourdomain.com. Con BYODKIM, invece, pubblichi un record TXT usando un tuo selettore. Durante il passaggio da un metodo all'altro, SES potrebbe inviare messaggi del tutto privi di firma, che il report segnala come DKIM mancante. Il controllo DKIM usa il token come selettore.

SPF e il percorso di ritorno. Per impostazione predefinita, SES usa un sottodominio di amazonses.com come MAIL FROM. SPF supera il controllo, ma per amazonses.com, quindi il report mostra SPF come non allineato con il tuo From. Quando DKIM è allineato, questo incide poco (2 punti su una scala di 100 invece di 5) e DMARC supera comunque il controllo grazie a DKIM. Per allineare anche SPF, configura un sottodominio MAIL FROM personalizzato con esattamente un record MX, 10 feedback-smtp.<region>.amazonses.com, e un record TXT v=spf1 include:amazonses.com ~all. Non scegliere un sottodominio che riceve email e non inserire aspf=s nel record DMARC, perché AWS specifica che l'allineamento SPF con SES non funziona con una policy SPF rigorosa.

DMARC. SES non ne pubblica uno per te. L'esempio di AWS è v=DMARC1;p=quarantine;rua=mailto:my_dmarc_report@example.com. Se nessuno legge ancora i tuoi report DMARC, inizia con p=none e applica una policy più rigorosa in seguito. Il controllo DMARC mostra la tua configurazione, mentre DMARC fail descrive i problemi più comuni.

List-Unsubscribe. SES aggiunge List-Unsubscribe e List-Unsubscribe-Post solo quando invii usando ListManagementOptions che punta a un elenco di contatti e a un argomento. Anche in questo caso, lo fa solo per i messaggi con un unico destinatario e solo con Easy DKIM, inoltre SES sovrascrive qualsiasi header di annullamento dell'iscrizione impostato da te. Tutti gli altri messaggi vengono inviati senza alcun header di annullamento dell'iscrizione. Per una newsletter, questo comporta il mancato superamento del controllo List-Unsubscribe e del controllo con un clic, a meno che tu non aggiunga gli header manualmente. Da marzo 2024, l'API v2 accetta header personalizzati senza MIME non elaborato. Adattati dal post di AWS sull'annullamento dell'iscrizione con un clic, i due header hanno questo formato:

"Headers": [
  { "Name": "List-Unsubscribe",
    "Value": "<https://yourdomain.com/unsub?address=x&topic=x>, <mailto:unsubscribe@yourdomain.com>" },
  { "Name": "List-Unsubscribe-Post",
    "Value": "List-Unsubscribe=One-Click" }
]

Il tuo endpoint deve quindi gestire la richiesta POST. Le reimpostazioni della password e le ricevute prive di header per le liste rappresentano un caso diverso, per il quale il report contrassegna il gruppo relativo ai mittenti di massa come ignorato. Per maggiori informazioni sull'header, consulta la nostra pagina su List-Unsubscribe.

IP e liste di blocco

I nuovi account inviano da IP condivisi con altri utenti SES e AWS consiglia di continuare a usarli, a meno che il tuo volume non sia elevato e regolare. Il report interroga 21 liste di blocco per l'IP di invio e, negli indirizzi condivisi, un rilevamento riguarda l'intero pool. Gli IP dedicati sono disponibili come Standard, con riscaldamento manuale, oppure Managed, con riscaldamento gestito da SES. In questo caso, un inserimento in una lista è legato ai tuoi invii. Puoi inserire qualsiasi IP trovato nella scheda Headers direttamente nello strumento di controllo delle liste di blocco.

Anche AWS monitora il tuo account. Le sue domande frequenti sull'applicazione delle regole indicano di eseguire i test usando indirizzi reali in grado di ricevere email, oppure il simulatore, in modo che destinatari inventati non aumentino i bounce. AWS sottopone un account a verifica quando il tasso di bounce raggiunge il 5% o il tasso di reclami raggiunge lo 0,1%.

Il piano di correzione in fondo elenca fino a otto modifiche, ciascuna con il record DNS da copiare, se applicabile. I punti accanto a ogni correzione corrispondono alle penalità attuali dei controlli interessati. Il modello sceglie e spiega le correzioni, ma non ne determina il costo. Se non sai cosa significa il nome di un controllo, la documentazione spiega tutti e 42 i controlli.