2026 yilinda kendi e-posta sunucusunu kurmak mantikli mi?

Kısa cevap

2026 yılında kendi e-posta sunucunuzu barındırmak, işi ikiye böldüğünüz sürece hala mantıklıdır. Kendi e-postalarınızı kendi VPS sunucunuzda almak düşük risklidir ve çalışır; çünkü alıcı sizsiniz ve kimsenin size güvenmesi gerekmez. Büyük posta kutusu sağlayıcılarının kabul edeceği şekilde e-posta göndermek ise farklı bir iştir ve bu, inşa etmek yerine devraldığınız bir IP adresi itibarına dayanır.

Deneyimli operatörlerin fiilen kullandığı kurulum hibrit bir yapıdır. Kendi sunucuları posta kutularını ve arşivi tutar; giden e-postalar ise 587 numaralı port üzerinden kimlik doğrulamalı bir relay (aktarıcı) aracılığıyla gönderilir. Her iki yönde tam self-hosting, hala birkaç özel durumda avantajlıdır ve bu durumlar yazının sonuna doğru açıklanmıştır.

Kendi e-posta sunucunuzu barındırmanın zor kısmı teslim edilebilirliktir

Bir e-posta sunucusu kurmak bir hafta sonu sürecek bir iştir. Modern bir yığın; e-posta iletimi için SMTP (simple mail transfer protocol), okuma için IMAP (internet message access protocol), spam filtreleme ve bir webmail arayüzünü tek bir compose dosyasında sunar; Mailcow mail server install on a VPS rehberi bu konuları kapsamaktadır. Kurulumun hiçbir aşaması zor değildir.

Zorluk, sunucunuz sizi hiç tanımayan bir şirketin işlettiği bir makineye bağlantı açıp bir mesajı birinin gelen kutusuna yerleştirmesini istediğinde başlar. Alıcının bunu kabul etmesi için hiçbir nedeni yoktur. Kararını şu sinyallere göre verir: bağlantı kuran IP adresinin itibarı, alan adınızın itibarı, mesajın doğrulanmış olup olmadığı ve kendi kullanıcılarının daha önce sizin postalarınıza nasıl tepki verdiği. Yeni bir göndericinin hiçbir geçmişi yoktur ve geçmişin yokluğu nötr olarak puanlanmaz. Risk olarak puanlanır. Bu yüzden ilk mesajlar spam klasörüne düşer veya bir düzen oluşana kadar ertelenir.

Reddedilme durumunu göreceksiniz. Gmail şu biçimde kalıcı bir ret gönderir:

550-5.7.1 [203.0.113.5      19] Our system has detected that this message is
550-5.7.1 likely unsolicited mail. To reduce the amount of spam sent to Gmail,
550-5.7.1 this message has been blocked.

Microsoft, değişen bir blok listesi koduyla biten farklı bir ret gönderir:

550 5.7.1 Unfortunately, messages from [203.0.113.5] weren't sent. Please
contact your Internet service provider since part of their network is on
our block list (S3150).

Her şeyden önce ilk rakamı okuyun. 4 ile başlayan bir kod geçicidir, bu nedenle sunucunuz mesajı tutar ve yeniden dener. 5 ile başlayan bir kod kalıcıdır, bu nedenle mesaj doğrudan göndericiye geri döner. Asla düzelmeyen bir 4xx ertelemesi, bir hız sınırı veya itibar sınırıdır ve kendiliğinden çözülebilir. Bir 5xx ise kesin bir karardır ve düzelmeyecektir.

Yeni bir sunucunun e-postaları neden spam klasörüne düşer?

Çünkü IP adresi yeni değildir. Size temiz bir adres verilmez. Sağlayıcınızın havuzundan geri dönüştürülmüş bir adres alırsınız ve bu adresin geçmişi de beraberinde gelir. Eğer önceki kullanıcı spam gönderdiyse, daha ikinci mesajınızı göndermeden ilk mesajınız reddedilebilir.

Üzerinde herhangi bir kurulum yapmadan önce adresi kontrol edin. Genel kara listeler (blocklist), adresin dört oktetinin ters çevrilmesiyle DNS üzerinden yanıt verir:

sudo apt update && sudo apt install -y bind9-dnsutils netcat-openbsd swaks
dig +short 10.0.0.10.zen.spamhaus.org

Boş bir yanıt, adresin listelenmediği anlamına gelir. 127.0.0.0/8 içinde bir yanıt ise adresin listelendiğini gösterir; son oktet ise hangi listenin eşleştiğini belirtir. Bu testteki bir tuzak şudur: Spamhaus, büyük genel çözümleyiciler (resolver) üzerinden gelen sorguları reddeder; bu nedenle 8.8.8.8 üzerinden yapılan aynı sorgu, gerçek durum ne olursa olsun 127.255.255.254 sonucunu döndürür. Bu kod, adresin listelendiği anlamına değil, sorgunun reddedildiği anlamına gelir. Testi kendi sunucunuzun çözümleyicisi üzerinden çalıştırın veya web tabanlı arama aracını kullanın.

Temiz bir sonuç gereklidir ancak yeterli değildir. Listelenmemiş olmak, sadece yakın zamanda o adres hakkında kimsenin şikayetçi olmadığı anlamına gelir. Bu durum pozitif bir itibar sağlamaz; e-postaların gelen kutusuna ulaşmasını sağlayan şey ise pozitif itibardır. İtibar, haftalar boyunca küçük hacimlerde istenen e-postalar gönderilerek kazanılır.

Komşularınız da önemlidir; çünkü bazı alıcılar itibarı tek bir adres yerine tüm ağ bloğu üzerinden değerlendirir. Aynı /24 aralığındaki başka bir müşteri spam göndermeye başladığında, e-postalarınız ilişkilendirme nedeniyle yavaşlayabilir. Bu blok düzeyindeki bakış açısı, hesap sahibinin hiç göndermediği trafik için neden bir VPS gelen kutusuna kötüye kullanım şikayetleri geldiğini de açıklar: şikayet, adres aralığını takip eder.

Başlamadan önce doğrulanması gerekenler: 25 numaralı port ve PTR kaydı

Giden TCP 25 numaralı port, internet üzerinde en çok suistimal edilen porttur; bu nedenle birçok barındırma sağlayıcısı, yeni hesaplarda bu portu varsayılan olarak kapatır. Bazıları talep üzerine açar. Bazıları ise hesap belirli bir süre aktif kaldığında ve ödeme geçmişi oluştuğunda açar. Bazıları ise hiçbir şekilde açmaz. Politikalar sağlayıcılar arasında farklılık gösterir ve zamanla değişebilir; bu yüzden bu gönderiyi, eski bir forum başlığını veya herhangi bir sağlayıcının pazarlama sayfasını güncel bir gerçek olarak kabul etmeyin. Ödeme yapmadan önce sorun ve yanıtı yazılı olarak alın.

Sunucunun kendisinden yolu test edin:

nc -vz gmail-smtp-in.l.google.com 25

Açık bir yol, bir saniye içinde succeeded! çıktısını verir. Engellenmiş bir yol ise askıda kalır ve ardından engeli belirten hiçbir mesaj vermeden zaman aşımına uğrar; çünkü sessizce düşürülen bir paket, sıradan bir ağ sorunuyla tamamen aynı görünür.

İkinci gereksinim, ters DNS olarak da adlandırılan bir PTR kaydıdır. Alıcılar, kendilerine bağlanan IP adresini alır, bir isim elde etmek için bu adresin PTR kaydına bakar, ardından bu isimden tekrar bir adres elde etmek için sorgulama yapar. İkisi birbiriyle eşleştiğinde buna "forward-confirmed reverse DNS" denir ve bu, bağlanan ana bilgisayarın iddia ettiği kişiye ait olduğunu doğrulayan ucuz bir kontroldür.

dig -x 203.0.113.5 +short
dig +short mail.example.com

Birincisi, posta ana bilgisayar adınızı döndürmelidir. İkincisi, başladığınız adresle aynı adresi döndürmelidir. Bir IP adresinin PTR kaydını yalnızca o adresin sahibi yayınlayabilir; bu nedenle bu, barındırma sağlayıcınızın sizin için ayarladığı veya bir kontrol panelinde sunduğu bir işlemdir. Eksik bir PTR kaydı veya 203-0-113-5.static.example-isp.net gibi genel bir kayıt, güçlü bir olumsuz sinyaldir; çünkü gerçek posta sunucuları neredeyse her zaman eşleşen bir isme sahiptir, toplu spam kaynakları ise genellikle sahip değildir.

