Sadece E‑Posta İçin Hosting Mimarisi: Web Sitesi Olmadan Kurumsal Mail Kurmak

Sadece E‑Posta İçin Hosting Neden Gündeme Geliyor?

Pek çok işletme için ilk ihtiyaç bir web sitesi değil, güvenilir bir kurumsal e‑posta altyapısı oluyor. Özellikle yeni kurulan şirketler, saha ekipleri ağır basan işletmeler, danışmanlık ofisleri veya sadece pazaryerlerinde satış yapan e‑ticaret girişimleri; henüz web sitesine bütçe ayırmadan, kendi alan adlarıyla profesyonel e‑posta kullanmak istiyor. Kartvizitte [email protected] yazsın, ama www.marka.com henüz yayında olmasın; bu oldukça yaygın bir senaryo.

Burada kritik soru şu: Web sitesi olmadan sadece e‑posta için nasıl bir hosting ve DNS mimarisi kurmalıyım? Hangi DNS kayıtları zorunlu, hangileri isteğe bağlı ama önemli? SPF, DKIM, DMARC, MTA‑STS ve benzeri güvenlik standartlarını web sitesi olmadan da devreye alabilir miyim? Ve tüm bunları yaparken, e‑postalarımın spam klasörüne düşmesini nasıl önlerim?

Bu yazıda DCHost ekibi olarak, sadece e‑posta için temiz, sürdürülebilir ve güvenli bir mimariyi adım adım anlatacağız. Alan adınızı yeni aldıysanız ve bu alan adında yalnızca e‑posta barındırmak istiyorsanız, aşağıdaki rehberi uygulayarak hem doğru DNS tasarımını kurabilir, hem de gelecekte web sitesi eklemek istediğinizde sorunsuzca genişleyebilecek bir altyapıya sahip olabilirsiniz.

Sadece E‑Posta İçin Hosting Seçenekleri

Önce büyük resmi netleştirelim. Sadece e‑posta için üç ana mimari yaklaşım var. Hangisini seçerseniz seçin, temel prensip aynı: Alan adınızın DNS kayıtları, e‑posta trafiğini doğru sunucuya yönlendirecek; siz de kullanıcı hesaplarını orada yöneteceksiniz.

1) Paylaşımlı E‑Posta Hosting (Web Sitesiz Kullanım)

En pratik yaklaşım, paylaşımlı bir hosting paketini yalnızca e‑posta için kullanmak. Web dizinine hiçbir site yüklemeden, sadece mail servislerini aktif tutabilirsiniz. Bu senaryoda:

• Alan adınızın MX kayıtları, DCHost mail sunucularına yönelir.
• cPanel veya benzeri panel üzerinden e‑posta hesaplarınızı ([email protected]) açarsınız.
• IMAP/POP3 ve SMTP erişimi hazır gelir, siz sadece DNS ayarlarını doğru yapmakla uğraşırsınız.

Özellikle 5‑20 kullanıcı arasında, basit bir mimariyle yola çıkmak isteyen işletmeler için bu model idealdir. Web sitesi ihtiyacı oluştuğunda, aynı hesap üzerinde WordPress veya farklı bir uygulama kurabilir; DNS tarafında büyük değişiklik yapmanıza gerek kalmadan yolunuza devam edersiniz. Bu yaklaşımın artısı, yönetimin kolay olması ve e‑posta + web sitesi için tek panel kullanmanızdır.

2) DCHost VPS/Dedicated Üzerinde Kendi Mail Sunucunuzu Kurmak

Daha ileri düzey kontrol isteyen, yüksek hacimli e‑posta trafiği olan veya sektör gereği log/tutma politikalarını sıkı uygulaması gereken firmalar için ikinci yol; DCHost üzerinde bir VPS ya da dedicated sunucu kiralayıp kendi mail sunucusunu yönetmektir. Bu senaryoda:

• Postfix/Exim + Dovecot gibi bileşenlerle kendi MTA ve IMAP/POP3 sunucunuzu kurarsınız.
• IP ısınması, RBL takibi, greylisting, spam filtresi gibi konularda tam yetki sizde olur.
• Yetkili olduğunuz sektörel veya kurumsal gereksinimlere göre log saklama, arşivleme, yedekleme politikalarınızı istediğiniz gibi tasarlarsınız.

