DMARC Nedir? DMARC Politikası ve Kademeli Geçiş Rehberi

DMARC nedir diye soranlara verilecek en net yanıt şudur: DMARC (Domain-based Message Authentication, Reporting and Conformance), SPF ve DKIM sonuçlarını iletinin görünen From alan adıyla ilişkilendiren ve doğrulamadan geçemeyen iletilere ne yapılacağını alıcı sunuculara bildiren bir politikadır. Alan adı sahibi DNS'e tek bir TXT kaydı ekleyerek bu iletilerin izlenmesini, karantinaya alınmasını ya da reddedilmesini isteyebilir ve alıcılardan düzenli rapor alır.

DMARC ilk olarak 2015'te RFC 7489 ile tanımlandı. 2026'da yayımlanan RFC 9989 bu belgenin yerini alarak DMARC'ı standartlar yoluna (Proposed Standard) taşıdı; raporlama ayrıntıları ise RFC 9990 ve RFC 9991'de tanımlanır.

DMARC neden gerekli?

SPF zarf göndericisini, DKIM ise imzalayan alan adını doğrular. Ancak ikisi de kullanıcının gördüğü From adresinin bu alan adlarıyla aynı olup olmadığını sorgulamaz. Saldırgan, kendi alan adıyla SPF ve DKIM'den geçen bir iletinin From alanına sizin adresinizi yazabilir. DMARC üç eksikliği birden kapatır:

• Hizalama: SPF veya DKIM'in, From alan adıyla uyumlu bir alan adı için geçmesini şart koşar.
• Politika: Doğrulamadan geçemeyen iletilere ne yapılacağını alan adı sahibinin belirlemesini sağlar.
• Raporlama: Alan adınız adına kimlerin e-posta gönderdiğini alıcıların raporlarıyla görünür kılar.

DMARC nasıl çalışır?

1. Alıcı sunucu iletideki From alan adını (örneğin example.com.tr) belirler.
2. _dmarc.example.com.tr adındaki TXT kaydını sorgular.
3. SPF ve DKIM sonuçlarının From alan adıyla hizalı olup olmadığına bakar. İkisinden birinin hizalı şekilde geçmesi DMARC'ın geçmesi için yeterlidir.
4. İkisi de hizalı geçemezse kayıttaki politikayı uygular.
5. Değerlendirme sonuçlarını, kayıtta belirtilmişse rapor adresine toplu olarak gönderir.

DMARC kaydının etiketleri

Örnek bir başlangıç kaydı şöyledir:

_dmarc.example.com.tr.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]; fo=1"

p etiketi olmayan bir kayıt en iyi ihtimalle p=none gibi değerlendirilir; bu yüzden politikayı her zaman açıkça yazın. RFC 7489'da yer alan pct, rf ve ri etiketleri ise RFC 9989 ile kaldırıldı. Eski kayıtlarda bu etiketlere hâlâ rastlayabilirsiniz, ancak yeni standardı uygulayan alıcıların bunları yok sayması beklenir.

fo=1 ayarı, SPF veya DKIM'den herhangi biri hizalı geçemediğinde hata raporu üretilmesini ister; ancak bu etiket yalnızca ruf raporlarını etkiler. Birçok büyük posta sağlayıcısı, kişisel veri içerebildiği için ruf raporu göndermez. Asıl değerli veri rua ile gelen toplu raporlardır; bu raporları nasıl yorumlayacağınızı DMARC raporu nasıl okunur yazımızda anlattık.

Politika seçenekleri: none, quarantine ve reject

p=none yalnızca gözlem sağlar, sahte iletileri engellemez. Gerçek koruma quarantine ile başlar ve reject ile tamamlanır.

Hizalama nedir? Gevşek ve sıkı mod

Hizalama, SPF'nin denetlediği zarf alan adının veya DKIM imzasındaki d= alan adının From alan adıyla eşleşmesidir. Gevşek modda aynı organizasyonel alan adı yeterlidir; sıkı modda adlar birebir aynı olmalıdır.

Türkiye'deki alan adları için bir ayrıntı önemlidir: com.tr bir genel sonek (public suffix) olduğundan example.com.tr alan adının organizasyonel alan adı kendisidir. Yani mail.example.com.tr ile gevşek modda hizalanır, ancak başka bir com.tr alan adıyla asla hizalanmaz. RFC 7489 bu belirlemeyi Public Suffix List ile yapıyordu; RFC 9989 ise _dmarc kayıtlarını DNS'te yukarı doğru sorgulayan "DNS ağaç yürüyüşü" (DNS Tree Walk) yöntemini kullanır. Ana alan adınızda açık bir DMARC kaydı yayımlamak, her iki yöntemde de sonucu netleştirir.

Adım adım kademeli DMARC geçişi

Doğrudan p=reject ile başlamak, unutulmuş bir fatura veya bülten sisteminin iletilerinin kaybolmasına yol açabilir. Güvenli bir geçiş planı şöyledir:

1. Envanter çıkarın: Alan adınızla gönderim yapan tüm sistemleri listeleyin (posta sunucusu, Microsoft 365 veya Google Workspace, CRM, fatura ve destek sistemleri).
2. İzlemeye başlayın: p=none ve rua adresi içeren kaydı yayımlayın.
3. Raporları analiz edin: En az iki ila dört hafta boyunca raporlarda hizasız kalan meşru kaynakları belirleyin.
4. Kaynakları düzeltin: Her meşru kaynak için SPF kaydını güncelleyin ve kendi alan adınızla DKIM imzalamayı etkinleştirin.
5. Karantinaya geçin: p=quarantine politikasını yayımlayın ve birkaç hafta boyunca raporları ve kullanıcılardan gelen geri bildirimleri izleyin.
6. Reddetmeye geçin: Raporlar temiz kaldığında p=reject politikasına geçin ve izlemeyi sürdürün.