Eğer barındırma sağlayıcınız IPv6 da atıyorsa ve sunucunuz bunu tercih ediyorsa, yukarıdakilerin tümü IPv6 adresi için de geçerlidir ve Gmail bu konuda daha katıdır. PTR kaydı olmayan bir adresten IPv6 üzerinden gönderim yapmak, mesajın PTR kayıtları ve kimlik doğrulama ile ilgili IPv6 gönderim kurallarını karşılamadığına dair bir reddedilme ile sonuçlanır. Eğer bir IPv6 PTR kaydı ayarlayamıyorsanız, yalnızca IPv4 üzerinden gönderim yapın. Postfix içinde IPv4'ü tercih etmek için smtp_address_preference = ipv4, IPv6'yı tamamen kapatmak için ise inet_protocols = ipv4 kullanılır.

Herhangi bir barındırma sağlayıcısına sorulması gereken üç soru

1. Yeni bir hesapta giden TCP 25 numaralı port açık mı? Eğer açık değilse, açılması için izlenmesi gereken tam süreç ve zaman çizelgesi nedir?
2. IPv4 adresim ve IPv6 adresim için PTR kaydını ayarlayabilir miyim ve bunu nereden yapabilirim?
3. Adresim, önceki bir müşteri nedeniyle bir engelleme listesinde (blocklist) çıkarsa, beni farklı bir adrese taşır mısınız?

Bu üç soruyu satın almadan önce sorun, aldıktan sonra değil. İlk ikisine net yanıt veren ancak üçüncüsüne hayır diyen bir sağlayıcı ile yine de çalışılabilir; çünkü adresi ilk gün kontrol edip iptal edebilirsiniz. Bunların hiçbirine yazılı yanıt vermeyen bir sağlayıcı, orada posta sunucusu çalıştırmanın nasıl bir deneyim olacağını size zaten göstermiştir.

SPF, DKIM ve DMARC gerçekte neyi kanıtlar?

Alan adınızdan geldiği iddia edilen postaların gerçekten oradan gönderildiğini üç DNS kaydı kanıtlar. Her biri farklı bir soruya yanıt verir ve üçüncüsü ancak ilk ikisi anlaşıldığında işlevsel hale gelir.

SPF (sender policy framework), alan adınız adına hangi sunucuların posta gönderebileceğini listeleyen bir TXT kaydıdır. Alıcı sunucu, bunu SMTP MAIL FROM komutunda verilen zarf gönderici adresiyle karşılaştırır; bu adres, okuyucunuzun gördüğü From: başlığı değildir.

DKIM (domainkeys identified mail), ileti gövdesini ve seçilen başlık listesini kapsayacak şekilde ileti başlıklarına kriptografik bir imza ekler. Eşleşen genel anahtar, seçtiğiniz bir seçici (selector) altında DNS'te yer alır. Herhangi bir alıcı, iletinin özel anahtarınızın sahibi tarafından gönderildiğini ve yolda değiştirilmediğini doğrulayabilir.

DMARC (domain-based message authentication, reporting and conformance), diğer ikisini görünürdeki From: başlığındaki alan adıyla ilişkilendirir ve eşleşme başarısız olduğunda alıcıların ne yapması gerektiğini bildirir.

example.com.                  TXT  "v=spf1 mx -all"
mail._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc.example.com.           TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Burada önemli olan kavram hizalamadır (alignment). DMARC, sadece SPF geçtiği için başarılı olmaz. DMARC, SPF veya DKIM başarılı olduğunda ve başarılı olan alan adı, From: başlığındaki alan adıyla aynı olduğunda geçer. Aktarılan (relayed) postaların sessizce başarısız olduğu nokta burasıdır: Zarf göndericisini kendi alan adına yeniden yazan bir aktarıcı, SPF'in geçmesini sağlar ancak başarılı olan alan adı aktarıcınınki olduğu için hizalama gerçekleşmez. Kendi DKIM imzanız mevcut ve geçerli değilse DMARC başarısız olur. Alan adınız altında yayınlanan bir anahtarla imzalama yaptığınızda bu sorun ortadan kalkar.