Bu mimariyi teknik ekibi olan, 30‑40+ kullanıcıya sahip kurumlarda sık görüyoruz. Eğer bu yolu düşünüyorsanız, DCHost blogdaki VPS’te e‑posta sunucusu kurulumuna dair detaylı rehber size iyi bir teknik temel sağlayacaktır.

3) Harici Kurumsal E‑Posta Servisi + DCHost DNS

Üçüncü seçenek, e‑postayı tamamen harici bir kurumsal servis sağlayıcıda barındırıp, alan adının DNS yönetimini DCHost üzerinde tutmak. Bu durumda:

• MX kayıtlarınızı harici servisin size verdiği adreslere yönlendirirsiniz.
• SPF, DKIM, DMARC gibi TXT kayıtları yine DCHost DNS üzerinde tutulur.
• İleride farklı bir servise geçmek istediğinizde tek yapmanız gereken DNS kayıtlarını güncellemektir.

Bu yaklaşım, DNS tarafında esneklik kazandırır. DCHost üzerinde Premium DNS veya barındırma hesabı ile tüm DNS kayıtlarınızı tek noktadan yönetebilir, mail sağlayıcınızı değiştirdiğinizde alan adını taşımak zorunda kalmazsınız. E‑posta hosting modellerini karşılaştırırken daha geniş çerçeve görmek isterseniz, e‑posta hosting seçimi rehberimize de göz atabilirsiniz.

Web Sitesi Olmadan DNS Tasarımı Nasıl Yapılır?

Sadece e‑posta kullanmak istediğinizde en çok karıştırılan nokta şu: Web sitem yoksa alan adımın A kaydı olmak zorunda mı? Teknik olarak hayır, ama pratikte çoğu senaryoda küçük bir A kaydı tanımlamak işinizi kolaylaştırır.

En sık kullandığımız basit şablon şöyle:

• mail.alanadi.com için bir A (ve mümkünse AAAA) kaydı
• MX kaydı: alanadi.com → mail.alanadi.com
• SPF için bir TXT kaydı: v=spf1 mx ~all veya mimarinize göre güncellenmiş hali
• DKIM, DMARC, MTA‑STS gibi ek güvenlik kayıtları

Bu mimaride www.alanadi.com için hiçbir kayıt tanımlamak zorunda değilsiniz. Dilerseniz park sayfasına, ileride açacağınız siteye ya da şirketinizin LinkedIn/Instagram profilinize 301 yönlendirmesi yapan bir basit landing sayfası da barındırabilirsiniz; ama bu tamamen opsiyonel.

DNS türleri ve hangi kaydın ne işe yaradığını daha temelden okumak isterseniz, DCHost blogdaki DNS kayıtları A’dan Z’ye rehberi bu yazıyla çok iyi tamamlayıcı olacaktır.

Sadece E‑Posta İçin Zorunlu ve Önerilen DNS Kayıtları

Şimdi detaylara inelim. Web siteniz olmasa bile, kurumsal e‑posta altyapınız için mutlaka tanımlamanız gereken (ve tanımlamanız şiddetle önerilen) kayıtlar var.

1) MX Kaydı: E‑Postanın Gideceği Sunucuyu Belirlemek

MX (Mail Exchanger) kaydı, alan adınıza gelen e‑postaların hangi sunucuya teslim edileceğini söyler. Örnek bir kurulum:

• Ad: alanadi.com
• Tür: MX
• Değer: mail.alanadi.com
• Öncelik: 10

Burada dikkat etmeniz gereken iki nokta var:

• MX hedefi mutlaka bir hostname olmalı (mail.alanadi.com gibi), doğrudan IP yazılmaz.
• Bu hostname için bir A veya AAAA kaydı tanımlanmış olmalı, aksi halde gönderici sunucular IP adresini çözemeyecektir.

2) A/AAAA Kayıtları: Mail Sunucusunun IP’sini Tanımlamak

MX kaydınızın işaret ettiği mail.alanadi.com için IP kayıtlarını tanımlarsınız:

• mail.alanadi.com → A → 203.0.113.10 (IPv4)
• mail.alanadi.com → AAAA → 2001:db8::10 (IPv6, varsa)

