DMARC quarantine ve reject: p=none’dan gerçek postayı kaybetmeden nasıl geçilir?

1. p=none, quarantine ve reject alıcılardan ne ister?

_dmarc.example.com adresindeki DMARC kaydında yer alan p etiketi, From alan adı DMARC’ı geçemeyen postaya alıcıların ne yapmasını istediğinizi belirtir; yani ne SPF ne de DKIM, onunla hizalı bir alan adı için geçmiştir. Bu bir taleptir. RFC 7489’un yerini alan ve Mayıs 2026’da yayımlanan DMARC standardı RFC 9989, son kararı her alıcının yerel politikasına bırakır.

İki nokta geçişi şekillendirir. Birincisi, p=none tek başına hiçbir şeyi korumaz; rapor üretir, o da yalnızca kayıtta bir rua adresi varsa. İkincisi, alıcıların hepsi aynı şekilde uygulamaz. RFC 9989 onlara yalnızca politika reject diyor diye reddetmemelerini söyler, bazıları bu postayı bunun yerine karantinaya alır; dolayısıyla tek bir politika değişikliği farklı posta sağlayıcılarında farklı görünebilir. Geçişi tek bir anahtar olarak değil, küçük ve geri alınabilir adımlar dizisi olarak planlayın.

Büyük posta sağlayıcıları toplu gönderenlerden zaten DMARC kaydı ister, ancak p=none’u kabul eder. SPF ve DMARC kontrol rehberi gereksinimlerini listeler ve kaydın her etiketini açıklar.

2. DMARC toplu (rua) raporları nasıl okunur?

Güvenli geçişi mümkün kılan şey toplu raporlardır. Kayda bir raporlama adresi ekleyin, örneğin rua=mailto:dmarc-reports@example.com; rapor gönderen alıcılar size, genellikle bir UTC gününü kapsayan, sıkıştırılmış bir XML dosyası yollar. Dosya, alan adınızı From satırında kullanarak posta gönderen her IP adresini ve bu postanın sonucunu listeler. Biçim RFC 9990’da tanımlıdır. receiver.example!example.com!1791590400!1791676800.xml.gz gibi bir dosya adı, raporu gönderen alıcıyı, alan adınızı ve dönemin başlangıç ile bitişini Unix zaman damgası olarak belirtir.

Dosyadaki her <record> mesajları kaynağa ve sonuca göre gruplar. En önemli alanlar şunlardır:

Son satır ile policy_evaluated arasındaki fark, öğrenmeniz gereken en yararlı şeydir. Bir bülten platformu auth_results içinde mailer.example.net için DKIM pass gösterip yine de DMARC’ı geçemeyebilir; çünkü bu alan adı example.com ile hizalı değildir. DMARC’ın vardığı sonucu yalnızca policy_evaluated söyler.

Raporları tek gün değil, birkaç hafta boyunca okuyun: aylık faturalar, üç aylık bültenler ve yıllık yenileme bildirimleri kendi takvimlerinde gelir. Hacim arttıkça ham XML yorucudur; satırları gün bazında kaynağa, hizalamaya ve disposition’a göre gruplayan bir ayrıştırıcı ya da raporlama aracı incelemeyi pratik kılar. Her alıcı toplu rapor göndermez; dolayısıyla sessiz bir hafta sessiz bir alan adı demek değildir. rua adresi başka bir kurumsal alan adındaysa, o alan adının v=DMARC1 ile başlayan, example.com._report._dmarc.reports.example.net gibi bir yetkilendirme kaydı yayımlaması gerekir; aksi hâlde alıcılar adresi yok sayar (RFC 9990, bölüm 4).

3. Uygulamadan önce meşru tüm göndericileri bulun

Uygulama, ancak alan adınızı From satırında kullanan her sistemi bildiğinizde güvenlidir. Listeyi iki yönden çıkarın: kurumun kullandıkları ve raporların gösterdikleri. Tipik kaynaklar:

• Çalışanların her gün kullandığı posta platformu.
• Birinin hâlâ giriş yaptığı eski bir kampanya aracı dâhil pazarlama ve bültenler.
• Uygulamanızdan giden işlemsel postalar: kayıt onayları, parola sıfırlamaları, makbuzlar.
• İş araçları: CRM, fatura ve ödeme sistemleri, destek masası, İK ve işe alım, takvim ve e-imza servisleri.
• noreply@example.com adına gönderen web sitesi formları ve eklentileri.
• Cihazlar ve betikler: tarayıcılar, izleme uyarıları, zamanlanmış işler ve şirket içi relay’ler.

Ardından raporlardaki her kaynağı listedeki bir kayıtla eşleştirin. IP adresinin ters sorgusu (dig +short -x 192.0.2.10) çoğu zaman sağlayıcının adını verir; sağlayıcının belgeleri de desteklediği SPF include ve DKIM kurulumunu açıklar. Sonucu şuna benzer bir tabloda tutun:

Son satır, bu çalışmanın asıl amacıdır. Bilinen her kaynak geçtiğinde, hâlâ başarısız olan şey çoğunlukla sahte veya yanlış yapılandırılmış postadır ve uygulamanın durdurması gereken de tam olarak budur. Seyrek gönderen kaynaklar en sık gözden kaçanlardır; sessiz geçen bir aya güvenmeden önce muhasebeye, İK’ya ve destek ekibine hangi araçları kullandıklarını sorun.

4. SPF ve DKIM hizalaması: gevşek mi, katı mı?

DMARC, SPF veya DKIM geçtiğinde ve geçtiği alan adı From alan adıyla hizalı olduğunda geçer. Hizalı tek bir geçiş yeterlidir. SPF’de denetlenen alan adı zarf göndericisidir (RFC 7208); DKIM’de geçerli bir imzanın d= değeridir (RFC 6376). aspf ve adkim etiketleri eşleşmenin ne kadar yakın olması gerektiğini belirler:

• Gevşek (r, varsayılan): iki alan adı aynı kurumsal alan adını paylaşır; yani bounce.example.com ve news.example.com, example.com ile hizalanır.
• Katı (s): alan adları birebir aynı olmalıdır.

RFC 9989, RFC 7489’un dayandığı genel son ek listesi yerine, tam addan yukarı doğru _dmarc kayıtlarını sorgulayan bir DNS Tree Walk ile kurumsal alan adını belirler.

RFC 9989, alan adı sahiplerinin neredeyse tamamının gevşek hizalamayı yeterli bulduğunu belirtir. Katı hizalama, sağlayıcı başına ayrı bir bounce alt alan adı kullanma yaygın düzenini bozar; bu yüzden özel bir gerekçeniz yoksa varsayılanı koruyun. Örneğin alt alan adları tedarikçilere devredilmişse ve gevşek hizalama vendor.example.com için doğrulanan postanın example.com adına geçmesine izin verecekse katı hizalama düşünülebilir. Ne seçerseniz seçin, her kaynak için hizalı yöntemin DKIM olmasını sağlayın. SPF, posta yönlendirildiğinde bozulur; çünkü yönlendiren sunucu sizin kaydınızda yer almaz. DKIM imzası ise mesaj değiştirilmediği sürece genellikle yönlendirmeden sağ çıkar.

5. Kademeli geçiş: pct kalktı, t=y kullanın

Eski rehberler uygulamayı pct ile kademelendirir: p=quarantine; pct=10, ardından 25, 50 ve 100; böylece politika başarısız postanın giderek büyüyen bir örnekleminde uygulanır. RFC 7489 kapsamında örneklem dışında kalan posta bir alt politikayı alırdı. RFC 9989 bu etiketi kaldırdı; Ek A.6, 0 ve 100 dışındaki değerlerin genellikle doğru uygulanmadığını ve bu yanlışlığın uygulamalar arasında çok değiştiğini açıklar.

