DMARC, _dmarc.<your domain> adresinde yayımlanan bir TXT kaydıdır. From başlığında alan adınızı kullanan ama hizalanmış SPF ve DKIM kontrollerinden geçemeyen e-postalarla ne yapılacağını ve raporların nereye gönderileceğini alıcı sunuculara bildirir. p=none yalnızca rapor ister; p=quarantine alıcı sunuculardan kontrolden geçemeyen e-postaları şüpheli saymalarını, p=reject ise bu e-postaları reddetmelerini ister.

Gmail, Yahoo ve Microsoft toplu göndericilerden p=none politikasını kabul ediyor; bu yüzden birçok alan adı bu politikayı yayımlayıp orada kalıyor ve kimlik sahteciliği yapanları engellemeden yalnızca raporluyor. Red Sift’in 73,3 milyon alan adını kapsayan ve Nisan 2026’da aktarılan analizine göre alan adlarının %14,9’unda herhangi bir DMARC politikası vardı, p=reject uygulayanların oranı ise %2,5’ti. Bir başka DMARC firması olan EasyDMARC, 2025’te yayımladığı raporda DMARC kullanan Fortune 500 şirketlerinin %62,7’sinin p=reject kullandığını, bu oranın Inc. 5000 şirketlerinde %15,2 olduğunu bildirdi.

Aşağıda, kurumsal e-posta hizmetinden, bir veya iki e-posta sağlayıcısından (ESP), bir yardım masası aracından ve bir faturalandırma aracından e-posta gönderen bir alan adını kayıt kayıt p=reject politikasına taşıyan 30 günlük bir plan bulacaksınız. Otuz gün, bir gönderim alt alan adı için uygundur. Çalışanlarınızın günlük yazışmalarında kullandığı bir alan adı daha uzun süre ister.

Öne çıkan noktalar

• v=DMARC1; p=none; rua=mailto:... kaydını ilk gün yayımlayın. rua etiketi yoksa alıcı sunucuların toplu rapor göndermemesi gerekir.
• Her meşru gönderici, From alan adınızla hizalanmış SPF ya da DKIM kontrolünden geçmelidir. Çoğu araç için bu, alan adınızla DKIM imzası atmak demektir.
• SPF kaydınızdaki DNS sorgusu gerektiren terimlerin sayısını, iç içe include ifadeleri dâhil en fazla 10 ile sınırlayın; aksi hâlde tüm e-postalarınız permerror sonucu alır.
• p=quarantine politikasına 15. gün, p=reject politikasına 22. gün geçin; her geçişi raporların sorunsuz geçtiği bir haftanın ardından yapın. Çalışanların günlük yazışmalarında kullandığı bir alan adı için RFC 9989, ilk iki aşamanın her birinde bir ay geçirilmesini istiyor.
• RFC 9989 (Mayıs 2026), pct etiketini tarihsel (historic) olarak işaretliyor. pct=10, pct=50 gibi kademeli artışları atlayın.
• BIMI için kurumsal alan adında p=quarantine ya da p=reject, sp=none olmaması, SVG Tiny PS formatında bir logo ve Gmail için bir VMC ya da CMC gerekir.

2026’da DMARC’ta neler değişti?

IETF, Mayıs 2026’da 2015 tarihli ve bilgilendirme amaçlı (Informational) bir belge olan RFC 7489’u DMARCbis ile değiştirdi: RFC 9091’i de geçersiz kılan, Önerilen Standart (Proposed Standard) statüsündeki RFC 9989 ve toplu raporlama için RFC 9990. Burada üç değişiklik önemli:

• pct artık tarihsel bir etiket. Ek A.6’ya göre bu etiket, “belirtilen değer 0 ya da 100 olmadıkça genellikle doğru uygulanmıyordu.”
• t=y, pct=0 değerinin yerini alıyor. Alıcı sunucular politikanızın bir alt seviyesini uygular; yani p=reject; t=y, quarantine gibi davranır. Bu bir test modudur.
• np yeni bir etiket. DNS’te var olmayan alt alan adlarını kapsar; eski alıcı sunucuların bu etiketi yok sayması gerekir.