Modern dünyada IPv6 kullanımı hızla arttığı için, eğer DCHost üzerinden IPv6 destekli bir VPS ya da hosting kullanıyorsanız, AAAA kaydı eklemeyi de tavsiye ediyoruz. IPv6 ile e‑posta gönderimi ve DNS tarafındaki gereksinimler için, blogdaki IPv6 ile e‑posta teslimi rehberimiz size daha da derin bir bakış sunabilir.

3) SPF Kaydı: Hangi Sunucun Adınıza Mail Gönderebileceğini İlan Etmek

SPF (Sender Policy Framework), alan adınız adına kimlerin e‑posta göndermeye yetkili olduğunu söyleyen bir TXT kaydıdır. En basit haliyle, yalnızca MX sunucularınızın mail göndermesine izin vermek için şu kaydı kullanabilirsiniz:

Ad: alanadi.com
Tür: TXT
Değer: v=spf1 mx ~all

Daha karmaşık yapılarda (farklı servislerden transactional e‑posta, pazarlama e‑postası, ticket sistemi vb.) SPF tasarımı hızla karışabilir. Üstelik 10 DNS lookup limiti gibi teknik sınırlar da vardır. SPF, DKIM ve DMARC’ı birlikte ele aldığımız özel alan adıyla e‑posta doğrulama rehberimizde hem temel, hem de gelişmiş senaryoları adım adım anlattık.

4) DKIM Kaydı: İçerik Bütünlüğünü Kriptografik Olarak İmzalamak

DKIM (DomainKeys Identified Mail), gönderdiğiniz e‑postaların içerik ve başlıklarının sizden çıktığını kriptografik imza ile kanıtlar. Teknik olarak:

• Mail sunucunuz (veya kullandığınız servis), her e‑postayı imzalar.
• Alıcı taraf, DNS’te yayınladığınız DKIM TXT kaydındaki açık anahtarı kullanarak imzayı doğrular.

DKIM kaydı, çoğu panelde otomatik üretilir. Siz sadece ilgili TXT kaydını DNS’e eklemiş olursunuz. Sadece e‑posta için hosting kullanıyorsanız bile, DKIM’i devreye almadan yola çıkmamanızı öneririz; spam filtreleri açısından büyük pozitif sinyaldir.

5) DMARC Kaydı: SPF ve DKIM Politikanızı İlan Etmek

DMARC, SPF ve DKIM sonuçlarına göre alıcı sunucuların nasıl davranmasını istediğinizi belirlediğiniz politikadır. Örnek bir başlangıç kaydı:

Ad: _dmarc.alanadi.com
Tür: TXT
Değer: v=DMARC1; p=none; rua=mailto:[email protected]

Burada:

• p=none ile henüz sert bir politika uygulamadan rapor toplarsınız.
• rua= ile toplu raporların geldiği e‑posta adresini belirlersiniz.

Zamanla DMARC uyumunuzu gördükçe politikayı quarantine ya da reject seviyesine çekebilirsiniz. DMARC’ın raporlama ve marka tarafındaki (örneğin BIMI) etkilerini daha derin okumak isterseniz, blogdaki SPF, DKIM, DMARC ve rDNS ile teslim edilebilirliği artırma rehberimiz iyi bir sonraki adımdır.

6) PTR (Reverse DNS) Kaydı: IP → Alan Adı Eşlemesi

PTR veya reverse DNS kaydı, IP adresinizden alan adınıza ters yönde çözüm yapılmasını sağlar. Birçok alıcı mail sunucusu, bağlantı kuran IP’nin reverse DNS’ini kontrol eder ve bunun SMTP oturumunda tanıtılan host adıyla tutarlı olmasını bekler.

DCHost üzerinde VPS veya dedicated sunucu kullanıyorsanız, support ekibimiz sizin için IP’lere uygun PTR kayıtlarını tanımlayabilir. Bu işlem çoğu zaman hosting panelinden değil, IP yönetim katmanından yapılır; dolayısıyla PTR’nin eksik olması, ama DNS tarafında her şeyin doğru görünmesi sık gördüğümüz bir tuzaktır. Bu konuyu ayrı ele aldığımız PTR ve e‑posta teslimi rehberine mutlaka göz atın.

7) MTA‑STS ve TLS‑RPT: Zorunlu Şifreleme Politikası

