VPS'te Kendi Mail Sunucusu Kurmak: Port 25, rDNS ve Spam Sorunu

Alıcı sunucu aslında neye, hangi sırayla karar verir?

Alıcı bir mail sunucusu bir dizi karar verir ve bunların çoğunu mesajınızın tek bir baytını bile okumadan önce verir. İşin faydalı kısmı bu sıralamadır, çünkü bağlantı aşamasındaki bir sorun daha iyi bir içerikle düzeltilemez ve geçmişi olmayan bir adresten gelen kusursuzca doğrulanmış bir mesaj yine de spam klasörüne düşer. Zinciri sırasıyla okumak, çabanızı nereye harcamanız gerektiğini gösterir — ki bu neredeyse hiçbir zaman insanların harcadığı yer değildir.

İlk karar TCP bağlantısında verilir: bu kim ve onunla hiç konuşmalı mıyım? O anda alıcının elinde IP adresiniz, ters DNS kaydınız ve alıcının ya da kullandığı kara liste sağlayıcılarının o adrese yüklediği her türlü itibar vardır. İkinci karar SMTP zarfında verilir — HELO ve MAIL FROM — burada SPF, bağlanan IP'ye göre değerlendirilir. Üçüncüsü mesaj verisiyle birlikte gelir; burada DKIM imzaları doğrulanır ve DMARC, doğrulama sonuçlarından birinin hizalanıp hizalanmadığına, görünür From: başlığındaki alan adıyla, karar verir. Ancak bunların hepsinden sonra içerik filtrelemeye benzer bir şey başlar ve o noktada sonucun büyük kısmı zaten belirlenmiş olur.

Buradan iki şey çıkar. En ucuz kazanımlar zincirin en başındadır: doğru bir PTR kaydı kontrol panelinde tek bir alana mal olur ve bütün bir ret sınıfını ortadan kaldırır. Zincirin en altı ise — herkesin endişelendiği kısım, mesajın metni — üzerinde en az söz sahibi olduğunuz kısımdır ve ancak yukarıdaki her şey temiz olduğunda önem kazanmaya başlar.

Port 25, Sorunun En Ucuz Kısmı

Neredeyse her büyük bulut sağlayıcısı, giden port 25'i varsayılan olarak engeller ve engeli kaldırmak talep göndermek anlamına gelir. AWS, Google Cloud, Azure, Oracle Cloud ve büyük VPS markalarının çoğu, çıkış trafiğinde 25 filtrelenmiş şekilde gelir; kaldırma talebi ise zaten kimliğinizi, kart bilgilerinizi ve telefon numaranızı taşıyan bir hesaba bağlı bir formdur. Kendi mail sunucunuzu kurma planı çoğunlukla tam burada sessizce ölür ve bu sayfaya insanları getiren aramanın genellikle 25 portu açık VPS gibi bir şeyin varyasyonu olmasının nedeni de budur.

Hangi portun ne işe yaradığını net biçimde ayırt etmek işe yarar, çünkü üçü sürekli birbirine karıştırılır. Port 25 sunucudan sunucuya çalışır: bir MX'in mesajı bir diğerine teslim etme yoludur, hiçbir zaman kimlik doğrulaması yapılmaz ve sizin kullanıcınız olmayan kişilere mail teslim etmek için önem taşıyan tek porttur. Port 587 gönderim (submission) içindir — kendi istemcileriniz, sunucunuz onlar adına aktarım yapmadan önce ona kimliğini doğrular. Port 465 aynı işi ilk bayttan itibaren TLS ile yapar; doksanlarda kullanımdan kaldırılmış, ardından RFC 8314 ile resmen geri getirilmiştir ve bugün akla yatkın varsayılan seçenektir. Giden 25'i kaybetmek dünyaya mail göndermenizi durdurur; gelen 25'i kaybetmek dünyanın size mail göndermesini durdurur ve birini diğeri olmadan kaybedip bir öğleden sonrayı DNS'i suçlayarak geçirmek gayet mümkündür.

