What causes bounce spikes on French ISPs like Orange, SFR & La Poste, and how can I troubleshoot them?
Published 14 Aug 2025
Updated 31 Jul 2026
12 min read
Summarize with
Updated on 31 Jul 2026: We updated this guide with current Orange limits and error-code checks, clearer greylisting guidance, safer SMTP retry advice, and expanded incident fields.
The direct answer: bounce spikes at French ISPs such as Orange, SFR, and La Poste are usually caused by a filtering or reputation change at the receiving side, a shared IP reputation swing, temporary throttling, a content classification issue, or an authentication problem that only becomes visible when those providers tighten acceptance. If the same campaign, sending platform, and shared IP suddenly bounce across several French domains, start by testing for a shared infrastructure or provider policy issue rather than treating it as a pure list hygiene problem.
The first troubleshooting move is not to guess the provider criteria. Get the raw SMTP rejection text for affected messages. ESP labels like hard bounce, soft bounce, or unclassified are platform interpretations after the rejection happened. The receiver gave a real SMTP reply during the delivery attempt, and that reply is the useful evidence.
French B2C delivery has local wrinkles. Orange and SFR have large consumer mail footprints, while Free and La Poste have their own mailbox bases and filtering patterns. Filtering decisions can react quickly to shared infrastructure behavior. A sender can have normal global metrics while a French segment shows a sharp, repeating spike. The fix still comes from the sender's own bounce text, timestamps, IPs, domains, retry history, and authentication results.
The most likely causes
When a spike repeats every week or every two weeks, look for a repeatable trigger. The trigger is often not a single bad address list. It can be a combination of cadence, volume, segment selection, shared IP traffic, and receiving-side enforcement.
- Shared IP: Another sender on the same pool can affect French provider acceptance even when your own complaints and bounces look stable elsewhere.
- Receiver throttling: A provider can defer or reject mail after a sudden connection, volume, or complaint pattern crosses its current threshold.
- Filtering update: Several French domains moving together can point to a common filtering rule or shared abuse signal.
- Authentication drift: A sender, subdomain, DKIM selector, return-path, or SPF include can change and fail only on part of the mailstream.
- Campaign pattern: A fortnightly blast to colder French recipients can create a local spike even when the total list is not stale.
- Blocklist hit: A blocklist or blacklist event affecting the sending IP or domain can show up first at stricter local providers.
Do not troubleshoot from the ESP category alone
An unclassified bounce category only says the sending platform did not map the reply into one of its own buckets. It does not mean the rejection text is missing. Ask for the raw event, raw JSON, SMTP transcript, or provider log line for a few recent affected recipients.
Flowchart for diagnosing a French ISP bounce spike.
Get the raw SMTP reply first
The raw SMTP reply is the difference between a hunch and a fix. It tells you whether the receiver complained about reputation, policy, content, authentication, rate, recipient status, mailbox status, DNS, or something else. A category like block or bounce does not carry enough meaning on its own.
Raw replies worth separatingtext
421 4.7.0 Temporarily deferred, try again later 451 4.7.1 Service unavailable, please retry 550 5.1.1 Recipient address rejected 550 5.7.1 Message rejected due to policy 554 5.7.1 IP reputation block
The exact code and wording matter. A 5.1.1 recipient rejection is not the same problem as a 5.7.1 policy rejection. A 4xx reply is a temporary deferral, so the sending MTA should queue the message and retry. A 5xx reply is a permanent failure for that rejected attempt. Reduce sending pressure only when the reply text or acceptance pattern indicates throttling; do not infer rate limiting from every 4xx code.
Do not label every temporary deferral as greylisting. Greylisting usually produces an initial 4xx response followed by acceptance after a normal retry. Repeated reputation or rate-limit deferrals require a different response. Compare the first attempt, later attempts, queue age, and final disposition before classifying the pattern.
ESP bounce category
- Timing: Assigned after the delivery attempt.
- Meaning: Based on that platform's rules.
- Risk: Can hide the real rejection reason.
Raw SMTP reply
- Timing: Returned by the receiver during delivery.
- Meaning: Contains the provider's reason text.
- Value: Separates rate, reputation, policy, and recipient failures.
For SFR specifically, the wording can be more useful than the high-level class. Save the full rejection text, enhanced status code, message ID, and timestamp in the incident notes so the ESP can find the exact delivery attempt.
Use Orange's current error codes and limits
Orange appends provider-specific numbers to many SMTP replies. Keep both the standard SMTP status and the Orange suffix, because the suffix can identify a connection limit, invalid recipient, authentication failure, suspected spam decision, or reputation throttle.
|
|
|
|---|---|---|
104 | Too many simultaneous connections | Reduce concurrency toward two connections per sending IP. |
109 | Too many messages per connection | Reduce the batch toward 100 messages per connection. |
416 | Invalid Orange or Wanadoo recipient | Suppress that address rather than retrying it. |
506 | Message blocked as suspected spam | Compare campaign content and recipient engagement, then escalate with samples. |
515 or 535 | DMARC failed or DKIM signature missing | Fix the affected source, selector, and domain match before retrying. |
988 to 990 | Rate limited for low reputation | Let normal retries run, lower pressure, and resume with engaged recipients. |
Common Orange reply suffixes and incident actions
Orange currently recommends no more than 100 messages per connection, two simultaneous connections per sending IP, and 100 recipients per message. It also publishes a 45 MB message limit and requires TLS 1.2 or later. Reputation can lower the effective sending limits, so use the returned code and observed acceptance rate rather than treating the published values as guaranteed capacity.
Keep Orange and Wanadoo together
Group Orange and Wanadoo recipients under the same provider view, but retain the original recipient domain. That gives you one operational trend without losing the domain detail needed for samples and escalation.
Build the incident table
Once the raw replies are available, build a small incident table to isolate what changed at the same time as the spike. Capture the affected provider, recipient domain, sending IP, campaign, subject family, sending subdomain, return-path, DKIM selector, reply code, exact text, first and last attempt times, retry count, queue age, and final disposition.
|
|
|
|---|---|---|
 Provider | Shows whether Orange is isolated. | Orange vs SFR |
 Provider | Shows whether SFR moved too. | SFR vs peers |
 Provider | Shows local provider spread. | La Poste vs all |
