cPanel Hosting ve Salesforce'ta Deliverability Nasıl Kontrol Edilir?

cPanel üzerinden çalışan paylaşımlı bir hosting veya bir Salesforce sandbox ortamından mail göndermek, deliverability açısından production/dedicated bir gönderim altyapısından temelden farklıdır. Bu yazı bu iki ortamda deliverability'nin nasıl kontrol edileceğini ve altyapı kısıtlarının B2B soğuk e-posta gönderimini neden sınırladığını anlatıyor.

cPanel/paylaşımlı hosting'de deliverability neden farklı çalışır

cPanel, birçok hosting sağlayıcısının (GoDaddy dahil) paylaşımlı sunucularda kullandığı bir yönetim panelidir. Paylaşımlı hosting'de aynı sunucu IP'sini genelde onlarca, bazen yüzlerce farklı hesap paylaşır. Bu, deliverability açısından kritik bir noktadır: o IP üzerinden başka bir hesap spam benzeri davranış sergilerse (yüksek hacimli, doğrulanmamış listeye gönderim gibi), IP itibarı düşer ve bu düşüş aynı IP'yi kullanan tüm hesapları etkiler — sen hiçbir şey yanlış yapmasan bile.

Bu yüzden cPanel üzerinden gönderilen mailler, aynı domain/DKIM ayarına sahip dedicated (özel) bir sunucudan gönderilen maillere kıyasla, genelde daha değişken ve öngörülemez bir deliverability performansı gösterir. Sonuç bir gün gelen kutusuna düşer, bir hafta sonra aynı ayarlarla spam klasörüne gidebilir — çünkü değişken olan senin ayarların değil, paylaştığın IP'nin komşularının davranışıdır.

Bu risk özellikle B2B soğuk e-posta için önemlidir, çünkü hedefli outreach'in başarısı büyük ölçüde tutarlılığa dayanır — bir kampanya gelen kutusuna düşerken aynı hafta içindeki ikinci kampanyanın spam'e düşmesi, gönderenin hiçbir şey değiştirmediği halde sonuçların anlamsızlaşmasına yol açar. Dedicated bir gönderim altyapısında bu değişkenlik büyük ölçüde ortadan kalkar, çünkü itibarı etkileyen tek taraf gönderenin kendisidir.

cPanel kendi başına deliverability'i "garanti eden" bir araç değildir; sadece mail gönderim/alım için bir arayüz sunar. SPF, DKIM, DMARC kayıtlarının doğru kurulup kurulmadığı yine domain'in DNS ayarlarından kontrol edilir, cPanel bunun için genelde bir "Email Deliverability" veya "Authentication" sekmesi barındırır.

Ek olarak, çoğu paylaşımlı hosting planı, gönderim hızını ve günlük hacmi sözleşme seviyesinde sınırlar — bu sınır sağlayıcının (Gmail, Outlook gibi) uyguladığı limitten bağımsız, hosting firmasının kendi kaynak paylaşımı politikasıdır. Bir hesap günlük hacim sınırını aşarsa, hosting sağlayıcısı genelde önce uyarı gönderir, ısrar halinde hesabın mail gönderim özelliğini geçici olarak kısıtlayabilir; bu GoDaddy dahil çoğu paylaşımlı cPanel sağlayıcısında benzer şekilde işler.

cPanel'de deliverability skoru nasıl kontrol edilir

cPanel arayüzünde genelde "Email Deliverability" adlı bir bölüm bulunur; bu bölüm domain için SPF, DKIM ve varsa PTR (reverse DNS) kayıtlarının doğru yapılandırılıp yapılandırılmadığını gösterir ve eksik/yanlış olan kayıtlar için önerilen DNS değerini verir. Bu ekran deliverability'nin teknik ön koşullarını (kimlik doğrulama kayıtları) kontrol eder, ama IP itibarı gibi cPanel dışındaki faktörleri göstermez.

