Allineamento DMARC: che cos’è, perché fallisce e come correggerlo

L’allineamento DMARC viene spesso trascurato. Il team pubblica SPF, DKIM e DMARC, ma Gmail continua a classificare alcuni messaggi come spam o a rifiutarli. Per rivedere l’insieme, consulta la nostra guida alla posta aziendale, poi torna qui per esaminare autenticazione e allineamento.

Superare l’autenticazione non basta: il dominio validato da SPF o DKIM deve essere allineato al dominio visibile di From. Se nessun meccanismo fornisce un risultato valido e allineato, DMARC fallisce; questo da solo non dimostra una falsificazione. Questi problemi riguardano piattaforme di invio, CRM, assistenza, inoltri e configurazioni DNS incomplete.

Vedremo come funziona l’allineamento, perché correggere solo SPF può non bastare e quali intestazioni esaminare. Spiegheremo anche quando DKIM può permettere a DMARC di passare dopo un inoltro, senza garantire che ogni percorso conservi la firma.

Che cos’è l’allineamento DMARC?

L’allineamento confronta il dominio autenticato da SPF o DKIM con il dominio visibile di From. DMARC passa se SPF passa con allineamento oppure se DKIM passa con allineamento. Basta un risultato valido e allineato; DMARC fallisce quando nessun meccanismo lo fornisce.

La regola viene da RFC 7489. DMARC si basa su SPF e DKIM, senza autenticare la posta in modo indipendente. Verifica se il dominio autenticato è allineato a quello visibile al destinatario.

Ecco le comparazioni:

In sintesi: SPF o DKIM valido con un dominio non allineato non basta da solo. Per DMARC, almeno uno deve passare ed essere allineato a From.

DMARC pass = (SPF pass + SPF aligned) OR (DKIM pass + DKIM aligned)

Perché SPF passa senza fornire allineamento DMARC

L’allineamento SPF fallisce quando il Return-Path appartiene a un dominio del fornitore non allineato al tuo. L’IP può essere autorizzato e SPF passare, ma un dominio di bounce di SendGrid, Mailchimp, HubSpot o Shopify può non essere allineato. DMARC può comunque passare se DKIM fornisce un risultato valido e allineato.

È un caso comune. Le piattaforme gestiscono mancati recapiti, liste di soppressione ed eventi; alcune usano per impostazione predefinita un proprio Return-Path.

From visibile: billing@example.com
Return-Path: bounces+123@sendgrid.net

SPF può passare perché SendGrid autorizza l’IP per sendgrid.net. Quel risultato non fornisce allineamento DMARC: sendgrid.net non è allineato a example.com.

Per allineare SPF, configura il dominio di bounce o Return-Path personalizzato del fornitore. Non confondere questa funzione con la personalizzazione dei link o il dominio di tracciamento: non cambiano necessariamente il mittente della busta.

bounces.example.com.   CNAME   u1234.wl.sendgrid.net.

Il CNAME è illustrativo. Il fornitore deve attivare la funzione e usare realmente bounces.example.com nel mittente della busta; controllalo su messaggi reali. In modalità rilassata, quel dominio è allineato a example.com.

L’inoltro aggiunge una difficoltà. Un’università, un rivenditore o una casella personale può inoltrare dal proprio IP, che SPF valuta per il dominio della busta usato in quel passaggio. Per questo le guide su come inoltrare la posta del dominio a Gmail e l’inoltro con alias trattano errori SPF. SPF è utile, ma non garantisce che DMARC passi dopo un inoltro.

Perché verificare l’allineamento DKIM

DKIM può resistere ad alcuni inoltri meglio di SPF. Per permettere a DMARC di passare, la firma deve restare valida e allineata e i dati firmati devono essere preservati dopo la canonicalizzazione. Dire soltanto che il messaggio non è cambiato in modo importante non basta.

È quindi consigliabile configurare DKIM allineato, soprattutto con intermediari. Non è un obbligo universale del protocollo quando SPF passa già con allineamento. Uno strumento che firma con il proprio dominio può superare DKIM senza contribuire all’allineamento del tuo dominio.

From visibile: newsletter@example.com
Firma DKIM: d=mailchimpapp.net