BitVPS'te giden 25, her planda ve her lokasyonda varsayılan olarak açıktır. Kaldırılacak bir şey olmadığı için ne form vardır ne de istisna süreci. Gelen 25, 465 ve 587 ise genel bir katman-3 filtresi yerine mail'i anlayan bir temizleme (scrubbing) katmanının arkasındadır; önemli olan fark da tam olarak budur: SMTP'yi anlayan bir filtre, arkasındaki meşru MX görüşmesini kaybetmeden bir saldırı akışını eleyebilir. Ayrıntılar için mail sunucusu sayfasına bakın; scrubbing'in genel olarak ne anlama gelip gelmediğini ise DDoS anlatımı ele alıyor.

Açık bir port 25, gerekli bir koşuldur ama yeterli olmaktan çok uzaktır — bu rehberin üç bin kelime daha sürmesinin tam nedeni de budur.

Size verilen adres, yapılandırmanızdan daha fazlasına karar verir

Yapılandırmanız birkaç DNS kaydı ve bir günlük iştir. IP adresi ise sizin yazmadığınız bir geçmiştir. 2019'u eczane spamı göndererek geçirmiş bir /24 hatırlanır; geçen ay hesabı kapatılmış bir müşteriden geri dönüştürülen bir adres daha baştan önyargıyla karşılanır; komşuları gürültülü olan bir aralık, /24 seviyesinde puanlama yapan alıcılarda ilişkilendirme yoluyla yargılanır. Bunların hiçbiri makinenin içinden görünmez ve hiçbiri daha iyi bir main.cf ile düzelmez.

O yüzden karar vermeden önce kontrol edin, sonra değil. Genel kara listeler hikayenin bir kısmını anlatır: teslimatı gerçekten etkileyen Spamhaus'tur; SBL ve CSS gözlemlenen göndericileri, PBL operatörü doğrudan mail göndermemesi gerektiğini beyan etmiş aralıkları, DBL ise adresleri değil alan adlarını listeler. Barracuda ve SpamCop'a da bakmakta fayda var, nedeni giderildiğinde hızlıca temizlenirler. Ancak sonucunuzun büyük kısmına karar veren iki itibar özeldir: Google ve Microsoft, sadece Postmaster Tools ve SNDS üzerinden sorgulayabildiğiniz, IP başına ve alan adı başına puanlar tutar; bunlar da ancak yeterince mail gönderdiğinizde bir fikir oluşturmaya başlar.

Başka yerlerde bulacağınız kontrol listeleri hakkında iki uyarı. Bunların yarısı hâlâ SORBS'u kontrol etmenizi söylüyor: SORBS, sahibi tarafından 5 Haziran 2024'te kapatıldı ve bölgeleri artık hiçbir yanıt vermiyor, dolayısıyla ona karşı yapılan bir sorgu temiz bir rapor değil, ölü bir sorgudur. UCEPROTECT seviye 2 ve seviye 3'e de şüpheyle yaklaşın — bunlar komşuları ve tüm otonom sistemleri ilişkilendirme yoluyla listeler, ardından sizi hızlandırılmış kaldırma için ücret ödemeye davet eder; ciddi alıcıların çoğunun bunları yok saymasının nedeni de budur. Bir seviye 3 listelemesinin peşinden koşmak, bir hafta sonunu hiçbir şey elde etmeden harcamanın bir yoludur. Ciddiye alınması gereken kaynak Spamhaus'un kendi itibar portalıdır.

Bir host'un ya yardımcı olduğu ya da olmadığı kısım da tam olarak burasıdır. BitVPS, sağlama sırasında her adresi başlıca listelere karşı kontrol eder ve bir adres bir listede çıkarsa siz daha giriş bile yapmadan değiştirir; mail müşterilerini son on iki ay içinde önceki bir mail müşterisinden geri dönüştürülmemiş /29'lardan tahsis eder ve aynı veri merkezindeki makineler arasında sizi yeniden IP'lemeden bir /29'u taşıyabilir — bu, altı ayınızı harcayarak inşa ettiğiniz bir itibara sahip bir adres söz konusu olduğunda muazzam önem taşır. Bunların hiçbiri bir adresi iyi yapmaz; onu nötr yapar, ki dürüst olmak gerekirse herhangi bir host'un sunabileceği en fazla şey de budur.

