Io farei queste modifiche:

1. usare un solo IP per l'invio (le email sono troppo poche per "disperderle" e distribuirle sembra un metodo da spammer, come ti ha già segnalato Nazzareno). Se proprio vuoi usare 4 IP assicurati che abbiano ciascuno un hostname diverso e che combaci (ora usi un hostname condiviso, che non è il massimo). Il nome a dominio che avete scelto (invio-campagne-dem.com) non è il massimo per dei mailserver.. se fossi un gestore di server lo considererei un nome "negativo" a prescindere e mi trovassi a scegliere di blacklistare su segnalazioni di abuso lo farei con più leggerezza rispetto a blacklistare un newsletter.camiciauomo.it). E' vero che il grosso dei filtri sono automatici, ma non dimentarti che c'è spesso una componente umana/sociale.
2. Assicurati che il dominio dell'indirizzo email mittente sia configurato bene, ad esempio che esistano i suoi record MX e che verifica la presenza in blacklist di questo dominio e di eventuali domini che utilizzi all'interno del messaggio. Gli indirizzi presenti nel From e Reply-To, funzionano?? Prova a mandare tramite gli stessi server una email "semplice" senza mai usare quei domini nelle intestazioni e nel corpo del messaggio per escludere che il problema sia il contenuto del messaggio e concentrarsi così sui server. Altra prova è inviare la stessa identica email tramite un server completamente diverso.
3. Toglierei l'allegato e le immagini embedded a favore di url "hostati": io credo che sia uno dei motivi principali che ti fanno finire in spam: puoi pensare quello che vuoi del tuo target, ma accetterò la tua posizione dopo che avrai fatto un AB Test con e senza allegato sulla stessa email e avrai controllato il diverso tasso di delivery e soprattutto il tasso di clic in base alle email inviate (e non rispetto alle ricevute come si fa di solito).

Le email di optin escono dagli stessi server? Se escono da altri server allora ti conviene farle uscire dagli stessi: sulle email di optin puoi sperare che il destinatario cerchi la mail nello spam e la tolga, aumentando così la tua reputazione, mentre sulle altre email è molto più difficile che avvenga. A volte bastano pochi segnali positivi per aumentare la reputazione, se non ce ne sono dei negativi.

Da quanto tempo inviate da questi server? Il problema che segnali l'avete sempre avuto o è sorto recentemente?

Il problema è sorto dopo che abbiamo realizzato e cambiato con questo sistema! Prima non andavano a finire cosi tante in spamming...
Quindi credo che il problema non sia delle immagini (ma comunque oggi faro un A/B test).
I record MX sono configurati correttamente e non siamo in blacklist, per gli ip che usiamo abbiamo anche uno Score di 97 su verificando su return-path!

Credo che dovremmo prendere in considerazione di usare un solo IP (e caso mai se sorgono problemi nel tempo cambiarlo se finisce in qualche blacklist o problema).
Idem per il nome del dominio scelto, vediamo cosa si può fare!
Ho anche paura che il problema del Received: from unknown (HELO DOMINIO INVIO) (192.168.210.254) potrebbe dare molto fastidio....

Che urto colossale!!! accetto altri consigli

Il cambio di IP lo escluderei: è proprio una di quelle cose che ti fa classificare come spammer puro. Se hai un IP e finisce in blacklist devi capire il motivo e risolverlo.

Quanto tempo è che siete passati ai nuovi server? Quanto spesso inviate?

Mi sembra di capire che oltre a cambiare i server avete anche cambiato sistema di invio (ora usate Interspire, prima?): hai verificato che differenze ci sono nel modo in cui sono fatti i nuovi messaggi rispetto a quelli vecchi?

Non credo che quel received possa essere problematico, mi risulta che solo Gmail dia abbastanza importanza agli header Received, ma basta fare delle prove per escluderlo. Se avete deciso di gestirvi dei server SMTP in casa immagino abbiate un po' di competenze sistemistiche.

Prova ad alterare direttamente il messaggio MIME e fare modifiche al MAIL FORM e vedere se queste modifiche influiscono sul posizionamento. Ci sono dei tool che ti aiutano ma questa sequenza, partendo dal server SMTP stesso è abbastanza semplice:

telnet IPDELSERVERSULQUALEINDAGHI 25
< 220 messaggio di benvenuto
EHLO hostnamedellipdalqualeescequestaconnessione
< 250 estensioni supportate
MAIL FROM:<indirizzoemailmittente>
< 250 Sender OK
RCPT TO:<indirizzoemaildestinatario>
< 250 Recipient OK
DATA
< 354 Ok
Qui incolli il tuo messaggio MIME e lo termini con una riga vuota e una riga con solo un "."
< 250 Message received
QUIT
< 221 bye bye

In questo modo usi solamente l'IP e decidi in tutto e per tutto quali sono i parametri SMTP, non dipendendo quindi da cosa fa interspire. Puoi così inviare usando il contenuto MIME che preferisci, con gli header che preferisci.

Considera che dovrai trattare ciascun dominio come caso a se stante: tiscali, libero, gmail, fastweb utilizzano ciascuno metodi molto differenti tra loro.
Ritengo molto strano che prima del passaggio tutti questi server ti prendessero email in inbox e dopo il passaggio (se l'unica differenza è l'IP e non è in blacklist) ti mettano tutti in SPAM. Per carità, la qualità degli IP è molto importante, ma non è l'unica variabile e non tutti i server che citi danno così tanta importanza all'IP.. quindi deve esserci un problema più grave a monte.
Prima, quando funzionava, come inviavi?
Che differenze ci sono oltre all'IP in uscita, nei messaggi che invii?
Il problema di email in spam lo noti allo stesso modo sia sulle transazionali che sulle DEM?

Per intenderci quando dico "IPDELSERVERSULQUALEINDAGHI" intendo un MX server del dominio di destinazione. Ad esempio per gmail l'MX prioritario è "gmail-smtp-in.l.google.com" e quindi userai questo nome al posto di "IPDELSERVERSULQUALEINDAGHI".

Ti mando via messaggio privato un header completo (se lo permette, qui mi vietava di mettere indirizzi e www).

Sorry non avevo visto che erano due messaggi da parte tua.
Per l'Ip ok mi fermo
Per il sistema di invio, anche prima era Interspire, sono solo cambiati i server di uscita della posta! E non è cambiato il modo di fare la DEM (sia per codice e embed) anche prima c'era Interspire.
Solo server di invio cambiato e quindi header e cose varie! Addirittura prima non c'erano i DKIM e SPF ora si! (che passano correttamente)

A breve ti mando l'header

Da quanto tempo usate il nuovo sistema? GLi IP necessitano di un warmup, se avete fatto solo qualche invio per 1-2 settimane non mi preoccuperei e mi aspetterei una soluzione automatica nel giro di altre 1-2 settimane al massimo.

Su DKIM e SPF non sono automaticamente una cosa positiva. Intanto devono essere configurati correttamente, e poi aiutano solo ad identificare meglio chi sei e quindi a gestire anche una reputazione in maniera più corretta: per intenderci se fai SPAM avere DKIM e SPF serve solo ad aiutare i destinatari a classificarti come spammer.

Primo sull'SPF di invio-campagne-dem com hai un include dell'SPF camicieuomo it che riporta un record errato (non finisce con un -all/~all)
Secondo, sul record DKIM che pubblichi c'è "t=y" che significa che la firma DKIM deve essere ignorata.

Al momento quindi i server riceventi dovrebbero ignorare sia il tuo SPF che il tuo DKIM e dovrebbe essere tutto equivalente a non averli: questo almeno secondo le specifiche. C'è però qualche server che considera negativamente questi fattori (più che altro per ignoranza dei postmaster che non sanno che queste casistiche devono essere trattate come "neutrali" e non come negative).

Il sistema sta su da 2 settimana ormai e mandiamo 5 giorni su 7 :-)!
Ieri abbiamo messo il -all sul SPF magari ancora non si è propagato!
Ora elimino dal dns il t=y perchè se come dici te allora lo leggevano lo passavano ma lo ignoravano poi!
Per ora i record aggiornati sono questi:
"v=spf1 a ip4:95.211.176.189 ip4:95.211.176.190 ip4:95.211.176.191 ip4:95.211.176.192 ip4:95.211.176.193 include:camicieuomo.it -all"
"v=DKIM1; k=rsa; p=QUI C'E' LA CHIAVE DKIM"