Hizalama, yönlendirme (forwarding) durumunu da açıklar. Bir posta listesi veya eski bir üniversite adresi iletinizi ileriye yönlendirdiğinde, yönlendiren sunucu bağlantı kuran IP adresi haline gelir. Bu IP adresi sizin SPF kaydınızda bulunmadığı için SPF nihai varış noktasında başarısız olur. DKIM ise imzaladığı başlıklar değiştirilmediği sürece yönlendirme sürecinde hayatta kalır. Çalışması gereken mekanizma DKIM'dir.

Önce rua= raporlama adresiyle p=none kaydını yayınlayın ve herhangi bir kısıtlama yapmadan önce iki hafta boyunca toplu raporları inceleyin. Bu raporlar, adınıza gönderilen ancak sizin göndermediğiniz postaları görebileceğiniz tek yerdir ve unuttuğunuz yönlendiricileri bulmanın tek yoludur. Doğrudan p=reject politikasına geçmek bu adımı atlar ve neyin bozulduğuna dair hiçbir kayıt bırakmadan meşru postaların engellenmesine neden olur.

Ardından tüm zinciri uçtan uca test edin. Büyük bir sağlayıcıda sahip olduğunuz bir hesaba bir ileti gönderin ve ham kaynak kodunu açın:

swaks --to you@gmail.com --from postmaster@example.com --server 127.0.0.1
sudo journalctl -t postfix/smtp -f

swaks, SMTP görüşmesini gerçekleştiği anda yazdırır. Postfix'in teslimat için kendi günlük satırı, alıcı sunucu iletiyi kabul ettiğinde status=sent (250 2.0.0 OK ...) ile biter. Bunun dışındaki durumlar reddetme metnini olduğu gibi günlüğe kaydeder; aramanız gereken metin budur. Teslim edilen iletide, ham kaynak kodu her bir denetimi "pass" veya "fail" durumuyla ve doğruladığı alan adıyla belirten bir Authentication-Results: başlığı taşır. Her üçü de "pass" demeli ve alan adı sizinkiyle eşleşmelidir.

İtibar sorunu nasıl tespit edilir?

Geri bildirim döngüsü (feedback loop), bir posta kutusu sağlayıcısının, kullanıcılarından biri "spam bildir" düğmesine tıkladığında size mesajın bir kopyasını gönderdiği bir düzenlemedir. Bu mekanizma olmadan sorunun ilk işareti, teslimatın başarısız olmasıdır ki bu da haftalar süren bir gecikme anlamına gelir.

Programlar farklılık gösterir ve hepsi tek bir IP adresine sahip tek bir VPS için uygun değildir. Ağustos 2026 itibarıyla Microsoft, adres sahibinin kaydolabileceği adres bazlı bir veri ve şikayet hizmeti yürütmektedir; Yahoo, DKIM imzalama alan adına dayalı bir şikayet geri bildirim döngüsü sunmaktadır; Google ise bireysel şikayetler yerine toplu itibar verilerini, kullanıcılarına anlamlı bir günlük hacimde e-posta gönderene kadar boş kalan bir panelde yayınlamaktadır. Herhangi birine güvenmeden önce her birinin güncel şartlarını okuyun; çünkü bu programlar değişmektedir ve hiçbiri size erişim garantisi vermez.

Şubat 2024'ten beri yürürlükte olan Google'ın yayınlanmış toplu gönderici gereksinimleri, büyük bir alıcının artık ne beklediğine dair en net kamu beyanıdır. Kişisel Gmail hesaplarına günde 5.000'den fazla mesaj gönderen bir gönderici, SPF ve DKIM ile kimlik doğrulaması yapmalı, bir DMARC politikası yayınlamalı, toplu postalarda tek tıkla abonelikten çıkma seçeneği sunmalı ve spam şikayet oranını yüzde 0.3'ün altında tutmalıdır. Küçük bir sunucudan gelen kişisel postalar bu eşiğin çok altında kalır, ancak aynı sinyaller her hacimde okunur ve şikayet oranı, geri bildirim döngüsü olmadan göremeyeceğiniz tek veridir.