PTR, HELO ve A kaydı aynı hikayeyi anlatmalı

Yetkin biçimde kurulmuş bir mail sunucusunun reddedilmesinin tek en yaygın nedeni budur ve bu sayfada doğru yapılması en ucuz olan şeydir. Üç adın birbiriyle uyuşması gerekir. Sunucunuz HELO'da bir ana bilgisayar adı bildirir; o adın, bağlandığı adrese işaret eden bir A kaydı vardır; ve o adresin, ana bilgisayar adına geri işaret eden bir PTR kaydı vardır. İleri yönde çözümlerseniz adrese varırsınız; geri yönde çözümlerseniz ada varırsınız. Bu gidiş-dönüşe ileri doğrulamalı ters DNS denir ve Şubat 2024'ten beri geçerli bir PTR kaydı Gmail'de bir incelik değil, toplu olsun olmasın her gönderici için açıkça belirtilmiş bir gerekliliktir.

Sıklık sırasına göre dört türlü ters gidiş var. Hiç PTR yoktur, çünkü host bu alanı sunmaz. Bir PTR vardır ama sağlayıcının genel PTR'ıdır — hosting şirketinin alan adıyla biten, her alıcıya bunun çoğunlukla mail göndermeyen bir aralıktaki kiralık bir adres olduğunu ilan eden türden. HELO adı yanlıştır: kurulumun varsayılanı, kısa ve niteliksiz bir ana bilgisayar adı ya da localhost — hiçbiri çözümlenmez. Ve dikkatli insanları bile yakalayan bir tanesi: makinede IPv6 vardır, alıcı bir AAAA kaydı yayınladığında MTA IPv6'yı tercih eder ve v6 adresinde PTR yoktur — böylece Gmail'e IPv4 üzerinden giden mail kusursuzca çalışırken aynı mail IPv6 üzerinden reddedilir. Ya v6 PTR'ını doğru şekilde ayarlayın ya da bunu yapana kadar aktarımı smtp_address_preference = ipv4 ile sabitleyin.

BitVPS'te PTR alanı, her IPv4 ve IPv6 adresi için panelde kendi kendinize yönetilir; zorunlu bir sağlayıcı son eki olmadan istediğiniz herhangi bir FQDN'yi kabul eder, değişiklikler beş dakikadan kısa sürede küresel olarak yayılır ve toplu düzenlemeler tek seferde on adrese kadar kapsar. Ayrıntılar için ağ sayfasına bakın; önemsemeniz gereken sebep tam olarak bu bölümdür: ters DNS ayarlamak için sizi ticket açmaya zorlayan bir host, her yeniden kurulumda sizi ticket açmaya zorlayacak bir host'tur.

SPF, DKIM ve DMARC: her biri neyi kanıtlar, hizalama ne anlama gelir?

Bu üçü DNS kaydı olarak yayınlanır, kurulumları bir saat sürer ve neredeyse her yerde kötü anlatılırlar — genellikle üç farklı iddia yerine birbirinin yerine geçebilen üç spam muskası gibi sunulurlar. SPF (RFC 7208), belirli bir zarf göndericisini taşıyan maili hangi adreslerin gönderebileceğini söyler. DKIM (RFC 6376), başlıklar ve gövde üzerine kriptografik bir imza ekler; böylece mesaj hangi alan adının ondan sorumlu olduğunu kanıtlayabilir. İkisi de alıcınızın gerçekte gördüğü adres hakkında hiçbir şey söylemez.

