People in our organization request one-time passwords to open Purview-protected emails, but the first code often arrives after it has expired. Later attempts can arrive faster.
We have an on-premises mail gateway and servers. The sender is allowlisted, and the timestamps appear to show the gateway receiving the message about 30 minutes late. Other mail generally arrives much faster. What should we check next?
Start with the full headers from a delayed code and compare the timestamps in each Received header. That can help locate the gap between mail hops rather than assuming the delay happened at the gateway.
Also compare the headers from a slow attempt with one that arrived quickly. If the gap is before your gateway's first recorded receipt, collect both examples and their request times for the sending service's support team. Headers can narrow down where to look, though they won't necessarily explain every delay.
Check the gateway's connection and SMTP logs, not just the message receipt timestamp. A sender can try to deliver before the gateway accepts the message. A temporary rejection or deferral followed by a later retry would look like late receipt in the message headers.
Look for greylisting or another policy that delays acceptance. The sender being allowlisted doesn't necessarily establish what happened on the SMTP connection.
Don't rule out DNS yet, but treat it as a hypothesis rather than the answer. Check whether the gateway logged lookup failures or timeouts around delayed attempts, and compare those with a fast delivery. The fact that other senders work normally makes a general mail problem less obvious, but doesn't identify the cause.
Answers are reviewed before publication.
Renvor.7p:
Match the logs to the time the code was requested as well as the time it arrived. That gives you a window to look for earlier delivery attempts.