Errore DMARC: cause e correzioni nella posta inoltrata

Le segnalazioni di errore DMARC arrivano talvolta quando la parte difficile sembra conclusa. SPF e DKIM sono pubblicati. La policy DMARC usa finalmente p=quarantine o p=reject. Poi un messaggio legittimo viene inoltrato e non raggiunge la destinazione prevista. Non è necessariamente contraffazione o spam: potrebbe aver seguito un percorso che la configurazione non gestiva correttamente.

È una delle difficoltà dell'errore DMARC durante l'inoltro. Il messaggio può essere legittimo, ma il passaggio intermedio modifica il contesto di recapito e il destinatario può non considerarlo più affidabile. Se controlli soltanto che SPF e DKIM siano presenti, sembra casuale. Esaminare percorso, firme e allineamento aiuta a individuare cause concrete e scegliere la correzione.

Per la configurazione generale, parti dall'email aziendale. Se utilizzi già inoltri, consulta anche l'inoltro email.

Cosa significa davvero un errore DMARC

Un errore DMARC significa che il messaggio non ha ottenuto né SPF superato e allineato né una firma DKIM valida e allineata al dominio del From visibile. L'autenticazione da sola non basta. DMARC verifica la relazione tra il dominio autenticato e quello presentato al destinatario, secondo la modalità di allineamento configurata.

DMARC si basa su SPF e DKIM. Il principio di base descritto nella specifica storica RFC 7489 prevede che basti una di queste condizioni:

1. SPF supera la verifica e il suo dominio è allineato al dominio del From nell'intestazione.
2. Una firma DKIM supera la verifica e il suo dominio è allineato al dominio del From nell'intestazione.

Sembra semplice. In pratica, l'analisi di un errore DMARC si complica quando vengono confusi tre concetti:

• Autenticazione: SPF o DKIM ha superato la verifica?
• Allineamento: il dominio verificato è allineato al dominio del From nell'intestazione?
• Conservazione durante l'inoltro: le modifiche del passaggio hanno invalidato la firma?

SPF può superare la verifica e lasciare un errore DMARC. DKIM può superarla e lasciare un errore DMARC. Se nessuna identità verificata è allineata al dominio richiesto, DMARC fallisce.

Perché l'inoltro può causare errori DMARC

L'inoltro può provocare un errore DMARC perché modifica il percorso e talvolta il contenuto. SPF dipende dalla connessione; DKIM dipende dall'integrità dei dati firmati. Un inoltro può compromettere una verifica, e alcune modifiche o configurazioni possono compromettere entrambe.

Ecco un percorso comune:

1. Un mittente invia da sender.com.
2. Una casella o un gateway intermedio riceve il messaggio.
3. Il sistema lo inoltra automaticamente a Gmail, Outlook o un'altra destinazione.

Il destinatario finale non vede più l'IP originale come client SMTP. Vede quello del servizio di inoltro.

Questo cambiamento può spiegare l'inizio di un errore DMARC.

SPF è spesso il primo a risentirne

SPF, definito in RFC 7208, verifica se l'IP connesso è autorizzato a inviare per il dominio del mittente della busta SMTP.

Dopo l'inoltro, la connessione arriva dall'intermediario. Se mantiene il mittente della busta e il suo IP non è autorizzato, SPF fallisce. SRS può riscrivere quel mittente e consentire SPF per il dominio dell'intermediario, ma non garantisce l'allineamento DMARC con il From originale.

Percorso originale: sender.com invia dall'IP A autorizzato. SPF supera la verifica.
Percorso inoltrato: l'intermediario invia dall'IP B. Il destinatario verifica sender.com rispetto all'IP B, non autorizzato in questo esempio. SPF fallisce.

Questo fallimento SPF non garantisce un errore DMARC. Se rimane una firma DKIM valida e allineata, DMARC può ancora superare la verifica. Conviene quindi testare DKIM sui percorsi indiretti reali.

DKIM può conservare l'autenticazione del messaggio

DKIM, definito in RFC 6376, firma determinate intestazioni e il corpo. La validità della firma non dipende dall'IP che inoltra il messaggio. DKIM può quindi offrire un percorso di verifica DMARC quando SPF non è più utilizzabile.

Perché questo avvenga, devono essere vere entrambe le condizioni:

1. La firma rimane valida dopo l'inoltro.
2. Il dominio d= è allineato al dominio del From visibile.

Se una condizione manca e SPF non supera la verifica con allineamento, può verificarsi un altro errore DMARC.

Alcuni intermediari modificano il messaggio in modi che possono invalidare la firma:

• Aggiunta di [EXTERNAL] all'oggetto
• Aggiunta di avvisi o note legali nel piè di pagina
• Riscrittura dei delimitatori MIME
• Modifica delle interruzioni di riga o degli spazi

La canonicalizzazione rilassata tollera alcune modifiche di formato, non tutte. Il risultato dipende dai dati firmati e dai cambiamenti apportati. Un errore DMARC su posta inoltrata non dimostra una contraffazione: può anche indicare un problema di implementazione.

Il mancato allineamento può causare errori anche senza inoltro

Un errore DMARC non richiede un inoltro. Può verificarsi quando un servizio SaaS autentica con il proprio dominio e nessuna identità verificata è allineata al tuo. Il messaggio può essere legittimo e fallire comunque DMARC.

È un aspetto da controllare per ogni servizio esterno.

Esempio:

• From: billing@yourcompany.com
• Return-Path: bounce.vendor-mail.com
• DKIM: d=vendor-mail.com

SPF può verificare un'identità di vendor-mail.com. DKIM può superare la verifica per vendor-mail.com. In questo esempio, DMARC mostra un errore DMARC perché nessuna identità autenticata è allineata a yourcompany.com.

Configura l'autenticazione personalizzata del dominio secondo le opzioni del provider. Per DMARC basta un percorso verificato e allineato; DKIM allineato è particolarmente utile negli inoltri. Una firma del provider non provoca il fallimento se un altro percorso soddisfa i requisiti.

Se stai riorganizzando una configurazione ricca di alias, leggi alias di dominio o casella email. Documentare il percorso di ogni indirizzo aiuta a localizzare i problemi di autenticazione.

Come diagnosticare l'errore dalle intestazioni

Le intestazioni permettono di indagare molti casi di errore DMARC senza tirare a indovinare. Parti da Authentication-Results aggiunto da un server ricevente affidabile, non da un'intestazione qualsiasi copiata nel messaggio. Confronta risultati e domini di SPF, DKIM e From.

Chiedi al destinatario le intestazioni complete e cerca un risultato come questo:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=pass header.i=@sender.com header.s=mail;
       dmarc=pass header.from=sender.com

È compatibile con un inoltro che ha fatto fallire SPF mentre DKIM consentiva a DMARC di superare la verifica. Conferma il percorso nelle intestazioni; il risultato da solo non dimostra il recapito in posta in arrivo.

Questo risultato richiede un'indagine:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=fail header.i=@sender.com;
       dmarc=fail header.from=sender.com

Può essere un errore DMARC legato all'inoltro: la connessione è cambiata e DKIM non è più valido. Verifica se l'intermediario ha modificato il messaggio o se la firma era già invalida prima del passaggio.

Come ridurre gli errori sulla posta inoltrata

Non puoi impedire ogni inoltro. Per ridurre l'errore DMARC sui messaggi legittimi, progetta e testa quei percorsi: DKIM valido e allineato, SPF mantenuto e intermediari che conservano i dati firmati. Nessuna combinazione garantisce il trattamento finale del destinatario.

1. Integra DKIM in ogni percorso di invio

Per conservare un percorso DMARC durante l'inoltro, configura DKIM allineato su ogni flusso legittimo: newsletter, assistenza, fatturazione e altri messaggi. Verifica la validità dopo i passaggi rilevanti.

La firma deve essere allineata al From visibile. Per un messaggio da yourdomain.com, può usare yourdomain.com o un sottodominio compatibile con la modalità configurata. L'allineamento rigoroso richiede una corrispondenza esatta.

In TrekMail, parti dai record DNS richiesti. Uno stato giallo o rosso merita una verifica; uno stato corretto non sostituisce una prova di inoltro.

2. Valuta la canonicalizzazione DKIM rilassata

La canonicalizzazione semplice tollera meno cambiamenti di formato. Alcune modifiche possono invalidare DKIM e contribuire a un errore DMARC. Quella rilassata ammette determinati cambiamenti di spazi e normalizzazione delle intestazioni previsti dalla specifica; non equivale all'allineamento DMARC rilassato.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
 c=relaxed/relaxed; h=from:to:subject:date:message-id; ...

Non conserva necessariamente la firma se viene aggiunto un piè di pagina al corpo. È una tolleranza di formato, non il permesso di modificare liberamente il contenuto.

3. Verifica le identità usate dai provider

Se CRM, assistenza o newsletter firma con d=vendor.com, controlla l'allineamento e l'eventuale presenza di un altro percorso verificato e allineato. Senza nessuno, può verificarsi un errore DMARC anche senza inoltro. Configura DKIM e mittente della busta personalizzati secondo il servizio; testa soprattutto DKIM allineato sui percorsi indiretti.

