550 5.7.1 Daily sending quota exceeded veya 552 5.3.4 Message size exceeds fixed maximum message size hata mesajını gördünüz ve şimdi kesin sayıyı arıyorsunuz. Sorun şu ki "e-posta gönderim sınırı" tek bir sayı değildir; bir mesajın yolunda en az beş bağımsız kota vardır ve her biri farklı bir yerde uygulanır. Hangi katmanın mesajınızı reddettiğini anlamadan, ayarlardaki her değişiklik sadece tahmin olur.
Bir e-postaya uygulanan beş kota
Bir mesajın PHP'deki mail() fonksiyonundan veya Thunderbird'den alıcının gelen kutusuna kadar izlediği yol bu katmanlardan geçer ve her katmanın kendi kotası vardır:
| Katman | Neyi sınırlar | Yaygın değer | Örnek hata |
|---|---|---|---|
| Yerel MTA (Exim/Postfix) | Mesaj başına alıcı sayısı | 50 ila 100 | 452 Too many recipients |
| Yerel MTA | Base64 sonrası toplam mesaj boyutu | 25 ila 50 megabayt | 552 Message size exceeds |
| Hesap kotası | Saat/gün başına mesaj sayısı | Saatte 200 ila 500 | 550 Daily sending quota exceeded |
| Hedef servis sağlayıcı | Bir IP'den bağlantı hızı | Değişken, genellikle belirsiz | 421 Too many connections |
| Nihai alıcı | Alındıktan sonra mesaj boyutu | 10 ila 25 megabayt | Sessiz ret veya bounce |
Çoğu kişiyi şaşırtan nokta son katmandır. Diyelim ki hosting'iniz 30 megabaytlık mesajı kabul ediyor ve başarıyla gönderiliyor. Gmail aynı mesajı kendi tarafında reddediyor, çünkü gerçek kotası daha düşük. Siz hosting logunda sadece 250 OK görüyorsunuz ve her şeyin doğru olduğunu düşünüyorsunuz. Gönderenin gelen kutusunda bounce'u açana kadar fark etmiyorsunuz.
Ek boyutu neden dosya boyutuyla aynı değil
Diskteki 20 megabaytlık bir dosya, SMTP'de yaklaşık 27 megabayt olur. Bunun nedeni eklerin Base64 ile kodlanması ve bu kodlamanın boyuta yaklaşık %33 eklemesidir. Buna MIME başlıklarını, multipart sınırlarını ve metnin UTF-8 kodlamasını da ekleyin.
Pratikte işe yarayan yaklaşık formül: ham dosya boyutu çarpı 1,37, artı birkaç kilobayt sabit değer. Yani mesaj kotası 25 megabayt ise, gerçekten geçen en büyük dosya yaklaşık 18 megabayttır, 25 değil.
Burada hata yapılıyor: kullanıcı panelde mesaj kotasını 50 megabayta yükseltiyor ve sorunun çözüldüğünü düşünüyor. Sonra mesajlar sessizce MTA kuyruğunda takılıyor, kuyruk doluyor ve tüm alan adının gönderimi duruyor. Belirtisi, küçük e-postaların bile artık gitmemesidir. Kotayı yalnızca gerçek alıcılarınızın kabul ettiği kadar yükseltin; daha yükseği sadece kuyruğu rehin alır.
Alıcı sayısı kotası ve To ile BCC arasındaki fark
Mesaj başına alıcı kotası genellikle 50 ila 100 arasındadır ve yalnızca To değil, To, Cc ve BCC toplamı üzerinden hesaplanır. BCC ile 300 kişiye e-posta gönderirseniz, aynı 452 Too many recipients hatasını alırsınız.
Doğru çözüm, BCC'yi kaldırmak değil, daha küçük gruplara bölmektir. Ancak basit bölme de yeterli değildir: aynı alan adına aralıksız 10 mesaj gönderirseniz, hedef sunucu bunu toplu gönderim kalıbı olarak algılar ve bağlantıyı 421 ile kapatır. Gruplar arasında en az 30 ila 60 saniye bırakın.
Birkaç yüz kişiden büyük listelere gönderim için hosting SMTP'si doğru yer değildir. Burada işlemsel e-posta ve neden hosting'den gönderilmemesi gerektiği konusu ciddileşir; özel toplu gönderim servisleri kuyruk yönetimini, ısıtılmış IP'yi ve bounce raporlamasını kendileri yapar ve sizi yerel kotalarla uğraşmaktan kurtarır.
Saatlik ve günlük gönderim kotası nereden geliyor
Bu kota sizi kısıtlamak için değil, kötüye kullanımı önlemek için vardır. Bir kullanıcı hesabı herhangi bir nedenle (savunmasız script, captcha'sız iletişim formu, sızdırılmış şifre) spam aracına dönüşürse, saatlik kota on dakikada yüz bin mesaj gönderilmesini engeller ve alan adının IP'si blacklist'e girmeden önce fark etmeniz için size fırsat verir.
Bu kotaya takıldığınızın belirtisini Exim logunda şu komutla görün:
exim -bp | wc -l
grep "sending quota" /var/log/exim/mainlog | tail -20İlk komutun çıktısı büyük bir sayı döndürüyorsa ve ikinci logda tekrarlayan satırlar görüyorsanız, mesajlar kuyrukta beklemiş ve kota devreye girmiş demektir. Nedeni çözmeden kuyruğu temizlemek, sadece birkaç saat sonra aynı durumu geri getirir.
Saatlik kota nasıl yükseltilir
Çoğu kontrol panelinde bu sayı değiştirilebilir, ancak her değişikliğin bir gerekçesi olmalıdır. Gerçekten haftada bir gönderim yaptığınız 800 aboneli bir bülteniniz varsa, kotayı yükseltmek mantıklıdır. Her kayıt için üç e-posta gönderen bir scriptiniz ve günde 2000 kaydınız varsa, sorununuz kota değil; gönderim mimarisidir.
Posta kutusu kotası, unutulan sınırlama
Gönderim kotası işin sadece bir tarafıdır. Alıcının posta kutusu dolduğunda, sunucu yeni mesajları 552 Mailbox full ile reddeder ve gönderen alan adınızın bozuk olduğunu düşünür. "Posta kutusu dolu" mesajı veya tuhaf bounce'larla karşılaştıysanız, e-posta depolama kotası yönetimi ve posta kutusu dolma çözümü tam da bu senaryoyu açıklıyor.
Pratik bir not: posta kutusu kotası ve gönderim kotası iki ayrı ayardır ve birini yükseltmek diğerini etkilemez. İkisini de aynı ticket'ta belirtirseniz, cevaba daha hızlı ulaşırsınız.
Hangi kotanın sizi reddettiğini nasıl anlarsınız
- Üç haneli SMTP kodunu okuyun.
5xxkalıcı ret,4xxgeçici ve yeniden denenebilir demektir. - Hata metnini tamamen kopyalayın, sadece kodu değil.
quotaifadesi gönderim kotasına,sizeboyuta,recipientsalıcı sayısına işaret eder. - MTA logunu aynı zaman aralığıyla eşleştirin, hatanın sizin tarafınızdan mı yoksa hedef sunucudan mı geldiğini anlayın.
- Hata hedef taraftan geliyorsa, alan adı kayıtlarını kontrol edin. SPF ve DKIM'in olmaması veya yanlış olması, hiçbir kota aşılmadığında bile mesajın reddedilmesine neden olur. MX kaydı ve alan adı kayıtları kontrol aracı ile mevcut durumu görebilirsiniz.
Deneyimlerime göre, "gönderim sınırı" başlığıyla bildirilen vakaların yarısından fazlası aslında alan adı kimlik doğrulama sorunudur. Mesaj gönderilir, hiçbir kota aşılmaz, ancak alıcı tarafında spam'e düşer veya tamamen reddedilir. Mesajlar gönderiliyor ama ulaşmıyorsa, tamamen farklı bir sorun giderme yolu gerekir ki bu da e-postaların spam'e düşme sorununu çözme rehberinde adım adım anlatılmıştır.
Kotayı yükseltmek ile mimariyi değiştirmek arasında seçim
Gönderim hacminiz günde birkaç bin mesajın altındaysa ve hepsi gerçekten gerçek alıcılara gidiyorsa, aynı hosting'de kotayı yükseltmek yeterlidir. Daha basit, daha ucuz ve ek bağımlılık yok.
Ancak toplu gönderim aralığına girdiyseniz, kotayı yükseltmek yanlıştır. Bedeli, hosting'in paylaşılan IP'sini kendi reputation'ınızla bağlamanızdır; kötü bir kampanya o sunucudaki tüm alan adlarının deliverability'sini düşürebilir. Bu durumda, toplu gönderim yolunu iş e-postası yolundan ayırmak doğru karardır, daha fazla iş gerektirse bile.
Günde birkaç yüz normal e-posta gönderen iş alan adları için, yapılandırılmış Exim ve şeffaf kotalara sahip bir Linux hosting yeterlidir; sadece kampanya başlatmadan önce kota sayısını panelden okuyun ve alıcı gruplandırmasını baştan doğru yapın.
Başka herhangi bir değişiklikten önce üç şeyi kontrol edin: hatanın kodu ve tam metni, Base64 sonrası gerçek mesaj boyutu ve her gruptaki alıcı sayısı. Çoğu durumda cevap bu üç sayıdadır. Bunlardan sonra hâlâ takılıysanız, dokümantasyon ve bilgi tabanı ve son olarak ServerNet blogu benzer durumları yapılandırma detaylarıyla ele almıştır.
Sıkça sorulan sorular
Paylaşımlı hosting'de e-posta gönderim kotası ne kadardır?
Sabit bir sayı yoktur ve servis sağlayıcılar arasında farklılık gösterir; yaygın aralık saatte 200 ila 500 mesaj ve günde birkaç bin mesajdır. Kendi servisinizin kesin sayısını kontrol panelinden veya o servis sağlayıcının dokümantasyonundan alın, çünkü tahmin etmek kotaya en kötü zamanda takılmanıza neden olur.
20 megabaytlık ekli e-posta neden gönderilmiyor?
Çünkü Base64 kodlaması ek boyutunu yaklaşık %33 artırır ve 20 megabaytlık bir dosya SMTP'de yaklaşık 27 megabayt olur. Mesaj kotası 25 megabayt ise bu mesaj reddedilir. 10 megabayttan büyük dosyalar için ek yerine indirme bağlantısı gönderin.
SMTP'de 550 ve 452 hatası arasındaki fark nedir?
5xx kodları kalıcı hatalardır ve yeniden denemenin faydası yoktur; günlük kotanın dolduğunu belirten 550 Daily sending quota exceeded gibi. 4xx kodları geçicidir ve gönderen daha sonra tekrar denemelidir; mesajı daha küçük gruplara bölerek çözülen 452 Too many recipients gibi.
Gönderim kotasını yükseltmek spam sorununu çözer mi?
Hayır. Gönderim kotası ve deliverability iki ayrı konudur. Mesajlar gönderiliyor ama spam'e düşüyorsa, sorun SPF, DKIM ve DMARC kayıtlarında veya alan adı reputation'ındadır, kotada değil. Önce alan adı kayıtlarını kontrol ederek başlayın, sonra kota ayarlarına geçin.