Greylisting Behaviour in EU ISPs and How PowerMTA Responds

• April 2021
• Engineering Memo · External Release

Greylisting is one of the most misunderstood delivery mechanisms encountered in European email infrastructure operations. It causes deferrals that look like delivery problems, creates accounting log noise that inflates deferral rate metrics, and occasionally produces incorrect bounce classification when the deferral is treated as a soft bounce rather than a transient greylisting event. Understanding exactly how greylisting works, which European ISPs use it and how, and how PowerMTA should be configured to handle it correctly eliminates a category of false alarms from deliverability monitoring.

This note documents greylisting mechanics, the EU ISP landscape for greylisting implementation, PowerMTA's default greylisting handling and where it needs tuning, and the monitoring approach that distinguishes genuine delivery problems from greylisting noise.

How Greylisting Works

Greylisting is an anti-spam technique that exploits the asymmetry between legitimate mail servers and spam-sending systems in their handling of temporary failures. A greylisting server, upon receiving a first connection from an unknown sending IP to deliver a message to a specific recipient, returns a 4xx temporary failure response rather than accepting the message. Specifically, it typically uses 451 with a message indicating the sender should try again later.

The greylisting server records the combination of sending IP, sender address, and recipient address — known as the "triplet." On retry, if the triplet is recognized (same IP, same sender, same recipient) and the configured minimum delay has elapsed (typically 5–30 minutes), the server accepts the message. Legitimate mail servers retry failed deliveries, as specified by the SMTP protocol. Many spam-sending systems do not implement retry logic, because they are designed for one-shot high-volume sending from rotating IPs. The greylist acts as a filter that accepts messages from retrying senders and rejects — or more precisely, silences — messages from non-retrying senders.

The greylisting triplet approach creates an important operational consideration: if a retry comes from a different IP address than the original attempt — which happens in environments that use IP rotation or send through a load-balanced SMTP gateway — the retry does not match the triplet and receives another 4xx. This can create situations where legitimate mail is repeatedly deferred by a greylisting server even though the sending infrastructure is correctly implementing retry logic, simply because the retries are not originating from the same IP.

EU ISPs That Use Greylisting

Greylisting is more prevalent among European ISPs than among the major US providers. Gmail, Yahoo, and Microsoft largely rely on reputation-based filtering rather than greylisting, because their scale and reputation data infrastructure makes greylisting less necessary. European regional providers — which have smaller volumes and less sophisticated reputation databases — more frequently rely on greylisting as a first-line spam defense.

Among the major European ISPs, the following have been observed using greylisting as of 2025–2026, with the specified characteristics:

PowerMTA Configuration for Greylisting Environments

PowerMTA handles 4xx responses by retrying the message after the configured retry interval. For greylisting environments, the correct configuration ensures the retry uses the same source IP as the original attempt — which is the IP required to match the greylisting server's triplet record. In environments using IP rotation (where each retry might use a different IP from the pool), greylisting can cause repeated deferrals because the retry IP doesn't match the original triplet.

The PowerMTA configuration solution: use session-affinity for retry attempts to greylisting-heavy destinations. In practice, this means configuring the domain block for greylisting-heavy EU ISPs with a smaller max-smtp-out value that limits the pool rotation, combined with retry-after values that ensure the same virtual MTA handles the retry before a rotation would occur. The configuration looks like this for T-Online.de:

<domain t-online.de>
  max-smtp-out         3         # Low connection count, reduces IP rotation
  retry-after          15m       # Wait 15min before retry (matches greylist delay)
  max-msg-per-connection 5       # Keep sessions active for multiple retries
  use-pipelining       yes
  bounce-after         4d        # Patient bounce window for greylist resolution
</domain>

The retry-after value of 15 minutes aligns with the minimum greylist delay for most EU ISPs. Setting it shorter (5 minutes) produces a retry that may arrive before the greylist's minimum delay has elapsed, resulting in another 4xx. Setting it longer (60 minutes or more) produces acceptable delivery but with unnecessary latency for time-sensitive campaigns. For bulk marketing campaigns, a 15–30 minute retry interval is appropriate. For time-sensitive triggered email to EU addresses, consider routing to a dedicated virtual MTA with a shorter retry interval and a prioritized queue that ensures this traffic is retried at the appropriate time.

