What causes '503 5.5.0 polite people say HELO first' bounce errors with Ziggo.nl and how are they resolved?
Michael Ko
Co-founder & CEO, Suped
Published 16 Jul 2025
Updated 23 May 2026
8 min read
Summarize with
The direct answer is that Ziggo.nl returned 503 5.5.0 polite people say HELO first when its receiving SMTP system believed the sender had not completed the required HELO or EHLO greeting before sending the next command. In the observed Ziggo.nl incident, the sender-side evidence showed that mail servers did send HELO or EHLO first, the error appeared across several ESPs during a narrow morning window in the Netherlands, and the provider later confirmed a configuration conversion issue. The resolution was to wait for the receiver-side fix and retry affected mail, not to change DMARC, SPF, or DKIM records.
Observed bounce texttext
503 5.5.0 polite people say HELO first
That distinction matters. A 503 greeting error is an SMTP conversation problem. It happens before the receiving system has accepted the message body, and it sits closer to transport handling than to inbox placement, content filtering, or DMARC policy enforcement. If the same error suddenly appears against one mailbox provider across unrelated senders, I treat it as a provider incident until the logs prove otherwise.
- Immediate cause: The Ziggo.nl SMTP front end rejected a command because its greeting state was wrong or misread.
- Practical fix: Confirm the sending trace includes HELO or EHLO, then retry after the provider clears the incident.
- What not to do: Do not rush into SPF flattening, DKIM key rotation, or DMARC policy changes for this specific bounce.
What caused the Ziggo.nl HELO bounce
SMTP requires a sending host to identify itself after the receiver sends its 220 banner. Modern senders use EHLO, while older or simpler clients use HELO. If the receiver sees MAIL FROM, RCPT TO, DATA, or another command before that greeting, it can return a 503 response because the commands are out of sequence.
Main takeaway
For this Ziggo.nl case, the meaningful signal was not the wording of the error by itself. It was the pattern: multiple ESPs, one receiving provider, a short time window, normal historical traffic, and sender transcripts showing that HELO or EHLO was sent.
A true sender-side version of this error points to a broken SMTP client, a custom integration that skips the greeting, an SMTP proxy that reorders commands, or a connection state bug after STARTTLS. The Ziggo.nl event looked different because unrelated sending platforms saw the same provider-specific failure at roughly the same time.
|
|
|
|---|---|---|
Several ESPs | Receiver issue | Compare logs |
One provider | Scoped fault | Retry later |
Short window | Incident spike | Track times |
EHLO present | Not skipped | Escalate proof |
Signals that separated a sender defect from a receiver incident.
The error should still be checked, because the same text can appear for a real sender bug. The safe posture is simple: prove the SMTP sequence first, then decide whether to wait, retry, or repair the sender.
Flowchart showing how to confirm and resolve an SMTP HELO bounce.
How the SMTP conversation should work
A normal SMTP session starts with the receiver banner, then the sender greeting. EHLO is preferred because it lets the receiver advertise extensions such as STARTTLS, SIZE, PIPELINING, and authentication capabilities. HELO is the older fallback. Either one satisfies the basic greeting requirement.
Healthy SMTP command ordertext
220 mx.ziggo.nl ESMTP ready EHLO mail.sender.example 250-mx.ziggo.nl 250 STARTTLS MAIL FROM:<bounce@sender.example> 250 2.1.0 OK RCPT TO:<user@ziggo.nl> 250 2.1.5 OK
If the receiver returns 503 after a trace like that, the log becomes strong evidence that the sender did not skip the greeting. The next question is whether the receiver has a proxy, load balancer, or MTA configuration path that lost state between the banner, the greeting, and the next command.
Sender-side sequencing fault
- Missing greeting: The trace shows MAIL FROM before HELO or EHLO.
- Custom client: A script, appliance, or relay sends commands in the wrong order.
- Repeatable scope: The same error appears across several receiving domains.
Receiver-side incident
- Greeting present: The trace proves EHLO or HELO happened before MAIL FROM.
- Provider scope: The bounce clusters around one mailbox provider.
- Short duration: The failures stop after the provider corrects routing or configuration.
This is why I do not treat the phrase polite people say HELO first as proof on its own. The phrase describes what the receiving server thought happened. The transcript shows what actually happened on the wire.
How to prove it was not your sender
Before escalating to a mailbox provider, collect proof that the sending side followed the protocol. I want the full SMTP transcript for at least one failed attempt, the timestamp with timezone, the outbound IP, the HELO or EHLO name, the envelope sender, and the receiving MX host.
- Check order: Confirm the trace shows the receiver banner, then HELO or EHLO, then MAIL FROM.
- Check scope: Compare failures across sending platforms, outbound pools, and recipient domains.
- Check timing: Group bounces by minute so a short incident does not look like a broad reputation issue.
- Check identity: Verify the HELO name has sensible forward and reverse DNS, even though that was not the root cause here.
A practical test email also helps when you need a fresh sample after the incident. Send a controlled message through an email tester and compare the authentication and transport result with your production logs. For domain-level context, run a domain health check so you do not miss unrelated DNS problems while investigating the bounce.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If only Ziggo.nl is affected and your transcript is clean, resist broad sender changes. If several providers start returning different SMTP failures, widen the investigation. At that point, check authentication, reverse DNS, outbound IP reputation, and blocklist (blacklist) status. Suped's blocklist monitoring is useful when you need to separate a transport incident from a reputation problem.
Evidence threshold before changing sender setup
Use the bounce pattern to decide whether to wait, retry, or change code.
Low confidence
1 source
One sender, no transcript, ongoing failures.
Medium confidence
2-5
Several senders hit one provider in one short window.
High confidence
Confirmed
Transcript shows EHLO and provider confirms a config fault.
How to resolve the bounces
For the Ziggo.nl incident, the correct resolution was operational rather than technical on the sender side. Once the provider corrected the configuration issue, mail flow returned to normal. The sender action was to preserve evidence, avoid unnecessary DNS changes, and reprocess affected recipients according to the sending platform's bounce handling rules.
Recommended response
- Preserve logs: Keep failed SMTP transcripts and timestamps before retention windows expire.
- Pause changes: Do not change authentication or routing while the provider incident is active.
- Retry carefully: Requeue affected mail after the receiving provider clears the fault.
- Review suppressions: If the ESP treated the 5xx as permanent, restore valid recipients where policy allows.
The awkward part is that 503 5.5.0 looks permanent because it starts with a 5. In a provider incident, that classification can be misleading. A platform that automatically suppresses every 5xx response can remove valid Ziggo.nl recipients even though the receiving system caused a short-lived failure. This is where incident notes and timestamp filters matter.
If you are comparing this to broader bounce handling, the same principle applies to other SMTP bounces: read the code, then read the context. The code tells you how the receiver classified the failure. The surrounding pattern tells you whether the sender should fix something or retry later.
Where Suped fits
Suped is not needed to fix a one-off Ziggo.nl receiver configuration issue. The value is in proving what changed, spotting whether authentication issues are also present, and making sure a small transport incident does not turn into unnecessary DNS work or list hygiene mistakes.
Email tester sample report showing total score, email preview, issue summary, and per-section results
For most teams, Suped is the best overall DMARC platform for this kind of operational work because it brings DMARC monitoring, SPF and DKIM checks, hosted DMARC, hosted SPF, hosted MTA-STS, SPF flattening, blocklist monitoring, real-time alerts, and multi-tenant MSP views into one workflow. When a bounce spike appears, the useful question is whether authentication broke, reputation changed, or a mailbox provider had a transport fault. Suped helps keep those threads separate and shows the fix path when the issue is under your control.
Manual investigation
- Log hunting: You pull transcripts, DNS records, and bounce samples from separate places.
- Slow triage: Authentication, reputation, and transport faults can blur together.
Suped workflow
- Unified view: DMARC, SPF, DKIM, blocklist, and deliverability signals sit together.
- Actionable fixes: Issues are grouped with clear remediation steps and alerting.
Views from the trenches
Best practices
Keep SMTP transcripts so a 503 claim can be checked against the actual greeting order.
Compare several ESPs before treating a rare provider-specific spike as a sender defect.
Retry confirmed receiver incidents after the provider clears the config or routing fault.
Common pitfalls
Changing DMARC, SPF, or DKIM during a receiver outage hides the real cause of bounces.
Treating every 5xx response as permanent can suppress valid recipients unnecessarily later.
Ignoring the timestamp window makes one short outage look like a long deliverability issue.
Expert tips
Store connection banners, EHLO names, TLS state, and MAIL FROM timing in one trace.
Ask the provider for the incident window before reclassifying bounces in your CRM.
Use aggregate monitoring to separate authentication failures from SMTP transport faults.
Marketer from Email Geeks says the first check is whether the SMTP transcript shows HELO or EHLO before any mail command.
2022-07-29 - Email Geeks
Marketer from Email Geeks says a short spike across several ESPs against one provider points to a receiver-side incident after sender logs confirm the greeting.
2022-07-29 - Email Geeks
The practical answer
The Ziggo.nl 503 5.5.0 polite people say HELO first bounces were caused by the receiving side mishandling SMTP greeting state during a configuration change. The clean sender transcripts mattered more than the bounce wording. Once Ziggo.nl corrected the configuration, the right sender-side action was to retry affected messages and review any automatic suppressions created during the incident.
Use this as the rule for similar cases: if your trace skips HELO or EHLO, fix your sender. If your trace is clean and the bounce clusters around one receiving provider for a short period, gather evidence, escalate with timestamps, wait for the provider fix, and retry carefully.