DKIM può passare, ma il dominio firmatario non è allineato. DMARC fallisce se neppure SPF passa con allineamento.

Configura l’autenticazione del dominio in ogni piattaforma. Può richiedere la pubblicazione dei record DKIM indicati dal fornitore e l’attivazione del loro uso, non soltanto un’attesa dopo la pubblicazione.

s1._domainkey.example.com.   CNAME   s1.domainkey.u1234.vendor.net.
s2._domainkey.example.com.   CNAME   s2.domainkey.u1234.vendor.net.

Dopo configurazione e verifica, la piattaforma può firmare con d=example.com o un sottodominio allineato in modalità rilassata, come d=mail.example.com. DKIM può fornire l’allineamento anche quando SPF fallisce per inoltro, purché la firma resti valida.

Le indicazioni Google citate richiedono ai mittenti di grandi volumi che SPF o DKIM passi allineato a From e raccomandano di configurare entrambi correttamente. Verifica requisiti attuali e ambito: errori di autenticazione possono contribuire alle restrizioni, ma l’allineamento non garantisce la posta in arrivo.

Allineamento rilassato e rigoroso

La modalità rilassata confronta il dominio organizzativo; quella rigorosa richiede il dominio completo esatto. La modalità rilassata è predefinita, ma la scelta dipende dai mittenti e dai rischi reali, non da una regola universale.

I tag aspf per SPF e adkim per DKIM controllano la modalità in DMARC.

Esempio:

_dmarc.example.com. TXT "v=DMARC1; p=none; aspf=r; adkim=r; rua=mailto:dmarc@example.com"

La modalità rigorosa può complicare l’operatività. Se un’applicazione firma con mail.example.com e From usa example.com, DKIM non fornisce più allineamento rigoroso; DMARC può comunque passare grazie a SPF valido e allineato.

Attiva la modalità rigorosa per un’esigenza concreta e dopo aver esaminato tutti i flussi. Anche nella modalità rilassata, verifica che ogni mittente autorizzato fornisca un risultato valido e allineato.

Come esaminare l’allineamento DMARC

Esamina le intestazioni ricevute: Authentication-Results, il dominio d= della firma DKIM, smtp.mailfrom per SPF e il risultato dmarc associato a header.from. Fidati soltanto di Authentication-Results generato dal destinatario che valuta il messaggio, non di intestazioni aggiunte dal mittente.

Se un messaggio sembra legittimo ma fallisce DMARC, queste intestazioni e la firma possono aiutare a identificare i domini usati. Confrontale con configurazione e log del servizio.

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces+123@sendgrid.net;
  dmarc=fail header.from=example.com

Leggi i dati in questo ordine:

1. Controlla header.from, il dominio visibile valutato da DMARC.
2. Controlla il dominio SPF in smtp.mailfrom. Se appartiene al fornitore senza essere allineato, SPF non fornisce allineamento DMARC.
3. header.i non sostituisce il dominio d= della firma, usato per l’allineamento DKIM e che può differire dall’identità i. Verifica la firma reale: un dominio del fornitore non allineato non fornisce allineamento.
4. Se nessun risultato riuscito è allineato a From, DMARC fallisce anche se SPF e DKIM passano per altri domini.

Puoi anche interrogare il DNS:

dig +short TXT _dmarc.example.com
dig +short TXT example.com
dig +short CNAME s1._domainkey.example.com

Nell’inoltro, un errore SPF può essere previsto, ma non va ignorato automaticamente. Verifica che DKIM passi con allineamento e che i dati firmati siano preservati dopo la canonicalizzazione; DKIM valido senza allineamento non salva DMARC.

Per configurare un dominio, la guida di TrekMail e quella per creare email con il tuo dominio aiutano a organizzare SPF, DKIM e DMARC. Mantieni un SPF valido per ogni dominio reale della busta e rispetta il limite di meccanismi e modificatori che richiedono DNS, incluse valutazioni annidate. Rimuovi i vecchi record solo dopo aver confermato che non servono più; non eliminare indistintamente tutti i record MX o selettori.

Situazioni frequenti di errore di allineamento

