Email Greylisting: Retry Behavior, Queue Timing and Troubleshooting

Anil Jalela · Published Mar 5, 2026 · 13 min read

Greylisting temporarily rejects an unfamiliar SMTP attempt and expects a standards-compliant sender to queue and retry. It is not a permanent block and should normally return a 4xx response such as 451. The technique can reduce opportunistic abuse, but poorly tuned state, retry windows or clustered storage can delay legitimate mail. Both receiving and sending teams need full response text, queue evidence and timing.

Understand the state key and lifecycle

A common implementation records a triplet of source IP, envelope sender and envelope recipient. The first unfamiliar combination receives a temporary deferral. A retry after the minimum delay and within the acceptance window is allowed, and the tuple can remain trusted for a defined period. Implementations may use network prefixes, sender domains or reputation to reduce churn.

Because large senders use pools and changing envelope senders, exact triplets can create repeated delays. Document the key used by the actual product.

Return the correct SMTP class

451 4.7.1 Temporary greylisting; please retry later

Use a temporary 4xx reply while retry can succeed. A 5xx tells the sender the failure is permanent and should not be retried. Provide an enhanced status code, stable explanatory text and support reference without exposing internal state.

Accept or reject at an appropriate SMTP stage and avoid accepting DATA only to generate a later bounce to a forged sender.

Sender-side retry behavior

A compliant sender queues a 4xx recipient and retries with backoff until acceptance or queue expiry. It must not retry continuously, create a duplicate message per attempt or convert the response to a hard bounce. Track next attempt, attempt count, last reply, remote host and oldest age.

Try other eligible MX hosts according to SMTP behavior, but do not use failover to evade a consistent receiver policy. Alert when a provider-specific greylisting delay exceeds the normal baseline.

Receiver-side tuning

Use narrow evidence-based bypasses

Bypass can use authenticated internal systems, stable trusted partners or reputation systems with clear ownership. Avoid permanent manual allowlisting of broad cloud ranges. Require expiration, documented reason and review. Authentication pass alone does not make arbitrary mail wanted, but it can be one input to a mature policy.

Emergency bypass for password resets or healthcare notices should be scoped to the receiving domain and sender route, then removed after root cause is fixed.

Troubleshoot recurring delay

1. Capture the complete 451 reply and exact timestamps.
2. Confirm the sender queued and retried rather than bouncing.
3. Check whether retry used a different IP, sender or recipient key.
4. Verify all receiving nodes share or consistently route state.
5. Inspect minimum delay, expiry and database health.
6. Compare accepted retry timing with normal baselines.

If the receiver returns 451 for days regardless of correct retries, the problem is no longer normal greylisting and needs operational repair.

Understand greylisting as temporary SMTP rejection

A greylisting receiver temporarily rejects a first attempt, commonly using a triplet or related state derived from connecting IP, envelope sender and recipient. A compliant sender queues and retries later. Once the retry satisfies receiver policy, delivery can proceed and future attempts may be recognized for a period.

Not every 4xx is greylisting. Preserve the complete response and receiving MX.

Know which changing identities can defeat recognition

illustrative greylist key:
  normalized_source_ip_or_prefix
  envelope_sender_or_domain
  recipient

receiver may also consider:
  HELO, ASN, reputation, authentication,
  time since first attempt and local exceptions

Implementation differs. If retries use another outbound IP, return path or recipient routing, the receiver may see a new tuple and defer again. Large pools need stable destination routing or receiver-aware state; do not pin permanently without failover planning.

IPv6 receivers may aggregate by prefix rather than individual address. Do not assume an exact public algorithm.

Configure sender retries for temporary failures safely

Use the MTA’s standards-compliant queue scheduler with increasing delay and jitter. Retain the same envelope identities and a stable route where practical. Track first attempt, each reply, next attempt, final acceptance and queue expiry per recipient.

greylist_event(
  queue_id, recipient_id, receiver_org, remote_mx,
  outbound_ip, envelope_domain, reply,
  attempt_number, attempted_at_utc, next_attempt_at_utc,
  final_outcome
)

Immediate rapid retries waste capacity and can look abusive. A delay that is too long harms latency. Tune from actual receiver responses and queue SLOs, not a copied universal interval.

Distinguish greylisting from reputation and system deferrals

Normalize reply families but retain raw text and parser version.

Operate greylisting on a receiving MTA without excessive harm

Use temporary replies only when the system can recognize valid retries and retain state reliably. Define tuple normalization, initial delay, state expiry, allow/exception controls and resource limits. Consider established authenticated/reputable senders and time-sensitive mail under a documented policy.

Greylisting is one abuse control, not a substitute for authentication, content scanning or rate limiting.

Measure the operational cost of greylisting

Track unique recipients deferred, attempts until acceptance, time-to-accept, queue bytes, oldest age and business expiry by receiver. Reply events alone exaggerate impact because one recipient can be deferred repeatedly. Separate true first-attempt greylisting from later provider pressure.

accept_delay = final_accept_at - first_attempt_at
retry_amplification = smtp_attempt_events / unique_recipients
greylist_recovery_rate = recipients_eventually_accepted
                         / recipients_first_greylisted