Distinguishing Greylisting from Genuine Delivery Problems

The accounting log signature of a greylisting event is distinctive: a 4xx response on the first delivery attempt, followed by a 250 OK on a retry from the same sending IP within 5–60 minutes. This pattern — deferral followed by successful delivery with no configuration change in between — is greylisting. It should be classified as "greylist resolved" in the bounce processing system, not as a soft bounce that increments the recipient's soft bounce counter.

The accounting log signature of a genuine delivery problem is different: multiple 4xx responses across multiple retries without resolution, or a transition from 4xx to 5xx as the message ages and the ISP escalates from temporary refusal to permanent rejection. This pattern requires investigation and potentially list action.

The monitoring consequence: deferral rate metrics that include greylisting events as soft bounces will systematically overstate the problem rate for EU ISP sending. A sending programme with 15% first-attempt deferral rate to T-Online.de, where 12% of those deferrals resolve within 30 minutes through greylisting, has a genuine problem rate of 3% — not 15%. Building greylisting-aware metrics requires parsing the accounting log for retry-resolved vs. non-resolved deferrals rather than counting all deferrals as equivalent problem events.

Greylisting Bypass: Established IP Reputation

Most ISPs that implement greylisting provide a mechanism for bypass: established, high-reputation IPs are added to a whitelist that allows their messages to pass without greylisting. This bypass typically develops naturally over time as the IP demonstrates clean sending behavior — the greylisting server learns that this IP consistently sends legitimate mail and stops greylisting it. The learning period varies by ISP from a few weeks to several months.

The warmup implication: new IPs added to a sending pool will experience greylisting from EU ISPs during the early warmup weeks even if the domain reputation is excellent. This is not a deliverability problem — it is the expected behavior for new IPs at greylisting-enabled receivers. The greylisting typically diminishes or disappears as the IP's sending history at that ISP accumulates. Operators who interpret early-warmup greylisting as a reputation problem and respond with reduced sending volumes may actually slow the accumulation of history needed for the greylisting server to learn the IP is trustworthy.

For senders with established IPs who begin sending to a new EU ISP destination they haven't sent to before — adding a regional European ISP to a new pool of addresses, for example — the first sends to that ISP will trigger greylisting even on a well-established IP, because the greylisting server's triplet database does not have history for this specific sending IP sending to these specific recipient addresses. The greylisting resolves quickly (typically within 1–3 campaigns) as the triplet database populates with successful delivery history.

Greylisting and Campaign Timing Implications

For bulk email campaigns targeting significant European audience segments, greylisting has a practical campaign timing implication that is rarely discussed in deliverability documentation: campaigns that send at high throughput to EU ISPs will have a portion of their messages deferred by greylisting, then delivered 15–45 minutes later than the initial send time. For time-sensitive campaigns — sales with expiry times, event reminders, flash promotions — this latency needs to be accounted for in campaign scheduling.

The practical approach: when sending time-sensitive campaigns to lists with significant EU components (20%+ European addresses), start the send 30–45 minutes before the intended "live" time of the promotion. This buffer absorbs the greylisting delay for first-time or low-reputation-IP sends, ensuring EU recipients receive the message within the intended window even if the first delivery attempt is deferred. For campaigns with European address segments above 40%, consider splitting the send — beginning the EU segment 30 minutes ahead of the US segment — so both segments receive the message at approximately the same local time, accounting for greylist latency.

This timing adjustment only applies to campaigns targeting EU ISPs known to implement greylisting. Gmail and Microsoft EU accounts (gmail.com, outlook.com, hotmail.com) are not typically greylisted. The primarily affected providers are the regional European ISPs (GMX, Web.de, T-Online, Orange, Free, Libero, and similar). Segmenting the EU ISP composition of the list — by analyzing the domain portion of recipient addresses — is necessary to determine whether the timing adjustment is warranted for a specific campaign's audience composition.

