What is a greylisted email?

One that was temporarily refused with a 4xx reply because the receiving server had not seen that combination of sending IP, envelope sender and recipient before. Nothing is wrong with the address or the message; it arrives on the retry.

What is the difference between a 4xx and a 5xx SMTP code?

A 4xx is transient — the condition is temporary and the sender should retry. A 5xx is permanent — the sender should not repeat the command in the same form. The enhanced codes 4.7.1 and 5.7.1 are otherwise identical, which makes this pair the clearest illustration of why the first digit decides everything.

Does the email verifier handle greylisting?

Yes. A deferral becomes unknown with the reason greylisted and retryable true, the probe is rescheduled, and you are not charged. Reporting a deferral as undeliverable would remove a live mailbox from a list because the server asked us to come back later.

SMTP reply code

450 4.7.1 — greylisted, try again later

A 450 4.7.1 reply is a temporary refusal, and on most servers it means greylisting: the receiving server has not seen this sender before and is asking it to come back. Retry and the message is normally accepted.

The facts

Reference facts for SMTP 450 4.7.1
Field	Value
Reply code	`450`
Enhanced status code	`4.7.1`
Class	4 — transient failure
Subject	7 — security or policy status
Detail	1 — delivery not authorized, message refused
Bounce type	Soft
Should the sender retry?	Yes
Representative wording	`450 4.7.1 <[email protected]>: Recipient address rejected: Greylisted, try again later`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 450 4.7.1
Field	Value
`emailStatus`	`unknown`
`reason`	`greylisted`
`smtpCheck`	`deferred`
`retryable`	`true` — and the probe is rescheduled
Charged	No. A retryable result is never charged.

The same enhanced code, a completely different meaning

The enhanced part of this code is 4.7.1, which decodes exactly like 5.7.1 — subject 7, security or policy; detail 1, delivery not authorized — with one digit changed. That digit is the whole meaning. Class 4 is transient: the server is not authorising delivery *right now*, and expects you to try again. Class 5 is permanent.

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

A bounce processor that matches on 4.7.1 and 5.7.1 together will treat a routine greylist as a reputation block, and a genuine reputation block as something that will sort itself out. Both errors are common and both are expensive.

Why it is nearly always greylisting

Greylisting works by temporarily rejecting mail from a sending IP, envelope sender and recipient combination the server has not seen before, then accepting it when the same combination returns. The technique is described in RFC 6647. A real mail server has a retry queue because the protocol requires one; a lot of bulk-sending malware does not, so the delay filters it out at almost no cost to legitimate mail.

450 4.7.1 is the reply most greylisting implementations use, usually with the word in the text. Other transient codes carry it too — some servers use 451 4.7.1 — so read the wording rather than matching the exact triple.

What to do

If you sent the message

Nothing. Your mail server will retry on its own schedule and the message will almost certainly arrive within the hour.
If it never arrives, the problem is your sending server’s retry behaviour rather than the greylist.

If you own the receiving domain

Greylisting is working as designed. The cost is a first-contact delay per sender.
If the delay is causing problems for transactional mail such as password resets, whitelist those senders rather than switching it off.

If you are a developer

Retry on a schedule and treat the first deferral as normal traffic, not as an error.
Never write a 4xx into a suppression list.
A verification result with reason: "greylisted" and retryable: true means exactly the same thing: ask again, and you were not charged.
Contrast it with reason: "catch_all", which is also unknown but has retryable: false — two unknowns, opposite advice.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.