E-postalar Neden Spam Klasörüne Düşer? Hosting ve VPS

E‑postalar Neden Sürekli Spam Klasörüne Düşüyor?

E‑posta altyapısı kurarken çoğu işletme önce adresleri açar, istemcileri (Outlook, Thunderbird, mobil uygulamalar) kurar ve gönderim yapmaya başlar. İlk kampanyalar veya ilk kurumsal duyurular gönderildikten sonra ise aynı şikâyet gelir: ‘Müşteri görmemiş, maili spam klasöründe bulmuş.’ Eğer siz de satış, destek veya fatura e‑postalarınızın bir kısmının kaybolduğunu hissediyorsanız, sorun içerikten kaynaklanabileceği gibi altyapı, itibar veya doğrulama ayarlarıyla da ilgili olabilir.

Spam filtreleri bugün yalnızca ‘konu satırında yasaklı kelime var mı?’ diye bakmıyor. Kaynak IP’nizin itibarından, SPF/DKIM/DMARC gibi DNS kayıtlarınıza, geri dönen hatalı gönderim oranlarından, kullanıcıların ‘Bunu spam olarak işaretle’ davranışına kadar birçok sinyali birleştiriyor. Paylaşımlı hosting ile kendi VPS’inizde SMTP sunucusu çalıştırmak arasındaki fark, özellikle gönderim IP’sinin paylaşımı ve yapılandırma üzerindeki kontrolünüz açısından önem taşıyor.

Bu yazıda e‑postaların neden spam klasörüne düştüğünü teknik ama anlaşılır şekilde ele alacağız. Ardından iki ayrı bölümde, paylaşımlı hosting ve VPS için uygulanabilir, adım adım bir teslim edilebilirlik (deliverability) kontrol listesi paylaşacağız. Böylece ister yeni bir kurumsal e‑posta altyapısı kuruyor olun, ister mevcut yapınızı iyileştiriyor olun, neleri kontrol etmeniz gerektiğini net şekilde göreceksiniz.

Spam Filtrelerinin Gözünden E‑posta: 4 Temel Sinyal

Spam filtresini, her gelen mesajı puanlayan akıllı bir sistem gibi düşünebilirsiniz. Bu sistem kabaca dört ana başlığa bakar:

• Kimlik doğrulama ve bağlantı sinyalleri (SPF, DKIM, DMARC, rDNS, HELO/hostname)
• IP ve alan adı (domain) itibarı
• İçerik kalitesi (metin, linkler, ekler, HTML yapısı)
• Alıcı davranışları ve teslimat istatistikleri (açma oranı, spam işaretleme, bounce oranı)

1. Kimlik Doğrulama ve DNS Tutarlılığı: SPF, DKIM, DMARC ve rDNS

Modern e‑posta dünyasında ‘Bu mesaj gerçekten bu alan adından mı gönderildi?’ sorusuna verilen teknik cevaplar çok önemli. Burada devreye üç kritik kayıt giriyor: SPF, DKIM ve DMARC.

• SPF (Sender Policy Framework): SMTP zarfındaki MAIL FROM veya HELO alan adı için hangi gönderim IP’lerinin yetkili olduğunu tanımlar; görünen From adresini tek başına doğrulamaz.
• DKIM (DomainKeys Identified Mail): İmzalanan seçili başlıkların ve gövdenin, DKIM’in normalleştirme kuralları kapsamında bütünlüğünü doğrular ve imzalayan alan adının sorumluluğunu belirtir; içerik güvenliğini veya kişinin kimliğini kanıtlamaz.
• DMARC: Görünen From alan adıyla hizalı en az bir başarılı SPF veya DKIM sonucu arar. Başarısız mesajlar için alan adının istediği işlemi (işlem talep etmeme, karantina veya ret) bildirir; nihai karar alıcıdadır.

Bu üçlünün ne olduğunu ve cPanel ile VPS üzerinde nasıl kurulduğunu detaylı anlattığımız SPF, DKIM ve DMARC rehberimizi mutlaka okuyun; bu yazıdaki birçok kontrol maddesi o makaleyle birlikte düşünülmeli.

