Newsletter dal Suo dominio

Modulo 7: Newsletter e posta dal Suo sito web · Tempo di lettura: 11 minuti

Obiettivo della lezione: Dopo questa lezione saprà collegare un servizio di invio in modo che la Sua newsletter, inviata per conto del Suo dominio, superi i controlli SPF, DKIM e DMARC, e saprà verificare nelle intestazioni se ci è riuscito.

Concetti chiave: servizio di invio, dominio From, Return-Path (dominio di bounce), dominio DKIM (d=), allineamento (alignment), dominio di bounce proprio tramite CNAME, DKIM tramite CNAME, sottodominio per il marketing, limite di invio, warm-up (riscaldamento)

Perché una newsletter è diversa dalla posta normale

Un'email a un cliente o a un collega la invia dalla Sua casella di posta personale. Una newsletter va a centinaia o migliaia di persone contemporaneamente. Per destinatari come Gmail, Outlook.com e T-Online si tratta di un tipo di traffico diverso: bulkmail (posta in massa). Questi provider la controllano con maggiore rigore, perché quasi tutto lo spam è anch'esso bulkmail.

Tre fattori fanno la differenza tra una newsletter che arriva nella posta in arrivo e una che finisce nello spam:

1. Tecnica: l'email deve essere dimostrabilmente inviata dal Suo dominio. Questo lo gestiscono SPF, DKIM e DMARC, e soprattutto l'allineamento tra di essi.
2. Reputazione: i server e il dominio con cui invia devono avere una buona reputazione (lezione 5.2).
3. Comportamento dei Suoi destinatari: aprono la Sua email, oppure cliccano su "Questo è spam"? Dipende dalla Sua lista e dal consenso (lezione 7.2).

Questa lezione tratta il primo punto. Le basi dei record sono spiegate nel corso DNS, lezione 7.4. Qui vediamo come verificare in pratica che tutto sia corretto.

Perché non semplicemente tramite la Sua casella di posta?

Può essere allettante inviare una newsletter in CCN dal Suo programma di posta abituale, oppure usare una mailing list sul Suo pacchetto di hosting. Per una piccola associazione di trenta membri che si conoscono tra loro, una mailing list va benissimo. Per una vera newsletter no, per quattro motivi:

• Limiti di invio. Quasi ogni fornitore limita quante email una casella o un pacchetto può inviare al giorno, per contenere gli abusi. Su WebOké vede questo limite in DirectAdmin nelle statistiche utente; presso altri fornitori è indicato nelle condizioni o nel pannello cliente. Una newsletter a 2.000 persone supera ampiamente questo limite.
• Reputazione condivisa. Condivide il server di invio con altri clienti. Se i destinatari si lamentano della Sua newsletter, ne risente anche la loro posta, e viceversa.
• Nessun pulsante di disiscrizione e nessuna gestione dei bounce. Un servizio di invio inserisce automaticamente le intestazioni di disiscrizione in ogni email (lezione 7.2), rimuove dalla Sua lista gli indirizzi non più esistenti e gestisce i reclami. Questo, fatto a mano, non funziona mai bene.
• Privacy. Un clic sbagliato e invia a tutti l'indirizzo degli altri nel campo A.

Un servizio di invio (servizio di newsletter come Laposta, Brevo, MailerLite o Mailchimp, oppure un servizio transazionale per conferme e fatture) è progettato per questo compito. Ma in tal caso è un'altra entità a inviare per conto del Suo dominio, e questo va dimostrato.

Tre domini in un'unica email

Ogni email ha almeno tre punti in cui compare un dominio. Nella posta normale inviata dalla Sua casella, questi di solito coincidono. Con un servizio di invio non automaticamente.

DMARC (lezione 4.4) approva un'email se SPF o DKIM ha successo, e il dominio che ha avuto successo è allineato con il dominio From. Allineato, nell'impostazione predefinita (relaxed), significa che si tratta dello stesso dominio organizzativo: mail.example.com è allineato con example.com, ma sender.example no.

Senza impostazioni proprie, una newsletter appare così:

Return-Path: <bounce-8f3a@mail.sender.example>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=sender.example; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=mail.sender.example;
       dkim=pass header.d=sender.example;
       dmarc=fail header.from=example.com

SPF ha successo e DKIM ha successo, ma entrambi per il dominio del servizio. Nessuno dei due è allineato con example.com, quindi DMARC fallisce. Se la Sua policy DMARC è p=none, se ne accorge solo nei Suoi rapporti (lezione 4.5). Se è quarantine o reject, la Sua newsletter finisce nello spam o viene rifiutata.

La soluzione: autenticare il dominio presso il servizio

Ogni servizio di invio serio ha un passaggio chiamato "autenticare il dominio", "verificare il dominio" o "configurare il dominio mittente". Il servizio Le fornisce quindi alcuni record da inserire nel Suo DNS. Di solito sono:

1. DKIM tramite CNAME, ad esempio s1._domainkey.example.com verso un nome presso il servizio. Dopodiché il servizio firma la Sua posta con d=example.com. Questo è il record più importante: con esso DMARC ha successo tramite DKIM.
2. Un dominio di bounce proprio, spesso un CNAME su un sottodominio, ad esempio bounce.example.com verso il servizio. Il Return-Path diventa allora ...@bounce.example.com. L'SPF di quel sottodominio punta tramite il CNAME al servizio, e SPF risulta quindi allineato. Non tutti i servizi offrono questa opzione; il solo DKIM è sufficiente per DMARC.
3. A volte una inclusione SPF (include) nel Suo record, se il servizio usa il Suo dominio principale come Return-Path. Lo faccia solo se il servizio lo richiede, e sempre nel Suo record SPF esistente (lezione 4.2).
4. A volte un TXT di verifica per dimostrare che il dominio è Suo.

