DMARC (Domain-Based Message Authentication, Reporting, and Conformance), alıcının gördüğü From (Gönderen) üstbilgisindeki alan adını doğrulanmış bir gönderim kimliğiyle karşılaştırarak bu alan adının yetkili kullanılıp kullanılmadığını denetler. Bu alan adına görünen gönderen alan adı denir.

DMARC, gönderim yetkisini denetleyen SPF (Sender Policy Framework) veya iletiye dijital imza ekleyen DKIM (DomainKeys Identified Mail) sonucunun yalnız başarılı olmasını yeterli saymaz. SPF ile doğrulanan SMTP MAIL FROM adresinin alan adını ve geçerli DKIM imzasındaki d= alan adını, görünen gönderen alan adıyla karşılaştırır. Bunlardan en az birinin görünen gönderen alan adıyla hizalı olması gerekir. Bu karşılaştırma alan adı hizalaması olarak adlandırılır.

DMARC şifreleme sağlamaz, ileti içeriğini güvenli ilan etmez ve teslimatı garanti etmez. Mayıs 2026’da yayımlanan RFC 9989 temel mekanizmayı, RFC 9990 toplu raporlamayı, RFC 9991 ise başarısızlık raporlamasını tanımlar. Bu üç standart, RFC 7489’un yerini alarak mekanizma ile iki rapor türünü ayrı belgelerde düzenler.

DMARC Hangi Sorunu Çözer?

Bir saldırgan kendi alan adı için geçerli SPF kaydı yayımlayabilir veya kendi alanıyla geçerli DKIM imzası oluşturabilir. İletinin From üstbilgisindeki gönderen adresinde başka bir kuruluşun alan adını yazması halinde yalnız spf=pass ya da dkim=pass sonucu, görünen gönderen alan adının yetkili kullanıldığını kanıtlamaz.

DMARC, doğrulanan alan adıyla görünen gönderen alan adı arasında bağ kurarak bu boşluğu azaltır. Korunan kısım, e-posta adresinin @ işaretinden sonraki görünen alan adıdır. @ işaretinden önceki kullanıcı adını, iletiyi yazan kişinin gerçek kimliğini veya benzer yazılmış başka bir alan adını doğrulamaz. Ele geçirilmiş meşru bir hesaptan gönderilen zararlı ileti de DMARC denetiminden geçebilir; içerik taraması, itibar değerlendirmesi ve diğer güvenlik önlemleri ayrıca gereklidir.

Örneğin example.com adına görünen bir iletinin SPF sonucu attacker.example için başarılıysa alanlar hizalı değildir. Buna karşılık geçerli DKIM imzasındaki d=example.com değeri görünen gönderen alan adıyla hizalıysa DMARC geçebilir.

DMARC Doğrulaması Adım Adım Nasıl Çalışır?

  1. Alıcı, From üstbilgisinden tek bir gönderen alan adı çıkarır. Hiç alan bulunmazsa veya birden fazla alan varsa standart DMARC doğrulaması tamamlanamaz.
  2. DNS içinde uygulanabilir DMARC politika kaydını arar. Kayıt bulunmazsa DMARC denetimi sona erer.
  3. SPF için MAIL FROM kimliğini, her DKIM imzası için d= kimliğini ve doğrulama sonuçlarını toplar.
  4. Başarılı doğrulama sonuçlarındaki alan adlarından en az birinin görünen gönderen alan adıyla gevşek veya katı kurala göre hizalanıp hizalanmadığını denetler.
  5. En az bir başarılı ve hizalı kimlik varsa pass, hiçbiri yoksa fail sonucu üretir.
  6. fail sonucunda alan sahibinin politika tercihini ve alıcının yerel güvenlik kurallarını birlikte değerlendirir.

Gerekli DNS sorgularından biri geçici ya da kalıcı DNS hatası yüzünden tamamlanamazsa ileti DMARC açısından geçmiş veya kalmış sayılmaz; alan sahibinin DMARC politikası bu sonuca uygulanamaz. Alıcı diğer yerel kurallarıyla karar verebilir.