MTA‑STS, alan adınıza gelen e‑postaların mutlaka TLS üzerinden, belirlediğiniz host adı ve sertifika gereksinimleriyle teslim edilmesini talep etmenizi sağlar. TLS‑RPT ise bu politikaya uyulmayan veya hata yaşanan durumların raporlanmasını mümkün kılar.

Sadece e‑posta için hosting kullansanız bile, özellikle KVKK/GDPR hassasiyeti olan sektörlerde MTA‑STS ve TLS‑RPT’yi devreye almak, e‑posta güvenliğine ciddi seviye atlatır. Aşamaları, TXT ve policy dosyası örnekleriyle birlikte MTA‑STS, TLS‑RPT ve DANE/TLSA rehberimizde detaylı biçimde bulabilirsiniz.

Güvenlik ve Teslim Edilebilirlik Perspektifinden Mimari Tasarım

DNS kayıtlarını kurmak yalnızca başlangıç. E‑postanın gerçekten güvenli ve teslim edilebilirliği yüksek çalışması için birkaç mimari karara daha ihtiyaç var.

Paylaşımlı IP mi, Dedicated IP mi?

Sadece e‑posta için hosting kullanırken, genellikle paylaşımlı IP üzerinden çıkış yapılır. Bu, küçük ölçekli işletmeler için maliyet avantajı sağlar; ancak aynı IP’yi kullanan başka bir kullanıcının kötü gönderim yapması, IP itibarını olumsuz etkileyebilir. Buna karşın, DCHost üzerinde kendi VPS veya dedicated sunucunuzu kullanıp özel IP ile e‑posta göndermek:

• IP itibarını tamamen sizin kontrolünüze bırakır,
• IP ısıtma stratejisi uygulamanıza imkan tanır,
• Büyük sağlayıcılarla daha kestirilebilir sonuçlar üretir.

Dedicated IP ve ısıtma konusu, kendi başına derin bir alan. Bu nedenle ayrı bir yazıda dedicated IP ısıtma ve e‑posta itibarı yönetimini detaylı ele aldık. Sadece e‑posta için VPS kullanmayı düşünüyorsanız, bu rehberi oyun planınızın parçası yapmanızda fayda var.

Güçlü Kimlik Doğrulama ve Erişim Kontrolleri

Kullanıcı tarafında atlanmaması gereken noktalar:

• Tüm posta kutuları için uzun ve karmaşık şifreler zorunlu olmalı.
• IMAP/SMTP bağlantıları mutlaka STARTTLS/SMTPS ile şifrelenmiş şekilde yapılandırılmalı.
• Mümkünse webmail/panel erişiminde iki faktörlü kimlik doğrulama (2FA) aktif edilmeli.
• IP bazlı kısıtlama, rate limiting, bruteforce koruması gibi güvenlik önlemleri sunucu tarafında açık olmalı.

DCHost ortamlarında, özellikle VPS ve dedicated sunucularda fail2ban, firewall, sshd_config sertleştirme gibi ek katmanları da devreye almanızı öneriyoruz. Bu konuları daha geniş çerçevede ele aldığımız VPS sunucu güvenliği rehberimiz, e‑posta sunucusu kurarken de birebir uygulanabilir prensipler içeriyor.

Teslim Edilebilirliği İzlemek ve İyileştirmek

Teknik kayıtlar doğru olsa bile, gerçek dünyada teslim edilebilirlik; içerik kalitesi, gönderim hacmi, bounce oranları ve kullanıcı etkileşimi gibi pek çok faktöre bağlı. Mimari açıdan şunları öneriyoruz:

• Yeni alan adında agresif kampanya gönderimi yerine, hacmi kademeli artırarak IP/alan adı ısındırın.
• Bounce’ları (geri dönen e‑postalar) aktif izleyin, geçersiz adresleri hızlıca listelerinizden çıkarın.
• DMARC ve TLS‑RPT raporlarını düzenli okuyun, yanlış yapılandırılmış kaynakları tespit edin.
• Sistemin ürettiği SMTP hata kodları ve bounce mesajlarını anlamlandırmak için, DCHost blogdaki SMTP hata kodları ve bounce mesajları rehberinden yararlanın.

Yedeklilik: Bir Sunucuya Bağımlı Kalmayan E‑Posta Altyapısı