Çalışan ayrım: gelen e-postaları self-host etmek, gidenleri relay üzerinden göndermek

Gelen e-postalar, neredeyse hiçbir dezavantajı olmayan kısımdır. Size gönderilen postayı kabul etmeniz için kimsenin size güvenmesi gerekmez. Alan adınız için posta sunucusunu belirten DNS kaydı olan MX kaydınız sunucunuzu işaret eder; göndericiler size bağlanır ve sonrasındaki her karar size aittir: neyin saklanacağı, ne kadar süre tutulacağı, nasıl indeksleneceği ve kimlerin arama yapabileceği. Depolama ucuzdur ve sahibi olduğunuz bir arşiv, başka bir yerdeki otomatik politika kararıyla kapatılamaz. İş yükü gerçektir ancak sınırlıdır: spam filtresini güncel tutun, TLS (transport layer security) sertifikalarını yenileyin, yedek alın ve diskin dolmasını engelleyin.

Giden e-postalar ise zorlu sorundan kurtulmak için ödeme yaptığınız kısımdır. Sunucunuzu, dünya ile 25 numaralı port üzerinden konuşmak yerine, her giden mesajı 587 numaralı port üzerinden kimlik doğrulamalı bir relay'e iletecek şekilde yapılandırın. Postfix'in main.cf dosyasında:

relayhost = [smtp.relay.example]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = encrypt

Kimlik bilgilerini bir düzenleyici ile /etc/postfix/sasl_passwd dosyasına yazın, böylece parola hiçbir zaman shell geçmişinize düşmez. Bu tek satırlık bir işlemdir ve soldaki ana makine adı, relayhost dosyasında göründüğü şekilde tam olarak yazılmalıdır:

[smtp.relay.example]:587 username:password

sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd.db
sudo systemctl reload postfix

Bu yeniden yüklemeden sonra gönderilen bir mesaj relay=smtp.relay.example[...]:587 ve status=sent günlük kayıtlarını oluşturur. SASL authentication failed ifadesini içeren bir günlük satırı, kimlik bilgilerinin kabul edilmediği anlamına gelir; bunun yaygın nedeni, sasl_passwd dosyasındaki bir ana makine adının relayhost dosyasındakinden farklı yazılmış olmasıdır, çünkü arama işlemi tam bir karakter dizisi eşleşmesi gerektirir.

Bu ayrım işe yarar çünkü relay, arkasında yıllarca kabul edilmiş posta geçmişi olan adreslere sahiptir ve bu itibarı korumak onun ana işidir. Alan adını, posta kutularını, arşivi ve ayrılma yetkisini elinizde tutarsınız; çünkü relay değiştirmek tek satırlık bir yapılandırma ve bir DNS kaydından ibarettir. Vazgeçtiğiniz şey, giden postaların relay operatörüne karşı gizliliğidir. Bu, düzenlemenin dürüst maliyetidir ve bunu keşfetmek yerine önceden kararlaştırmak daha iyidir.

İlk gün yapılması gereken bir ayrım daha vardır. Toplu gönderilen her şey, kendi DKIM anahtarına sahip ayrı bir alt alan adından çıkmalıdır: bültenler için news.example.com ve kişisel postalar için mail.example.com. İtibar, gönderen alan adına bağlıdır; bu nedenle self-hosted Listmonk bülteni üzerindeki bir şikayet oranı, kişisel postalarınızın itibarını aşağı çekemez.

Tam kapsamlı self-hosting ne zaman doğru tercihtir?

Hacim. İleti başına ücretlendirme, aylık yüzlerce mesaj için makuldür ancak milyonlarca mesaj seviyesinde bu durum değişir. Bu ölçekte, özel IP adreslerini ve bunların çalışmasını sağlayan ısınma (warmup) takvimini karşılayabilirsiniz.

Yargı yetkisi. Bir yönetmelik veya sözleşme, postanın üçüncü taraf bir diske kaydedilmemesi gerektiğini belirtiyorsa, teslimat kalitesi belirleyici faktör değildir. Bu durumda bir relay hizmeti sizin için seçenek olamaz.