Ma la specifica dell'RFC dice di metterlo il t=y però o sbaglio?
Ps hai nell'indirizzo e-mail che mi hai dato gli header chiesti.

L'SPF al quale mi riferivo io è quello "incluso":

host -t txt camicieuomo.it ns1.leaseweb.nl

camicieuomo.it descriptive text "v=spf1 ip4:95.211.176.189 ip4:95.211.176.190 ip4:95.211.176.191 ip4:95.211.176.192 ip4:95.211.176.193"
(non è una questione di propagazione perchè sto interrogando il nameserver autoritativo)

Come vedi non ha il "meccanismo" di default (-all ad esempio) alla fine. Non è obbligatorio, ma se non ce l'hai riporti sempre "Neutral".

Ora è passato parecchio tempo da quando ho implementato le specifiche SPF ma se ricordo bene se il record riferito ad un "include" ritorna neutral allora viene considerato permerror e quindi la regola originale del dominio "includente" fallisce.
Da http://www.openspf.org/SPF_Record_Syntax

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. Warning: If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError..

Quindi

1. metti un ~all in fondo a quella regola
2. inutile che il primo dominio faccia "include:camicieuomo.it" visto che poi ripete gli stessi IP di camicieuomo.it. Quindi o lasci solo gli IP e togli l'include o lasci solo l'include e togli l'elenco di IP.

@eliofilo said:

Ma la specifica dell'RFC dice di metterlo il t=y però o sbaglio?

Dice di metterlo se vuoi testarlo senza usarlo.

http://www.ietf.org/rfc/rfc4871.txt

t= y This domain is testing DKIM. Verifiers MUST NOT treat messages from signers in testing mode differently from unsigned email, even should the signature fail to verify. Verifiers MAY wish to track testing mode results to assist the signer.

OK corretto, però credo ti conveniva fare # host -t txt invio-campagne-dem.com ns1.leaseweb.nl che è il dominio del FROM, ecc...

Comunque prima di procedere con le analisi aspetta si sia propagato il DNS. Adesso c'è in giro la configurazione che ho trovato io, e quella fa fallire l'SPF.

Inoltre nel return-path hai un no-reply, cosa sbagliatissima. Come fai a ricevere i bounce e mantenere pulita la lista?

In verità quell'indirizzo newsletter-no-reply funziona ed è reale!

Allora chiamalo diversamente! alcun filtri antispam cercano proprio la sequenza no-reply/noreply e la penalizzano. Con tutti i nomi che potevi dargli proprio uno penalizzante?
Tra l'altro il return-path non viene fatto vedere praticamente da nessun client, quindi non puoi nemmeno aver avuto motivazioni "estetiche", che comunque sarebbero state discutibili perchè è sempre meglio incentivare il "reply" e non disincentivarlo.. oggi giorno ancora di più considerando che molti provider basano la reputazione sull'engagement e il fatto che ci sia un dialogo (botta/risposta) è considerato molto positivo...

Ok ora tutte le cose principali dovrebbero esser chiare:

• DKIM e SPF sistemati e si staranno propagando.
• l'indirizzo di from e return-path corretti
• ho fatto anche una prova eliminando allegati e immagini in embed ma non è cambiato nulla.

L'unica prova da fare è capire se c'è qualcosa che non va nell'header, soprattutto per l'Unknown sull'HELO. E se mettendo un solo ip di uscita (uno tra quelli che già utilizzo) migliora le cose.

PEr gli header che ho inviato c'è qualche dubbio o consiglio?

grazie

Aspettiamo qualche giorno, prima di approfondire. Potrebbe essere sufficiente quello che hai fatto.
Altrimenti, prima di lavorare sugli header bisognerebbe provare a fare le connessioni SMTP "manuali" come ti spiegavo prima, così puoi provare a togliere header e modificare il messaggio in vari modi e vedere se qualche operazione risolve il problema o meno. A memoria non ricordo di aver visto problemi con un header "unknown", e in ogni caso l'unico server che ricordo che fa sicuramente dei check sui received è google. Poi è vero che queste cose cambiano molto frequentemente e quindi, aspettiamo qualche giorno e poi al limite proseguiamo con le ipotesi.