SPF ve DKIM İçin Hangi Alan Adları Karşılaştırılır?

YolDoğrulanan kimlikDMARC için geçiş koşuluDoğrulamayı bozabilen durum
SPFSMTP MAIL FROM alan adıSPF başarılı olmalı ve bu alan adı görünen gönderen alan adıyla hizalı olmalıdır.Yönlendiren sunucunun kaynak IP adresi SPF denetiminden geçmeyebilir; zarf göndereni adresinin alan adı değiştirilirse hizalama da bozulabilir.
DKIMGeçerli imzadaki d= alan adıEn az bir DKIM imzası başarılı olmalı ve imzadaki d= alan adı görünen gönderen alan adıyla hizalı olmalıdır.Posta listesi ya da aracı sistem, imzalanmış üstbilgi veya gövdeyi değiştirirse imza bozulabilir.

DMARC’ın geçmesi için iki yolun birden geçmesi gerekmez; SPF veya DKIM yollarından en az biri hem başarılı hem hizalı olmalıdır. Standarda tam uyum için alan sahipleri her iki mekanizmayı da hizalı biçimde yapılandırmalıdır. Özellikle p=reject kullanırken yalnız SPF başarısına güvenilmez; iletiler hizalı ve geçerli DKIM imzası taşımalıdır.

Bir iletide birden fazla DKIM imzası bulunabilir. İmzalardan herhangi biri geçerliyse ve d= alan adı görünen gönderen alan adıyla hizalıysa DKIM yolu DMARC geçişini destekler. Başarılı fakat hizasız bir imza tek başına yeterli değildir.

Gevşek ve Katı Hizalama Nasıl Yorumlanır?

Relaxed (gevşek) hizalama, görünen gönderen alan adı ile doğrulanmış kimliğin aynı kuruluş alan adına ait olmasını gerektirir. Kuruluş alan adı, aynı yönetim yetkisinin sürdüğü alan adı hiyerarşisinin en üstündeki addır. Strict (katı) hizalama ise iki alan adının birebir aynı olmasını gerektirir. DKIM için adkim=, SPF için aspf= etiketi kullanılır; varsayılan değer her ikisinde de r, yani gevşektir.

Görünen gönderen alan adıDoğrulanmış alanGevşekKatı
news.example.combounce.example.comAynı kuruluş alan adı belirlenirse hizalı olabilir.Alanlar birebir aynı olmadığı için hizasızdır.
example.comexample.comHizalıdır.Hizalıdır.
example.comexample.netHizasızdır.Hizasızdır.

RFC 9989, kuruluş alan adını ve uygulanabilir politikayı bulmak için DNS Tree Walk yöntemini tanımlar; önceki genel son ek listesi bağımlılığının yerini bu yöntem almıştır. Kötüye kullanımı sınırlamak için çok derin adlarda en fazla sekiz DNS sorgusu yapılır. Katı hizalamada ise kuruluş alan adı hesabı yerine doğrudan alan adı karşılaştırması yeterlidir.

DMARC Kaydı Nerede Yayımlanır ve Nasıl Bulunur?

DMARC politikası DNS TXT kaydı olarak _dmarc etiketi altında yayımlanır. example.com için ilk sorgu _dmarc.example.com adına yapılır. Görünen gönderen alan adında geçerli kayıt yoksa DNS Tree Walk yöntemiyle sırasıyla kuruluş alan adı ve varsa genel son ek alan adı (PSD) politikası aranır.

Tercih sırası görünen gönderen alan adı, bunun kuruluş alan adı ve PSD’sidir. Uygulanan üst politika bir kuruluş alan adına aitse mevcut alt alanlar için sp=, var olmayan alt alanlar için np= kullanılabilir; uygun etiket yoksa p= devralınır.