Bunlara ek olarak kritik bir kayıt daha var: PTR (Reverse DNS). Alıcı sunucular, gönderim IP’sinin rDNS kaydını ve bu kayıttaki hostname’in ileri DNS çözümlemesini kontrol edebilir. Örneğin Gmail, PTR ile belirtilen mail.sizinalanadiniz.com gibi hostname’in A/AAAA kaydının gönderim IP’sine dönmesini ister. Bu konuyu pratik örneklerle anlattığımız PTR (Reverse DNS) kaydı rehberimize de göz atabilirsiniz.

2. IP ve Alan Adı İtibarı

İmzanız ne kadar düzgün olursa olsun, eğer gönderen IP’niz veya alan adınız daha önce spam olarak işaretlenmişse, kara listelere (RBL) girmişse veya aşırı bounce üretiyorsa, bu sinyaller alıcının filtreleme politikasına göre spam sınıflandırmasına veya reddedilmeye yol açabilir.

• Paylaşımlı hosting’te gönderim IP’si de paylaşılıyorsa IP itibarı ortaktır; başka bir kullanıcının hatalı kurguladığı kampanyalar sizi de etkileyebilir.
• Yalnızca sizin kullandığınız bir çıkış IP’si, gönderim trafiği üzerinde daha fazla kontrol sağlar; ancak VPS veya özel IP tek başına temiz itibar sağlamaz. IP geçmişi, gönderim düzeni ve alan adı itibarı da önemlidir.

Kara listeye düştüğünüzde neler yapmanız gerektiğini, hangi adımlarla itibarın geri kazanılacağını ayrı bir yazıda detaylandırdık: E‑posta itibarını kurtarma rehberi özellikle VPS tarafında kendi SMTP sunucusunu yönetenler için çok değerli.

3. İçerik Kalitesi ve Teknik Yapı

Filtreler, mesajınızın metnini, bağlantılarını ve HTML yapısını da değerlendirebilir. Tamamen görselden oluşan veya bozuk HTML içeren iletiler okunabilirliği azaltabilir; yanıltıcı bağlantılar ve agresif konu satırları da güven sorununa yol açabilir. Ancak belirli bir kelimenin, link sayısının ya da tasarım biçiminin tek başına spam kararı verdiği evrensel bir kural yoktur. İçeriği, gönderici itibarı ve doğrulama sonuçlarıyla birlikte değerlendirin.

4. Alıcı Davranışları ve İstatistikler

Alıcı davranışları ve teslimat istatistikleri yararlı göstergelerdir; ancak sağlayıcıların kullandığı sinyaller ve bunların ağırlıkları değişir. Gönderici panelindeki açılma oranını, alıcının filtreleme kararıyla bire bir eşitlememek gerekir:

• Kaç kişi e‑postayı açıyor?
• Kaç kişi doğrudan siliyor?
• Kaç kişi ‘spam’ veya ‘gereksiz’ olarak işaretliyor?
• Kaç gönderim geçersiz adres gibi kalıcı bir hatayla (hard bounce) geri dönüyor?

Özellikle yüksek spam şikâyeti ve geçersiz adreslere gönderim oranları, liste kalitesi ve gönderici itibarı açısından uyarı işaretleridir. Açılma veya silinme davranışından tek başına alan adınızın ya da IP’nizin ‘güvensiz’ sayıldığı sonucunu çıkarmayın. Liste temizliğini, teslim hatalarını ve alıcıların gerçekten beklediği içerikleri birlikte değerlendirin.

Paylaşımlı Hosting Üzerinde E‑posta: Avantajlar, Riskler ve Check‑list

Pek çok işletme için ilk adım, web sitesini ve e‑postaları aynı paylaşımlı hosting paketinde barındırmaktır. Bu seçenek için seçilen paketin e‑posta barındırma desteği, kota ve gönderim limitleri ihtiyaçlarla karşılaştırılmalıdır. Uygun kapasite ve yapılandırmayla küçük ve orta ölçekli işletmeler için ekonomik bir çözüm olabilir.

Ancak paylaşımlı hosting’in doğası gereği e‑posta tarafında bazı ek dikkat noktaları var:

• Gönderim IP adresi birçok müşteriyle ortak olabilir.
• rDNS (PTR) genellikle sunucu bazında ortak hostname’e işaret eder.
• Günlük/saatlik gönderim limitleri uygulanabilir (suistimali önlemek için).
• Sunucuda merkezi spam filtreleme (SpamAssassin vb.) bulunabilir; gelen ve giden posta denetimlerinin kapsamı farklı olabilir.

Paylaşımlı Hosting İçin Teslim Edilebilirlik Kontrol Listesi

Aşağıdaki maddeleri, e‑posta barındırma desteği olan bir paylaşımlı hosting paketini kullanırken e‑posta teslim edilebilirliğini artırmak için pratik bir kontrol listesi olarak düşünebilirsiniz:

1. E‑posta DNS kayıtlarınız kullandığınız hizmetle uyumlu mu?
   MX kayıtları gelen postayı alacak hizmeti, SPF ise yetkili gönderim kaynaklarını yansıtmalıdır. Web sitesi ve e‑posta farklı hizmetlerde olabilir; alan adının tüm kayıtlarını aynı hosting hesabına yönlendirmek gerekmez. Bu konuda adım adım rehber isterseniz, alan adını hosting hesabına bağlama rehberimize göz atabilirsiniz.
2. SPF kaydınız paylaşımlı sunucuya uygun mu?
   SPF kaydınız yalnızca kullandığınız yetkili gönderim kaynaklarını kapsamalıdır. Değerlendirilen alan adı için tek bir SPF TXT kaydı yayımlayın. DNS sorgusuna yol açan SPF terimlerinin 10 sınırı, iç içe include/redirect değerlendirmeleri dahil geçerlidir; bu, tüm DNS sorgularının basit toplamı değildir.
3. DKIM imzası etkin mi?
   Kontrol paneliniz destekliyorsa DKIM’i etkinleştirin ve gerekli açık anahtar TXT kaydını alan adının yetkili DNS sağlayıcısında yayımlayın. TXT kaydı tek başına giden postayı imzalamaz; gönderim sunucusunda imzalamanın da etkin olması gerekir.
4. DMARC kaydınız var mı?
   p=none politikasıyla başlayıp toplu raporlar için rua hedefi tanımlayın. Meşru gönderimlerin hizalı SPF veya DKIM ile geçtiğini değerlendirmeden quarantine ya da reject politikasına geçmeyin. Ret politikası her alan adı için uygun değildir; özellikle posta listesi kullanan genel amaçlı alan adlarında meşru iletileri etkileyebilir.
5. Görünen From alan adı doğrulamayla hizalı mı?
   Örneğin siteniz example.com ise, no-reply@example.com ya da info@example.com kullanabilirsiniz. Web sitesiyle aynı alan adı şart değildir; gönderim için yetkili olduğunuz bir alan adı kullanın ve DMARC için From alan adının başarılı SPF veya DKIM kimliğiyle hizalanmasını sağlayın.
6. SMTP kimlik doğrulama kullanıyor musunuz?
   Web uygulamanızdan harici bir gönderim hizmetine bağlanıyorsanız, hizmetin TLS ve SMTP kimlik doğrulama ayarlarını kullanın. php mail() tek başına spam nedeni değildir; yerel posta sunucusu üzerinden gönderimde de DKIM imzalama, yetkilendirme ve günlük kaydı doğru yapılandırılmalıdır.
7. Gelen ve giden posta filtrelerini ayırıyor musunuz?
   Gelen posta için sunulan spam filtrelerini ayarlamak, gönderdiğiniz iletilerin alıcıda gelen kutusuna ulaşmasını sağlamaz. Panelinizde mevcutsa SpamAssassin ve RBL ayarlarını yönetmek için cPanel’de e‑posta spam filtreleme rehberimizden yararlanabilirsiniz.
8. Aynı IP’den toplu pazarlama kampanyası gönderiyor musunuz?
   Yüksek hacimli kampanyalarda, gönderim limitleri ve pazarlama trafiğine izin verilip verilmediği belirleyicidir. Bu hacme uygun bir gönderim hizmeti veya ayrı altyapı değerlendirilebilir; yalnızca VPS/özel IP’ye geçmek teslim edilebilirlik sağlamaz.
