Alan adı, hosting ve kurumsal e-posta: sahiplik, kurulum ve teslim edilebilirlik

Yıllar önce sitenizi yapan firmayla yollarınız ayrıldı. Yeni ekip alan adının paneline girmek istiyor; kimse şifreyi bilmiyor, kayıt bilgilerinde eski ajansın adı yazıyor ve yenileme uyarıları üç yıl önce ayrılmış bir çalışanın posta kutusuna gidiyor. Bu tablo sandığınızdan yaygındır ve genellikle en kötü anda, alan adının süresi dolduğu ya da e-postaların durduğu gün fark edilir.

Bu yazıda alan adı, barındırma (hosting) ve kurumsal e-postayı tek bir altyapı olarak ele alıyoruz: hangisi kimin adına olmalı, nerede yönetilmeli, hosting türleri arasında nasıl seçim yapılır ve e-postalarınız neden spama düşer. Hedef basit: ekip, ajans ya da çalışan değişse bile anahtarlar şirketin elinde kalsın.

Alan adı kimin malı: kayıt sahibi ve hesap ayrı şeyler

Alan adında iki ayrı sahiplik katmanı vardır. Birincisi kayıt sahibidir (registrant): kayıt kuruluşunun ve uzantıyı yöneten otoritenin kayıtlarında hak sahibi olarak görünen kişi ya da kurum. İkincisi alan adını yöneten hesaptır, yani şifreyi, transfer kodunu ve yenileme düğmesini elinde tutan kullanıcı.

İkisi de şirketinize ait olmalı. Kayıt sahibi olarak ajansın ya da bir çalışanın adı yazıyorsa, marka adınız kâğıt üzerinde başkasına aittir. Hesap bir ajansın panelindeyse her DNS değişikliği için ona muhtaç kalırsınız; dostane bir ayrılık bile haftalar süren yazışma demektir.

Ajansların alan adlarını kendi hesaplarında toplaması çoğu zaman kolaylık içindir. Kabul edebilirsiniz; yeter ki kayıt sahibi şirketiniz olsun ve alan adını istediğiniz an alabileceğiniz sözleşmede yazsın.

• Kayıt sahibi alanına şirketin ticaret unvanını yazın; şahıs işletmesiyseniz işletme sahibinin adını.
• Kayıt kuruluşu hesabını kişisel bir adresle değil, şirketin bir rol adresiyle açın (ör. alanadi@ ya da bt@).
• İki adımlı doğrulamayı açın ve en az iki yetkilinin erişimi olsun.
• Faturayı şirket kartına bağlayın; bir çalışanın kişisel kartı, o kişi ayrıldığı gün devreden çıkar.

Kayıt kuruluşu ile DNS yönetimi aynı yer değil

Alan adını satın aldığınız firma (kayıt kuruluşu, registrar) ile DNS kayıtlarının yönetildiği yer çoğu zaman aynıdır, ama olmak zorunda değildir. Alan adı bir kayıt kuruluşunda, ad sunucuları (nameserver) Cloudflare'de, site bir hosting firmasında, e-posta Google'da olabilir. Dört yer, dört hesap, dört ayrı risk.

DNS, alan adınızın adres defteridir. A ve AAAA kayıtları sitenin hangi sunucuda durduğunu, MX kayıtları e-postanın nereye teslim edileceğini, TXT kayıtları SPF, DKIM, DMARC ve hizmet doğrulamalarını söyler. Hangi kaydın neden orada olduğunu bilmeyen biri, tek bir değişiklikle hem siteyi hem e-postayı durdurabilir.

En sık kaza: yeni hosting firması ad sunucularını kendine yönlendirtir ve yeni DNS bölgesinde yalnızca sitenin kaydı vardır. MX ve DKIM kayıtları eski bölgede kaldığı için e-posta gelmez olur. Giden e-postalar çalıştığı için kimse fark etmez; müşteriler cevap alamadığını iki gün sonra telefonla söyler.