Kurumsal alan adını (organizational domain) bulmak için de Public Suffix List yerine artık DNS ağacında yukarı doğru yapılan bir tarama (tree walk) kullanılıyor.

DMARC’ın dayandığı üç kayıt

SPF ya da DKIM kontrolünden geçildiğinde ve kontrolü geçen alan adı From alan adıyla hizalandığında DMARC başarılı olur. Hizalanmış tek bir başarılı sonuç yeterlidir.

SPF ve 10 sorgu sınırı

SPF, zarf (MAIL FROM ya da Return-Path) alan adı adına e-posta göndermeye yetkili sunucuları belirler; DMARC’ın kullandığı tek kimlik budur, HELO değil. RFC 7208, bölüm 4.6.4, DNS sorgusu gerektiren terimleri 10 ile sınırlar: include, a, mx, ptr, exists ve redirect; iç içe geçmiş tüm include ifadeleri boyunca sayılır. ip4, ip6 ve all sorgu sayısına dâhil edilmez. Sınır aşılırsa sonuç permerror olur. Aynı bölüm en fazla iki “boş sorguya” (void lookup) izin verir; bunlar genellikle artık var olmayan bir host adını gösteren bir include ifadesinden kaynaklanır.

example.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.helpdesk.example include:mail.billing.example ~all"

Bu kayıt, firmaların kendi kayıtlarına iç içe eklediği sorgular sayılmadan 4 sorgu harcar; bu yüzden her birini zincir boyunca dig +short TXT <name> ile çözümleyin. 10 sınırını aşmamak için artık kullanılmayan araçları kaldırın ya da her ESP’ye bounce.example.com gibi, kendi 10 sorgu bütçesi olan ayrı bir Return-Path alt alan adı verin. Microsoft’un SPF kurulum rehberi, DKIM ve DMARC da kullanan alan adlarında kaydı -all ile bitirmeyi öneriyor.

Birçok ESP varsayılan olarak kendi Return-Path alan adını kullanır ve bu alan adı sizinkiyle hizalanmaz. Özel bir Return-Path ayarlayın ya da DKIM’e güvenin.

DKIM: 2048 bitlik anahtarlar, seçiciler ve anahtar yenileme

DKIM her mesajı bir alan adı (d=) ve bir seçiciyle (selector, s=) imzalar; alıcı sunucu anahtarı <selector>._domainkey.<d domain> adresinden alır. d=vendor-mail.example ile imzalayan bir araç DKIM kontrolünden geçer ama DMARC’tan kalır.

RFC 8301, imzalayanların en az 1024 bitlik RSA anahtarları kullanmak zorunda olduğunu, 2048 bit kullanmalarının ise önerildiğini belirtiyor. Google’ın gönderici yönergeleri de kişisel Gmail hesaplarına gönderilen e-postalar için aynısını söylüyor. 2048 bitlik bir anahtar 255 karakterlik TXT dizesi sınırını aştığı için tek bir kayıtta, tırnak içine alınmış birkaç dize olarak girilir; çoğu DNS sağlayıcısı bu bölmeyi sizin için yapar.

s202610._domainkey.example.com.  3600  IN  TXT  ( "v=DKIM1; k=rsa; "
    "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAu1x..."
    "...remainder-of-the-2048-bit-key...IDAQAB" )

Her gönderim sistemine ayrı bir seçici verin ve bir adı asla yeniden kullanmayın. s202610 gibi bir tarih, geçmişi okunabilir tutar. M3AAWG’nin anahtar yenileme uygulamaları, anahtarların en az altı ayda bir yenilenmesini öneriyor:

1. Yeni seçiciyi yayımlayın ve DNS’te yayılmasını bekleyin.
2. İmzalamayı yeni anahtara geçirin.
3. Yolda olan e-postaların doğrulanabilmesi için eski açık anahtarı 7 ila 30 gün DNS’te tutun.
4. Eski seçiciyi boş bir p= değeriyle devre dışı bırakın. Silmeyin.

Hizalama: esnek mi, katı mı?

RFC 9989 iki mod tanımlar:

RFC 9989, “alan adı sahiplerinin neredeyse tamamının esnek hizalamayı yeterli bulduğunu” belirtiyor. aspf ve adkim etiketlerini hiç eklemeyin. Katı SPF hizalaması, alt alan adında kullanılan olağan Return-Path yapısını bozar.

30 günlük plan

Her aşamanın kaydı. Bir sonraki aşamaya ancak raporların sorunsuz geçtiği bir haftanın ardından geçin.

İkinci hafta kimsenin düzeltemediği bir kaynak ortaya çıkarsa p=none politikasında kalın. Kendi faturalarınızın reddedilmesi, uygulama moduna geç geçmekten daha kötüdür.

1–7. günler: p=none politikasını raporlamayla yayımlayın

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

Raporlar, her alıcı sunucudan en az günde bir kez gelen, gzip ile sıkıştırılmış XML dosyalarıdır; bu yüzden rua adresini bir kişiye değil, bir rapor işleme hizmetine yönlendirin. Adres başka bir kurumsal alan adındaysa RFC 9990, example.com._report._dmarc.<report domain> kaydı yetki vermediği sürece alıcı sunucuların bu adresi yok saymasını öngörür. Rapor işleme hizmetleri bu kaydı kendileri yayımlar; kendi alan adlarınız için kaydı siz ekleyin.

Tam olarak bir DMARC kaydı yayımlayın. Kurulum sihirbazları _dmarc.example.com adresinde iki v=DMARC1 kaydı bırakırsa alıcı sunucular ikisini de yok sayar.

ruf etiketini kullanmayın. RFC 9989, gizliliğe önem veren alıcı sunucuların hata raporlarını büyük ölçüde maskelediğini ya da hiç göndermediğini belirtiyor; Microsoft’un yüksek hacimli göndericilere yönelik duyurusundaki SSS bölümü de şirketin rua raporları gönderdiğini, ruf göndermeye ise hiç niyeti olmadığını söylüyor.

Toplu rapor nasıl okunur?

RFC 9990, her politika alan adı için bir tane olmak üzere “günlük (ya da daha sık)” XML raporlarını tanımlar. Örneğinden uyarlanmış bir kayıt:

<record>
  <row>
    <source_ip>192.0.2.123</source_ip>
    <count>123</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <envelope_from>bounces.vendor.example</envelope_from>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>vendor.example</domain>
      <selector>abc123</selector>
      <result>pass</result>
    </dkim>
    <spf>
      <domain>bounces.vendor.example</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

policy_evaluated içindeki dkim ve spf değerleri hizalama sonuçlarıdır; disposition ise alıcı sunucunun ne yaptığını gösterir. auth_results, ham sonuçları ve ilgili alan adlarını içerir. Burada ikisi de vendor.example için başarılı, dolayısıyla ikisi de hizalamadan kalıyor: Adınıza gönderim yapan ama sizin adınıza imzalamayan bir firma. Bu firmanın özel DKIM ya da alan adı doğrulama (domain authentication) özelliğini açın.

1–7. günler: bilinmeyen göndericileri bulun

Kayıtları source_ip, envelope_from ve DKIM domain ile selector değerlerine göre gruplayın, count değerine göre sıralayın ve şu kategorilere ayırın:

Bir IP’nin kime ait olduğunu bulmak için dig -x 192.0.2.123 +short komutunu çalıştırın ve çoğu zaman firmanın adını taşıyan seçiciye bakın. Ardından finans, destek ve satış ekiplerine şirket adına nelerin e-posta gönderdiğini sorun: faturalandırma, yardım masası, takvim davetleri, ofis tarayıcıları.

