DMARC Nedir? Alignment, Politikalar ve 2026 RFC'ler

DMARC Nedir? It is a DNS record that tells receiving mail servers what to do when a message claims your domain in the From header but fails authentication, and where to send reports about it. DMARC does not authenticate anything by itself. It checks that SPF or DKIM passed and that the domain they validated matches the domain the reader sees.

That match is called alignment, and it is the part most teams get wrong. A message can pass SPF, pass DKIM, and still fail DMARC.

DMARC, SPF ve DKIM Üstünde Bir Politika Katmanıdır

SPF, bir alan adı için hangi IP'lerin posta gönderebileceğini listeler. DKIM mesajı imzalar; böylece alıcı mesajın değiştirilmediğini ve imza veren alan adının bunu onayladığını doğrulayabilir. Her ikisi de insan tarafından okunan From adresine bakmaz.

DMARC bu boşluğu doldurur. Tek bir soruyu sorar: görünür From başlığındaki alan adı, SPF ya da DKIM'i geçen alan adıyla uyumlu mu? Evet ise mesaj geçer. Hayır ise alıcı politikanızı uygular.

Kayıt _dmarc.ornegaalanadi.com adresinde bir TXT kaydı olarak bulunur. Minimal, geçerli bir kayıt şöyle görünür:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Üç tag gerçek işi yapar. p politikadır, rua toplam raporların nereye gideceğidir ve adkim / aspf alignment ne kadar katı olacağını ayarlar. Geri kalan her şey isteğe bağlıdır. Gereksiz karmaşıklıktan kaçınmak için başta yalnızca bu üç tag'a odaklanın.

Alignment İyi Kurulumların Başarısız Olduğu Yerdir

SPF, return-path alanı adı olan zarf gönderenini doğrular. DKIM, imzanın d= etiketindeki alan adını doğrular. DMARC, bunlardan en az birinin From alanı adıyla eşleşmesine ihtiyaç duyar; tam eşleşme (strict) ya da kurumsal alan adı düzeyinde (relaxed, varsayılan).

İz çalışmasında en sık gördüğümüz hata şu şekildedir. Bir takım üçüncü taraf bir sağlayıcı üzerinden gönderir; sağlayıcı kendi alan adıyla (d=provider-mail.net) imzalar ve kendi geri dönüş alan adını kullanır. SPF geçer, DKIM geçer ve DMARC başarısız olur çünkü her iki alan adı da example.com ile eşleşmez.

Çözüm özel bir gönderme alan adıdır: kendi alan adınız altında yayınlanan bir DKIM anahtarı ve ideal olarak alt alan adında özel bir return-path. Her ciddi sağlayıcı bunu destekler. Çok azı varsayılan olarak etkinleştirir. Bu konfigürasyonu ayarlamak ilk başta karmaşık görünebilir ama alignment sorunu devam ettikçe imzaları yönetmek daha zordur.

Üç Politika: none, quarantine, reject

p etiketinin üç değeri vardır ve bunlar bir programa göre çıktığınız bir merdiven değildir.

• p=none: alıcı normal olarak sunar ve size raporlar gönderir. İlk 2 ila 4 hafta kullanın, gönderenlerin envanterini yazarken.

• p=quarantine: alıcı başarısızlıkları istenmeyen posta veya çöp kutusuna yönlendirir. Raporlar tüm meşru kaynakların uyumlu olduğunu gösterdiğinde kullanın.

• p=reject: alıcı başarısızlıkları SMTP aşamasında reddeder. Karantina bir tam gönderme döngüsü için temiz çalıştığında kullanın.

p=none izleme, koruma değildir. İki yıl boyunca none konumunda kalan bir alan adı bir uyum onay kutusu ve spoofing savunması yoktur. Bunu orada bırakma cazibesini atla çünkü "hiçbir şey kırılmadı". Compliance gereklilikleriniz varsa iki yıldan sonra ileri taşımak zorunluyacaktır.

p=reject yalnızca kontrol ettiğiniz posta gönderen herhangi bir alan adı için hedeftir. Ağır posta listesi trafiği veya eski yönlendiriciler içeren alan adları daha fazla dikkat gerektirir, çünkü yönlendirme genellikle SPF'yi bozar ve gönderilen kişi gövdesini düzenlemişse DKIM'i bozabilir.

Gmail ve Yahoo Kuralları Bunu Neden Acil Yaptı

Şubat 2024'ten beri Google'ın gönderici yönergeleri Gmail hesaplarına günde 5.000'den fazla mesaj gönderen herhangi bir kişinin bir DMARC kaydı yayınlamasını gerektirir; SPF ve DKIM yerinde olmalıdır. Politika none olabilir. Google ayrıca toplu gönderenleri Postmaster Tools'ta kullanıcı tarafından bildirilen spam oranını %0,30'un altında tutmayı ister ve %0,10'un altında kalmanızı önerir.