9. Liste temizliği ve geri dönen mailler
   Kalıcı teslimat hatalarını (hard bounce) nedenlerine göre inceleyin; geçersiz adreslere gönderimi durdurun. Yüksek hata oranları liste kalitesi sorununa işaret edebilir ve itibarı olumsuz etkileyebilir. Geri dönen mesajları anlamak için SMTP hata kodları ve bounce mesajları rehberimizden yararlanabilirsiniz.
10. İçerik ve imza standardı
    Okunabilir bir HTML şablonu, metin‑görsel dengesi, açık gönderen bilgileri ve yanıltıcı olmayan konu satırları kullanın. Pazarlama iletilerinde görünür abonelikten çıkış bağlantısı sağlayın; Gmail’in toplu gönderici kuralları kapsamındaki pazarlama/abonelik iletilerinde ayrıca tek tıkla abonelikten çıkış mekanizması gerekir. Bunlar tek başına gelen kutusuna teslim garantisi değildir.

VPS Üzerinde Kendi E‑posta Sunucunuzu Kullanmak

Daha fazla kontrol, ayrı IP ve gelişmiş politika yönetimi gerekiyorsa, VPS üzerinde kendi SMTP sunucunuzu çalıştırmak bir seçenek olabilir. Yüksek hacimli gönderim için ayrıca sağlayıcının gönderim politikalarını, limitlerini ve sunucu yönetimi sorumluluklarını değerlendirmek gerekir. Postfix/Dovecot gibi çözümler bu tür bir posta altyapısının bileşenleri olarak kullanılabilir.

Paylaşımlı hosting’te birçok posta ayarını sağlayıcı yönetirken, yönetilmeyen bir VPS’te yapılandırma, güvenlik ve bakım sorumluluğu size aittir. VPS daha fazla kontrol ve görünürlük sağlayabilir; ancak doğru yapılandırma bile tek başına daha iyi teslim edilebilirlik garantisi değildir.

Başlangıç için detaylı teknik rehber arıyorsanız, adım adım kurulum anlattığımız VPS’te e‑posta sunucusu kurulumu yazımızı mutlaka inceleyin.

VPS İçin Teslim Edilebilirlik Kontrol Listesi

VPS üzerinde kendi posta sunucunuzu çalıştırıyorsanız, aşağıdaki başlıkların her biri kritik önem taşır:

1. Doğrudan SMTP teslimi için giden TCP 25 erişimi
   Alıcı alan adının MX sunucularına doğrudan teslim yapacaksanız, seçtiğiniz sağlayıcı ve VPS planının giden TCP 25 bağlantılarına izin verdiğini doğrulayın. Sunucu ve ağ güvenlik duvarlarının da bu çıkışı engellemediğini kontrol edin. İstemcilerin ileti gönderimi için kullanılan 587 portuna erişebilmesi, doğrudan sunucudan sunucuya teslim için TCP 25 erişiminin yerini tutmaz. Bu erişim sağlanamıyorsa, kullanımınıza izin veren yetkili bir SMTP relay hizmetini değerlendirin; hizmetin bağlantı, TLS, kimlik doğrulama, kota ve alan adı doğrulama gereksinimlerini karşılayın.
2. Hostname ve PTR uyumu
   VPS’inizin hostname’i (örneğin mail.example.com), giden SMTP bağlantısında kullanılan HELO/EHLO adı ve gönderen IP’nin PTR kaydı tutarlı olmalı. PTR’nin gösterdiği adın A/AAAA kaydı da aynı gönderen IP’ye dönmeli. rDNS kurulumunu ve etkilerini detaylandırdığımız PTR rehberini burada tekrar hatırlatalım. Harici relay kullanıyorsanız, alıcıya bağlantıyı kuran çıkış IP’si relay hizmetine aittir; bu çıkışın PTR ve HELO/EHLO yapılandırmasını hizmet yönetir.