Aynı sorgu adında tek bir geçerli DMARC politika kaydı bulunmalıdır. Birden fazla DMARC kaydı dönerse alıcı o sorgu adındaki DMARC kayıtlarının tümünü yok sayar; DNS ağaç taramasında başka bir uygun politika aramayı sürdürür. TXT kaydı aynı kayıt içinde birkaç tırnaklı karakter dizisine bölünmüşse bu diziler sırayla ve araya boşluk eklenmeden birleştirilir.

Güncel DMARC Etiketleri Ne Anlama Gelir?

EtiketGöreviGüncel not
v=DMARC1Sürümü bildirir.Zorunludur, ilk etiket olmalıdır ve değeri büyük-küçük harfe duyarlıdır.
p=Ana politika tercihini bildirir.none, quarantine veya reject; yoksa geçerli kayıt p=none gibi yorumlanır.
sp=Mevcut alt alanların politikasını bildirir.Etiket yoksa uygun p= politikası devralınır.
np=Var olmayan alt alanların politikasını bildirir.Yoksa önce sp=, o da yoksa p= kullanılır.
adkim= / aspf=DKIM ve SPF hizalama modunu seçer.r gevşek ve varsayılan; s katıdır.
t=Politika test modunu bildirir.n varsayılan; y belirtilen politikadan bir seviye daha düşük uygulama isteğidir.
rua=Toplu rapor hedeflerini belirtir.Yoksa alan için toplu rapor üretilmez.
ruf= / fo=Başarısızlık raporu hedefini ve koşullarını belirtir.Alıcıların rapor göndermesi yerel destek, gizlilik ve oran sınırlarına bağlıdır.
psd=Kaydın PSD ya da kuruluş alan adı rolünü açıklar.y, n ve varsayılan u değerleri DNS ağaç taramasında kullanılır.

RFC 7489’daki yüzdelik uygulama etiketi pct=, RFC 9989’dan kaldırılmıştır. Güncel DMARC kaydında kademeli uygulama için pct= değerine güvenilmemelidir. t=y test modu, quarantine politikasını none, reject politikasını quarantine düzeyinde uygulama isteği bildirir; none üzerinde etkisi yoktur.

none, quarantine ve reject Politikaları Nasıl Yorumlanır?

PolitikaAlan sahibinin tercihiAlıcının olası işlemi
p=noneDMARC başarısızlığı için özel işlem tercihi bildirmez.Doğrulama ve istenmiş raporlama sürer; alıcı diğer sinyallerle karar verir.
p=quarantineBaşarısız iletiyi şüpheli sayar.İstenmeyen posta klasörü, ek inceleme veya yerel karantina uygulanabilir.
p=rejectAlan kullanımını geçersiz kabul eden ret tercihi bildirir.Alıcı, başka güvenlik verileriyle birlikte değerlendirerek SMTP aşamasında reddedebilir; yalnız bu politikaya dayanarak ret vermez.

Bu değerler alıcının yerel kararını tamamen ortadan kaldıran komutlar değildir. Alıcı, güvenilir yönlendirme bilgisi, itibar, kötü amaçlı içerik taraması ve kullanıcı politikası gibi sinyalleri de değerlendirir. RFC 9989’a göre ek bilgi veya analiz bulunmuyorsa p=reject nedeniyle reddetmek yerine başarısız iletiyi p=quarantine uygulanıyormuş gibi ele alır.

DMARC geçişi gelen kutusu garantisi değildir; başarısızlık da her alıcıda otomatik ret anlamına gelmez. DNS hatası nedeniyle DMARC sonucu üretilemeyen iletiye p=, sp= veya np= politikası uygulanamaz.

DMARC Raporları Ne Gösterir?

