Toplu E-posta Gönderiminde DMARC Ayarları: Newsletter İçin DNS Yapılandırması

Bir e-ticaret sitesi haftalık 40.000 aboneye newsletter gönderiyor, transactional e-postaları ayrı bir sunucudan yolluyor ve pazarlama ekibi üçüncü bir ESP (Email Service Provider) üzerinden kampanya postaları atıyor. Üç farklı gönderim kaynağı, tek bir domain. DMARC politikasını bu domain'e `p=reject` olarak eklediğinizde, tek bir yanlış yapılandırılmış kaynak yüzünden binlerce meşru e-posta aynı anda reddedilebilir; bu üç kaynağın hiçbiri birbirinden habersiz çalışamaz.

Düşük hacimli bir kurumsal domain'de DMARC geçişi nispeten basittir: birkaç gönderim kaynağı, öngörülebilir trafik, hızlı teşhis. Toplu e-posta gönderiminde durum değişir. Yüksek hacim, aggregate raporlarındaki gürültüyü artırır; farklı segmentler farklı IP havuzlarından gönderim yapabilir; ESP'nin kendi altyapısı zaman zaman IP değiştirebilir. Bu değişkenlik, DMARC politikasını sabit bir kural seti gibi değil, sürekli izlenen bir süreç gibi ele almayı gerektirir.

Toplu gönderim özelinde DMARC'ın nasıl kademeli kurulacağı, ESP hizalamasının nereden kırıldığı, aggregate raporların hangi sinyalleri taşıdığı ve `p=quarantine` aşamasından `p=reject`'e ne zaman geçilebileceği aşağıda adım adım ele alınıyor.

Neden Newsletter Gönderimi DMARC Açısından Farklı Bir Risk Taşır?

Standart bir kurumsal e-posta trafiğinde gönderen sayısı sınırlıdır: birkaç çalışan, bir CRM, belki bir fatura sistemi. Newsletter gönderiminde ise tek bir kampanya, ESP'nin onlarca IP'sinden aynı anda dağıtılabilir. Bu IP'lerin her biri SPF kaydında tanımlı olmalı, DKIM imzası her IP'den tutarlı şekilde uygulanmalı. Herhangi bir IP havuzu SPF'e dahil edilmemişse, o havuzdan giden postaların tamamı DMARC değerlendirmesinde başarısız olur.

İkinci risk katmanı segmentasyondan gelir. Pazarlama ekibi A/B testi için aynı kampanyayı iki farklı ESP üzerinden gönderiyorsa, domain aynı kalır ama gönderim altyapısı ikiye bölünür. Her iki altyapının da SPF ve DKIM açısından ayrı ayrı doğrulanması gerekir; birini eklemeyi unutmak, kampanyanın yarısının sessizce spam klasörüne düşmesine yol açar. Bu tür belirtileri ayırt etmenin genel yöntemi DNS kaynaklı deliverability sorunlarının teşhis sırası yazısında ele alınan mantıkla aynıdır, ama newsletter'da hata payı çok daha büyük bir kitleye yayılır.

Yüksek hacimli gönderimde tek bir yanlış yapılandırma, birkaç e-postayı değil, o günkü tüm kampanyayı etkiler. Bir segment testinde kullanılan geçici ESP hesabı SPF'e eklenmeden gönderim yapıldığında, hata sadece o segmentte görülür ve genellikle kampanya bittikten günler sonra aggregate raporlarında fark edilir.

p=none İle Başlamak Neden Atlanamaz Bir Adımdır?

Toplu gönderim yapan domainlerde DMARC'a doğrudan `p=quarantine` ile başlamak cazip görünür; sonuçta amaç zaten sahte gönderimleri engellemektir. Ama bu yaklaşım, henüz SPF'e eklenmemiş bir ESP IP'sini veya DKIM imzası tutmayan bir gönderim yolunu ilk günden cezalandırır. `p=none` aşaması, herhangi bir postayı reddetmeden veya karantinaya almadan, yalnızca izleme yapar; gerçek gönderim envanterinizin tam listesini bu aşamada çıkarırsınız.