3. SPF, DKIM ve DMARC eksiksiz kurulu mu?
   SPF kaydı yalnızca sizin gerçek gönderenlerinizden (doğrudan gönderimde VPS IP’niz ve gerekiyorsa üçüncü taraf servisler) oluşmalı. Harici relay kullanıyorsanız onun yetkili gönderim kaynaklarını da hizmetin yönergelerine göre tanımlayın. DKIM imzaları, MTA’nızın imzalama özelliği, ona entegre edilen bir imzalayıcı veya kullandığınız gönderim hizmeti tarafından eklenmeli ve alıcıda doğrulanmalı. DMARC raporlarıyla meşru gönderim kaynaklarını ve görünür From alan adıyla SPF/DKIM hizalamasını izleyin. Politikayı ancak bu akışları doğruladıktan sonra sıkılaştırmayı değerlendirin; her alan adı için reject uygun değildir.
4. IPv6 kullanıyorsanız ek kontroller
   IPv6 üzerinden mail gönderiyorsanız, kullanılan IPv6 çıkış adresi için de IPv6 ile e‑posta teslimi rehberimizde anlattığımız PTR, HELO, SPF ve RBL kontrollerini yapın. Yalnızca IPv4 yapılandırmasını kontrol etmek, IPv6 üzerinden yapılan gönderimleri kapsamaz.
5. IP ısıtma (IP warming)
   Yeni bir IP’den ilk günden binlerce alıcıya mail göndermek, filtreleme veya geçici kısıtlama riskini artırabilir. İlk günlerde düşük hacimle, izinli ve etkileşimli alıcılara gönderim yapın; hacmi teslim sonuçlarına göre kademeli artırın. Ayrıntıları için yine e‑posta itibarını kurtarma rehberindeki IP ısıtma bölümüne bakabilirsiniz.
6. Güvenli TLS ve modern SMTP güvenlik özellikleri
   Gmail gönderici yönergeleri TLS kullanımını gerektirir. MTA‑STS ve TLS‑RPT gibi ek protokolleri de taşıma güvenliği tasarımınız kapsamında değerlendirin; bunları gelen kutusuna ulaşma garantisi olarak görmeyin. Bu başlıkları teknik seviyede anlattığımız MTA‑STS, TLS‑RPT ve DANE rehberimiz VPS tarafı için özellikle önemli.
7. Rate limit ve kuyruk yönetimi
   MTA’nızda alıcı başına, domain başına ve toplamda saniye/dakika başına gönderim limitleri tanımlayın. Böylece bir uygulama hatası veya sızma durumunda kısa sürede gönderilebilecek spam miktarını sınırlayabilirsiniz; limitler tek başına kötüye kullanımı veya itibar kaybını engellemez.
8. RBL kontrolleri ve log takibi
   Sunucunuzun düzenli olarak yaygın kara listeleri kontrol etmesini sağlayın veya bunu manuel olarak takip edin. Log analizi, hem teslim hatalarını hem de olası kötüye kullanımları (relay attempt, brute‑force vs.) görebilmeniz için kritik.
9. Yetkisiz relay kapalı mı?
   Sunucunuz ‘open relay’ olmamalı: Yetkisiz istemcilerin üçüncü taraf alan adlarına posta aktarmasına izin vermeyin. Kimliği doğrulanmış kullanıcılar ve açıkça tanımlanmış güvenilir istemciler için aktarım yetkisini sınırlayın. Sunucunuzun hizmet verdiği alan adlarına gelen postayı kabul etmek ise relay yetkisi vermekle aynı şey değildir. Açık relay, kötüye kullanım ve kara liste riskini artırır.
10. Doğru bounce işleme ve liste temizliği
    Kalıcı olarak geçersiz adresleri gönderim listesinden çıkaran bir süreç kurun. Geçici teslim hatalarını kalıcı adres hatalarından ayırın; yalnız hata sayısına bakarak adresleri otomatik silmeyin. SMTP hata kodlarını doğru yorumlamayı bilmiyorsanız, yine SMTP hata kodları rehberi burada yol gösterici olacaktır.
