Identificare il trasporto prima di modificare DNS
Un evento WordPress non identifica il suo provider di posta in uscita. Reimpostazione della password dell'inventario, moduli di contatto, notifiche degli ordini ed eventuali newsletter. Per ciascuno, registra il plug-in o l'applicazione che lo genera, il relativo indirizzo Da e se un'integrazione SMTP o API configurata sostituisce il percorso predefinito. Salvare l'originale ricevuto e le impostazioni di trasporto correnti prima di apportare modifiche.
WP Engine consiglia un host di posta elettronica di terze parti per funzionalità di posta più potenti e afferma che non fornisce MX o DKIM valori per l'hosting della posta elettronica. La sua guida all'invio documenta anche le limitazioni del servizio predefinito. Non promettere un dominio cliente WP Engine universale Selettore DKIM. Invio di e-mail su WP Engine.
Scegli la configurazione specifica del percorso documentata
Per il relè WordPress predefinito, la guida di autenticazione di WP Engine identifica MailChannels e i documenti include:relay.mailchannels.net in SPF. Unisci quel meccanismo solo dove è appropriato per il dominio della busta effettivo e il percorso corrente. Conserva gli altri mittenti richiesti nella policy esistente. Un meccanismo copiato SPF del dominio Da visibile non viene stabilito allineamento quando la busta utilizza un dominio diverso. Record di posta del motore WP.
Per un servizio SMTP o API esterno, ottieni le istruzioni attuali per la verifica del dominio, DKIM e la busta da tale servizio. Configura l'integrazione di WordPress utilizzando il trasporto supportato. WP Engine documenta che la porta 25 non è disponibile ed elenca le alternative consentite; verificare che il servizio scelto e le impostazioni di crittografia siano supportati. Guida all'invio di WP Engine.
Non modificare il routing MX in entrata semplicemente per inviare notifiche al sito Web. Allo stesso modo, una modifica al record A del sito Web non dovrebbe spostare accidentalmente un nome host di posta che segue il sito Web tramite un alias. Mantieni coinvolto il proprietario della casella di posta in entrata se è pianificata una migrazione DNS , ma separa tale migrazione da questa attività di autenticazione in uscita.
Utilizza un'identità che il sito è autorizzato a inviare
Per i moduli di contatto, rendi visibile Da un dominio controllato dalla tua organizzazione e autenticato con il servizio di invio effettivo. Inserisci l'indirizzo del visitatore in Reply-To quando l'applicazione supporta tale disposizione. Consideralo come un consiglio sulla progettazione dell'applicazione, non come un'affermazione sul comportamento predefinito di un particolare plug-in. Il dominio esterno di un visitatore non è tuo per l'autenticazione.
Ottieni i valori DKIM dal firmatario reale. La pubblicazione di una chiave creata autonomamente nel DNS non può creare un segnale di inoltro con la chiave privata corrispondente. Allo stesso modo, l'aggiunta di un'inclusione SPF generica non può riparare DKIM assente o non allineato. Verifica la politica SPF completa per il dominio della busta valutato, incluso il budget di ricerca, prima di distribuire un record unito. SPF, DKIM.
Attiva gli eventi WordPress effettivi
Utilizza un account di prova controllato e destinazioni non cliente. Testa l'evento, non solo il pulsante di connessione del plug-in SMTP . Conserva insieme il timestamp, l'evento dell'applicazione, il trasporto configurato, la risposta del fornitore e l'originale ricevuto.
- Evento: reimpostazione della password; Distinzione importante: percorso generato dall'applicazione rispetto al test del plug-in; Prova di accettazione: consegna originale ricevuta e prevista con successo
- Evento: modulo di contatto; Distinzione importante: risposta del visitatore e mittente approvato; Prova di accettazione: allineamento del mittente autenticato e destinazione della risposta corretta
- Evento: notifica dell'ordine; Distinzione importante: flusso di lavoro della transazione rispetto al test manuale; Prova di accettazione: evento di prova innocuo attraverso lo stesso trasporto
- Evento: lavoro pianificato; Distinzione importante: esecuzione in background e invio interattivo; Prova di accettazione: traccia del messaggio e del provider per il percorso pianificato
Questa è una matrice di accettazione sintetica, non un test WP Engine eseguito. Su ogni originale, controllare il dominio della busta e ciascuna coppia DKIM d= e s= rispetto ai risultati del ricevitore attendibile. Un metodo di autenticazione passante deve anche essere allineato con il Da visibile per essere soddisfatto DMARC. Una connessione al plug-in riuscita non dimostra questo risultato. DMARC.
Recupera il percorso, non l'intero dominio
Se non arriva alcun messaggio, separare la generazione dell'applicazione, l'invio del trasporto e l'accettazione del destinatario prima di modificare DNS . Se viene utilizzato il percorso sbagliato, rivedere la precedenza del plug-in o la configurazione dell'applicazione. Se l'autenticazione fallisce, controlla il firmatario esatto o il servizio di busta anziché dare per scontato che l'host web fornisca ogni record.
Metti in pausa un flusso di lavoro in errore o ripristina il trasporto precedentemente approvato preservando i flussi di lavoro. Evita un fallback che invia silenziosamente la posta del cliente non autenticata. Testa nuovamente ogni evento interessato dopo la riparazione e rimuovi le credenziali inutilizzate e le autorizzazioni DNS quando un servizio esterno viene ritirato tramite il processo di modifica autorizzata. Tieni i segreti lontani dagli artefatti diagnostici. Per questa guida documentaria non è stato effettuato alcun sito Web, account fornitore, evento messaggio o modifica DNS .
Conferma il limite del provider
L'attuale guida all'invio elenca 2525 come consigliato e 587/465 come alternative consentite, con Microsoft 365 limitato a 587 in tale guida. Utilizza le impostazioni di crittografia e trasporto supportate dal provider selezionato, non un cambio di porta indovinato. WP Engine non pubblica il suo esatto limite orario predefinito e descrive una diagnostica di posta lato server limitata; non promette una capacità di invio numerico o log che non sono stati ottenuti.
Elaborare un caso diagnostico immaginario
Solo caso scritto immaginario: WPE-01 presuppone che un test del plug-in SMTP da site@museum.example passi con d=museum.example, ma il modulo di contatto invia Da visitor@outside.example attraverso un trasporto sconosciuto. La busta del modulo e le firme sono sconosciute. Il proprietario del sito web deve mappare il trasporto effettivo dell'evento e utilizzare un mittente organizzativo approvato con una risposta separata per il visitatore, ove supportato. Il risultato del plugin non può stabilire l'autenticazione del modulo o autorizzare il dominio del visitatore. Nessun account, DNS , CRM, fattura, campagna o consegna è stato testato in questo caso.
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.