Publish p50/p95 delay and expired messages. A high eventual acceptance rate can still violate security-code or event-reminder usefulness.

Keep retries stable across an outbound IP pool

Hash receiver organization or tuple to a healthy route within an approved pool so retry identity is reasonably stable. The design needs bounded failover: if an IP fails, mail must move rather than remain trapped. Record route version and do not use greylisting as a reason to ignore provider throttling.

On shared ESPs, request evidence that queue retries preserve appropriate identity. Customers cannot fix pool routing by repeatedly resubmitting campaigns, which creates new queue IDs and may restart greylisting.

Keep aligned DKIM stable even when the IP changes so receiver identity and later authentication remain accountable.

Worked case: a rotating pool creates an endless first attempt

A transactional platform uses six outbound IPs with random selection on each retry. A corporate receiver greylists based on source IP, envelope domain and recipient. Every retry arrives from a different IP, creates a new tuple and receives another 4xx. The message expires despite all hosts being healthy.

Operators preserve replies and route logs, then implement stable receiver-aware hashing with failover. They do not hard-code the recipient to one failed server forever. A controlled test shows the second attempt using the stable tuple is accepted after the receiver delay.

Monitoring adds attempt count, route changes and time-to-accept. The issue was not content or recipient validity; it was sender retry identity.

Prevent retry logic from becoming an abuse amplifier

Cap attempts, apply jitter, deduplicate recipients and stop at business/queue expiry. A malicious receiver or network failure must not hold unlimited sender storage. Sanitize remote response text before dashboards and never execute URLs/commands found in replies.

Greylisting troubleshooting checklist

1. Capture the complete temporary reply and MX.
2. Confirm reply class and likely greylist wording.
3. Trace outbound IP, envelope identities and recipient per retry.
4. Measure elapsed delay and route stability.
5. Separate provider pressure/system errors.
6. Correct scheduler or pool routing without rapid resubmission.
7. Verify controlled retry and final acceptance.
8. Monitor queue age, expiry and recurrence.

Contact the receiver only after evidence shows compliant retries remain deferred beyond its documented/observed behavior.

Design and monitor a greylist state store

Store normalized tuple, first seen, last attempt, pass state, expiry and policy version. Bound cardinality and memory/disk. Use monotonic time for delays and clear behavior for clock changes. Replication/failover must not forget every tuple and re-greylist established traffic unexpectedly.

greylist_state(
  tuple_hash, first_seen_at, last_seen_at,
  attempt_count, eligible_after,
  passed_at, expires_at, policy_version
)

Protect the store from untrusted raw strings and enumeration. Monitor insert rate, hit/pass rate, expiry, latency and capacity.

Use exceptions from accountable evidence, not broad allowlists

Receivers may bypass greylisting for authenticated, established or locally critical senders. An exception needs exact identity, business reason, owner, expiry and abuse monitoring. IP-only exceptions are risky for shared/reassigned infrastructure.

Greylisting bypass does not bypass spam, malware, authentication or recipient checks.

Observe common MTA queue behavior without copying unsafe configuration

# Read-only operational examples; paths vary by system
postqueue -p
postcat -q QUEUE_ID
journalctl -u postfix --since "2026-08-29 10:00:00"

# Inspect complete remote 4xx, attempt time, recipient and next retry.
# Do not force-flush the full queue repeatedly.

Use system-specific commands under authorization. A manual queue flush can restart greylisting tuples, overload receivers and obscure the scheduler’s behavior. Inspect a controlled queue ID and verify configuration through the maintained MTA documentation.

Separate acceptable anti-abuse delay from service failure

A receiver should measure legitimate p95 delay before deploying policy broadly. A sender should cancel obsolete mail instead of delivering after relevance expires.

Handle a greylisting incident at sender or receiver

1. Preserve reply, tuple components, MX, attempts and times.
2. Confirm it is temporary and likely greylisting.
3. Check route/identity stability and queue scheduler.
4. At receiver, check state-store health and policy release.
5. Contain retry storms; do not force queue flush.
6. Correct state/routing and run controlled retry.
7. Measure eventual acceptance and delay.
8. Add regression and capacity monitoring.

Do not disable all anti-abuse controls because one tuple fails. Correct the precise boundary.

Test greylisting safely in a controlled SMTP lab

Simulate first-attempt 451, retry before eligibility, retry after eligibility, route-IP change, envelope change, state expiry, receiver restart and permanent recipient rejection. Assert next-attempt scheduling, jitter, tuple persistence, no 5xx retry and final queue disposition.

expected sequence:
  attempt 1 at T0          -> 451 temporary
  no retry before policy
  attempt 2 at T0 + delay  -> 250 accepted
  queue recipient complete exactly once

Never load-test public receivers. Use a lab or approved staging service and preserve fixture versions.

Greylisting production checklist

• Preserve full temporary replies.
• Keep tuple identity stable where practical.
• Use bounded jittered MTA retry.
• Separate greylisting from rate/reputation/system errors.
• Monitor unique recipients, attempts and accept delay.
• Bound receiver state and define safe failure.
• Scope exceptions with ownership/expiry.
• Protect time-sensitive business expiry.
• Test restart, pool routing and recovery.

