DMARC Kaydı Nasıl Oluşturulur?

Sesli Dinle — Makale

DMARC (Domain-Based Message Authentication, Reporting, and Conformance) kaydı, DNS içinde _dmarc etiketi altında yayımlanan bir TXT kaydıdır. Kayıt; alan sahibinin politika tercihini, hizalama ayarlarını ve istenen rapor hedeflerini bildirir.

DMARC kurulumu yalnız DNS paneline bir satır eklemek değildir. Alan yöneticisi önce görünen From (Gönderen) adresinde alan adını kullanan bütün meşru gönderim kaynaklarını belirler. Gönderim yetkisini denetleyen SPF (Sender Policy Framework) veya ileti imzasını doğrulayan DKIM (DomainKeys Identified Mail) başarılı olmalı; bu doğrulamada kullanılan alan adı da görünen gönderen alan adıyla hizalı olmalıdır. Yönetici bu koşulu doğruladıktan sonra DMARC politikasını yayımlar ve gerçek alıcı sonuçlarını izler.

Mayıs 2026 tarihli RFC 9989 güncel DMARC mekanizmasını, RFC 9990 toplu raporlamayı, RFC 9991 ise başarısızlık raporlamasını tanımlar. Güncel kurulumda kaldırılmış pct= etiketi yerine rapor temelli geçiş ve gerektiğinde t= test modu değerlendirilir.

DMARC Kapsamındaki Gönderim Kaynaklarının Belirlenmesi

Kurumsal posta, web sitesi bildirimleri, destek masası, fatura ve ödeme iletileri, pazarlama platformu, müşteri ilişkileri sistemi ve üçüncü taraf gönderim hizmetlerini envantere ekleyin. Her kaynak için görünen From alan adını, SMTP MAIL FROM adresini, DKIM imzasındaki d= alan adını ve gönderim sunucularının IP adreslerini kaydedin.

Bir hizmetin SPF kaydında bulunması veya DKIM açık anahtarının DNS’te yayımlanması, o hizmetten gelen iletinin DMARC denetiminden geçtiğini kanıtlamaz. Her kaynaktan kontrollü örnek ileti gönderip doğrulama sonuçlarını ve kullanılan alan adlarını inceleyin. Eski uygulamaları, yedek sistemleri ve yalnız belirli olaylarda ileti gönderen hizmetleri de bu denetime katın.

DMARC’ın koruduğu görünen From alan adı, standartta Author Domain olarak adlandırılır. E-posta adresinin @ işaretinden önceki bölümü, kişinin gerçek kimliği ve ileti içeriğinin güvenli olup olmadığı DMARC kaydının doğruladığı kapsam değildir.

SPF ve DKIM Hizalaması Yayından Önce Nasıl Denetlenir?

Bir iletinin DMARC denetiminden geçmesi için iki yolun birden başarılı olması gerekmez; en az biri hem başarılı hem hizalı olmalıdır. Standarda tam uyum için alan sahibi her iki mekanizmayı da hizalı biçimde yapılandırmalıdır. p=reject kullanırken yalnız SPF’ye güvenilmez; iletilere hizalı ve geçerli DKIM imzaları eklenmelidir. Yönlendirme SPF yolunu bozabilir; posta listesi veya aracı sistem gövdeyi değiştirirse DKIM yolu bozulabilir.

Relaxed (gevşek) hizalama, doğrulanmış alanla görünen From alan adının aynı kuruluş alan adına ait olmasını gerektirir. Bu, aynı yönetim yetkisinin sürdüğü alan adı hiyerarşisinin en üstündeki addır. Strict (katı) hizalama alan adlarının birebir eşleşmesini gerektirir. Varsayılan olarak DKIM için adkim=r, SPF için aspf=r kabul edilir.

Toplu Rapor ve Başarısızlık Raporu Adreslerinin Hazırlanması