Yönlendirilen ve listelerden gelen e-postalar sizin düzeltemeyeceğiniz şekillerde kontrolden kalır; Google’ın gönderici SSS sayfası da bu e-postalar için hizalama şartı aramaz. Bu yüzden planı bu e-postalar yüzünden bekletmeyin.

8–14. günler: tüm meşru kaynakları düzeltin

En yüksek count değerinden başlayarak aşağı doğru ilerleyin:

1. Kurumsal e-posta (Google Workspace, Microsoft 365). Yönetici konsolunda DKIM’i açın (sunuluyorsa 2048 bit) ve sağlayıcının include ifadesinin SPF kaydınızda yer aldığını doğrulayın.
2. ESP’ler ve pazarlama araçları. Sizin d= değerinizle imzalamaları için alan adı doğrulamasını kurun; sunuluyorsa özel bir Return-Path da ayarlayın.
3. Yardım masası, faturalandırma, CRM. ESP’lerle aynı. Biri alan adınızla imzalayamıyorsa, imzalayabildiği bir alt alan adını ya da aracın kendi alan adını kullanın.
4. Kullanılmayan araçlar. Bunların include ifadelerini ve seçicilerini kaldırın.

Ardından SPF sorgularını yeniden sayın.

15. gün: p=quarantine

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

Karantina genellikle spam klasörü demektir. quarantine sonucuyla (disposition) işaretlenen meşru kaynakları takip edin. Prova yapmak isterseniz p=quarantine; t=y, RFC 9989’u uygulayan alıcı sunuculardan none uygulamalarını ister; ancak RFC yalnızca birkaç aylık ve henüz her alıcı sunucu t etiketini dikkate almıyor.

22. gün: p=reject

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

p=reject politikasını dikkate alan alıcı sunucular, kontrolden geçemeyen e-postaları SMTP oturumu sırasında reddeder; ancak RFC 9989, ellerindeki tek kanıt politika olduğunda alıcı sunuculara e-postayı karantinaya almalarını söyler. Bu yüzden bu e-postaların bir kısmı spam klasörüne düşer.

Aynı RFC’ye göre p=reject politikasındaki bir alan adı “yalnızca SPF’e dayanmamalıdır” (MUST NOT) ve DKIM ile imzalamalıdır; çünkü yönlendirme SPF’i bozar ama DKIM’i bozmaz. Önce tüm kaynaklarda hizalanmış DKIM olduğunu doğrulayın.

rua etiketini hiç kaldırmayın. Gelecek çeyrekte eklenen yeni bir araç, destek taleplerinize yansımadan önce raporlarınızda görünür.

Plan ne zaman uzatılmalı?

RFC 9989’un 7.4 numaralı bölümü, kullanıcıları e-posta listelerine ileti gönderen alan adlarının p=reject yayımlamaması gerektiğini (SHOULD NOT), yayımlayacak olanların ise önce p=none politikasında “en az bir ay”, p=quarantine politikasında da “aynı uzunlukta bir süre” geçirmesi gerektiğini söylüyor. Şirketlerin ana alan adlarının çoğu bu gruba girer; bu yüzden onlarda ilk iki aşamanın her birine bir ay ayırın. Yalnızca ESP’nizin kullandığı bir alt alan adında liste trafiği olmaz; bu alan adı 30 günlük tempoyu koruyabilir.

Alt alan adı politikası: sp= ve np=

p, alan adını ve alt alan adlarını kapsar. sp bu politikayı mevcut alt alan adları için, np ise var olmayanlar için geçersiz kılar. Kendi kaydı olan bir alt alan adı o kaydı kullanır ve RFC 9989 orada sp etiketini dikkate almaz.

mail.example.com gibi, SPF ve DKIM’i doğrulanmış tek bir ESP’nin kullandığı, yalnızca gönderime ayrılmış bir alt alan adı ilk günden p=reject yayımlayabilir. Ana alan adında p=none; sp=reject kullanmak, siz ana alan adındaki çalışmayı tamamlarken alt alan adlarını korur, ancak BIMI’yi engeller.

