DMARC Politikası Seçimi: none, quarantine, reject

DMARC kaydını p=none ile yayınladın, raporlar gelmeye başladı ve şimdi asıl soruyla karşı karşıyasın: ne zaman ve nasıl sıkılaştıracaksın? DMARC politikası seçimi, mail altyapısındaki en riskli tek karardır — çünkü reject yazdığın anda hizalanmamış her sistemin maili sessizce yok olmaya başlar ve bunu genellikle bir müşteri "faturayı alamadım" dediğinde fark edersin. Öte yandan sonsuza kadar p=none kalmak da bir çözüm değil; o politikanın hiçbir koruyucu etkisi yoktur, yalnızca rapor toplar.

Bu rehberde üç politika değerinin ne yaptığını, aralarındaki geçişin nasıl planlanacağını, pct, sp, adkim ve aspf etiketlerinin geçişi nasıl yumuşattığını ve tipik olarak hangi sistemlerin kırıldığını anlatacağım. Sonunda elinde, alan adını haftalar içinde reject seviyesine taşıyacak somut bir plan olacak. Baştan söyleyeyim: acele etme, ama durma da.

DMARC Politikası Ne Yapar#

DMARC, SPF ve DKIM sonuçlarının üzerine iki şey ekler: hizalama kontrolü ve politika beyanı. Hizalama, kullanıcının gördüğü From başlığındaki alan adının, SPF'in doğruladığı zarf alan adıyla ya da DKIM imzasının alan adıyla eşleşmesini şart koşar. Politika ise "bu kontrol başarısız olursa ne yapmanı istiyorum" cevabıdır.

Kritik nokta şudur: SPF ya da DKIM'den birinin hizalı biçimde geçmesi yeterlidir. İkisinin de geçmesi gerekmez. Bu esneklik, yönlendirme gibi SPF'i kaçınılmaz olarak kıran senaryolarda hayat kurtarır.

; Tipik bir DMARC kaydı
_dmarc.firmaniz.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; pct=100; adkim=r; aspf=r"

Politikanın alıcı tarafında bir talep olduğunu unutma, bir zorunluluk değil. Büyük sağlayıcılar bu talebe büyük ölçüde uyar ama nihai karar onlarındır; p=reject yazman, hiçbir sahte mailin asla ulaşmayacağı anlamına gelmez. Yine de pratikte etkisi çok yüksektir ve alan adın adına yapılan sahtecilik girişimlerinin ezici çoğunluğunu durdurur. Sahtecilik savunmasının bütününü e-posta spoofing önleme yazısında ele almıştım.

Üç Politika Değeri Karşılaştırması#

p=none hiçbir koruma sağlamaz. Tek işlevi rapor akışını başlatmaktır ve bu değerli bir işlevdir — hangi sistemlerin senin adına mail gönderdiğini ancak bu raporlardan öğrenirsin. Ama burada kalıcı olarak durmak, alarmı kurup hiç kurmamak gibidir.

p=quarantine ara duraktır. Başarısız mail spam klasörüne düşer, yani hâlâ bulunabilir. Bir sistemi yanlışlıkla kırdıysan kullanıcı maili Junk'ta bulur ve sana haber verir. Bu geri bildirim döngüsü, reject'te tamamen yoktur.

p=reject hedeftir. Başarısız mail teslim edilmez ve gönderen bir bounce alır. Sahteciliğe karşı gerçek koruma budur ve BIMI gibi ileri özellikler de bunu ya da quarantine'i şart koşar; ayrıntısı BIMI kaydı nedir yazısında.

Sık sorulan bir soruya baştan cevap vereyim: quarantine'de kalıcı olarak durmak da eksik bir çözümdür. Kimlik avı maili spam klasöründe olsa bile bir kullanıcı onu açabilir ve senin markanın adı o mailin üzerindedir.

Kademeli Geçiş Planı#

Aşağıdaki plan, birkaç yüz kullanıcılı tipik bir kurumda altı ila sekiz haftada tamamlanır. Aceleye getirmek, atlanan her adımın bedelini kayıp mail olarak ödetir.

