Sorun Giderme·
14 Haziran 2026
Bir e-posta gönderdiğinizde sunucudan 552 5.2.2 Mailbox Full ya da 452 4.2.2 Mailbox quota exceeded gibi bir hata kodu aldığınızda, mesajınız karşı tarafa ulaşamamış demektir. Bu yazıda söz konusu hataların teknik arka planını, etkilenen taraflara yönelik geçici çözümleri ve kalıcı alternatif iletişim yöntemlerini ele alacağız.
E-posta iletimi, RFC 5321 (Simple Mail Transfer Protocol) tarafından standartlaştırılan bir protokol üzerinde çalışır. Bu protokolde her yanıt kodu üç haneli bir sayı ile başlar; ilk hane işlemin başarılı mı (2xx), geçici mi başarısız (4xx) yoksa kalıcı mı başarısız (5xx) olduğunu belirtir.
"Mailbox Full" durumu iki farklı kod biçiminde karşınıza çıkabilir:
Google Workspace ve Microsoft Exchange Online gibi kurumsal platformlar, her iki kod türünü de farklı koşullarda kullanabilir. Google Postmaster Tools üzerinden gönderim itibarınızı izlediğinizde bu hata oranlarının domain reputation'ınızı doğrudan etkilediğini görebilirsiniz.
| SMTP Kodu | Kategori | Anlamı | Gönderen MTA Davranışı | Kullanıcı Etkisi |
|---|---|---|---|---|
452 4.2.2 |
Geçici (Soft Bounce) | Kota geçici olarak aşıldı | Birkaç gün boyunca yeniden dener | Mesaj kuyruğa alınır, gecikme yaşanır |
552 5.2.2 |
Kalıcı (Hard Bounce) | Posta kutusu dolmuş, ret kesin | Yeniden denemez, NDR gönderir | Mesaj iletilmez, geri bildirim alınır |
550 5.2.1 |
Kalıcı | Hesap devre dışı veya kapalı | Yeniden denemez | Adres artık aktif değil |
421 4.4.2 |
Geçici | Sunucu bağlantı zaman aşımı | Kısa süre sonra yeniden dener | Geçici kesinti, çoğunlukla otomatik çözülür |
Posta kutusu doluluk hatalarının birkaç temel nedeni vardır:
Mesajınız 452 ya da 552 koduyla geri döndüğünde aşağıdaki adımları izleyebilirsiniz:
Non-Delivery Report (NDR), RFC 3464 standardına göre oluşturulur ve genellikle hangi sunucunun reddettiğini, tam SMTP yanıt kodunu ve zaman damgasını içerir. Bu bilgiler olmadan sorunun geçici mi kalıcı mı olduğunu tespit edemezsiniz.
Acil durumlarda telefon, SMS veya anlık mesajlaşma uygulamaları devreye girer. Kurumsal ortamlarda Microsoft Teams, Slack veya WhatsApp Business gibi araçlar bu boşluğu doldurmaktadır.
Alıcının birden fazla e-posta adresi (örneğin farklı bir domain veya kişisel hesap) varsa ve bu bilgiye erişiminiz varsa, mesajı oraya iletmeyi deneyebilirsiniz.
Büyük ekleri içeren bir mesajı iletmeye çalışıyorsanız, Google Drive, Microsoft OneDrive veya Dropbox gibi bulut depolama servislerinden bağlantı oluşturup bu bağlantıyı SMS ya da alternatif kanaldan paylaşabilirsiniz.
Eğer "Mailbox Full" hatasını başkalarından alıyorsanız, sorunu çözmek için şu adımları izlemeniz gerekir:
Çoğu e-posta istemcisinde eklere göre sıralama yapabilirsiniz. Gmail'de has:attachment larger:10M, Outlook'ta ise Gelişmiş Arama üzerinden boyut filtresi uygulanabilir. Bu mesajları yerel diske veya buluta aktardıktan sonra silebilirsiniz.
Spam ve silinmiş öğeler klasörleri pek çok kullanıcı tarafından göz ardı edilir; ancak bu klasörler toplam kota hesabına dahildir. Kalıcı silme işlemi (EXPUNGE komutu IMAP protokolünde RFC 3501 kapsamında tanımlıdır) bu iletileri sunucudan kaldırır.
Sistem yöneticinizden veya barındırıcı sağlayıcınızdan ek depolama alanı talep edebilirsiniz. Kurumsal Microsoft 365 planlarında Exchange Online posta kutusu kotası yöneticiler tarafından PowerShell ile genişletilebilir.
IMAP protokolünde sunucu tarafı arşivleme politikaları tanımlanabilir. Microsoft Exchange'de "Retention Policy" ve Google Workspace'te "Vault" bu amaçla kullanılır; eski iletiler otomatik olarak arşive taşınarak birincil kota korunur.
Tek bir e-posta kanalına bağımlı kalmak, özellikle müşteri iletişiminde ciddi iş riskleri doğurur. Aşağıdaki yaklaşımlar kurumsal iletişim altyapınızı daha dayanıklı hâle getirir:
RFC 5321 ve IETF'in e-posta en iyi uygulamaları çerçevesinde, işlemsel (sipariş onayı, şifre sıfırlama gibi) e-postalar ile toplu gönderimler (bülten, kampanya) farklı IP havuzlarından ve alt domainlerden gönderilmelidir. Bu ayrım hem itibar yönetimi hem de kota sorunlarını izole etmek açısından kritiktir.
E-postalarınızın spam klasörüne düşmesi, dolaylı yoldan alıcı kotasını tüketen gereksiz iletilere yol açar. RFC 7208 (SPF), RFC 6376 (DKIM) ve RFC 7489 (DMARC) standartlarını eksiksiz uygulayarak gönderim itibarınızı güçlendirin. Google Postmaster Tools ve Microsoft SNDS (Smart Network Data Services) üzerinden gönderim kalitesini düzenli izleyin.
Sadece e-postaya bağımlı kalmak yerine SMS API entegrasyonu, anlık bildirim sistemleri ve web formu tabanlı destek araçlarıyla iletişim altyapınızı çeşitlendirin. Bu yaklaşım, herhangi bir kanalın geçici olarak kullanılamaz hâle gelmesi durumunda iş sürekliliğini korur.
Bounce yönetimi, sağlıklı bir e-posta programının temel taşlarından biridir. 552 5.2.2 gibi hard bounce alan adresleri listenizden hemen çıkarmak zorunludur; aksi takdirde gönderim itibarınız zamanla düşer ve teslim edilebilirlik oranlarınız olumsuz etkilenir. Connect365 gibi profesyonel e-posta pazarlama platformları bu süreci otomatik olarak yönetir.
Hayır, alıcı posta kutusunun dolduğunu genellikle fark etmez. Bildirim yalnızca göndericiye NDR (Non-Delivery Report) biçiminde iletilir. Alıcının haberi olması için başka bir kanaldan uyarılması gerekir.
452 4.2.2 geçici bir hata olup gönderen sunucu birkaç gün boyunca yeniden deneme yapar. 552 5.2.2 ise kalıcı ret anlamına gelir; mesaj kuyruktan düşer ve gönderici e-posta programı yeniden denemez.
RFC 5321'e göre gönderen MTA, geçici hatalar (4xx) için genellikle en az 4-5 gün yeniden deneme yapmalıdır. Bu süre sunucu yapılandırmasına göre değişebilir; bazı sistemler 24 saat ile 7 gün arasında farklı politikalar uygular.
Hard bounce (552) alan adresleri listenizden hemen çıkarmanız gerekir. Soft bounce (452) alan adreslere birkaç deneme sonrası hâlâ ulaşılamıyorsa bu adresleri de suppress listesine almanız önerilir. Aksi takdirde gönderim itibarınız zarar görür.
Gmail'de has:attachment larger:5M araması, Outlook'ta Gelişmiş Arama ile boyut filtresi uygulanarak büyük mesajlar listelenir. Ayrıca spam, çöp ve gönderilmiş öğeler klasörlerinin de kotaya dahil olduğunu unutmayın.
Microsoft 365 ortamlarında Exchange Online posta kutusu kotası yalnızca yönetici rolüne sahip kişiler tarafından artırılabilir. Google Workspace'te de benzer şekilde yönetici konsolundan depolama alanı düzenlenebilir. Paylaşımlı barındırıcı kullanıyorsanız destek hattıyla iletişime geçmeniz gerekir.
Doğrudan ilgili değildir; ancak bu ayarların eksik olması e-postalarınızın spam klasörüne düşmesine neden olur. Spam klasörüne giden mesajlar silinmediğinde alıcı kotasını tüketir. RFC 7208 (SPF), RFC 6376 (DKIM) ve RFC 7489 (DMARC) standartlarına uyum, genel teslim edilebilirliği iyileştirir.
Evet, Connect365 gibi profesyonel platformlar hard ve soft bounce'ları otomatik olarak izler, hata alan adresleri suppress listesine ekler ve gönderim itibarınızı korumaya yardımcı olur. Ayrıca toplu gönderimler ile işlemsel e-postalar ayrı altyapılardan iletildiğinden kota sorunları izole kalır.
Telefon, SMS veya anlık mesajlaşma uygulamaları (WhatsApp Business, Microsoft Teams, Slack) ilk başvurulacak alternatiflerdir. Belge veya dosya paylaşımı gerekiyorsa Google Drive ya da OneDrive üzerinden bağlantı oluşturup bu kanaldan iletebilirsiniz. Uzun vadede birden fazla iletişim kanalı tutmak iş sürekliliği açısından kritik öneme sahiptir.
Çoğunlukla evet; sorun alıcının posta kutusu kapasitesindedir. Ancak nadiren gönderen sunucunun çıkış kuyruğu dolu olduğunda da benzer 452 kodları üretilebilir. NDR mesajındaki sunucu bilgisi incelenerek sorunun hangi taraftan kaynaklandığı tespit edilebilir.
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.