Greylisting temporarily rejects the first delivery attempt from an unknown mail server with a
451 4.7.1(please retry later) response.
Legitimate mail servers always retry within minutes and are then accepted — and remembered.
Most spam engines never retry, so their messages simply never enter your platform.
¶ Benefits
- Removes a large share of botnet spam for free:
No content analysis, no external lookups — the spam is refused before the message body is even transmitted. - Authenticated senders are never delayed:
Senders that pass SPF or DKIM with DMARC alignment bypass greylisting entirely (configurable), so mail from well-configured domains (Gmail, Microsoft 365...) flows without delay. - Allow lists:
Trusted networks (IP/CIDR) and host names (wildcards supported) skip greylisting. - Safe failure modes:
If the database backing the greylist is unavailable, you choose the behaviour (work from the in-memory cache or fail-open)
greylisting can never lose mail, only delay it. - Per-instance policy:
With multiple SMTP instances, each instance can have its own greylisting rule. - Smart by design:
Authenticated or allow-listed senders can be persisted as accepted, and the first retry after the configured delay is accepted immediately.
¶ Use cases
- Internet-facing MX:
Cut the noise of botnet spam before your antivirus / antispam layer spends CPU on it. - Spam waves:
During a campaign targeting your domain, greylisting absorbs most of the junk with zero rule maintenance. - Small platforms:
Get a strong first line of defense without subscribing to external reputation feeds.
¶ Create the greylisting rule
Open MTA Mail system » Access Control Lists, click New Rule and select GreyListing:
Attach at least one object to define the scope (typically All).
Outbound/authenticated submissions and messages already in scope of DKIM/ARC signing are automatically skipped — greylisting only evaluates inbound, unauthenticated mail.
¶ Configure the options
| Option | Default | Meaning |
|---|---|---|
| Retry delay (seconds) | 300 |
Minimum wait before a retry of the same host name + IP pair is accepted. |
| Authentication bypass | Bypass when DMARC passes |
Senders passing SPF or DKIM with DMARC alignment skip greylisting. |
| Remember authenticated senders | enabled | Persist authenticated senders as accepted so they are never greylisted again. |
| Behaviour when the database is unavailable | cache_only |
Keep deciding from the in-memory cache, or fail-open (accept everything) until the database returns. |
| Temporary rejection SMTP code / message | 451 / 4.7.1 Greylisted, please retry later |
The temporary response sent on first contact. |
| Accepted sender lifetime | 2592000 (30 days) |
How long an accepted pair stays valid without new mail. |
| Pending entry lifetime | 86400 (1 day) |
How long a first-seen pair may wait for its retry before expiring. |
| In-memory cache lifetime | 900 |
TTL of the local decision cache shielding the database. |
| Cleanup interval | 3600 |
How often expired entries are purged. |
| Allow-listed IP / CIDR | — | Networks that always bypass greylisting (one per line). |
| Allow-listed host names | — | Host names that always bypass (wildcards such as *.trusted-partner.com are supported). |
¶ How a delivery is evaluated
- Allow-listed IP/CIDR or host name → accepted.
- Sender authenticated (per the Authentication bypass mode) → accepted (and optionally remembered).
- Known accepted
host name + IPpair → accepted. - Unknown pair → temporarily rejected (
451 4.7.1), recorded as pending. - Retry after the delay → accepted and promoted to accepted.
Every greylist temporary rejection is also written to Postfix's mail.log in the standard Postfix format, so your log analysis keeps working.
¶ Monitoring and dry-run
The milter's REST control socket exposes greylisting counters and a simulator (see Monitoring & REST API):
# live counterscurl --unix-socket /usr/share/artica-postfix/bin/run/artica-milter.sock http://x/greylisting/metrics
# what would happen for this tuple? (no side effects)curl --unix-socket /usr/share/artica-postfix/bin/run/artica-milter.sock -X POST http://x/greylisting/simulate -d '{"instance_id":0,"hostname":"mx.example.net","ip":"203.0.113.10","mail_from":"user@example.net"}'
¶ Related features
- DKIM signing — authenticated mail bypasses greylisting.
- Data Loss Prevention