DNS değişikliği neden “küçük” bir işlem değildir?
Kurumsal e-posta tarafında SPF, DKIM ve DMARC kayıtları çoğu zaman tek satırlık DNS girdileri gibi görünür. Ancak bu kayıtlar, alıcı sistemlerin göndereninizi nasıl doğruladığını ve e-postalarınızın gelen kutusuna mı yoksa spam/karantina gibi klasörlere mi düşeceğini doğrudan etkiler. Yanlış yazılmış bir değer, eksik bir nokta, yanlış bir selector, fazla uzun bir TXT kaydı ya da hatalı bir politika; bir anda teslimat sorunlarına, sahtecilik riskinin artmasına veya üçüncü taraf sistemlerin gönderimlerinin reddedilmesine yol açabilir.
Bu nedenle amaç yalnızca doğru kaydı yazmak değil, değişikliği güvenle yayına almak, DNS yayılımının doğasını anlamak ve her adım için geri dönüş (rollback) planı oluşturmaktır.
Temel kavramlar: TTL, cache ve yayılım (propagation)
TTL nedir ve neden planlanmalıdır?
TTL (Time To Live), DNS kaydınızın resolver’lar tarafından ne kadar süreyle önbellekte tutulacağını belirtir. Örneğin TTL 3600 ise, o kaydı alan bir resolver teorik olarak 1 saat boyunca aynı yanıtı tekrar sorup güncellemeyebilir. Bu, DNS değişikliği yaptığınız anda tüm dünyanın yeni değeri görmeyeceği anlamına gelir.
“Propagation” aslında tek bir anda gerçekleşmez
DNS yayılımı pratikte; authoritative DNS sunucunuzdaki yeni değerin farklı resolver’ların cache süreleri doldukça görülmesidir. Bazı istemciler ve ağlar eski kaydı daha uzun süre tutabilir. Bu nedenle kritik e-posta DNS değişiklikleri, “hemen oldu” varsayımıyla yapılmamalıdır.
Negatif cache ve NXDOMAIN etkisi
Bir kaydı geçici olarak silmek veya yanlış isimle sorgulanmasına neden olmak, bazı resolver’ların “yok” sonucunu da cache’lemesine yol açabilir. Bu da düzeltme yapsanız bile bir süre daha sorun yaşanabileceği anlamına gelir. Bu yüzden özellikle DKIM selector ve DMARC kaydı gibi isimlendirmesi hassas kayıtlar için silip ekleme yerine kontrollü güncelleme tercih edilir.
Değişiklik öncesi hazırlık: Envanter ve bağımlılıklar
Hangi sistemler sizin adınıza e-posta gönderiyor?
Değişiklik planına başlamadan önce, alan adınızdan gönderim yapan tüm kaynakları çıkarın. Tipik kaynaklar şunlardır:
- Kurumsal posta sunucusu veya e-posta servis sağlayıcınız
- CRM ve satış otomasyonları
- Helpdesk/ticket sistemleri
- E-bülten ve pazarlama araçları
- Web sitesi formları ve uygulama sunucuları (transactional mail)
- Yazıcılar, NAS cihazları, izleme sistemleri gibi cihazlar
Bu envanter, SPF include’ları, DKIM selector’ları ve DMARC alignment davranışınızı doğrudan etkiler. Eksik envanter, “bizim sistem değil” sandığınız bir kaynağın gönderimlerinin bir anda fail vermesine neden olur.
Mevcut kayıtları yedekleyin
Değişiklikten önce SPF, DKIM (tüm selector’lar), DMARC ve varsa ilgili TXT/CNAME kayıtlarının mevcut hallerini bir dokümana kaydedin. Geri dönüş planının en hızlı yolu, önceki değerleri hatasız şekilde geri yazabilmektir.
Güvenli TTL stratejisi: Değişiklik penceresi tasarlama
Değişiklikten 24–48 saat önce TTL düşürme
Eğer mevcut TTL değerleriniz yüksekse (örneğin 4 saat, 12 saat, 24 saat), kritik değişikliklerden 24–48 saat önce TTL’yi daha düşük bir değere çekmek işleri kolaylaştırır. Düşük TTL, değişiklik sonrası yeni değerin daha hızlı “genel olarak” görünmesini sağlar. Ancak bunu son dakika yapmak çoğu zaman işe yaramaz; çünkü resolver’lar eski TTL’ye göre cache’lemiş olabilir.
Değişiklik sonrası TTL’yi tekrar makul seviyeye almak
Değişiklik oturduktan ve doğrulamalar yapıldıktan sonra TTL’yi operasyonel olarak makul bir seviyeye yükseltmek (örneğin 1–4 saat) yaygın bir pratiktir. Sürekli çok düşük TTL, DNS sorgu sayısını artırabilir ve yönetim açısından gereksiz olabilir.
SPF değişikliklerini güvenle uygulama
SPF’te en büyük riskler
- 10 DNS lookup limitini aşmak
- Yanlış include zinciri nedeniyle beklenmedik “permerror”
- ~all ile -all seçiminin acele yapılması
- Gönderici kaynak envanterinin eksik olması
Kademeli yaklaşım
SPF’te en güvenli yöntem, önce doğru kaynakları tanımlayıp doğrulamadan “katı” moda (-all) geçmemektir. Özellikle daha önce gevşek bir politika varsa, değişikliği önce izleme ve doğrulama ile desteklemek gerekir. Ayrıca SPF kaydının tek bir TXT olarak ve doğru biçimde yayınlandığından emin olun; aynı isimde birden fazla SPF TXT kaydı birçok alıcıda sorun çıkarır.
Rollback planı
SPF değişikliği sonrası beklenmedik reddedilmeler görürseniz, en hızlı geri dönüş önceki SPF değerini geri yazmaktır. Bu nedenle eski değerin kopyasını saklamak kritik önem taşır.
DKIM değişikliklerini güvenle uygulama: Selector ile “çift yayın” mantığı
Selector stratejisi
DKIM değişikliklerinde anahtar rotasyonu veya sağlayıcı değişikliği gibi durumlarda, aynı anda iki selector’ı bir süre birlikte çalıştırmak güvenli bir geçiş sağlar. Çünkü bazı sistemler yeni selector ile imzalamaya geçerken, bazıları eski selector ile imza üretmeye devam edebilir.
Güvenli cutover adımları
- Yeni selector için DNS kaydını ekleyin (henüz trafik taşımasa bile).
- Yeni selector’ın DNS’te erişilebilir ve doğru olduğundan emin olun.
- Gönderim sisteminde imzalamayı yeni selector’a alın.
- Eski selector’ı hemen kaldırmayın; belirli bir süre daha tutun.
Bu yaklaşım, özellikle kuyrukta bekleyen iletiler veya gecikmeli gönderimler nedeniyle oluşabilecek doğrulama problemlerini azaltır.
DMARC değişikliklerini güvenle uygulama: Politika hatalarından kaçınma
DMARC’ta riskli değişiklikler
- p=none’dan doğrudan p=reject’e geçmek
- Yanlış rua/ruf adresleri nedeniyle raporların gelmemesi
- Yanlış alignment varsayımları (adkim/aspf) nedeniyle beklenmedik fail
- Yanlış “sp” ve alt alan adı davranışlarının gözden kaçması
Politika değişimini operasyonel bir proje gibi ele alın
DMARC politikası yalnızca bir güvenlik ayarı değildir; e-posta ekosisteminizin gerçekte nasıl çalıştığının bir yansımasıdır. DMARC’ı sıkılaştırmadan önce SPF/DKIM doğrulama oranlarınızı, kimlerin gönderdiğini ve hangi akışların alignment dışına düştüğünü görmek gerekir. DMARC raporları bu süreçte en önemli geri bildirim mekanizmasıdır.
Geri dönüş planı
DMARC değişikliğinden sonra beklenmedik karantina veya reddetme durumları oluşursa, politikayı geçici olarak daha yumuşak bir değere almak (örneğin p=none veya quarantine) hızlı nefes aldırır. Buradaki hedef “kalıcı geri adım” değil, sorunlu kaynakları tespit etmek için zaman kazanmaktır.
Kontrol listesi: Değişiklik sonrası doğrulama ve izleme
Teknik doğrulamalar
- DNS kayıtlarının doğru isimde yayınlandığını kontrol edin (özellikle _dmarc ve DKIM selector).
- TXT değerlerinde kopyalama hatası, tırnak, noktalama ve boşluk sorunlarını kontrol edin.
- Birden fazla SPF TXT kaydı olmadığından emin olun.
Operasyonel doğrulamalar
- Farklı alıcı sağlayıcılara test e-postaları gönderin ve header sonuçlarını inceleyin.
- Bounce ve SMTP hata kodlarını takip edin; “policy”, “authentication” ve “permerror” gibi ipuçlarını ayıklayın.
- DMARC raporlarında yeni başarısızlık kaynakları oluşup oluşmadığını izleyin.
Değişiklik penceresi, iletişim ve sorumluluk
DNS tabanlı e-posta kimlik doğrulama değişiklikleri için bir değişiklik penceresi belirlemek, ilgili ekipleri bilgilendirmek ve “kim geri alacak, kim kontrol edecek” sorularını netleştirmek gerekir. Küçük işletmelerde bile bu, en azından bir kontrol listesi ve karar yetkisi anlamına gelir. Özellikle pazarlama kampanyası, fatura gönderimi veya yoğun transactional mail dönemlerinde değişiklik yapmak risklidir.
Sonuç: Güvenli DNS değişikliği, doğru kayıt kadar önemlidir
SPF/DKIM/DMARC kayıtlarını güncellemek, yalnızca DNS’e bir değer yazmak değil; TTL’yi planlamak, yayılım davranışını hesaba katmak, kademeli geçiş yapmak ve geri dönüş planı hazırlamaktır. Bu disiplin, teslim edilebilirlik riskini azaltır ve sorun yaşandığında teşhisi hızlandırır.
E-posta altyapınızı yönetirken, alan adınızın DNS kayıtlarının güncel tutulması ve değişikliklerin kontrollü uygulanması kritik önem taşır. MX1Mail gibi iş e-postası altyapısı kullanan ekipler de aynı şekilde SPF/DKIM/DMARC ve ilgili DNS ayarlarını planlı değişiklik süreçleriyle yöneterek daha öngörülebilir bir e-posta akışı sağlayabilir.