DMARC Raporu Nasıl Okunur? p=reject, p=quarantine, p=none Farkları

E-posta altyapınızı kimlik avı ve sahteciliğe karşı koruyan DMARC politikaları, yalnızca doğru yapılandırıldığında etkilidir. Bu rehberde DMARC raporlarını nasıl yorumlayacağınızı, p=none, p=quarantine ve p=reject politikalarının gerçek dünya etkilerini ve adım adım nasıl geçiş yapacağınızı ele alıyoruz.

DMARC Nedir ve Neden Önemlidir?

Domain-based Message Authentication, Reporting and Conformance (DMARC), RFC 7489 kapsamında standartlaştırılmış bir e-posta kimlik doğrulama çerçevesidir. SPF (RFC 7208) ve DKIM (RFC 6376) protokollerinin üzerine inşa edilen DMARC, alan adı sahiplerinin doğrulama başarısız olduğunda alıcı sunucuların nasıl davranması gerektiğini belirlemelerine olanak tanır.

Google ve Yahoo, 2024 yılı başında toplu gönderenler için DMARC kaydı zorunluluğunu resmi hale getirdi. Microsoft'un Exchange Online da benzer gereksinimler uygulamaktadır. Bu gelişmeler DMARC'ı artık yalnızca büyük kurumsal altyapıların değil, her ölçekteki işletmenin gündemine taşımıştır.

DMARC Kaydı Nasıl Görünür?

DMARC kaydı, _dmarc.alanadi.com adresinde yayımlanan bir TXT DNS kaydıdır. Örnek bir kayıt şu şekilde görünür:

v=DMARC1; p=quarantine; rua=mailto:dmarc-raporlari@alanadi.com; ruf=mailto:adli-raporlar@alanadi.com; pct=100; adkim=s; aspf=s;

Temel etiketlerin anlamları şöyledir:

• v: Sürüm. Her zaman DMARC1 olmalıdır.
• p: Politika modu. none, quarantine veya reject.
• rua: Toplu (aggregate) raporların gönderileceği adres.
• ruf: Adli (forensic) raporların gönderileceği adres.
• pct: Politikanın uygulanacağı mesaj yüzdesi (varsayılan: 100).
• adkim: DKIM hizalama modu; r (relaxed) veya s (strict).
• aspf: SPF hizalama modu; r (relaxed) veya s (strict).
• sp: Alt alan adları için alt politika.

p=none, p=quarantine ve p=reject: Temel Farklar

DMARC politika modları, RFC 7489'un 6.3. bölümünde tanımlanmıştır. Her birinin alıcı sunucu davranışı ve operasyonel riski birbirinden önemli ölçüde farklıdır.

p=none: Görünürlük, Koruma Değil

p=none politikası, DMARC'ı aktif olarak uygulamaz; yalnızca raporlama etkinleştirir. DMARC doğrulamasında başarısız olan bir ileti, normal şekilde alıcının gelen kutusuna ulaşır. Bu mod, yeni bir alan adı yapılandırmasında hangi göndericilerin SPF veya DKIM doğrulamasında başarısız olduğunu tespit etmek için idealdir. Ancak uzun süre bu modda kalmak, alan adınızı sahteciliğe karşı savunmasız bırakır.

p=quarantine: Geçiş Modeli

p=quarantine politikası, DMARC doğrulamasında başarısız olan iletileri alıcının spam ya da önemsiz klasörüne yönlendirmesini tavsiye eder. "Tavsiye" kelimesi önemlidir: alıcı sunucu bu yönlendirmeyi zorunlu uygulamaz, ancak Google, Microsoft ve büyük ESP'lerin büyük çoğunluğu bu talebi onurlandırır. pct etiketi ile politikayı kademeli olarak, örneğin önce pct=10, ardından pct=50 şeklinde genişletebilirsiniz.

p=reject: Tam Uygulama

