p=reject'e Geçmeden Önce DMARC Politikası Kontrol Listesi

DMARC kaydı ne işe yarar sorusunun kısa cevabı: SPF ve DKIM'i From başlığındaki domain ile hizalayıp, hizalama başarısız olduğunda alıcı sunucuya ne yapacağını söyler. Ama politikayı p=none'dan p=quarantine veya p=reject'e erkenden geçirmek, henüz hizalanmamış meşru gönderim kaynaklarınızı — CRM, fatura sistemi, destek yazılımı — da bloklayabilir.

DMARC politikası ne işe yarar, neden aceleyle değiştirilmemeli

DMARC (Domain-based Message Authentication, Reporting & Conformance), _dmarc.domain.com altında yayınlanan bir DNS TXT kaydıdır. SPF ve DKIM sonuçlarını From başlığındaki domain ile 'alignment' (uyum) üzerinden birleştirir; bu kontroller başarısız olursa alıcı sunucuya üç seçenekten birini söyler: p=none (sadece izle, hiçbir işlem yapma), p=quarantine (spam klasörüne koy) veya p=reject (tamamen reddet).

Sorun şurada: bir şirketin domain'i adına genelde tek bir araç değil, birçok kaynak e-posta gönderir — satış ekibinin CRM'i, fatura sistemi, destek yazılımı, bazen de bir pazarlama otomasyon aracı. Bu kaynakların hepsi SPF/DKIM ile hizalanmadan p=reject'e geçmek, aralarından hizalanmamış olanların e-postalarını da otomatik olarak reddettirir — ve bu genelde fark edilmeden, sessizce olur.

Bu durum özellikle DMARC'ı 'bir kere kurulur, bir daha bakılmaz' bir görev olarak ele alan ekiplerde ortaya çıkıyor. Oysa DMARC politikası, domain'in gönderim ekosistemi büyüdükçe yeniden gözden geçirilmesi gereken canlı bir yapılandırmadır — yeni bir araç eklendiğinde, mevcut politika o aracı kapsayacak şekilde güncellenmeli veya en azından o aracın hizalanması doğrulanmalıdır.

Geçiş öncesi çıkarılması gereken envanter

İlk adım, domain adına fiilen e-posta gönderen her kaynağı tek tek listelemektir. Bu liste sanılandan uzun çıkar: satış ekibinin kullandığı CRM veya adresli outreach platformu, muhasebe/fatura sistemi, destek/ticket yazılımı, dahili araçların gönderdiği bildirim e-postaları, bazen de tek bir çalışanın kişisel e-posta istemcisinden domain adına yaptığı yönlendirmeler.

Her kaynak için iki soru sorulmalı: bu kaynak SPF kaydındaki include listesinde mi, ve bu kaynağın kendi DKIM selector'ı DNS'te doğru yayınlanmış mı. İkisinden biri eksikse, o kaynağın e-postaları DMARC hizalamasını geçemez ve p=reject sonrası reddedilir.

Envanter çıkarma süreci genelde ekip içinde bir 'keşif' egzersizine dönüşür — pazarlama, satış, finans, IT ayrı ayrı sorulmadan hangi araçların domain adına gönderim yaptığı tam olarak bilinemez. Özellikle uzun süredir kullanılmayan ama hâlâ aktif bir entegrasyonun olduğu eski araçlar (ör. artık kullanılmayan bir form aracı veya eski bir CRM) bu aşamada gözden kaçan en tipik kalemlerdir.

• CRM / adresli outreach platformu (satış e-postaları)
• Fatura / muhasebe sistemi
• Destek / ticket yazılımı
• Dahili bildirim ve otomasyon araçları
• Alt domainler üzerinden gönderim yapan ayrı sistemler (ör. crm.sirket.com, news.sirket.com)

rua= raporlarını izlemeden politika değiştirmeyin

DMARC kaydındaki rua= etiketi, alıcı sunucuların günlük veya haftalık toplu (aggregate) raporlar gönderdiği bir adrestir. Bu raporlar hangi IP/kaynağın domain'iniz adına gönderim yaptığını ve SPF/DKIM hizalamasından geçip geçmediğini gösterir. p=none aşamasında bu raporları en az birkaç hafta izlemek, envanterde unutulan bir kaynağı (ör. eski bir entegrasyonun hâlâ aktif olduğunu) yakalamanın en güvenilir yoludur.

Raporlar ham XML formatında geldiği için çoğu ekip bunları doğrudan okumaz; bir DMARC raporlama/görselleştirme aracı kullanmak pratikte işi kolaylaştırır. Önemli olan, raporları en az bir defa gözden geçirmeden politika sertleştirmemektir — 'muhtemelen her şey hizalı' varsayımı, p=reject sonrası kaybolan meşru e-postaların en sık nedenidir.

Raporları okurken dikkat edilmesi gereken temel şey, tanımadığınız bir IP veya kaynağın domain adına gönderim yaptığını görmektir. Bu, ya envanterde unutulmuş meşru bir araçtır ya da domain'inizin izinsiz kullanıldığı (spoofing) bir durumdur — her iki durumda da bu sinyal, politikayı sertleştirmeden önce çözülmesi gereken bir konudur.

Kademeli geçiş: none → quarantine → reject

