Hatanın Teknik Kökeni: RFC 5321 ve SMTP Protokolü

SMTP protokolünü tanımlayan RFC 5321 standardı, e-posta iletiminde maksimum mesaj boyutunu sunucu operatörünün belirlemesine bırakır. Standart, teorik bir üst sınır koymaz; ancak gerçek dünya uygulamalarında her sunucu kendi politikasını oluşturur. RFC 5321'in 4.5.3.1.7 numaralı bölümü, sunucuların en az 64.000 sekizli (yaklaşık 64 KB) kabul etmesi gerektiğini belirtir; bu değer yalnızca minimum zorunluluktur, üst sınır değil.

Hata kodlarına bakıldığında:

• 552 — "Requested mail action aborted: exceeded storage allocation" — gönderilen mesaj alıcı sunucunun izin verdiği boyutu aşıyor.
• 554 5.3.4 — Özellikle Microsoft Exchange ve Microsoft 365'in kullandığı kod; mesaj boyutu politikası ihlali.
• 451 4.3.4 — Geçici hata; sunucu geçici olarak aşırı yüklü veya kota dolu.

Yaygın Platform Limitleri (Haziran 2026 itibarıyla)

Aşağıdaki tablo, kurumsal ortamlarda en sık kullanılan e-posta platformlarının varsayılan mesaj boyutu limitlerini göstermektedir. Son güncelleme: Haziran 2026. Platform politikaları değişkenlik gösterebilir; güncel değerler için ilgili sağlayıcının yönetici belgeleri kontrol edilmelidir.

Neden Limit Bu Kadar Düşük Görünüyor? Base64 Şişmesi

Pek çok kullanıcı şunu sorar: "10 MB'lık bir dosyayı gönderemedim ama limit 10 MB'tı. Neden?" Yanıt teknik bir zorunluluktan kaynaklanır: SMTP üzerinden aktarılan ekler, RFC 2045 standardı olan MIME (Multipurpose Internet Mail Extensions) çerçevesinde Base64 kodlamasına tabi tutulur. Base64 kodlaması, ham ikili veriyi yaklaşık yüzde 33 büyütür.

Örnek: 7,5 MB boyutundaki bir PDF dosyası, Base64 kodlamasının ardından e-posta içinde yaklaşık 10 MB yer kaplar. Buna e-posta başlıkları ve gövde metni eklendiğinde limit kolayca aşılabilir.

Bu nedenle pratik kural şudur: İzin verilen mesaj boyutu limitinin yaklaşık yüzde 75'ini gerçek ek boyutu olarak düşünmelisiniz. 25 MB limitli bir sunucuya güvenli şekilde gönderebileceğiniz ek büyüklüğü yaklaşık 18–19 MB'tır.

Anlık Çözümler: Hemen Uygulayabileceğiniz 5 Yöntem

1. Dosyayı Bulut Depolama Üzerinden Paylaşın

Dosyayı doğrudan e-postaya eklemek yerine Microsoft OneDrive, SharePoint veya Google Drive'a yükleyip paylaşım bağlantısını e-posta gövdesine ekleyin. Bu yöntem hem boyut sorununu çözer hem de alıcı tarafın her zaman güncel versiyona erişmesini sağlar. Microsoft 365 kurumsal lisansı olan kullanıcılar, Outlook'un "Bağlantı olarak ekle" seçeneğini doğrudan kullanabilir.

2. Dosyayı Sıkıştırın

PDF dosyaları genellikle Adobe Acrobat veya çevrimiçi araçlarla yüzde 40–60 oranında küçültülebilir. Görsel içeren Office belgeleri, "Farklı Kaydet" sırasında görsel kalitesi düşürülerek küçültülebilir. ZIP sıkıştırması zaten sıkıştırılmış formatlarda (JPEG, PDF) çok az etki yapar; ancak metin tabanlı dosyalar ve Office belgelerinde önemli kazanım sağlar.

3. Büyük Ekli Gönderiyi Parçalara Bölün

Çok sayıda ek söz konusuysa bunları birden fazla ayrı e-postaya dağıtabilirsiniz. Alıcıyı bilgilendirmek için konu satırına "(1/3)", "(2/3)" gibi bir gösterim eklemek iş yazışması protokolleri açısından iyi bir pratiktir.

4. Dosya Transfer Servisi Kullanın

WeTransfer, Filemail gibi servisler veya kurumsal güvenlik politikalarına uygun dahili dosya transfer portalları bu senaryolar için tasarlanmıştır. KVKK'nın 12. maddesi uyarınca kişisel veri içeren dosyaların üçüncü taraf servisler üzerinden aktarımında veri işleme sözleşmesi (DPA) ve yeterli güvenlik tedbirleri zorunludur; bu nedenle kurumsal ortamlarda onaylı servisleri tercih edin.

5. Alıcıyla Önceden İletişim Kurun

Kritik ve büyük dosyaların transferi için FTP/SFTP, VPN üzerinden dosya paylaşımı veya her iki tarafın da erişebildiği bir ortak bulut alanı üzerinde anlaşmak, tekrar eden boyut sorunlarını kalıcı olarak ortadan kaldırır.

Yöneticiler İçin: Sunucu Tarafında Limit Artırma

E-posta altyapısını yöneten BT yöneticileri için platforma göre limit artırma adımları aşağıda özetlenmiştir. Herhangi bir limit artışının spam filtresi ve antivirüs katmanı üzerindeki etkisi değerlendirilmeden uygulanmamalıdır; Sophos resmi teknik belgelerine göre büyük mesajlar gateway seviyesinde tarama sürelerini önemli ölçüde uzatabilir.

Limit artırımı yapılmadan önce şu noktalar değerlendirilmelidir: disk kotaları, yedekleme penceresi genişlemesi, antivirüs gateway kapasitesi ve kullanıcı eğitimi. Büyük mesajların olağan hale gelmesi, uzun vadede depolama maliyetlerini ve yedek süreleri artırır.

KVKK ve Veri Güvenliği Boyutu

Türkiye'de faaliyet gösteren şirketler için büyük dosya transferlerinde KVKK'nın 12. maddesi (teknik ve idari güvenlik tedbirleri) ile 9. maddesi (yurt dışına veri aktarımı) doğrudan uygulanır. Kişisel veri içeren büyük dosyaları üçüncü taraf bulut servislerine yüklemeden önce, o servisin KVKK uyumlu veri işleme sözleşmesi sunup sunmadığını ve sunucularının coğrafi konumunu teyit etmek kurumsal bir zorunluluktur. Bu değerlendirmeyi yapmadan yürütülen transferler idari yaptırım riskini beraberinde getirir.