# 30 günde DMARC: p=none değerinden p=reject değerine Kanonik URL: https://brew.new/tr/blog/dmarc-p-none-to-reject-in-30-days Yazar: Thomas Park Yayımlandı: 2026-10-04 Güncellendi: 2026-10-04 DMARC, `_dmarc.` 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](https://redsift.com/blog/email-authentication-bespinlabs-redsift) 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](https://easydmarc.com/blog/dmarc-adoption-across-fortune-500-and-inc-5000-the-growing-divide/) 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](https://www.rfc-editor.org/rfc/rfc9989.html) ve toplu raporlama için [RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html). 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](https://www.rfc-editor.org/rfc/rfc7208.html#section-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. ```dns 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 ` 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](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure), 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ı `._domainkey.` adresinden alır. `d=vendor-mail.example` ile imzalayan bir araç DKIM kontrolünden geçer ama DMARC’tan kalır. [RFC 8301](https://www.rfc-editor.org/rfc/rfc8301.html), 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](https://support.google.com/mail/answer/81126) 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. ```dns 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ı](https://www.m3aawg.org/sites/default/files/m3aawg-dkim-key-rotation-bp-2019-03.pdf), 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: | Mod | Etiket | Kontrolü geçen SPF/DKIM alan adı | From alan adı | Hizalı mı? | |---|---|---|---|---| | Esnek (relaxed, varsayılan) | `aspf=r`, `adkim=r` | `bounce.example.com` | `mail.example.com` | Evet, kurumsal alan adı aynı | | Katı (strict) | `aspf=s`, `adkim=s` | `bounce.example.com` | `mail.example.com` | Hayır, adların birebir eşleşmesi gerekir | | İkisi de | | `vendor.example.net` | `example.com` | Hayır | 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 ![Dört aşamalı 30 günlük DMARC zaman çizelgesi: 1–7. günlerde rua raporlamasıyla p=none, 8–14. günlerde göndericilerin düzeltilmesi, 15. gün p=quarantine, 22. gün p=reject, 30. günden itibaren BIMI; her aşama için birebir TXT kaydıyla.](/images/blog/dmarc-p-none-to-reject-in-30-days-timeline.png) *Her aşamanın kaydı. Bir sonraki aşamaya ancak raporların sorunsuz geçtiği bir haftanın ardından geçin.* | Günler | Politika | Yapılacaklar | Geçiş koşulu | |---|---|---|---| | 1–7 | `p=none` | `rua` ile yayımlayın, tüm kaynakları listeleyin | Google, Yahoo ve Microsoft’tan 7 günlük rapor | | 8–14 | `p=none` | DKIM ve SPF’i düzeltin, kullanılmayan göndericileri kaldırın | Tüm meşru kaynaklar hizalanmış SPF ya da DKIM kontrolünden geçiyor | | 15–21 | `p=quarantine` | Karantinaya alınan meşru e-postaları takip edin | Hiçbir meşru kaynağın kontrolden kalmadığı 7 gün | | 22–30 | `p=reject` | Raporları okumaya devam edin, `np=reject` ekleyin | Bir hafta boyunca sorunsuz | | 30+ | `p=reject` | BIMI çalışmasına başlayın | Sertifika düzenlendi | İ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 ```dns _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.` 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](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) 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: ```xml 192.0.2.123 123 none fail fail bounces.vendor.example example.com vendor.example abc123 pass bounces.vendor.example pass ``` `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: | Rapordaki örüntü | Olası neden | Yapılacak işlem | |---|---|---| | Hizalanmış DKIM ya da SPF başarılı | Doğru yapılandırılmış | Gerekmiyor | | DKIM ve SPF, firma alan adları için başarılı | Kendi kimliğini kullanan bir SaaS aracı | Özel DKIM’i açın | | Hizalanmış DKIM başarılı, SPF başarısız; posta kutusu sağlayıcısının ya da bir listenin IP’si | Yönlendirme ya da bir e-posta listesi | Genellikle gerekmiyor. Hizalanmış DKIM yönlendirmeden etkilenmez | | DKIM yok, SPF başarısız; kime ait olduğu belirlenemeyen IP’ler | Kimlik sahteciliği | Gerekmiyor. `p=reject` tam da bunu durdurur | 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ı](https://support.google.com/mail/answer/14229414) 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 ```dns _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 ```dns _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: | Gereksinim | Ayrıntı | Kaynak | |---|---|---| | DMARC politikası | Kurumsal alan adında ve From alan adında `p=quarantine` ya da `p=reject` | BIMI taslağı | | Alt alan adı politikası | `sp` yayımlanmışsa `none` olmamalı | BIMI taslağı | | Yüzde | Quarantine kullanılıyorsa `pct` 100’ün altında olmamalı | BIMI taslağı | | Logo | SVG Tiny PS: `baseProfile="tiny-ps"`, `version="1.2"`, bir `` öğesi; betik ya da harici referans yok, kök öğede `x=` veya `y=` yok | BIMI Group | | Sertifika | Gmail bir VMC (tescilli marka gerekir, onay işareti çıkar) ya da bir CMC (tescilli marka gerekmez, onay işareti çıkmaz) ister | Google | [BIMI taslağı](https://datatracker.ietf.org/doc/draft-brand-indicators-for-message-identification/) 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](https://bimigroup.org/creating-bimi-svg-logo-files/), 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](https://workspaceupdates.googleblog.com/2024/09/gmail-additional-bimi-protections.html). [BIMI Group uygulama rehberine](https://bimigroup.org/implementation-guide/) göre kayıt şöyle: ```dns 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. | | Gmail | Yahoo | Outlook.com | |---|---|---|---| | Eşik | Birincil alan adı başına kişisel Gmail hesaplarına günde 5.000’e yakın e-posta; bir kez ulaşıldığında kalıcı | Toplu göndericiler; sayı belirtilmemiş | From alan adı başına outlook.com, hotmail.com ve live.com adreslerine günde 5.000’in üzerinde e-posta | | SPF ve DKIM | İkisi de | İkisi de | İkisinden de geçilmeli | | DMARC | Kayıt zorunlu, `p=none` kabul ediliyor | En az `p=none`; `rua` şiddetle öneriliyor | En az `p=none` | | Hizalama | SPF ya da DKIM | SPF ya da DKIM; esnek hizalama yeterli | SPF ya da DKIM | | Uyulmazsa | Kasım 2025’ten beri geçici ve kalıcı retler | Belirtilmemiş | `550 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.` | Kaynaklar: [Google’ın gönderici yönergeleri](https://support.google.com/mail/answer/81126) ve [SSS sayfası](https://support.google.com/mail/answer/14229414), [Yahoo’nun göndericiler için önerdiği en iyi uygulamalar](https://senders.yahooinc.com/best-practices/), Microsoft’un [Nisan 2025 duyurusu](https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%e2%80%99s-new-requirements-for-high%e2%80%90volume-senders/4399730) ve [5.7.515 destek sayfası](https://support.microsoft.com/en-us/outlook/fix-ndr-error-550-5-7-515-in-outlook-com). 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](/tr/blog/agent-email-deliverability) yazımıza ve [teslim edilebilirlik rehberimize](/tr/blog/email-deliverability) göz atın. ## Brew gönderim alan adında DMARC Brew, [alan adı kurulumunda](https://docs.brew.new/get-started/verify-your-sending-domain) ş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: ```dns ; 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ı](/tr/blog/transactional-emails) 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](https://bimigroup.org/understanding-bimi-certificate-types/), Yahoo ve Fastmail dâhil birkaç sağlayıcının sertifikası olmayan, beyana dayalı logoları da gösterdiğini belirtiyor.