Separate greylisting from connection tarpitting and rate control

Greylisting returns a temporary failure and expects a later transaction. Tarpitting slows the current SMTP conversation. Rate limiting restricts sessions or recipients. Reputation deferrals apply policy based on observed behavior. These controls can coexist, but sender logs and operator actions differ.

Troubleshoot greylisting when an ESP owns the MTA

Request the connecting IP for each attempt, timestamps, complete replies, retry schedule, envelope domain and final outcome. The customer’s application event does not show whether the ESP preserved route identity. Do not resubmit the campaign through the API; that can create a new queue item and restart attempts.

Ask whether shared-pool retries use stable destination routing and how failover behaves. Provide a controlled recipient and message ID. If the ESP cannot expose evidence, document the visibility gap when selecting a provider.

Do not request broad receiver allowlisting merely because the provider rotates many addresses.

Monitor receiver greylisting effectiveness and false delay

receiver_daily(
  policy_version, first_time_tuples,
  temporary_rejections, passed_retries,
  expired_without_retry, state_store_errors,
  p50_retry_delay, p95_retry_delay,
  exception_hits, abuse_outcomes
)

Measure whether abusive senders retry too; modern bots often do, so greylisting effectiveness can decline. Compare blocked abuse value with legitimate delay and resource cost. A control that delays everyone without reducing harm should be redesigned or retired.

Segment by authenticated/reputation class and avoid retaining more sender/recipient data than necessary.

Release receiver policy changes gradually

1. Replay sanitized historical tuples in a lab.
2. Test state capacity, restart, replication and clock behavior.
3. Shadow-score without temporary rejection.
4. Enable on a bounded domain/traffic share.
5. Watch legitimate retry delay and support cases.
6. Expand under rollback gates.

Record tuple normalization and exception version. Rollback should preserve valid passed state where safe so every sender is not greylisted again. Announce material policy to internal mail owners and support.

Worked receiver case: state loss after deployment

A receiving cluster deploys new nodes without shared greylist state. Load balancing sends each retry to another node, and every node sees a first attempt. Legitimate delivery delays grow while the aggregate temporary-reject counter looks normal.

Operators correlate tuple and node ID, drain the faulty nodes, restore replicated/consistent state and allow controlled retries. They preserve anti-abuse/content controls rather than globally accepting mail. Monitoring adds per-node first-seen ratio and repeated tuple rejection across nodes.

The lesson mirrors outbound pool rotation: state and routing must agree on the identity used to recognize a retry.

Review sender and receiver configuration after MTA upgrades

MTA defaults, queue scheduling, IPv6 routing, address pools and plugin/database formats can change across releases. Record the effective configuration and test fixtures before/after upgrade. Do not paste configuration for a different MTA version or operating system path.

Use a staged upgrade and keep rollback evidence.

Report delay and eventual outcome by recipient, not reply count

A weekly operations view should show unique first-greylisted recipients, percentage eventually accepted, attempts to acceptance, p50/p95 delay, expirations, route changes and provider/stream distribution. Reply-event totals measure workload but can overstate affected population.

recipient_final_state:
  first_greylisted_at
  accepted_at OR expired_at OR permanent_failed_at
  attempts
  distinct_outbound_ips
  business_expired_before_acceptance

Alert when distinct route count rises, delay shifts or state-store errors appear. Annotate sender/receiver releases. Successful eventual acceptance is necessary but not sufficient for time-sensitive service objectives.

Assign end-to-end ownership for greylisting behavior

Sender operations owns queues/retry/routing; receiver operations owns temporary policy/state; application teams own message expiry and user experience. Support needs a diagnostic path that captures Message-ID, recipient domain and UTC time without asking users to resend repeatedly.

Review contacts, queue SLOs, state capacity and exceptions before peak periods. Every manual queue flush, receiver bypass or retry override needs an owner and expiry. Retain the final accepted or expired outcome with the incident.

Final review

Confirm a controlled first attempt receives a temporary response, the scheduler waits, the retry preserves the expected tuple and final acceptance occurs exactly once. Verify time-sensitive expiry, queue storage and failover. Record sender/receiver policy versions and remove emergency overrides after recovery.

Evidence retention

Keep the complete SMTP reply, tuple inputs, queue/recipient IDs, every attempt time, outbound route, receiver MX, scheduler policy and final outcome. Redact public examples but preserve the operational artifact. This allows a later MTA or pool change to be compared against the exact failed behavior.

Record review date

Store the tested MTA/scheduler versions, receiver policy assumptions, UTC review time, owners and next controlled failover/greylist exercise.

Sign-off

Approve only after controlled retries, failover, queue expiry and final acceptance behavior have been demonstrated and recorded.

Archive

Archive the final queue and receiver evidence securely after review.

Primary references

• RFC 5321 SMTP
• RFC 3463 Enhanced Status Codes
• Greylisting paper by Evan Harris

Continue learning

• SMTP Error Codes
• Email Throttling
• Soft and Hard Bounces