Yahoo Sender Hub aynı temel gereksinime şunu belirtir: bir p=none politikasının geçerli DMARC kaydı; From alanı SPF ya da DKIM alanı adıyla uyumlu. Relaxed alignment kabul edilebilir.

Bu kurallarla neler ve neler değil olduğuna dikkat edin. Gereklilik yayınlanan bir kaydı ve uyumluluğun geçmesidir, zorlama değil. Bu bir taban. Bitmiş bir çizgi değil. Gmail ve Yahoo kuralları posta altyapısının bel kemiğini oluştururlar.

Toplam Raporlar Üründür, Politika Anahtarıdır

rua adresi, DMARC'ı onuran her alıcıdan günlük XML raporları alır. Her rapor kaynak IP'lerini, mesaj sayılarını, SPF ve DKIM sonuçlarını ve alignment tutup tutmadığını listeler. Unutulmuş göndereni bulmanın yolu budur: eski CRM dışarı aktarması, bir müteahhit 2022'de bağlayan faturalandırma aracı, kimse tarafından sahip olmayan bir alt alan adındaki pazarlama formu.

Ham XML hacimde okunaksızdır. rua dosyasını ayrıştırıcının yutabileceği bir posta kutusuna veya barındırılan bir DMARC raporlama hizmetine yönlendirin ve verileri kaynağa göre gruplanmış olarak arayın. Görmek istediğiniz şey, her meşru kaynağın %100 uyumlu olması ve başka her şey açıkça bilinmiyorsa.

Pratik bir dağıtım şu sırada çalışır:

1. p=none ve rua adresini yayınlayın.

2. İki ila dört hafta rapor toplayın. Gönderici envanterini oluşturun.

3. Her meşru uyumsuz kaynağı özel bir DKIM alan adı veya return-path ile düzeltin.

4. p=quarantinee geçin. Posta kaybı hakkında destek biletlerini izleyin.

5. Karantina meşru başarısızlıklar göstermediğinde p=rejecte geçin.

Her adımı ayrı gönder. Politikayı değiştirmek ve yeni bir gönderme sağlayıcısı eklemek aynı haftada herhangi bir gerilemeyi atfetmeyi imkansız hale getirir. Kademeli yaklaşım imalarda belirlenen sorunları izole etmeyi sağlar.

DMARCbis Etiketleri Değiştirir, Kaydınız Değil

2026'da IETF RFC 9989, RFC 9990 ve RFC 9991 yayınladı; bunlar RFC 7489'u yıkıyor. RFC 9989 çekirdek DMARC özelliğidir. Toplam raporlama ve başarısızlık raporlaması kendi belgelerine taşındı.

Kayıt sahibi için pratik değişiklikler küçüktür:

• pct, rf ve ri kaldırılır.

• t (test modu) pct'nin yerini alır; her şey veya hiç anahtarı: t=y zorlama olmadan raporlar.

• np var olmayan alt alan adları için bir politika ayarlar; spoofing abc123.example.com gibi adreslerini engeller.

• psd herkese açık alan adı sonek alan adlarını işaretler ve DNS ağacı yürümesi eski Genel Alan Sonek Listesi aramasının yerini alır.

Mevcut v=DMARC1 kayıtları geçerli kalır. Bugün hiçbir şeyi değiştirmezseniz hiçbir şey kırılmaz. Yeni etiketler için sağlayıcı desteği eşit olmayan şekilde toplanacaktır; bu nedenle hiçbir şey yapmıyor görünen yeni bir etiket genellikle alıcı henüz uygulamadığı anlamına gelir.

np etiketi erken benimsenmeye değerdir. p hala none iken np=reject ayarlanması, posta'nın geri kalanını zorlama için işlemeden sahte alt alan adı istismarı yolunu kapatır.

Alt Alan Adları ve Neden Varsayılan Devraldığı

Kurumsal alan adı üstündeki bir DMARC kaydı alt alan adlarına da uygulanır; sp ile geçersiz kılmadıkça. Bu miras kullanışlı ve aynı zamanda bir tuzaktır.

Pazarlama news.example.comdan ayrı bir sağlayıcı aracılığıyla gönderirse, üst alan adı politikasını devralır. Bunu p=rejecte taşımadan önce bu sağlayıcı DKIM alignment gerçekleştirmişse haber bülteni yerde kalır. Kendi gönderici filosuna ve kendi dağıtım hızına sahip olan bir alt alan adı için _dmarc.news.example.com kaydını ayrı olarak yayınlayın.

