Un mittente può dimostrare il controllo del proprio dominio. Può comunque mostrare il tuo dominio nell'indirizzo From. L'autenticazione riuscita da sola non stabilisce il permesso di usare quell'identità visualizzata.
Perché SPF e DKIM possono passare mentre DMARC fallisce?
Entrambi i controlli possono autenticare domini che non corrispondono al dominio From visibile.
SPF verifica se il server connesso è autorizzato per il dominio dell'envelope sender usato per le notifiche di mancata consegna. DKIM convalida una firma crittografica associata a un dominio di firma, identificato dal tag d della firma.
L'envelope sender viene fornito durante la conversazione SMTP. È separato dall'intestazione From visualizzata dal client di posta del destinatario.
Per esempio, un mittente che controlla attacker.example può superare SPF e DKIM per quel dominio. Il mittente può inserire billing@example.com in From. Nessuno dei due risultati convalida example.com, quindi DMARC fallisce.
Un dominio organizzativo è il confine amministrativo che contiene un dominio e i suoi sottodomini, ad esempio example.com per news.example.com.
Cosa conta come allineato?
L'allineamento rilassato richiede un dominio organizzativo condiviso. L'allineamento rigoroso richiede domini identici.
RFC 9989 definisce come i riceventi scoprono quel confine.
| Dominio autenticato | Dominio From | Allineamento |
|---|---|---|
foo.example.com | news.example.com | Rilassato, perché entrambi condividono example.com |
news.example.com | news.example.com | Rigoroso, perché i domini sono identici |
foo.example.net | news.example.com | Nessuno, perché i domini organizzativi differiscono |
Il tag adkim controlla l'allineamento DKIM. Il tag aspf controlla l'allineamento SPF. Ciascuno accetta r per rilassato o s per rigoroso, con rilassato come valore predefinito.
Usa l'allineamento rigoroso solo quando hai bisogno di domini identici, perché esclude corrispondenze altrimenti valide tra sottodomini fratelli. Un servizio che firma come foo.example.com non può soddisfare l'allineamento rigoroso per From su news.example.com.
La specifica riporta che quasi tutti i proprietari di dominio trovano sufficiente l'allineamento rilassato. I tuoi requisiti di corrispondenza del dominio determinano se l'allineamento rilassato è appropriato.
DMARC ha bisogno che entrambi i metodi siano allineati?
No: un pass allineato da SPF o DKIM è sufficiente.
Il ricevente valuta i metodi indipendentemente. Un risultato superato ma non allineato non può fornire il pass DMARC.
L'inoltro può interrompere SPF cambiando il server connesso. DKIM può sopravvivere se l'intermediario preserva il contenuto firmato. Una firma intatta da un dominio allineato consente quindi al messaggio di superare DMARC nonostante il fallimento di SPF.
Se l'inoltro modifica il contenuto firmato, anche DKIM può fallire. Come risolvere i fallimenti DMARC spiega la diagnosi.
Perché un servizio di invio può interrompere l'allineamento SPF?
L'allineamento SPF fallisce quando il servizio usa un dominio envelope sender che non è allineato con il tuo dominio From visibile.
Se il servizio usa il proprio dominio di rimbalzo non correlato, SPF può passare per quel dominio. DMARC rifiuta quel risultato come non allineato. Aggiungere il servizio a un record SPF sul tuo dominio non cambia il dominio verificato dal ricevente.
Configura un return path personalizzato, il dominio usato per le notifiche di mancata consegna, sotto il tuo dominio. Con l'allineamento rilassato, bounce.example.com può corrispondere a From su example.com.
DKIM offre un percorso alternativo: configura il servizio per firmare usando un dominio allineato. Puoi confermare entrambi i risultati nei report aggregati, che riepilogano i controlli del ricevente.
Come si configura il return path con Bird?
Pubblichi l'alias del return path di Bird sotto il tuo dominio di invio.
Pubblica quell'alias come record CNAME. L'alias del return path fornisce la configurazione SPF di Bird, quindi non hai bisogno di un record SPF separato alla radice del dominio per gli invii Bird.
Il campo return_path.name di API accetta da 1 a 63 lettere, cifre o trattini, con una lettera o cifra a ciascuna estremità. Un'etichetta più lunga o che inizia con un trattino non è valida.
Bird aggiunge il tuo dominio di invio. Per esempio, send su mail.example.com diventa send.mail.example.com. Quel return path può allinearsi con From su mail.example.com in modalità rilassata.
La guida al bounce domain tratta il record. Pubblichi anche il record DKIM. Bird accetta una policy DMARC valida sul dominio di invio o sul suo dominio organizzativo. Una policy di monitoraggio di p=none, che non esprime preferenze di gestione per i fallimenti, è sufficiente.
Come trova la specifica i domini organizzativi?
RFC 9989 cerca nella gerarchia dei domini i record che stabiliscono la policy applicabile e il confine del dominio. Questa ricerca è chiamata DNS tree walk.
La specifica sostituisce l'approccio Public Suffix List descritto da RFC 7489. Quella lista identifica suffissi di registrazione condivisi come com e co.uk.
La distinzione influisce sull'allineamento rilassato perché il dominio organizzativo scoperto determina se i nomi correlati corrispondono. Influisce anche su quale policy del dominio padre si applica a un sottodominio. Una specifica pubblicata non stabilisce quale metodo di scoperta un particolare ricevente implementa.
Un tag percentuale può controllare l'enforcement?
Il tag percentuale pct non fornisce un enforcement parziale affidabile. RFC 9989 lo esclude.
L'Appendice A.6 descrive una gestione incoerente delle percentuali intermedie. Un'impostazione di pct=50 pertanto non può garantire che una gestione più rigorosa colpisca esattamente la metà dei messaggi che falliscono.
I valori eccezionali erano zero e cento, corrispondenti a nessun enforcement basato sulla percentuale e a enforcement completo. Alcuni intermediari trattavano inoltre pct=0 come un segnale per riscrivere l'indirizzo From visibile ed evitare fallimenti a valle.
Usa i report per correggere i fallimenti legittimi prima di modificare la policy tramite none, quarantine e reject. Il valore none non esprime preferenze di gestione. Il valore quarantine contrassegna i fallimenti come sospetti. Il valore reject identifica un uso non autorizzato del dominio. La guida alla policy spiega il rollout.
Un pass allineato dimostra che il messaggio è sicuro?
Un pass allineato dimostra l'uso autorizzato del dominio From, senza stabilire se il messaggio è desiderato o sicuro.
Un ricevente può rifiutare o mettere in quarantena un messaggio che ha superato il controllo usando le proprie regole di filtraggio. Può anche accettare un messaggio che ha fallito quando altre evidenze supportano la consegna.
L'autorizzazione del dominio e la reputazione del mittente, la valutazione del ricevente sul traffico di un mittente, rispondono a domande diverse. Verifica entrambe quando indaghi sulla consegna.
In breve
L'autenticazione deve corrispondere al dominio visibile.
SPF e DKIM possono passare per domini non correlati, perciò DMARC richiede un pass allineato per il dominio in From.
Ciascuno dei due metodi allineati può fornire un pass.
Una firma DKIM allineata e intatta può preservare un pass DMARC quando l'inoltro interrompe SPF.
Rilassato e rigoroso usano regole di corrispondenza diverse.
L'allineamento rilassato accetta un dominio organizzativo condiviso. L'allineamento rigoroso richiede domini identici.
Scoperta del dominio ed enforcement sono meccanismi separati.
RFC 9989 usa un DNS tree walk per scoprire i confini del dominio. Esclude il tag percentuale inaffidabile dal suo formato di policy.