• Ad sunucusu değiştirmeden önce mevcut DNS bölgesinin tam dökümünü (zone file) alın ve arşivleyin.
• Taşımadan bir iki gün önce kritik kayıtların TTL değerini düşürün; değişiklik daha çabuk yayılır.
• Her TXT kaydının hangi hizmete ait olduğunu not edin, kullanılmayan hizmetin kaydını silin.
• Taşımadan sonra siteyi, gelen ve giden e-postayı ayrı ayrı test edin.

Yenileme, transfer kilidi ve .com.tr kuralları

Yenilemeyi şansa bırakmayın

Alan adı bir kez alınıp unutulan bir mülk değil, süreli bir tahsistir. Otomatik yenilemeyi açın, kartın son kullanma tarihini takvime yazın, ana alan adını mümkünse birkaç yıllığına yenileyin. Yenileme uyarıları hesabın e-posta adresine gider; o adres yanlışsa uyarı da boşa gider.

Süresi dolan alan adı çoğu uzantıda hemen silinmez; önce bir ek süre, ardından daha maliyetli bir kurtarma dönemi gelir ve süreler uzantıya göre değişir. Serbest kalan değerli alan adlarını anında yakalayan otomatik sistemler de vardır; adresi kaptırmamak, geri almaya çalışmaktan her zaman kolaydır.

Transfer kilidi ve yetki kodu

.com ve çoğu genel uzantıda kayıt kuruluşu alan adına bir transfer kilidi koyar (registrar lock; teknik kayıtlarda clientTransferProhibited olarak görünür). Kilit etkinken alan adı başka bir kayıt kuruluşuna taşınamaz. Taşımak için kilidi kaldırır ve yetki kodunu (EPP ya da auth code) alırsınız. Bu kod panelde görünür ya da hesabın e-posta adresine gelir. Kısacası hesabın kontrolü, transferin kontrolüdür.

Kilidi her zaman etkin bırakın, yalnızca bilerek başlattığınız bir transferde kaldırın. İşinizin tamamı tek bir alan adına bağlıysa, bazı uzantılarda sunulan ve kritik değişiklikleri elle doğrulamaya bağlayan kayıt otoritesi kilidini (registry lock) kayıt kuruluşunuza sorun.

.com.tr ve TRABİS

.tr uzantılı alan adlarının yönetimi 14 Eylül 2022'de ODTÜ bünyesindeki nic.tr'den BTK bünyesindeki TRABİS'e geçti. Bu geçişle .com.tr, .net.tr ve .org.tr gibi uzantılar belgesiz hale geldi ve ilk gelen alır esasıyla tahsis ediliyor. Başvurular BTK'nın yetkilendirdiği kayıt kuruluşları üzerinden yapılıyor. .av.tr, .dr.tr, .gov.tr, .edu.tr, .k12.tr ve .bel.tr gibi uzantılar ise belge istemeye devam ediyor.

Yani eskiden belgesiz alınamayan firmaniz.com.tr adresini artık herkes alabilir. Markanızın .com ve .com.tr adreslerinin ikisi de sizde olsun, biri diğerine yönlensin. Başkası almışsa, BTK'nın yetkilendirdiği uyuşmazlık çözüm hizmet sağlayıcıları üzerinden mahkeme dışı bir başvuru yolu var; dosyanızı hukuk danışmanınızla birlikte değerlendirin.

Barındırma türleri: paylaşımlı, VPS, yönetilen ve bulut

Asıl soru, sitenizin ne iş yaptığı ve sunucuyu kimin yöneteceğidir; beş sayfalık bir kurumsal site ile günde binlerce sipariş alan bir mağazanın ihtiyacı aynı değildir.

Paylaşımlı hosting

Aynı sunucuyu yüzlerce siteyle paylaşırsınız; kaynaklar, IP adresi ve çoğu zaman e-posta itibarı ortaktır. Az trafikli bir tanıtım sitesi için yeterlidir. Sınırı, komşunuza bağlı olmanızdır: aynı sunucudaki bir site saldırıya uğradığında ya da spam gönderdiğinde siz de etkilenirsiniz.

VPS

Sanal bir sunucu size ayrılır; işlemci, bellek ve disk sizindir. Esneklik artar, ama güncellemeler, güvenlik duvarı ve yedekler de sizin işiniz olur. Yönetimsiz bir VPS'i kurup unutmak, yıllarca güncellenmemiş bir sunucuyla internete açık durmak demektir. Bunu düzenli yapacak biri yoksa VPS doğru seçim değildir.