Önerilen yol, doğrudan p=reject'e atlamak değil, kademeli ilerlemektir. Önce p=none ile başlayıp rua= raporlarını birkaç hafta izleyin ve envanterdeki tüm kaynakların hizalandığını doğrulayın. Sonra pct= etiketiyle (uygulanacak yüzde) düşük bir oranda p=quarantine'e geçip etkiyi gözlemleyin; sorun çıkmazsa oranı kademeli artırın. Son adım olarak p=reject'e geçin — ve geçiş sonrası ilk günlerde raporları normalden sık kontrol edin.

Bu süreç aceleye getirilmemeli. Birkaç haftalık bir izleme dönemi, sertleştirme sonrası ortaya çıkabilecek 'meşru e-posta reddedildi' sorununu kampanya ortasında değil, önceden yakalamanızı sağlar.

B2B outreach yürüten ekipler için bu kademeli geçiş özellikle önemlidir, çünkü satış e-postalarının hedef aldığı alıcı sayısı zaten sınırlıdır — eğer geçiş sırasında CRM'den giden meşru satış e-postaları da hizalanmamış bir kaynak olarak reddedilirse, bu hem kampanyayı durdurur hem de sorunun kaynağını (içerik mi, hedefleme mi, teknik mi) yanlış teşhis etme riskini doğurur.

spf dkim dmarc test: geçişin her aşamasında nasıl doğrulanır

Her aşama geçişinden önce ve sonra bir spf dkim dmarc test yapmak, değişikliğin beklenen etkiyi yarattığını doğrulamanın en pratik yoludur. Test, gerçek gönderim kaynaklarınızdan (sadece ana domain değil, CRM'in kullandığı alt domain veya paylaşımlı gönderim altyapısı dahil) yapılmalı, çünkü DNS kaydı doğru görünse bile gerçek gönderim davranışı farklı sonuç verebilir.

MXToolbox gibi araçlar kaydın söz dizimini ve mevcut durumunu hızlıca gösterir, ama gerçek hizalama sonucunu görmek için bir test e-postası gönderip başlıklarındaki Authentication-Results satırını incelemek gerekir. Bu satır, SPF, DKIM ve DMARC'ın her birinin ayrı ayrı geçip geçmediğini ve hizalamanın başarılı olup olmadığını gösterir — sadece 'kayıt var' bilgisinden çok daha güvenilir bir sinyaldir.

Dmarc kaydı oluşturma: politika değiştirmeden önce yapı doğru mu

Dmarc kaydı oluşturma teknik olarak tek bir DNS TXT satırı eklemekten ibarettir, ama politika değiştirmeden önce kaydın yapısının doğru olduğunu doğrulamak gerekir. Kayıt en az bir p= (politika), genelde bir rua= (aggregate rapor adresi) ve isteğe bağlı bir ruf= (forensic rapor adresi) etiketi içerir; bu etiketlerden biri eksik veya yanlış yazılmışsa kayıt geçersiz sayılabilir ya da beklenen raporlar hiç gelmeyebilir.

Politika değiştirmeden önce mevcut kaydı bir kez daha açıp şu üç şeyi doğrulamak faydalıdır: rua= adresinin gerçekten aktif ve raporları alan bir kutu olduğu, p= değerinin şu an gerçekten istenen aşamada (none, quarantine veya reject) olduğu, ve sp= (alt domain politikası) varsa ana domainden farklı bir davranış tanımlayıp tanımlamadığı. Bu üç kontrol, geçiş öncesi kaydın kendisinden kaynaklanan sürpriz bir hatayı önler.

Geçiş sırasında sık yapılan hatalar

En sık hata, envanteri sadece bir kez çıkarıp bir daha güncellememektir. Geçiş süreci haftalarca sürdüğü için, bu süre içinde yeni bir araç eklenmiş veya bir entegrasyon değiştirilmiş olabilir; envanterin geçiş tamamlanana kadar canlı tutulması gerekir. İkinci hata, raporları sadece toplu sayılara bakarak okumaktır — 'yüzde 95 hizalı' görünen bir rapor, geriye kalan yüzde 5'in tam olarak hangi kaynak olduğunu söylemez; her satırı tek tek incelemeden hangi kaynağın risk altında olduğu anlaşılamaz.

Üçüncü hata, pct= etiketini hiç kullanmadan doğrudan tam oranda (pct=100) p=quarantine veya p=reject'e geçmektir. pct= etiketi, politikanın yalnızca belirli bir yüzdelik gönderime uygulanmasını sağlar; düşük bir oranla başlayıp kademeli artırmak, geniş çaplı bir sorunu küçük bir örneklemde yakalamayı mümkün kılar. Dördüncü hata, geçişi bir Cuma günü veya tatil öncesi yapmaktır — sorun çıkarsa izleyecek ve müdahale edecek kimsenin olmaması, küçük bir yapılandırma hatasının günler boyu fark edilmeden büyümesine yol açar.

Geçiş sonrası kontrol listesi

Politika sertleştirildikten sonra iş bitmiş sayılmaz — özellikle ilk hafta izleme kritik.

• Envanterdeki tüm gönderim kaynakları SPF include listesinde mi
• Her kaynağın DKIM selector'ı DNS'te doğrulandı mı
• rua= raporları en az 2-4 hafta izlendi mi
• Geçiş kademeli mi yapıldı (none → quarantine → reject), doğrudan reject'e mi atlandı
• Geçiş sonrası ilk hafta raporlar günlük kontrol edildi mi
• Alt domainler için ayrı bir DMARC kaydı gerekip gerekmediği değerlendirildi mi

Sık sorulan sorular