Greylisting on a mail server — when it helps, when it hurts

Greylisting is the technique of temporarily rejecting unknown sender/recipient pairs with a soft (4xx) error. Legitimate mail servers retry within minutes and pass; many spam senders don't retry and give up. It was a near-magical spam-reduction trick from 2005–2015 — easily 80% spam volume reduction overnight. The world has changed; this article covers whether to enable it now.

How it works

1. SMTP RCPT TO from a previously-unseen (sender_ip, sender_addr, recipient_addr) tuple arrives.
2. Your server responds 451 Greylisted, try again in 5 minutes.
3. RFC-compliant senders retry within 5–30 minutes; the second attempt is accepted because the tuple is now known.
4. Non-compliant or low-effort spammers don't retry; the message never gets through.

Tuple memory typically expires in a few weeks of inactivity, so cold senders re-trigger the greylist; established correspondents don't.

Why it's less effective now

• Major spam volumes shifted to legitimate-looking compromised accounts. Mail from a hacked Gmail account doesn't fail greylisting — Gmail's MTAs retry properly. The delivery shape is identical to legitimate mail; only the content is spam.
• Modern Bayesian + DNSBL + DMARC ecosystem catches most of what greylisting used to catch, without the delivery delay.
• Some legitimate senders retry slowly or only once. Mailing list software, transactional services on shared infrastructure (older SendGrid, some mass-mailers) sometimes give up after one 4xx and never come back. You lose the message and don't know why.

Why you'd still enable it

• Low-volume mail server with mostly known correspondents. The first-message delay is rare; subsequent messages from established senders are immediate.
• A second-layer defense in addition to Rspamd or SpamAssassin. Catches some of the low-effort spam before it even hits the more expensive content scan.
• Honeypot accounts (catch-all addresses, intentional spam traps). Greylisting kills volumetric spam to these addresses before it ever gets to your real disk.

Why you wouldn't

• You can't tolerate any first-message delay. Password reset emails, "click this link in 5 minutes to verify your account" flows — even short greylist delays break these UX patterns when the receiver runs a greylist.
• You correspond a lot with new senders. Mailing list signups, single-shot notifications, broadcast lists from services you only just signed up for. All trigger greylist.
• You receive mail from many small-volume IPs (newsletter subscribers, individual senders) who may not retry properly.

Enabling it with postgrey (SpamAssassin pipeline)

apt install postgrey      # Debian/Ubuntu
dnf install postgrey      # AlmaLinux (EPEL)

systemctl enable --now postgrey

Wire into Postfix:

# /etc/postfix/main.cf
smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service unix:private/postgrey

# Inform Postfix of the postgrey socket (Debian uses TCP; Alma uses unix socket)
# /etc/postfix/master.cf (Debian — postgrey on TCP 10023 by default)
# 127.0.0.1:10023 inet  n  -  n  -  -  spawn user=postgrey argv=/usr/sbin/postgrey ...

systemctl reload postfix

Default delay is 5 minutes. Tune in /etc/default/postgrey:

POSTGREY_OPTS="--inet=10023 --delay=300 --max-age=35"

Enabling it with Rspamd (preferred for new setups)

Rspamd has greylisting built in; no separate package needed. It's enabled by default in modern Rspamd installs — check /etc/rspamd/local.d/greylist.conf or the web UI's Symbols page.

Tune the score threshold that triggers greylist:

# /etc/rspamd/local.d/greylist.conf
greylist_min_score = 4;    # don't greylist if score is below this
expire = 1d;               # how long to remember greylist tuples
timeout = 5m;              # how long sender must wait before retry

Whitelist your trusted senders

Some senders should bypass greylisting regardless. Your own IP, your relay (if you have one), your CI/CD system, and any specific addresses you don't want delayed:

# /etc/postgrey/whitelist_clients
.gmail.com
.outlook.com
.mailgun.org
sendgrid.net
123.45.67.0/24

# /etc/postgrey/whitelist_recipients
postmaster@example.com
critical-alerts@example.com

Restart postgrey after editing. Whitelist entries take effect immediately.

What "good greylisting" looks like

• ~10-30% of incoming mail gets greylisted (volume of new sender-recipient pairs).
• ~85% of greylisted mail comes through on retry within 30 minutes.
• Spam volume on the next scoring step (Rspamd / SpamAssassin) drops by ~30%.
• Zero or near-zero false-positives reported by users (mail that never arrived).

If you see false positives — legitimate senders not getting through — they're hitting greylist and either not retrying or hitting it during the wrong window. Whitelist them and adjust the max-age longer so established pairs stay remembered.

Bottom line

Default OFF for most modern setups. Enable only if you have a specific problem it solves (volumetric spam to honeypot accounts, very-low-volume server where the delay is acceptable). The CPU/operational cost is low; the user-experience cost of delayed first-contact messages is real.