Toplu bir gönderim başlattınız ve iletiler beklediğinizden çok daha yavaş gidiyor. Bazıları "geçici olarak reddedildi" hatası veriyor. Bu, bir arıza değil throttling'dir — alıcı sunucuların gönderim hızınızı bilinçli olarak sınırlaması.
Bu rehber, gönderim limitlerinin nasıl çalıştığını, geçici retlerin nasıl yorumlanacağını ve hızın nasıl yönetileceğini anlatıyor.
Neden Limit Var?
Alıcı sunucular, tanımadıkları bir kaynaktan gelen yüksek hacimli trafiği doğal olarak şüpheyle karşılar. Spam kampanyalarının tipik davranışı budur: kısa sürede çok sayıda ileti. Limitler bu davranışı yavaşlatarak filtreleme sistemlerine değerlendirme zamanı kazandırır.
Önemli bir nokta: limitler sabit değildir. Gönderen itibarınıza göre dinamik olarak ayarlanır. İtibarı yüksek bir gönderen çok daha yüksek hızda gönderim yapabilirken, itibarı düşük veya bilinmeyen bir gönderen sıkı biçimde sınırlanır. Yani throttling yaşıyorsanız, bu aynı zamanda itibarınız hakkında bir geri bildirimdir.
Üç Farklı Limit Katmanı
| Katman | Kim uygular | Aşıldığında |
|---|---|---|
| Gönderim sağlayıcısı limiti | Smarthost / e-posta platformunuz | Gönderim durur veya kuyruğa alınır |
| Alıcı sunucu limiti | Hedef e-posta sağlayıcısı | Geçici ret — sonra tekrar denenir |
| Bağlantı limiti | Hedef sunucu | Yeni bağlantı reddedilir |
Bu üç katman farklı davranır ve karıştırılmamalıdır. Sağlayıcı limitini aşmak bir hesap sorunudur; alıcı sunucu limitini aşmak ise normal işleyişin parçasıdır ve doğru yapılandırılmış bir sistem bunu otomatik yönetir.
Geçici Ret: Hata Değil, Talimat
Alıcı sunucu bir iletiyi geçici olarak reddettiğinde aslında "şu anda değil, biraz sonra tekrar dene" der. Bu, protokolün normal bir parçasıdır ve greylisting gibi bazı spam koruma yöntemleri bunu bilinçli olarak kullanır: yeni bir göndericiyi ilk denemede reddedip, tekrar deneyip denemediğine bakarlar. Gerçek posta sunucuları tekrar dener, basit spam araçları denemez.
Buradaki kritik nokta şudur: gönderim sisteminiz yeniden deneme yapıyor mu? Yapmıyorsa, geçici olarak reddedilen her ileti sessizce kaybolur ve siz bunu fark etmezsiniz. Basit betiklerle yapılan gönderimlerde en yaygın kayıp nedeni budur.
Doğru bir gönderim altyapısı, geçici retleri kuyruğa alır ve artan aralıklarla tekrar dener. Bu davranışın kurulu olduğunu doğrulamak, yüksek hacimli gönderim yapmadan önceki en önemli kontroldür.
Hız Yönetimi
Sağlayıcı Bazında Ayarlama
Her alıcı sağlayıcının kabul hızı farklıdır. Hepsine aynı hızda göndermek, bazılarında gereksiz geçici retlere yol açar. Gönderim altyapınız sağlayıcı bazında hız ayarı yapabiliyorsa bunu kullanın: listeyi alıcı sağlayıcıya göre gruplayıp her gruba uygun hızda gönderin.
Kademeli Isıtma
Yeni bir gönderim kimliğiyle başlarken hacmi kademeli artırın. İlk günlerde düşük hacimle ve en yüksek etkileşim alan alıcılarla başlamak, itibarınızı hızla yükseltir ve limitlerinizin gevşemesini sağlar.
Bu süreç, gönderimi itibarı zaten kurulmuş bir smarthost altyapısı üzerinden yaptığınızda büyük ölçüde ortadan kalkar — çünkü IP havuzunun itibarı ve hız yönetimi sağlayıcı tarafından yürütülür.
Zamanlama
Tüm listeye aynı anda göndermek yerine gönderimi zamana yayın. Bu hem limitlere çarpma olasılığını düşürür hem de açılma oranınızı iyileştirir: aynı dakikada gelen 50.000 iletinin tamamı, alıcı sağlayıcı için tek bir toplu hareket olarak görünür.
Limite Çarptığınızı Nasıl Anlarsınız?
- Gönderim beklenenden uzun sürüyor: Kuyruk boşalmıyor, iletiler yavaş yavaş gidiyor.
- Geçici ret sayısı artıyor: Loglarda geçici ret yanıtları birikiyor.
- Belirli bir sağlayıcıda yoğunlaşma: Retlerin çoğu tek bir alıcı sağlayıcıdan geliyorsa, sorun genel değil o sağlayıcıdaki itibarınızdadır.
- Hesap uyarısı: Gönderim sağlayıcınızdan limit aşımı bildirimi alıyorsanız, bu alıcı sunucu limiti değil sağlayıcı limitidir ve farklı bir müdahale gerektirir.
Limite Çarptığınızda Ne Yapmalı?
- Hacmi artırmayın. İlk refleks daha hızlı göndermeye çalışmak olur; bu, durumu kötüleştirir ve engellemeye dönüşebilir.
- Yeniden deneme mekanizmasının çalıştığını doğrulayın. Geçici retler tekrar deneniyorsa iletiler kaybolmuyor demektir — sabırlı olmak yeterlidir.
- Hangi sağlayıcıda sorun olduğunu tespit edin. Tek bir sağlayıcıda yoğunlaşıyorsa, o sağlayıcıdaki alıcı listenizin kalitesini ve etkileşim oranını gözden geçirin.
- Kimlik doğrulamayı kontrol edin. SPF/DKIM/DMARC eksikse limitler daha sıkı uygulanır. Bunları düzeltmek, hız kısıtını gevşetir.
- Liste kalitesini gözden geçirin. Yüksek geri dönme oranı, limitlerin sıkılaşmasının en yaygın nedenidir.
Sonuç
Gönderim limitleri bir engel değil, alıcı sunucuların size verdiği geri bildirimdir: itibarınız ne kadar yüksekse limitleriniz o kadar gevşer. Bu yüzden throttling yaşadığınızda çözüm daha hızlı göndermeye çalışmak değil, itibarı yükseltmektir — kimlik doğrulamayı tamamlayın, listeyi temizleyin, etkileşimi artırın. Ayrıca gönderim sisteminizin geçici retleri kuyruğa alıp tekrar denediğinden emin olun; bu mekanizma yoksa yavaşlama değil sessiz kayıp yaşarsınız ve bunu fark etmeniz aylar sürebilir.
Sıkça Sorulan Sorular (SSS)
Geçici ret alan iletiler kaybolur mu?
Gönderim sisteminiz yeniden deneme yapıyorsa hayır — kuyrukta bekler ve sonra teslim edilir. Yeniden deneme yapmayan basit gönderim betiklerinde ise evet, sessizce kaybolur. Bu yüzden altyapınızın kuyruk ve yeniden deneme yeteneği kritiktir.
Limitimi artırabilir miyim?
Sağlayıcı limitini paket yükselterek artırabilirsiniz. Alıcı sunucu limitleri ise doğrudan artırılamaz — yalnızca itibarınızı yükselterek dolaylı olarak gevşetebilirsiniz. Kısa yolu yoktur; tutarlı iyi gönderim davranışı gerekir.
Gönderimi hızlandırmak için ne yapabilirim?
Kimlik doğrulamayı eksiksiz kurun, listenizi temizleyin ve etkileşim oranını yükseltin. Bu üçü itibarınızı yükseltir, itibar yükseldikçe alıcı sunucular daha yüksek hıza izin verir. Teknik bir hız ayarından çok, davranış meselesidir.
Greylisting nedir, sorun mu?
Yeni gönderenleri ilk denemede geçici olarak reddedip tekrar deneyip denemediklerine bakan bir spam koruma yöntemidir. Sorun değildir — gönderim sisteminiz tekrar deniyorsa ileti birkaç dakika gecikmeyle teslim edilir. Yalnızca tekrar denemeyen sistemler için sorundur.
