RFC 6647 — Email Greylisting

When your first attempt to deliver to an unfamiliar receiver is deferred with a temporary failure, greylisting is the most common reason. Your retry logic has to be designed with greylisting in mind, or the deferral can repeat indefinitely.

Greylisting means temporarily degrading service to unknown email clients as a defense against abuse. It exploits the fact that much spam software sends once and never retries after a 4xx temporary failure, while a compliant MTA queues the message and retries as RFC 5321 §4.5.4 requires. RFC 6647 documents the technique. It is a Standards Track applicability statement in the style of a BCP, published in 2012.

How greylisting is applied (the five variants)

The RFC classifies greylisting by the SMTP stage at which the decision is made, and by what is recorded:

The standard form, and the one the RFC recommends implementing, is the triplet of IP address, RFC5321.MailFrom and the first RFC5321.RcptTo.

Reply codes

"Per RFC 5321, the only two reasonable choices are 421 if the implementation wishes to terminate the connection immediately, and 450 otherwise." A greylisting deferral therefore looks exactly like any other soft failure, and nothing in the reply reliably identifies it as greylisting. Some receivers say "greylisted" in the text, so always log the full reply text.

Timing parameters (Section 5 recommendations to greylisters)

Other MUST and SHOULD items for greylisters:

• All inbound border MTAs of an administrative management domain (ADMD) listed in DNS SHOULD share a common greylisting database and common policies. Otherwise a sender that retries to a different MX starts the clock again, which makes the delay longer.
• Greylisters MAY track CIDR blocks (for example, /24) or groupings by domain, so that clustered outbound server farms qualify as a unit.
• Greylisters MUST provide a manual override (an exception list) for IP addresses and network blocks.
• Greylisting SHOULD NOT be applied on the submission service for authenticated clients, or to any authenticated session.

Exceptions / whitelisting (Section 2.7)

Exception sets may name IP addresses, CIDR blocks, host names or domain names that are exempt from greylisting. Good candidates are hosts known to retry properly and hosts that rarely send. DNS-based allowlist services can serve as a shared source of exceptions.

What senders must do

On the client side, RFC 6647's position is that a client cannot know why a 4xx reply came back ("greylisting could be in effect"). A client therefore needs to be able to retry in order to be considered fully capable. For an ESP, this has these operational consequences:

1. Retry from the same IP address. The tuple includes the source IP address. If your MTA retries a deferred message from a different IP address in the pool, the greylister sees a brand-new tuple and defers again, possibly forever as the retries cycle through the pool. Your queue and retry logic must pin a deferred message (or at least a deferred destination) to the IP address that made the first attempt. This is the key interaction between greylisting and sending from pools.
2. Keep MailFrom stable across retries. VERP and return paths unique to each message are fine, since the tuple is per message anyway. Rewriting the envelope sender between attempts, however, creates a new tuple.
3. Time the first retry well. The RFC 5321 SHOULD of ≥30 minutes sits comfortably inside the default acceptance window (1-minute-to-24-hour). A first retry in the 5–30 minute range clears most greylisters quickly. Retrying within seconds is wasted, because the entry is still under the minimum age, and it looks like hammering the server.
4. Expect inconsistency between MX hosts. Receivers that ignore the SHOULD on a shared database defer you separately at each MX, and a retry that lands on another MX host restarts the wait. This is a defect at the receiver, not yours. Patience is the fix, not rotating IP addresses.
5. Plan for warm-up. New IP addresses are by definition unknown everywhere, so the first sends from a fresh IP address to smaller receivers see higher deferral rates for the first hours. Allow for this in your throughput expectations for IP warm-up. It clears as the tuples age in.
6. Know that address changes defeat aging. Senders on DHCP or rotating addresses appear as new sources after every change. Conversely, NAT makes separate MTAs share one IP address, so a pass by one machine exempts the others. This is why receivers increasingly distrust greylisting on its own.
7. Protect time-critical mail such as password resets and other transactional mail. Greylisting can delay delivery on first contact by minutes to hours. The RFC's own security section warns of "unintentional and detrimental consequences for delivery of legitimate mail", particularly for time-critical applications. The mitigation is to send transactional mail from established IP addresses used consistently, which will already be aged in or on exception lists.

Security considerations (Section 8)

• Attackers who rotate the tuple parameters can bloat the greylisting database, a denial of service against the receiver. Implementations should define a failure policy for when the database is attacked or unavailable.
• Greylisting slows abuse down but does not authenticate anyone: any botnet that retries passes it. Its value is that it cheaply filters out the share of abuse that does not retry.

Related articles

• RFC 5321 — SMTP, the retry obligations that greylisting relies on (≥30-minute retry interval, 4–5 day give-up)
• Enhanced Status Codes, for classifying 4xx deferrals
• IP Warm-Up, on why fresh IP addresses see more deferrals