SMTP "451 4.7.1 Greylisting in action, please try again later"

What’s actually happening

First message to a recipient sits in your mail queue instead of bouncing. The log shows a 451 with a "try again" instruction and a delay in seconds or minutes. After the delay your server retries and the message delivers normally. Real spam often never retries, which is the whole point of the tactic.

Common causes

• The recipient's server has never seen your sender-IP / MAIL FROM / RCPT TO triplet before and defers it on purpose
• Your sending IP is new or rotated, so every triplet looks first-seen and gets greylisted
• A sending setup that doesn't honor retries — a script firing raw SMTP once, or a misconfigured relay — gives up after the first 451
• Sending through a pool of IPs (some hosted senders, some load balancers) so the retry comes from a different IP than the original and resets the greylist clock
• Retry interval set longer than the recipient's greylist window expires, so the entry is purged and the next attempt is treated as first-seen again

How to fix it

1. Wait and let your MTA retryPostfix, Exim, and Sendmail all retry deferred mail automatically. Check the queue with `postqueue -p` (Postfix) or `exim -bp` (Exim). Most messages clear within 5-15 minutes with no action.
2. Pin outbound mail to a stable IPIf you send from a pool, configure a single consistent source address so the IP half of the triplet stays constant across retries. In Postfix set `smtp_bind_address`; on a NAT gateway lock the egress IP.
3. Tighten the retry intervalMake your minimum retry shorter than typical greylist windows. In Postfix lower `minimal_backoff_time` (e.g. `300s`); in Exim set `retry` rules with a short first interval so you re-attempt before the recipient purges the triplet.
4. Authenticate so recipients can whitelist youPublish SPF, DKIM, and DMARC. Many greylisting implementations skip the delay for senders that pass authentication or appear on known-good lists, so proper records often make the 451 disappear entirely.
5. Confirm the deferral actually clearsTail the log (`grep RCPT /var/log/mail.log` or your provider's delivery log) and verify the second attempt returns 250. If you keep getting 451 on every retry, the problem is IP rotation or a too-long retry gap, not greylisting itself.