Manuel Kontrolden Sürekli İzlemeye: DMARC'ı API ile Otomatikleştirmek

Manuel bir DMARC kontrolü, o anki durumu gösterir; ama raporlar günlük olarak birikirken aradaki bir haftayı kaçırırsanız, bir domain'in sessizce başarısızlığa düştüğünü fark etmeniz haftalar sürebilir. Bu yazıda manuel kontrolün nerede yetersiz kaldığını ve API tabanlı sürekli izlemenin çok domainli B2B gönderim altyapılarında neden pratik hale geldiğini anlatıyoruz. Odak noktamız tek seferlik bir kontrol aracı seçmek değil, zaman içinde büyüyen bir gönderim altyapısını nasıl sürdürülebilir şekilde izleyeceğinizdir.

Manuel kontrolün gerçek sınırı nerede başlar

Tek bir domain için haftada bir checker aracına bakmak makul bir rutindir. Ancak DMARC aggregate raporları, gönderen posta sağlayıcılarından (Google, Microsoft, Yandex gibi büyük alıcı sunucular dahil) günlük olarak, her biri ayrı bir XML dosyası halinde gelir. Beş-on domain ve düzinelerce gönderim kaynağı olan bir yapıda, bu dosyaları elle indirip okumak bir tam zamanlı iş yüküne dönüşür — ve gerçekte kimse bunu her gün yapmaz.

Sonuç olarak manuel kontrol, pratikte „ara sıra bakma" haline gelir. Bu da bir SPF include zincirinin limiti aşması, yeni bir gönderim aracının DKIM'siz kalması veya bir alt alan adının DMARC kapsamı dışında kalması gibi sorunların günler, bazen haftalarca fark edilmeden kalması demektir. Bu tür sorunlar genelde bir kampanyanın deliverability'sinin beklenmedik şekilde düşmesiyle, yani sonuçtan geriye doğru fark edilir.

Somut bir örnek: yedi domain yöneten bir B2B ekibinde raporları izleme görevi bir kişiye aittir ama bu kişi asıl işi (satış operasyonları) yoğunlaştığında raporlara bakmayı üç hafta erteler. Bu üç hafta içinde domainlerden birinin DKIM anahtarı, DNS sağlayıcı panelinde yapılan alakasız bir güncelleme sırasında yanlışlıkla silinir. Raporlar üç hafta sonra incelendiğinde, o domain'den giden tüm e-postaların üç haftadır SPF'e bel bağlayarak (ve DMARC alignment'ın zayıflamasıyla) daha düşük teslim oranıyla gittiği ortaya çıkar — kayıp geri alınamaz, sadece ileriye dönük düzeltilebilir.

API tabanlı izleme ne değiştirir

API tabanlı bir DMARC izleme çözümü, rua= adresine gelen XML raporlarını otomatik olarak toplar, normalize eder ve kaynak IP, gönderim aracı, geçme/başarısız olma oranı gibi kırılımlarla okunabilir bir görünüme dönüştürür. Bu sayede „hangi kaynak SPF'de başarısız oluyor" sorusunun cevabı dakikalar içinde alınabilir, XML dosyalarını tek tek açmaya gerek kalmaz.

Bazı çözümler bunun ötesine geçip belirli bir eşik aşıldığında (ör. bir kaynağın başarısızlık oranı aniden yükseldiğinde) otomatik uyarı gönderir. Bu, özellikle p=quarantine'den p=reject'e geçiş sürecinde değerlidir — politika sertleştirildikten sonra beklenmedik bir kaynağın e-postaları reddedilmeye başlarsa, bunu saatler içinde fark edip müdahale etmek mümkün olur, haftalar sonra fark etmek yerine.

„API tabanlı izleme" iki farklı şekilde kurulabilir. Birincisi, rua= adresini doğrudan bir izleme sağlayıcısının kendi kabul adresine yönlendirmektir — sağlayıcı raporları kendi tarafında toplar, siz sadece onların panelini veya API'sini kullanırsınız. İkincisi, raporları kendi kutunuza almaya devam edip bir script veya entegrasyonla bu XML dosyalarını otomatik ayrıştırıp kendi sisteminize (bir veritabanına, bir Slack kanalına) aktarmaktır. İlk yol daha az geliştirme yükü ister, ikinci yol ise verinin tamamen kendi altyapınızda kalmasını sağlar.

dmarcian ve benzeri kurumsal çözümler nerede devreye girer

dmarcian, DMARC izleme ve raporlama konusunda bilinen bir kurumsal araçtır; XML raporlarını toplayıp analiz eden, kaynak bazında görünürlük sağlayan ve genelde çok domainli yapılar için tasarlanmış bir platform sunar. Bu tür araçların kesin fiyatlandırması ve özellik kapsamı zamanla ve sağlayıcının paket yapısına göre değişebileceğinden, net bir rakam vermek yerine doğrudan sağlayıcıyla görüşüp domain sayınıza ve ihtiyacınıza uygun paketi netleştirmenizi öneririz. Fiyat teklifi isterken kaç domain, hangi hacimde gönderim ve kaç kullanıcı erişimi ihtiyacınız olduğunu net şekilde belirtmek, size en uygun paketin hızlıca netleşmesini sağlar.

Bu tür araçları değerlendirirken bakılacak pratik kriterler şunlardır: kaç domain'i tek panelden izleyebiliyorsunuz, raporlar ne sıklıkla güncelleniyor, otomatik uyarı eşikleri özelleştirilebiliyor mu, ve API erişimi kendi iç sistemlerinize (ör. bir Slack kanalına veya dahili bir dashboard'a) entegre edilebiliyor mu.

