Domain ve DNS Bilgi Rehberi
Bir kapıya beş sürgünün sabit sırayla takılması, üçüncüsü atlanırsa kapının yine açılması

Google Workspace için DNS Kayıtları: Adım Adım Kurulum Kontrol Listesi

Bir şirket Google Workspace'e kaydolduğunda kurulum sihirbazı birkaç dakika içinde biter, ama asıl iş o noktada başlar. Gmail'in gelen kutusunu görebilmeniz, e-posta gönderebilmeniz, sahte gönderim girişimlerinin engellenmesi ve domain sahipliğinin doğrulanması; bunların hepsi DNS panelinizde doğru sırayla eklenmiş birkaç kayda bağlıdır. Sihirbaz size hangi değerleri gireceğinizi gösterir, ama neden o sırayla ilerlemeniz gerektiğini ve hangi kaydın eksik kalması durumunda ne olacağını açıklamaz.

Bu kontrol listesi, Google Workspace kurulumunda gereken beş DNS bileşenini (doğrulama, MX, SPF, DKIM, DMARC) ve isteğe bağlı servis CNAME kayıtlarını sırayla ele alır. Her adımda hangi kaydın hangi amaçla eklendiğini, doğru söz dizimini ve kurulum sonrası nasıl doğrulanacağını gösterir. Amaç sihirbazı tekrar etmek değil, arkasında ne olduğunu anlayarak eksiksiz ve doğru sırayla ilerlemenizi sağlamaktır.

Bu kontrol listesinin en çok işe yaradığı yer çoğu zaman yeni bir domain'in ilk kurulumu değildir; mevcut bir domain'i Google Workspace'e taşırken ya da başka bir e-posta sağlayıcısından geçiş yaparken ortaya çıkan karmaşadır. Eski sağlayıcının bıraktığı MX kaydı, birden fazla SPF include'ı, unutulmuş bir DKIM selector'ı; bunların hepsi aynı DNS panelinde birikir ve hangisinin güncel, hangisinin gereksiz olduğunu ayırt etmek zamanla zorlaşır.

Google Workspace Kurulumunda DNS'in Rolü Nedir?

Google Workspace bir bulut hizmetidir; e-postalarınızı, takviminizi ve dosyalarınızı Google'ın sunucularında barındırır. Ancak domain'iniz hâlâ kendi registrar'ınızda kayıtlıdır ve DNS kayıtlarınız muhtemelen başka bir sağlayıcıda yönetilir. Google'ın bu domain adına e-posta alabilmesi, göndermesi ve sahipliğinizi doğrulayabilmesi için DNS üzerinden birkaç farklı kayıt türüyle yetki tanımlanması gerekir.

Bu yetkilendirme beş ayrı katmanda çalışır: domain sahipliğinin doğrulanması (TXT), gelen e-postanın Google sunucularına yönlendirilmesi (MX), giden e-postanın yetkili olduğunun kanıtlanması (SPF), her mesajın kriptografik olarak imzalanması (DKIM) ve bu mekanizmalar başarısız olduğunda ne yapılacağının tanımlanması (DMARC). DNS sorgularının fiziksel olarak nasıl dağıtıldığı bu katmanların neden birbirinden bağımsız yapılandırıldığını kavramayı kolaylaştırır. Her katman bağımsız çalışır; birinin eksik olması diğerlerinin işlevini tam olarak yerine getirmesini engeller.

Doğrulama (TXT) Kaydı: Domain Sahipliğini Kanıtlama

Google Workspace'e ilk kaydolduğunuzda admin panel, domain sahipliğini kanıtlamanızı ister. En yaygın yöntem, panelin verdiği benzersiz bir kodu kök domain'e TXT kaydı olarak eklemektir. Bu kayıt yalnızca doğrulama amacıyla kullanılır; e-posta akışına hiçbir etkisi yoktur.