Kaldırmanın keskin bir yanı var. RFC 9989 alıcılara bilmedikleri etiketleri yok saymalarını söyler; dolayısıyla yeni standardı izleyen bir alıcı p=quarantine; pct=25 kaydını düz p=quarantine olarak okur ve tüm başarısız postaya uygular. Kısmi bir pct’nin etkiyi sınırlayacağına artık güvenilemez.

Yerine gelen, t test bayrağıdır. t=y ile alıcılardan yayımlanan politikanın bir kademe altını uygulamaları istenir: p=quarantine; t=y, none gibi; p=reject; t=y ise quarantine gibi işlenir. Raporlar olağan şekilde sürer ve alıcı sapmayı policy_test_mode nedeniyle kaydedebilir. RFC 9989, t=y ve t=n’i pct=0 ve pct=100’ün karşılıkları olarak tanımlar.

Geçiş döneminde bazı alıcılar hâlâ yalnızca RFC 7489’u uygular ve t’yi yok sayar; daha yeniler ise pct’yi yok sayar. Eski kurallardaki pct=0 ile yeni kurallardaki t=y aynı işleyişi istediğinden, test sırasında ikisini birden yayımlayabilirsiniz:

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

Raporları birkaç hafta izleyin, ardından iki etiketi de kaldırın; böylece p=quarantine tam olarak uygulanır. Aynı deseni reject öncesinde tekrarlayın: p=reject; t=y; pct=0 alıcılardan karantina ister, iki etiketi kaldırmak ise reject’i devreye alır.

Yüzde yerine posta akışına göre de kademelendirebilirsiniz. news.example.com gibi bir alt alan adı kendi DMARC kaydını taşıyabilir ve ana alan adından daha erken ya da geç uygulamaya geçebilir; RFC 9989’un kendi dağıtım örneği, daha da sıkılaştırmadan önce bir alt alan adında t=y ile p=quarantine dener.

6. Alt alan adı politikası: sp ve np

example.com üzerindeki bir DMARC kaydı, kendi _dmarc kaydı olmayan alt alan adlarını da kapsar. İki etiket, alt alan adı politikasının p’den farklı olmasını sağlar:

Birkaç kural bunu öngörülebilir kılar. sp yalnızca kurumsal alan adındaki kayıtta anlamlıdır; kendi kaydını yayımlayan bir alt alan adı, o kaydın p değeriyle yönetilir. p hâlâ none iken np=reject ayarlamak düşük riskli bir erken adımdır: billing-support.example.com gibi uydurma adlardan gelen sahte posta reddedilir; np’yi desteklemeyen alıcılar ise basitçe sp veya p’ye döner. Buna güvenmeden önce, gerçekten gönderim yaptığınız her alt alan adının en az bir DNS kaydı olduğundan emin olun ki mevcut sayılsın. Ayrıca SPF’in miras alınmadığını unutmayın: zarf göndericisi olarak kullanılan her ad, DMARC politikası ne olursa olsun kendi SPF kaydına ihtiyaç duyar.

7. p=none’dan p=reject’e gerçekçi bir takvim

Her alan adına uyan bir takvim yoktur ve RFC 9989, alan adı sahibinin uygulamaya hazır olmasının raporlarla birçok ay sürebileceği konusunda uyarır. Kullanıcıları posta listelerine yazan alan adları için en az bir ay p=none, aynı uzunlukta bir dönem de p=quarantine önerir, sonuçların karşılaştırılmasını ister ve yine de bu tür alan adlarının reject yayımlamaması gerektiğini söyler. Bir avuç gönderen servisi olan bir kurum şöyle planlayabilir:

Her değişiklikten önce _dmarc TXT kaydının TTL değerini, örneğin 300 saniyeye, en az bir eski TTL süresi kadar önceden düşürün; böylece bir geri dönüş çözümleyicilere hızla ulaşır. Kaydı haftanın başında değiştirin, destek ekibine nelere dikkat edeceğini söyleyin ve yayımladığınız her değerin tarihli bir kaydını tutun. RFC 9989, p=reject yayımlayan her alan adının postasını yalnızca SPF’e güvenmek yerine geçerli DKIM imzalarıyla imzalamasını gerektirir. Reject tek iyi son durum değildir: çalışanların posta listelerinde kullandığı bir alan adı için iyi izlenen bir quarantine daha doğru seçim olabilir; yalnızca fatura ve bildirimler için kullanılan bir alan adı ise reject için güçlü bir adaydır.

8. Meşru posta başarısız olduğunda: teşhis, düzeltme, geri alma

Er ya da geç bir rapor veya bir meslektaşınız meşru postanın başarısız olduğunu gösterecektir. Toplu raporlarda eşleşen satırları bulun ya da etkilenen bir mesajın tam başlıklarını isteyip Authentication-Results başlığını okuyun, ardından deseni karşılaştırın:

Başarısızlık büyükse ya da makbuz ve parola sıfırlama gibi gelir getiren postaları etkiliyorsa önce geri alın, sonra araştırın: t=y ve pct=0 ekleyin veya önceki politikaya dönün. Kısa bir TTL ile değişiklik çoğu çözümleyiciye dakikalar içinde ulaşır. 5xx reddi kalıcıdır; yani daha önce reddedilen posta sonradan teslim edilmez, etkilenen ekibe hangi mesajları yeniden göndermesi gerektiğini söyleyin. Ardından kaynağı düzeltin, birkaç günlük raporda geçtiğini izleyin ve yeniden ilerleyin. Kimlik doğrulama sonuçlarını ARC (RFC 8617) ile koruyan yönlendiriciler ve listeler yardımcı olabilir; ancak RFC 9989, böyle bir mekanizmanın henüz yaygın kullanılmadığını belirtir, bu yüzden her kaynakta DKIM güvenilir çözüm olmayı sürdürür.

9. Yayımlanan DMARC kaydı nasıl kontrol edilir?

DNS panelinin gösterdiğini değil, gerçekte yayımlananı kontrol edin:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

İlk iki satır çözümleyicilerin döndürdüğünü gösterir; sonuncusu yetkili sunucuyu doğrudan sorgular ve önbellekteki yanıtlar sona ermeden önce değişikliği gösterir. Şunları doğrulayın:

• _dmarc adresindeki tam olarak bir TXT kaydı v=DMARC1 ile başlıyor; iki kayıt varsa alıcılar ikisini de atar ve alan adı hiç DMARC kaydı yokmuş gibi davranır;
• v=DMARC1 ilk etiket ve p değeri none, quarantine veya reject;
• rua posta kutusu mevcut ve başka bir alan adındaysa _report._dmarc kaydıyla yetkilendirilmiş;
• etiketler noktalı virgülle ayrılmış; bir belgeden yapıştırılmış tipografik tırnak veya yabancı karakter yok.

Ardından her gönderen servisten kontrolünüzdeki bir posta kutusuna mesaj gönderin ve Authentication-Results başlığını okuyun: From alan adınızla birlikte dmarc=pass alıcının kararıdır ve geçerli olan da odur.

Dışarıdan hızlı bir bakış için ücretsiz SPF ve DMARC kayıt kontrolü, girdiğiniz ana makine adındaki _dmarc kaydını üst alan adına geri dönmeden okur. Eksik kaydı (ana makinede MX kaydı varsa orta) ve p=none’ı (izleme modu olarak düşük) işaretler; quarantine ve reject sinyal üretmez. Raporlarınızı okumaz, sp, np, t, pct, rua veya hizalamayı değerlendirmez. Aynı posta DNS kontrolü SPF, MTA-STS ve CAA’yı da okur ve kayıt gerektirmeyen, her kontrol için sonuç içeren bir puan döndüren ücretsiz Yayına Hazırlık Snapshot’ının sekiz pasif kontrolünden biridir. Süregelen bir inceleme düzeni için DNS ve e-posta güvenliği rehberine bakın.