Admin konsolunda "Gmail'i etkinleştir" adımına geldiniz, sağ üstte turuncu bir uyarı duruyor: "Alan adınızın MX kayıtları henüz bulunamadı." Kayıtları eklediğinizden eminsiniz, hosting panelinde de görünüyorlar. Ya da daha can sıkıcı ikinci senaryo: kurulum tamamlandı, ekipteki üç kişiye test maili attınız, ikisi Gmail'e düştü, üçüncüsü hâlâ eski hosting'in webmail arayüzünde bekliyor. Aynı alan adı, aynı gün, iki farklı posta kutusu.
Bu iki tablonun da arkasında neredeyse her zaman aynı sebep vardır: alan adının DNS bölgesinde birbiriyle çelişen kayıtlar duruyor ve gönderen sunucular hangisine güveneceklerine kendi kurallarına göre karar veriyor. Google'ın kendi kurulum sihirbazı "şu kaydı ekleyin" der ama "şunları silin" kısmını çoğu zaman siz atlarsınız — çünkü panelde eski kayıtlar zaten oradadır ve zararsız görünürler.
Bu rehberde Google Workspace geçişinde eklemeniz gereken dört kaydı (doğrulama TXT'si, MX, SPF, DKIM) hangi alana tam olarak ne yazacağınız düzeyinde ele alacağız; ardından cPanel kullanıyorsanız DNS doğru olsa bile mailin sunucudan çıkmamasına yol açan e-posta yönlendirme ayarını düzeltecek ve her adımı dig ile doğrulayacağız.
Kayıtları Hangi Panele Yazacaksınız?#
İlk ve en çok zaman kaybettiren karar bu. DNS kayıtlarını alan adının nameserver'larının gösterdiği yere yazarsınız; alan adını nereden satın aldığınıza değil. Alan adınız ns1.hostingfirmasi.com gibi nameserver'lara yönlendirilmişse kayıtlar hosting panelinizin DNS/Zone Editor bölümüne, Cloudflare'e taşınmışsa Cloudflare paneline, kayıt firmasının varsayılan sunucularında duruyorsa firma paneline yazılır. Hangi panelin yetkili olduğunu tek komutla görürsünüz:
dig NS ornek.com +short
Çıkan sunucu adları hangi firmaya aitse kayıtlarınız orada yaşıyor demektir. Kayıtları yanlış panele yazmak, "ekledim ama görünmüyor" şikâyetinin en yaygın sebebidir; komutun çıktısı bu tartışmayı bitirir. Ekleyeceğimiz kayıtların tamamı şu tabloda:
| Amaç | Tip | Host / Ad | Değer | Öncelik |
|---|---|---|---|---|
| Alan adı doğrulama | TXT | @ (boş) | google-site-verification=... | — |
| Posta teslimi | MX | @ (boş) | smtp.google.com | 1 |
| Gönderen yetkisi | TXT | @ (boş) | v=spf1 include:_spf.google.com ~all | — |
| İmza doğrulama | TXT | google._domainkey | v=DKIM1; k=rsa; p=... | — |
| Politika bildirimi | TXT | _dmarc | v=DMARC1; p=none; rua=mailto:... | — |
Panellerdeki alan adları farklıdır: "Host", "Name", "Ad", "Alias" hepsi aynı şeydir. Bazı paneller kök alan adı için boş bırakmanızı, bazıları @ yazmanızı, bazıları da alan adının tamamını (ornek.com.) yazmanızı bekler. Kaydı ekledikten sonra listede nasıl göründüğüne bakın: ornek.com.ornek.com gibi bir sonuç çıktıysa alan adını iki kez yazmışsınızdır.
Adım 1: Alan Adı Doğrulama TXT Kaydı#
Google, alan adının gerçekten sizin olduğunu görmeden posta trafiğini teslim etmez. Admin konsolu size google-site-verification= ile başlayan bir dize verir; bunu kök alan adına TXT olarak eklersiniz.
ornek.com. 3600 IN TXT "google-site-verification=Xy4pQ2r8sT1uVw0zAbCdEfGhIjKlMnOpQrSt"
Üç noktaya dikkat edin. Birincisi, TTL'i 3600 saniyede bırakabilirsiniz; doğrulama kaydının hızlı yayılması gerekmez. İkincisi, dizeyi tırnak içinde saklamak panelin işidir — siz tırnak yazarsanız bazı paneller tırnağı da değerin parçası sayar ve doğrulama başarısız olur. Üçüncüsü ve en önemlisi: doğrulama tamamlandıktan sonra bu kaydı silmeyin. Google zaman zaman sahipliği yeniden kontrol eder; kayıt yoksa alan adı doğrulanmamış duruma düşer ve kullanıcı ekleme gibi işlemler kilitlenir.
TXT ile doğrulama mantığının tamamı ve alternatif yöntemler (HTML dosyası, meta etiketi, CNAME) için TXT ile alan adı doğrulama yazısına bakabilirsiniz.
Adım 2: MX Kaydı Artık Tek Satır#
Yıllarca Google Workspace kurulumu beş MX kaydı eklemek demekti: ASPMX.L.GOOGLE.COM öncelik 1, iki ALT1/ALT2 öncelik 5, iki ALT3/ALT4 öncelik 10. Google bu yapıyı sadeleştirdi; artık yeni kurulumlarda tek bir MX kaydı yeterli:
ornek.com. 3600 IN MX 1 smtp.google.com.
Bu tek kayıt eski beş kaydın tamamının yaptığı işi yapar; yedeklilik Google'ın kendi tarafında, smtp.google.com arkasındaki anycast altyapıda çözülür. Eski beş kayıtlı düzen hâlâ çalışır, yani yıllardır sorunsuz işleyen bir kurulumu sırf modernize etmek için bozmanıza gerek yok. Ama yeni bir alan adı taşıyorsanız tek kayıtla ilerleyin: bakımı kolay, hata payı düşük.
| Yapı | Kayıt sayısı | Değerler | Ne zaman |
|---|---|---|---|
| Güncel | 1 | 1 smtp.google.com | Yeni kurulum, taşıma |
| Eski (legacy) | 5 | 1 ASPMX.L..., 5 ALT1/ALT2, 10 ALT3/ALT4 | Zaten çalışan kurulum |
İki pratik ayrıntı: bazı paneller hedef sunucu adının sonunda nokta ister (smtp.google.com.). Nokta istemeyen bir panele nokta yazarsanız ya da tersini yaparsanız kayıt smtp.google.com.ornek.com gibi çözülür ve posta hiçbir yere gitmez. İkincisi, MX kaydının host alanı kök alan adı olmalıdır; www yazarsanız [email protected] adresine gelen postalar için hiçbir şey değişmez.
MX kaydının çalışma mantığını, önceliklerin ne anlama geldiğini hiç ele almadıysanız MX kaydı nedir yazısı bu adımı çok daha anlaşılır kılar.
Eski Kayıtları Silmezseniz Postalar Nereye Gider?#
Asıl mesele burada. Gönderen posta sunucusu, alan adının MX kayıtlarını çeker ve öncelik değeri en küçük olanı ilk dener. Eski hosting kurulumlarında cPanel varsayılan olarak 0 ornek.com ya da 0 mail.ornek.com şeklinde bir MX kaydı bırakır. Siz Google'ın kaydını öncelik 1 ile eklediğinizde tablo şöyle olur:
ornek.com. 3600 IN MX 0 mail.ornek.com.
ornek.com. 3600 IN MX 1 smtp.google.com.
0 < 1 olduğu için her posta eski sunucuya gider. Gmail arayüziniz bomboş kalır, siz de "MX kaydı doğru, neden çalışmıyor" diye saatlerce panele bakarsınız. Kayıt gerçekten doğrudur; sadece sıradaki ikinci adaydır.
İkinci ve daha sinsi varyant: eski kaydın önceliği 10 ise. Bu durumda postalar normal zamanlarda Google'a düşer, sistem çalışıyor görünür. Ama Google tarafında anlık bir geçici hata olduğunda ya da bazı gönderen sunucular sıradaki adayı denediğinde postalar eski makinedeki, artık kimsenin açmadığı posta kutusuna iner. Müşteri "faturayı gönderdim" der, siz "gelmedi" dersiniz, mail aslında iki yıldır kimsenin girmediği bir webmail hesabında durur. Ayda üç beş mail kaybı üreten, teşhisi en zor senaryo budur.
Kural nettir: Google'ın MX kaydını eklemeden önce alan adındaki diğer tüm MX kayıtlarını silin. Google'a ait olmayan tek bir MX kaydı bile kalmamalı. Kayıt listesini gözle kontrol etmek yetmez; bir sonraki bölümlerde dig ile teyit edeceğiz, çünkü paneller bazen sildiğiniz kaydı arka planda tutmaya devam eder.
Adım 3: SPF Kaydı — Alan Adında Tek Satır Olmalı#
SPF, "bu alan adı adına hangi sunucular posta gönderebilir" listesidir. Google Workspace için gereken değer kısa:
ornek.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
Buradaki en yaygın hata, mevcut bir SPF kaydının üzerine ikinci bir SPF kaydı eklemek. Bir alan adında v=spf1 ile başlayan birden fazla TXT kaydı bulunursa doğrulama permerror verir ve SPF sonucu geçersiz sayılır — yani iki kayıt eklemek, sıfır kayıt eklemekten daha kötüdür. Hâlâ eski sunucudan da posta gönderiyorsanız (site iletişim formu, e-ticaret bildirimleri, fatura sistemi) iki ayrı kayıt değil, tek kayıtta birleştirme yaparsınız:
ornek.com. 3600 IN TXT "v=spf1 include:_spf.google.com ip4:203.0.113.10 include:_spf.saglayici.com ~all"
Bir sınıra daha dikkat edin: SPF değerlendirmesi sırasında yapılabilecek DNS sorgusu sayısı 10 ile sınırlıdır ve her include: bu bütçeden yer. Dört beş farklı hizmeti üst üste eklerseniz kayıt sessizce çalışmaz hâle gelir. Kullanmadığınız hizmetleri kayıttan çıkarın.
Sondaki ~all "softfail" anlamına gelir: listede olmayan bir sunucudan gelen posta reddedilmez ama işaretlenir. Geçişin ilk haftalarında bu doğru tercihtir; her şeyin oturduğundan emin olduktan sonra -all yapmayı değerlendirebilirsiniz. SPF, DKIM ve DMARC'ın birbirini nasıl tamamladığını SPF, DKIM ve DMARC yazısında derinlemesine anlattık.
Adım 4: DKIM Anahtarını Üretin ve Yayınlayın#
DKIM, giden her postaya sunucunun bir imza eklemesi ve alıcının bu imzayı DNS'teki açık anahtarla doğrulamasıdır. Google Workspace'te DKIM varsayılan olarak açık gelmez; anahtarı sizin üretip yayınlamanız gerekir.
Admin konsolunda Uygulamalar → Google Workspace → Gmail → E-postanın kimliğini doğrula yolunu izleyin. Alan adını seçip yeni kayıt oluşturduğunuzda 2048 bit anahtar ve google seçici (selector) varsayılan olarak gelir. Konsol size iki bilgi verir:
- Host / Ad:
google._domainkey - Değer:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A...IDAQAB
google._domainkey.ornek.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..." "...wIDAQAB"
Kaydı ekledikten sonra konsola geri dönüp "Kimlik doğrulamayı başlat" düğmesine basmayı unutmayın. Bu adım atlandığında DNS kaydı yayında olur, dig ile görünür, her şey doğru görünür — ama Google giden postaları imzalamadığı için alıcı tarafında DKIM sonucu none çıkar. Kurulumu doğru yapıp neden çalışmadığını anlayamayanların yarısı bu düğmeye basmamıştır.
255 Karakter Sınırı: Değer Alana Sığmıyor#
2048 bit bir açık anahtarın base64 karşılığı 400 karakterin üzerindedir. DNS protokolünde tek bir TXT dizesi en fazla 255 karakter olabilir; daha uzun değerler tek kayıt içinde birden fazla tırnaklı parçaya bölünerek saklanır. cPanel Zone Editor ve Cloudflare bu bölmeyi otomatik yapar. Bazı eski paneller yapmaz ve size "değer çok uzun" hatası verir.
Böyle bir panelle karşılaşırsanız sırasıyla şunları deneyin: değeri 255'er karakterlik parçalara elle bölüp her parçayı tırnak içinde aynı kayda yazın; panel buna da izin vermiyorsa alan adını Cloudflare gibi bir DNS servisine taşımayı değerlendirin. Anahtarı 1024 bit'e düşürmek teknik olarak sorunu çözer ama zayıf anahtar üretmiş olursunuz — kalıcı çözüm değildir. DKIM doğrulamasının başarısız olduğu diğer senaryolar için DKIM doğrulaması başarısız yazısına bakın.
Adım 5: DMARC Kaydı#
DMARC, SPF ve DKIM sonuçları uyuşmadığında alıcının ne yapması gerektiğini söyleyen politikadır. Google ve Yahoo, toplu gönderim yapan alan adlarından DMARC kaydı beklediğini duyurdu; kurumsal posta için de artık standart parçası sayılıyor.
_dmarc.ornek.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; adkim=r; aspf=r"
p=none ile başlayın. Bu politika hiçbir postayı engellemez, sadece rua adresine günlük rapor gönderilmesini sağlar. Raporlarda hangi sunucuların sizin adınıza posta gönderdiğini birkaç hafta izleyip listeyi SPF'e ekledikten sonra p=quarantine, en sonunda p=reject seviyesine geçebilirsiniz. Sıralamayı atlayıp doğrudan p=reject yazmak, unuttuğunuz bir bordro yazılımının maillerini bir gecede yok eder. Toplu gönderim yapıyorsanız büyük posta sağlayıcılarının artık DMARC kaydını zorunlu tuttuğunu da hesaba katın.
cPanel Kullanıyorsanız: E-posta Yönlendirmesini Uzak Sunucuya Alın#
Bu adım rehberlerin çoğunda yoktur ve DNS'i kusursuz yapmış insanların takıldığı yer tam olarak burasıdır. Alan adınızın web sitesi hâlâ bir cPanel sunucusunda duruyorsa, o sunucu üzerindeki posta yazılımı (Exim) alan adını yerel kabul eder. Yani sunucu, [email protected] adresine gitmesi gereken bir postayı MX kaydına hiç bakmadan kendi içindeki posta kutusuna teslim eder.
Sonuç şudur: dışarıdan gelen postalar Gmail'e düşer, ama sitenizin iletişim formundan, WordPress bildirimlerinden veya aynı sunucudaki başka bir hesaptan gönderilen postalar Gmail'e hiç ulaşmaz. "Form çalışıyor mu?" diye test edersiniz, mail gelmez, formu suçlarsınız. Form çalışıyordur; mail sunucudan hiç çıkmamıştır.
Düzeltmesi tek ayardır: cPanel → E-posta → E-posta Yönlendirmesi (Email Routing) → alan adını seçin → Uzak Posta Değişimi (Remote Mail Exchanger). Root erişiminiz varsa sonucu sunucudan da doğrulayabilirsiniz:
# Alan adı hangi listede duruyor?
grep -H ornek.com /etc/localdomains /etc/remotedomains
Alan adı /etc/remotedomains içinde görünmelidir. /etc/localdomains içinde kaldıysa ayar uygulanmamıştır. Aynı sunucuda eski posta hesaplarını da bir süre silmeyin; geçiş sırasında oraya düşmüş mailler olabilir. Konunun cPanel tarafındaki tüm ayrıntıları cPanel MX kaydı ve e-posta yönlendirme yazısında.
dig ile Kurulumu Doğrulama#
Panelde "kaydı ekledim" demek yeterli değil; kaydın dünyaya nasıl göründüğüne bakmanız gerekir. Beş komut tüm kurulumu denetler:
# MX: tek satır ve sadece Google çıkmalı
dig MX ornek.com +short
# SPF ve doğrulama TXT'si aynı çıktıda görünür
dig TXT ornek.com +short
# DKIM açık anahtarı
dig TXT google._domainkey.ornek.com +short
# DMARC politikası
dig TXT _dmarc.ornek.com +short
# Kendi yerel önbelleğinizi atlayıp harici bir çözücüye sorun
dig @8.8.8.8 MX ornek.com +short
Beklenen çıktı MX için tek satırdır: 1 smtp.google.com. Başka bir sunucu adı görüyorsanız silmeniz gereken bir kayıt kalmış demektir. Windows üzerinde dig yoksa aynı sorguyu şöyle yaparsınız:
nslookup -type=MX ornek.com 8.8.8.8
dig çıktısını okuma alışkanlığı yoksa dig komutu kullanımı yazısı bayrakları tek tek açıklıyor. Kayıtlar sizde doğru görünüp başkalarında görünmüyorsa sorun yayılım aşamasındadır; farklı ülkelerdeki çözücülere sorgu atan propagasyon kontrol servisleriyle durumu haritada görebilirsiniz.
Son test her zaman gerçek bir postadır: kişisel bir Gmail hesabından kurumsal adresinize mail atın, gelen mesajda Orijinali göster seçeneğine tıklayın. Üst blokta SPF: PASS, DKIM: PASS, DMARC: PASS satırlarını görüyorsanız kurulum tamamdır.
Belirti → Sebep → Çözüm Tablosu#
| Belirti | Muhtemel sebep | Çözüm |
|---|---|---|
| Gmail'e hiç mail gelmiyor | Öncelik 0 olan eski MX kaydı duruyor | Google dışı tüm MX kayıtlarını silin |
| Mailler ara ara kayboluyor | Yedek konumda eski MX kaydı var | Aynı: tek MX kaydı bırakın |
| Site formundan gelen mail yok | cPanel yerel teslim yapıyor | E-posta Yönlendirmesi → Remote Mail Exchanger |
Alıcıda dkim=none | "Kimlik doğrulamayı başlat" tıklanmamış | Admin konsolunda DKIM'i etkinleştirin |
Alıcıda spf=permerror | Alan adında iki SPF kaydı var | Tek kayıtta birleştirin |
| Panel "değer çok uzun" diyor | 2048 bit DKIM 255 karakteri aşıyor | Değeri tırnaklı parçalara bölün |
| Konsol "doğrulanmadı" diyor | Doğrulama TXT'si silinmiş | google-site-verification kaydını geri ekleyin |
Geçiş Gününü Kayıpsız Planlamak#
Kayıtları doğru yazmak işin yarısı; geçişi ne zaman ve hangi sırayla yaptığınız diğer yarısı.
- Geçişten 24 saat önce mevcut MX ve TXT kayıtlarının TTL değerini 300 saniyeye düşürün. Böylece değişiklik saatler yerine dakikalar içinde yayılır.
- Kullanıcıları önce oluşturun. Google tarafında hesaplar hazır olmadan MX'i değiştirirseniz gelen postalar "böyle bir kullanıcı yok" hatasıyla geri döner.
- Eski postaları taşıyın. Google'ın veri taşıma aracı ya da IMAP üzerinden aktarım, MX değişiminden önce başlatılabilir; sonrasında son bir tur daha çalıştırırsınız.
- MX'i değiştirin, ardından eski kayıtları silin. Yoğun olmayan bir saat seçin.
- Eski hosting hesabını en az iki hafta kapatmayın. Yayılım tamamlanana kadar bazı gönderenler eski adresi denemeye devam eder; hesap kapalıysa o postalar geri döner.
- Bir hafta sonra TTL'i 3600'e geri çıkarın ve DMARC raporlarını okuyun.
Kurumsal posta için Google Workspace'in mi yoksa hosting paketinizle gelen posta hizmetinin mi daha uygun olduğuna hâlâ karar vermediyseniz kurumsal e-posta mı Google Workspace mi karşılaştırması maliyet ve yönetim yükü tarafını ele alıyor.
Sıkça Sorulan Sorular#
Google Workspace için kaç MX kaydı eklemem gerekiyor?#
Yeni kurulumlarda tek bir MX kaydı yeterlidir: öncelik 1 ile smtp.google.com. Google eskiden beş kayıt (ASPMX ve ALT1-ALT4) isterdi; bu yapı hâlâ çalışıyor, dolayısıyla yıllardır sorunsuz işleyen bir kurulumu değiştirmek zorunda değilsiniz. Ancak yeni bir alan adı taşıyorsanız tek kayıtla ilerleyin. Önemli olan, alan adında Google'a ait olmayan başka MX kaydı bırakmamaktır.
Eski MX kayıtlarını silmezsem tam olarak ne olur?#
Gönderen sunucular önceliği en düşük olan kaydı ilk dener. Eski hosting'in kaydı öncelik 0'daysa postaların tamamı eski sunucuya gider ve Gmail kutunuz boş kalır. Öncelik 10 gibi bir yedek konumdaysa postalar çoğunlukla Google'a düşer, ama geçici hatalarda eski sunucuya kayar. İkinci durum daha tehlikelidir çünkü kayıp düzensizdir ve fark edilmesi haftalar sürebilir.
DKIM kaydını ekledim ama alıcıda hâlâ doğrulanmıyor, neden?#
En yaygın sebep, Admin konsolunda kaydı oluşturduktan sonra "Kimlik doğrulamayı başlat" adımının atlanmasıdır. DNS kaydı yayında olsa bile Google giden postaları imzalamaya başlamaz. İkinci sebep, 2048 bit anahtarın DNS'e eksik yazılmasıdır: değer 255 karakterden uzun olduğu için bazı paneller sonunu kırpar. dig TXT google._domainkey.ornek.com çıktısını konsoldaki değerle karşılaştırın.
SPF kaydımı Google için değiştirirsem eski sunucudan gönderdiğim mailler etkilenir mi?#
Evet, mevcut SPF kaydının üzerine yazarsanız eski sunucunuz yetkili listeden çıkar ve oradan giden postalar softfail alır. Doğru yaklaşım ikinci bir SPF kaydı eklemek değil, tek kayıtta birleştirmektir: v=spf1 include:_spf.google.com ip4:ESKI_SUNUCU_IP ~all. Alan adında v=spf1 ile başlayan birden fazla TXT kaydı bulunması, SPF'i tamamen geçersiz kılar.
DNS kayıtlarının yayılması ne kadar sürer?#
Pratikte çoğu çözücü değişikliği 15 dakika ile birkaç saat arasında görür; teorik üst sınır ise eski kaydın TTL değeridir. TTL 86400 saniyeye ayarlıysa bazı sunucular eski cevabı bir gün daha önbellekte tutabilir. Bu yüzden geçişten en az 24 saat önce TTL'i 300'e düşürmek, taşınma gününü saatler yerine dakikalarla ölçmenizi sağlar.
Alan adı doğrulama TXT kaydını sonradan silebilir miyim?#
Silmeyin. Google alan adı sahipliğini periyodik olarak yeniden kontrol eder ve kayıt bulunamazsa alan adı doğrulanmamış duruma düşer; bu durumda yeni kullanıcı ekleme gibi yönetim işlemleri kısıtlanabilir. Kayıt küçük bir TXT satırıdır, hiçbir maliyeti yoktur ve başka hiçbir kaydı etkilemez — bölgenizde kalıcı olarak bırakın.
Web sitem başka bir sunucuda kalabilir mi?#
Evet, tamamen ayrı iki kayıt kümesidir. Sitenizin nereden yayınlandığını A ve AAAA kayıtları, postanın nereye teslim edileceğini MX kayıtları belirler. Siteniz mevcut hosting'de kalmaya devam ederken postalar Google'a gidebilir. Tek dikkat edilmesi gereken, o sunucu cPanel ise e-posta yönlendirmesini "Uzak Posta Değişimi" olarak ayarlamaktır; aksi halde sunucu kendi içinden gönderilen postaları dışarı çıkarmaz.