1. Hafta 1-2 — Gözlem. p=none; rua=... yayınla ve raporları topla. Hiçbir şeyi değiştirme, sadece izle.
2. Hafta 2-3 — Envanter. Raporlardan senin adına mail gönderen tüm sistemleri listele: mail sunucun, CRM, fatura yazılımı, form bildirimi, pazarlama aracı, izleme sistemleri. Genellikle beklediğinden fazla çıkar.
3. Hafta 3-4 — Hizalama. Her sistem için SPF include kaydını ekle ve mümkünse DKIM imzalamayı aç. Hedef: her akışta ya SPF ya DKIM hizalı geçsin.
4. Hafta 5 — Kısmi quarantine. p=quarantine; pct=25 yayınla. Trafiğin dörtte biri politikaya tabi olur; sorun çıkarsa etkisi sınırlı kalır.
5. Hafta 6 — Tam quarantine. Sorun görülmediyse pct=100 yap ve bir hafta daha izle.
6. Hafta 7-8 — Reject. Raporlarda hizalanmamış meşru akış kalmadıysa p=reject yayınla.

Her adımdan sonra raporları oku; okumadan bir sonraki adıma geçme. Rapor okumanın pratiğini DMARC raporu nasıl okunur yazısında ayrıntılı anlattım — özellikle hangi kaynak IP'nin hangi akışa ait olduğunu eşleştirme kısmı bu geçişin can damarıdır.

; Hafta 5 — kısmi uygulama
_dmarc.firmaniz.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

; Hafta 8 — hedef durum
_dmarc.firmaniz.com.  3600  IN  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:[email protected]; sp=reject"

pct, sp ve Hizalama Etiketleri#

Geçişi yumuşatan asıl araçlar bu üç etikettir ve çoğu kişi ikisini hiç kullanmadan doğrudan sıkılaştırır.

pct politikanın trafiğin yüzde kaçına uygulanacağını belirler. pct=25 yazdığında alıcı, başarısız maillerin kabaca dörtte birine politikayı uygular, kalanını bir alt seviyeye düşürür. Bu, bir hatanın etkisini dörde bölmenin en kolay yoludur. Not: pct yalnızca quarantine ve reject için anlamlıdır ve BIMI kullanacaksan sonunda 100 olmalıdır.

sp alt alan adları için ayrı bir politika tanımlar. Belirtmezsen alt alan adları ana politikayı miras alır. Bu genellikle istediğin şeydir ama bir alt alan adından (örneğin bildirim.firmaniz.com) henüz hizalanmamış bir sistem mail gönderiyorsa, ana alan adını reject yaparken alt alanı geçici olarak sp=none bırakabilirsin.

adkim ve aspf hizalama katılığını belirler. Varsayılan r (relaxed), organizasyon alan adı düzeyinde eşleşmeyi yeterli sayar: posta.firmaniz.com ile firmaniz.com hizalı kabul edilir. s (strict) ise birebir eşleşme ister.

Geçiş sırasında adkim ve aspf değerlerini r bırak. s yapmak, alt alan adlarından gönderen sistemleri bir anda kırar ve kazandırdığı ek güvenlik çoğu kurumda bu riski karşılamaz.

Geçişte Kırılan Tipik Sistemler#

Envanter çıkarırken şu listeyi bir kontrol listesi olarak kullan; deneyimime göre unutulan sistemler hemen her zaman buradan çıkar.

• Fatura ve muhasebe yazılımı. Kendi SMTP sunucusundan [email protected] adına mail atar, DKIM imzası yoktur.
• Web sitesi form bildirimleri. PHP mail() fonksiyonu, From başlığına ziyaretçinin adresini yazar — bu hem hizalamayı bozar hem de baştan yanlış bir tasarımdır.
• CRM ve destek sistemleri. Kendi altyapılarından gönderirler; SPF include ve DKIM anahtarı eklemen gerekir.
• Pazarlama aracı. Genellikle kendi alt alan adını kullanır ama From adresi ana alan adı olabilir.
• İzleme ve yedekleme sistemleri. Sunucudaki cron mailleri, uyarı bildirimleri; kimse bunları düşünmez ama reject'te ilk kaybolanlar bunlardır.
• Otomatik yönlendirmeler. Kullanıcıların kurduğu Gmail'e yönlendirmeler SPF'i kırar; DKIM sağlamsa sorun olmaz, mail değiştiriliyorsa olur.

