---
title: "What is email greylisting? - Emvero"
description: "Greylisting temporarily defers an unfamiliar SMTP attempt. Learn why a probe can return unknown, when retrying may help, and why no retry guarantees acceptance."
url: https://emvero.io/glossary/greylisting/
language: en
updated: 2026-10-07
---

All terms

Glossary

# Greylisting

Greylisting temporarily defers an unfamiliar SMTP attempt and assesses a later retry. The initial refusal gives no answer about whether the mailbox exists.

## How a later attempt may pass

Greylisting records an unfamiliar SMTP attempt and defers it with a temporary `4xx` reply. The server may use the connecting source, envelope sender and recipient to recognise a later attempt. [RFC 6647](https://www.rfc-editor.org/rfc/rfc6647.html) describes these policies.

Once the configured delay has elapsed, a recognised retry may pass the greylisting rule. Other server checks still apply. There is no universal waiting period or guarantee of acceptance on the second attempt. If the source or envelope details change, the server may treat it as a new attempt.

## What the verification result means

A reply such as `451` indicates a temporary failure, but its number does not identify the cause. Server load and [SMTP throttling](https://emvero.io/glossary/smtp-throttling/) can produce similar replies. Emvero uses `SMTP_GREYLISTED` for an observation classified as greylisting and `SMTP_TEMPORARY_FAILURE` for a general temporary SMTP failure.

If no other evidence determines the result, a greylisted probe returns `unknown` with `allow_with_email_confirmation`. The deferral supplies no basis for an `undeliverable` result. Emvero sends no email and stops before `DATA`, so it cannot observe greylisting applied only at the message-content stage.

## Waiting for a check or starting another

When the response is `pending`, retrieve the same check after `retry_after_ms`. A completed `unknown` has finished; decide separately whether to start another check later. That check may use cached evidence and may encounter another refusal. The [verification result guide](https://emvero.io/blog/reading-a-verification-result/) explains the distinction.

At signup, your application can send confirmation to establish access. For a list, keep the reason while deciding whether to hold or recheck the address; see [unknown versus undeliverable](https://emvero.io/compare/unknown-kept-apart/). A verification retry gathers evidence, whereas a sending server’s retry attempts to deliver an actual message.

## Related reason codes

The API uses these identifiers to explain a check. The notes identify values that the current verification policy or probe does not return.

`SMTP_GREYLISTED`

Temporary refusal classified as greylisting

`SMTP_TEMPORARY_FAILURE`

Temporary failure at the mail server

## Related terms

### Hard bounce and soft bounce

Permanent and temporary delivery failures describe a sending attempt. Learn how they differ from verification evidence.

### SMTP handshake

The greeting and commands used to ask a mail server about a recipient, stopping before message content is sent.

### Throttling and rate limiting

A destination limits how often probes can connect or ask about recipients. The limit does not establish mailbox existence.

## Compared side by side

### Real-time vs list verification

Check one address while someone waits or work through a stored list. Compare timing, pending responses and the workflow your system manages.

### Unknown vs undeliverable

Separate inconclusive evidence from a permanent technical failure, then choose whether to retry, confirm or reject.

[All terms](https://emvero.io/glossary/)

## Try a check in your account.

Choose the check that fits your question and inspect the result.

Start for free