Bunu yapan DMARC'tır (RFC 7489) ve önemli olan kelimenin hizalama olmasının nedeni de budur. DMARC, SPF veya DKIM geçtiğinde ve doğrulanan alan adı görünür From: başlığındaki alan adıyla eşleştiğinde geçer. Klasik hata tam olarak burada yaşanır: mailiniz SPF'yi geçer çünkü sekme (bounce) adresi gönderen host'un kontrol ettiği bir alan adındadır, ama bu alan adı From:'takiyle aynı değildir, dolayısıyla hizalanmaz; dayanacak bir DKIM imzası da olmadığından, günlüklerde kusursuzca doğrulanmış görünen bir mesajda DMARC başarısız olur. Diğer klasik hata ise tek bir rapor bile okunmadan ilk günden p=reject yayınlamak ve bir ay sonra faturalandırma sisteminin bütün bu süre boyunca sessizce reddedildiğini keşfetmektir. p=none'dan bir rua adresiyle başlayın, gelenleri okuyun, sonra sıkılaştırın.

Göründüklerinden daha değerli iki operasyonel not. SPF kaydını on DNS sorgusunun içinde tutun — her include: bir sorguya mal olur ve üç SaaS sağlayıcısını iç içe geçirmek limiti aşarak geçici bir hata yerine kalıcı bir hataya dönüşür. Ve DKIM selector'larını hiç döndürmemek yerine ara sıra döndürün: bir selector eklemek ucuzdur ve önceden yayınlanmış ikinci bir selector'ın olması, beş dakikalık bir anahtar rotasyonuyla bir kesinti arasındaki farktır.

2024'te Değişen Taban, 2025'te Bir Kez Daha Değişti

Yirmi yıl boyunca mail göndermenin taban çizgisi kabaca "bir PTR'ın olsun ve Spamhaus'ta olma" idi. Bu, Google ve Yahoo'nun neredeyse birebir aynı gönderici gereksinimlerini yayınlayıp uygulamaya başladığı Şubat 2024'te değişti. Artık her gönderici — günde dört mesaj gönderen siz dahil — geçerli, ileri doğrulamalı bir PTR kaydına, bağlantıda TLS'e ve en azından SPF ya da DKIM'den birine ihtiyaç duyar. Tek bir alıcıya günde kabaca beş binin üzerinde mesaj gönderenlerin ise SPF ve DKIM ve bir DMARC kaydına, RFC 8058'e uygun çalışan bir tek tıkla abonelikten çıkma başlığına ve 0.3%'ün altında tutulan bir spam şikayet oranına ihtiyacı vardır.

Microsoft, 5 Mayıs 2025'te Outlook.com, Hotmail ve Live için aynı şekilde bir kuralla bunu takip etti: bu tüketici kutularına günde beş binden fazla mesaj gönderen alan adlarının SPF, DKIM ve DMARC'a sahip olması gerekir; kurallara uymayan mailler önce spam klasörüne yönlendirilir, sonrasında ise doğrudan reddedilir. Herhangi bir şey göndermeden önce Microsoft'un gönderici desteği ile Yahoo'nun en iyi uygulamalar sayfasını okumak için on dakika ayırmaya değer.

Kişisel ya da küçük ekip sunucuları için pratik sonuç, eşiklerin sizi yakalaması değildir — yakalamayacaktır — ama kimlik doğrulaması olmayan taban çizgisinin artık gerçekten anormal görünmesidir. Geçmişi olmayan bir adresten gelen, DMARC kaydı olmayan mail eskiden sıradandı. 2026'da ise filtrelerin durdurmak için tasarlandığı her şeyin profiline benziyor. Toplu gönderici olmasanız bile öyleymiş gibi yapılandırın, çünkü maliyeti bir öğleden sonra ve alternatifi ait olmadığınız bir kitleye göre puanlanmaktır.

Kimsenin görmediği bir adresi ısındırmak

