Scegli deliberatamente il modello di verifica del mittente
Per il dominio di un'organizzazione, la verifica del dominio del mittente SMTP2GO è il percorso documentato per l'autenticazione del dominio del cliente. La verifica tramite e-mail singola è un'opzione diversa e non fornisce la stessa cosa SPF E DKIM allineamento. Inizia con i domini e gli indirizzi che le applicazioni utilizzeranno invece di selezionare la schermata di verifica più rapida. Opzioni di verifica SMTP2GO, dominio mittente ed e-mail a mittente singolo.
Elenca le fonti effettive: chiamate API dell'applicazione, client di inoltro SMTP , dispositivi e integrazioni. Registra ogni account o sottoaccount, destinato al dominio e al proprietario operativo. Un dominio condiviso non significa che ogni percorso utilizza le stesse credenziali o configurazione. Includi esplicitamente i percorsi di fallback e non considera la loro consegna riuscita come un test del percorso principale.
SMTP2GO documenta i mittenti verificati come richiesto e registra i tentativi da parte di mittenti non verificati come rifiutati. Il suo annuncio di lancio lo spiega anche percorso di ritorno modello di sottodominio e perché radice esistente Registri SPF non è necessario ampliarlo. Annuncio del mittente verificato SMTP2GO.
Cattura i tre record rilasciati sul conto
In Invio > Mittenti verificati > Domini mittente, aggiungi il dominio desiderato e acquisisci i tre CNAME record. L'insieme documentato copre il percorso di ritorno/funzione SPF , DKIM e tracciamento. Pubblicare i valori attualmente emessi anziché esempi generici. La guida offre modifiche DNS manuali o un flusso DNS automatizzato. Mittenti verificati SMTP2GO, passaggi uno e due.
La guida al dominio del mittente consente ai sottodomini DNS esistenti di inviare sotto un dominio di primo livello verificato. Questa è l'autorizzazione all'invio, non la prova del rigoroso allineamento per ogni sottodominio. Se la policy vieta i CNAME, la guida offre la configurazione TXT / MX su richiesta; ottenere l'alternativa supportata invece di tradurre i record da soli.
Selezionare il metodo attraverso il processo di cambiamento dell'organizzazione. Un flusso automatizzato può richiedere l'accesso al DNS , quindi esamina esattamente quali accessi e modifiche propone prima di concederlo. La pubblicazione manuale dovrebbe comunque utilizzare lo stesso set di record revisionato. Non concedere un accesso più ampio semplicemente per evitare di comprendere un conflitto di nomi.
Per ogni record, salva il proprietario completo, la destinazione e il TTL. Controlla l'uso esistente dei nomi proposti, inclusi altri CNAME, certificati, servizi di tracciamento ed elaborazione della posta. Chiedi all'amministratore dell'account un nome host alternativo supportato in caso di collisione; non inventare un nuovo target né sovrascrivere il servizio esistente.
Mantieni SPF e monitoraggio distinti
Il percorso di restituzione del dominio cliente di SMTP2GO è l'identità SPF pertinente. L'aggiunta di un'inclusione alla policy root aziendale non sostituisce il percorso di ritorno CNAME emesso. Questa distinzione è particolarmente utile laddove la policy root autorizza già diversi servizi non correlati. Mantieni invariate le autorizzazioni esistenti a meno che una modifica esaminata separatamente non lo richieda.
SPF controlla l'identità SMTP utilizzata nella transazione. Le sue regole di valutazione non trasferiscono automaticamente una policy dal dominio Da visibile a un dominio busta diverso. RFC 7208 , sezioni 2.4 e 4.
Il CNAME di tracciamento ha uno scopo separato. SMTP2GO documenta il provisioning del certificato HTTPS per quel nome di tracciamento dopo la verifica. Un problema di tracciamento dovrebbe essere analizzato in modo autonomo e non interpretato come una prova della mancanza della chiave DKIM . Mittenti verificati SMTP2GO, dominio di monitoraggio.
Registrare la verifica del monitoraggio e lo stato del certificato separatamente nel foglio di lavoro. Se la politica sulla privacy o sulle comunicazioni limita il tracciamento, chiedi al proprietario appropriato di rivedere tali impostazioni dell'applicazione. Il lavoro di autenticazione non dovrebbe attivare silenziosamente una funzionalità di analisi non correlata.
Verifica DNS pubblico e l'accesso all'account
Esamina le risposte CNAME pubbliche dal servizio DNS autorevole e confrontale con i record emessi. Conferma che l'editor DNS non abbia aggiunto il dominio due volte o modificato la destinazione. Quando i risultati differiscono tra i server autorevoli, risolvi tale incoerenza invece di ricreare ripetutamente il dominio in SMTP2GO.
La guida del provider supporta la concessione ai sottoaccount selezionati dell'accesso a un dominio verificato nell'account principale. Conferma che l'account secondario di invio effettivo disponga di tale accesso. Non dare per scontato che un dominio visualizzato nell'account principale sia automaticamente utilizzabile ovunque. La guida identifica i domini assegnati nel sottoaccount con un tag Master non modificabile; registrare tale prova per l'effettivo account di invio. Mittenti verificati SMTP2GO, accesso all'account secondario.
Registra quale account possiede il dominio, quali account secondari sono autorizzati e chi può modificare tali autorizzazioni. Per l'uso da parte di clienti o multimarca, conservare l'autorizzazione per il dominio specifico e lo scopo del mittente. Il controllo DNS non stabilisce se una particolare applicazione debba essere autorizzata a inviare dati con quel marchio.
Testare separatamente i percorsi SMTP e API, se utilizzati
La documentazione API tratta l'autenticazione della chiave API e la verifica del mittente come requisiti separati. Una chiave valida da sola non autorizza un'identità Da non verificata. Guida API SMTP2GO, autenticazione e verifica del mittente.
Utilizza contenuti innocui per controllare caselle di posta esterne e inviarli tramite ciascun percorso di materiale. Conserva gli identificatori dell'applicazione, gli orari UTC, gli ID dei messaggi e i record delle attività dei fornitori corrispondenti. Per un dispositivo o un'integrazione, esegui il test da quel dispositivo o integrazione anziché solo dallo script di test separato di uno sviluppatore. Conserva il Da osservato anche se si prevedeva che l'applicazione utilizzasse qualcos'altro.
Al destinatario, registra Return-Path , l'identità e il risultato SPF attendibili, ogni valore DKIM d e s e il DMARC risultato. Ispezionare la chiave pubblica per il file selettore effettivamente utilizzato; un selettore verificato ma non utilizzato non dimostra che il messaggio sia stato firmato con esso. RFC 6376 , sezioni 3.5 e 6.1.
Determina quale dominio autenticato si allinea con il Da visibile. Un percorso di ritorno del sottodominio può soddisfare un allineamento SPF rilassato senza soddisfare un rigoroso allineamento del dominio esatto. Per DMARC è sufficiente un solo meccanismo allineato, sebbene requisiti organizzativi o provider separati possano richiedere entrambi i meccanismi. RFC 9989 , Spiegazione dell'allineamento degli identificatori e valutazione DMARC.
Mantieni la politica DMARC sotto la proprietà del dominio
La pagina di configurazione DMARC di SMTP2GO inserisce la pubblicazione della policy nel DNS del dominio anziché nella piattaforma di invio. Trattalo come una modifica separata a livello di dominio che interessa anche altri mittenti. Guida SMTP2GO DMARC , Come impostare DMARC.
Utilizzare la definizione del protocollo corrente per la decisione di superamento. Alcune parole esplicative del provider comprimono l'autenticazione e la consegna in una storia più semplice; non dovrebbe prevalere sulla distinzione tra allineamento, politica e filtraggio indipendente da parte del ricevente. Non abbassare una politica di applicazione esistente semplicemente per rendere utilizzabile un percorso di posta elettronica singola non verificata.
Se la posta viene rifiutata prima del completamento dell'invio, controlla la verifica del mittente, l'ambito dell'account e l'indirizzo del mittente effettivo. Se il messaggio viene recapitato con un'identità imprevista, controlla le sostituzioni dell'integrazione e la selezione dell'account. Se l'autenticazione viene superata ma il posizionamento dello spam rimane scarso, indagare separatamente sulla reputazione, sulle aspettative del destinatario e sul contenuto. La modifica ripetuta dei CNAME non è un rimedio generale alla consegna.
Documentare il percorso di implementazione e ripristino
Utilizza il dominio SMTP2GO e il foglio di lavoro dell'applicazione (crea un record di revisione separato con i campi descritti qui). Separa le tre funzioni DNS , l'autorizzazione dell'account secondario e la prova del ricevitore specifica del percorso. Registra il motivo preciso per qualsiasi controllo di accettazione non riuscito anziché solo lo stato rosso o verde.
Metti in pausa o reindirizza il traffico delle applicazioni interessate attraverso un percorso approvato e precedentemente testato se l'implementazione non riesce. Conserva i record necessari per la posta in coda e le integrazioni funzionanti. Prima di ritirare un dominio, verifica che nessun dispositivo, account cliente o percorso di fallback dipenda ancora da esso. Ripeti il test dopo aver modificato l'host DNS , l'applicazione Dall'identità o l'accesso all'account secondario.
Caso diagnostico immaginario che coinvolge l'account sbagliato
Solo caso scritto immaginario: S2G-01 presuppone che l'account principale abbia verificato service.example , ma un'applicazione che invia alerts@service.example utilizza un account secondario senza l'allocazione del dominio richiesta e riceve un rifiuto di invio. Non esiste alcun risultato SPF , DKIM o DMARC del destinatario per il tentativo rifiutato. Il proprietario dell'applicazione deve verificare la selezione dell'account e ottenere l'approvazione per l'allocazione del dominio con ambito ristretto, quindi testare lo stesso percorso. Un esempio di conto principale non risolve il problema del conto secondario. Non è stata utilizzata alcuna chiave API, autorizzazione del tenant o messaggio.
L'accettazione resta in sospeso
Accetta solo quando i percorsi effettivi utilizzano il dominio approvato, i record DNS emessi vengono risolti, l'ambito dell'account pertinente viene verificato e i risultati del ricevitore attendibile stabiliscono l'allineamento richiesto. I controlli del tenant in tempo reale, DNS e dei messaggi, l'accettazione dell'ambito originale, la revisione tecnica indipendente, la revisione visiva e l'approvazione della PMI umana rimangono in sospeso per questa bozza non pubblicata.
Separare un messaggio di passaggio dalla disponibilità all'applicazione
RFC 9989 La sezione 7.4 richiede DKIM valido per la pubblicazione di un dominio p=reject e avvertenze sull'interoperabilità della posta indiretta. Un singolo risultato SPF allineato non giustifica di per sé l’implementazione di una politica di rifiuto. Esamina tutti i percorsi legittimi e la proprietà delle policy separatamente dalla configurazione di questo provider.