Utilizza il flusso di lavoro del servizio avanzato per il dominio del mittente effettivo
Il servizio di recapito e-mail avanzato di Sage Intacct dispone di un flusso di lavoro del dominio che include record DNS generati dall'account e una fase di convalida separata. Inizia con la comunicazione finanziaria che l'organizzazione deve inviare, ad esempio una fattura controllata o un test di notifica di pagamento, quindi identifica il dominio del mittente previsto. Non dare per scontato un vecchio SPF l'autorizzazione o la chiave del mittente dell'e-mail dimostrano che il percorso avanzato è pronto. Questa guida riguarda la registrazione del dominio, la revisione dei record e l'accettazione a livello di messaggio, con la verifica dell'account live ancora in sospeso.
Il corrente guida alle impostazioni del dominio dice esplicitamente che i domini principali e i sottodomini necessitano di un'autenticazione separata. Distingue inoltre Autenticato da Convalidato: il primo richiede ancora la convalida prima che l'invio autenticato sia pronto. Utilizza queste istruzioni del flusso di lavoro anziché interpretare come completamento un nome di dominio familiare o un'e-mail precedente riuscita. Le descrizioni generiche dei campi della stessa pagina menzionano anche l'invio da sottodomini; poiché tale formulazione differisce dalle sue esplicite istruzioni di autenticazione separata, risolvi qualsiasi ambiguità specifica del tenant con Sage piuttosto che assumere l'autenticazione del sottodominio ereditata.
Inventariare gli indirizzi dei mittenti utilizzati da ciascuna azienda e flusso di lavoro pertinenti. Registra quale amministratore possiede la configurazione, quale persona può modificare DNS e chi può approvare un innocuo test del sistema finanziario. Evita di inviare fatture reali o istruzioni di pagamento esclusivamente per testare l'autenticazione. Un test dovrebbe esercitare il percorso di applicazione reale utilizzando destinatari controllati e contenuti campione non sensibili.
Stabilisci la proprietà dell'azienda e della console prima della modifica
Apri Azienda, Configurazione, Azienda, quindi la scheda Sicurezza e le impostazioni del dominio del mittente dell'e-mail, come descritto nella guida del provider. Verifica quale azienda o Console possiede la configurazione del dominio. La documentazione attuale descrive l'ereditarietà gestita dalla console, quindi un dominio mostrato in un'azienda può essere gestito più in alto nella gerarchia. Non creare configurazioni duplicate a livello aziendale né rimuovere record prima di identificare il proprietario.
Registrare l'esatto stato visualizzato e la data. Se l'account differisce dalle istruzioni pubbliche, fermati alla mancata corrispondenza e chiedi all'amministratore autorizzato o al supporto Sage il flusso di lavoro corrente. Un articolo di prodotto non può stabilire le autorizzazioni o la gerarchia del tenant dell'organizzazione. Mantieni distinguibili le impostazioni ereditate, le impostazioni aziendali autonome e i record precedenti nella richiesta di modifica.
Pianificare il rollback con il proprietario finanziario. Sospendere un test è diverso dall'interrompere l'esecuzione di una fattura e la modifica di un mittente può influire sul riconoscimento del cliente o sulla gestione delle risposte. Conserva la configurazione precedentemente approvata e scegli una finestra che eviti attività di fatturazione critiche. La pulizia dell'autenticazione non dovrebbe cambiare silenziosamente chi sembra aver inviato una notifica finanziaria.
Generare e conservare la tabella dei record specifici del dominio
Per un nuovo dominio approvato, utilizza il flusso di lavoro documentato di aggiunta e autenticazione e salva la tabella DNS generata per quel dominio. La guida pubblica descrive una tabella con un SPF CNAME, due DKIM CNAME, voci TXT di sicurezza del mittente e una voce SPF legacy per compatibilità. Copia i proprietari, i tipi di record e i valori effettivi dell'account. Nessun campione selettore, il valore del token lungo o dello screenshot in questo articolo è una configurazione riutilizzabile.
Conserva la tabella generata con il ticket di modifica e annota lo scopo di ciascuna riga. Distinguere il proprietario SPF delegato del servizio avanzato dalla policy SPF precedente nel dominio principale. Tratta il valore TXT di verifica aziendale come un record a sé stante anziché ripiegarlo in una stringa SPF . Diversi controlli possono condividere la zona DNS senza condividere una sintassi o uno scopo operativo.
IL Guida alla convalida DNS spiega il controllo delle alternative di sicurezza del mittente e nota che una di queste voci è sufficiente per il controllo descritto. Conferma la scelta appropriata rispetto alla tabella generata, in particolare per la configurazione gestita dalla console. Preservare l’incertezza se il conto effettivo richiede una disposizione diversa; non utilizzare un esempio per sovrascrivere le istruzioni correnti.
Pubblica record preservando i servizi di posta esistenti
Esporta prima i record DNS interessati. Confronta ogni proprietario rilasciato con i record e le deleghe esistenti. Un conflitto CNAME richiede la risoluzione supportata da un amministratore, non un secondo record di altro tipo presso lo stesso proprietario. Controlla se l'editor DNS prevede un'etichetta relativa o un nome completo e verifica il nome pubblico risultante dopo il salvataggio. La risposta finale DNS è la prova che conta.
Laddove la voce SPF di compatibilità con le versioni precedenti richieda una modifica a una politica esistente, rivedere la politica completa di seguito RFC 7208. Mantieni una policy SPF presso il proprietario valutato, preserva gli altri mittenti attivi e tieni conto dei termini di query DNS nidificati. Non incollare un ulteriore Registro SPF accanto a quello esistente. Non rimuovere l'autorizzazione legacy semplicemente perché sono presenti i record migliorati; stabilire innanzitutto se eventuali flussi di lavoro live dipendono ancora da esso.
Mantieni i record pubblici separati dalle credenziali e dai segreti dell'applicazione. La tabella DNS è adatta per l'amministratore DNS autorizzato, ma un pacchetto di prove non necessita di esportazioni illimitate di tenant o di dati dei clienti. Elimina i dettagli delle transazioni non necessari preservando un contesto sufficiente per associare un test al flusso di lavoro e all'azienda.
Controllare i proprietari emessi e completare la convalida
Controlla il proprietario e la destinazione esatti di ogni CNAME , quindi verifica che la ricerca delegata si risolva come previsto. Controlla DKIM utilizzando i selettori effettivi mostrati nella tabella generata. La guida di convalida del fornitore contiene formati di selezione illustrativi; copiare questi esempi in un tenant diverso non è un test valido. Registra il tempo di ricerca, il sistema di risoluzione e il valore restituito in modo che un revisore successivo possa distinguere i dati non aggiornati da un errore di trascrizione.
Torna al dominio selezionato nelle impostazioni del dominio del mittente dell'e-mail e utilizza Convalida dominio. Conserva lo stato o l'errore risultante. Le cache DNS e i controlli del provider possono ritardare il riconoscimento, quindi evita di rigenerare ripetutamente la configurazione mentre i record sono ancora in fase di definizione. Se la convalida fallisce, confronta prima i nomi, i tipi e i valori pubblicati, quindi esamina la riga precisa che non è risolta.
Uno stato Convalidato è un'utile prova di registrazione, ma non dimostra che la fattura o la notifica prevista utilizzasse tale identità. Mantieni il successivo test a livello di messaggio come un cancello separato. Un amministratore dovrebbe essere in grado di mostrare sia la disponibilità del dominio sia il risultato del destinatario per un messaggio rappresentativo dal flusso di lavoro aziendale.
Verifica i messaggi finanziari su un ricevitore esterno controllato
Attiva un test autorizzato da ogni azienda materialmente diversa o flusso di lavoro di invio. Salva l'ID messaggio, l'ora UTC, il mittente previsto e l'azione dell'applicazione che ha prodotto il messaggio. Registra anche dove va la risposta. Un indirizzo di risposta può essere importante dal punto di vista operativo senza essere il dominio valutato da SPF o firmato DKIM .
Esaminare i risultati dell'autenticazione attendibile del sistema ricevente. Registra il visibile Da, Return-Path e ogni DKIM d= dominio di firma e s= selettore. RFC 6376 definisce la relazione tra i campi DKIM e la chiave di verifica DNS . Un controllo DNS riuscito per un selettore configurato non stabilisce che il messaggio lo abbia utilizzato; la firma effettiva risolve questa domanda.
Sotto RFC 9989, DMARC richiede un risultato SPF o DKIM superato con la relazione appropriata con il dominio Da. Applica la configurazione del dominio allineamento modalità e registrare quale meccanismo fornisce il passaggio allineato. Una notifica di pagamento che arriva in una casella di posta non dimostra l’allineamento e l’autenticazione non dimostra l’accuratezza o la legittimità di un’istruzione finanziaria. Questi sono controlli aziendali separati.
Esaminare gli errori utilizzando sia l'applicazione che le prove del messaggio
Se non arriva alcun messaggio di prova, verificare se l'applicazione ha tentato di inviarlo prima di cambiare DNS . Conservare la voce o l'errore pertinente nella cronologia di consegna. La guida del dominio identifica diverse visualizzazioni della cronologia a seconda dello stato di validazione del dominio; utilizzare la visione appropriata a quello stato piuttosto che interpretare una visione vuota come prova che non è successo nulla.
Se il messaggio arriva con un mittente imprevisto, riconcilia la selezione del mittente del flusso di lavoro con l'inventario del dominio autenticato. Se DKIM è assente o non funziona, confronta il selettore effettivo e la risposta pubblica e controlla se un gateway downstream ha modificato il messaggio. Se SPF supera ma DMARC fallisce, esaminare l'allineamento. Un'ulteriore autorizzazione root non riparerà ogni mancata corrispondenza del dominio busta.
Effettuare l'escalation con l'identificatore della società o della console, lo stato del dominio, le righe DNS interessate, il tempo del test e le prove di autenticazione oscurate. Mantieni i dettagli finanziari reali del cliente fuori dall'esempio di supporto. Conserva la politica DMARC esistente a meno che il suo proprietario non approvi una modifica più ampia che copra tutti i mittenti legittimi.
Foglio di lavoro del dominio Sage Intacct
- Proprietario dell'azienda o della console e amministratori responsabili: ____.
- Flusso di lavoro aziendale, mittente previsto e casella di posta di risposta: ____.
- Dominio principale o sottodominio registrato separatamente: ____.
- Riferimento della tabella DNS generata e data dell'istruzione: ____.
- Delega SPF avanzata ed entrambi i controlli dei record DKIM : ____.
- Scelta della sicurezza del mittente e revisione delle dipendenze SPF legacy: ____.
- Stato del dominio visualizzato prima e dopo la convalida: ____.
- Test ID messaggio, ora UTC e riferimento cronologia consegne: ____.
- Osservato da, Return-Path , identità DKIM e risultato allineato: ____.
- Eccezioni, recupero approvato e revisore: ____.
Esempio immaginario di fermarsi allo stato sbagliato
Solo caso scritto immaginario: SI-01 presuppone che il dominio example.org principale sia convalidato nella console proprietaria, ma il flusso di lavoro della fattura intende From invoices@billing.example.org . La registrazione per billing.example.org è sconosciuta e non esistono risultati ricevuti. L'amministratore finanziario deve verificare il sottodominio autenticato separatamente e il flusso di lavoro effettivo prima di programmare il test innocuo; lo stato del dominio principale non può stabilire la copertura. Se lo stato visualizzato è solo Autenticato, completare prima la convalida DNS . Non è stata controllata alcuna fattura, inquilino o transazione reale.
Conservare i restanti cancelli di rilascio
L'attuale ispezione degli inquilini, la revisione dei record generati, DNS in tempo reale e la verifica delle intestazioni, la revisione visiva e l'approvazione delle PMI umane rimangono in sospeso. Risolvere eventuali discrepanze tra la documentazione pubblica e l'azienda effettiva o la Console prima della pubblicazione. Questo articolo è una bozza di implementazione non pubblicata, non una conferma che i messaggi finanziari di un'organizzazione sono pronti per la produzione.
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.