Form bildirimleri için doğru çözüm şudur: From başlığına kendi alan adını yaz, ziyaretçinin adresini Reply-To başlığına koy.

# Yanlış — From başlığında ziyaretçinin adresi
From: [email protected]
To: [email protected]

# Doğru — From kendi alan adın, cevap ziyaretçiye gider
From: [email protected]
Reply-To: [email protected]
To: [email protected]

Yönlendirme kaynaklı kırılmalar için ARC devreye girebilir ama bu, yönlendiren tarafın uygulaması gereken bir çözümdür; nasıl çalıştığını ARC imzası nedir yazısında anlattım.

Doğrulama ve İzleme#

Her politika değişikliğinden sonra kaydın yayına girdiğini ve beklediğin sonucu ürettiğini doğrula.

# Kaydın güncel hâlini oku
dig _dmarc.firmaniz.com TXT +short
# "v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]"

# Alt alan adı için ayrı kayıt var mı (varsa ana politikayı ezer)
dig _dmarc.bildirim.firmaniz.com TXT +short

# Kendine test maili at ve sonucu başlıklarda gör
# Beklenen satır:
# Authentication-Results: mx.hedef.com;
#   spf=pass smtp.mailfrom=firmaniz.com;
#   dkim=pass header.d=firmaniz.com;
#   dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=firmaniz.com

İzlemede bakacağın tek sayı, raporlardaki hizalanmamış meşru trafik oranıdır. Sahte trafiğin başarısız olması iyi bir haberdir, o zaten hedefin. Kendi sistemlerinden birinin başarısız olması ise düzeltmen gereken bir eksiktir. Bu ikisini ayırt etmenin yolu, rapordaki kaynak IP'yi kendi envanterinle eşleştirmektir.

pct değerini artırmadan önce en az bir hafta temiz rapor görmelisin. "Temiz" derken sıfır başarısızlık kastetmiyorum — sahte trafik her zaman olacak — kendi sistemlerinden hiçbirinin listede olmaması gerekir.

Sık Yapılan Hatalar#

1. Doğrudan p=reject ile başlamak. Envanter çıkarmadan atılan bu adım, hangi sistemin kırıldığını bilmeden mail kaybetmek demektir.
2. rua adresini tanımlamamak. Rapor gelmeyen bir DMARC kaydı kör uçuştur; p=none bile anlamsızlaşır.
3. Sonsuza kadar p=none kalmak. En yaygın hata budur. Kayıt vardır, koruma yoktur ve kurum kendini güvende sanır.
4. Alt alan adı kaydını unutmak. Bir alt alan adında ayrı _dmarc kaydı varsa ana politikayı ezer; envantere onu da dâhil et.
5. adkim=s ile başlamak. Katı hizalama, alt alan adlarından gönderen tüm sistemleri bir anda kırar.
6. Raporları okumadan adım atmak. Her adım arasında en az bir haftalık rapor okuması olmalı; aksi hâlde plan sadece takvimdir, ölçüm değil.

Sıkça Sorulan Sorular#

DMARC politikasını doğrudan reject yapabilir miyim#

Teknik olarak yapabilirsin ama şiddetle önermem. Kurumların büyük çoğunluğunda, kimsenin hatırlamadığı en az bir sistem kendi adına mail gönderir — fatura yazılımı, izleme uyarıları, bir form bildirimi. reject yazdığın anda o maillerin hepsi sessizce yok olur ve bunu ancak biri "gelmedi" dediğinde fark edersin. En az iki hafta p=none ile rapor toplayıp envanter çıkarmadan sıkılaştırma.