Sadece e‑posta için hosting kullanıyorsanız, sistemin tek bir noktaya bağlı kalması risklidir. Donanım arızası, ağ problemi veya yanlış bir güvenlik kuralı, tüm şirketin mail trafiğini etkileyebilir. Bunu azaltmak için:

• Birden fazla MX kaydı tanımlayıp backup MX senaryosu kurabilir,
• Birincil sunucu erişilemez olduğunda devreye girecek ikincil bir MTA planlayabilir,
• Büyük kurumlarda split delivery ile bazı kutuları lokal sunucuda, bazılarını harici serviste tutabilirsiniz.

Bu senaryoları adım adım anlattığımız e‑posta altyapısında yedeklilik rehberi, özellikle SLA beklentisi yüksek kurumlarda mutlaka incelenmesi gereken bir kaynak. DCHost üzerinde iki farklı lokasyonda VPS kullanarak aktif/pasif veya aktif/aktif e‑posta mimarileri tasarlamak mümkün.

Yalnızca E‑Posta İçin Örnek Mimariler

Teoriyi somutlaştırmak için üç tipik senaryoyu özetleyelim.

Senaryo 1: 10 Kişilik Muhasebe Bürosu – Paylaşımlı E‑Posta Hosting

Bu senaryoda hedef; düşük maliyet, basit yönetim ve temel güvenlik. Mimari:

• DCHost üzerinde küçük bir paylaşımlı hosting paketi açılır.
• Alan adının nameserver kayıtları DCHost’a yönlendirilir.
• DNS’te yalnızca şu kayıtlar bulunur: MX, mail.alanadi.com için A, SPF, DKIM, DMARC.
• Kullanıcılar IMAP üzerinden bağlanır, webmail yedek erişim olarak kullanılır.

Web sitesi henüz yoktur, ama ileride WordPress kurulmak istendiğinde aynı pakette bir klasör daha açmak yeterlidir. Bu, sadece e‑posta ile başlayıp büyümeye açık tipik bir ofis yapısıdır.

Senaryo 2: 70 Kişilik Dağıtık Ekip – DCHost VPS Üzerinde Kendi MTA

Burada ihtiyaçlar biraz daha karmaşık: Farklı lokasyonlarda çalışan ekipler, yüksek sayıda günlük e‑posta, detaylı loglama ve arşiv zorunluluğu. Mimari şöyle şekillenir:

• DCHost’ta NVMe diskli, orta seviyede vCPU/RAM’e sahip bir VPS kiralanır.
• Postfix + Dovecot + rspamd gibi bileşenlerle güçlü bir mail stack kurulur.
• Harici bir object storage veya ikinci VPS üzerinde IMAP yedekleri ve günlük snapshot’lar tutulur.
• DMARC ve MTA‑STS raporları düzenli olarak analiz edilir.

Bu yapıda, sadece e‑posta için dahi olsa, gelişmiş monitoring ve alerting (disk doluluğu, queue uzunluğu, outbound hata oranı vb.) kurulmasını kesinlikle öneriyoruz. DCHost blogda VPS izleme ve alarm kurulumunu Prometheus ve Grafana ile anlattığımız yazı, burada doğrudan uygulanabilir.

Senaryo 3: Ajans – Onlarca Müşteri Alan Adı için Merkezi Mail ve DNS

Ajans tarafında sık gördüğümüz diğer bir model; onlarca küçük müşterinin sadece e‑posta altyapısını yönetmek. Örneğin:

• DCHost üzerinde güçlü bir VPS veya birkaç VPS ile multi‑tenant mail sunucusu kurulur.
• Her müşteri alan adı için MX, SPF, DKIM, DMARC kayıtları ajansın yönettiği DNS üzerinde tutulur.
• Ajans, müşterilere kullanıcı hesabı ve kota açar; web sitesi başka sağlayıcıda olsa bile e‑posta tek merkezden yönetilir.

Bu yaklaşımla tek panelden onlarca müşteri e‑postası yönetilebilir. Ayrıntılı tasarım, yetki sınırları ve güvenlik tarafını, ajanslara özel hazırladığımız multi‑tenant e‑posta ve DNS mimarisi rehberinde bulabilirsiniz.

Yedekleme, Arşiv ve Log Yönetimi