Yönetilen hosting

Sağlayıcı bakımı, güncellemeleri, yedekleri ve çoğu zaman önbellekleme ile güvenlik taramasını üstlenir. WordPress gibi bir içerik yönetim sistemiyle çalışan, teknik ekibi olmayan işletmeler için çoğu zaman en dengeli seçenek budur. Karşılığında her sunucu ayarını istediğiniz gibi yapamazsınız.

Bulut

AWS, Google Cloud, Microsoft Azure ya da Vercel ve Netlify gibi platformlar kullandıkça ölçeklenir. Güçlüdür, ama ayar çoktur ve fatura kullanıma bağlıdır; kurulumu yapan kişi maliyet uyarılarını ve erişim yetkilerini de tanımlamalı.

Hangi türü seçerseniz seçin, şu soruların yanıtını teklif aşamasında yazılı alın:

• Veri merkezi nerede ve hedef kitlenize ne kadar yakın?
• Yedekleri kim, ne sıklıkla, nereye alıyor ve en son ne zaman geri yükleme denendi?
• Destek hangi dilde ve hangi saatlerde veriliyor; çalışma süresi taahhüdü (SLA) ihlal edilirse ne oluyor?
• Ayrılmak istediğinizde dosyalarınızı ve veritabanınızı hangi biçimde, ne kadar sürede alabiliyorsunuz?

SSL, CDN ve yedekleme: otomatik çalışsın, hesabı sizde olsun

SSL (doğrusu TLS) artık tartışma konusu değil; her sayfa HTTPS ile açılmalı. Asıl mesele yenileme. CA/Browser Forum'un 2025'te kabul ettiği kararla sertifikaların azami geçerlilik süresi kademeli olarak kısalıyor: 15 Mart 2026'dan bu yana en fazla 200 gün, 2029'da ise 47 gün. Sertifikayı yılda bir kez elle yenileyip takvime not ettiğiniz dönem kapandı; yenileme otomatik olmalı.

Let's Encrypt gibi sertifika yetkilileri ve çoğu hosting paneli bu otomasyonu ACME protokolüyle zaten yapıyor. Sizin kontrol edeceğiniz şey, otomasyonun gerçekten çalıştığı, hata olduğunda uyarının doğru kişiye gittiği ve www ile alt alan adlarının da kapsamda olduğudur.

CDN (içerik dağıtım ağı), sabit dosyaları ziyaretçiye yakın sunuculardan dağıtır ve kötü niyetli trafiğin bir kısmını sunucuya ulaşmadan durdurur; yurt dışına satan bir şirket için hız farkı hissedilir. Dikkat: Cloudflare gibi bir hizmete geçmek çoğu zaman ad sunucularını da taşımak demektir; DNS artık o hesaptadır ve hesap şirket envanterine girmelidir.

Yedeklemede tek kuralımız şu: hosting firmasının aldığı yedek, sizin yedeğiniz değildir. O yedek aynı altyapıda durur; hesap askıya alınırsa ya da firma kapanırsa onunla birlikte gider. Yaygın 3-2-1 yaklaşımı iyi bir başlangıçtır: üç kopya, iki farklı ortam, bir kopya başka bir yerde.

• Dosyaları ve veritabanını otomatik olarak, ayrı ayrı yedekleyin.
• En az bir kopyayı hosting firmasından bağımsız bir depolamada tutun.
• Yılda en az bir kez gerçek bir geri yükleme deneyin; hiç denenmemiş yedek bir varsayımdır.
• Kurumsal e-posta hizmetleri altyapıyı korur, ama kapatılan bir çalışan hesabını sonsuza kadar saklamaz; veri saklama ayarlarını bilerek yapın.

Kurumsal e-posta: Google Workspace mı, Microsoft 365 mi?

Hosting paketiyle gelen e-posta kutuları başlangıçta cazip görünür. Ama spam filtresi zayıftır, depolama sınırlıdır, gönderim itibarınız aynı sunucudaki diğer sitelere bağlıdır ve hosting firmasını değiştirdiğiniz gün e-postayı da taşımanız gerekir. Birkaç kişiden fazla çalışan her işletmeye e-postayı siteden ayırmasını öneriyoruz.

