DMARC Kaydını Doğru Kurmak: p=none'dan p=reject'e Kademeli Yol

Bir DMARC kaydını yanlış hızda devreye almak, spam gönderenleri değil kendi ekibinizin meşru soğuk e-postalarını bloke edebilir. Bu yazıda DMARC kaydının parçalarını, kademeli yayına alma sırasını ve adresli B2B kampanyalar için hangi ayarların risk taşıdığını anlatıyoruz.

DMARC kaydı nedir, hangi parçalardan oluşur

DMARC (Domain-based Message Authentication, Reporting & Conformance) kaydı, _dmarc.domaininiz.com adresinde yayınlanan bir DNS TXT kaydıdır. Bu kayıt, alıcı posta sunucusuna şunu söyler: gelen e-posta SPF ve DKIM kontrollerinden geçmezse veya bu kontroller From başlığındaki domain ile hizalanmazsa (alignment) ne yapılacağını.

Kaydın en önemli etiketi p= — politika. Üç değer alabilir: none (sadece izle, hiçbir işlem yapma), quarantine (şüpheli e-postayı spam klasörüne yönlendir), reject (e-postayı tamamen reddet). Bunun yanında rua= toplu (aggregate) rapor adresini, ruf= adli (forensic) rapor adresini belirtir; pct= politikanın gönderimlerin yüzde kaçına uygulanacağını, sp= alt alan adları için ayrı politikayı, adkim= ve aspf= ise DKIM/SPF hizalama modunun katı mı (strict) yoksa gevşek mi (relaxed) olacağını tanımlar.

Pratikte en çok kullanılan ve en faydalı etiket rua='dır — aggregate raporlar, hangi kaynak IP'nin, ne sıklıkta, hangi sonuçla (pass/fail) e-posta gönderdiğini özetleyen düzenli bir dökümdür. ruf= ile istenen adli raporlar ise tek tek başarısız e-postaların ayrıntılarını içerir; bu raporları destekleyen alıcı sunucu sayısı aggregate raporlara göre azdır ve genelde gizlilik kaygılarıyla sınırlı gönderilir, bu yüzden çoğu ekip pratikte sadece rua= ile ilerler. rua= alanına birden fazla adres virgülle ayrılarak eklenebilir; örneğin hem dahili bir kutuyu hem bir izleme aracının aldığı adresi aynı anda tanımlamak mümkündür.

Neden doğrudan p=reject ile başlamamalısınız

Bir domain adına e-posta çıkaran araç sayısı genelde sanıldığından fazladır: CRM veya soğuk e-posta platformu, Google Workspace/Microsoft 365 üzerinden manuel yazışma, fatura sistemi, destek hattı, webinar veya etkinlik davetleri, bazen pazarlama otomasyon araçları. Bu araçlardan her biri SPF ve DKIM ile ayrı ayrı hizalanmadıysa, p=reject anında devreye alındığında bu araçlardan giden meşru e-postalar da reddedilir.

Bu yüzden yaygın tavsiye edilen yol, önce p=none ile başlayıp haftalarca raporları izlemek, hangi kaynakların gerçekten sizin adınıza e-posta gönderdiğini ve hangilerinin SPF/DKIM'de başarısız olduğunu görmek, sonra kademeli olarak p=quarantine'e, en son da p=reject'e geçmektir. pct= etiketiyle bu geçişi kademeli hale getirmek de mümkündür — örneğin önce pct=25 ile politikayı gönderimlerin sadece dörtte birine uygulayıp etkiyi gözlemleyebilirsiniz.

Somut bir senaryo düşünün: bir B2B soğuk e-posta ekibi CRM üzerinden dizi (sequence) gönderimi yapıyor, ama fatura sistemi hâlâ farklı bir sunucudan, DKIM'siz e-posta gönderiyor. Ekip raporları hiç incelemeden p=reject'e geçerse, CRM'den giden dizi e-postaları etkilenmeyebilir (çünkü CRM zaten hizalanmış) ama fatura sistemi ile giden bildirimler alıcı tarafında sessizce reddedilmeye başlar — ve bu genelde bir müşterinin „faturanızı alamadım" demesiyle haftalar sonra fark edilir. Raporları önceden izlemiş olsalar, bu kaynağı p=reject öncesinde tespit edip düzeltebilirlerdi.

Kaydı oluşturma adımları

Önce SPF ve DKIM'in her iki tarafta da (kullandığınız tüm gönderim araçlarında) doğru kurulu olduğundan emin olun; DMARC bunların üzerine inşa edilir, onların yerini almaz. SPF ve DKIM kurulu değilse DMARC kaydı eklemek tek başına bir şey değiştirmez, sadece raporlama başlar.

rua= adresi için kullanacağınız kutuyu seçerken, bu kutunun düzenli okunacağından emin olun; bazı ekipler ayrı, kimsenin bakmadığı bir dmarc-reports@ adresi oluşturup unutuyor. Küçük ölçekte kendi ekibinizden birinin doğrudan izlediği bir kutu yeterlidir; domain sayısı arttıkça bu adresi bir raporlama/izleme aracına yönlendirmek daha sürdürülebilir olur.