• cPanel > Email Deliverability sekmesinden SPF/DKIM/PTR durumunu kontrol et; "Not Valid" veya "Not Enabled" görünen kayıtları düzelt.
• Sunucunun paylaşımlı IP adresini bul (genelde cPanel > Server Information altında) ve bu IP'yi bağımsız bir blacklist kontrol aracında tara.
• Gönderilen bir test mailinin başlıklarını (header) inceleyerek SPF/DKIM/DMARC sonucunun "pass" olup olmadığını doğrula.
• Mail kuyruğu (mail queue) ve teslim loglarını (Exim/Postfix logları, cPanel'de genelde "Track Delivery" veya WHM üzerinden erişilir) inceleyerek reddedilen/geciken mailleri tek tek görebilirsin.
• Bağımsız bir deliverability test aracına (kutuya bir test maili gönderip aldığı puanı ve teşhisi gösteren araçlar) test maili göndererek genel bir skor almak, cPanel'in kendi ekranının göstermediği içerik/itibar faktörlerini de kapsar.
• How to check email deliverability score sorusunun en pratik cevabı genelde şu üç kontrolü birlikte yapmaktır: DNS kayıtlarının teknik doğruluğu (cPanel ekranı veya bağımsız DNS sorgu aracı), IP/domain itibarının blacklist durumu (bağımsız blacklist tarayıcı) ve gerçek bir test mailinin büyük sağlayıcılardaki (Gmail, Outlook) inbox/spam sonucu. Tek bir kontrol yeterli bir skor vermez, üçü birlikte tam bir tablo oluşturur.

Salesforce sandbox'ta deliverability testi neden yanıltıcıdır

Salesforce'ta sandbox, production (canlı) ortamdan tamamen izole edilmiş bir test ortamıdır. Sandbox'tan gönderilen mailler genelde farklı bir gönderim yolu, farklı bir varsayılan "deliverability" ayarı (Salesforce sandbox'larda e-posta gönderimi varsayılan olarak kısıtlı veya kapalı gelebilir) ve production'dan bağımsız bir itibar geçmişi kullanır.

Bu yüzden sandbox'ta "mail gönderildi, teslim oldu" görmek, aynı kampanyanın production'da aynı performansı göstereceği anlamına gelmez. Sandbox testinin amacı entegrasyonun (şablonun doğru render olması, alanların doğru dolması, otomasyonun tetiklenmesi) çalıştığını doğrulamaktır — deliverability performansını (spam'e düşme oranı, açılma oranı) ölçmek için güvenilir bir ortam değildir.

Salesforce'ta gerçek deliverability'i değerlendirmek istiyorsan, production organizasyonunda, gerçek gönderim domaini ve gerçek SPF/DKIM ayarlarıyla, küçük ölçekli bir gerçek test kampanyası (bir avuç gerçek test kutusuna) çalıştırmak, sandbox'ta "gönderildi" görmekten çok daha güvenilir bir sinyal verir.

Bir başka pratik nokta: sandbox'lar zaman zaman "refresh" edilir (production verisiyle yeniden senkronize edilir) ve bu işlem sırasında e-posta ayarları da sıfırlanabilir. Bir ekip sandbox'ta özenle test ettiği bir deliverability yapılandırmasının, bir sonraki refresh'ten sonra kaybolduğunu görüp şaşırabilir — bu yüzden deliverability'e özgü ayarların (SPF/DKIM hizalaması, gönderim domaini) production'da doğrulanması, sandbox'a güvenmekten daha kalıcı bir yaklaşımdır.

Salesforce'ta deliverability'i kontrol etmenin pratik yolları

Salesforce, gönderilen e-postaların teslim durumunu izlemek için birkaç yerleşik araç sunar; bunlar production ortamında en anlamlı sonucu verir.

• Setup > Email > Deliverability altında organizasyonun genel gönderim erişim seviyesini (All email, System email only, No access) kontrol et — sandbox'larda bu genelde kısıtlıdır.
• Email bounce yönetimi (Bounce Management) özelliğini etkinleştirerek hard/soft bounce'ların otomatik olarak kayıt/lead üzerinde işaretlenmesini sağla.
• Gönderim yapılan domain için SPF/DKIM/DMARC kayıtlarının Salesforce'un istediği formatta DNS'te doğru kurulu olduğunu bağımsız bir DNS sorgu aracıyla doğrula.
• Mümkünse Salesforce entegre kampanyaları için ayrı, kampanyaya özel bir gönderim alt-domaini kullan; bu ana kurumsal domainin itibarını izole eder.
• Gerçek deliverability performansı için production'da küçük bir pilot gönderim yapıp sonucu bağımsız bir deliverability test aracıyla doğrula, sadece Salesforce içi "gönderildi" durumuna güvenme.

B2B outreach açısından ne anlama geliyor

Hedefli B2B soğuk e-posta göndermek isteyen bir ekip için hem paylaşımlı cPanel hosting hem de Salesforce sandbox, üretim kampanyaları için yetersiz temellerdir — biri paylaşılan itibar riski taşır, diğeri gerçek performansı yansıtmaz. İkisi de belirli amaçlar için (kurumsal web sitesi maili, entegrasyon testi) uygundur, ama ölçeklenebilir, itibarı korunan bir B2B outreach altyapısının yerini tutmaz.

Pratik yaklaşım, kurumsal/transaksiyonel maili (fatura, şifre sıfırlama gibi) mevcut hosting/CRM altyapısında bırakıp, hedefli soğuk e-posta kampanyaları için ayrı, izole edilmiş, kendi SPF/DKIM/DMARC hizalaması ve itibar geçmişi olan bir gönderim alt-domaini/altyapısı kurmaktır. Bu ayrım, bir tarafta sorun çıksa bile diğerinin etkilenmemesini sağlar.

Bu ayrım özellikle Salesforce kullanan B2B ekipleri için önemlidir, çünkü Salesforce genelde CRM'in merkezi konumundadır ve hem müşteri iletişimi hem soğuk outreach aynı organizasyondan yönetilme eğilimindedir. İkisini aynı gönderim domaininde tutmak yerine ayırmak, soğuk kampanyada olası bir itibar sorununun mevcut müşteri iletişimine sıçramasını engeller.

Sık sorulan sorular