DMARC nedir? p=none'dan p=reject'e güvenli geçiş planı

SPF zarf göndericisinin (MAIL FROM) alan adını, DKIM imzadaki d= alan adını doğrular; ikisi de kullanıcının gördüğü From satırıyla doğrudan ilişkili değildir. DMARC bu boşluğu kapatır: SPF ya da DKIM geçmeli ve geçen alan adı From alan adıyla hizalı olmalıdır. İkisinden biri yeter; RFC 9989 yine de ikisini birden kurmanızı önerir.

Sınırları: DMARC yalnızca From alan adının birebir taklidini hedefler. ornek.com yerine omek.com gibi benzer alan adlarını ve görünen adı (display name) kapsamaz. Geçmesi iletinin gelen kutusuna gireceği anlamına da gelmez. Son karar alıcıdadır; politikanıza uymak zorunda değildir (RFC 9989 §1, §2.2, §5.4).

Hizalama, From alan adı ile doğrulanan alan adının aynı kuruluşa ait olması demektir. İki kip vardır: relaxed (esnek; r, varsayılan) iki alan adının kuruluş alan adı (organizational domain; ornek.com gibi, alt alanların bağlı olduğu ana ad) aynıysa hizalı sayar, strict (katı; s) alan adlarının birebir aynı olmasını ister. Kipi DKIM için adkim, SPF için aspf belirler. RFC 9989'a göre alan adı sahiplerinin neredeyse tamamı relaxed kipi yeterli bulmuştur.

From alan adı ornek.com iken, SPF'de zarf göndericisinin (Return-Path) ve DKIM'de imzadaki d= alan adının durumu:

Sık görülen tuzak: Bir hizmet sizin adınıza gönderirken kendi alan adıyla imzalarsa (d=gonderim.example.net) DKIM "geçer" ama hizalanmaz; DMARC bunu saymaz. Çözümü "Üçüncü taraf gönderenler" bölümünde.

Kaydı yayımlamadan önce SPF ve DKIM çalışmalı, rapor adresi hazır olmalıdır (RFC 9989 §5.1.4; SPF için SPF kaydı nedir?). Rapor adresi için kişisel kutunuzu değil, ayrı bir kutu ya da grup açın: Google Workspace belgesi, büyük kuruluşların günde yüzlerce, hatta binlerce rapor alabileceğini yazıyor.

_dmarc.ornek.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

• v=DMARC1: sürüm. İlk etiket olmalı ve aynen bu yazılmalı, yoksa kayıt yok sayılır.
• p=none: alıcıdan işlem istemez; yalnızca izlemedesiniz.
• rua=mailto:...: toplu raporların (aggregate report) gideceği adres. Yazmazsanız alıcılar rapor üretmez.

Kayıt _dmarc adında, TXT türünde ve tek olmalıdır (RFC 9989 §4.10); TXT için DNS kayıt türleri sayfasına bakın. Panelde hangi alana ne yazacağınızı DNS raporumuzdaki "Düzeltilmesi gerekenler" bölümünde, DMARC bulgusunun altındaki "Nasıl eklenir?" bloğunda bulursunuz: cPanel ve DirectAdmin için alanlar ve kopyala düğmeleri orada. Kayıt yoksa raporumuz hazır bir kayıt önerir; öneri p=none ile başlar, yani yalnızca izler ve iletilerin akışını değiştirmez.

Kaydı herhangi bir yerden sorgulayabilirsiniz. Google'ın kaydı, 26 Ekim 2026 (çıktı zamanla değişebilir):

$ dig +short TXT _dmarc.google.com @8.8.8.8
"v=DMARC1; p=reject; rua=mailto:[email protected]"

Windows'ta eşdeğeri nslookup -type=TXT _dmarc.google.com 8.8.8.8. Uzun kayıtlar tırnaklı birkaç parça olarak dönebilir (26 Ekim 2026'da amazon.com'un kaydı böyleydi); alıcı parçaları birleştirir (RFC 9989 §4.5). Raporumuzun terminal çıktısında (curl ipsorgu.net/dns/google.com) aynı kayıt şöyle görünür:

DMARC    Geçerli   p=reject · rua tanımlı

Politika (p) alıcıdan ne istediğinizi söyler: none işlem istemez, yalnızca rapor ister; quarantine başarısız iletileri şüpheli sayar (çoğunlukla spam klasörü); reject geçersiz sayar ve reddetmeyi ister. Adımlar:

1. p=none ve rua yayımlayın. RFC 9989 buna izleme kipi (Monitoring Mode) der; p=none alıcıların posta işleyişini değiştirmemelidir (§5.4). Raporumuz bu kayıt için uyarı ve "Zayıf" etiketi verir: kayıt hatalı değil, yalnızca henüz koruma sağlamıyor.
2. Raporlardan gönderenleri çıkarın. Her kaynak IP için sorun: Bu benim mi? Benimse neden hizalanmıyor? Meşru olup hizalanmayan akışlar, politikayı sıkılaştırmadan önce düzeltilmelidir (§5.1.6).
3. p=quarantine. Meşru iletilerin spam klasörüne düşüp düşmediğine bakın: kullanıcı şikâyetleri, raporlardaki disposition ve reason alanları. Listelerden ve yönlendirmeden geçen iletiler hizalamayı bozabilir.
4. p=reject (isteğe bağlı). Yalnızca meşru her akışın DKIM ile hizalı olduğundan eminseniz.

Ne kadar beklemeli?

Tek bir takvim yok; kaynaklar bile ayrışıyor. Google Workspace belgesi, p=none için bir haftanın genellikle tüm posta akışlarını temsil eden veriye yettiğini yazar. RFC 9989 ise gönderim ritmine göre "birçok ay" sürebileceğini söyler (§5.1.7); p=reject yayımlamak isteyen ve kullanıcıları e-posta listelerine yazabilen alan adlarına p=none için en az bir ay, ardından p=quarantine için aynı süreyi önerir (§7.4). Ölçütünüz kapsam olsun: yılda bir giden fatura gibi seyrek akışlar da raporda hizalı görünmeden bir üst kademeye geçmeyin.

reject her zaman hedef değildir

RFC 9989, kullanıcıları e-posta listelerine yazabilen genel amaçlı alan adlarının p=reject yayımlamamasını önerir; yayımlayanın da yalnızca SPF'ye güvenmeyip geçerli DKIM imzası kullanması gerekir (§7.4, §8). Uyarı kullanıcıları olan alan adları içindir; yalnızca sistemlerin ileti gönderdiği alan adları (fatura, bildirim) kapsam dışıdır. Microsoft, meşru kaynaklar hizalandıktan sonra en etkili ayarın p=reject olduğunu söylüyor. Alıcılar farklı davranır: RFC 9989, alıcıların yalnızca p=reject gördükleri için ileti reddetmemesini ister (§5.4); Yahoo ise p=reject korumalı alan adlarında hizalanmayan iletileri reddettiğini yazıyor.

ruf'a güvenmeyin. RFC 9991'e göre hata raporları ileti başlıklarını, bazen iletinin tamamını içerebilir; kişisel veri taşıyabilir. Gmail ruf'u desteklemediğini, Outlook.com göndermeyi planlamadığını, Microsoft 365 göndermediğini belgelerinde yazıyor. İzlemeyi rua raporlarına kurun.

rua başka bir alan adındaysa. Adres, kaydın kuruluş alan adının dışındaysa (örneğin bir rapor hizmeti), alıcı yetkiyi DNS'ten sorar: adresin alan adında ornek.com._report._dmarc.rapor.example.net adlı, değeri v=DMARC1; olan bir TXT kaydı olmalıdır. Kaydı rapor alan taraf ekler; yoksa alıcılar rapor göndermez (RFC 9990 §4).

DMARC'ın ilk tanımı RFC 7489'du (Mart 2015). Mayıs 2026'da IETF onu üç belgeyle değiştirdi: RFC 9989 (protokol), RFC 9990 (toplu raporlar), RFC 9991 (hata raporları). RFC 9989 standart izindedir (Standards Track, Proposed Standard) ve RFC 7489 ile RFC 9091'i geçersiz kılar. Kayıt hâlâ v=DMARC1 ile başlar.