Ad/Host: _dmarc
Tür: TXT
Değer: v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
TTL: 3600

`fo=1` etiketi burada özellikle önemlidir: SPF veya DKIM'den herhangi biri hizalama testinde başarısız olduğunda forensic rapor üretilmesini sağlar. Varsayılan davranış (`fo=0`), yalnızca her ikisi de başarısız olduğunda rapor üretir; bu, kısmi hizalama sorunlarının gözden kaçmasına neden olabilir. Newsletter gönderiminde SPF geçip DKIM'in kırılması (veya tersi) sık görülen bir senaryodur, bu yüzden `fo=1` daha erken uyarı verir.

İzleme süresi konusunda sabit bir kural yoktur ama toplu gönderimde en az iki tam kampanya döngüsünü (haftalık gönderim yapan bir liste için iki hafta, aylık bülten için iki ay) `p=none` altında geçirmek, mevsimsel veya kampanya bazlı gönderim farklılıklarını da rapor havuzuna dahil eder. Kampanya sıklığınız düşükse ve iki döngü beklemek pratik değilse, en azından farklı segment tiplerinin (transactional, promosyonel, işlemsel bildirim) her birinden bir örnek gönderim geçtiğinden emin olun.

Aggregate Raporları Yüksek Hacimde Nasıl Okumalısınız?

Düşük hacimli bir domain'de aggregate rapor birkaç kaynak IP içerir ve elle gözden geçirmek pratiktir. Newsletter domaininde aynı rapor yüzlerce satır, onlarca farklı kaynak IP taşıyabilir. XML yapısının kendisi değişmez; aggregate rapordaki record bloğunun okunma sırası burada da geçerlidir, fark hacimde ve otomasyon ihtiyacında ortaya çıkar.

Elle inceleme yerine, raporları bir tabloya (ya da bir DMARC izleme aracına) aktarıp kaynak IP başına pass/fail oranı çıkarmak, hangi gönderim yolunun sorunlu olduğunu saniyeler içinde gösterir. Beklenmeyen bir IP bloğu görüyorsanız, önce bunun ESP'nin kendi altyapı genişlemesinden mi yoksa gerçek bir sahte gönderim girişiminden mi kaynaklandığını ayırt edin.

# Her record bloğunda önemli üç alan:
# source_ip     -> hangi sunucudan gönderildi
# count         -> kaç e-posta bu IP'den geldi
# policy_evaluated.dkim / .spf -> pass mı fail mi

# Yüksek hacimde manuel okuma yerine:
# 1. Tüm source_ip değerlerini benzersiz listeye çıkarın
# 2. Her IP için toplam count ve fail oranını hesaplayın
# 3. Fail oranı yüksek olan IP'leri ESP'nizin IP listesiyle karşılaştırın

Beklenmedik bir sonuç: bazı büyük ESP'ler kampanya trafiğini paylaşımlı IP havuzlarından gönderir ve bu havuz zaman zaman genişler. SPF kaydınızda ESP'nin `include:` mekanizmasını kullanıyorsanız (doğrudan IP listelemek yerine), bu genişleme otomatik olarak kapsanır; aksi halde SPF kaydı yeni havuzu kapsamaz. IP'leri elle listelediyseniz, ESP'nin sessizce eklediği yeni bir sunucu SPF'te görünmez ve o sunucudan gelen postalar başarısız olur.