Google Workspace ile Microsoft 365 arasındaki seçim çoğu zaman teknik değil, alışkanlık meselesidir. Ekibiniz tarayıcıda çalışıyor, belgeleri ortak düzenliyor ve Gmail'i seviyorsa Workspace doğal seçimdir. Muhasebe masaüstü Excel'le çalışıyor, Teams ve Outlook günlük düzenin parçasıysa 365 daha az sürtünme yaratır. İkisi de güvenilir; yanlış seçim, ekibin kullanmayacağı aracı seçmektir.

Kurulumda atlanan adım sonradan pahalıya patlar. Asgari liste:

1. Alan adını sağlayıcıda TXT kaydıyla doğrulayın.
2. MX kayıtlarını sağlayıcının verdiği değerlerle değiştirin ve eski MX kayıtlarını kaldırın.
3. SPF kaydını tek bir kayıt olarak oluşturun ya da mevcut kayda ekleyin.
4. DKIM anahtarını üretip DNS'e ekleyin. Google Workspace'te bu, Yönetici konsolunda Uygulamalar, Google Workspace, Gmail altındaki E-postanın kimliğini doğrulama bölümünden yapılır; Google 2048 bitlik anahtar öneriyor.
5. DMARC kaydını izleme modunda (p=none) yayımlayın ve raporların geleceği bir adres belirleyin.
6. Çalışan ayrıldığında hesabı silmek yerine verisini devretme ve askıya alma adımlarını yazılı hale getirin.

SPF, DKIM, DMARC ve Gmail ile Yahoo'nun gönderici kuralları

Bu üç kayıt, e-postanın gerçekten sizden geldiğini kanıtlar. SPF, adınıza hangi sunucuların gönderebileceğini listeler. Bir alan adında tek bir SPF kaydı olabilir ve kayıt en fazla 10 DNS sorgusuna yol açabilir; her yeni hizmet için ikinci bir SPF kaydı eklemek en yaygın ve en sessiz hatadır. Google Workspace için tipik kayıt v=spf1 include:_spf.google.com ~all biçimindedir; Microsoft 365'te include değeri spf.protection.outlook.com olur.

DKIM, her e-postaya alan adınıza ait bir dijital imza ekler; e-posta gönderen her hizmetin (kurumsal e-posta, bülten aracı, fatura sistemi) kendi anahtarı olmalı. DMARC ikisinin üstünde durur: görünen gönderen alan adının SPF ya da DKIM'de doğrulanan alan adıyla eşleşmesini (hizalama) ister ve eşleşmeyen e-postayla ne yapılacağını söyler: izle (p=none), spama at (p=quarantine) ya da reddet (p=reject).

İzleme modunda başlayıp raporları birkaç hafta okuyun. Raporlar, adınıza e-posta gönderdiğini bilmediğiniz hizmetleri ortaya çıkarır: eski bir CRM, unutulmuş bir anket aracı, muhasebecinin fatura programı. Hepsi hizalanınca politikayı adım adım sıkılaştırırsınız.

Şubat 2024'ten bu yana geçerli kurallar

Gmail ve Yahoo, Şubat 2024'te gönderici kurallarını sıkılaştırdı. Gmail'in yönergelerine göre kişisel Gmail adreslerine gönderen herkes SPF ya da DKIM kullanmalı, geçerli ters DNS (PTR) kaydına sahip olmalı, TLS ile göndermeli ve spam şikâyet oranını yüzde 0,3'ün altında tutmalı. Günde 5.000 ve üzeri ileti gönderen toplu göndericiler için SPF, DKIM ve DMARC'ın üçü de zorunlu; DMARC p=none olabilir, ama gönderen alan adı SPF ya da DKIM ile hizalanmalı. Pazarlama e-postalarında tek tıkla abonelikten çıkma ve metinde görünür bir çıkış bağlantısı şart; Google çıkış taleplerinin iki gün içinde işlenmesini istiyor.

