Kısaca özet
- DMARC politikası, SPF ve DKIM denetiminden geçemeyen ve alan adınızı gönderen olarak gösteren e-postalara alıcı sunucunun ne yapmasını istediğinizi söyleyen DNS kaydıdır.
- p=none yalnız izler ve rapor toplar, p=quarantine başarısız iletiyi spam klasörüne yönlendirir, p=reject iletiyi hiç kabul ettirmez.
- Doğrudan p=reject ile başlamak, kendi faturalama sisteminiz ya da bülten aracınız gibi meşru gönderenlerin e-postalarını da kaybettirebilir.
- Doğru sıra, p=none ile rua raporlarını birkaç hafta okumak, tüm meşru kaynakları hizalamak, sonra quarantine ve reject’e geçmektir.
- Google, günde 5.000’den fazla ileti gönderenlerden DMARC kaydı istiyor; bu gönderenler için en az p=none yeterli sayılıyor.
- DMARC’ın güncel standardı Mayıs 2026’da yayımlanan RFC 9989’dur; RFC 7489’u geçersiz kıldı ve pct etiketini tarihsel kabul etti.
SPF ve DKIM kayıtlarını kurdunuz, ama e-posta kontrol araçları hâlâ “DMARC politikası zayıf” uyarısı veriyor. Kaydı eklemek iki dakika sürüyor; asıl soru p değerinin ne olacağı. p=reject en güvenlisi gibi görünüyor, fakat yanlış zamanda açıldığında müşterilere giden faturalar, iletişim formundan gelen bildirimler ve bülten gönderimleri sessizce kaybolabiliyor. Üç politika arasındaki fark teknik olarak basit; zor olan geçişi kimseyi kesintiye uğratmadan yapmak.
DMARC Politikası Ne İşe Yarar
SPF, iletiyi gönderen sunucunun alan adınız adına göndermeye yetkili olup olmadığını denetler. DKIM, iletinin yolda değişmediğini ve imzalayan alan adını doğrular. İkisinin de ortak eksiği, okuyucunun gördüğü “Kimden” adresine doğrudan bağlı olmamalarıdır. Dolandırıcı, kendi alan adıyla SPF’den geçip “Kimden” alanına sizin adresinizi yazabilir.
DMARC bu boşluğu hizalama (alignment) kuralıyla kapatır. İletinin DMARC’tan geçmesi için SPF veya DKIM’in başarılı olması yetmez; başarılı olan denetimin alan adı, “Kimden” adresindeki alan adıyla eşleşmelidir. DMARC politikası da bu denetim başarısız olduğunda alıcıdan ne istediğinizi söyler. Standart, RFC 9989 numarasıyla Mayıs 2026’da yayımlandı ve 2015 tarihli RFC 7489’un yerini aldı.
Bilgi
DMARC kaydı alan adınızın DNS bölgesine, _dmarc adlı bir TXT kaydı olarak eklenir. En sade hâli v=DMARC1; p=none; rua=mailto:[email protected] şeklindedir. cPanel Zone Editor’da kaydın adım adım nasıl ekleneceği DMARC kaydı oluşturma rehberinde anlatılıyor.
p=none, quarantine ve reject Farkı
Üç değer, alıcı sunucuya verdiğiniz üç farklı talimattır. Hiçbiri alıcıyı zorlamaz; alıcı kendi politikasıyla birlikte değerlendirir. Yine de büyük e-posta sağlayıcıları bu talimata büyük ölçüde uyar.
| Politika | Başarısız iletiye ne olur | Ne zaman kullanılır | Risk |
|---|---|---|---|
| p=none | Olağan şekilde teslim edilir, yalnız raporlanır | Başlangıçta, gönderen kaynakları keşfederken | Sahte iletiye karşı koruma sağlamaz |
| p=quarantine | Spam veya karantina klasörüne gider | Meşru kaynaklar hizalandıktan sonra ara adım | Yanlış yapılandırılmış meşru ileti spama düşer |
| p=reject | Alıcı sunucu iletiyi kabul etmez | Raporlar temiz, tüm kaynaklar hizalı olduğunda | Hata varsa meşru ileti tamamen kaybolur |
Bunlara ek olarak sp etiketi alt alan adları için ayrı politika tanımlar. RFC 9989 ile gelen np etiketi ise var olmayan alt alan adları için politika belirler; “fatura.alanadiniz.com” gibi hiç kullanmadığınız bir alt alan adının taklit edilmesini kapatmak için kullanışlıdır.
Raporlama, rua Adresi Neden Şart
DMARC politikasını güvenle sıkılaştırmanın tek yolu, alan adınız adına kimlerin e-posta gönderdiğini görmektir. rua etiketine yazdığınız adrese, e-posta alan büyük sağlayıcılar toplu raporlar gönderir. Bu raporlar XML biçimindedir ve hangi IP adresinden kaç ileti geldiğini, SPF ve DKIM sonucunu, hizalamanın tutup tutmadığını gösterir.
Raporları ham XML olarak okumak zordur; bir DMARC rapor analiz aracı ya da ayrı bir posta kutusu ve düzenli bir inceleme alışkanlığı gerekir. İlk haftalarda genelde sürprizler çıkar; unutulmuş bir iletişim formu eklentisi, muhasebe yazılımının kendi sunucusundan gönderdiği faturalar ya da e-bülten hizmeti. Bunların her biri SPF’ye eklenmeli ya da kendi alan adınızla DKIM imzalamalıdır. ruf etiketiyle istenen ileti bazlı hata raporlarını ise birçok büyük sağlayıcı gizlilik nedeniyle göndermez; asıl bilgi kaynağı toplu raporlardır.
Dikkat
rua adresi başka bir alan adındaysa, o alan adının DNS’inde raporları kabul ettiğini gösteren ek bir yetki kaydı gerekir. Bu kayıt yoksa alıcılar raporu göndermez ve siz “rapor gelmiyor” diye beklersiniz. En kolay yol, rapor adresini aynı alan adında açmaktır.
SPF ve DKIM Hizalaması Nasıl Kurulur
Hizalamanın iki modu vardır. Varsayılan gevşek (relaxed) modda alt alan adı ile ana alan adı eşleşmiş sayılır; “bulten.alanadiniz.com” ile imzalanan ileti “alanadiniz.com” adresinden gönderildiğinde hizalama tutar. Katı (strict) modda ise alan adları birebir aynı olmalıdır. adkim ve aspf etiketleri bu modu seçer. Çoğu işletme için gevşek mod yeterlidir.
Pratikte hizalamanın kırıldığı yer üçüncü taraf gönderim hizmetleridir. Bir bülten aracı iletiyi kendi alan adıyla imzalayıp kendi dönüş adresini kullanıyorsa, SPF ve DKIM başarılı görünür ama hizalama tutmaz. Çözüm, o hizmette kendi alan adınız için DKIM anahtarı oluşturup DNS’e eklemektir. DKIM kaydının cPanel’de nasıl eklendiği DKIM kaydı rehberinde anlatılıyor. Spama düşmenin diğer nedenlerini de e-postalar neden spama düşer yazısında topladık.
Aşamalı Geçiş Planı, none’dan reject’e
Güvenli geçiş, her adımda raporların temiz olduğunu görmeye dayanır. Takvim alan adının büyüklüğüne göre değişir; tek sunucudan gönderen küçük bir işletme birkaç haftada, çok sayıda gönderim hizmeti kullanan bir şirket birkaç ayda reject’e ulaşır.
Birinci aşamada p=none ve rua adresiyle başlayın, en az iki üç haftalık rapor toplayın. İkinci aşamada raporlarda çıkan her meşru kaynağı SPF ve DKIM ile hizalayın. Üçüncü aşamada p=quarantine’e geçin ve bir iki hafta daha izleyin. Son aşamada p=reject’e geçin. Eski standartta bu geçişi yumuşatan pct etiketi RFC 9989’da tarihsel kabul edildi, çünkü uygulamalar tutarsız davranıyordu. Yerine gelen t=y test modu etiketi, politikayı yayımlayıp alıcıdan henüz uygulamamasını istemenin yoludur; ancak her alıcının yeni etiketi desteklediğini varsaymayın.
Örnek senaryo
Bursa’da yirmi çalışanlı bir yedek parça toptancısı, sahte “ödeme bilgisi değişti” e-postaları müşterilerine ulaşınca DMARC politikası kurmaya karar veriyor. p=none ile başlıyor; ilk hafta raporlarda üç kaynak görüyor: kendi e-posta sunucusu, muhasebe yazılımının fatura sunucusu ve web sitesindeki iletişim formu. Fatura sunucusunu SPF’ye ekliyor, iletişim formunu kimliği doğrulanmış SMTP ile gönderecek şekilde düzenliyor. Dördüncü haftada quarantine’e, yedinci haftada reject’e geçiyor. Sahte iletiler artık müşterilerin gelen kutusuna ulaşmıyor.
Google ve Yahoo Gönderici Kuralları Ne İstiyor
Google, 1 Şubat 2024’ten itibaren Gmail hesaplarına günde 5.000’den fazla ileti gönderenlerden SPF, DKIM ve DMARC’ın üçünü birden istiyor. Google’ın gönderen yönergelerine göre bu gönderenler için DMARC politikası none olabilir; ayrıca “Kimden” alanındaki alan adının SPF ya da DKIM alan adıyla hizalı olması gerekiyor. Tüm gönderenler için ise en az SPF veya DKIM şart. Yahoo da aynı dönemde benzer kurallar duyurdu.
Yani büyük sağlayıcılar herkesi reject’e zorlamıyor; zorunlu olan kaydın var olması ve hizalamanın tutması. Reject, taklit edilme riskini ortadan kaldırmak isteyen alan adı sahibinin kendi kararıdır. Kurumsal alan adlarında, özellikle ödeme ve fatura yazışması yapılan işletmelerde, bu karar genelde reject yönünde verilir. Şirket e-postasını sıfırdan kuruyorsanız alan adı, hesaplar ve DNS kayıtlarının bütün resmini şirket e-postası oluşturma rehberinde bulabilirsiniz.
Sonuç
DMARC politikası seçimi bir güvenlik ayarından çok bir geçiş sürecidir. p=none ile görünürlük kazanın, raporlarda çıkan her meşru göndereni hizalayın, quarantine ile ara testi yapın ve raporlar temiz kaldığında reject’e geçin. Bu sırayla ilerleyen alan adında hem sahte e-posta durur hem de hiçbir meşru ileti kaybolmaz.
Kontrol Listesi, DMARC Politikası Sıkılaştırmadan Önce
- SPF kaydınızın tek olduğunu ve tüm gönderen sunucuları kapsadığını doğrulayın.
- Kendi e-posta sunucunuzda DKIM imzalamanın açık olduğunu kontrol edin.
- DMARC kaydını p=none ve aynı alan adındaki bir rua adresiyle yayımlayın.
- En az iki üç haftalık toplu raporu kaynak kaynak inceleyin.
- Bülten, fatura ve form gibi üçüncü taraf gönderenleri kendi alan adınızla DKIM ile imzalatın.
- Hiç e-posta göndermeyen alt alan adları için sp veya np politikasını belirleyin.
- quarantine’de raporlar temiz kaldıktan sonra reject’e geçin ve raporları izlemeye devam edin.
Sıkça sorulan sorular
DMARC politikası p=none olarak kalırsa sakıncası var mı?
p=none raporlama sağlar ve Google’ın toplu gönderici şartını karşılar, ama sahte iletiye karşı koruma sağlamaz. Alan adınızı taklit eden bir e-posta yine teslim edilir. Uzun süre none’da kalmak, raporları okumuyorsanız DMARC’ın asıl faydasından vazgeçmek demektir. Hedef, raporlar temizlendikten sonra quarantine ya da reject’tir.
p=reject e-postalarımın hiç teslim edilmemesine yol açar mı?
Doğru hizalanmış iletileriniz etkilenmez. Reject yalnız DMARC’tan geçemeyen iletileri durdurur. Sorun, hizalanmamış meşru bir kaynağınız varsa çıkar; örneğin kendi alan adınızla imzalamayan bir bülten aracı. Bu yüzden reject’e geçmeden önce raporlarda tüm kaynakların DMARC’tan geçtiğini görmek gerekir.
Yönlendirilen e-postalar DMARC’ta neden başarısız olur?
Yönlendirme sırasında ileti başka bir sunucudan yeniden gönderilir ve SPF denetimi bu sunucuya göre yapılır, bu yüzden SPF kırılır. DKIM imzası ileti değişmediği sürece korunur ve DMARC’ı tek başına geçirir. Konu satırına etiket ekleyen e-posta listeleri ise DKIM’i de bozabilir; bu durum reject politikasında liste iletilerinin kaybolmasına yol açabilir.
pct etiketini hâlâ kullanmalı mıyım?
RFC 9989 pct etiketini tarihsel kabul etti; yeni kayıtlarda aşamalı geçişi pct ile planlamayın. Eski standarda göre çalışan alıcılar etiketi bir süre daha okuyabilir, ancak davranışı tutarlı değildi. Yeni standartta test amaçlı t=y etiketi var. En güvenli yöntem yine none, quarantine ve reject adımlarını raporlara bakarak sırayla uygulamaktır.
DMARC raporları hangi sıklıkla gelir?
Toplu raporlar genelde günde bir kez, alan adınıza e-posta ulaştıran her büyük sağlayıcıdan ayrı ayrı gelir. Gönderim hacmi düşük bir alan adında bazı günler hiç rapor gelmeyebilir. Raporlar XML biçiminde ve sıkıştırılmış olarak gelir; bu yüzden ayrı bir posta kutusu açmak ve bir analiz aracıyla okumak işi kolaylaştırır.
Narhost’ta
Kurumsal e-posta paketlerimizde alan adınıza özel adresler, SPF ve DNS kayıt desteği, e-posta gönderi takibi ve yetkilendirilebilir yönetim paneli bulunur.