Sorun Giderme·
17 Haziran 2026
E-posta sunucunuz "421 Too Many Connections" hatasıyla reddetmeye başladığında, gönderim kuyruğunuz tıkanır ve pazarlama kampanyalarınız kesintiye uğrar. Bu kılavuz, hatanın teknik kökenini açıklıyor ve kalıcı çözüm adımlarını sıralıyor.
SMTP protokolü, RFC 5321 ile standartlaştırılmıştır. Bu RFC, 4xx kodlarını "geçici ret" (temporary failure) olarak tanımlar: sunucu isteği kalıcı olarak reddetmemiştir; ancak belirtilen kısıtlamalar ortadan kalkana kadar bağlantıyı kabul etmeyecektir. 421 kodu özelinde RFC 5321, Bölüm 4.2.1'de şu tanımı verir: "Service not available, closing transmission channel." Bu, alıcı MTA'nın (Mail Transfer Agent) kaynak koruma amacıyla bağlantıyı kapattığı anlamına gelir.
Büyük servis sağlayıcılar bu sınırı farklı biçimlerde uygular. Google Workspace, tek bir gönderen IP'den saniyede en fazla 5 SMTP bağlantısına izin verirken Microsoft 365 (Exchange Online Protection), saatlik bağlantı eşikleri ve alıcı başına mesaj kotaları belirler. Bu kotalar, Google Postmaster Tools ve Microsoft'un Exchange Online Sınırları belgelerinde kamuya açık biçimde yayımlanmaktadır.
Hata mesajı tam metin olarak değişkenlik gösterebilir:
421 Too many connections from your IP421 4.7.0 Too many connections421 Connection rate limit exceeded421 4.3.2 Service not availableTüm bu varyantlar aynı kök soruna işaret eder: gönderen tarafın bağlantı davranışı, alıcı sunucunun politikasını ihlal etmektedir.
Hatanın neden kaynaklandığını anlamak, doğru çözümü uygulamanın ön koşuludur. En yaygın beş neden şunlardır:
E-posta gönderim yazılımları, performansı artırmak için birden fazla TCP bağlantısını paralel açar. Alıcı sunucu, tek bir IP'den eş zamanlı bağlantı sayısını kısıtladığında 421 döner. Postfix kullanan sistemlerde bu, smtp_destination_concurrency_limit parametresiyle kontrol edilir; varsayılan değer 20'dir, ancak Gmail gibi büyük sağlayıcılar bu sayının çok altında bir eşik uygular.
Yeni bir IP adresinden yüksek hacimde posta göndermek, alıcı sunucuların kara liste kontrollerini ve itibar algoritmalarını tetikler. IP ısınması (IP warming) süreci atlandığında, sunucu bağlantıları 421 ile keserek spam önleme mekanizmasını devreye sokar.
Birden fazla IP içeren gönderim havuzlarında tüm trafiğin tek IP üzerinden yönlendirilmesi, o IP'nin kotasını anında doldurar. Havuz dengeleme (pool balancing) mekanizmasındaki bir hata ya da DNS sorunları bu durumu tetikleyebilir.
Büyük kampanyaların anlık olarak başlatılması, kısa sürede binlerce bağlantı oluşturur. Özellikle milyonluk listelere yönelik "blast" gönderimleri, sunucu tarafında oran sınırlama (rate limiting) kurallarını tetikler.
Sunucunuzda çalışan bir zararlı yazılım ya da ele geçirilmiş bir hesap, istemsiz yüksek hacimli gönderim başlatabilir. Bu durumda 421, aslında bir güvenlik sinyalidir.
Sorunu tespit etmek için aşağıdaki sırayı izleyin:
Postfix sistemlerde /var/log/mail.log, Exim'de /var/log/exim4/mainlog dosyaları incelenmelidir. 421 yanıtlarının hangi saatlerde yoğunlaştığını, hangi hedef sunuculara yapılan bağlantılarda oluştuğunu ve aynı zaman diliminde kaç paralel bağlantının açıldığını not edin.
Linux sistemlerde anlık bağlantı sayısını şu komutla görebilirsiniz:
ss -tn state established '( dport = :25 or dport = :587 or dport = :465 )' | wc -lGoogle Postmaster Tools, gönderen IP ve domain itibar puanını gerçek zamanlı olarak sunar. "Domain Reputation" veya "IP Reputation" kısmında düşük ya da kötü değer varsa, alıcı sunucuların kısıtlama uygulaması beklenen bir davranıştır.
RFC 7208 (SPF), RFC 6376 (DKIM) ve RFC 7489 (DMARC) çerçevesinde yayımladığınız DNS kayıtlarının doğru yapılandırıldığını kontrol edin. MXToolbox, mail-tester.com veya dmarcanalyzer.com araçları bu kontrolleri ücretsiz gerçekleştirir. Eksik ya da hatalı kayıtlar, alıcı sunucuların spam filtreleme davranışını sertleştirir ve 421'e zemin hazırlar.
| Alıcı Platform | Eş Zamanlı Bağlantı (IP Başına) | Saatlik Mesaj Kotası | Önerilen Gönderim Hızı |
|---|---|---|---|
| Gmail / Google Workspace | ~5 | Belirtilmemiş (itibar bazlı) | < 20 mesaj/saniye |
| Microsoft 365 (EOP) | ~30 (domain başına) | 10.000 (dış gönderim) | < 30 mesaj/saniye |
| Yahoo / AOL | ~10 | Politika belgesi yok | < 10 mesaj/saniye |
| Yandex Mail | ~5 | Politika belgesi yok | < 5 mesaj/saniye |
| Genel kurumsal Postfix | Değişken (20–100) | Yapılandırmaya bağlı | Hedef adminiyle görüşün |
Tablodaki değerler, kamuya açık belgeler ve gönderim sağlayıcılarının paylaştığı deneyim raporları temel alınarak derlenmiştir; sağlayıcılar bu limitleri önceden bildirmeksizin değiştirebilir.
Postfix kullanan sistemlerde /etc/postfix/master.cf veya main.cf dosyasında şu parametre düzenlenmelidir:
smtp_destination_concurrency_limit = 5
smtp_destination_rate_delay = 1s
smtp_extra_recipient_limit = 10Bu yapılandırma, her hedef domain için eş zamanlı bağlantı sayısını 5'e düşürür ve gönderimler arasında 1 saniyelik bekleme ekler. Ayarları değiştirdikten sonra postfix reload komutuyla yapılandırmayı yeniden yükleyin.
Büyük listeleri tek seferde göndermek yerine zaman dilimlere yayın. Connect365 gibi e-posta pazarlama platformları, kampanya gönderimini saatlere veya günlere bölme özelliği sunar. Önerilen yaklaşım: 100.000 alıcılık listeyi 4–6 saatlik bloklara bölmek ve her blok arasında en az 30 dakika bekleme süresi tanımlamaktır.
Yeni IP adreslerinden gönderime başlarken şu takvimi izleyin: ilk hafta günde en fazla 200–500 mesaj, ikinci hafta 1.000–5.000, üçüncü hafta 10.000–25.000. Her artıştan sonra sekme dışı geri dönüş (bounce) oranlarını ve spam şikayet oranlarını izleyin. Google Postmaster Tools'daki itibar puanı "Yüksek" seviyeye ulaşmadan hızı artırmayın.
Birden fazla IP kullanıyorsanız, her IP'nin ayrı bir gönderim havuzunda dengeli biçimde görev alması gerekir. Postfix'te smtp_bind_address veya özel transport haritaları kullanılarak IP rotasyonu sağlanabilir. Sendgrid, Mailgun, Amazon SES gibi bulut tabanlı yönlendirme altyapıları bu dengelemeyi otomatik olarak yönetir.
RFC 5321, 550 "User unknown" gibi kalıcı ret kodlarını (5xx) geçici retlerden (4xx) ayırır. Sert geri dönüş (hard bounce) oranı %2'yi aştığında ve spam şikayet oranı Google için %0,10'u geçtiğinde sunucular otomatik kısıtlama başlatır. Bu oranları Google Postmaster Tools ve sağlayıcınızın analitik paneli aracılığıyla haftalık olarak izleyin.
RFC 7208 kapsamında SPF kaydınızın tüm gönderim IP'lerini içerdiğinden emin olun. RFC 6376 uyarınca DKIM imzalamasını 2048 bit anahtar uzunluğuyla yapılandırın; 1024 bit artık yetersiz kabul edilmektedir. RFC 7489 çerçevesinde DMARC politikanızı en az p=quarantine düzeyine getirin ve raporlama e-postalarını (rua/ruf) düzenli olarak inceleyin. Bu üç kaydın eksik olduğu gönderimler, büyük sağlayıcılar tarafından şüpheli kabul edilir ve ek kısıtlamalara maruz kalır.
421 hatasının tekrarlanmaması için aşağıdaki izleme mekanizmalarını kurun:
Hayır. RFC 5321'e göre 4xx kodları geçici retlerdir. Sunucu, bağlantı sınırlamasının ortadan kalkmasını beklediğini belirtir. İyi yapılandırılmış göndericiler, bu mesajları aldıklarında belirli bir süre bekleyip (back-off) yeniden dener. 5xx kodları ise kalıcı reddir ve yeniden deneme yapılmamalıdır.
Doğrudan değil. 421, çoğunlukla bağlantı kotasının aşılmasından kaynaklanır. Ancak bazı sunucular kötü itibar tespitinde de 421 kullanabilir. Hatanın spam listesiyle ilgili olup olmadığını anlamak için MXToolbox Blacklist Check ve Google Postmaster Tools'u birlikte değerlendirin.
Bu, hedef sunucunun politikasına bağlıdır. Gmail için saniyede 20 mesajın altında kalmak güvenlidir. Microsoft 365 için saatlik mesaj kotanızı doldurmamak önemlidir. Genel öneri: 421 almadan önce ölçülen maksimum hızın %50–70'inde çalışmaktır.
main.cf dosyasına smtp_destination_concurrency_limit = 5 ve smtp_destination_rate_delay = 1s parametrelerini ekleyin, ardından postfix reload çalıştırın. Exim kullanıyorsanız smtp_connect_backoff_count ve ilgili ACL kurallarını gözden geçirin.
Kısmen evet, ancak garanti değil. Alıcı sunucular IP başına değil, bazı durumlarda domain başına kota uygular. Ayrıca yeni IP'lerin soğuk olması nedeniyle ısınma sürecini her biri için ayrı ayrı yönetmeniz gerekir.
Her ikisi de geçici ret kodudur; ancak 421 genellikle bağlantı düzeyinde verilirken (sunucu iletişim kanalını kapatır), 450 mesaj kabul aşamasında döner (örneğin, posta kutusu geçici olarak kullanılamıyor). RFC 5321, her iki kodu da geçici hata kategorisinde değerlendirdiğinden yeniden deneme mantığı aynıdır.
Bu kayıtların eksikliği doğrudan 421'e yol açmaz; daha çok 550 veya sessiz spam klasörü yönlendirmeleriyle sonuçlanır. Ancak eksik kimlik doğrulaması, sunucunun genel itibar değerlendirmesini olumsuz etkiler ve bağlantı kısıtlamalarının daha düşük eşiklerde devreye girmesine neden olabilir.
RFC 5321, sabit bir bekleme süresi belirtmez; ancak üstel geri çekilme (exponential back-off) önerir. Pratikte 5–30 dakika beklendikten sonra yeniden deneme yapmak, çoğu sağlayıcının kota penceresinin dolmasını karşılar. Kimi sunucular 421 yanıtında "retry after" ipucu da verebilir; bu değere öncelik tanıyın.
Connect365, otomatik yeniden deneme (retry) mekanizması, hedef sunucuya göre ayarlanabilir gönderim hızı ve eş zamanlı bağlantı yönetimiyle donatılmıştır. Platform, 421 yanıtı aldığında ilgili mesajı kuyruğa geri alır ve üstel geri çekilme mantığıyla yeniden gönderimi dener; bu süreç kampanya raporlarında şeffaf biçimde görüntülenir.
Tamamen engellemek mümkün değildir; zira alıcı sunucunun politikaları her zaman değişebilir. Bununla birlikte, doğru IP ısınması, uygun bağlantı sınırları, temiz liste hijyeni ve eksiksiz kimlik doğrulama kayıtlarıyla 421 oranını operasyonel açıdan ihmal edilebilir düzeyde tutmak mümkündür.
Reklamsız, KVKK uyumlu; kurulum ve geçiş ücretsiz, mailleri biz taşırız.
Kurulum + migrasyon ücretsiz. KVKK uyumlu, Türkiye'de barındırma. 7/24 Türkçe destek.
Kampanya 30 Haziran'a kadar geçerlidir.