Sadece e‑posta için hosting kullandığınızda, sistemdeki tek kritik veri çoğu zaman e‑posta kutularının içeriği oluyor. Bu yüzden yedekleme ve arşiv konusunu hafife almamak gerekiyor.

• IMAP tabanlı erişim son kullanıcıların mailleri sunucuda tutmasını sağlar; bu da merkezi yedeklemeyi kolaylaştırır.
• cPanel veya VPS tarafında günlük/haftalık tam yedek ve artımlı yedek politikaları belirlenmeli.
• Uzun süre saklanması gereken e‑postalar için arşiv sunucusu veya journaling mimarisi değerlendirilmeli.
• KVKK/GDPR bağlamında, log saklama süreleri ve silme politikaları yazılı hale getirilmeli.

DCHost olarak, e‑posta arşivleme ve yasal saklama politikalarını hem cPanel hem de VPS tarafında nasıl kurabileceğinizi (journaling, harici depolama, saklama süreleri) ayrı rehberlerde adım adım ele aldık. Sadece e‑posta kullanan yapılar için bu rehberleri operasyonel prosedürlerinizle birleştirmenizi tavsiye ederiz.

DCHost ile Sadece E‑Posta Altyapısını Adım Adım Kurmak

Toparlayalım. DCHost üzerinde sadece e‑posta için temiz bir mimari kurmak istiyorsanız tipik yol haritası şu şekilde:

1. Alan adınızı kaydedin veya mevcut alan adınızı kullanmaya karar verin.
2. İhtiyacınıza göre paylaşımlı e‑posta hosting ya da VPS/dedicated seçin.
3. Alan adınızın nameserver kayıtlarını DCHost DNS’e yönlendirin.
4. Panelden gerekli MX, A/AAAA, SPF, DKIM, DMARC kayıtlarını oluşturun.
5. Gerekirse PTR (reverse DNS) için destek talebi açın.
6. MTA‑STS/TLS‑RPT gibi gelişmiş güvenlik özelliklerini planlayın.
7. Kullanıcı Posta kutularını oluşturup, IMAP/SMTP ayarlarını müşterilere/çalışanlara dokümante edin.
8. Yedekleme, log saklama ve arşiv politikalarınızı yazılı hale getirin ve periyodik test edin.

Bu adımların birçoğunu, kendi alan adınızla kurumsal e‑posta kurma rehberimizde görsel ekran alıntılarıyla da anlattık. Bu yazı ise daha çok mimari ve güvenlik perspektifini tamamlıyor.

Sonuç: Web Sitesi Olmadan da Kurumsal E‑Posta Mümkün, Önemli Olan Mimari

Web siteniz henüz hazır olmasa bile, alan adınızla profesyonel e‑posta kullanmanızın önünde hiçbir teknik engel yok. Kritik olan, DNS kayıtlarını doğru tasarlamak, SPF/DKIM/DMARC üçlüsünü eksiksiz kurmak ve PTR, MTA‑STS, TLS‑RPT gibi detayları göz ardı etmemek. Sadece e‑posta için tercih edeceğiniz hosting mimarisi; şirketinizin büyüklüğü, teknik ekibinizin yetkinliği ve regülasyon gereksinimlerinizle birebir bağlantılı.

DCHost olarak, ister paylaşımlı bir e‑posta altyapısıyla küçük ölçekli başlayın, ister kendi VPS’iniz üzerinde kurumsal seviyede bir mail sunucusu inşa edin; DNS tasarımı, güvenlik ve teslim edilebilirlik tarafında yanınızdayız. Mevcut senaryonuzu birlikte gözden geçirip; hangi kayıtların eksik, hangi güvenlik katmanlarının devreye alınması gerektiğini netleştirmek isterseniz, destek ekibimize birkaç örnek e‑posta başlığı ve hata mesajıyla ulaşmanız yeterli.

Bir sonraki adımda, alan adınız ve DNS altyapınızın tamamını masaya yatırmak isterseniz, DNS TTL değerlerini stratejik olarak ayarladığımız rehberimiz de yol gösterici olacaktır. Böylece yalnızca bugün için değil, yarın web sitenizi yayına aldığınızda da sorun yaşamayacağınız, sürdürülebilir bir e‑posta odaklı hosting mimarisi kurmuş olursunuz.