Dopo le impostazioni corrette, la stessa newsletter appare così:

Return-Path: <bounce-8f3a@bounce.example.com>
From: Nieuws <nieuws@example.com>
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1; ...
Authentication-Results: mx.example.net;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

Riprenda sempre nomi e destinazioni testualmente dal pannello del Suo servizio. Variano da servizio a servizio e talvolta da account ad account.

Un sottodominio separato per il marketing?

I grandi mittenti usano spesso un sottodominio proprio per le newsletter, come nieuws.example.com o info.example.com, con mittente nieuwsbrief@nieuws.example.com. L'idea: la reputazione della Sua posta di marketing resta così separata da quella della Sua posta ordinaria. Se una campagna va male, la Sua posta quotidiana con i clienti ne risente meno.

Per chi invia una newsletter qualche volta al mese, non è necessario. Complica però la gestione: il sottodominio ha bisogno di un DKIM proprio, e la Sua policy DMARC per i sottodomini (sp=) deve essere coerente. Lo consideri se invia molta posta o se, oltre alle newsletter, ha anche molta posta transazionale (ordini, password). Quella non vuole mai che risenta di una campagna fallita.

Importante: non imposti su un sottodominio di invio nessun record MX verso il servizio se non Le serve, e non modifichi mai l'MX del Suo dominio principale per una newsletter. L'MX determina dove arriva la posta; le risposte alla Sua newsletter devono finire normalmente nella Sua casella di posta.

Warm-up: non iniziare subito con tutto

Invia per la prima volta con un nuovo servizio o un nuovo dominio, oppure invia improvvisamente dieci volte tanto rispetto al solito? In tal caso i destinatari non La conoscono ancora. I grandi destinatari rallentano i mittenti sconosciuti (presso Microsoft vede allora rifiuti temporanei come 451 4.7.500, lezione 6.4). Inizi quindi in piccolo: prima i Suoi lettori più attivi, poi ogni volta una parte più ampia. Questo si chiama warm-up (riscaldamento). Con un servizio di invio condiviso, il servizio stesso si occupa in gran parte di questo, ma anche lì conta la reputazione del Suo dominio.

In pratica: come appare in un pannello

Inserisce i record del servizio nell'amministrazione DNS del Suo dominio. Su WebOké si tratta della scheda DNS in Mio WebOké oppure di Amministrazione DNS in DirectAdmin; presso altri fornitori si chiama gestione DNS, gestione zona o record DNS e funziona in modo simile. Attenzione ai due errori classici: il nome di dominio duplicato nel nome (s1._domainkey.example.com.example.com), e la creazione di un record TXT dove il servizio richiede un CNAME.

Fatto? Invii una newsletter di prova a un Suo indirizzo Gmail o Outlook.com e apra le intestazioni (lezione 1.5). Vuole vedere in Authentication-Results: dkim=pass con header.d= il Suo dominio, e dmarc=pass.

Riepilogo

• Una newsletter è bulkmail: i destinatari la controllano con maggiore rigore. Usi un servizio di invio, non la Sua casella di posta ordinaria.
• In ogni email compaiono tre domini: From (DMARC), Return-Path (SPF) e il dominio DKIM d=.
• DMARC ha successo solo se SPF o DKIM ha successo per un dominio allineato con il dominio From.
• Autentichi il Suo dominio presso il servizio: DKIM tramite CNAME è il più importante, un dominio di bounce proprio è un vantaggio in più.
• Verifichi con un'email di prova: dkim=pass header.d=<Suo dominio> e dmarc=pass. Con un nuovo servizio inizi in piccolo.

Quiz

Esercizio

Esercizio Z7.1: Verificare l'allineamento di una newsletter. Invii una newsletter dal Suo servizio di invio a Se stesso (oppure usi il file di esempio nieuwsbrief-kopregels-1.txt del corso) e incolli le intestazioni. Indichi: il dominio From, il dominio Return-Path, il dominio DKIM (d=) e se secondo Lei DMARC ha successo (sì/no) e tramite quale via (SPF, DKIM, entrambi o nessuno). Il programma analizza da solo le intestazioni, controlla dal vivo il selector DKIM nel DNS e il record DMARC del dominio From, e confronta il suo risultato con il Suo.

Per approfondire

I passaggi descritti in questi articoli valgono per i pannelli di WebOké; presso altri fornitori il funzionamento è simile.

• Corso gratuito DNS 7.4: Newsletter e servizi di invio
• Corso gratuito DNS 4.5: DMARC: cosa devono fare i destinatari con le email false
• Guida DirectAdmin 5.8: Attivare e verificare DKIM
• Guida DirectAdmin 7.10: Mailing List
• Limite per l'invio di email
• È possibile inviare un mailing tramite il Suo pacchetto di hosting presso WebOké?
• Google, Linee guida per i mittenti (Email sender guidelines): https://support.google.com/a/answer/81126