Un correu retardat és diferent d’un de perdut. Com que finalment arriba, les capçaleres acostumen a mostrar en quin traspàs ha esperat: WordPress, cua, proveïdor d’enviament, gateway receptor o regla de bústia.
Conserva una capçalera completa d’una prova innòcua i construeix una línia temporal.
Registra quatre moments
Anota:
hora d'enviament al navegador
hora d'entrada o log a WordPress
hora d'acceptació del proveïdor
hora de lliurament a la bústia finalControla les zones horàries. Les capçaleres Received apareixen ordenades i poden usar offsets diferents. No publiquis capçaleres completes perquè revelen adreces i infraestructura.
Confirma també que el rellotge del servidor estigui sincronitzat.
Comprova si WordPress ha posat l’avís a la cua
Alguns connectors envien immediatament; altres utilitzen WP-Cron, Action Scheduler o una cua externa. Revisa les accions pendents o fallides, la programació i els intents.
Un web amb poc trànsit pot executar WP-Cron tard quan arriba un altre visitant. Un cron de sistema desactivat deixa missatges esperant.
No eliminis cues sense classificar: poden contenir comandes, subscripcions o altres avisos.
Inspecciona els esdeveniments del proveïdor SMTP
Cerca el missatge per ID, destinatari i hora. Distingeix accepted, queued, deferred, delivered, bounced o suppressed.
El proveïdor pot acceptar immediatament i ajornar perquè el servidor receptor respon temporalment 4xx. Desa la resposta exacta. Comprova límits del compte i backlog sense exposar correu d’altres clients.
Llegeix la ruta final del missatge
Les capçaleres completes mostren cada salt Received i l’hora. Localitza la diferència més gran entre dos salts consecutius.
Si el reté l’emissor, repara la cua, autenticació o capacitat. Si el gateway receptor el demora després d’acceptar, aquell administrador és responsable del salt.
No utilitzis només Date: l’aplicació pot establir-la molt abans de l’enviament real.
Considera greylisting i reputació
Alguns receptors rebutgen temporalment un remitent nou i accepten el reintent. Un proveïdor SMTP correcte reintenta automàticament.
Errors SPF, DKIM o DMARC, mala reputació o un pic de volum augmenten els ajornaments. Corregeix autenticació i comportament; no reenviïs moltes proves idèntiques.
Demana a l’administrador receptor que rastregi el message ID i la resposta temporal.
Comprova el filtratge posterior
El missatge pot arribar a l’organització però esperar en moderació, quarantena, regla de transport o helpdesk. Compara l’hora del gateway amb la visibilitat a la safata.
Revisa reenviaments, bústies compartides i connectors. Un retard posterior a l’acceptació SMTP final no és un problema de PHP. Prova un segon destinatari controlat.
Repara i torna a mesurar
Corregeix el runner de cua, timeout, límit, autenticació o regla receptora demostrats. Conserva el rollback.
Envia una prova etiquetada i compara de nou els quatre moments. Confirma que l’entrada es desa a l’instant i que vendes la rep dins de l’objectiu. Monitoritza diversos esdeveniments no sensibles.
Defineix què significa «tard»
Fixa un llindar realista. Un lead comercial que s’ha d’atendre en cinc minuts no és igual que un informe setmanal. Desa l’hora a WordPress i inclou-la a la notificació per distingir un correu tardà d’una resposta tardana.
Durant el diagnòstic, permet a l’equip autoritzat revisar entrades o utilitza un canal alternatiu. No afegeixis cadenes de reenviament com a pedaç: cada sistema suma una cua i un filtre.
Si només passa en hores punta, compara-ho amb els recursos del hosting i el throttling del proveïdor.
Quan cal demanar ajuda
Demana una avaluació si les capçaleres mostren buits llargs, les cues reapareixen o només falla un domini. Facilita temps redactats, message ID i resposta SMTP, no contingut ni credencials.
Un diagnòstic útil identifica el salt que espera i el seu propietari, en lloc de recomanar un altre connector sense evidències.