• Kaldırılanlar: pct, rf (hata raporu biçimi), ri (rapor aralığı). RFC 9989 Ek A.6: pct, 0 ve 100 dışında alıcılar arasında çok farklı uygulanıyordu; 0 ise bazı aracılar için From satırını yeniden yazma işareti olmuştu.
• Eklenenler: np, psd, t. t=y, politikanın bir kademe hafif uygulanmasını ister (reject yerine quarantine, quarantine yerine none); raporları ve p=none kaydını etkilemez. RFC, t=y ile t=n'yi eski pct=0 ve pct=100'ün karşılığı sayar.
• Kuruluş alan adı: Genel Sonek Listesi (PSL) yerine DNS ağacı yürüyüşü (DNS Tree Walk) geldi: alıcı _dmarc kaydını alan adından başlayıp soldan etiket atarak arar. Eski ve yeni uygulama farklı sonuca varabilir; strict hizalama ve kullandığınız her From alan adı için açık kayıt bunu önler (Ek C.3).

Doğrulayamadıklarımız. Standart iki şeyi söylemiyor: alıcıların eski pct etiketini ne kadar süre uygulayacağını ve hangi alıcıların t ile np etiketlerini bugün uyguladığını. IANA kayıt defteri pct, rf, ri etiketlerini "historic" (hiçbir güncel uygulamada kullanılması beklenmeyen) diye işaretler; bu bir beklentidir, ölçüm değil. Google Workspace (22 Ekim 2026) ve Microsoft 365 (17 Temmuz 2026) yönetici belgeleri hâlâ pct anlatıp RFC 7489'a atıf yapıyor; ikisinin etiket listesinde t ya da np yok.

Ne yapmalı? Yeni kayıtta pct yazmayın; mevcut pct=100 (varsayılan) kalabilir. t=y kullanırsanız: RFC 7489 bilinmeyen etiketlerin yok sayılmasını şart koşar, yani t'yi tanımayan alıcı p değerini tam uygular; p=reject; t=y her alıcıda yumuşak sonuç vermez.

Rapor göndermek alıcılar için zorunlu değil, önerilir (RFC 9989 §1); gönderenler toplu raporu rua adresinize e-postayla, günlük ya da daha sık yollar. Ek XML'dir ve gzip ile sıkıştırılması önerilir; adı alıcı!alanadı!başlangıç!bitiş.xml.gz biçimindedir, zamanlar Unix saniyesidir (RFC 9990 §3.5.2). Örnek, RFC 9990 şemasına göre doğrulanmış bir raporun kısaltılmış hâlidir (adresler belgeleme aralığından):

<feedback xmlns="urn:ietf:params:xml:ns:dmarc-2.0">
  <policy_published><domain>ornek.com</domain><p>none</p></policy_published>
  <record>
    <row><source_ip>192.0.2.25</source_ip><count>412</count>
      <policy_evaluated><disposition>none</disposition><dkim>fail</dkim><spf>fail</spf></policy_evaluated></row>
    <auth_results>
      <dkim><domain>gonderim.example.net</domain><selector>s1</selector><result>pass</result></dkim>
      <spf><domain>bounce.gonderim.example.net</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

• policy_published: alıcının gördüğü kaydınız; p değerini burada doğrularsınız.
• Her record: kaynak IP (source_ip), ileti sayısı (count) ve alıcının uyguladığı işlem (disposition: none, pass, quarantine, reject).
• policy_evaluated hizalı sonucu, auth_results ham SPF ve DKIM sonucunu verir. Burada ham sonuçlar pass, hizalı sonuçlar fail: imza ve zarf göndericisi gonderim.example.net alan adına ait, ornek.com'a değil; tanımadığınız ama büyük olasılıkla meşru bir hizmet. Aynı raporun ikinci kaydında 203.0.113.77 adresinden 38 ileti var, DKIM imzası yok, SPF başarısız: taklit.