RaporStandartİçerik ve sınır
Toplu raporRFC 9990Gönderen sunucuların IP adreslerini, ileti sayılarını, uygulanan politika ile SPF, DKIM ve hizalama sonuçlarını XML biçiminde toplulaştırır; tekil ileti içeriğini taşımaz.
Başarısızlık raporuRFC 9991Belirli başarısız iletiler için ayrıntı, üstbilgi ve bazı durumlarda gövde içeriği taşıyabilir; kişisel ve gizli veri riski nedeniyle birçok alıcı bunu kısıtlar.

rua= toplu rapor, ruf= başarısızlık raporu hedefini belirtir. Her alıcının rapor göndermesi beklenemez. Başarısızlık raporu üreten alıcı sistemler oran sınırı uygulamalı; alan sahipleri hedefleri, saklama süresini ve erişim yetkilerini gizlilik açısından yönetmelidir.

Rapor adresinin alan adı ile politikayı yayımlayan alan adı aynı kuruluş alan adını paylaşmıyorsa rapor alacak alanın DNS üzerinden izin vermesi gerekir. Bu doğrulama, başka bir alanın izni olmadan rapor yükü altında bırakılmasını önler. Yetkilendirme başarısızsa standarda uyumlu alıcı sistem ilgili dış adresi yok sayar.

Yönlendirme ve Posta Listeleri DMARC’ı Nasıl Etkiler?

Yönlendirme, alıcıya bağlanan sunucunun kaynak IP adresini değiştirdiği için SPF doğrulamasını bozabilir. İleti gövdesi ve imzalanan üstbilgiler değişmeden kalırsa DKIM yolu geçerli ve hizalı kalabilir. Posta listesi konu satırını, gövdeyi veya içerik kodlamasını değiştirirse DKIM imzası da bozulabilir.

Alıcı, bilinen ve güvenilir bir aracı yüzünden iki yolun da bozulduğunu yerel kanıtlarla belirlerse alan sahibinin politikasını geçersiz kılabilir. Bu istisna, DMARC’ın başarısız sonucu saklaması anlamına gelmez; alıcı raporda politika geçersiz kılma nedenini ayrıca gösterebilir.

Gönderim Kaynaklarını Doğrulama ve DMARC Politikasını Sıkılaştırma

DNS’te sözdizimi geçerli bir kayıt bulunması, gerçek iletilerin DMARC denetiminden geçtiğini göstermez. Bunu doğrulamak için her gönderim kaynağından test iletisi gönderip alıcının doğrulama sonuçlarını inceleyin.

  1. Kurumsal posta, işlem iletileri, destek, pazarlama ve üçüncü taraf hizmetler dahil bütün gerçek gönderim kaynaklarını çıkarın.
  2. Her kaynakta SPF ile doğrulanan MAIL FROM adresinin alan adını ve DKIM imzasındaki d= alan adını görünen gönderen alan adıyla hizalı olacak biçimde yapılandırın.
  3. Tek ve sözdizimi geçerli DMARC kaydını yayımlayın; başlangıçta p=none ve yönettiğiniz bir rua= rapor adresi kullanarak gönderim kaynakları hakkında veri toplayın.
  4. Her gerçek kaynaktan kontrollü ileti gönderin. Güvendiğiniz alıcı posta sisteminin eklediği Authentication-Results üstbilgisinde SPF, DKIM, DMARC ve hizalanan alanları inceleyin.
  5. Toplu raporlardaki bilinmeyen kaynakları ve alıcının politikanızdan ayrılma nedenlerini inceleyin; meşru gönderimlerdeki doğrulama ve hizalama hatalarını düzeltin.
  6. Meşru trafik doğrulandıktan sonra quarantine ve reject seviyelerine geçişi değerlendirin. p=reject öncesinde hizalı DKIM imzalarını ve posta listelerine etkisini sınayın; listelere ileti gönderen kullanıcıların bulunduğu alanlarda ret politikası önerilmez. Güncel standartta kaldırılmış pct= etiketine güvenmeyin.
  7. Alt alanlar, var olmayan alt alanlar, dış rapor hedefleri, DNS ağaç taraması ve önbellek sürelerini ayrıca sınayın.