4. Mantieni SPF entro i limiti

SPF non fallisce soltanto durante l'inoltro. RFC 7208 limita a 10 i termini che richiedono ricerche DNS durante la valutazione, inclusi i termini pertinenti annidati. Superare il limite, non semplicemente raggiungerlo, può produrre permerror e rendere SPF inutilizzabile come percorso verificato per DMARC.

dig +short TXT example.com

dig +short TXT _dmarc.example.com

Se hai accumulato Google, Microsoft, Mailgun, SendGrid, Zendesk e tre vecchi host in SPF, controlla quali inviano ancora. Rimuovi le autorizzazioni obsolete dopo verifica e usa sottodomini quando opportuno, senza eliminare mittenti legittimi alla cieca.

5. Comprendi i limiti di SRS e ARC

SRS riscrive il mittente della busta e può consentire SPF per il dominio dell'intermediario, generalmente senza allineamento al From originale. ARC conserva risultati precedenti che il destinatario può valutare in base alla fiducia nei sigillatori. Non trasforma automaticamente un fallimento DMARC in successo e non garantisce il recapito. Nessuno dei due sostituisce DKIM configurato correttamente.

Le raccomandazioni Google per gli inoltri prevedono un trattamento diverso dell'allineamento DMARC e raccomandano ARC ai servizi di inoltro. Questo non cambia la regola di verifica del protocollo. Per le operazioni nel 2025 e nel 2026, controlla sempre l'ambito attuale delle regole del destinatario.

Se gestisci molte caselle inoltrate, confronta le capacità attuali della piattaforma. TrekMail offre inoltro e indicazioni DNS secondo la configurazione; consulta utilizzare il proprio SMTP e testa l'allineamento con il provider scelto.

Approccio precedente e approccio attuale per più domini

Un modo di gestire l'errore DMARC consisteva nell'accumulare strumenti fino a perdere l'inventario delle firme. Un altro separa chiaramente hosting delle caselle, invio e stato DNS per identificare e correggere gli errori. La visibilità dipende dal mantenimento della documentazione.

È l'approccio operativo di TrekMail secondo le funzioni attuali: ospitare più domini, condividere lo spazio e confrontare condizioni senza costi per utente, con SMTP gestito o esterno. Consulta l'hosting email multidominio e imapsync per la migrazione. IMAP non trasferisce DNS, reputazione o applicazioni.

Cosa fare quando arriva una segnalazione DMARC

Davanti a un errore DMARC, non passare automaticamente da reject a none. Determina prima se c'è stato inoltro, DKIM invalido o mancato allineamento. Se serve un adeguamento per proteggere traffico legittimo, prepara inventario, analisi dei report disponibili, test e piano di ripristino.

1. Ottieni le intestazioni complete e conferma quale server ricevente affidabile ha aggiunto i risultati.
2. Verifica se SPF ha fallito con la connessione di un intermediario noto.
3. Controlla se DKIM ha superato la verifica e quale dominio d= ha firmato.
4. Verifica l'allineamento della firma al From visibile.
5. Cerca arc=pass e valuta la fiducia nella catena se c'è stato un intermediario.
6. Esamina SPF per ricerche eccessive o autorizzazioni obsolete.

Su TrekMail, parti da aggiungere un dominio per rivedere i record e da non ricevo email se il messaggio manca senza un rifiuto visibile.

Conclusione: indaga sul progetto anziché supporre un mistero

Un errore DMARC ricorrente non dimostra che l'infrastruttura sia irrecuperabile. Può segnalare dipendenza da SPF su percorsi indiretti, DKIM invalido o non allineato, oppure modifiche degli intermediari. I report aggregati aiutano, ma sono parziali e non provano da soli la causa di ogni messaggio.

La correzione parte dalle basi: identità allineate, test DKIM dopo ogni percorso pertinente e manutenzione SPF. Includi inoltri e mailing list nei test, invece di presumere che conservino il messaggio.

Se cerchi questo modello operativo, confronta le funzioni e condizioni attuali di TrekMail: hosting multidominio a tariffa fissa, spazio condiviso, migrazione IMAP delle caselle, catch-all e opzioni di invio senza costi per utente. La fonte pubblicizza piani a pagamento da $3.50 al mese con fatturazione annuale e una prova gratuita di 14 giorni; verifica l'obbligo di carta. Nano è proposto gratuitamente senza carta. Consulta i prezzi o TrekMail. Prezzi e condizioni possono cambiare.

In breve: se nel tuo ambiente esistono inoltri, l'errore DMARC merita test espliciti. Correggere le cause individuate può migliorare l'operatività, ma superare DMARC non garantisce il recapito in posta in arrivo.