Admin panelde gösterilen kodu birebir kopyalamanız gerekir; tırnak işareti veya fazladan boşluk doğrulamayı başarısız kılar. Bazı DNS panelleri kök domain'i otomatik varsayar, bazıları ise açıkça "@" veya boş bırakılmasını ister. Doğrulama onayı anlık gelmeyebilir; panel birkaç dakika ile birkaç saat arasında DNS değişikliğinin yayılmasını bekler. "Doğrulanamadı" hatası alıyorsanız Google tarafını değil, DNS panelinizde kaydın gerçekten eklenip eklenmediğini kontrol etmek daha hızlı bir teşhis yoludur.

MX Kayıtları: Gelen E-postanın Google'a Yönlendirilmesi

MX (Mail Exchange) kaydı, domain'inize gelen e-postanın hangi sunucuya teslim edileceğini belirler. Eski kurulumlarda beş farklı ASPMX sunucusu farklı önceliklerle tanımlanırken, güncel kurulumda tek bir MX kaydı yeterlidir.

Eski kurulumdan geçiş yapıyorsanız önceki ASPMX kayıtlarını silmeden önce yeni kaydı ekleyin, ardından eskileri kaldırın; böylece geçiş penceresinde iki yapılandırma bir arada bulunur ve teslimat kesintisi oluşmaz. Geçiş penceresinde kesintisiz posta akışını korumak için TTL değerini geçişten önce düşürmek belirleyicidir; propagasyon penceresi kapanmadan eski kayıtları silmek en sık karşılaşılan hatadır. Domain'inizde başka bir MX kaydı hâlâ duruyorsa Google Workspace kurulumu tamamlanamaz; kök domain için yalnızca Google'a ait tek MX kaydı bulunmalıdır.

SPF Kaydı: Google'ın Gönderim Yetkisini Tanımlama

SPF (Sender Policy Framework), hangi sunucuların domain'iniz adına e-posta göndermeye yetkili olduğunu TXT kaydı üzerinden tanımlar. Google Workspace kullanıyorsanız en azından Google'ın gönderim altyapısını kapsayan bir kayıt gereklidir.

Domain'inizden başka servisler de e-posta gönderiyorsa (bir CRM, fatura sistemi veya pazarlama aracı), bunların da aynı SPF kaydına dahil edilmesi gerekir; her kaynak için ayrı bir SPF kaydı oluşturmak çalışmaz, bir domain için yalnızca tek bir SPF kaydı geçerlidir. Birden fazla include mekanizması eklendikçe DNS lookup sayısı artar ve 10'u aştığında kayıt sessizce geçersiz hale gelir; bu, SPF lookup limitinin klasik belirtisidir. Yeni bir gönderim servisi entegre etmeden önce o servisin önerdiği include değerini mevcut kayda eklemeyi kurulum adımlarından biri olarak listeleyin.

DKIM Kaydı: İmza Doğrulama Yapılandırması

DKIM, giden her e-postaya kriptografik bir imza ekler ve alıcı sunucunun bu imzayı DNS üzerinden yayınlanan public key ile doğrulamasını sağlar. Google Workspace admin panelinde DKIM anahtarı "Uygulamalar → Google Workspace → Gmail → E-posta kimlik doğrulama" bölümünden oluşturulur; panel size bir TXT değeri üretir ve bunu belirli bir host adına eklemeniz istenir; host adı DKIM selector katmanıdır.

Kaydı ekledikten sonra admin panelde "kimlik doğrulamayı etkinleştir" adımını tamamlamanız gerekir; DNS kaydı eklenmiş olsa bile bu adım atlanırsa Google giden e-postaları imzalamaya başlamaz. DKIM public key'i genellikle uzundur; bazı DNS panelleri TXT değerini otomatik parçalara ayırıp birleştirirken, bazıları elle bölünmüş girişi ister ve aradaki boşluk veya tırnak hatası anahtarı bozar. Kırpılmış bir public key DKIM doğrulamasının sessizce başarısız olmasına yol açar; kayıt "var" görünür, ama eksiktir.

DMARC Kaydı: Politika ve Raporlama