Önce count değeri büyük, başarısız kaynakları tanıyın: meşruysa düzeltin, değilse sıkılaştırınca engellenecek akış budur. Raporlar toplu hâlde elle okunmaz (RFC 9990 §9.2); RFC 9989 raporları işleyen üçüncü taraf hizmetleri ya da kendi araçlarınızı sayar. Gelen dosya güvenilmeyen veridir: RFC 9990 §8 sahte raporlara ve sıkıştırma ya da XML bombasına karşı uyarır.

Bülten, CRM, fatura ya da destek yazılımı gibi hizmetler From satırında sizin alan adınızı kullanır ama kendi sunucularından gönderir. Hizmet kendi alan adıyla imzalıyor ve kendi zarf göndericisini kullanıyorsa SPF ve DKIM "geçer" ama hizalanmaz (yukarıdaki raporun ilk kaydı). Çözüm, hizmetin panelinde alan adınızı doğrulamaktır:

• DKIM: Hizmetin belgesindeki kayıtları (CNAME ya da TXT) DNS'inize ekleyin; imza d=ornek.com ile atılır ve hizalanır.
• SPF: Hizmet zarf göndericisini alan adınızın bir alt alanına çevirebiliyorsa SPF de hizalanır (RFC 7960 §4.1.1). Çeviremiyorsa DKIM tek başına yeter.

İsterseniz hizmete ayrı bir alt alan (bulten.ornek.com) verin; kendi politikasını taşıyabilir. Anahtar yönetimini üçüncü tarafa bırakmak risklidir; CNAME ve alt alan riski azaltabilir (RFC 7960 §4.1.1). Bir alt alanın DNS'ini ya da DKIM anahtarını başkası yönetiyorsa relaxed kip ona ana alan adınız adına DMARC geçirme gücü verir; RFC 9989 §11.8 alt alanların denetimini devretmemeyi ve uygunsa strict kipi düşünmeyi önerir. Strict, alt alandan imzalayan meşru hizmetleri de hizasız bırakır.

E-posta listeleri ve yönlendirme

Yönlendiren sunucu zarf göndericisini olduğu gibi bırakırsa SPF başarısız olur, kendi alan adını koyarsa SPF geçer ama hizalanmaz; DMARC'ı DKIM geçirmek zorundadır. Liste yazılımı iletiyi değiştirirse (konuya ya da alt bilgiye ekleme) DKIM de bozulur (RFC 7960 §2.2, §2.3). p=reject varsa liste iletisi reddedilebilir ve liste yazılımı alıcının aboneliğini iptal edebilir; RFC 9989 §7.4'e göre liste yazılımlarının tümü bunun için From satırını yeniden yazan çözümler benimsemiştir. Google, toplu gönderici hizalama şartını yönlendirilen ve liste iletilerine uygulamadığını yazıyor.

ARC (Authenticated Received Chain, RFC 8617), araya giren her sunucunun iletiyi aldığı andaki kimlik doğrulama sonucunu imzalı bir zincire eklemesini sağlar; sonraki alıcı özgün sonucu görebilir. RFC 8617 "Experimental" statüsündedir; RFC 9989 yayımlandığı sırada bu tür yöntemlerin hiçbirinin yaygınlaşmadığını yazar. Yahoo yönlendirme yapanlara, Microsoft liste ve yönlendirme için ARC'yi öneriyor.

E-posta göndermediğiniz bir alan adında meşru posta olmadığı için sıkı politika yan etki doğurmaz. Üç kayıt yeter:

ornek.com.         IN  TXT  "v=spf1 -all"
ornek.com.         IN  MX   0 .
_dmarc.ornek.com.  IN  TXT  "v=DMARC1; p=reject;"

• v=spf1 -all: hiçbir sunucu yetkili değildir. RFC 7208 §10.1.2 bunu posta göndermeyen alan adları için "iyi yerleşmiş en iyi uygulama" sayar.
• MX 0 . (null MX, RFC 7505): alan adı posta kabul etmez; göndericiler yeniden denemek yerine hemen hata alır.
• p=reject: sp yazılmadıysa alt alanlar da bu politikayı kullanır. SPF böyle değildir; RFC 7208 §3.5, alt alanlar için ayrı kayıt (ya da joker kayıt) ister.

