DMARC Nedir?
Kısa tanım
DMARC, alan adı sahibinin SPF ve DKIM sonuçlarını iletinin görünür Kimden (From) adresine bağlamasını, doğrulamayı geçemeyen postaya ne yapılacağını (none, quarantine, reject) ilan etmesini ve alıcılardan rapor almasını sağlayan e-posta kimlik doğrulama standardıdır. Politika _dmarc alt adında bir TXT kaydıyla yayımlanır. İlk olarak RFC 7489 ile tanımlandı; Mayıs 2026'da yayımlanan RFC 9989 bu belgenin yerini aldı.
Diğer adları: Domain-based Message Authentication, Reporting and Conformance, DMARC kaydı, DMARC politikası, _dmarc, v=DMARC1
Eksik halka: görünen gönderen adresi
SPF zarf göndereninin alan adını, DKIM ise imzayı atan alan adını doğrular. İkisi de kullanıcının e-posta programında gördüğü From: adresiyle doğrudan ilgilenmez. Bir sahtekâr kendi alan adıyla SPF ve DKIM'den geçen, ama From: satırında sizin adresinizi gösteren bir ileti gönderebilir. DMARC bu boşluğu uyum (alignment) kuralıyla kapatır: bir ileti, ancak geçen SPF veya DKIM sonucunun alan adı From: alan adıyla uyumluysa DMARC'tan geçer.
- Gevşek uyum (relaxed, varsayılan): Aynı kurumsal alan adı yeterlidir;
bulten.example.comile imzalanan iletiFrom: [email protected]için uyumlu sayılır. - Katı uyum (strict): Alan adlarının birebir aynı olması gerekir.
Uyumlu SPF ya da uyumlu DKIM'den birinin geçmesi yeterlidir. Yönlendirmede SPF sıkça bozulduğu için pratikte DKIM uyumu daha belirleyicidir.
Bir DMARC kaydı
Politika, _dmarc alt adında bir TXT kaydı olarak yayımlanır:
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]; adkim=r; aspf=r"| Etiket | Görevi |
|---|---|
p | Doğrulamayı geçemeyen posta için politika: none (yalnızca izle), quarantine (şüpheli say), reject (reddet). |
sp / np | Alt alan adları için ve DNS'te var olmayan alt alan adları için ayrı politika. |
rua | Toplu (aggregate) raporların gönderileceği adres. |
adkim / aspf | DKIM ve SPF için uyum modu: r gevşek, s katı. |
t | t=y, politikanın test modunda olduğunu, henüz tam uygulanmasının istenmediğini belirtir. |
p=none'dan p=reject'e aşamalı geçiş
Doğrudan p=reject ile başlamak, unutulmuş bir fatura sisteminin veya CRM'in gönderdiği meşru postaların reddedilmesine yol açabilir. Güvenli yol aşamalıdır:
p=noneve birruaadresiyle başlayın. Alıcılar, alan adınız adına hangi IP'lerden ne kadar posta geldiğini ve SPF/DKIM sonuçlarını XML raporlarla bildirir.- Raporlarda gördüğünüz meşru kaynakların her birini kendi alan adınızla DKIM imzalayacak ve SPF'ye dahil olacak şekilde düzeltin.
- Meşru trafik uyumlu hâle geldiğinde
p=quarantine, ardındanp=rejectpolitikasına geçin.
RFC 7489'daki yüzde bazlı kademelendirme etiketi pct, yeni standartta kaldırıldı ve yerine t etiketi geldi. Alıcıların yeni sürüme geçişi zaman alacağı için bir süre iki davranış bir arada görülebilir. Arka arkaya gelen raporları okumak zahmetliyse bir DMARC rapor analiz aracı kullanmak işi kolaylaştırır; hata (failure) raporları için ruf etiketi de vardır, ancak birçok alıcı gizlilik gerekçesiyle bu raporları göndermez.
Standardın güncel durumu
DMARC 2015'te RFC 7489 ile yayımlandığında IETF standardı değil, bilgilendirici (informational) bir belgeydi. Mayıs 2026'da yayımlanan RFC 9989, RFC 7489'un yerini alarak DMARC'ı standartlar yoluna (standards track) taşıdı; raporlama ayrı belgelere (RFC 9990 ve 9991) ayrıldı. Önemli bir değişiklik, kurumsal alan adının artık Public Suffix List yerine “DNS tree walk” adı verilen, DNS hiyerarşisini yukarı doğru sorgulayan bir yöntemle belirlenmesidir. Kayıt sürümü hâlâ v=DMARC1'dir; mevcut kayıtlar çalışmaya devam eder.
Büyük posta sağlayıcıları ne istiyor?
Google ve Yahoo'nun Şubat 2024'te uygulamaya başladığı şartlara göre toplu göndericilerin (Google'ın tanımıyla kişisel Gmail hesaplarına günde 5.000'den fazla ileti gönderenler) bir DMARC kaydı yayımlaması ve From: alan adının SPF veya DKIM alan adıyla uyumlu olması gerekir. Her iki sağlayıcı da p=none politikasını bu şart için yeterli sayar. Yani şart, kaydın varlığı ve uyumdur; reject'e geçmek ise alan adınızı sahteciliğe karşı korumak için verdiğiniz ayrı bir karardır.