Microsoft’un SPF rehberine göre park edilmiş alan adları v=spf1 -all kaydını, ayrıca _dmarc adresinde v=DMARC1; p=reject; kaydını yayımlamalıdır.

30. gün ve sonrası: BIMI

BIMI, destekleyen gelen kutularında kimliği doğrulanmış e-postaların yanında logonuzu gösterir:

BIMI taslağı 14. revizyonunda (Mayıs 2026) ve hâlâ RFC 7489 temel alınarak yazılmış bir Internet-Draft; pct etiketinin geçmesinin nedeni de bu. pct etiketini eklemeyin ve t=y ayarlamayın.

Kurumsal alan adı kuralı, alt alan adından gönderim yapanları hazırlıksız yakalar: mail.example.com alan adı p=reject, example.com ise p=none politikasındaysa alıcı sunucuların logoyu göstermemesi gerekir; bu yüzden ana alan adının da planı tamamlaması şart.

BIMI Group’un SVG rehberi, düz bir arka plan üzerinde ortalanmış, kare ve 32 KB altında bir logo öneriyor. Google Eylül 2024’te CMC desteği ekledi. BIMI Group uygulama rehberine göre kayıt şöyle:

default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/bimi/logo.svg; a=https://example.com/bimi/certificate.pem"

Marka tescili aylar sürdüğü için VMC hazırlığına şimdiden başlayın.

Gmail, Yahoo ve Microsoft ne istiyor?

Üçü de uygulama modunu şart koşmuyor; yalnızca bir DMARC kaydı ve hizalama istiyor.

Kaynaklar: Google’ın gönderici yönergeleri ve SSS sayfası, Yahoo’nun göndericiler için önerdiği en iyi uygulamalar, Microsoft’un Nisan 2025 duyurusu ve 5.7.515 destek sayfası. Microsoft, 29 Nisan’daki bir güncellemeyle yaptırımı Gereksiz E-posta klasörüne taşımaktan reddetmeye çevirdikten sonra 5 Mayıs 2025’te uygulamaya başladı.

Google’ın SSS sayfası, hem SPF hem de DKIM hizalamasının “zamanla gönderici gereksinimi hâline geleceğini” söylüyor; bu yüzden ikinci haftada ikisini de hizalayın. Abonelikten çıkma ve spam oranları için e-postalarınızı bir ajan gönderdiğinde de geçerli olan kurallar yazımıza ve teslim edilebilirlik rehberimize göz atın.

Brew gönderim alan adında DMARC

Brew, alan adı kurulumunda şunları ister:

• DKIM: gönderim alan adınızın altında, bir ._domainkey seçicisinde yer alan TXT kaydı. Zorunlu.
• SPF: Brew tarafından Return-Path olarak kullanılan send.<your sending domain> adresinde bir MX ve bir TXT kaydı. Zorunlu.
• DMARC: _dmarc.<your sending domain> adresinde bir TXT kaydı. İsteğe bağlı ama önerilir.
• Tıklama izleme için bir CNAME kaydı; yalnızca özel bir izleme alt alan adı kullanıyorsanız.

SPF ve DKIM doğrulandığında alan adından gönderim yapılabilir; Brew de duruma uygun bir DMARC değeri önerir:

; dedicated sending subdomain, e.g. mail.example.com
_dmarc.mail.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@mail.example.com"
 
; apex domain, or a domain Brew can't prove is dedicated
_dmarc.example.com.       TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Ayrılmış bir alt alan adı için p=reject önerilir, çünkü Brew için gereken SPF ve DKIM doğrulanmadan önce o alan adından hiçbir şey gönderilmez. Ana alan adı için ise p=none önerilir, çünkü diğer araçlarınız da büyük olasılıkla o alan adı adına gönderim yapar; bu durumda yukarıdaki planı uygulayın. Hizalama esnek kalır, çünkü send.<domain> Return-Path alan adı yalnızca esnek modda hizalanır.