Toplu raporlar için kişisel posta kutusu yerine erişimi ve saklama süresi yönetilen ayrı bir adres kullanın. rua=, RFC 9990 kapsamındaki toplu rapor hedeflerini belirtir. Bu raporlar gönderen sunucuların IP adreslerini, ileti sayılarını, politika kararlarını ve SPF, DKIM ve hizalama sonuçlarını XML biçiminde bir araya getirir.

ruf=, RFC 9991 kapsamındaki iletiye özgü başarısızlık raporlarını ister; fo= istenen koşulları etkiler. Başarısızlık raporları üstbilgi ve bazı durumlarda gövde içeriği taşıyabileceği için kişisel ve gizli veri riski daha yüksektir. Her alıcı bu raporları desteklemez.

Posta kutusunun ileti kabul ettiğini, kota ve kötüye kullanım sınırlarını, yetkili kullanıcılarını ve saklama politikasını yayından önce doğrulayın. rua= yoksa alan için toplu rapor üretilmez; rapor adresi yazmak da raporların mutlaka ulaşacağını garanti etmez.

_dmarc TXT Kaydının Temel Sözdizimi Nedir?

Başlangıç gözlemi için kullanılabilecek sade örnek şöyledir:

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

Bu adres yalnız örnektir; dmarc-reports@example.com yerine yönettiğiniz gerçek rapor adresini yazın. v=DMARC1 zorunludur, ilk etiket olmalıdır ve değeri büyük-küçük harfe duyarlıdır. Etiketler noktalı virgülle ayrılır; son etiketten sonraki noktalı virgül isteğe bağlıdır.

p= etiketinin yazılması önerilir, ancak güncel standartta bu etiketin bulunmadığı ve diğer yönlerden sözdizimi geçerli bir kayıtta p=none varsayılır. Bu varsayım için rua= bulunması şart değildir; rua= yoksa yalnız toplu raporlama talebi oluşmaz. Bilinmeyen etiketler yok sayılır, fakat v=DMARC1 eksikse, ilk sırada değilse veya değeri yanlışsa kayıt yok sayılır.

DNS paneli uzun TXT değerini aynı kayıt içinde birden fazla tırnaklı karakter dizisine bölebilir. DMARC değeri okunurken bu diziler sırayla ve araya boşluk eklenmeden birleştirilir. Aynı DNS adı altında iki ayrı v=DMARC1 kaydı oluşturmak aynı işlem değildir; alıcı bu kayıtların ikisini de yok sayar.

DMARC Etiketleri ve Varsayılan Değerleri

RFC 9989, eski pct= etiketini kaldırmıştır. t=y, p=quarantine için none, p=reject için quarantine düzeyinde uygulama isteği bildirir; p=none üzerinde etkisi yoktur. Kademeli geçiş yalnız etikete bırakılmamalı, gerçek gönderim ve rapor kanıtıyla yönetilmelidir.

DNS Yönetim Panelinde DMARC Kaydı Ekleme

1. Alan adının yetkili DNS sağlayıcısını NS kayıtlarından doğrulayın.
2. Yetkili panelde yeni TXT kaydı oluşturun.
3. Ad veya ana bilgisayar alanına panelin davranışına göre _dmarc ya da _dmarc.example.com yazın.
4. Değer alanına hazırlanan DMARC metnini tek kayıt olarak girin.
5. TTL değerini değişiklik planına ve DNS sağlayıcısının önerisine göre seçin.
6. Panelin oluşturacağı tam DNS adını önizleyin ve alan adının iki kez eklenmediğini kontrol edin.
7. Kaydı kaydedin; yetkili DNS yanıtı görünmeden politika geçişine başlamayın.

Bazı paneller alan adını otomatik ekler; böyle bir yerde tam adı yazmak _dmarc.example.com.example.com gibi yanlış bir kayıt oluşturabilir. Çoğu web paneli TXT değerini tırnaksız ham metin olarak ister ve DNS gösterim tırnaklarını kendisi yönetir. DNS sağlayıcısının bu alana ilişkin açıklamasını izleyin.