11. E‑posta yönlendirmeleri için SPF/DMARC farkındalığı
    Forwarding (yönlendirme), SPF doğrulamasını bozabilir. Görünür From alan adıyla hizalanmış geçerli bir DKIM imzası korunursa DMARC yine başarılı olabilir. Bu konuda e‑posta yönlendirmede SPF/DMARC neden kırılıyor? yazımızı mutlaka inceleyin; SRS ve ARC’nin hangi sorunları ele aldığını ve sınırlarını değerlendirin. Özellikle ARC, alıcının değerlendirmesine bağlıdır; otomatik DMARC geçişi veya teslim garantisi sağlamaz.

İçerik ve Tasarım Kaynaklı Spam Sorunları

Altyapınız mükemmel kurulmuş olsa bile, içeriğiniz spam filtresinin kırmızı çizgilerini zorluyorsa yine klasörün yanlış tarafında kalabilirsiniz. Aşağıdaki noktalara dikkat etmenizi tavsiye ederiz:

• Metin/görsel dengesi: Tamamen görselden oluşan e‑postalar yerine, her zaman yeterli düz metin içeren, görseller için alt metinleri olan tasarımlar kullanın.
• Okunabilir HTML: Gereksiz karmaşıklığı ve bozuk HTML’yi azaltın. Tablo veya inline stil kullanımı tek başına spam göstergesi değildir; okunabilirliği ve farklı e‑posta istemcilerinde düzgün görüntülenmeyi hedefleyin. Temiz kodlu, responsive tasarımlar tercih edin.
• Abonelikten çık (unsubscribe) linki: Pazarlama ve abonelik iletilerinde görünür, çalışan bir çıkış bağlantısı sunun. Gmail’in toplu gönderici kurallarına tabi bu iletilerde ayrıca tek tıkla abonelikten çıkma desteği gerekir; yalnız gövdedeki bağlantı yeterli değildir. Kolay çıkış, spam şikâyeti yerine abonelikten ayrılmayı teşvik eder.
• Gerçek gönderici bilgileri: Şirket adı ve uygun iletişim bilgilerini footer’da sunun. Açık adres veya telefon gibi bilgilerin zorunluluğunu, ileti türüne ve geçerli mevzuata göre değerlendirin.
• Yanıltıcı veya agresif dil ve biçim: Aşırı büyük harf, çok sayıda ünlem, ‘hemen tıkla’, ‘bedava para’ vb. agresif ifadelerden uzak durun. Amaç belirli kelimelerden kaçınarak filtreyi aşmak değil, alıcıya açık ve yanıltıcı olmayan bir ileti sunmaktır.

IP ve Alan Adı İtibarını Korumak İçin Sürekli Yapılması Gerekenler

Teslim edilebilirlik, bir kere ayarlanıp unutulacak bir şey değil; devam eden bir süreç. Özellikle VPS veya özel IP kullananlar için aşağıdaki rutinleri oturtmak büyük fark yaratır:

• Düzenli kara liste kontrolü: Haftalık veya aylık periyotlarla IP ve alan adınızı RBL listelerine karşı tarayın.
• DMARC raporlarının analizi: Rutin takipte toplu RUA raporlarıyla gönderim kaynaklarını ve SPF/DKIM doğrulama ve hizalama sonuçlarını inceleyin. Harici bir alan adındaki rapor hedefine gönderim için raporu alacak tarafın DNS üzerinden yetkilendirme yapması gerekir. Raporlar tüm gönderimleri kapsamayabilir; RUF hata raporlarını birçok sağlayıcı üretmez ve bu raporlar kişisel veri veya ileti içeriği barındırabilir. Politikayı sıkılaştırırken posta listesi ve yönlendirme akışlarını da değerlendirin. Posta listesi kullanıcıları bulunan genel amaçlı alan adlarında p=reject yayımlanmamalıdır. Ret politikası kullanan alan adları yalnız SPF’ye güvenmemeli, geçerli DKIM imzaları da uygulamalıdır.
• Gönderim istatistiklerini takip: Açılma oranları, spam şikâyetleri, bounce oranları gibi metrikleri düzenli gözden geçirin.
• Şüpheli aktivite alarmı: Bir anda fırlayan gönderim hacmi, olağan dışı hata kodu artışı vb. durumlar için alarm mekanizması kurun.