Forensic rapor (`ruf`) ile aggregate rapor (`rua`) yüksek hacimde birbirinden tamamen farklı davranır. Aggregate rapor günlük özet niteliğindedir ve hacim arttıkça dosya boyutu büyür ama satır sayısı yönetilebilir kalır. Forensic rapor ise her başarısız e-posta için ayrı bir bildirim üretir; 40.000 abonelik bir listede SPF henüz tam oturmamışken `ruf` etkinse, tek bir hatalı kampanya saatler içinde binlerce forensic e-postası tetikleyebilir ve bu e-postalar başlı başına bir posta kutusu doldurma sorununa dönüşür. Bu yüzden yüksek hacimli domainlerde `ruf` genellikle yalnızca `p=none` döneminin ilk haftalarında, sorunları hızlı teşhis etmek için açık tutulur; kaynaklar stabilize olduktan sonra kapatılıp yalnızca `rua` ile devam edilir.

Bazı büyük alıcı sunucular (örneğin büyük webmail sağlayıcıları) gizlilik politikaları gereği forensic rapor göndermez, yalnızca aggregate raporla yetinir. Bu, `ruf` etiketinin işe yaramadığı anlamına gelmez; sadece o alıcılardan detaylı bildirim beklenmemesi gerektiği anlamına gelir. Aggregate rapor tek başına IP ve hizalama sonucu için yeterli sinyali taşır.

Elle tablo tutmak, birkaç hafta süren `p=none` izlemesi için yeterlidir ama domain kalıcı olarak yüksek hacimde gönderim yapıyorsa (haftalık düzenli newsletter, günlük transactional trafik), raporları otomatik ayrıştıran bir DMARC izleme aracına geçmek zaman kazandırır. Böyle bir araç, XML dosyalarını kendiniz açıp saymak yerine, kaynak IP başına trend grafiği ve yeni görülen kaynakları otomatik işaretleyen bir gösterge sunar. Elle takip ile otomasyon arasındaki karar noktası basittir: günlük gelen rapor sayısı elle okunabilir durumdaysa (birkaç dosya) elle devam edin, haftada onlarca farklı alıcı sunucudan rapor geliyorsa otomasyona geçme zamanı gelmiştir.

ESP Kullanırken SPF ve DKIM Hizalamasını Doğru Kurmak

Newsletter gönderiminde en sık kırılan nokta alignment'tır; yani "From" başlığındaki domain ile SPF veya DKIM'in doğruladığı domain'in eşleşip eşleşmediği. Alignment kavramının genel işleyişi burada aynı şekilde çalışır, ama ESP'ler genellikle iki farklı kurulum yolu sunar: paylaşımlı bir alt domain üzerinden gönderim (örneğin `bounce.espdomain.com`) veya kendi domain'inize özel bir CNAME ile DKIM imzalama. İkincisi, yani özel CNAME ile DKIM, alignment açısından daha güçlüdür çünkü hem SPF hem DKIM sonuçta sizin ana domain'inizle hizalanır (strict veya relaxed mod fark etmeksizin).

# SPF kaydına ESP'nin gönderim alt yapısını dahil etme
v=spf1 include:_spf.google.com include:sendgrid.net ~all

# ESP tarafından verilen DKIM CNAME kaydı (selector adı sağlayıcıya göre değişir)
Ad/Host: em1234._domainkey
Tür: CNAME
Değer: em1234.dkim.espdomain.net

Birden fazla ESP veya gönderim aracı kullanıyorsanız, her yeni `include:` mekanizması SPF'in lookup sayısını artırır. Newsletter altyapısı genellikle ESP, CRM ve bir de transactional e-posta servisi olmak üzere üç ayrı kaynak barındırır; bu üç kaynak tek başına SPF'in 10 lookup sınırına yaklaşabilir. Sınır aşıldığında SPF tamamen `PermError` döner, bu da DMARC'ın SPF bacağını sessizce geçersiz kılar; sorun DMARC kaydında değil, SPF'in kendi yapısındadır.

DKIM için CNAME kaydı kullanan ESP'lerde, kayıt eklendikten sonra ESP panelindeki "doğrulandı" işaretine bakmak yeterli değildir. `dig` ile CNAME'in gerçekten ESP'nin belirttiği hedefe çözümlendiğini kontrol edin; bazı yerli DNS panelleri CNAME hedefinin sonuna otomatik nokta eklemez veya kaldırır, bu da teknik olarak farklı bir kayda işaret etmesine yol açabilir.