Yeni bir adres nötr değil, daha çok bilinmeyen olarak başlar ve bilinmeyen, ne kadar gönderdiğinizle orantılı bir şüpheyle karşılanır. İşe yarayan yol sıkıcıdır: gerçekten açıp yanıt verecek kişilerle gerçek yazışmalarla başlayın, günlük hacmi kabaca sabit tutup basamaklar halinde değil kademeli olarak büyütün ve satın aldığınız ya da bir yerden dışa aktardığınız bir listeyi asla yeni bir adrese yöneltmeyin. Bilinmeyeni güvenilire çeviren sinyal etkileşimdir ve bunu üretecek hiçbir kestirme yol yoktur.

Kendi gelen kutunuza bakarak değil, alıcıların size verdiği araçlarla ölçün. Google'ın Postmaster Tools'u, alan adını doğruladıktan sonra alan adı ve IP itibarını, spam şikayet oranlarını ve kimlik doğrulama geçiş oranlarını gösterir — ama herhangi bir şeyi toplayabilecek kadar mail gönderene kadar boş kalır, ki kişisel bir sunucu için bu asla anlamına gelebilir ve bu sorun değildir. Microsoft'un SNDS'i Outlook.com için aynı işi yapar ve şikayetleri doğrudan size ileten Junk Mail Reporting Program ile eşleşir. Tek seferlik bir puanlama servisi, bozuk bir kaydı on saniyede yakalamak için yararlıdır, başka hiçbir şey için değil — itibar hakkında hiçbir şey söylemez, çünkü onun da sizinle bir geçmişi yoktur.

En zorlu alıcı hakkında beklentilerinizi dürüstçe belirleyin. Yeni bir adresin en uzun süre zorlandığı yer Outlook.com'dur: Gmail bunu ilk mesajdan itibaren kabul ederken, kusursuz kimlik doğrulamaya sahip doğru yapılandırılmış bir sunucunun orada haftalarca spam klasörüne düşmesi yaygındır. Çözüm başka bir DNS kaydı değil; zaman, tutarlılık ve mesajı spam klasöründen çıkaran alıcılardır. Outlook.com'da ilk günden itibaren teslim edilebilirlik bir tercih değil de bir iş gerekliliğiyse, bu, kendi barındırdığınız bir gönderici yerine bir relay istediğinizin işaretlerinden biridir — ki bu da son bölümün konusudur.

Ne çalıştırmalı ve ne kadar makine gerekir?

Neredeyse herkesi kapsayan dört seçenek var. Postfix'in IMAP için Dovecot ve filtreleme için rspamd ile eşleştirilmesi referans kurulumdur: üç daemon, düz metin yapılandırma ve göreceğiniz her hata mesajının bir yerlerde zaten yanıtlanmış olması. OpenSMTPD, tek oturuşta okuyabileceğiniz bir yapılandırma dosyasıyla aynı işi yapar; bu, sabahın üçünde kulağa geldiğinden çok daha değerlidir. Stalwart, SMTP, IMAP ve JMAP konuşan, filtrelemesi dahili tek bir binary'dir ve bugün sıfırdan başlamak için en keyifli seçenektir. Mailcow ya da Mail-in-a-Box ise, seçmediğiniz ve kolayca parçalarına ayıramayacağınız bir yığın bedeline, webmail dahil her şeyi sizin için bir araya getirir.

Boyutlandırma, posta kutularından çok önüne ne eklediğinizle ilgilidir. SMTP ve IMAP'in kendisi ucuzdur; birkaç düzine posta kutusu modern herhangi bir makinede yuvarlama hatası mertebesindedir. Bellek filtrelemeye gider. rspamd mütevazıdır, haritaları yüklüyken birkaç yüz megabayt tutar. ClamAV öyle değildir: yalnızca imza veritabanı onu bir gigabaytın epey üzerine iter ve küçük bir örneği swap yapmaya başlatması en muhtemel tek bileşendir — bir mail sunucusunda bu, kuyruğun tıkandığı ve teslimatın alıcıların sizi ertelemeye başlayacağı noktaya kadar yavaşladığı anlamına gelir. RAM'iniz varsa çalıştırın, yoksa atlayın ve yükü rspamd'e taşıtın.