Eğer bir şekilde itibarınız bozulduysa, ‘sil baştan domain değiştireyim’ demeden önce itibar kurtarma rehberindeki adımları dikkatlice uygulamanızı öneririz.

Paylaşımlı Hosting'den VPS'e Geçmek Teslim Edilebilirliği Nasıl Etkiler?

Bir noktadan sonra aşağıdaki sorunları sık yaşamaya başladıysanız, e‑posta tarafını da içerecek şekilde paylaşımlı hosting’den VPS’e geçmeyi düşünmenin zamanı gelmiş olabilir:

• Paylaşılan IP itibar sorunları (başka bir kullanıcının spam’i sizi vuruyor).
• Daha yüksek hacimli transactional veya pazarlama e‑postalara ihtiyacınız var.
• Daha gelişmiş politika yönetimi, log analizi ve güvenlik kontrolleri istiyorsunuz.

Web sitesi ile e‑posta aynı anda taşınmak zorunda değildir; e‑postayı mevcut hizmette bırakmak veya ayrı bir gönderim hizmeti kullanmak da değerlendirilebilir. E‑postayı VPS’e taşıyacaksanız, IP, DNS, gönderim erişimi ve bakım sorumluluklarını ayrıca planlayın. Genel geçiş yaklaşımı için Paylaşımlı Hosting’den VPS’e sorunsuz geçiş rehberimizi inceleyebilir, IP, DNS ve e‑posta tarafındaki dikkat noktalarını önceden not alabilirsiniz.

Eğer ağırlıklı olarak e‑posta tarafını düşünüyorsanız, seçeceğiniz VPS planında ve kuracağınız altyapıda şu gereksinimleri doğrulayın:

• Alıcı MX sunucularına doğrudan teslim için giden TCP 25 bağlantılarına sağlayıcı ve seçilen plan tarafından izin verilmesi, sunucu ve ağ güvenlik duvarlarının bu çıkışı engellememesi; erişim sağlanamıyorsa kullanımınıza uygun yetkili bir SMTP relay hizmeti seçeneği,
• Doğrudan gönderim yapacaksanız kendinize özel bir gönderen IP adresi kullanabilme,
• Bu IP’nin PTR/rDNS kaydını sağlayıcı üzerinden düzenleyebilme ve ileri DNS ile tutarlı kurgulayabilme,
• Postfix/Dovecot gibi posta yazılımlarını yapılandırmak için gerekli yönetim erişimi,
• DMARC, MTA‑STS ve TLS‑RPT için gerekli DNS ve hizmet yapılandırmalarını yönetebilme.

Sonuç: Altyapı, İtibar ve İçeriği Birlikte Değerlendirin

Kurumsal tarafta e‑posta hâlâ en kritik iletişim kanallarından biri. Fatura, sözleşme, şifre sıfırlama, sipariş onayı, destek biletleri ve pazarlama kampanyaları; hepsi e‑posta üzerinden dönüyor. Altyapı hataları bu iletilerin reddedilmesine, gecikmesine veya spam olarak sınıflandırılmasına yol açabilir.

Bu yazıda hem paylaşımlı hosting hem VPS için ayrı ayrı birer teslim edilebilirlik kontrol listesi ortaya koyduk. SPF, DKIM, DMARC, PTR, IP ısıtma, içerik düzeni, liste temizliği ve DMARC raporları gibi başlıklar ilk bakışta karmaşık görünebilir; ama adım adım ilerlediğinizde her birini rayına oturtmak mümkün.

Yeni bir yapı kurmayı ya da paylaşımlı hosting’den VPS’e geçmeyi düşünüyorsanız, paket ve mimari seçimini gönderim hacminize, sunucu yönetimi kapasitenize ve ihtiyaç duyduğunuz destek kapsamına göre yapın. Sağlam bir e‑posta altyapısı teslim edilebilirliği destekler, ancak gelen kutusuna ulaşmayı garanti etmez. Altyapı ve itibar kontrollerini içerik kalitesi, liste temizliği ve alıcı geri bildirimleriyle birlikte değerlendirin.