p=quarantine Aşamasına Geçiş İçin Hangi Koşullar Sağlanmalı?

`p=none` döneminde toplanan raporlarda tüm bilinen gönderim kaynaklarının pass oranı istikrarlı şekilde yüksekse (pratikte yüzde 95 ve üzeri, kalan pay tanımlı ve açıklanabilir kaynaklardan geliyorsa), `p=quarantine` aşamasına geçilebilir. Bu aşamada başarısız postalar tamamen reddedilmez, alıcı sunucunun spam klasörüne yönlendirilir; bu, `p=reject`'e göre çok daha güvenli bir ara adımdır çünkü meşru ama henüz hizalanmamış bir kaynak varsa postalar kaybolmaz, sadece gecikir ve görünür kalır.

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1

`pct=25` etiketi, politikanın yalnızca uyumsuz postaların yüzde 25'ine uygulanacağını belirtir; kalan yüzde 75 hâlâ `p=none` gibi davranır. Bu, yüksek hacimli newsletter domainlerinde riski dağıtmanın en pratik yoludur. İlk hafta `pct=25` ile başlayıp raporlarda beklenmeyen bir düşüş görülmezse `pct=50`, ardından `pct=100` şeklinde artırılabilir. Her artışta en az bir kampanya döngüsü beklemek, mevsimsel gönderim farklarının politika değişikliğiyle karışmasını önler.

Peki `pct` değerini ne zaman artırmamalısınız? Aggregate raporlarda daha önce görülmemiş bir kaynak IP'nin fail oranı hâlâ yüksekse. Bu genellikle iki şeyden biridir: ya bilinen bir gönderim kaynağı henüz SPF'e eklenmemiştir, ya da domain adına gerçek bir kimlik avı kampanyası yürütülmektedir. İkinci ihtimal, `p=quarantine` aşamasının tam olarak amacıdır; sahte gönderimler zaten spam klasörüne düşmeye başlamıştır.

quarantine'den reject'e Kademeli ve Güvenli Geçiş

`p=reject` en katı politikadır ve hizalama testinden geçemeyen her postayı doğrudan reddeder; alıcı sunucu postayı hiç teslim etmez, kuyruğa da almaz. Newsletter domaininde bu geçişi tek adımda yapmak, aylar süren `p=none` ve `p=quarantine` gözleminin tüm faydasını bir günde riske atabilir. Aynı `pct` mantığı burada da uygulanır, ama artık daha temkinli aralıklarla.

# 1. Hafta
v=DMARC1; p=reject; pct=10; rua=mailto:[email protected]

# 3. Hafta (raporlar temizse)
v=DMARC1; p=reject; pct=50; rua=mailto:[email protected]

# 6. Hafta (tam geçiş)
v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]

Bu sürecin süresi domain'in gönderim çeşitliliğine bağlıdır. Tek bir ESP üzerinden, sabit bir kaynak setiyle çalışan bir newsletter domaini birkaç haftada tam `p=reject`'e ulaşabilir. Mevsimsel kampanyalar, geçici ortak (affiliate) gönderimleri veya yıl içinde değişen üçüncü taraf entegrasyonları olan domainlerde bu süreç aylara yayılabilir; acele etmenin getirisi yoktur, kaybedilen meşru postanın maliyeti ise gecikmiş bir geçişten çok daha yüksektir.

`pct` değerini artırmadan önce DMARC kaydının TTL'ini de gözden geçirin. Geçiş dönemi boyunca TTL'i düşük (300-600 saniye gibi) tutmak, bir sorun fark edildiğinde `pct` değerini geri düşürmenin ya da politikayı tamamen `p=none`'a döndürmenin hızlı yayılmasını sağlar. Tam `p=reject; pct=100` aşamasına geçtikten ve raporlar en az bir kampanya döngüsü boyunca temiz kaldıktan sonra TTL'i standart değerine (3600 veya üzeri) yükseltmek makul bir sondur.