Daha temiz bir mimari, akışları başında alt alan adları tarafından ayırır. İşlemsel posta birinde, yaşam döngüsü bir diğerinde, insan postaları kökende. Her biri kendi DKIM anahtarlarını, kendi itibarını ve kendi DMARC kaydını alır. Bu ayrıştırma operasyonel esneklik sağlar.

Tahmin Etmeden Önce Authentication-Results Başlığını Okuyun

Bir mesaj başarısız olduğunda, alıcı sunucusu neden başarısız olduğunu kaydeder. Gmail'de "Orijinali göster" Authentication-Results başlığını ortaya çıkarır ve herhangi bir panelden daha fazlasını söyler.

Authentication-Results: mx.google.com;
  spf=pass smtp.mailfrom=bounce.provider-mail.net;
  dkim=pass header.d=provider-mail.net;
  dmarc=fail (p=NONE) header.from=example.com

Bunu soldan sağa okuyun. SPF bounce.provider-mail.net için geçti. DKIM provider-mail.net için geçti. DMARC başarısız oldu çünkü From başlığı example.com diyor ve ne geçen alan adı da bununla eşleşmez.

(p=NONE) notu alıcının gördüğü politikayı gösterir. none konumunda bu mesaj yine de iletilirdi. reject konumunda bir 5.7.x hatasıyla geri sıçrarve gönderici bir müşteriden öğrenirdi.

İki kontrol çoğu bu durumları yakalar. DKIM sonucundaki header.d değerinin alan adınız olduğunu onaylayın. Ardından smtp.mailfrom alanı adının alan adınız veya alt alan adının bir alt alan adı olduğunu onaylayın. Bu basit denetim listesi hatakaldırma zamanını ilerletir.

SPF'nin Bir Arama Sınırı Vardır; DMARC Bunu Ortaya Çıkarır

SPF değerlendirme başına on DNS araması sağlar. Her sağlayıcı için include: bunlardan bazılarını harcamıştır ve iç içe includes daha fazlasını harcar. On geçin ve SPF kalıcı bir hata döndürür; bu başarısız sayılır.

Beş veya altı gönderme aracı olan takımlar bunu fark etmeden vuruş. SPF başarısızlıkları DMARC raporlamasından önce görünmezdi. rua raporları ulaştığında, desen açıktır: bir kaynak birden bire tüm alıcılar üzerinde SPF'de başarısız olurken; biri başka bir include: eklediği gün.

Bu, DKIM alignment'in birincil yol olarak güvenilme konusunun başka bir nedenidir. DKIM çoğu yönlendirmeyi kurtarır; arama bütçesi yoktur ve mesajla bağlantılıdır bağlantı IP'sinden daha. SPF geçerli tutun ama tek başına DMARC geçişi oluşturmayın.

DMARC Ne Yapmayacağı

DMARC tam alan adı spoofing'ini engeller. Benzer alan adlarını (examp1e.com) durdurmaz, içeriği yargılamaz ve kötü gönderici itibarı düzeltmez. Mükemmel uyumlu alan adı satın alınan listelere gönderirse yine de istenmeyen postaya iner.

Aynı zamanda izlemeyi değiştirmez. Alignment sessizce bozabilir: DNS değişikliği bir DKIM seçiciyi kaldırır; sağlayıcı anahtarları döndürür; yeni araç bilginiz olmadan göndermeye başlar. Raporlar kullanıcılarınızdan önce nasıl öğrendiğinizdir.

DMARC kaydını üretim yapılandırması gibi davran. Sürüm kontrolünde yer almaktadır; değişiklikler inceleme yapılarak girilir ve rua posta kutusu bir sahibi gerektirir.

Kaydı Yayınlamadan Önce

Bunu bir kez çalıştırın. Tek bir alan adı için bir saatten az sürer.

• Posta olarak alan adınız gönderen her sistemi listeleyin: ürün, faturalandırma, destek masası, CRM, pazarlama, takvim davetleri.

• Her birinin satıcının değil, alan adınız ile DKIM imzaladığını onaylayın.

• Sağlayıcı izin verdiğinde özel bir return-path ayarlayın.

• rua hedefi birinin okuduğu şeyi seçin.

• p=none konumunda başlayın ve incelemeyi planlamak için takvimi kontrol edin.

• Dağıtım sırasında Google Postmaster Tools'ta spam oranını haftalık kontrol edin.

Buradan Nereye Gidilir

Hiç raporlarınızı incelediyseniz p=none ve rua adresini bugün yayınlayın ve iki haftada ne geldiğini okuyun. İlk rapor neredeyse her zaman kimse hatırlamayan en az bir göndericiyi adlandırır. Sonraki somut adım bunlardan hangisini tuttuğuna karar vermektir. Kurulumunuz ilk ayda hayat kurtarıcı imzasızlıklar ortaya çıkaracaktır.