Gerçek planlara uyarlarsak: 2 vCPU, 4 GB RAM ve 60 GB NVMe'li $8.50'lık Starter, ClamAV'ı dışarıda bıraktığınız sürece kişisel bir alan adı için Postfix, Dovecot ve rspamd'i rahatça çalıştırır. 4 vCPU, 8 GB ve 120 GB'lı $13.50'lık Growth ise artık düşünmeyi bıraktığınız boyuttur — tam filtrelemeyle yirmi ila otuz posta kutusu, yıllarca büyüyecek bir mail deposu için bolca alan. Aslında önce tükenen eksen depolamadır, çünkü mail, onu bir kez bile alan herkes tarafından sonsuza dek saklanır.

Doğru sırayla ayağa kaldırmak

1. Alan adını yönlendirin ve sunucuyu kurun. Sunucunun kendini tanıtacağı ana bilgisayar adına karar verin — geleneksel kullanım mail.example.com'dur — A kaydını yayınlayın, yalnızca IPv6 üzerinden göndermeyi düşünüyorsanız AAAA ekleyin ve alan adının MX kaydını o ada işaret edecek şekilde yayınlayın. Yazıştığınız kişilere en yakın lokasyonu seçin; BitVPS'te sunucu, ödeme onaylandıktan yaklaşık altmış saniye sonra, giden 25 zaten açık halde canlıya geçer.

2. Ters DNS'i buna uydurun. IPv4 adresinin PTR'ını — bir AAAA yayınladıysanız IPv6 adresininkini de — birinci adımdaki ana bilgisayar adıyla tam olarak eşleşecek şekilde ayarlayın. İleri ve geri yön birbiriyle uyuşmalıdır. Bu tek bir panel alanıdır ve tüm sürecin en değerli dakikasıdır.

3. Doğru portları her iki yönde de açın. Teslim için giden 25, almak için gelen 25, kendi kullanıcılarınızın gönderim yapması için 587 ve 465, IMAP için 993, geri kalan her şey kapalı. Giden 25'e izin verip gelene izin vermeyen bir güvenlik duvarı, hata ayıklamanın ilk saatinde tam olarak bir DNS sorunu gibi görünür ama değildir.

4. MTA'yı kurun ve ona gerçek bir kimlik verin. Postfix, OpenSMTPD ya da Stalwart; HELO adını birinci adımdaki ana bilgisayar adına ayarlayın; o ad için bir sertifikayla TLS'i etkinleştirin. Let's Encrypt ücretsizdir ve internetin çoğunun sunduğu da budur. Devam etmeden önce kendinize bir mesaj gönderin ve başlıkları okuyun — sonraki her adım bunun işe yaradığını varsayar.

5. SPF, DKIM ve DMARC yayınlayın. Gönderen adresi listeleyen ve test ederken ~all ile biten bir SPF kaydı. Selector'ı yayınlanmış ve imzalama etkinleştirilmiş, 2048-bit bir DKIM anahtarı. Raporların gelmeye başlaması için p=none'da bir rua adresiyle bir DMARC kaydı. Üç DNS kaydı, sıfır maliyet, en fazla bir saat.

6. Gelen kutusunu değil, kimlik doğrulama sonuçlarını okuyun. Gmail'e, Outlook.com'a ve bir kurumsal alıcıya gönderin, ardından her birinde Authentication-Results'ı açın. İstediğiniz şey spf=pass, dkim=pass, dmarc=pass ve hizalamanın görünür From:'taki alan adına karşı olmasıdır. Üç geçişle spam klasörüne düşmek bir itibar sorunudur; bir hatayla spam klasörüne düşmek bir yapılandırma sorunudur. İkisi tamamen farklı şekillerde düzeltilir ve bunları birbirine karıştırmak haftalarca zaman kaybettirir.