Aggiorno la situazione a oggi,
DKIM, SPF eccc sono configurati e passati bene. Il problema è Cloiudmark e Brightmail... i loro servizi metto i miei ip in blacklist (quindi libero, tiscali, aruba e chi usa quel servizio ne risentono)
Ho contattato nuovamente contattato Cloudmark (sarà al 5 volta che mi levano e mettono dalla lista) dicendomi che resettano e che non sarà in blacklist. Ora sembra che cloudmark non mi ha reinserito...Ho anche inviato i falsi positivi!
Per Brightmail ho inviato i falsi positivi alle mail che loro segnalano sul sito ([email protected]). Ma on ho avuto nessuna risposta.

Altra domanda libero da questo messaggio nell'header, ti che tipo di servizio anti spam si tratta?:
X-Junkmail: UCE(300)
X-Junkmail-Status: score=300/55, host=hostlibero
X-Junkmail-Signature-Raw: score=confirmed,
refid=str=0001.0A0C0208.50C74336.016A,ss=4,re=0.000,fgs=12,
ip=95.211.176.193,
so=2011-06-21 16:49:39,
dmn=2011-06-08 23:29:05,
mode=multiengine
X-Junkmail-IWF: false
X-libjamoibt: 2587
X-cp3a: Confirmed Spam

Consigli o metodi più efficaci per aggirare questi problemi?

A me alcuni sembrano gli header di Memova di CriticalPath (fornitori di Libero, Tiscali, Alice..), altri del Razorgate di Mirapoint

Comunque il prossimo step è provare a inviare la stessa email con altri IP ed email diverse con gli stessi IP per capire se c'è un problema di IP o di contenuti.

Quando parli di rimozione su cloudmark parli di dominio o IP? Il fatto che ti delistino e poi ci rifinisci è sospetto e normalmente significa che molta gente che riceve le tue newsletter ti marca come spam. Sei proprio sicuro al 100% che la lista sia opt-in e che invii alle stesse persone alle quale inviavanoi i vecchi server che non avevano problemi di delivery? Alternativamente: sei sicuro che non ci siano spammer che stanno usando i tuoi server per inviare spam a tua insaputa?

Questi invece sembrano header di Razorgate:

X-Junkmail: UCE(300)
X-Junkmail-Status: score=300/55, host=hostlibero

300 è il massimo score spam che può registrare quel sistema, e normalmente assegnato solamente a virus, malware ed email di "enlargement" di quello che puoi immaginare e cose simili: è MOLTO strano che trovi questi header in una email legittima.

Poi non ho capito una cosa: questo "X-Junkmail: UCE(300)" te lo trovi guardando gli header nella email ricevuta di libero nella casella spam o sono in un bounce ricevuto da libero?

Il "X-Junkmail: UCE(300)" lo trovo nell'header della mail che ricevo nella casella di libero (email di test e controllo)
Le liste di invio sono le stesse e vengono pulite ogni giorno da hard bounce, il vecchio server di invio era di proprietà del provider (quindi sicuramente non cosi facile da inserire in qualche backlist) ma come hai visto gli header del vecchio server erano davvero molto scarne e senza DKIM e SPF.
Inoltre non ho spammer che inviamo dai miei server al 100%.

Cludmark mi ha resettato per l'ennesima volta gli IP che uso e gli ho inviato anche il nome del dominio! ma credo abbiamo resettato entrambi, dal loro modulo di reset non risulto oggi.

Secondo me stiamo parlando troppo

Qualche messaggio fa ti ho spiegato come simulare una connessione SMTP completa con un telnet.
Prova a mandare un semplice messaggio così costruito a libero e vedi se ti arriva in spam o meno e quali sono gli header.

Questo è quello che scrivi dopo il DATA

Subject: Prova invio
From: "Tuo Nome" untuoindirizzochenonsiaquello@cheusinelleemailproblematiche
To: "Nome Destinatario" [email protected]

Semplice messaggio di testo
.

(quella riga con solo il punto è importante e serve per dire che hai finito il messaggio)