İki ayrıntı sık gözden kaçıyor. 5.000 sınırı ana alan adı ve alt alan adlarından gönderilenlerin toplamıyla hesaplanıyor ve bir kez toplu gönderici sayılan alan adı kalıcı olarak öyle kalıyor. Kural da kâğıt üzerinde kalmadı: Google, Kasım 2025'ten itibaren uyumsuz trafiği geçici ve kalıcı olarak reddetmeye başladı. Microsoft da Mayıs 2025'ten bu yana Outlook.com, Hotmail ve Live adreslerine günde 5.000'den fazla e-posta gönderenlerden benzer şartları istiyor. Google'ın önerisi spam oranını yüzde 0,1'in altında tutmak; yüzde 0,3 aşılmaması gereken çizgi.

Site sunucusundan e-posta göndermenin sorunları

Form bildirimleri bazen gelmiyor ya da spama düşüyorsa, sorun büyük ihtimalle gönderim yöntemindedir. Pek çok site bildirimleri doğrudan web sunucusundan, PHP'nin mail() işleviyle ya da WordPress'in varsayılan ayarıyla gönderir. Bu e-postaların arkasında ne SPF'de tanımlı bir sunucu ne de DKIM imzası vardır; DMARC'tan geçemezler.

Daha kötüsü de yapılır: form, gönderen adresi olarak ziyaretçinin kendi e-postasını kullanır. [email protected] adına sizin sunucunuzdan çıkan bir e-posta Gmail'in DMARC politikasına çarpar ve teslim edilmez. Paylaşımlı sunucudaysanız, aynı IP'den başkalarının gönderdiği spam yüzünden kara listeye girmeniz de cabası.

Çözüm, form bildirimlerini ve sipariş onayı, şifre sıfırlama gibi işlem e-postalarını bu iş için kurulmuş bir servis üzerinden göndermektir. Amazon SES, Postmark, Mailgun, SendGrid ve Brevo yaygın seçeneklerdir. Site servise kimlik doğrulamalı SMTP ya da API ile bağlanır; servis sizin alan adınız adına DKIM imzası atar, gönderim kayıtlarını ve geri dönen e-postaları raporlar.

• İşlem e-postaları için bildirim.firmaniz.com.tr gibi bir alt alan adı kullanın; pazarlama gönderimlerindeki bir itibar sorunu sipariş onaylarını etkilemesin.
• Gönderen adresi her zaman kendi alan adınızda olsun; ziyaretçinin adresini Reply-To alanına koyun.
• Form kayıtlarını sitenin panelinde ya da veritabanında da saklayın; e-posta gecikse bile talep kaybolmaz.
• Kendinize bir form gönderin, Gmail'de iletiyi açıp Orijinali göster seçeneğine tıklayın. SPF, DKIM ve DMARC satırlarının üçünde de PASS görmelisiniz.

Nereden başlamalı?

Önce bir envanter çıkarın: her satır için hesabın kimin adına olduğunu ve şifrenin nerede durduğunu yazın. Boş kalan her hücre, bir gün önünde bekleyeceğiniz bir kapıdır.

1. Kayıt kuruluşunun panelinde kayıt sahibini kontrol edin; şirket değilse düzeltilmesini isteyin.
2. Tüm hesapları şirketin parola yöneticisine taşıyın, iki adımlı doğrulamayı açın.
3. DNS bölgenizin dökümünü alın ve sahipsiz kayıtları temizleyin.
4. Otomatik yenilemeyi ve transfer kilidini kontrol edin.
5. SPF'nin tek kayıt olduğunu ve DKIM'in tüm gönderen hizmetlerde açık olduğunu doğrulayın, DMARC'ı izleme modunda başlatın.
6. Site formlarını bir işlem e-posta servisine bağlayın ve bir yedeği gerçekten geri yükleyip deneyin.

AYTE Digital olarak yeni bir site kurarken ya da devraldığımız bir altyapıyı düzenlerken bu envanteri birlikte çıkarıyor, hesapları şirketinizin adına toparlıyor ve DNS ile e-posta kimlik doğrulamasını devretmeden önce test ediyoruz. Amacımız, yarın başka bir ekiple çalışmak isteseniz bile hiçbir anahtarı aramak zorunda kalmamanız.