7. Raporlar temiz olduğunda sıkılaştırın. Hiçbir meşru kaynağın başarısız olmadığı bir iki haftalık DMARC raporunun ardından p=quarantine'a, sonra da p=reject'e geçin ve SPF'yi ~all'dan -all'a değiştirin. Raporları okumadan önce sıkılaştırmak, insanların bir ay boyunca fark etmeden kendi faturalarını engellemesinin yoludur.

8. Herkesin unuttuğu parçaları ekleyin. Diğer göndericilerin sizinle TLS'te ısrar etmesi gerektiğini bilmesi için MTA-STS ve TLS-RPT yayınlayın, bölgeniz imzalıysa DANE ekleyin, gelen kutusunun önüne rspamd koyun, mail deposunu bu makine olmayan bir yere yedekleyin ve durağan haldeyken şifreleyin — tam disk şifreleme anlatımı bunun neyi koruyup neyi korumadığını ele alıyor. Ardından giden kuyruğu izleyin: sessizce büyüyen bir kuyruk, bir itibar sorununun ilk belirtisidir ve eksik yanıtları fark etmenizden günler önce ortaya çıkar.

Kendi sunucunuzda barındırmanın yanlış araç olduğu durumlar

Kendi göndericinizi çalıştırmanın kötü bir alışveriş olduğu durumlar var ve bunlar hakkında net olmak, bir cesaretlendirme paragrafı daha eklemekten çok daha yararlıdır. Soğuk başlangıçlı toplu pazarlama bunun en bariz örneğidir: geçmişi olmayan yeni bir adresten binlerce mesaj göndermek, filtrelerin yakalamak için var olduğu tam da o imzadır ve hiçbir yapılandırma bunu kurtaramaz. Kaybolan bir mesajın paraya mal olduğu işlemsel mail — şifre sıfırlama, sipariş onayları, iki faktörlü kodlar — köklü bir itibara sahip altyapıya aittir, çünkü yeni bir adresin kendini kanıtlamak için harcadığı iki hafta, iki haftalık destek ticket'ı demektir. Ve pazar günü mail kuyruğuna bakacak birinin olmadığı herhangi bir ekip, giden trafiğinin cumadan beri ertelendiğini sonradan keşfedecek bir ekiptir.

Çoğu yazıda atlanan bir anonimlik alışverişi de var. Bir mail sunucusu, çalıştırabileceğiniz en az anonim şeydir. Bir alan adı, sabit bir adres, o alan adını taşıyan bir PTR kaydı, bunları birbirine bağlayan bir MX kaydı yayınlar ve her alıcıya yolu tarif eden eksiksiz bir başlık kümesi verir. Anonimlik ile herkese açık bir MX zıt yönlere çeker; buraya gelme sebebiniz kontrol değil de gizlilikse, inşa etmeden önce kripto hosting'in gerçekte ne kadar izlenebilir olduğunu okuyun. Kendi sunucunuzda barındırmak, gerçekten de saklanan mailinizden ve onun meta verisinden üçüncü bir tarafı kaldırır, ki bu gerçek ve değerli bir kazançtır — ama mailin kendisini anonim yapmaz ve yapamaz da, çünkü her yazışmanın yarısı başka birinin posta kutusunda yaşar.

Çoğu insan için işe yarayan düzenleme bir ayrımdır. Mutlaka ulaşması gereken maili itibarlı bir sağlayıcıda tutun, üçüncü taraf altyapısının dışında tutmak istediğiniz yazışmalar için ikinci bir alan adını kendi sunucunuzda barındırın ve her birine iyi olduğu yükü taşıtın. Bu bir ekstra DNS bölgesine mal olur, hiçbir sistemin kötü olduğu bir işi yapmadığı anlamına gelir ve BitVPS'te mail sunucusu çalıştıran insanların büyük bir kısmının fiilen yaptığı şey de budur. Ne gönderirseniz gönderin, yalnızca opt-in olsun — satın alınmış listeler kabul edilebilir kullanım politikamızın dışındadır ve size teslim ettiğimizde temiz olan bir adresi yakmanın en hızlı yoludur.