Satın alınamayacak düzeyde kontrol. Plan seviyesine değil, kendi politikanıza uygun saklama kuralları; sızıntıyı tespit edebilmek için her servis için ayrı bir adres; kendi kodunuzu çalıştıran filtreleme ve itiraz hakkı tanımayan sistemler tarafından askıya alınmayan hesaplar.

Ağınızdan asla çıkmayan postalar. Uyarılar ve diğer makineden makineye (M2M) postalar, her iki uç da size ait olduğu için teslim edilebilirlik sorunu yaşamaz. Kendi posta kutularınıza teslimat yapan yerel bir SMTP sunucusu tüm sorunu çözer; bu, bir asistana kendi self-hosted posta kutusunu verme konusunda MCP (model context protocol) arkasındaki modelin aynısıdır.

Eğer giden postaları doğrudan gönderiyorsanız, adresi ısıtın. Postalarınızı bekleyen kişilere düşük günlük hacimlerle başlayın, birkaç hafta boyunca kademeli olarak artırın ve soğuk bir adresten asla ani gönderim yapmayın. İtibar, zaman içinde az şikayet alan kabul edilmiş postalarla inşa edilir; bu nedenle geçmişi olmayan bir adresten gelen ani trafik artışı, tam olarak ele geçirilmiş bir sunucu gibi görünür ve öyle muamele görür.

Bir posta sunucusu çalıştırmanın ilk yılının maliyeti nedir?

İlk hafta kurulum sürecidir: paketler, DNS kayıtları, TLS sertifikaları, ilk test mesajları ve p=none seviyesinde DMARC.

İkinci ve altıncı haftalar arası, kimsenin planlamadığı kısımdır. DMARC toplu raporlarını okursunuz, varlığından haberdar olmadığınız bir hizalama sorunu bulursunuz, SPF'i bozan bir yönlendirici keşfedersiniz ve ardından politikayı p=quarantine, daha sonra ise p=reject seviyesine taşırsınız. Bu süreç, self-hosting işleminin sizin için rutin bir iş mi yoksa pişmanlık duyduğunuz bir yük mü olacağına karar verir.

Bundan sonra süreç ayda yaklaşık bir saate oturur: paket güncellemeleri, varsayım yerine doğrulama yaptığınız bir sertifika yenileme, yedekten geri yükleme testi, disk büyüme takibi ve bir adet kara liste sorgusu.

Bir de planlayamayacağınız o hafta vardır. Bir adres, yapmadığınız bir şey yüzünden listeye alınır. Büyük bir alıcı bir kuralı değiştirir ve postalarınız tekrar spam klasörüne düşmeye başlar. Kuyruktaki posta, kaybolmuş posta değildir: Postfix, maximal_queue_lifetime = 5d ile belirlenen varsayılan süre olan beş gün boyunca ertelenen bir mesajı yeniden denemeye devam eder; bu nedenle saatlerle ölçülen bir kesinti size yalnızca gecikmeye mal olur. Haftalarla ölçülen bir kesinti ise postalarınızı kaybetmenize neden olur.

Yedek bir MX kaydı, göründüğünden daha zayıf bir çözümdür. Gönderen sunucular zaten kendi başlarına günlerce yeniden deneme yapar, bu yüzden sadece kuyruğa alan bir ikincil sunucu pek bir şey katmaz. Daha kötüsü, alan adınız için hangi adreslerin var olduğunu bilmeden posta kabul eden bir ikincil sunucu, var olmayan adresler için posta alır ve ardından bunları sahte gönderenlere geri döndürür; bu da yedeğinizi bir backscatter kaynağına dönüştürür. Eforunuzu izleme süreçlerine ve gerçekten test ettiğiniz bir geri yükleme işlemine harcayın.

Tüm bu süreci, sunucudaki diğer her şey için uygulayacağınız soruyla değerlendirin: buna sahip olmak size satın alamayacağınız bir şey sağlıyor mu? Posta kutuları ve arşiv için cevap genellikle evettir. Yabancılara giden teslimatlar için ise genellikle hayırdır. Bu, 2026 yılında self-hosting yapmaya değer şeyler listesi içindeki diğer öğeleri de ayıran aynı testtir.

