DMARC Flow: How Email Security Flows

E-posta, iş iletişiminin omurgası olmaya devam ediyor ve aynı zamanda en büyük saldırı vektörlerinden biri. Kimlik avı, spoofing ve Business Email Compromise (BEC) her yıl milyarlarca dolarlık zarara yol açıyor. Ancak e-postayı uçtan uca güvence altına alan iyi tanımlanmış bir teknik akış var: DMARC Flow. Bunu adım adım anlamak, doğru şekilde uygulamak için ön koşuldur.

1. Adım — Gönderici Beyan Eder: SPF

Sender Policy Framework (SPF), alanınız adına e-posta göndermeye yetkili posta sunucularını listeleyen bir DNS kaydıdır. Alıcı bir posta sunucusu, siz@example.com'dan geldiği iddia edilen bir mesaj aldığında, example.com'un SPF kaydı için DNS sorgusu yapar ve bağlanan IP adresinin yetkili listede olup olmadığını denetler.

IP listede yoksa ve SPF -all (sert başarısız) ile bitiyorsa SPF başarısız olur. ~all (yumuşak başarısız) kullanılırsa mesaj işaretlenir ancak doğrudan reddedilmez. SPF tek başına alan kimliğine bürünmeyi durdurmaya yetmez; çünkü SPF, kullanıcıların gerçekte gördüğü görünür Kimden başlığını değil, zarf göndericisini ("Return-Path") denetler.

Akışı bozan yaygın SPF hataları: 10 DNS sorgu sınırını aşmak, hizmet dışı bırakılan sağlayıcılardan kalan eski include'ları bırakmak ve yeni e-posta gönderme araçlarını (CRM'ler, pazarlama platformları, işlem sistemleri) kayda eklemeyi unutmak.

2. Adım — Mesaj İmzalanır: DKIM

DomainKeys Identified Mail (DKIM), her giden mesaja kriptografik bir imza ekler. Gönderici posta sunucusu mesajı özel anahtarla imzalar ve imzayı başlık alanı olarak ekler. Karşılık gelen açık anahtar, selector1._domainkey.example.com gibi bir seçici kaydı altında DNS'te yayımlanır.

Alıcı sunucu mesajı aldığında açık anahtarı DNS'ten alır ve imzayı doğrulamak için kullanır. Geçerli bir imza iki şeyi kanıtlar: birincisi, mesajın özel anahtara sahip bir sunucudan geldiğini (yani yetkili bir gönderici); ikincisi, mesaj gövdesi ve anahtar başlıklarının iletim sırasında değiştirilmediğini.

SPF'nin aksine DKIM, mesajın kendisine bağlı olduğundan gönderen IP'ye değil, e-posta iletiminde ayakta kalır. Bu, DKIM'i hizalama için daha güçlü bir sinyal yapar. Ancak DKIM de tek başına alan kimliğine bürünmeyi engelleyemez; imzalı alanın DMARC'a katkıda bulunabilmesi için Kimden başlığıyla hizalı olması gerekir.

3. Adım — Politika Uygulanır: DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ile DKIM'i birbirine bağlayan ve onları eyleme dönüştürülebilir kılan katmandır. Bir DMARC kaydı, _dmarc.example.com'da yayımlanan ve alıcı sunuculara üç şeyi bildiren bir TXT kaydıdır:

1. Hem SPF hem DKIM hizalamasında başarısız olan mesajlara ne yapılacağı — politika (p=none, p=quarantine veya p=reject).
2. Toplu raporların gönderileceği yer (rua parametresi) — alanınızdan olduğunu iddia eden tüm postaların kimlik doğrulama sonuçlarını gösteren, her büyük posta kutusu sağlayıcısından gelen günlük XML özetleri.
3. Adli raporların gönderileceği yer (ruf parametresi) — bireysel kimlik doğrulama başarısızlıkları için mesaj bazında hata raporları.

