DMARC Politikaları Nelerdir? p=none, p=quarantine, p=reject
DMARC (Domain-Based Message Authentication, Reporting, and Conformance) kaydındaki p değeri, e-posta uygulamasında görünen From (Gönderen) alanındaki alan adıyla gönderildiği iddia edilen bir ileti DMARC doğrulamasından geçemediğinde alan adı sahibinin alıcıdan nasıl davranmasını istediğini belirtir. p=none belirli bir teslimat işlemi istemez, p=quarantine iletinin şüpheli kabul edilmesini, p=reject ise iletinin reddedilmesini talep eder.
Bu politikalar tek başına gönderen sunucunun bir alan adı adına posta gönderme yetkisini denetleyen SPF (Sender Policy Framework) veya iletiyi alan adıyla ilişkilendirilmiş kriptografik imzayla doğrulayan DKIM (DomainKeys Identified Mail) sonucuna göre çalışmaz. DMARC, görünen From alan adıyla SPF ya da DKIM tarafından doğrulanan alan adı arasında hizalama arar; hizalanmış yöntemlerden en az biri başarılıysa DMARC sonucu başarılı olur.
Politika değeri, alan adı sahibinin alıcı posta sistemine ilettiği bir taleptir; zorunlu bir teslimat komutu değildir. Alıcı posta sistemi kendi güvenlik kuralları, itibar verileri ve yerel politikası nedeniyle farklı bir işlem uygulayabilir.
Sözdizimi bakımından geçerli bir DMARC kaydında p etiketi bulunmuyorsa alıcı p=none varmış gibi işlem yapar; bu varsayım için toplu rapor hedeflerini belirten rua etiketinin bulunması gerekmez.
DMARC Başarısızlığında Politika Ne Zaman Uygulanır?
DMARC değerlendirmesinin merkezinde görünen From alan adı bulunur. SPF, SMTP oturumunda bağlantıyı kuran IP adresinin MAIL FROM adresindeki alan adı adına gönderim yetkisini denetler. DKIM ise imzanın d= etiketindeki alan adını dijital imza üzerinden doğrular. DMARC, bu doğrulanmış kimliklerden en az birinin görünen From alan adıyla kabul edilen hizalama kurallarına uymasını bekler.
SPF başarısızken hizalanmış bir DKIM imzası geçerliyse ileti DMARC'tan geçebilir. Aynı şekilde DKIM başarısız olsa bile hizalanmış SPF sonucu başarılıysa DMARC başarılı olabilir. Politika ancak iki yoldan da hizalanmış başarı elde edilemediğinde, yani DMARC sonucu başarısız olduğunda anlam kazanır.
Yalnız SPF ya da DKIM sonucunun başarısız olduğunu görmek, p değerinin uygulanacağı anlamına gelmez. Alıcı, politika kararından önce doğrulama sonucunu ve alan adı hizalamasını birlikte değerlendirir. DMARC için gerekli DNS sorguları hata nedeniyle tamamlanamazsa ileti DMARC denetiminden geçmiş veya kalmış sayılmaz; alan sahibinin politikası bu durumda uygulanamaz. Alıcı diğer yerel kurallarıyla karar verir.
p=none: İzleme ve Kaynak Envanteri
p=none, alan adı sahibinin DMARC başarısızlığına dayanarak özel bir karantina veya ret işlemi istemediğini belirtir. Alıcı iletiyi kendi spam filtreleri, itibar değerlendirmesi ve diğer güvenlik sinyalleriyle işlemeye devam eder. Bu nedenle p=none, başarısız iletinin mutlaka gelen kutusuna teslim edileceği anlamına gelmez.
Bu politika genellikle meşru gönderim kaynaklarını belirlemek, hangi hizmetlerin hizalanmış SPF veya DKIM kullanmadığını görmek ve daha sıkı bir politikaya geçmeden önce hataları düzeltmek için seçilir. Alıcı posta sistemi DMARC doğrulamasını yapmayı sürdürür; ancak alan adı sahibi karantina veya ret işlemi talep etmez.
p=none uzun süre değişmeden bırakılırsa alıcıya alan adı sahibi adına başarısız iletileri engelleme talebi iletilmez. Buna karşılık doğrulanmamış bir ortamda doğrudan karantina veya ret politikasına geçmek de meşru iletilerin kaybına yol açabilir. Kullanım süresi, gönderim altyapısının ne kadar iyi bilindiğine ve raporlama bulgularının ne kadar düzenli incelendiğine bağlıdır.
p=quarantine: Şüpheli Olarak İşleme Talebi
p=quarantine, DMARC'tan geçemeyen iletilerin normal ve güvenilir posta gibi işlenmemesini ister. Alıcı sistem iletiyi istenmeyen e-posta klasörüne taşıyabilir, iletiye uyarı ekleyebilir veya ek filtrelerden geçirebilir. Karantinanın nasıl uygulandığı, alıcı posta sisteminin güvenlik ve teslim kurallarına göre değişir.
p=quarantine, p=none sonrasında kontrollü yaptırım başlatmak için kullanılabilir. Sahte gönderimlere karşı daha belirgin bir tercih bildirirken yanlış yapılandırılmış meşru akışların tamamen reddedilmeden fark edilmesine olanak tanıyabilir. Ancak bazı alıcılar karantinayı sert biçimde uygulayabileceği için teslimat etkisi yine ciddi olabilir.
Özellikle destek sistemi, pazarlama platformu, faturalama hizmeti veya üçüncü taraf gönderici kullanan alan adlarında hizalama eksikleri önce giderilmelidir. Meşru bir kaynak DMARC'tan geçemiyorsa p=quarantine sonrasında iletiler kullanıcıların ana gelen kutularında görünmeyebilir ve iş süreçleri gecikebilir.
p=reject: Teslimatı Reddetme Talebi
p=reject, DMARC başarısızlığı için en katı alan adı sahibi talebidir. Alıcıdan, iletiyi kabul etmek yerine reddetmesi istenir; standart yaklaşım ret kararının SMTP oturumu sırasında verilmesidir. Bu yöntem, alıcının iletiyi kabul ettikten sonra sahte zarf göndereni adresine hata bildirimi yollayıp ilgisiz bir posta kutusunu bildirimlerle doldurmasını önlemeye yardımcı olur.
Bu politikaya geçmeden önce bütün meşru gönderim kaynaklarını belirleyip doğrulama sonuçlarını sınayın. RFC 9989, p=reject kullanan alan sahiplerinin DMARC başarısı için yalnız SPF’ye güvenmesini yasaklar; meşru gönderimlerde görünen From alan adıyla hizalı DKIM imzası da kullanılmalıdır. Aksi halde unutulmuş bir uygulama, eski bir sunucu veya yanlış alan adıyla imza atan bir hizmet meşru iletilerin reddedilmesine neden olabilir. Posta listelerine ileti gönderen kullanıcı hesaplarının bulunduğu alan adlarında p=reject önerilmez; böyle bir politikadan önce liste trafiğine etkisi ayrıca incelenmelidir.
p=reject de mutlak bir komut değildir. Alıcı bilinen bir yönlendirme akışı, güvenilir gönderici ilişkisi, kullanıcı tercihi veya başka yerel değerlendirmeler nedeniyle iletiyi kabul edebilir. Tersi yönde, p=none kullanılan bir alan adından gelen ileti de diğer güvenlik kontrolleri nedeniyle reddedilebilir.
p=none, p=quarantine ve p=reject Arasındaki Farklar
Aşağıdaki karşılaştırma, üç değerin yalnız DMARC başarısızlığı sonrasındaki alan adı sahibi talebini nasıl değiştirdiğini gösterir. Gerçek teslimat sonucu her durumda alıcının kendi politikasından etkilenir.
| Politika | Alan Adı Sahibinin Talebi | Muhtemel Alıcı İşlemi | Uygun Geçiş Aşaması | Meşru Posta Riski |
|---|---|---|---|---|
| p=none | DMARC başarısızlığına özel işlem istemez | Normal filtreleme ve yerel değerlendirme | Kaynak keşfi ve izleme | Politikadan kaynaklanan risk düşüktür, ancak sahte iletiler için yaptırım talebi yoktur |
| p=quarantine | İletiyi şüpheli kabul etmesini ister | İstenmeyen e-posta klasörü, uyarı veya ek denetim | Kontrollü yaptırım | Hizalanmamış meşru iletiler ana gelen kutusunda görünmeyebilir |
| p=reject | İletiyi kabul etmemesini ister | SMTP sırasında ret veya teslim etmeme | Meşru kaynakların doğrulandığı, hizalı DKIM imzalarının kullanıldığı yapı | Hizalanmamış meşru iletiler reddedilebilir |
Kademeli Politika Geçişi Nasıl Planlanır?
Kademeli geçiş, yalnız p değerini değiştirmekten ibaret değildir. Yaptırım güçlenmeden önce alan adını kullanarak gönderim yapan bütün meşru kaynaklar tanımlanmalı ve her kaynağın en az bir hizalanmış doğrulama yoluna sahip olduğu kanıtlanmalıdır.
- Kurumsal posta sunucularını, bulut posta hizmetlerini, bülten sistemlerini, destek uygulamalarını ve otomatik bildirim kaynaklarını envantere alın.
- Her kaynak için görünen From alan adıyla hizalı SPF veya DKIM doğrulamasını sınayın; p=reject planlıyorsanız yalnız SPF başarısını yeterli saymayın ve hizalı DKIM imzasını doğrulayın.
- p=none döneminde beklenmeyen kaynakları ve başarısızlıkları izleyin; meşru gönderimlerdeki hataları düzeltin.
- p=quarantine ile kontrollü yaptırım başlatın; kullanıcı şikayetlerini, teslimat hatalarını ve gönderim kayıtlarını izleyin.
- Kritik iletilerin tutarlı biçimde DMARC denetiminden geçtiğini doğruladıktan sonra p=reject politikasına geçişi ve posta listelerine olası etkisini değerlendirin.
Eski DMARC standardı RFC 7489’daki pct etiketi, politikanın yalnız belirli bir ileti yüzdesine uygulanmasını istiyordu; ancak uygulamalar arasındaki büyük farklar nedeniyle Mayıs 2026’da yayımlanan RFC 9989’dan kaldırıldı. Güncel standarttaki t=y test bayrağı, p=quarantine politikasını p=none, p=reject politikasını da p=quarantine düzeyinde değerlendirme isteği iletir. Bu bayrak, hatalı gönderim kaynaklarını düzeltmenin ve sonuçları izlemeyi sürdürmenin yerini tutmaz.
Politika değişikliği yayımlandıktan sonra bütün alıcıların aynı anda yeni değeri kullanması beklenmemelidir. DNS önbellekleri ve kayıtların yenilenme süreleri nedeniyle eski değer bir süre daha görülebilir. Değerlendirme, farklı gönderim kaynaklarından yeterli sayıda ileti görüldükten ve DNS önbellekleri yenilendikten sonra yapılmalıdır.
Geçiş sırasında SMTP ret kayıtları, teslim edilememe bildirimleri, iletilerin istenmeyen e-posta klasörüne düşmesiyle ilgili kullanıcı şikayetleri ve üçüncü taraf gönderim hizmetlerinin hata günlükleri birlikte izlenmelidir. Politika değişikliğinden sonra belirli bir kaynaktaki sorunların artması hizalama eksikliğine işaret edebilir; ancak alıcı filtrelerindeki veya gönderici itibarındaki değişiklikler de sonucu etkileyebileceğinden tek bir belirtiyle kesin karar verilmemelidir.
Alıcının Yerel Politikası Nihai Sonucu Neden Değiştirir?
DMARC politikası, gönderen alan adı sahibinin yayımladığı işleme isteğidir. Alıcı posta sistemi kendi kötüye kullanım verileri, kullanıcı tercihleri, izin listeleri, yönlendirme bilgileri ve operasyonel kuralları doğrultusunda bu isteği aynen uygulayabilir veya farklı bir karar verebilir.
Bu nedenle DMARC'tan geçemeyen aynı ileti bir alıcıda istenmeyen e-posta klasörüne düşerken başka bir alıcıda reddedilebilir ya da özel koşullarda kabul edilebilir. Gönderen taraf p=quarantine ile belirli bir klasörü, p=reject ile de her alıcıda kesin ret sonucunu zorlayamaz.
RFC 9989’a göre alıcı, yalnız p=reject politikasına dayanarak iletiyi reddetmemeli; gönderim geçmişi, içerik ve diğer güvenlik verilerini de değerlendirmelidir. Ek bilgi veya analiz yoksa başarısız iletiyi p=quarantine uygulanıyormuş gibi ele almalıdır.
Hizalama Hataları ve Yönlendirme Meşru İletileri Nasıl Etkiler?
En sık risk, alan adını kullanarak gönderim yapan bir hizmetin unutulmasıdır. Müşteri ilişkileri sistemi, destek masası, personel yönetimi uygulaması, muhasebe platformu veya web formu farklı bir altyapıdan posta gönderiyor olabilir. Bu kaynaklardan biri hizalanmış doğrulama sağlayamıyorsa politika sıkılaştığında gerçek iletiler karantinaya alınabilir veya reddedilebilir.
- İletinin yönlendirilmesi SPF değerlendirmesini bozabilir çünkü alıcıya bağlanan sunucu değişir.
- İleti gövdesi ya da imzalanmış başlıklar aktarım sırasında değiştirilirse DKIM imzası geçersiz olabilir.
- Üçüncü taraf hizmet farklı bir alan adıyla DKIM imzalarsa imza geçerli olsa bile DMARC hizalaması oluşmayabilir.
- Meşru bir gönderim hizmetinin From adresinde kurumsal alan adı kullanılırken SPF veya DKIM başka bir alan adını doğruluyorsa hizalama sağlanmayabilir.
Bu sorunlar, yalnız SPF kaydını genişleterek veya yalnız DKIM'i etkinleştirerek her durumda çözülmez. Her gönderim akışında hangi kimliğin doğrulandığı, bu kimliğin görünen From alan adıyla hizalanıp hizalanmadığı ve alıcının gerçek DMARC sonucunun ne olduğu birlikte kontrol edilmelidir.
