SFR SMTP Error Codes
Navigate SFR's complex multi-domain email infrastructure. Understand SFR_IN error codes, reputation-based limits, and 2-hour blocking system.
📡 About SFR Grand Public
Company Overview
- • Founded in 1987, initially mobile telephony
- • Expanded to Internet access and television
- • 2011: Vivendi subsidiary
- • 2014: Acquired by Numericable
- • 2016: Acquired by Altice
- • Single infrastructure for all email domains
Email Infrastructure
- • MX: smtp-in.sfr.fr for all domains
- • Covers 20+ email domains
- • Unified filtering policy
- • Uses market anti-spam solutions
- • Partners with Signal Spam for FBL
🌐 SFR Email Domains
All these domains use the same infrastructure. SFR Grand Public applies the same filtering policy to all of its email services:
🔍 Understanding SFR_IN Error Codes
SFR uses a unique error code system: SFR_IN_XXX
Code Structure:
- SFR_IN_ - SFR Grand Public code for inbound connection
- First digit - Internal information to SFR Grand Public
- Last two digits - Specific error type:
Each code has its own trigger threshold based on a specific observation period
SFR SMTP Error Codes Explained
421 4.7.0
SFR closed the connection after accumulating too many SMTP errors in a short period.
Protocol mistakes (bad HELO, premature QUIT, missing TLS) cause repeated 421 events. If the pattern continues, SFR escalates to SFR_IN codes.
How to Fix:
- ✓Validate SMTP command order and enforce STARTTLS where required.
- ✓Ensure your MTA respects SFR’s two-connection limit per IP.
- ✓Retry with exponential backoff to avoid hitting an automatic two-hour suspension.
- ✓Monitor logs for authentication failures or unexpected 5xx responses.
450 4.7.1
SFR_IN_101SFR detected too many spam complaints and blocked the IP for two hours.
SFR_IN_101 is triggered when subscribers mark excessive messages as spam. The block affects all SFR brands (sfr.fr, neuf.fr, numericable.fr).
How to Fix:
- ✓Pause SFR traffic and remove unengaged or purchased lists immediately.
- ✓Review Signal Spam feedback loop reports for complaint trends.
- ✓Slow the send rate and resume with high-engagement cohorts first.
- ✓Audit creative, frequency, and consent sources before ramping back up.
450 4.7.1
SFR_IN_102SFR found malware or dangerous attachments and blocked the IP for two hours.
If your outbound stream includes executable attachments or infected links, SFR issues SFR_IN_102 and suspends the connection.
How to Fix:
- ✓Scan outbound messages with multiple antivirus engines before sending.
- ✓Disable file types that SFR routinely blocks (EXE, SCR, certain ZIP archives).
- ✓Investigate compromised accounts or relays immediately.
- ✓Rebuild trust with a gradual ramp once the issue is resolved.
450 4.7.1
SFR_IN_103The IP generated too many SMTP errors unrelated to other SFR_IN codes.
Mismatched TLS, invalid commands, or timeouts lead to SFR_IN_103. The IP is paused for two hours to protect the infrastructure.
How to Fix:
- ✓Confirm your HELO/EHLO string is a valid, resolvable hostname.
- ✓Increase SMTP timeouts so the connection does not drop mid-session.
- ✓Avoid testing scripts that intentionally send malformed commands.
- ✓Limit retry attempts during the two-hour suspension window.
450 4.7.1
SFR_IN_104Too many messages were addressed to non-existent SFR users.
SFR counts unknown users aggressively. Hit the threshold and you receive a two-hour block that resets with each offense.
How to Fix:
- ✓Remove hard bounces from all SFR domains immediately.
- ✓Use confirmed opt-in for French lists to avoid typos.
- ✓Clean legacy data sets before new campaigns, especially after mergers.
- ✓Segment SFR addresses and monitor bounce rates separately.
450 4.7.1
SFR_IN_105The sending IP exceeded the volume allowed by its current reputation tier.
SFR ties connection, message, and hourly limits to reputation. Overrunning those thresholds produces SFR_IN_105 and a two-hour suspension.
How to Fix:
- ✓Throttle deliveries so hourly volume stays within SFR’s recommended levels.
- ✓Warm new IPs gradually and distribute volume across multiple days.
- ✓Avoid resending to the same SFR users multiple times in a short window.
- ✓Track SFR-specific metrics in your deliverability dashboards.
450 4.7.1
SFR_IN_106The IP sent too many messages to the same recipient or group within a short interval.
SFR monitors per-user frequency. Automated testing or transactional retries can look like abuse and trigger SFR_IN_106.
How to Fix:
- ✓Implement per-user frequency caps for SFR addresses.
- ✓Stagger transactional retries instead of retrying instantly.
- ✓Group low-importance alerts into digests rather than multiple sends.
- ✓Educate support teams to avoid repeated resends to the same mailbox.
450 4.7.1
SFR_IN_107SFR rejected the session because the HELO/EHLO name or reverse DNS is invalid.
SFR expects the connecting IP to have proper reverse DNS and to announce a matching hostname. Typos or generic cloud hostnames trigger SFR_IN_107.
How to Fix:
- ✓Set PTR records that map each IP to a descriptive, unique hostname.
- ✓Update the SMTP HELO string to match the reverse DNS value.
- ✓Avoid generic cloud hostnames like ip-10-1-1-1.compute.internal.
- ✓Document DNS changes so they survive infrastructure migrations.
550 5.1.1
SFR confirmed the recipient does not exist. Treat as a hard bounce.
User unknown bounces count toward SFR_IN_104. Remove the address immediately to protect reputation.
How to Fix:
- ✓Delete the address after the first bounce and avoid further attempts.
- ✓Validate signups with double opt-in for French subscribers.
- ✓Synchronise suppression lists between ESPs and transactional systems.
- ✓Alert stakeholders when VIP contacts bounce so they can verify the mailbox.
552 5.2.2
The recipient’s mailbox is full and cannot accept new mail.
Treat 5.2.2 as a soft bounce. If it repeats over multiple sends, suppress the address to protect deliverability.
How to Fix:
- ✓Retry for a few days before suppressing the contact.
- ✓Encourage key recipients to free up space or provide alternate addresses.
- ✓Escalate to sales or support if the mailbox belongs to a major customer.
- ✓Exclude chronically full mailboxes from high-frequency marketing campaigns.
550 5.7.1
SFR rejected the message because the content or domain violates its spam policy.
550 5.7.1 indicates SFR’s filters still see risky behaviour after multiple deferrals. Permanent remediation is required before sending resumes.
How to Fix:
- ✓Audit content, links, and headers for spam-like characteristics.
- ✓Remove recent imports or unverified purchases from French lists.
- ✓Share remediation actions (complaint reduction, authentication fixes) when contacting SFR support.
- ✓Resume gently with a small, high-engagement segment once trust improves.
SFR Best Practices
Reputation Management
- •Connection limits based on reputation
- •Messages per connection varies by reputation
- •Hourly connection limits by reputation
- •Build reputation gradually over time
Authentication
- •SPF authentication recommended
- •DKIM signing recommended
- •Use consistent sending domains
- •Avoid shared infrastructure if possible
Error Code System
- •SFR_IN prefix for inbound connections
- •Last two digits indicate error type
- •All blocks last exactly 2 hours
- •Each code has specific thresholds
List Quality
- •Monitor invalid recipient rates (SFR_IN_104)
- •Track spam classifications (SFR_IN_101)
- •Access FBL via Signal Spam
- •Clean lists regularly to avoid blocks
Technical Configuration
SFR Connection Settings
MX: smtp-in.sfr.fr
concurrent_connections_per_IP = based_on_reputation
messages_per_connection = based_on_reputation
connections_per_IP_per_hour = based_on_reputation
SPF: Recommended
DKIM: Recommended
Complaint Feedback Loops
📈 Aggregated FBL
CSV format with daily complaint volumes by IP:
- • Available to Signal Spam members only
- • Daily aggregated data
- • IP-based complaint tracking
📧 ARF Feedback Loop
Individual complaint reports in ARF format:
- • Signal Spam members
- • Validity FBL ($18+ per year)
- • Real-time complaint notifications
Note: Some monitoring tools like Postmastery integrate data from the aggregated FBL through their partnership with Signal Spam, making it easier to track SFR complaint rates.
⏱️ Important: 2-Hour Blocking System
Block Duration
- • All SFR_IN blocks last exactly 2 hours
- • No early removal possible
- • Blocks apply per sending IP
- • Multiple blocks can overlap
Prevention Strategy
- • Monitor error rates closely
- • Stay below trigger thresholds
- • Use multiple IPs for large volumes
- • Implement circuit breakers
📞 Contacting SFR Support
Contact SFR's abuse handling unit at: abuse@sfr.fr
Include the following information:
- ✓Date and time of occurrence
- ✓Sending IP address(es)
- ✓Sending hostname(s)
- ✓Sending domain
- ✓Complete SMTP error with SFR_IN code
Struggling with SFR Delivery?
SFR's multi-domain infrastructure and 2-hour blocking system require careful management. Let us help you navigate their reputation-based limits and avoid costly blocks.