Fornitori esterni, inoltri, sottodomini e record DNS vecchi o duplicati sono piste comuni. Riconoscere una situazione orienta l’esame, ma non dimostra da solo la causa.

Controlla questi casi:

1. Il marketing usa il proprio dominio di bounce: SPF passa senza allineamento; DMARC può passare con DKIM valido e allineato.
2. Il fornitore firma con il suo dominio: DKIM passa senza allineamento; SPF valido e allineato può ancora far passare DMARC.
3. Un inoltro fa fallire SPF: DKIM deve restare valido e allineato per fornire il risultato restante.
4. La modalità rigorosa impedisce l’allineamento di un sottodominio autorizzato; controlla se l’altro meccanismo fornisce allineamento.
5. Restano DNS vecchi: conferma quali record e servizi sono usati prima di modificarli; un record obsoleto non dimostra che la piattaforma invii o firmi ancora.

L’errore Gmail 4.7.32, quando indica che From non è allineato a SPF o DKIM, segnala un problema specifico di allineamento. Possono coesistere anche problemi di reputazione o invio. Consulta le linee guida di invio di Google e il loro ambito attuale.

Correggere l’allineamento con TrekMail

TrekMail può riunire gestione delle caselle, controlli DNS e scelte di invio secondo il piano. Centralizzare può facilitare il coordinamento tra cinque pannelli, ma servono comunque configurazioni corrette e test di ogni mittente.

Ecco alcune opzioni pratiche.

Gestione distribuita e centralizzata

Con SMTP gestito nei piani a pagamento che lo includono, pubblica i DNS indicati e testa l’autenticazione allineata su messaggi reali. Con SMTP proprio su Nano o piani compatibili, configura il fornitore reale, SES, SendGrid, Mailgun o altro. L’obiettivo è un risultato valido e allineato, non solo un indicatore positivo nel pannello.

Riferimenti utili:

Le mie email arrivano nello spam tratta errori SPF e DKIM valido negli inoltri, che superano DMARC solo se DKIM è anche allineato. La documentazione delle impostazioni IMAP & SMTP presenta i punti di connessione per testare l’accesso dei client, distinto dall’allineamento dell’invio.

L’offerta descritta presenta Starter da $3.50 al mese e una prova gratuita di 14 giorni sui piani a pagamento che richiede una carta di credito per iniziare. Nano è proposto senza costi con SMTP proprio, fino a 10 domini e 5 GB di spazio condiviso secondo le condizioni. Verifica prezzi, limiti e funzionalità attuali nella pagina dei prezzi di TrekMail. La copia IMAP non sostituisce il cambio dei record MX né migra tutte le applicazioni; confrontare i modelli tariffari non garantisce risparmi.

Lista finale per l’allineamento DMARC

Una distribuzione controllata mira a SPF o DKIM valido e allineato per ogni mittente autorizzato, possibilmente entrambi. Aiuta a valutare le restrizioni, ma non elimina tutti i rischi dell’inoltro né garantisce il recapito.

1. Elenca tutti i mittenti: hosting delle caselle, CRM, fatturazione, assistenza, negozio, moduli e marketing.
2. Conferma il dominio visibile di From per ogni servizio.
3. Controlla SPF e allineamento del dominio reale del Return-Path, non solo la sua presenza.
4. Configura e verifica DKIM del fornitore allineato al tuo dominio, soprattutto nei percorsi con inoltro.
5. Mantieni aspf=r e adkim=r salvo un’esigenza testata che giustifichi la modalità rigorosa.
6. Invia test a Gmail ed esamina Authentication-Results prodotto dal destinatario e il dominio reale della firma DKIM.
7. Valuta di mantenere p=none mentre validi i flussi; non richiede restrizioni DMARC, ma restano attivi i filtri locali.
8. Applica restrizioni dopo aver confrontato report parziali con inventari, log e test dei flussi critici poco frequenti, valutando errori restanti ed eccezioni locali.

L’allineamento è una condizione di autenticazione DMARC, non una classificazione infallibile tra messaggi legittimi e falsificati né una garanzia di contenuto sicuro. Per coordinare più domini, valuta TrekMail secondo i piani e la tua operatività, senza presumere risparmi rispetto alla fatturazione per utente.