Google Workspace Gmail Geçişi: DNS, SPF, DKIM ve DMARC
Posta envanteri, migration kapsamı, MX değişimi, gönderici doğrulama ve delta kontrolüyle Gmail geçişini planlayın.
İçerik güncellemesi:
Mimari ve çalışma modeli
Posta geçişinde önce kullanıcı, alias, grup, ortak adres, yönlendirme, arşiv ve harici gönderici envanteri çıkarılır. Posta mesajı, takvim, kişi, delegasyon ve izin aynı veri türü değildir. Seçilen taşıma aracının kaynak sistem ve nesne desteği doğrulanır. Mesajların kopyalanması tüm takvim izinlerinin ve eski uygulama entegrasyonlarının taşındığını göstermez.
MX gelen postanın rotasını, SPF zarf gönderen için izinli kaynakları, DKIM mesaj imzasını, DMARC ise görünen From ile SPF/DKIM kimlik hizalamasını etkiler. Bunlar birbirinin yerine geçmez. Mevcut CRM, yazıcı ve bülten kaynakları korunmadan sadece Google için SPF yazmak meşru postayı bozabilir. Aynı domain için çakışan birden fazla SPF kaydı oluşturmayın.
Gmail kurulumu için güncel MX yönlendirmesini yönetim konsolu ve resmî dokümandan alın; eski çok-kayıt örneğini her yeni tenant için zorunlu saymayın. DNS TTL ve cache nedeniyle gelen mesajlar geçişte farklı hedeflere düşebilir. İlk taşıma, son delta ve posta rotası değişimi ayrı adımlardır. Her iki tarafta gelen son mesajı takip edin.
Kabul testi içeriden/dışarıdan gönderim, alias/grup teslimi, reply, takvim daveti ve istemci girişini kapsar. DMARC politikasını gerçek gönderici raporlarıyla aşamalı sıkılaştırın. Geri dönüşte yeni tarafta alınan mesajların ve takvim değişikliklerinin nasıl korunacağı belirlenir; yalnız eski MX kaydına dönmek tam rollback değildir.
- 1Posta ve nesne envanteri
- 2Pilot / ilk import
- 3DNS ve son delta
- 4Teslim ve kimlik kabulü
Tasarım parametreleri
- Nesne ve araç kapsamı
- Mesaj, takvim, kişi ve izin için desteklenen kaynak/hedef kapsamını ayrı yazın.
- DNS kontrolü
- MX, SPF, DKIM selector ve DMARCı yetkili DNS ile gerçek mesajda doğrulayın.
- Delta ve çakışma
- Tekrar taşımanın duplicate, güncellenen veri ve teslim rotası davranışını pilotta sınayın.
- Kesinti ve geri dönüş
- Gönderim ve teslim kabul sınırını, geri dönüş kararını ve yeni veriyi koruma adımını belirleyin.
Hesap ve uygulama örneği
100 posta kutusundan beş farklı kullanıcıyı pilot seçin: büyük arşiv, mobil istemci, yönetici asistanı, grup üyesi ve CRM göndericisi. Mesaj sayısı yanında tarih, ek, klasör/etiket eşlemesi ve seçili kayıtları karşılaştırın. Kaynak desteğine göre takvim ve kişileri ayrı doğrulayın.
MX geçişinden sonra dış bir test adresinden her alias ve gruba posta gönderin. Gerçek Authentication-Results başlığında SPF, DKIM ve DMARC sonucunu inceleyin. Son delta zamanını eski sistemin son teslimiyle karşılaştırın. Bu test gerçek kullanıcı postası veya parola paylaşımını gerektirmez; kontrollü test hesapları kullanın.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Gelen posta eski sisteme gidiyor | Resolver cachei veya yanlış MX scopeu olabilir. | Yetkili MX cevabı, TTL ve alıcı domaini birlikte kontrol edin. |
| SPF pass, DMARC fail | SPF domaini From ile hizalı değil veya DKIM uygun olmayabilir. | Gerçek zarf, From ve DKIM d= alanını karşılaştırın. |
| Mesajlar geldi, delegasyon eksik | Taşıma aracı izin nesnesini kapsamıyor olabilir. | Destek kapsamı ve hedef delegasyonu ayrı kontrol edin. |
Kabul ve doğrulama kontrolleri
- MX geçişini veri taşıma ve gönderici doğrulamayla birlikte kabul edin.
- Tüm meşru göndericileri SPF/DKIM kapsamına alın.
- Alias, grup ve reply teslimini test edin.
- Takvim ve izin kapsamını ayrıca doğrulayın.
- Son delta ile kaynakta kalan yeni veriyi eşleştirin.
- Rollbackte yeni mesajların korunmasını sınayın.
İlgili kavramlar
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
Birincil teknik dokümantasyon
Hazırlama yöntemi
Doz Teknoloji Teknik Ekibi tarafından hazırlanan bu rehberde üreticilerin resmi dokümanları temel alınır. Örnek senaryolar ve hesaplar yöntemi açıklamak içindir; tamamlanmış müşteri testleri değildir. Uygulamadan önce sürüm, lisans, istemci desteği, güvenlik koşulları ve geri dönüş planını kendi ortamınızda doğrulayın. Seçim mevcut ürünlerinize ve iş yükünüze göre yapılır.
İlgili işbirliği rehberleri
Google Workspace Kurulum, Lisans ve Kullanıcı Yönetimi
Alan adı, kullanıcı, organizasyon birimi, grup, lisans ve çalışan yaşam döngüsü için kontrollü Workspace kurulum rehberi.
Rehberi inceleGoogle Drive ve Shared Drives: Sahiplik, Paylaşım ve Yetki Tasarımı
My Drive ve shared drive ayrımı; ekip sahipliği, dış paylaşım, grup erişimi, senkronizasyon ve çalışan ayrılışı kontrolleri.
Rehberi inceleGoogle Workspace Güvenliği: MFA, Cihaz, OAuth ve Audit
2-Step Verification, passkey, cihaz koşulları, uygulama izinleri ve olay kayıtları için katmanlı güvenlik rehberi.
Rehberi inceleGoogle Workspace Vault, Saklama ve Yedekleme Stratejisi
Vault retention ve hold davranışını operasyonel backupdan ayırın; silinme, erişim, lisans ve geri kazanım kapsamını test edin.
Rehberi inceleGoogle Workspace ve Microsoft 365 (Office 365) Karşılaştırması
E-posta, belgeler, dosya paylaşımı, güvenlik, cihaz yönetimi, saklama ve toplam maliyet için ihtiyaç temelli karşılaştırma.
Rehberi inceleBilgi Merkezi’ndeki tüm rehberler
Platform seçimini mevcut ürünleriniz, iş yükünüz ve işletim ihtiyaçlarınızla birlikte değerlendiriyoruz.