Aynı sorgu adında eski DMARC kaydı varsa yeni bir kayıt eklemek yerine mevcut kaydı dikkatle güncelleyin. Kaydetmeden önce tek bir DMARC kaydı bulunduğunu, v=DMARC1 etiketinin ilk sırada olduğunu, rapor adreslerini ve noktalı virgül ayrımlarını kontrol edin.

Harici Rapor Hedefi Nasıl Yetkilendirilir?

Rapor adresi politikayı yayımlayan alanın kuruluş alan adı içindeyse ek dış hedef yetkilendirmesi gerekmez. Farklı bir kuruluş alan adına gönderilecek rapor için hedef alan, DNS’te rapor kabul izni yayımlamalıdır; izin bulunmazsa standarda uyumlu alıcı sistem dış hedefi yok sayar.

example.com politikasındaki rua=mailto:dmarc@reports.example.net hedefi için, hedefin DNS bölgesinde aşağıdaki ad ve değer gerekebilir:

example.com._report._dmarc.reports.example.net  TXT  "v=DMARC1;"

Bir raporlama hizmeti kullanılıyorsa hizmetin verdiği hedef adı ve değeri aynen uygulanmalıdır. Rapor adresinin alt alanı, yetkilendirme sorgusundaki hedef ana bilgisayarı etkiler. Yanlış alan altında yayımlanan izin, rapor hedefini yetkilendirmez.

Yayımlanan Kayıt ve Gerçek Gönderim Nasıl Doğrulanır?

Önce yetkili DNS sunucusunu, ardından farklı recursive resolver hizmetlerini sorgulayın. Eski kaydın önbellekte kalan süresi dolana kadar bazı ağlar önceki değeri görebilir. Daha önce alınmış bir “kayıt yok” yanıtı da ayrı bir süre için önbelleğe alınabilir; yeni TXT kaydının TTL değerini düşürmek bu süreyi kısaltmaz. DNS yanıtı doğru olsa bile her gerçek gönderim hizmetinden ileti gönderip SPF ile doğrulanan MAIL FROM adresinin alan adını, DKIM imzasındaki d= alan adını ve DMARC sonucunu kontrol edin.

DMARC Kurulumunda Hangi Hatalar Nasıl Düzeltilir?

DMARC’ta İzlemeden Karantina ve Ret Politikasına Geçiş

1. Tek ve sözdizimi geçerli v=DMARC1; p=none kaydını, yönettiğiniz bir rua= rapor adresiyle yayımlayın.
2. Yetkili DNS sunucularının ve recursive resolver hizmetlerinin yanıtlarını doğrulayın; eski kayıt veya “kayıt yok” yanıtı için kalan önbellek süresini hesaba katın.
3. Bütün gerçek kaynaklardan test iletisi gönderip SPF ve DKIM sonuçlarıyla alan adı hizalamasını doğrulayın. p=reject planlıyorsanız yalnız SPF başarısını yeterli saymayın; hizalı DKIM imzasının da geçerli olduğunu kontrol edin.
4. Toplu raporlardaki bilinmeyen kaynakları ve alıcının politikanızdan ayrılma nedenlerini inceleyin; meşru iletilerdeki doğrulama ve hizalama hatalarını düzeltin.
5. Mevcut alt alanlar için sp=, var olmayan alt alanlar için np= gereksinimini ayrı değerlendirin.
6. Meşru trafik hazır olduğunda quarantine ve ardından reject politikasına geçişi değerlendirin; posta listelerine ileti gönderen kullanıcıların bulunduğu alanlarda ret politikası önerilmez. Liste trafiğine etkisini ayrıca inceleyin ve gerekiyorsa t=y test modunu kullanın.
7. Her politika değişiminden sonra gerçek alıcı sonuçlarını ve rapor eğilimlerini yeniden denetleyin.

p=none teslimat garantisi değildir; yalnız alan sahibinin DMARC başarısızlığı nedeniyle özel işlem tercihi bildirmediğini gösterir. Alıcı istenmeyen e-posta, itibar ve içerik kurallarıyla iletiyi yine sınıflandırabilir.