Gerçek örnek: IANA, example.com ve example.org'u belgeleme için tutar; example.com, example.net ve example.org bu üç kaydı yayımlıyor (26 Ekim 2026; çıktı zamanla değişebilir):

$ dig +short TXT example.com @8.8.8.8 | grep spf1
"v=spf1 -all"
$ dig +short MX example.com @8.8.8.8
0 .
$ dig +short TXT _dmarc.example.com @8.8.8.8
"v=DMARC1;p=reject;sp=reject;adkim=s;aspf=s"

rua zorunlu değil; Microsoft'un park edilmiş alan adı örneği de yazmaz. Yazarsanız adres posta almayan bu alan adında olamaz: başka bir alan adındaki adresi kullanıp yetki kaydını ekleyin.

Üç büyük alıcının DMARC şartı benzer: kayıt olmalı, p=none yeter, SPF ya da DKIM'den biri From alan adıyla hizalı geçmeli. Kurallar değişebilir.

• Google (Gmail): Kişisel Gmail hesaplarına 24 saat içinde 5.000'e yakın ya da daha fazla ileti gönderen "toplu gönderici" sayılır; aynı birincil alan adından gidenler birlikte sayılır, durum kalıcıdır. Şart: SPF, DKIM ve DMARC (politika none olabilir); doğrudan iletilerde From alan adı SPF ya da DKIM alan adıyla hizalı olmalı. Şartlar 1 Şubat 2024'te başladı; Kasım 2025'ten itibaren uymayan trafikte geçici ve kalıcı reddetmeler dahil aksamalar var. DMARC kaydı yoksa Gmail 4.7.31 koduyla geçici hız sınırı uygular.
• Yahoo: Eşik açıklanmamış; "önemli hacimde" gönderenler toplu sayılır. Şart: en az p=none ile geçerli DMARC, DMARC'ın geçmesi, From alan adının SPF ya da DKIM alan adıyla hizalı olması; rua kesinlikle önerilir, relaxed hizalama kabul. Uygulama Şubat 2024'te başladı, kademeli yaygınlaştırıldı.
• Microsoft (Outlook.com, Hotmail, Live.com, MSN): Microsoft'un tüketici hizmetlerine 5.000 veya daha fazla ileti gönderen ve hepsinde aynı From alan adını kullananlar (2 Nisan 2025 duyurusu günde 5.000'den fazla ileti diyor). Şart: SPF ve DKIM geçmeli, en az p=none DMARC kaydı olmalı, SPF ya da DKIM hizalı olmalı. Duyuru uygulama tarihini 5 Mayıs 2025 verir; uymayan iletiler 550 5.7.515 ile reddedilir.

p=none taklit iletileri engellemez; taklidi engellemek istiyorsanız yukarıdaki planı izleyin.

• İki DMARC kaydı ya da v=DMARC1'in ilk etiket olmaması: kayıt yok sayılır (RFC 9989 §4.7, §4.10). Raporumuz iki kaydı hata olarak işaretler.
• Alan adının iki kez yazılması. Bazı paneller alan adını kendisi ekler; ad alanına _dmarc.ornek.com yazarsanız _dmarc.ornek.com.ornek.com oluşabilir (Google belgesi uyarıyor). Ekledikten sonra dig ile kontrol edin.
• SPF'yi -all ile bitirip DKIM'e güvenmek. Bazı alıcılar SPF başarısızlığında iletiyi DMARC'a bakmadan SMTP oturumunun başında reddedebilir; böyle iletiler toplu raporlarda hiç görünmez (RFC 9989 §7.1).
• Alt alan adını sorgulayıp "kayıt yok" görmek. Raporumuz yalnızca sorguladığınız adın kendi _dmarc kaydına bakar; ana alan adının politikası alt alan için geçerli olsa bile "kayıt yok" çıkabilir.

Raporumuz şunları işaretler: kayıt yok, birden fazla kayıt, geçersiz ya da eksik p (hata); p=none, rua yok (uyarı); p none değilken pct 100'ün altında, t=y, sp=none (bilgi). adkim, aspf, ruf, fo ve np değerlendirilmez.