Editoria SPF per example.com non autorizza automaticamente l'utilizzo della posta bounce.example.com come dominio della busta. SPF cerca la policy per l'identità in base alla valutazione RFC 7208 §4.4. Non esiste un fallback generale del dominio principale che trasformi la politica root in una politica ereditata per ogni figlio.
Ciò è importante quando una nuova applicazione introduce una consuetudine percorso di ritorno dominio. L'indirizzo Da visibile può rimanere invariato mentre il dominio rilevante per SPF cambia sotto di esso.
Inizia da un messaggio ricevuto
Ottieni un messaggio ricevuto da un sistema di cui ti fidi. Identificare l' SMTP MAIL DA dominio dall'evidenza del destinatario attendibile e distinguerlo dal campo Da visibile. Per un percorso inverso nullo, la valutazione relativa a HELO richiede un'attenzione separata. Non dare per scontato che il dominio principale sia l'obiettivo solo perché appare nel testo di marketing o nell'interfaccia utente.
Interroga TXT nel dominio esatto da valutare. Registra il nome del proprietario, la risposta e i server autorevoli. Se il sottodominio è delegato a un'altra zona o servizio DNS , collabora con il suo operatore effettivo anziché modificare una voce della zona principale non correlata.
Scegli l’indipendenza esplicita o una politica condivisa
Un bambino può avere la propria politica SPF su misura per i suoi mittenti. Ciò è spesso utile quando la fatturazione, il marketing e la posta operativa utilizzano servizi diversi. Le autorizzazioni potranno poi essere esaminate in maniera indipendente.
Laddove diverse identità necessitano realmente della stessa politica completa, SPF modificatore di reindirizzamento In RFC 7208 §6.1 può centralizzarlo. Ad esempio, la politica sintetica v=spf1 redirect=_spf.example.com nei confronti di un bambino indirizza la valutazione verso un obiettivo politico esplicitamente mantenuto. La destinazione deve pubblicare SPF valido. Il reindirizzamento viene utilizzato quando nessun meccanismo corrisponde; UN Tutto Il meccanismo nel record originale impedisce l'utilizzo del reindirizzamento.
Un'inclusione ha una semantica diversa sotto RFC 7208 §5.2: un passaggio dalla policy inclusa fa sì che l'inclusione corrisponda, mentre gli altri risultati vengono elaborati secondo le regole di inclusione. Non scambiare include e reindirizzare semplicemente perché entrambi fanno riferimento a un altro nome. Scegli in base se stai incorporando un set di mittenti o delegando la decisione politica finale.
Non utilizzare un carattere jolly in sostituzione dell'inventario
Il comportamento dei caratteri jolly DNS è più limitato rispetto a “applicalo a ogni sottodominio”. I nomi esistenti e la struttura ad albero DNS influiscono sull'eventuale esecuzione della sintesi dei caratteri jolly. RFC 7208 §3.5 scoraggia la pubblicazione di caratteri jolly SPF e spiega perché potrebbero essere necessari record aggiuntivi laddove i nomi già esistono.
Per un'identità di invio importante, pubblica una policy gestita esplicita o una delega supportata e verifica quel nome esatto. Un carattere jolly che sembra funzionare per un nome di test non utilizzato non dimostra che un sottodominio dell'applicazione stabilito ottenga la stessa risposta.
Metti alla prova il confine con un esempio concreto
Esempio illustrativo: example.com autorizza l'indirizzo della documentazione 192.0.2.10 , mentre bounce.example.com non ha una politica SPF . Può passare una connessione da 192.0.2.10 utilizzando l'identità root; l'uso dell'identità secondaria non eredita quel passaggio e normalmente non ne produce alcuno quando non sono presenti record applicabili e nessun altro errore di ricerca.
Se il bambino invece autorizza solo 198.51.100.20 con finale -all, una connessione da 192.0.2.10 può fallire per il figlio anche se passa per il genitore. Questa indipendenza è utile: un servizio di marketing non ha bisogno di acquisire le stesse autorizzazioni di mittente della posta dei dipendenti.
Gestisci l'intero ciclo di vita
Prima di aggiungere un sottodominio, assegna un proprietario dell'azienda, un operatore DNS e un set di mittenti previsti. Conservare la policy approvata e le istruzioni di ripristino. Dopo la pubblicazione, testa i nuovi messaggi utilizzando l'esatto dominio della busta e registra sia il risultato SPF che eventuali risultati separati allineamento valutazione richiesta dal progetto di autenticazione più ampio.
Al momento del pensionamento, controlla se il sottodominio offre ancora lavori ritardati o elaborazioni di rimbalzo. Non rimuovere una destinazione di reindirizzamento condivisa finché tutti i dipendenti non sono stati esaminati. L'inventario del dominio figlio è completo quando ciascuna identità SMTP utilizzata dispone di una policy intenzionale e di un proprietario denominato, anziché presupporre che sia coperta dal genitore.
Utilizzare le prove per prendere una decisione
Per un'ipotetica implementazione della fatturazione, registrare il nome MAIL FROM effettivo del bambino, il suo operatore DNS , la politica esatta e l'identità di prova. Se la posta principale passa ma la posta secondaria non restituisce nessuno, controlla la ricerca secondaria anziché aggiungere più intervalli al genitore. Per le destinazioni di reindirizzamento condivise, conservare un elenco di identità dipendenti e testare i casi negativi nonché i mittenti previsti. Nessuna delega o policy DNS è stata modificata.