FAQ

VPS sağlayıcım 25 numaralı giden portu engelliyorsa kendi e-posta sunucumu barındırabilir miyim?

Evet, e-posta almak ve bir relay üzerinden göndermek için barındırabilirsiniz. Gelen e-postalar sunucunuzdaki 25 numaralı porta ulaşır ve giden port engeli bunu etkilemez. Giden e-postalar ise sağlayıcıların engellemediği 587 numaralı port üzerinden kimlik doğrulamalı bir relay ile gönderilir. 25 numaralı port kapalıyken yapamayacağınız tek şey, diğer e-posta sunucularına doğrudan teslimat yapmaktır; çünkü sunucudan sunucuya teslimat tanım gereği 25 numaralı port üzerinden gerçekleşir. Durumu nc -vz gmail-smtp-in.l.google.com 25 ile test edebilirsiniz. Bir takılmanın ardından gelen zaman aşımı, portun engellendiği anlamına gelir.

SPF, DKIM ve DMARC kayıtlarımın tamamı başarılı olmasına rağmen e-postalarım neden spam klasörüne düşüyor?

Kimlik doğrulama, mesajı kimin gönderdiğini kanıtlar. Ancak mesajın istenip istenmediğini kanıtlamaz. Üçünün de başarılı olması sizi "tanımlanamayan" durumundan "tanımlanan" durumuna geçirir. Bundan sonra alıcı, IP adresinizin ve alan adınızın itibarına bakar; yeni bir göndericinin ise henüz bir itibarı yoktur. İtibarınızı, haftalar boyunca insanların beklediği küçük hacimli e-postalar göndererek oluşturun. Ardından PTR kaydının e-posta ana bilgisayar adınızla her iki yönde de eşleştiğini doğrulayın ve içeriğin, bağlantı kısaltıcılar veya bilinmeyen takip alan adları gibi kendi başına ceza puanı getiren unsurlar içermediğinden emin olun.

Kendi e-posta sunucumu barındırmak için özel bir IP adresine ihtiyacım var mı?

Doğrudan giden teslimat için evet. Bir e-posta sunucusu, PTR kaydını kontrol edebildiğiniz ve itibarı yalnızca size ait olan bir adrese ihtiyaç duyar; bir VPS adresi bu anlamda zaten özeldir. Kontrol edemediğiniz şey, IP adresinin geçmişi veya aynı ağ bloğundaki komşularıdır. Eğer giden e-postaları bir relay üzerinden gönderirseniz, itibar relay adresine ait olur ve sizinki yalnızca gelen bağlantıları kabul etmekle yükümlü kalır.

Ana e-posta adresimi kendi barındırdığım sunucuya taşımak güvenli mi?

Taşıma işlemini tek seferde yapmak yerine aşamalı olarak gerçekleştirin. Mevcut posta kutunuzu aktif tutun, kendi sunucunuzu ikinci bir hedef olarak ekleyin ve birkaç hafta boyunca bir kopyasını oraya yönlendirin. Bu süreçte DMARC raporlarını okuyun ve e-posta akışının her iki yönde de çalıştığını doğrulayın. MX kaydını, yalnızca bir haftalık test e-postaları doğru şekilde ulaştıktan sonra değiştirin. İnsanların pişmanlık duyduğu hata, gelen e-postaların kaybolmasına neden olan ani bir geçiştir; gelen e-posta trafiği, geri döndürülemeyecek tek kısımdır.

E-postalarımın kontrolünü elimde tutmamı sağlayan en küçük kurulum nedir?

Posta kutuları ve arşiv için kendi sunucunuzu kullanıp, giden e-postaları 587 numaralı port üzerinden kimlik doğrulamalı bir relay'e devretmektir. Verilerin ve alan adının sahibi siz olursunuz ve itibar sorununu tamamen aşarsınız. Fikrinizi değiştirmenin maliyeti düşük kalır; çünkü relay ayarı tek bir yapılandırma satırı ve bir SPF girişinden ibarettir, bu yüzden daha sonra değiştirmek sadece bir öğleden sonranızı alır.