What Is Greylisting?

Greylisting is a spam prevention technique based on a single observation: spam is usually sent by automated systems optimized for volume, not for reliable delivery. Legitimate mail servers, on the other hand, follow the SMTP standard and retry when they receive a temporary failure response.

Here's how it works in one sentence: when a message arrives from a sender your server hasn't seen before, respond with a temporary failure code — the SMTP 451 "Try again later" response — and log the triplet of sender IP, sender address, and recipient address. When that same triplet retries after a short delay, accept the message and remember the sender as legitimate going forward.

Spambots almost universally don't retry. They're built to blast millions of messages as fast as possible and move on. A temporary failure is functionally the same as a block because they never come back. Legitimate mail servers retry automatically, so the only cost to real email is a short delay on the very first message from a new sender.

Why It Works So Well

The effectiveness of greylisting comes down to the economics of spam. Running a spam campaign means sending tens or hundreds of millions of messages. Retrying failed deliveries would roughly double the work — and the infrastructure cost — for marginal benefit, since most targets will have some filtering anyway. Spambot software is written with this in mind. Retry queues are disabled or set to very long intervals that exceed the greylisting expiry window.

Independent studies of greylisting effectiveness have found it blocks between 70 and 90 percent of spam outright, before any content filtering even runs. For a filter that requires zero content analysis and has no false positive risk for established senders, that's an extraordinary result.

There's also a secondary benefit: by the time a greylisted sender successfully retries, DNS blacklists have had time to be updated. A spambot IP that wasn't yet listed when it first tried may well be listed by the time it would retry — if it ever did. Greylisting buys time for the rest of your filtering stack to catch up.

How Legitimate Mail Servers Handle It

The SMTP protocol explicitly defines a category of temporary failure responses, and every compliant mail transfer agent is required to implement a retry queue. When your server responds with a 451 code, the sending server logs the failure, places the message in its retry queue, and tries again — typically within 5 to 30 minutes, depending on its configuration.

Major mail providers — Google Workspace, Microsoft 365, Fastmail, and virtually every hosted email service — all retry properly. The delay experienced by the recipient is usually under 10 minutes for first-time senders. After the first successful delivery, the sender's triplet is recorded as known and future messages are accepted immediately with no delay at all.

Tuning defer_minutes and expire_hours

Indition Spam Killer exposes two greylisting parameters you can adjust:

  • defer_minutes: How long to wait before accepting a retry from an unknown sender. The default is 5 minutes. Setting this lower reduces the delay for first-time senders but may let through spambots that do retry quickly. Setting it higher (10–15 minutes) increases spam blocking at the cost of longer first-delivery delays.
  • expire_hours: How long a successful sender triplet remains in the allowlist before it expires and needs to prove itself again. The default is 168 hours (7 days). For most organizations, this is appropriate — a vendor you haven't heard from in a week is reasonably treated as new again.
greylisting:
  enabled: true
  defer_minutes: 5
  expire_hours: 168

These defaults work well for general corporate email. For a support inbox where even a 5-minute delay on a first contact is acceptable, the defaults are fine. For a domain where any delay is a problem, you should disable greylisting at the domain level.

Per-Domain Override: When to Disable Greylisting

Greylisting is not appropriate for every domain. There are two clear cases where it should be disabled:

Time-sensitive alert domains. If you have a domain that receives monitoring alerts, uptime notifications, or automated system emails, even a 5-minute delay can mean missing a critical notification. For these domains, disable greylisting entirely and rely on IP whitelisting for the known sending systems instead.

Transactional domains with bounce handling. Bounced message notifications often come from the same IP as the original send but with different envelope addresses, which can trip up greylisting logic. If your bounce handling is time-sensitive, consider disabling greylisting for that domain.

Disabling greylisting for a specific domain is a one-line override:

domains:
  alerts.acme.com:
    greylisting:
      enabled: false

Everything else about the domain's configuration — spam threshold, SPF enforcement, upstream server — is inherited from global defaults. You're only changing the one setting that needs to differ.

For most standard corporate domains, greylisting should be on. The first-time delivery delay is negligible in practice, and the reduction in spam volume reaching your content filters means better performance, lower false positive rates, and less noise in your quarantine. It's one of those rare settings where the default is almost always correct.