If the mail is legitimate, the originating server will try again after a delay, and if sufficient time has elapsed, the email will be accepted.
A server employing greylisting temporarily rejects email from unknown or suspicious sources by sending 4xx reply codes ("please call back later"), as defined in the Simple Mail Transfer Protocol (SMTP).
Fully capable SMTP implementations are expected to maintain queues for retrying message transmissions in such cases,[1] and so while legitimate mail may be delayed, it should still get through.
[2] Temporary rejection can be issued at different stages of the SMTP dialogue, allowing for an implementation to store more or less data about the incoming message.
[citation needed] The biggest disadvantage of greylisting is that for unrecognized servers, it destroys the near-instantaneous nature of email that users expect.
Explaining this to users who have become accustomed to immediate email delivery will probably not convince them that a mail server that uses greylisting is behaving correctly.
If the sending MTA of the site is poorly configured, greylisting may delay the initial email link.
In extreme cases, the delivery delay imposed by the greylister can exceed the expiry time of the password reset token delivered in email.
In these cases, manual intervention may be required to whitelist the website's mailserver such that the email containing the reset token can be used before it expires.
[4] SMTP says the retry interval should be at least 30 minutes, while the give-up time needs to be at least 4–5 days;[1] but actual values vary widely between different mail server software.
Since the IP addresses will be different, the recipient's server will fail to recognize that a series of attempts are related, and refuse each of them in turn.