Greylisting in Corporate Mail Environments

Greylisting is not limited to consumer ISPs. Many corporate mail servers — particularly those using open-source mail server software with spam filtering plugins — implement greylisting as part of their inbound filtering stack. Postfix with Postgrey, Exim with acl_check_rcpt greylisting rules, and Microsoft Exchange with transport rules that emulate greylisting behavior are all common in corporate email environments.

For B2B senders or transactional email programmes that deliver to corporate mail servers (as opposed to consumer ISPs), greylisting can be more disruptive than in consumer contexts. Corporate recipients may notice if a time-sensitive transactional message (a 2FA code, a document-signing link, a meeting invitation) arrives 30 minutes later than expected. Corporate IT administrators who monitor their mail server logs may contact the sender's postmaster to report delivery delays they believe are on the sender's side, when the delay is actually caused by their own greylisting configuration.

The accounting log pattern is identical for corporate greylisting as for ISP greylisting: first attempt deferred with 4xx, retry accepted. The domain block configuration adjustment for corporate destinations should use the same retry-after interval (15 minutes) and session-affinity approach as for greylisting-heavy consumer ISPs. The difference is that corporate addresses are in the long tail of the domain distribution — many different individual corporate domains each with small recipient counts — rather than concentrated at a handful of consumer ISP domains. Domain-specific PowerMTA configuration is not practical for the long tail; instead, configure the default wildcard domain block with appropriate retry intervals and let PowerMTA apply these defaults to all unspecified destinations.

Greylisting as Signal: What High Greylist Rates Actually Indicate

High greylisting rates at an established ISP — where previous sends had lower greylist rates — can be a signal of reputation change at that ISP, even if the message is ultimately delivered. Some ISPs adjust the aggressiveness of their greylisting based on the sender IP's reputation: IPs with declining reputation get greylisted more frequently, because the ISP is increasing scrutiny before committing to accepting the messages.

If the first-attempt deferral rate at a specific EU ISP has increased from 5% to 25% over four weeks — and the messages are still eventually being accepted on retry — this is a soft reputation warning. The ISP is not yet rejecting the mail, but it is treating it with increased suspicion. Left unaddressed, this trend may eventually progress to higher deferral rates, longer retry delays enforced by the ISP, or outright rejection.

Monitoring for this pattern requires tracking the first-attempt deferral rate per ISP in the accounting log — specifically the rate of messages that receive a 4xx on attempt number 1, not the overall deferral rate which includes all retry attempts. A rising trend in this metric at a specific EU ISP, without a corresponding rise at other ISPs, is an ISP-specific reputation signal worth investigating through ISP postmaster contact and review of complaint data from that ISP's feedback loop if available.

Configuration Summary: PowerMTA for Optimal EU Delivery

For sending programmes with significant EU recipient populations (30%+ European addresses), a complete PowerMTA configuration for EU ISPs includes: per-ISP domain blocks for GMX, Web.de, T-Online, Orange.fr, Free.fr, and Libero.it with retry intervals tuned to each ISP's greylisting minimum delay; conservative max-smtp-out values (3–5 connections) for greylisting-heavy ISPs to minimize IP rotation during retry sequences; session-affinity through careful virtual MTA assignment for EU traffic streams; and a wildcard domain block with 15-minute retry-after as the default for corporate and small European ISP destinations not specifically configured.

This configuration will produce slightly lower throughput to EU ISPs in initial send phases — because the greylisting deferrals extend delivery time — but will produce significantly higher eventual delivery rates and accurate deferral metrics that distinguish greylisting from genuine delivery problems. The cumulative effect over sustained campaigns is better EU inbox placement, more accurate monitoring data, and fewer false alarms in the deliverability monitoring system that would otherwise trigger unnecessary investigations of normal greylisting behavior.

