Un errore DMARC significa che il messaggio non ha ottenuto un risultato di autenticazione valido e allineato al dominio di From. p=reject richiede il rifiuto; p=quarantine richiede un trattamento restrittivo. Il destinatario può applicare eccezioni locali e non è garantita una specifica cartella spam. Esamina la configurazione senza escludere problemi di reputazione concomitanti. Per il contesto generale, consulta la posta aziendale per le piccole imprese.
Molti casi riguardano l’allineamento, un inoltro che fa fallire SPF, un flusso senza DKIM o SPF che supera il limite di valutazione DNS. Leggi le intestazioni, confronta i domini e identifica il meccanismo che non fornisce un risultato valido e allineato.
Questa guida propone una tabella diagnostica, un processo di verifica ed esempi DNS da adattare e controllare, senza promettere una soluzione definitiva per ogni caso.
Che cosa significa davvero un errore DMARC?
DMARC fallisce quando nessun meccanismo fornisce un risultato di autenticazione valido e allineato. SPF o DKIM può passare per un altro dominio; se nessuno passa allineato a From, DMARC fallisce.
La specifica richiede che SPF o DKIM passi e che il dominio autenticato sia allineato al dominio RFC5322 di From. Consulta RFC 7489.
| Scenario | SPF | DKIM | DMARC | Interpretazione | Verifiche |
|---|---|---|---|---|---|
| Entrambi i meccanismi falliscono | Fail | Fail | Fail | Possibile errore di configurazione, inoltro o mittente non autorizzato; non dimostra abuso | Confrontare mittente, IP, DNS e firma con inventario e log |
| Autenticazione senza allineamento | Pass, non allineato | Pass, non allineato | Fail | L’autenticazione passa, ma non è allineata a From | Configurare e verificare Return-Path personalizzato e DKIM allineato |
| Messaggio inoltrato | Fail | Pass, allineato | Pass | Possibile comportamento previsto dell’inoltro | Verificare firma valida e allineata e conservazione dei dati firmati dopo la canonicalizzazione |
| Inoltro con modifica | Fail | Fail | Fail | Una lista o un relay può aver modificato dati firmati; esaminare la causa | Valutare flusso ed eccezioni locali; ARC può orientare il destinatario, non trasformare l’errore in autenticazione riuscita |
| SPF PermError | PermError | Fail o assente | Fail | Possibile superamento del limite di valutazione SPF o sintassi errata | Verificare SPF; separare i fornitori richiede l’uso reale dei nuovi domini della busta |
Passo 1: verificare prima l’allineamento
Molti errori nei messaggi legittimi dipendono dall’allineamento: il fornitore autentica il proprio dominio anziché il tuo. Conta quale dominio passa, non soltanto il successo della verifica.
Esempio:
From dell’intestazione:
support@yourdomain.com
Return-Path:bounces.vendor.net
DKIM:d=vendor.net
Il messaggio può mostrare spf=pass e dkim=pass e fallire comunque DMARC perché vendor.net non è allineato a yourdomain.com.
È comune con marketing, CRM, assistenza e SMTP alternativi. Verifica se il fornitore consente l’autenticazione del dominio, Return-Path e dominio di bounce personalizzati o DKIM con il tuo dominio. Un dominio di tracciamento o di personalizzazione dei link non sostituisce un Return-Path personalizzato.
Questi cambiamenti DNS sono illustrativi; usa i valori del fornitore reale e attiva e prova le funzioni:
Type: CNAME
Host: bounces
Value: yourvendor.example.net
Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net
Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.netTrekMail offre un processo di configurazione DNS secondo il servizio scelto. Consulta l’aggiunta di un dominio e i record DNS necessari. Se SPF esiste già, riunisci le autorizzazioni valide in un record per dominio reale della busta, senza aggiungere un secondo SPF. Il pannello non dimostra l’autenticazione di tutti i flussi.
Passo 2: esaminare le intestazioni originali
Apri il sorgente del messaggio e identifica Authentication-Results, Return-Path e i domini DKIM d=. Fidati soltanto dei risultati generati dal destinatario che valuta il messaggio; il mittente può aggiungere intestazioni false.
Usa questa lista:
- Identifica il dominio visibile di From.
- Verifica se SPF è passato.
- Verifica per quale dominio SPF è passato.
- Verifica se DKIM è passato.
- Identifica il dominio firmatario reale di DKIM.
- Confronta entrambi con From.
Ecco un esempio di intestazione con errore DMARC:
Authentication-Results: mx.google.com;
dkim=pass header.i=@sendgrid.net header.s=s1;
spf=pass smtp.mailfrom=bounces.sendgrid.net;
dmarc=fail (p=reject) header.from=yourdomain.comInterpretala con attenzione:
SPF è passato per bounces.sendgrid.net, che condivide il dominio organizzativo sendgrid.net. L’identità DKIM indicata appartiene a sendgrid.net, ma header.i non sostituisce il dominio d= della firma: verificalo. From usa yourdomain.com. Il risultato del destinatario indica che nessun meccanismo ha fornito autenticazione allineata.
Ripeti la verifica per ogni flusso. La posta transazionale può essere corretta mentre marketing, assistenza o alias inoltrati continuano a fallire. Consulta anche come configurare email sul tuo dominio.
Passo 3: esaminare l’inoltro separatamente
L’inoltro può far fallire SPF: il relay invia da un altro IP che può non essere autorizzato dal dominio reale di MAIL FROM. DMARC passa ancora se DKIM resta valido e allineato e i dati firmati sono preservati dopo la canonicalizzazione.
Un errore SPF su Google Groups, Outlook o relay universitari non racconta tutto. Se DKIM passa allineato, DMARC passa. Questo non garantisce contenuto sicuro né recapito nella posta in arrivo.
RFC 7960 spiega che conservare il mittente originale della busta può far fallire SPF; riscriverlo, per esempio con SRS, non ripristina l’allineamento al From originale. DKIM può fornire il risultato allineato, ma non resiste a tutti i percorsi. Consulta RFC 7960.
Non aggiungere autorizzazioni SPF indiscriminatamente per tentare di correggere tutti gli inoltri. Verifica questi punti:
- Firma con DKIM i flussi in uscita compatibili e verifica l’allineamento.
- Valuta la modalità rilassata, che confronta il dominio organizzativo; quella rigorosa richiede un’esigenza concreta e test.
- Esamina le liste che modificano dati firmati e possono far fallire DKIM e, senza un altro risultato allineato, anche DMARC.
Se dipendi dall’inoltro, consulta la configurazione dell’inoltro email e come inoltrare la posta del dominio a Gmail. TrekMail offre inoltro e opzioni SMTP secondo il piano, senza garantire la conservazione di DKIM o il recapito attraverso qualsiasi intermediario.
Passo 4: verificare SPF e gli errori permanenti
SPF PermError può verificarsi quando si supera il limite di dieci meccanismi o modificatori che richiedono ricerche DNS, comprese le valutazioni annidate, oppure per sintassi e inclusioni non valide. Non è un limite del totale dei pacchetti DNS. Un risultato permanente inutilizzabile non fornisce SPF valido e allineato a DMARC.
Un SPF con molte inclusioni può apparire così:
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~allL’aspetto non determina la validità. Valuta inclusioni annidate e reindirizzamenti secondo le regole SPF; contare soltanto le query visibili non basta.
Interroga i record con questi strumenti:
dig +short txt yourdomain.com
nslookup -type=txt yourdomain.comQueste ricerche non dimostrano da sole un PermError. Verifica i servizi attivi. Se non usi una piattaforma da sei mesi, rimuovi l’autorizzazione solo dopo aver confermato che non serve. Puoi valutare la separazione dei fornitori per sottodominio:
marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.comOgni dominio può avere la propria valutazione SPF se il fornitore lo usa realmente in MAIL FROM. Creare il sottodominio non cambia l’invio: attiva la configurazione e testa SPF, DKIM e allineamento a From prima di spostare il flusso.
La documentazione TrekMail spiega come evitare SPF duplicati e riunire le autorizzazioni in un TXT valido. Consulta la verifica dello stato DNS.
Passo 5: distinguere errori e possibili falsificazioni
Non tutti gli errori DMARC giustificano l’autorizzazione di una nuova fonte. Alcuni corrispondono a falsificazioni, altri a mittenti legittimi mal configurati o inoltri. Il risultato di autenticazione non basta per decidere.
Se SPF e DKIM falliscono da un IP sconosciuto, non autorizzarlo né bloccarlo automaticamente. Confronta inventario, log e percorsi di inoltro. p=quarantine e p=reject richiedono restrizioni, ma l’applicazione dipende dal destinatario e da possibili eccezioni locali.
Segui questo processo:
- Esamina l’IP o il fornitore sconosciuto prima di classificarlo come abuso.
- Per un mittente autorizzato, identifica la piattaforma e verifica l’autenticazione del dominio.
- Se manca DKIM su una piattaforma compatibile, configuralo e verifica firma e allineamento.
- Se nessun meccanismo può passare allineato, valuta un altro fornitore o la separazione del flusso con configurazione attiva e test, non soltanto nuovi DNS.
Le indicazioni Google citate spiegano l’applicazione delle politiche DMARC quando autenticazione o allineamento falliscono, secondo il caso e le regole locali. Verifica requisiti attuali e ambito nelle indicazioni di autenticazione dei mittenti di Google.
Schemi di errore per tipo di mittente
Il tipo di sistema può orientare l’indagine, ma non dimostra automaticamente la causa. Verifica il flusso e i risultati reali.
| Tipo di mittente | Possibile causa | Verifica o correzione |
|---|---|---|
| Marketing | DKIM o dominio di bounce non allineato | Configurare e provare DKIM personalizzato e Return-Path proprio |
| Assistenza o CRM | Domini di autenticazione del fornitore non allineati a From | Completare e verificare l’autenticazione del dominio |
| Inoltro della casella | SPF fallisce dopo il relay | Verificare DKIM valido e allineato e conservazione dei dati firmati |
| Lista di distribuzione | Inoltro con modifiche al corpo o intestazioni firmate | Esaminare gli errori; ARC può orientare eccezioni locali, senza garantire il successo di DMARC |
| Piccola impresa con più servizi | Valutazione SPF eccessiva o DNS incompleto | Riunire autorizzazioni e valutare domini della busta separati realmente utilizzati |
| Agenzia con molti domini | Configurazioni DNS incoerenti | Standardizzare il processo con valori adattati e test per cliente |
Risolvere gli errori DMARC su più domini
Un cliente usa Google Workspace, un altro cPanel, un altro SendGrid e un altro inoltra tutto a Gmail. Senza documentazione dei DNS attuali, gli errori possono diventare incidenti ricorrenti.
Un processo comune può aiutare: inventario, lista DNS e piano di migrazione per esaminare domini, inoltri, SMTP e autenticazione. Centralizzare non sostituisce i test per flusso.
L’offerta TrekMail descritta presenta piani a pagamento da $3.50 al mese, una prova gratuita di 14 giorni soggetta a condizioni e un piano senza costi con SMTP proprio secondo l’offerta attuale. Domini personalizzati, caselle IMAP, catch-all, inoltro, copia IMAP, API e strumenti DNS dipendono dal piano e dai suoi limiti. Copiare messaggi non sostituisce il cambio dei record MX e non migra tutte le applicazioni; queste funzioni non garantiscono risparmi o meno incidenti.
Per molti domini dei clienti, consulta l’hosting email multidominio e confronta il processo con la gestione manuale presso ogni registrar.
Lista breve per esaminare un errore DMARC
Parti da un messaggio fallito, identifica i domini autenticati, confrontali con From e prova la correzione corrispondente. Ripeti l’esame per gli altri flussi, inclusi quelli critici e poco frequenti.
- Apri il messaggio ed esamina
Authentication-Resultsdel destinatario attendibile. - Verifica se SPF è passato e per quale dominio reale della busta.
- Verifica se DKIM è passato e per quale dominio
d=. - Confronta entrambi con From visibile.
- Se nessuno passa allineato, correggi autenticazione e allineamento necessari.
- Se c’è inoltro, verifica DKIM valido e allineato e conservazione dei dati firmati.
- Se SPF supera il limite, rimuovi autorizzazioni inutili o configura e testa domini della busta separati.
- Se entrambi falliscono da una fonte sconosciuta, esaminala prima di classificarla o cambiarne il trattamento.
Il processo si basa su risultati attendibili, inventario e test, non su supposizioni.
Conclusione: identificare il meccanismo all’origine dell’errore
Un errore DMARC può comparire al recapito per disallineamento, inoltro con DKIM non valido, SPF PermError o fonte non autorizzata. Occorre distinguere questi casi senza presumere che ogni errore sia abuso o che un risultato valido garantisca sicurezza.
Correggi la configurazione identificata e verifica messaggi reali anziché aggiungere DNS casualmente. TrekMail offre spazio condiviso, gestione multidominio, SMTP proprio su Nano, SMTP gestito sui piani compatibili e copia IMAP secondo l’offerta attuale. Non sostituisce la validazione né garantisce una migrazione completa. Consulta TrekMail o confronta le condizioni su https://trekmail.net/pricing.