RFC 7489 döneminde politikayı iletilerin bir yüzdesine uygulamak için pct etiketi (örneğin pct=25) kullanılırdı. RFC 9989, bu etiketin pratikte tutarlı uygulanmadığını belirterek onu kaldırdı ve yerine t (test) bayrağını getirdi. Kademeli geçişte asıl güvenceniz yüzdeler değil, her adımdan önce raporları dikkatle incelemektir.

Alt alan adları ve sp etiketi

sp etiketi yalnızca organizasyonel alan adının kaydında anlamlıdır ve var olan alt alan adlarının politikasını belirler. Belirtilmezse p değeri alt alan adlarına da uygulanır. Bir alt alan adının kendi _dmarc kaydı varsa o kayıt önceliklidir. RFC 9989 ile gelen np etiketi ise DNS'te hiç var olmayan alt alan adlarını kapsar; saldırganların fatura.example.com.tr gibi uydurma adlarla gönderim yapmasını zorlaştırmak için np=reject kullanılabilir.

Hiç e-posta göndermeyen alan adlarınızı da unutmayın; saldırganlar korumasız bu alan adlarını kolayca taklit edebilir. Bu alan adlarında v=spf1 -all SPF kaydıyla birlikte v=DMARC1; p=reject DMARC kaydı yayımlamak, taklidi zahmetsizce engeller.

Rapor adresi başka bir alan adındaysa ne yapılır?

rua adresi farklı bir alan adına aitse (örneğin bir rapor analiz hizmeti), o alan adının bu raporları kabul ettiğini DNS'te beyan etmesi gerekir:

example.com.tr._report._dmarc.rapor-ornek.net.  3600  IN  TXT  "v=DMARC1"

Bu kayıt yoksa alıcılar raporları göndermez ve kurulumun çalışmadığını uzun süre fark etmeyebilirsiniz.

DMARC kaydı nasıl doğrulanır?

Kaydı yayımladıktan sonra dig TXT _dmarc.example.com.tr +short komutuyla sorgulayıp dönen metnin v=DMARC1 ile başladığını kontrol edin. Bir test iletisinin Authentication-Results başlığında dmarc=pass görmeniz ve ilk toplu raporların bir iki gün içinde gelmesi, kurulumun uçtan uca çalıştığını gösterir.

Sık yapılan DMARC hataları

• Yıllarca p=none politikasında kalıp hiçbir koruma sağlamamak.
• rua adresi tanımlamadan kayıt yayımlamak ve raporları hiç görmemek.
• Üçüncü taraf göndericileri kendi alan adınızla DKIM imzalamaya geçirmeden reject politikasına geçmek.
• Aynı ad üzerinde birden fazla DMARC kaydı yayımlamak; bu durumda alıcılar politikayı yok sayar.

MXZilla'in DMARC rapor analizi, rua adresine gelen XML raporlarını okunabilir bir panelde özetleyerek hangi kaynakların hizalı geçtiğini görmenizi kolaylaştırır. Gelen posta tarafında ise her iletinin DMARC sonucu filtreleme kararında kullanılır.

Kayıtlarınızın mevcut durumunu görmek için ücretsiz güvenlik kontrolü ile başlayabilir, DMARC raporlaması ve gelen posta koruması için paketlerimizi inceleyebilirsiniz. DMARC politikanız quarantine veya reject düzeyine ulaştığında, marka logonuzu gelen kutusunda göstermenizi sağlayan BIMI için de ön koşulu sağlamış olursunuz.

Sık sorulan sorular

DMARC için SPF ve DKIM'in ikisi birden gerekli mi?

DMARC'ın geçmesi için ikisinden birinin hizalı şekilde geçmesi yeterlidir. Yine de ikisini birlikte yapılandırmak önerilir, çünkü yönlendirilen iletilerde SPF bozulurken DKIM imzası çoğu zaman geçerliliğini korur. İki mekanizma birbirinin yedeği gibi çalışır.

p=none politikası alan adımı korur mu?

Korumaz. p=none alıcılardan yalnızca rapor göndermelerini ister ve sahte iletilere herhangi bir işlem uygulanmaz. Bu politika, gönderim kaynaklarını keşfetmek için kullanılan geçici bir izleme aşamasıdır.

DMARC kaydı nereye eklenir?

DMARC kaydı, alan adının _dmarc alt adına TXT kaydı olarak eklenir; example.com.tr için kayıt adı _dmarc.example.com.tr olur. Kaydı doğrudan alan adının kendisine eklemek işe yaramaz. Bir alan adı için yalnızca tek bir DMARC kaydı bulunmalıdır.

Gmail ve Yahoo DMARC kaydı istiyor mu?

Toplu gönderim yapanlar için istiyor. Gmail ve Yahoo'nun gönderici kuralları, yüksek hacimli göndericilerden en az p=none politikalı bir DMARC kaydı ve From alanıyla hizalı kimlik doğrulama bekler. Ayrıntıları Gmail ve Yahoo toplu gönderici kuralları yazımızda bulabilirsiniz.

DMARC reject politikasına geçmek ne kadar sürer?

Süre, gönderim kaynaklarınızın sayısına ve raporlardaki tabloya bağlıdır. Az sayıda göndericisi olan bir şirket birkaç hafta içinde geçiş yapabilirken çok sayıda üçüncü taraf hizmet kullanan kuruluşlarda süreç birkaç ayı bulabilir. Önemli olan, her aşamaya raporlar temiz göründüğünde geçmektir.