Kurumsal DMARC izleme sağlayıcılarının çoğu, raporlara programatik erişim için bir REST API sunar — bu sayede raporları kendi dashboard'unuza, bir BI aracına veya bir uyarı sistemine bağlayabilirsiniz. API erişiminin hangi pakette dahil olduğu, kaç istek/ay içerdiği ve hangi veri alanlarını döndürdüğü sağlayıcıdan sağlayıcıya değişir; bu detayları netleştirmeden bir sözleşmeye girmemek, sonradan „API'ye erişim için ek ücret" gibi sürprizlerle karşılaşmamak açısından önemlidir.

Çok domainli bir B2B gönderim altyapısında pratik senaryo

Birden fazla tenant veya müşteri adına gönderim yapan bir ajans modelinde, her domain'in kendi SPF/DKIM/DMARC durumu vardır ve bunlardan biri bozulduğunda etkilenen sadece o domain'dir — ama fark edilmesi diğer domainlerin izlenmesini de aksatabilir. Bu senaryoda API tabanlı merkezi bir gösterge paneli, her domain için ayrı ayrı manuel kontrol yapmak yerine tek ekrandan genel sağlığı görmeyi mümkün kılar.

Aynı mantık, tek bir şirket içinde birden fazla marka veya bölge için ayrı domain kullanan B2B ekipleri için de geçerlidir — örneğin bir şirketin hem ana kurumsal domaini hem de belirli bir ürün hattı için ayrı bir domaini varsa, her ikisi de ayrı SPF/DKIM/DMARC yapılandırması gerektirir ve ikisinin de sağlığı aynı anda izlenmelidir. Domain sayısı arttıkça bu izlemeyi merkezi bir panelden yapmak, dağınık sekmelerde tek tek kontrol etmekten kayda değer ölçüde daha az zaman alır.

Karar checklist'i: API'ye geçmeye değer mi

Bu soruların çoğuna evet yanıtı veriyorsanız, manuel kontrolden API tabanlı bir çözüme geçişi değerlendirmenin zamanı gelmiş demektir. Tek-iki domainli, sınırlı hacimde çalışan bir ekip için ise düzenli manuel kontrol hâlâ yeterli ve maliyet açısından mantıklı bir seçenek olabilir.

• Beşten fazla domain veya gönderim kaynağı yönetiyor musunuz?
• Raporları izleyecek biri var mı, yoksa bu görev sürekli erteleniyor mu?
• p=quarantine'den p=reject'e geçiş planınız var mı — geçiş sırasında hızlı uyarı almanız gerekir mi?
• Bir domain'in bir haftalığına sessizce bozulması işiniz için ne kadar maliyetli olur?
• İç sistemlerinize (Slack, dashboard) entegre edilebilecek bir API'ye ihtiyacınız var mı?

Kendi entegrasyonunuzu kurmak mı, hazır bir araç mı

Teknik kapasitesi olan bir ekip için rua= raporlarını kendi altyapısında ayrıştırıp bir dashboard'a bağlamak mümkündür — açık kaynak kütüphaneler DMARC XML formatını ayrıştırmayı kolaylaştırır ve bu yaklaşım verinin tamamen kendi kontrolünüzde kalmasını sağlar. Ancak bu bir defalık bir kurulum değil, sürdürülmesi gereken bir küçük iç araçtır: yeni bir rapor formatı varyasyonu, yeni bir gönderim kaynağı ya da script'in kendisinde bir hata, birinin bunu bakımdan sorumlu tutmasını gerektirir.

Hazır bir kurumsal araç kullanmak bu bakım yükünü ortadan kaldırır ama abonelik maliyeti getirir ve rapor verisinin bir kısmının üçüncü taraf bir sağlayıcıda tutulması anlamına gelir. Karar, ekibinizin mühendislik kapasitesine, kaç domain yönettiğinize ve verinin nerede tutulduğu konusundaki tercihlerinize bağlıdır — evrensel olarak „doğru" bir cevap yoktur.

Pratik bir orta yol, küçük ölçekte kendi script'inizle başlayıp domain sayınız ve ekibiniz büyüdükçe hazır bir araca geçmektir; bu, erken aşamada gereksiz abonelik maliyetinden kaçınırken, bakım yükü artmaya başladığında elinizde zaten neye ihtiyacınız olduğuna dair somut bir fikir bırakır.

Sık sorulan sorular