# Geçiş dönemi (pct artırılırken)
Ad/Host: _dmarc
TTL: 300

# pct=100 en az bir kampanya döngüsü temiz kaldıktan sonra
Ad/Host: _dmarc
TTL: 3600

Bir rollback gerektiğinde önce hangi kaynağın başarısız olduğunu aggregate rapordan doğrulayın, sonra kaydı geri alın; sırayı tersine çevirip önce politikayı gevşetip sonra teşhis etmek, hangi değişikliğin sorunu çözdüğünü anlamayı zorlaştırır. `pct` değerini bir önceki başarılı seviyeye (örneğin `pct=100`'den `pct=50`'ye) düşürmek genellikle domaini tamamen `p=none`'a döndürmekten daha az yıkıcıdır; zaten hizalanmış kaynaklar `p=reject` altında kalmaya devam eder, yalnızca sorunlu payın etkisi azaltılır.

Yaygın Hatalar: Alignment Kopması ve Forwarder Kaynaklı Sorunlar

Newsletter alıcılarının bir kısmı e-postalarını başka bir adrese otomatik yönlendiriyor olabilir (örneğin eski bir kurumsal adresten Gmail'e forward). Forwarder, orijinal SPF sonucunu bozar çünkü postayı yeni bir sunucudan iletir; DKIM imzası genellikle sağlam kalır ama bazı forwarder'lar mesaj gövdesine küçük ekler (footer, uyarı metni) yaptığında DKIM imzası da geçersiz hale gelir. Bu durumda alıcı tarafında hem SPF hem DKIM başarısız görünür, ama kaynak sizin altyapınız değil, alıcının forward zinciridir.

İkinci yaygın hata, abonelik iptali (unsubscribe) linklerini işleyen üçüncü taraf bir servisin, geri bildirim postalarını sizin domaininiz adına göndermesidir. Bu servis SPF'e dahil edilmemişse, bu tür otomatik postalar DMARC tarafından reddedilir; kullanıcı unsubscribe işlemini tamamladığını sanır ama onay postası hiç ulaşmaz. DMARC'ın kademeli geçiş mantığının genel çerçevesi bu tür ikincil gönderim akışlarını da SPF ve DKIM kapsamına almayı gerektirir; sadece ana kampanya trafiğini değil.

DMARC raporlarında sürekli aynı üç dört forwarder alan adından (büyük e-posta sağlayıcılarının bilinen forward mekanizmaları) düşük hacimli fail kayıtları görmek normaldir ve genellikle müdahale gerektirmez. Asıl dikkat edilmesi gereken, daha önce hiç görülmemiş, yüksek hacimli ve tek bir coğrafi bölgeden gelen fail kümeleridir; bu profil sahte gönderim girişimine daha çok benzer.

Toplu gönderim yapan bir domain için DMARC, bir kerelik kurulumdan çok, gönderim envanterinin canlı bir haritasıdır. Yeni bir pazarlama aracı eklendiğinde, bir kampanya için geçici bir ESP kullanıldığında veya mevcut sağlayıcı IP havuzunu değiştirdiğinde, bu değişiklik SPF ve DKIM tarafında da yansıtılmadıkça raporlarda hemen görünür hale gelir.

Politikayı `p=reject` seviyesine taşıdıktan sonra da izleme bitmez. Aggregate raporları düzenli aralıklarla (haftalık ya da aylık) gözden geçirmek, yeni bir gönderim kaynağının sessizce devreye girip devre dışı kalmasını erken yakalamanın tek yoludur; DMARC kaydı bir kez yazılıp unutulacak bir ayar değil, gönderim altyapısı değiştikçe güncellenmesi gereken canlı bir belgedir.