• 1) SPF ve DKIM'in tüm gönderim araçlarında kurulu ve doğrulanmış olduğunu kontrol edin
• 2) p=none ile bir DMARC kaydı oluşturup rua= adresine kendi izlediğiniz bir kutuyu (veya bir raporlama aracını) tanımlayın
• 3) En az birkaç hafta boyunca gelen toplu raporları inceleyip hangi kaynakların SPF/DKIM'de başarısız olduğunu tespit edin
• 4) Başarısız olan meşru kaynaklar için SPF/DKIM'i düzeltin (ör. eksik selector ekleyin)
• 5) pct= değerini kademeli artırarak p=quarantine'e geçin ve etkiyi izlemeye devam edin
• 6) Raporlarda meşru kaynaklardan başarısızlık kalmayınca p=reject'e geçin

Aggregate raporda nelere bakılır

Bir DMARC aggregate raporu, her kaynak IP için ayrı bir kayıt (record) içerir ve bu kayıtta source_ip (gönderen IP), count (o IP'den gelen e-posta sayısı), disposition (uygulanan politika sonucu — none/quarantine/reject), ve ayrı ayrı SPF ile DKIM sonuçları (pass/fail) bulunur. Bir kaynağın kim olduğunu genelde IP'nin ait olduğu servis sağlayıcıdan (ör. bilinen bir CRM'in veya e-posta sağlayıcının IP aralığı) tahmin edebilirsiniz; emin değilseniz IP'yi bir ters DNS sorgusuyla kontrol etmek yardımcı olur.

Raporu okurken asıl odaklanılması gereken satırlar, disposition alanı none/quarantine olup SPF veya DKIM sonucu fail olan kayıtlardır — bunlar, henüz hizalanmamış ama sizin adınıza gerçekten e-posta gönderen kaynaklardır. count değeri yüksek olan bir fail kaydı, gözden kaçırılmaması gereken öncelikli bir düzeltme adayıdır.

• source_ip: e-postayı hangi IP'nin gönderdiği
• count: o IP'den o dönemde kaç e-posta geldiği
• disposition: alıcı sunucunun uyguladığı sonuç (none/quarantine/reject)
• dkim ve spf sonuçları: her ikisinin ayrı ayrı pass/fail durumu

Sık yapılan hatalar

En sık görülen hata, raporları hiç okumadan veya çok kısa bir süre izleyip doğrudan p=reject'e atlamaktır — bu genelde bir kampanya ortasında fark edilen ve „neden e-postalarımız gitmiyor" sorusuyla sonuçlanan bir duruma yol açar. İkinci hata, rua= adresini kimsenin takip etmediği bir kutuya yönlendirip raporları hiç okumamaktır; DMARC kaydı varlığıyla değil, raporların düzenli izlenmesiyle değer katar.

Üçüncü hata, sp= (alt alan adı politikası) etiketini unutmaktır — ana domain için p=reject ayarlanmış olsa bile alt alan adları (ör. mail.sirketiniz.com veya info.sirketiniz.com) için ayrı bir politika tanımlanmazsa bu alt alan adları varsayılan olarak daha zayıf korunabilir. Son olarak, adkim= ve aspf= değerlerini strict (s) yapıp ardından SPF/DKIM'deki domain ile From başlığındaki domain'in birebir aynı olmadığı senaryoları test etmeden bırakmak da beklenmedik başarısızlıklara yol açar.

• Raporları izlemeden doğrudan p=reject'e geçmek
• rua= adresini kimsenin okumadığı bir kutuya yönlendirmek
• sp= etiketini unutup alt alan adlarını korumasız bırakmak
• Strict alignment (adkim=s, aspf=s) ayarlarken domain eşleşme senaryolarını test etmemek

DMARC ile İYS/KVKK arasındaki fark

DMARC, SPF ve DKIM gibi bir kimlik doğrulama mekanizmasıdır — e-postanın gerçekten iddia ettiği domainden geldiğini kanıtlar, ama kime, hangi izinle gönderildiğine dair bir şey söylemez. Türkiye'de ticari elektronik iletiler için İYS (İleti Yönetim Sistemi) üzerinden onay kontrolü yapılması ve KVKK kapsamında kişisel veri işleme ilkelerine uyulması ayrı bir konudur; bu ağırlıklı olarak tüketiciye yönelik toplu pazarlama iletilerini ve „ticari elektronik ileti" tanımına giren durumları kapsar.

Hedefli B2B soğuk e-postada durum nüanslıdır: bir şirket yetkilisine, meşru iş amacıyla, bire-bir gönderilen ve önceden var olan iş ilişkisi ya da açık iş bağlamı taşıyan iletişim, kitlesel tüketici pazarlama iletisiyle aynı kefeye konmaz. Yine de bu konuda kesin bir hukuki değerlendirme için hukuk danışmanınıza başvurmanızı öneririz — DMARC kurulumu bu değerlendirmenin yerine geçmez, sadece teknik teslimatı güçlendirir.

Checklist

Bu checklist'i her yeni gönderim aracı eklendiğinde veya domain yapınızda değişiklik olduğunda tekrar gözden geçirmek, DMARC kaydının zamanla „unutulan" bir DNS satırına dönüşmesini engeller.

• SPF ve DKIM tüm gönderim araçlarında doğrulanmış mı?
• p=none ile başlayıp raporları en az birkaç hafta izlediniz mi?
• rua= adresi düzenli okunan bir kutuya mı yönlendiriliyor?
• sp= etiketiyle alt alan adları da kapsandı mı?
• p=reject'e geçmeden önce tüm meşru kaynaklar SPF/DKIM'de pass veriyor mu?

Sık sorulan sorular