What to do when Orange.fr is having email delivery issues?
Published 30 Jul 2025
Updated 9 Aug 2026
12 min read
Summarize with
Updated on 9 Aug 2026: We updated this guide with Orange's current requirements and clearer error-code handling.
When Orange.fr is having email delivery issues, first slow or pause non-urgent mail to Orange.fr and Wanadoo.fr, keep transactional mail on a conservative retry schedule, preserve all 4xx evidence, and check whether the issue is receiver-side or caused by your own authentication, reputation, or SMTP setup. A temporary 421 response is not a reason to suppress recipients. It is a reason to retry later, with lower pressure on Orange's servers.
Orange's Orange Postmaster guidance, last updated May 15, 2026, is the baseline for this work. It covers authentication, rDNS, HELO, TLS, connection limits, message limits, complaint thresholds, and common Orange error codes. If your sending setup does not meet that baseline, fix your side before asking Orange to investigate.
First decision
If you see a 421 service refused response, including OFR_108 in historical incident examples, stop treating the queue like normal volume. Hold marketing and bulk mail, let urgent mail retry with queue backoff, and watch whether the same response continues through later attempts.
First response when Orange.fr starts failing
The first job is classification. Determine whether Orange is refusing mail temporarily, throttling your traffic for its behavior, rejecting messages because authentication failed, or blocking a sender because reputation crossed a threshold. The answer changes the action immediately.
- Pause: Hold non-essential campaign and bulk mail to Orange.fr and Wanadoo.fr while temporary service refusals remain elevated.
- Protect: Keep receipts, password resets, one-time codes, and account notices on retry, but reduce concurrency and queue depth.
- Segment: Move Orange.fr and Wanadoo.fr to a separate queue so the rest of your mail stream is not slowed unnecessarily.
- Preserve: Keep recipients active after 421 and other 4xx responses. Save SMTP transcripts, timestamps, sending IPs, and message categories.
- Resume: Restart gradually after errors drop. A full queue release can restart the same problem even after Orange recovers.
Flowchart for pausing bulk mail, retrying critical mail, checking sender setup, and resuming slowly.
If only Orange-hosted domains are affected and the errors are mostly temporary, treat it as an Orange-specific incident until the evidence changes. If several unrelated mailbox providers begin failing together, treat it as a sender-side problem first.
A user who cannot sign in, open Orange webmail, or connect through IMAP or POP has a mailbox-access problem, not an inbound email delivery diagnosis. Test webmail and the mail client's account settings separately. Do not change recipient suppression or sender authentication because of a local access error.
What the Orange.fr SMTP error is telling you
Orange errors usually include the SMTP class, a French and English explanation, and an OFR code. The SMTP class tells you whether to retry. The OFR code and full response text tell you what to fix or how to pace the queue.
Example Orange temporary refusaltext
421 opmta1mti07nd1 smtp.orange.fr 7xfWn7Ublsk48 Service refuse. Veuillez essayer plus tard. Service refused, please try later. OFR_108 [108]
In that historical example, 421 is the most important part. The server did not accept the message for that attempt, but it did not say the address is invalid. Orange's current published table does not list code 108, so classify the current SMTP status and full text before acting. Do not clean the recipient, change consent status, or mark the contact as bad from this response alone.
|
|
|
|---|---|---|
421 | Temporary refusal | Retry later with slower pacing |
OFR_108 | Historical service-refusal example | Follow the current SMTP class and response text |
99 / 103 | Sending IP blacklisted by Orange | Correct the cause and contact Orange |
104 | Too many connections | Limit concurrent connections |
107 | Missing PTR record | Publish valid reverse DNS for the sending IP |
109 | Too many messages per connection | Reduce messages per connection |
20x | Invalid HELO or EHLO | Use a resolvable fully qualified hostname |
397 / 398 | Sender-domain SPF error | Correct the SPF TXT record and allow for DNS TTL |
405 | Sender-domain DNS error | Publish a valid A or MX record |
416 | User does not exist | Suppress the invalid recipient |
425 | Sender domain on a blacklist | Investigate the blocklist or blacklist cause |
506 | Message blocked as suspected spam | Check consent, complaints, content, and reputation |
515 | DMARC failure | Fix authentication before retrying |
519 | Sending IP not authorized by SPF | Authorize the source or stop its mail |
535 | DKIM signature missing | Sign the message and verify DKIM |
988-990 | Low-reputation rate limit | Retry later and correct the reputation cause |
Common Orange signals and first actions.
Do not suppress on 421
- Temporary: A 421 response means Orange rejected this delivery attempt, not the recipient.
- Permanent: A 5xx invalid recipient or authentication rejection needs remediation before further sends.
- Evidence: Save the raw response, sending IP, From domain, envelope sender, and first-seen time.
How to separate an Orange incident from a sender issue
An Orange incident is likely when failures cluster at Orange.fr and Wanadoo.fr, the response is temporary, and other mailbox providers look normal. A sender issue is likely when authentication failures, missing PTR records, bad HELO, high complaints, or blocklist (blacklist) signals appear across multiple destinations.
Receiver incident pattern
- Scope: Mostly Orange.fr and Wanadoo.fr domains fail.
- Codes: Responses say 421, service refused, retry later, or another temporary deferral.
- Timing: Failures begin suddenly across otherwise stable traffic.
Sender issue pattern
- Scope: Multiple providers fail or spam placement rises everywhere.
- Codes: SPF, DKIM, DMARC, PTR, HELO, or blacklist errors repeat.
- Action: Fix the root cause before pushing deferred volume back into the queue.
Before blaming the receiver, check the domain baseline with a domain health checker. Use it to review DMARC, SPF, DKIM, MX, DNS, and sender identity before changing retry rules.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
If the check is clean and only Orange-hosted domains are failing, keep the pause in place and monitor recovery. If the check finds a broken record, missing signature, or bad DNS, fix that first and then restart with a small controlled test.
Authentication and reputation checks before retrying
Orange's current guidance requires a static sending IP, valid PTR, a resolvable fully qualified HELO or EHLO, and valid A or MX records for the sending domain. It says to enable encryption with TLS 1.2 or newer because older versions are unsupported. SPF, DKIM, and DMARC are mandatory and must all pass. ARC sealing is strongly recommended for forwarded messages, and an email cannot exceed 45 MB.
Illustrative authentication recordsdns
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:d@example.com" selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIIB..." example.com. TXT "v=spf1 include:_spf.sender.example -all"
These are syntax examples, not records to copy. Replace every placeholder with your own authorized sources, DKIM public key, and reporting address. A record that exists in DNS can still fail on a delivered message, so verify the authentication results in message headers and DMARC data.
Practical baseline
- SPF: The envelope sender domain authorizes the sending IP or hosted sender, and SPF passes.
- DKIM: Every production stream signs with a stable selector and current key, and DKIM passes.
- DMARC: DMARC passes. Senders above 1,000 messages per day also match the Header From domain to the authenticated domains.
- PTR: The sending IP has reverse DNS that points to a real hostname and resolves correctly.
- TLS: The sending MTA supports TLS 1.2 or newer.
Suped's DMARC monitoring shows which sending sources pass, which fail, and which unknown sources use the domain. Suped's blocklist monitoring adds IP and domain blacklist context. Keep the raw Orange SMTP logs as well because those logs, not DMARC reports, contain OFR codes and queue deferrals.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Use the monitoring view to answer a narrow question: is Orange refusing otherwise healthy mail, or is Orange rejecting mail that fails its published policy? That distinction saves time and prevents an outage response from hiding a sender defect.
Requirements for senders over 1,000 messages a day
Orange applies a specific checklist to senders that deliver more than 1,000 messages per day. Meeting the technical checks alone is not enough. Orange also evaluates sender identity, consent, complaint handling, and unsubscribe behavior.
- Authenticate: Make SPF, DKIM, and DMARC pass, with the Header From domain matching the authenticated domains.
- Identify: Use a display name that accurately identifies the entity that obtained the recipient's consent.
- Document: Host a website on the Header From domain with company identity, address, consent information, and legal notices.
- Get consent: Use verified opt-in, never buy lists, and provide an easy one-click unsubscribe.
- Label traffic: Add a stable Feedback-ID header so complaints can be tied to the right mail stream.
- Handle feedback: Process bounces and complaint feedback promptly if your organization has authorized feedback-loop access.
- Limit complaints: Keep the complaint rate below Orange's protection thresholds and investigate every sudden increase.
Complaint-rate threshold
Orange currently says a spam-report rate of 0.6% or higher can trigger protection mechanisms, and it intends to move gradually toward 0.3%. Use 0.3% as the internal ceiling now. Staying below it does not guarantee acceptance because reputation and sending behavior still affect filtering.
Queue pacing and retry strategy
Retry behavior matters because receiver incidents get worse when every sender retries aggressively. Orange recommends up to two simultaneous connections per sending IP, 100 messages per connection, and up to 100 recipients per message. Treat these as published limits, not targets. Use lower limits when reputation is weak or temporary refusals rise.
Orange.fr retry pacing
Suggested internal operating bands for Orange-specific queues, not official Orange thresholds.
Normal
0-1% 4xx
Small temporary deferral level
Slow
1-5% 4xx
Deferrals rising
Pause bulk
>5% 4xx
Receiver pressure or incident pattern
Fix first
Any auth 5xx
Authentication or policy rejection
- Throttle: Cap the Orange queue to two simultaneous connections per IP, then go lower during active 421 spikes.
- Batch: Keep messages per connection at 100 or lower when service refused responses increase.
- Separate: Use different queues for Orange-hosted domains, transactional mail, and marketing mail.
- Expire: Set a sensible queue lifetime. A time-sensitive promotion should not keep retrying for days.
- Audit: Track first seen, last seen, retry count, SMTP response, and campaign or message type.
After errors drop, send one real message to a controlled Orange.fr address and inspect the headers with the email tester before reopening full traffic.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
One successful test does not prove full recovery. Use it as a gate before increasing volume, then watch the fresh 4xx rate, delivered volume, and complaint rate in short intervals.
When to contact Orange.fr postmaster
Escalate after checking your own setup and gathering evidence. A useful postmaster request is specific. It shows Orange that your mail stream is authenticated, your retries are controlled, and the issue is still happening.
- Include: Sending IPs, From domain, envelope sender, HELO, sample recipient domains, UTC timestamps, and raw SMTP responses.
- Exclude: Vague screenshots, ticket text without codes, and reports that omit sending IP or message class.
- Prove: Authentication status, bounce classification, suppression rules, opt-in source, and recent complaint rate.
- Ask: Whether the current deferrals are incident-related, reputation-related, or policy-related.
|
|
|---|---|
SMTP text | Shows the exact Orange code |
IP list | Lets Orange inspect reputation |
Auth proof | Rules out SPF, DKIM, and DMARC |
Retry plan | Shows you are reducing load |
Escalation packet checklist.
If the pattern is sustained throttling rather than a short incident, the Orange.fr throttling notes are more specific. For wider regional patterns, use the French ISP bounces guide. The Orange complaint threshold changes article explains the 0.6% trigger and Orange's announced move toward 0.3%.
Where Suped fits in the workflow
Suped covers the sender-side verification in this workflow. Suped aggregates DMARC results, maps sending sources, checks DNS, tracks blocklist (blacklist) signals, and alerts teams to authentication changes. Orange-specific SMTP deferrals still come from your MTA or sending provider logs, so keep those logs alongside Suped's diagnostics.
Manual workflow
- Collect: Pull bounces, queue logs, DNS records, and complaint data from separate places.
- Compare: Manually decide whether a source is trusted, unknown, broken, or spoofed.
- React: Wait until someone notices a spike, then reconstruct the timeline.
Suped workflow
- Detect: Automated issue detection flags authentication and source problems early.
- Alert: Alerts notify the team when authentication failures exceed expected levels.
- Fix: Guided steps explain what to change in DNS, sender setup, or policy staging.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Use Suped to confirm whether the affected source still authenticates and whether domain or IP reputation changed. Use the sending system to track OFR codes, deferral rates, queue age, and retry counts. This division keeps receiver incidents separate from sender defects.
Views from the trenches
Best practices
Keep Orange.fr and Wanadoo.fr in a separate queue so pauses do not block other mail.
Save SMTP transcripts with timestamps before changing suppression or retry rules.
Restart in measured batches and watch fresh 4xx rates before raising the limit again.
Common pitfalls
Treating temporary 421 deferrals as hard bounces removes valid recipients too fast.
Retrying every queued message at once can extend a receiver-side incident for everyone.
Blaming Orange before checking SPF, DKIM, DMARC, PTR, HELO, and blocklists wastes time.
Expert tips
Use complaint rate and bounce trend alerts to detect Orange.fr issues early enough to act.
Keep transactional mail in its own retry lane with tighter caps during incidents.
Document the exact error code because a temporary 421 needs different action than OFR_515.
During a January 2022 incident, Orange asked senders to hold nonessential traffic for 4-5 hours because retries into 421 errors added load.
2022-01-13 - Email Geeks
A January 2022 report treated OFR_108 as a temporary service refusal, not a reason to suppress recipients.
2022-01-13 - Email Geeks
A practical Orange.fr recovery plan
The right response is calm queue control plus evidence. Pause nonessential Orange.fr and Wanadoo.fr traffic when temporary errors spike, keep critical mail retrying gently, and avoid any recipient cleanup until the response is permanent.
- Short incident: Pause bulk traffic, preserve recipients, and resume slowly after fresh tests pass.
- Sender defect: Fix SPF, DKIM, DMARC, PTR, HELO, blocklist (blacklist), or complaint problems before retrying.
- Ongoing throttle: Gather exact codes, samples, timestamps, and retry limits before contacting Orange.
Suped keeps the sender-side evidence in one operational view: DMARC status, sending sources, DNS diagnostics, blocklist and blacklist signals, alerts, and remediation steps. Pair it with the SMTP queue logs that contain Orange's response codes.