Hizalama denetimi temel kavramdır. DMARC; SPF hizalaması geçerse (Return-Path'teki alan, Kimden alanıyla eşleşir) ya da DKIM hizalaması geçerse (DKIM imzasındaki alan, Kimden alanıyla eşleşir) başarıyla sonuçlanır. Kimden başlığınızı taklit eden bir saldırgan hizalamayı geçemez; çünkü DNS'inizi kontrol edemez ya da özel anahtarınızla imzalayamaz; bu nedenle mesajı reddedilir.

Üç Politika Düzeyi Açıklandı

• p=none: İzleme modu. DMARC'ta başarısız olan mesajlar teslim edilmeye devam eder. Toplu raporlar rua adresinize gönderilir. Bu başlangıç noktasıdır; herhangi bir uygulama eylemi almadan önce size görünürlük sağlar. Kuruluşlar 30–60 günden fazla p=none'da kalmamalıdır.
• p=quarantine: DMARC'ta başarısız olan mesajlar spam/önemsiz klasörüne gönderilir. Bu, tam redde geçmeden önce hiçbir meşru postanın yakalanmadığını doğrulamanıza olanak tanıyan ara adımdır. Başlangıçta yalnızca başarısız postanın belirli bir yüzdesine karantina uygulamak için pct= parametresini kullanın.
• p=reject: DMARC'ta başarısız olan mesajlar alıcı sunucu tarafından doğrudan reddedilir. Hiçbir zaman gelen kutusuna ya da spam klasörüne ulaşmazlar. Bu, alan kimliğine bürünmeyi tam anlamıyla engelleyen tek politika düzeyidir. Google, Yahoo ve çoğu sigorta şirketi artık p=reject'i köklü alanlar için beklenen temel olarak değerlendiriyor.

Raporlama Döngüsü: Akışı Kapatmak

DMARC'ı tek seferlik bir yapılandırma değil, bir akış yapan şey, raporlama geri bildirim döngüsüdür. Her gün önde gelen sağlayıcılar —Gmail, Outlook, Yahoo, Apple Mail— rua adresinize toplu XML raporları gönderir. Bu raporlar şunları içerir:

• Gönderici IP adresleri ve hacimleri
• Her kaynak için SPF ve DKIM sonucu
• Uygulanan DMARC kararı (none, quarantine, reject)

Bu raporları analiz ederek bilinmeyen gönderici kaynaklarını keşfeder, yanlış yapılandırılmış sistemleri tespit eder ve tam uygulamaya doğru ilerlemenizi izlersiniz. Bu geri bildirim döngüsü olmadan körü körüne hareket edersiniz; politikalar yayımlanmış ama çalışıp çalışmadığı ya da meşru postaları yakalayıp yakalamadığı bilinmiyor.

DMARCFlow, bu XML raporlarını otomatik olarak ayrıştırır ve okunabilir paneller olarak sunar; yeni kaynaklar göründüğünde veya kimlik doğrulama oranları beklenmedik biçimde düştüğünde sizi uyarır.

DMARC Flow'un Güvenliğin Ötesindeki Önemi

DMARC Flow'u tamamlamak —SPF ve DKIM'den aktif izlemeyle birlikte p=reject'e kadar— kimlik avını durdurmak dışında da faydalar sağlar:

• Gelen kutusu yerleşimi: Gmail ve Yahoo'nun toplu gönderici kılavuzları (2024'ten itibaren geçerli) toplu göndericiler için p=quarantine veya daha yüksek düzey gerektiriyor. DMARC uygulaması olmayan alanlar artan spam filtrelemesiyle karşılaşıyor.
• Marka koruması: p=reject uygulandıktan sonra alanınız, müşterilerinize veya ortaklarınıza ikna edici kimlik avı e-postaları göndermek için kullanılamaz. Müşteri sahtekarlığına neden olan bir spoofing olayının itibar riski ortadan kalkar.
• Sigorta ve uyumluluk: Siber sigortacılar ve düzenleyiciler (NIS2, ISO 27001, PCI DSS v4) DMARC uygulamasını temel bir kontrol olarak değerlendiriyor. p=none'daki alanlar, sigortalama modellerinde daha yüksek riskli olarak sınıflandırılıyor.
• BIMI uygunluğu: Gmail gelen kutularında logonuzu gösteren özellik olan Brand Indicators for Message Identification, ön koşul olarak DMARC'ın p=quarantine veya p=reject düzeyinde olmasını gerektiriyor.