SPF ve DKIM kurulduktan sonra, bu mekanizmalardan biri başarısız olduğunda alıcı sunucunun ne yapacağını tanımlayan DMARC kaydı eklenir. Yeni kurulumda doğrudan reject politikasıyla başlatmak risklidir; henüz SPF veya DKIM'e dahil edilmemiş meşru bir gönderim kanalı varsa, bu kanaldan gelen e-postalar da reddedilir.

p=none ile başlamak herhangi bir e-postayı reddetmeden yalnızca rapor toplamanızı sağlar. Birkaç hafta boyunca rua raporlarını inceleyip tüm meşru gönderim kaynaklarının SPF veya DKIM üzerinden geçtiğini doğruladıktan sonra politika kademeli olarak quarantine, ardından reject'e yükseltilebilir. Bu kademeli geçiş Google Workspace'e özgü değildir; herhangi bir e-posta altyapısında aynı sırayla ilerler.

Ek Servisler İçin İsteğe Bağlı CNAME Kayıtları

Bazı kurumsal domain'ler, Google Workspace servislerine kısa alt alan adlarıyla (mail.example.com, calendar.example.com gibi) erişim sağlamak ister. Bu isteğe bağlıdır; temel e-posta işlevselliği için gerekli değildir. CNAME kayıtları admin panelde "Alan adları → Alan adı bazlı hizmetler" bölümünden etkinleştirilir; DNS tarafında CNAME eklemek tek başına yeterli değildir, panel tarafında da ilgili servisin bu alt alana bağlanması gerekir. Apex domain'de CNAME kısıtları ve düzleştirme konusu, kök domain üzerinde benzer yönlendirme yapmak istediğinizde neden farklı bir yaklaşım gerektirdiğini açıklar.

Aynı Domain'de Başka Servisler Çalışırken Çakışmaları Önleme

Küçük ve orta ölçekli şirketlerde tek bir domain, Google Workspace'in yanı sıra bir web sitesi, bir yardım masası ve bazen ikinci bir e-posta gönderim servisi barındırır. En sık görülen çakışma, kök domain'de zaten bir TXT kaydı varken Google'ın SPF kaydının bu kayda eklenmek yerine ayrı bir ikinci TXT kaydı olarak oluşturulmasıdır; sonuç iki SPF kaydının aynı anda var olması ve doğrulamanın permerror ile başarısız olmasıdır.

Bu riski azaltmanın pratik yolu, kök domain'deki tüm TXT kayıtlarını periyodik olarak listelemek ve v=spf1 ile başlayan kaydın tek olduğundan emin olmaktır. Aynı mantık DKIM için geçerli değildir; her servis kendi selector'ıyla ayrı bir _domainkey alt alanına yazar, DKIM kayıtları çakışmaz ama birikir. Zamanla biriken bu kayıtları takip etmek zaman alır; çok domain'li yapılarda DNS düzenini korumak için de benzer bir kayıt disiplini gerekir.

Beş kaydın tamamı eklendikten sonra doğrulamayı tek tek yapmak, bir sorun çıktığında hangi katmanın eksik olduğunu hızlıca bulmanızı sağlar. Sıra önemlidir: TXT doğrulama ve MX önce kontrol edilir, çünkü bunlar olmadan e-posta akışı hiç başlamaz; SPF, DKIM ve DMARC daha sonra gelir. Temel sorgular: dig example.com TXT +short, dig example.com MX +short, dig google._domainkey.example.com TXT +short ve dig _dmarc.example.com TXT +short.

Kurulumun tamamlandığından emin olmanın en pratik yolu, gerçek bir test e-postası göndermek ve alıcı tarafında başlıkları incelemektir; SPF, DKIM ve DMARC sonuçlarının üçünün de pass döndüğü bir başlık, beş kaydın da doğru sırayla ve doğru içerikle yerleştiğinin göstergesidir. Atlanan tek bir adım, örneğin DKIM etkinleştirmenin unutulması, e-postaların gönderilmeye devam etmesine rağmen alıcı tarafında güven puanının düşmesine yol açabilir.

İlgili Yazılar