Brew, canlı _dmarc.<sending domain> kaydını alan adı eklenirken, doğrulanırken ve her yeniden kontrolde okur. Sonucu Alan adları sayfası gösterir; MCP üzerinden get_domain_health aracı ve GET /v1/domains/{domainId}/health isteği de aynı sonucu döndürür:

• dmarc_missing: eklenmesi gereken kaydı birebir gösteren bir uyarı.
• dmarc_invalid: aynı adda iki DMARC kaydı olduğunda, sürüm veya politika hatalı olduğunda ya da yinelenen etiketler bulunduğunda. Silinmesi gereken kaydı belirtir.
• Doğrulandı: tam olarak bir geçerli kayıt bulunduğunda.

Otomatik DNS kurulumu, DMARC kaydını yalnızca hiç kayıt yoksa yazar; böylece mevcut bir kaydı asla çoğaltmaz. Kontrol üst alan adında değil, gönderim alan adının kendisinde yapılır. Bu yüzden her gönderim alt alan adına ayrı bir kayıt verin; dokümantasyonun önerdiği gibi pazarlama ve işlemsel e-postaları ayırıyorsanız işlemsel e-posta alan adınıza da. Raporları okuyacağınız ve reject politikasına ne zaman geçeceğinize karar vereceğiniz yer, rua rapor işleme hizmetinizdir.

Sıkça sorulan sorular

Quarantine politikasına geçmeden önce ne kadar süre p=none politikasında kalmalıyım?

Tam bir haftalık raporlar tüm meşru kaynakların hizalanmış SPF ya da DKIM kontrolünden geçtiğini gösterene kadar; bir gönderim alt alan adı için bu genellikle bir ila iki hafta sürer. Çalışanların günlük yazışmalarında kullandığı bir alan adı için RFC 9989 en az bir ay istiyor. Raporları kimsenin okumadığı iki yıllık bir p=none dönemi hiçbir işe yaramaz.

DMARC pct etiketi kullanımdan kaldırıldı mı?

Evet. RFC 9989, pct etiketini “tarihsel” (historic) olarak listeler ve bu etiketin güvenilir olan tek değerlerinin yerine t etiketini getirir: t=y, pct=0 gibi; t=n ise pct=100 gibi davranır. Eski alıcı sunucular pct etiketini hâlâ okuyabilir, ancak ara değerleri hiçbir zaman tutarlı biçimde uygulamadılar; bu yüzden tam adımlarla ilerleyin.

p=reject, yönlendirilen e-postalarımı engeller mi?

Basit yönlendirme genellikle SPF’i bozar ama DKIM’i bozmaz; bu yüzden hizalanmış DKIM yine başarılı olur. Konu satırını ya da alt bilgiyi düzenleyen listeler DKIM’i bozar; bazıları bunu telafi etmek için From başlığını yeniden yazar. En iyi korumanız, her yerde hizalanmış DKIM kullanmaktır.

Gmail ve Yahoo p=reject şartı arıyor mu?

Hayır. İkisi de toplu göndericilerden DMARC yayımlamalarını istiyor ve p=none politikasını kabul ediyor; Outlook.com’a günde 5.000’den fazla mesaj gönderenler için Microsoft da öyle. Uygulama modu kimlik sahteciliğini durdurur ve BIMI için zorunludur, ancak üçünden hiçbiri bunu şart koşmuyor.

BIMI için VMC gerekli mi?

Gmail için ya tescilli marka gerektiren ve onay işareti gösteren bir VMC’ye ya da logoyu onay işareti olmadan gösteren bir CMC’ye ihtiyacınız var. BIMI Group, Yahoo ve Fastmail dâhil birkaç sağlayıcının sertifikası olmayan, beyana dayalı logoları da gösterdiğini belirtiyor.