IP pool | Shared IPs add noise. | Pool vs pool |
Reply code | Splits temp and final. | 4xx vs 5xx |
Auth | Finds SPF or DKIM drift. | Pass vs fail |
Compact incident fields for French ISP bounce spikes
If Orange alone moved, read the Orange subset first and compare it with recent Orange-only engagement. If Orange, SFR, and La Poste moved together, treat it as a shared infrastructure or policy signal until the raw replies prove otherwise. The same method applies when diagnosing Orange.fr failures in isolation.
Check authentication before blaming the ISP
Authentication problems can look like provider-specific deliverability problems when only part of the mailstream uses the broken sender, selector, or return-path. Check SPF, DKIM, DMARC, reverse DNS, HELO, and domain match before contacting a provider or asking the ESP to escalate.
- SPF: Confirm the visible sender path is authorized and the SPF record stays under lookup limits.
- DKIM: Confirm the affected messages have a DKIM signature and the selector's public key resolves.
- DMARC: Confirm SPF or DKIM passes with domain match for the visible From domain.
- DNS: Confirm rDNS, HELO, MX, and TXT records resolve consistently during the spike window.
Suped's DMARC monitoring shows whether the affected French traffic is authenticating, which sources are verified, and which senders are failing SPF or DKIM. For this workflow, Suped helps match authentication failures to the sending source and spike window. The raw SMTP replies still need to come from the ESP's delivery logs.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
For a quick outside-in check before digging into message logs, run the domain through Suped's domain health check. It does not replace raw SMTP evidence, but it catches common DNS and authentication mistakes that can reduce provider acceptance during a spike.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Separate reputation, rate control, content, and recipient quality
After authentication, split the problem into four lanes: reputation, rate control, content, and recipient quality. Each needs a different fix. Changing subject lines will not repair a shared IP reputation hit. Slowing the queue will not fix a broken DKIM signature. Removing old addresses will not solve a content rejection if the same creative is rejected for active buyers. An invalid-recipient code needs suppression, not a reputation warm-up.
Reputation or blocklist
- Signal: Rejections mention IP, reputation, spam policy, abuse, or blacklist.
- Action: Pause cold French segments and ask the ESP about shared pool health.
- Proof: Compare other senders, IP pools, and blocklist or blacklist status.
Throttling or rate limit
- Signal: Replies mention temporary deferral, rate, connection, or retry later.
- Action: Reduce concurrency and restart with recent openers and buyers.
- Proof: Acceptance improves when volume and retry pressure drop.
For content, compare the exact campaigns sent just before each spike. Keep the French domains separate in reporting. Review subject lines, URL domains, image hosts, redirect chains, unsubscribe headers, brand changes, and whether the campaign hit inactive recipients at a higher rate than usual.
Blocklist or blacklist checks are part of the evidence, not the full diagnosis. Suped's blocklist monitoring tracks IP and domain listings alongside authentication signals, which helps when the same spike crosses more than one provider.
Shared IP escalation checklist
- Evidence: Send the ESP raw replies, affected domains, timestamps, campaign IDs, and sending IPs.
- Question: Ask whether other customers on the same pool saw French ISP rejects.
- Request: Ask for pool movement, rate caps, or provider escalation if the evidence points to the IP.
- Limit: Do not ask for a generic deliverability review without the SMTP replies.
Run a controlled troubleshooting sequence
Use a tight sequence because random changes blur the evidence. Change one major variable at a time and watch French provider acceptance recover or fail.
- Collect: Export the last 14 days of raw bounce events before logs roll off in the sending platform.
- Group: Split by provider, reply code, sending IP, domain, campaign, recipient engagement, and final disposition.
- Confirm: Validate SPF, DKIM, DMARC, rDNS, HELO, and MTA-STS if the domain uses it.
- Reduce: Slow French-domain sends and stop nonessential retries when the reply text shows rate pressure. Let the ESP's normal retry queue handle other 4xx deferrals.
- Segment: Resume with recent openers, buyers, and low-complaint recipients first.
- Escalate: Send the ESP a concise evidence pack if shared IP reputation is likely.
A live message test also helps separate inbox rendering, authentication headers, and basic placement evidence. Use Suped's email tester after checking the raw bounces, not instead of checking them. The live test shows what a message looks like now, while the bounce log explains why past attempts failed.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
If the spike appears during a warm-up or after switching sending infrastructure, compare it with known IP warming bounces. French providers can throttle mail when a sender jumps from little history to large bursts, especially on shared infrastructure.
When to contact the ESP or provider
Contact the ESP when the evidence points to shared IP reputation, missing raw bounce visibility, or provider-side blocking that the ESP controls. On a shared IP, the ESP has the relationship, the pool view, and the delivery logs. A third party cannot retrieve raw rejects for mail it did not send.
The request should be specific. Ask for raw SMTP replies for example recipients at Orange, SFR, and La Poste during the spike window. Ask whether the shared pool had other French-provider incidents. Ask whether the ESP can move the traffic to a cleaner pool or apply French-domain throttles while you reduce risk.
A useful escalation note
Use this wording: "We saw a French ISP bounce spike between 09:00 and 13:00 UTC affecting Orange, SFR, and La Poste. Please provide the raw SMTP replies for these sample message IDs and confirm whether the sending IP pool had provider-level throttling or reputation blocks during the same window."
If support only returns a category, ask again for the raw event fields. Many platforms expose the raw reason in an event payload, profile activity record, export, API, or support-only log view. If logs expire after a short retention period, make collection part of the incident process.
For the general mechanics of reading bounce evidence, keep a separate playbook for troubleshooting bounces so the team does not restart from scratch every time a provider spikes.
Views from the trenches
Best practices
Save raw SMTP replies within 14 days so short log retention does not erase the evidence.
Group French provider bounces by IP, campaign, code, and exact text before changing sends.
Use ESP support for shared IP incidents because they own pool data and provider contacts.
Common pitfalls
Treating an unclassified bounce as missing evidence instead of asking for raw event data.
Changing content, cadence, and segment rules at once, which blurs the cause of recovery.
Assuming list quality is the cause when several French providers reject together.
Expert tips
Ask for the raw JSON bounce event because the useful reason is often hidden in the payload.
Save example message IDs with timestamps so support can query the exact delivery attempt.
Treat ESP bounce classes as hints, not facts, because SMTP has the authoritative reply.
Marketer from Email Geeks says multiple French ISPs rejecting together points to a shared filtering or infrastructure signal, so the full SMTP replies matter more than the high-level bounce count.
2024-04-02 - Email Geeks
Marketer from Email Geeks says bounce categories are platform guesses made after the reject, while the raw SMTP response has the receiver's actual reason for that attempt.
2024-04-02 - Email Geeks
Recover French ISP delivery safely
Recover a French ISP bounce spike with evidence instead of guesswork. Pull the raw SMTP replies, split them by provider and IP, verify authentication, check blocklist and blacklist evidence, review retry history, and restart with the safest French recipients first. If the sending IP is shared, bring the ESP in with message IDs, timestamps, and raw replies.
Suped supports the ongoing monitoring part of this workflow. DMARC reports, automated issue detection, alerts, and blocklist monitoring keep authentication and reputation evidence with the incident. Suped does not replace the ESP's raw delivery logs, which remain the source for provider replies and retry outcomes.