p=reject, DMARC'ın en güçlü politika modudur. Doğrulama başarısız olan iletiler, alıcı sunucu tarafından SMTP 550 5.7.1 veya benzeri bir 5xx hata koduyla reddedilir; ileti ne teslim edilir ne de spam klasörüne düşer. Bu mod, alan adınızın e-posta kimlik avı saldırılarında kötüye kullanılmasını en etkili biçimde engeller. Ancak SPF ve DKIM altyapınız eksiksiz yapılandırılmadan p=reject'e geçilmesi, meşru iletilerin de reddedilmesine yol açabilir.

DMARC Aggregate (RUA) Raporu Nasıl Okunur?

Aggregate raporlar, alıcı alan adları tarafından günlük olarak XML formatında gönderilir. Google, Microsoft, Yahoo ve diğer büyük posta sağlayıcıları bu raporları standart biçimde iletir. Ham XML oldukça ayrıntılı görünse de yapısı anlaşıldığında son derece bilgilendiricidir.

Bir RUA raporunun temel bölümleri şunlardır:

• <report_metadata>: Raporu gönderen kuruluş, rapor kimliği ve kapsadığı tarih aralığı.
• <policy_published>: Raporlama döneminde yayımlanan DMARC politikanızın anlık görüntüsü.
• <record>: Her kayıt, belirli bir kaynak IP'den gelen iletiler için SPF ve DKIM sonuçlarını gösterir.

Her <record> içindeki <row> elemanı, kaynak IP, mesaj sayısı ve politika değerlendirme sonucunu (pass, fail, softfail) içerir. <auth_results> bölümü ise ham SPF ve DKIM sonuçlarını listeler.

Büyük hacimli raporları manuel olarak işlemek yerine dmarcian, Valimail, PowerDMARC veya açık kaynaklı parsedmarc gibi araçları kullanabilirsiniz. Google Postmaster Tools da alan adınıza yönelik kimlik doğrulama hatalarını görsel olarak takip etmenizi sağlar.

SPF ve DKIM Hizalaması: DMARC'ın Kritik Mekanizması

DMARC doğrulaması yalnızca SPF veya DKIM'nin geçmesiyle değil, aynı zamanda bu sonuçların RFC 5321'de tanımlanan envelope from ya da RFC 6376'da belirtilen DKIM d= değerinin, RFC 5322'deki Header From alan adıyla hizalanmasıyla ilgilenir. Hizalama iki modda çalışır:

• Relaxed (r): Alan adı ve üst alan adı eşleşmesi yeterlidir. Örneğin mail.alanadi.com, alanadi.com ile hizalanmış sayılır.
• Strict (s): Tam eşleşme gereklidir. mail.alanadi.com, alanadi.com ile hizalanmış sayılmaz.

Üçüncü taraf e-posta servislerini (CRM, pazarlama otomasyonu, destek sistemleri) kullanıyorsanız, bu servislerin gönderdiği iletilerin de sizin alan adınız üzerinden doğru SPF ve DKIM yapılandırmasına sahip olduğunu doğrulamanız kritik önem taşır.

Güvenli Geçiş: none → quarantine → reject

RFC 7489'un yazarları ve Google, Microsoft gibi büyük posta sağlayıcıları, kademeli geçişi şiddetle tavsiye eder. Önerilen süreç şu şekilde işlemelidir:

1. Keşif (2–4 hafta): p=none ile başlayın, RUA raporlarını toplayın, tüm gönderici kaynaklarını (envelope from ve DKIM imzalayanlar dahil) belgeleyin.
2. SPF/DKIM Temizliği: Tüm meşru gönderici IP'lerini SPF kaydına ekleyin; üçüncü taraf servislerde DKIM imzalamayı etkinleştirin.
3. Kademeli Quarantine (2–4 hafta): p=quarantine; pct=10 ile başlayın. Hiçbir meşru iletinin spam'e düşmediğini doğruladıktan sonra pct=50, ardından pct=100'e yükseltin.
4. Tam Uygulama: p=reject; pct=100'e geçin ve RUA raporlarını izlemeye devam edin.

Sık Sorulan Sorular