What is greylisting?

The mechanism is precise, and precision is the entry ticket here: the pages currently ranking for this term include an IETF RFC and a university wiki, and both are exact.

The receiving server records a triplet — the sending IP address, the envelope sender, and the recipient address. On first sight of a triplet it answers with a temporary rejection. If the same triplet returns after a configured delay, the message is accepted, and the triplet is usually remembered for a period afterwards so the delay is paid once rather than on every message.

The bet is behavioural, not cryptographic. A real mail server has a queue and a retry schedule because RFC 5321 requires it to; a lot of bulk-sending malware has neither, because a retry queue costs the sender money and the sender does not care about any individual message. The behaviour is described in RFC 6647 — Email Greylisting: An Applicability Statement for SMTP, which is the primary source and which almost nothing else ranking for this term links.

A 4xx reply, and the exact wording is server-specific. Postfix’s widely-used greylisting policy daemons answer with variants of 450 4.7.1 Greylisted, try again in N seconds; other implementations say 451 4.7.1 Please try again later or 450 4.2.0 Recipient address rejected: Greylisted. Quote the one your logs show rather than assuming a universal string.

The effect on a normal send is a delay on first contact with a recipient — typically a few minutes, configured per server — after which mail flows normally. It is invisible to the recipient and there is nothing to fix at your end, provided your sending server retries.

They are confused constantly, because both produce a rejection code. They are opposite in every other respect: greylisting is temporary, applies to senders the server has not met yet, and resolves itself by waiting. Blocklisting is a reputation judgement about you, persists until something changes, and requires action — usually a delisting request and a fix to whatever produced the listing.

This is the clearest demonstration that unknown is a considered verdict rather than a shrug. A catch-all result and a greylisted result are both unknown, and what you should do about them is exactly opposite: retry the greylisted one, because the server told you to; do not bother retrying the catch-all one, because the domain will answer identically forever.

That is what retryable is for. It is true for greylisting and false for catch-all, and an integration that switches on it gets both right without knowing anything about SMTP.

When a verifier advertises anti-greylisting, what it means is retry scheduling: queueing a second probe after the greylist window instead of reporting the first rejection as a failure. That is worth having and it is what we do.

There is no way to skip a greylist. A vendor implying it has one is overselling a retry loop. The only alternative to waiting is reporting the deferral as a failure, which is the behaviour the technique exists to catch.

Two practical routes. Read the 4xx reply text — most implementations name themselves. Or send twice and compare: a first attempt deferred and a second accepted minutes later, with nothing else changed, is greylisting almost by definition.

Knowing the receiving platform is most of the answer, because several greylist by default. An MX record lookup tells you who runs the domain’s mail.