Reviewing EU ISP delivery metrics quarterly — checking first-attempt deferral rates, final delivery rates, and time-to-delivery distributions for each major EU ISP — provides the data needed to tune the configuration as ISP behavior changes. Greylisting implementations evolve, and ISPs that were aggressively greylisting in 2022 may have modified their approach by 2025, or new greylisting patterns may have emerged at ISPs that previously did not use it. Quarterly review ensures the PowerMTA configuration remains calibrated to current EU ISP behavior rather than to the behavior observed at the time of initial setup.

Building Greylisting Awareness into Bounce Processing

The bounce processing pipeline in a MailWizz + PowerMTA environment receives bounce signals from two sources: the PowerMTA accounting log (which records every SMTP attempt and response) and the MailWizz bounce server (which receives bounced message copies via IMAP). Both sources need greylisting awareness to avoid incorrect soft bounce counter increments.

In the accounting log, a greylisting event appears as a deferral record followed by a delivery record for the same message. A correctly implemented accounting log processor should check whether a deferred message was subsequently delivered before classifying the deferral as a soft bounce. If the message was delivered on retry — within a reasonable window, say 2 hours — the initial deferral is a greylist event and should not increment the recipient's soft bounce counter. If the message was deferred and not delivered within the bounce-after window, it is a genuine soft bounce that warrants counter increment.

In the MailWizz bounce server (the IMAP account that receives Delivery Status Notifications), greylisting events do not typically generate bounce messages — because the message is eventually delivered, no bounced message copy is generated. However, some configurations produce DSN messages even for deferred deliveries that are eventually resolved. These DSN messages contain the original deferral code (451) and may be misclassified as soft bounces by the MailWizz bounce processing rules. Adding a specific rule that excludes 451 DSN messages from soft bounce classification — or that checks whether the original message was subsequently delivered before classifying — prevents greylisting-driven DSN messages from polluting the soft bounce data.

The correct integrated approach: accounting log processing is the authoritative source for delivery outcomes because it has the complete timeline of attempts and responses. Bounce server IMAP data is supplementary for messages where the accounting log does not provide complete resolution data (particularly for messages that received DSN notifications from intermediate MTAs before final delivery). When the two sources disagree — the accounting log shows eventual delivery, the bounce server shows a 451 DSN — the accounting log delivery confirmation takes precedence. The recipient's soft bounce counter is not incremented. The DSN message is logged as a greylisting event, not as a delivery failure.

A production-ready greylisting-aware accounting log processor should: read every deferral record and create a pending-deferral entry; when a subsequent delivery record appears for the same message (matching on message ID), mark the deferral as "greylist-resolved" and update the entry; after the bounce-after window has elapsed without a delivery record, promote the deferral to a genuine soft bounce and apply the configured counter increment. This stateful approach — tracking message outcomes across multiple accounting log entries — requires slightly more processing complexity than a stateless per-record classifier, but it produces dramatically more accurate soft bounce data for lists with significant EU ISP audiences. The investment in building this processing logic correctly, once, eliminates the recurring problem of EU list contacts being incorrectly suppressed due to greylisting events being misclassified as delivery failures.

Greylisting is, ultimately, a correctness problem that masquerades as a delivery problem. Understanding the distinction — that the 4xx response is intentional and expected, not evidence of infrastructure failure or list quality problems — allows operators to configure their systems to handle it correctly, monitor their metrics accurately, and focus their deliverability attention on the genuine problems rather than the expected behavior of a widely-deployed spam filtering technique. The EU ISP landscape in 2025 and 2026 includes enough greylisting-enabled providers that ignoring it is not an option for senders with significant European audiences — but handling it correctly is straightforward once the mechanism is understood.

Operators who invest in greylisting-aware infrastructure configuration and monitoring build sending environments that deliver to EU audiences more reliably, with less operational overhead from false alarms, and with more accurate deliverability data on which to base suppression and list management decisions. The configuration investment is modest — primarily the per-ISP domain block tuning and the accounting log processor update — relative to the improvement in data quality and operational clarity it produces across every campaign that includes significant European address segments.