quarantine ile reject arasındaki fark pratikte ne kadar önemli#

Fark, mailin bulunabilir olup olmamasıdır. quarantine başarısız maili spam klasörüne düşürür; kullanıcı arayıp bulabilir ve sana "bu neden Junk'ta" diye haber verebilir. reject ise maili hiç teslim etmez, gönderen bir bounce alır. Geçiş aşamasında quarantine bu geri bildirim döngüsü sayesinde çok değerlidir; hedef durum olarak ise reject daha güçlü koruma sağlar.

pct etiketi tam olarak nasıl çalışır#

pct, politikanın başarısız maillerin yüzde kaçına uygulanacağını belirtir. pct=25 yazdığında alıcı sunucular, DMARC kontrolünden geçemeyen maillerin kabaca dörtte birine ilan ettiğin politikayı uygular, kalanını bir alt seviyede işler. Bu, bir yapılandırma hatasının etkisini sınırlamak için tasarlanmış bir emniyet valfidir. Geçiş tamamlandığında 100 yapmalısın; BIMI kullanacaksan bu zaten zorunludur.

DMARC reject yaptım, mailler kaybolmaya başladı, ne yapmalıyım#

İlk iş politikayı geri almaktır: kaydı p=none ya da p=quarantine; pct=25 seviyesine düşür, DNS TTL'i kadar bekle. Ardından raporları açıp hangi kaynak IP'lerin ve hangi alan adlarının başarısız olduğunu tespit et; kayıp mailler neredeyse her zaman envantere alınmamış bir sistemden gelir. O sistemi SPF ve DKIM ile hizaladıktan sonra kademeli geçişi baştan başlat.

DMARC kaydı olmadan mail gönderemez miyim#

Gönderebilirsin, DMARC zorunlu değildir. Ancak büyük sağlayıcılar toplu gönderim yapan alan adlarından DMARC kaydı beklemeye başladı ve kaydı olmayan gönderenlerin teslimat oranı belirgin biçimde düşük. Ayrıca DMARC olmadan senin alan adın adına sahte mail gönderilmesini engelleyecek hiçbir mekanizma yoktur. En azından p=none ile başlayıp rapor toplamanı öneririm.

Alt alan adları için ayrı politika şart mı#

Şart değildir; sp etiketini belirtmezsen alt alan adları ana politikayı miras alır ve çoğu kurumda istenen davranış budur. Ayrı politika, yalnızca bir alt alan adından henüz hizalanmamış bir sistem mail gönderdiğinde işe yarar: ana alan adını reject yaparken o alt alanı geçici olarak sp=quarantine bırakabilirsin. Bu bir ara çözümdür, kalıcı bir yapılandırma olarak düşünme.

Kapanış#

DMARC politikası seçimi bir teknik ayar değil, bir proje yönetimi işidir. Aklında kalması gereken dört alışkanlık: p=none ile başla ama orada kalma, envanteri raporlardan çıkar ve tahminle çalışma, pct etiketini emniyet valfi olarak kullan ve her adım arasında en az bir hafta rapor oku. Sıkılaştırmadan önce bakacağın tek sayı, kendi sistemlerinden kaç tanesinin hâlâ hizalanmamış olduğudur; o sayı sıfır olduğunda reject risksiz hâle gelir.

Bu geçişi sağlıklı yürütmek için gönderim tarafında kontrol sahibi olman işini kolaylaştırır. Kendi posta sunucunu kurup DKIM imzalamayı yönetmek istiyorsan VDS paketlerimizde tam root erişimin olur; DKIM anahtarı üretilmiş, rDNS kaydı tanımlanmış hazır bir gönderim altyapısı istersen SMTP sunucu paketlerimize bakabilirsin. Toplu gönderim yapıyorsan e-posta pazarlama, yalnızca kurumsal posta kutusu istiyorsan kurumsal e-posta çözümümüz uygun başlangıç noktalarıdır.