Argomenti in questo gruppo:
le impostazioni minime richieste
ottenere il pieno controllo nella reputazione delle vostre email
controllare cosa succede alle vostre email
automaticamente ogni dieci minuti viene verificato il corretto funzionamento dei servizi
Argomenti in questo gruppo:
Sender Policy Framework introduzione
controllo delle impostazioni SPF inviando un messaggio email
DomainKeys Identified Mail introduzione
controllo delle impostazioni DKIM inviando un messaggio email
SPF è l’abbreviazione di Sender Policy Framework, uno standard di autenticazione della posta elettronica,
che consente di dichiarare quali sono i server smtp autorizzati ad inviare email per il vostro dominio.
Permette di convalidare l’indirizzo del mittente e la sua relazione con il server che ha inviato il messaggio.
Per le email inviate con il vostro dominio nel mittente, il destinatario può identificare se sono state inviate da un server smtp da voi riconosciuto.
Si consiglia di configurarlo, perché alcuni destinatari potrebbero rifiutare i messaggi se l’spf non è stato impostato del tutto.
Ci sono due diversi approcci:
La configurazione “soft” produrrà meno/nessun rifiuto da parte dei destinatari.
Quella “hard” causerà il rifiuto di alcuni messaggi se il server non è stato dichiarato oppure in alcuni casi quando l’email è stata reindirizzata o inviata attraverso una mailing list.
L’impostazione “hard” è quella che fornisce al server di posta di destinazione più facoltà di decidere se accettare o meno il messaggio, questo è l’approccio che suggeriamo.
L’impostazione dell’spf richiede di conoscere esattamente quali server vengono utilizzati per l’invio dei messaggi di posta elettronica.
Con RealSender, il record TXT del vostro dominio (example.com) dovrebbe contenere la stringa
a:example.realsender.com ed assomigliare a questo:
example.com TXT "v=spf1 a:example.realsender.com ~all"Con HighSender, il record TXT del vostro dominio (example.com) dovrebbe contenere la stringa
include:spf.realsender.com ed assomigliare a questo:
example.com TXT "v=spf1 include:spf.realsender.com ~all"Questi strumenti vi aiuteranno a convalidare la configurazione:
www.kitterman.com/spf/validate.html *
recupera il record SPF per il nome di dominio specificato e determina se è valido
spf tester online
controllo delle impostazioni SPF inviando un messaggio email
* = link ad un sito web esterno, si aprirà in una nuova pagina
Anche se tutto è impostato correttamente, la verifica del messaggio potrebbe non risultare corretta
se l’email è stata reindirizzata (inoltrata) o inviata tramite una mailing list.
In questi casi, per mantenere consistente l’autenticazione delle email,
configurare il dominio della firma dkim in modo che sia allineato con l’indirizzo From del mittente.
Vedi: autenticazione e-mail avanzata » <dkim> allineamento per dmarc.
spf@tester.realsender.comhttps://tester.realsender.com/spfRealSender SPF tester online aggiungerà un prefisso all’oggetto, se il messaggio non è stato autenticato correttamente:
!! spf-fail !! il server smtp non è elencato tra quelli autorizzati
e la mail deve essere rifiutata o scartata
!! spf-softfail !! il server smtp non è elencato tra quelli autorizzati
ma ciò va considerato come un "softfail"
!! spf-neutral !! il record SPF indica esplicitamente che nulla può essere detto sulla validità
!! spf-none !! il dominio del mittente non contiene informazioni per autenticare la mailA volte le informazioni registrate a livello di dominio non risultano corrette/comprensibili.
!! spf-permerror !! si è verificato un errore permanente (ad esempio record SPF formattato in modo errato)
!! spf-temperror !! si è verificato un errore temporaneoIl controllo SPF viene effettuato sull’indirizzo “Mail-From”, che è nascosto nelle intestazioni dell’email.
È visibile solo l’indirizzo “From” del mittente. Se i loro domini di base sono diversi, viene visualizzato questo avviso:
!! spf-diff !! i domini di base negli indirizzi "Mail-From" e "From" sono diversiSe il messaggio supera sia il controllo SPF ED il controllo dell’allineamento SPF per DMARC (allineamento “relaxed”), risulterà:
|OK| spf-pass l'email passa il controllo SPF + il controllo dell'allineamento SPFSe solo uno, SPF OPPURE DKIM, supera il controllo di allineamento per DMARC (allineamento “relaxed”),
il messaggio è ancora considerato “OK” (attendibile) ed il simbolo ~ (tilde) viene aggiunto all’inizio:
|~OK| spf-pass l'email passa il controllo SPF (non l'allineamento)
+ il controllo dell'allineamento DKIM
DKIM è l’acronimo di DomainKeys Identified Mail, uno standard per l’autenticazione delle email,
progettato per garantire che i messaggi email (compresi gli allegati) non vengano modificati dopo che sono stati “firmati”.
Ciò si ottiene apponendo una firma digitale, collegata ad un nome di dominio, a ciascun messaggio email in uscita.
Vengono utilizzate due chiavi: una “pubblica” ed una “privata”:
Durante l’invio di un messaggio, il server smtp genera una “firma in codice”, basata sul contenuto del messaggio email e sulla chiave privata.
Il sistema destinatario può verificare la firma presente nell’intestazione, confrontandola con il contenuto della mail e con la chiave “pubblica” del mittente.
Le firme DKIM non sono immediatamente visibili agli utenti finali, vengono aggiunte e verificate dall’infrastruttura di posta elettronica.
I server smtp di RealSender firmano tutti i messaggi email in uscita con la firma dkim.
RealSender da subito firma tutti i messaggi in uscita con il proprio dominio collegato al server smtp,
non è necessaria alcuna configurazione lato utente/amministratore.
Per ottenere “l’allineamento del dominio dkim per dmarc”,
il messaggio deve essere firmato con lo stesso dominio del mittente.
Con RealSender, dovreste aggiungere due record CNAME
nelle impostazioni dns del vostro dominio (example.com), come questi:
key1._domainkey.example.com CNAME key1._domainkey.nomeazienda.realsender.com
key2._domainkey.example.com CNAME key2._domainkey.nomeazienda.realsender.comQuesto strumento vi aiuterà a convalidare la configurazione:
toolbox.googleapps.com *
* = link ad un sito web esterno, si aprirà in una nuova pagina
Un messaggio sigillato con dkim non può essere modificato, ma può essere sempre letto da chiunque.
Un messaggio firmato che non supera la verifica, di solito viene respinto.
Se non sono state apportate modifiche lungo il percorso dal mittente al destinatario, ciò non dovrebbe accadere.
Abbiamo riscontrato rari casi, tutti correlati alla lunghezza delle linee (deve essere massimo 990 caratteri).
Alcune applicazioni inviano il contenuto tutto in una riga o trasmettono una riga molto lunga all’interno dell’html.
In queste occasioni la firma dkim risulta corrotta, causando l’esito della verifica “dkim = fail”.
dkim@tester.realsender.comhttps://tester.realsender.com/dkimRealSender DKIM tester online aggiungerà un prefisso all’oggetto, se il messaggio non è stato firmato correttamente:
!! dkim-none !! non sono state trovate intestazioni DKIM-Signature (valide o non valide)
!! dkim-fail !! è stata trovata un'intestazione DKIM-Signature valida, ma la firma
non contiene un valore corretto per il messaggioA volte non è possibile eseguire il controllo:
!! dkim-invalid !! c'è un problema nella firma stessa o nel record della chiave pubblica.
La firma non può essere verificata
!! dkim-temperror !! è stato rilevato un errore che è probabilmente di natura transitoria,
come l'incapacità temporanea di recuperare la chiave pubblicaQuando il messaggio è stato firmato utilizzando un dominio diverso, verrà aggiunto un avviso “diff” all’oggetto.
Questo avviso NON verrà visualizzato se il mittente supera il controllo SPF e l’allineamento SPF per dmarc:
!! dkim-diff !! il messaggio NON è stato firmato dal dominio del mittenteSe il messaggio supera sia il controllo DKIM ED il controllo dell’allineamento DKIM per DMARC (allineamento “relaxed”), risulterà:
|OK| dkim-pass l'email passa il controllo DKIM + il controllo dell'allineamento DKIMSe solo uno, DKIM OPPURE SPF, supera il controllo di allineamento per DMARC (allineamento “relaxed”),
il messaggio è ancora considerato “OK” (attendibile) ed il simbolo ~ (tilde) viene aggiunto all’inizio:
|~OK| dkim-pass l'email passa il controllo DKIM (non l'allineamento)
+ il controllo dell'allineamento SPFArgomenti in questo gruppo:
I domini SPF non allineati possono causare il fallimento del test DMARC
I domini DKIM non allineati possono causare il fallimento del test DMARC
Domain-based Message Authentication, Reporting and Conformance
ricezione dei messaggi rua e generazione di report giornalieri dmarc online
DMARC è uno standard di autenticazione delle email, sviluppato per combattere la posta elettronica falsificata.
Per l’allineamento del dominio richiede che:
quando un mittente autentica la propria email utilizzando SPF e/o DKIM,
almeno uno dei domini deve essere allineato con il dominio From del mittenteCon SPF (Sender Policy Framework), per ottenere l’allineamento si controllano due domini:
DMARC prevede due tipi di allineamento SPF: allineamento “relaxed” e allineamento “strict” (rigoroso).
Se non viene dichiarato un allineamento “strict”, per default viene utilizzato l’allineamento “relaxed”.
Con l’allineamento “relaxed”, solo il dominio di base (root) dell’indirizzo Mail-From deve corrispondere al dominio di base (root) dell’indirizzo From del mittente.
L’allineamento “relaxed” consente di utilizzare qualsiasi sottodominio e di soddisfare comunque i requisiti di allineamento del dominio.
esempio:
se il dominio Mail-From è mail.abc.it ed il dominio From è abc.it,
l’email passerà il test per l’allineamento SPF (i domini di base “abc.it” corrispondono)
se il dominio Mail-From è abc.mail.it ed il dominio From è abc.it,
l’email NON passerà il test per l’allineamento SPF (i domini di base “mail.it” e “abc.it” non corrispondono)
Con l’allineamento “strict”, il dominio dell’indirizzo Mail-From deve corrispondere esattamente al dominio dell’indirizzo From.
esempio:
se il dominio Mail-From è mail.abc.it ed il dominio From è mail.abc.it,
l’email passerà il test per l’allineamento SPF (i domini “mail.abc.it” corrispondono)
se il dominio Mail-From è mail.abc.it ed il dominio From è abc.it,
l’email NON passerà il test per l’allineamento SPF (i domini “mail.abc.it” e “abc.it” non corrispondono)
DMARC è uno standard di autenticazione delle email, sviluppato per combattere la posta elettronica falsificata.
Per l’allineamento del dominio richiede che:
quando un mittente autentica la propria email utilizzando SPF e/o DKIM,
almeno uno dei domini deve essere allineato con il dominio From del mittenteCon DKIM (DomainKeys Identified Mail), per ottenere l’allineamento
il dominio della firma dkim (DKIM-Signature: d = …) deve corrispondere al dominio From del mittente.
DMARC prevede due tipi di allineamento DKIM: allineamento “relaxed” e allineamento “strict” (rigoroso).
Se non viene dichiarato un allineamento “strict”, per default viene utilizzato l’allineamento “relaxed”.
Con l’allineamento “relaxed”, solo la base (root) del dominio nella firma dkim deve corrispondere al dominio di base (root) dell’indirizzo From del mittente.
L’allineamento “relaxed” consente di utilizzare qualsiasi sottodominio e di soddisfare comunque i requisiti di allineamento del dominio.
esempio:
se il dominio della firma dkim è mail.abc.it ed il dominio From è abc.it,
l’email passerà il test per l’allineamento DKIM (i domini di base “abc.it” corrispondono)
se il dominio della firma dkim è abc.mail.it ed il dominio From è abc.it,
l’email NON passerà il test per l’allineamento SPF (i domini di base “mail.it” e “abc.it” non corrispondono)
Con l’allineamento “strict”, il dominio della firma dkim deve corrispondere esattamente al dominio dell’indirizzo From.
esempio:
se il dominio della firma dkim è mail.abc.it ed il dominio From è mail.abc.it,
l’email passerà il test per l’allineamento DKIM (i domini “mail.abc.it” corrispondono)
se il dominio della firma dkim è mail.abc.it ed il dominio From è abc.it,
l’email NON passerà il test per l’allineamento DKIM (i domini “mail.abc.it” e “abc.it” non corrispondono)
DMARC significa: autenticazione, reportistica e conformità dei messaggi basata sul dominio.
È uno standard di autenticazione delle email, sviluppato per combattere la posta elettronica falsificata.
Mittenti:
Destinatari:
Con alcuni provider di caselle email, la sua impostazione influenza la consegna dei messaggi in modo significativo, vedi:
Come funziona dmarc con Google Mail ed Office 365 nel 2020 *
“Office 365: è generalmente reattivo a spf e dkim.
L’unico modo per ottenere risultati costanti, con la consegna nella posta in arrivo, è utilizzare anche dmarc”
* = collegamento a un sito web esterno, verrà aperto in una nuova pagina
DMARC utilizza SPF (Sender Policy Framework) e DKIM (Domain Keys Identified Emails)
per controllare la situazione quando i messaggi di posta elettronica non superano i test di autenticazione.
SPF richiede che vengano dichiarati quali server smtp si utilizzano per inviare messaggi email.
Vedi come si configura spf per saperne di più ed impostarlo correttamente.
I server smtp di RealSender firmano già tutti i messaggi di posta elettronica in uscita con la firma DKIM.
È necessaria una configurazione se si desidera firmare con lo stesso dominio del mittente.
Vedi come si configura dkim per saperne di più.
RealSender fornisce una casella di posta che riceve i report dmarc generati dai destinatari.
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc.example@rsbox.com"A partire dal giorno successivo, inizierete a ricevere i dmarc report rua online.
Potreste scoprire di aver dimenticato di autenticare una campagna email che viene distribuita da una terza parte. Se succede qualcosa del genere, è sufficiente autenticarla e verificare che il mailing successivo superi i controlli di dmarc.
Quando i report sono corretti per alcune settimane, si può dire ai provider di caselle email di rifiutare/bloccare le email contraffatte/fasulle.
Il record TXT _dmarc del vostro dominio va modificato come segue:
"v=DMARC1; p=reject; rua=mailto:dmarc.example@rsbox.com"Se la vostra organizzazione implementa dmarc, dovrete fare attenzione
prima di introdurre qualsiasi nuova modalità di invio delle email.
Dmarc applica politiche rigide su come vengono verificati spf e dkim.
Questo può causare che delle email che normalmente verrebbero accettate,
siano rifiutate dai provider di caselle email.
Anche se tutto è impostato correttamente, la verifica potrebbe fallire:
RealSender riceve ed analizza i report di dmarc rua(*) per voi.
* = significato di rua:
Reporting URI(s) for aggregate data. In RealSender, il “rua” è l’indirizzo email fornito ai clienti,
a cui vengono inviati i report aggregati
dai domini che hanno ricevuto posta elettronica che dichiara di appartenere al vostro dominio.
I report vengono generati ogni giorno alle 13:00 e contengono i dati degli ultimi sette giorni.
Questa è una pagina di esempio del report dmarc online:
Argomenti in questo gruppo:
rapporti dettagliati per mese, giorni, ore, host, email del mittente
log delle email, notifiche dello stato di consegna, notifiche di avvenuta consegna
controllo dei messaggi email inviati per capire cosa sta succedendo
RealSender offre rapporti dettagliati per ogni server smtp / attività di invio messaggi email.
I dati vengono aggiornati automaticamente ogni cinque minuti.
A richiesta possiamo inviare un riepilogo settimanale via email.
Nota: questi errori sono generati da tentativi non autorizzati di inviare messaggi email attraverso il server
RealSender consente di accedere via browser allo stato di consegna dei messaggi email:
I dati visualizzati possono essere salvati in locale direttamente dal browser, o registrati automaticamente ad intervalli regolari (ad esempio una volta al giorno), per conservare lo storico.
May 31 06:26:22 rs336 v4V4QL1K030027: from=mittente@nomedidominio.it May 31 06:26:25 rs336 v4V4QL1K030027: to=destinatario@nomedelcliente.com, dsn=2.0.0, stat=Sent (Message accepted for delivery)
May 31 08:58:04 rs336 v4V6w3jN001390: from=mittente@nomedidominio.it
May 31 08:58:05 rs336 v4V6w3jN001390: to=destinatario@nomedelcliente.com, dsn=4.0.0, stat=Deferred: 421 destinatario@nomedelcliente.com Service not available - too busy
May 31 09:02:03 rs336 v4V6w3jN001390: to=destinatario@nomedelcliente.com, dsn=4.0.0, stat=Deferred: 421 destinatario@nomedelcliente.com Service not available - too busy
May 31 09:12:42 rs336 v4V6w3jN001390: to=destinatario@nomedelcliente.com, dsn=2.0.0, stat=Sent (Message accepted for delivery)
May 31 10:00:22 rs336 v4V80L9Z004176: from=mittente@nomedidominio.it
May 31 10:00:24 rs336 v4V80L9Z004176: to=destinatario@nomedelcliente.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 destinatario@nomedelcliente.com: Recipient address rejected: Greylisting in effect, please come back later
May 31 10:02:03 rs336 v4V80L9Z004176: to=destinatario@nomedelcliente.com, dsn=4.7.1, stat=Deferred: 451 4.7.1 destinatario@nomedelcliente.com: Recipient address rejected: Greylisting in effect, please come back later
May 31 10:12:04 rs336 v4V80L9Z004176: to=destinatario@nomedelcliente.com, dsn=2.0.0, stat=Sent (Message accepted for delivery)
May 31 16:17:14 rs336 v4VEHCk6017038: from=mittente@nomedidominio.it
May 31 16:17:15 rs336 v4VEHCk6017038: to=destinatario@nomedelcliente.com, dsn=5.1.1, stat=User unknown
May 31 16:17:15 rs336 v4VEHCk6017038: v4VEHFk5017041: DSN: User unknown
May 25 12:43:37 rs336 v4PAhZw1019212: from=mittente@nomedidominio.it
May 25 12:43:38 rs336 v4PAhZw1019212: to=destinatario@nomedelcliente.com, dsn=5.0.0, stat=Service unavailable
May 25 12:43:38 rs336 v4PAhZw1019212: v4PAhcw0019217: DSN: Service unavailable
May 25 09:17:41 rs336 v4P7Hc6P011481: from=mittente@nomedidominio.it
May 25 09:17:42 rs336 v4P7Hc6P011481: to=destinatario@nomedelcliente.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 destinatario@nomedelcliente.com 4.2.2 mailbox full
[…] il sistema riprova la consegna ogni dieci minuti […]*
May 25 13:25:47 rs336 v4P7Hc6P011481: to=destinatario@nomedelcliente.com, dsn=4.1.1, stat=Deferred: 452 4.1.1 destinatario@nomedelcliente.com 4.2.2 mailbox full
May 25 13:25:48 rs336 v4P7Hc6P011481: v4PBPko0020848: sender notify: Cannot send message for 4 hours*
* = vedi nota al termine del paragrafo successivo
I bounce (mail respinte) tornano all’indirizzo email del mittente o all’indirizzo di return-path (se specificato).
In caso di ritardo nella consegna dei messaggi (delay), riceverete un avviso dopo 30 minuti*, come questo:
Oggetto:
Warning: could not send message for past 30 minutes
Corpo:
**********************************************
** THIS IS A WARNING MESSAGE ONLY **
** YOU DO NOT NEED TO RESEND YOUR MESSAGE **
**********************************************
[...] Il sistema riproverà in automatico per quattro ore*. Se non riceverete ulteriori notifiche, significa che il messaggio è stato consegnato correttamente. È possibile controllare i dettagli all’interno del log (vedi gli esempi sopra riportati).
Dopo aver tentato la consegna senza successo per quattro ore*, tornerà un errore definitivo al mittente o all’indirizzo di return path (se specificato), come segue:
Oggetto:
Returned mail: see transcript for details
Corpo:
The original message was received at ...
----- The following addresses had permanent fatal errors -----
<destinatario@nomedelcliente.com>
----- Transcript of session follows -----
Deferred: Connection timed out with yourcustomer.com.
Message could not be delivered for 4 hours
Message will be deleted from queue
[...] * = quando si fanno invii massivi:
vengono disabilitate le notifiche di ritardo nella consegna,
aumentato l’intervallo tra i tentativi di recapito (da dieci a trenta minuti),
allungato il tempo massimo di permanenza in coda dei messaggi (da quattro a ventiquattro ore)
A richiesta, possiamo attivare la “notifica di consegna” anche per le mail andate a buon fine. Per ogni messaggio inviato, tornerà al mittente dal server di destinazione la ricevuta di consegna, come quella d’esempio riportata di seguito. Questa opzione è utile per chi necessita delle ricevute di consegna per ogni mail inviata.
Oggetto:
Return receipt
Corpo:
The original message was received at ...
----- The following addresses had successful delivery notifications -----
<destinatario@nomedelcliente.com> (successfully delivered to mailbox)
----- Transcript of session follows -----
<destinatario@nomedelcliente.com>... Successfully delivered
[...]In rari casi (meno dell'1% delle mail inviate), la ricevuta non viene rilasciata al mittente. Ciò accade se il destinatario ha attivato una speciale opzione “privacy / noreceipts” nel suo server di posta. Questa impostazione è generalmente sconsigliata, in quanto blocca anche l’invio delle notifiche di mancata consegna standard.
A volte, per capire cosa sta succedendo, è necessario esaminare i messaggi email inviati.
A richiesta, RealSender può attivare la copia automatica di tutte le email in uscita in una mailbox dedicata.
La casella è configurata in modo che possa ricevere grandi quantità di email in breve tempo senza alcun problema.
I messaggi di posta elettronica vengono eliminati automaticamente dopo 7 giorni.
Attenzione: nel caso i messaggi vengano spediti da account di posta personali (anche se si tratta di caselle aziendali),
occorre informare il mittente che le comunicazioni che invia possono essere lette per effettuare verifiche tecniche.
Per monitorare il corretto funzionamento del servizio,
abbiamo attivato un ambiente di controllo automatico.
Un’applicazione esterna si connette a ciascun server smtp ogni dieci minuti
ed invia un messaggio reale. L’avvenuto invio dell’email ci consente di garantire
la disponibilità ed il corretto funzionamento del sistema.
Il risultato viene pubblicato sulla “pagina di stato” del vostro server RealSender,
liberamente accessibile all’indirizzo web: rsXXX-realsender.com/status
I dati sono visualizzati in tempo reale, come quelli d’esempio qui sotto indicati.
Le informazioni riportate sono relative alle ultime ventiquattro ore.
2024-09-11 06:25:26 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 06:16:18 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 06:05:56 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:55:41 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:45:57 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:35:58 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:25:27 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:16:30 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 05:05:57 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK
2024-09-11 04:55:36 UTC
rsXXX- every ten minutes UPTIME CHECK (an email has been successfully sent) - OK