security operations

Greylisting

Updated October 16, 2026

Greylisting is an email anti-abuse technique that temporarily defers an unfamiliar delivery attempt and relies on the sending server to retry. It can discourage senders that do not implement normal retry behavior. It introduces delay and should not be confused with quarantine, permanent rejection, or a complete phishing defense.

2 min. read

What do I need to know about Greylisting?

Legitimate mail can be delayed, including password resets and time-sensitive alerts.
Malicious senders using normal mail infrastructure can retry too. Retrying is not proof of good intent.
Shared sending pools and changing source addresses can complicate recognition of a returning sender.
Use only where the mail platform supports it and where its operational tradeoffs fit the organization.

An illustrative example

A customer reports that an account-reset email arrived too late. Delivery logs show an initial temporary deferral followed by a successful retry. The message was not permanently blocked. The administrator checks whether the delay is acceptable for that workflow before changing broader filtering policy.

Practical checks

Correlate the first delivery attempt, temporary response, retry, and final outcome.
Measure delays for critical senders rather than judging the control only by spam reduction.
Document supported exceptions and retain other authentication, content, and account protections.

Five FAQs about Greylisting

Is greylisting the same as a blocklist?

No. Greylisting normally defers delivery temporarily. A blocklist identifies sources or indicators to reject or restrict according to policy; its decision is not simply a request to retry later.

Will legitimate mail always retry successfully?

Standards-compliant systems normally retry temporary failures, but timing, queue limits, and configuration vary. Monitor actual delivery rather than assuming every legitimate application behaves correctly.

Can greylisting stop targeted phishing?

It may deter some senders, but an attacker using infrastructure that retries can pass through. It does not evaluate whether a message’s business request is fraudulent.

Should we enable it for every mailbox?

Assess provider support and the impact on important workflows first. Authentication, filtering, reporting, and incident response remain necessary regardless of whether greylisting is used.

How can I tell a temporary delay from a permanent failure?

Administrators can inspect SMTP responses and message-trace evidence. A temporary response generally invites retry; a permanent rejection needs investigation rather than blind resending.