DMARC Nasıl Kurulur? none, quarantine ve reject Adımları

DMARC kaydını kurmanın güvenli yolu üç adımdır: önce p=none ile yalnızca izlemek, sonra raporlardan meşru göndericileri bulup düzeltmek, en son p=quarantine ve p=reject politikasına kademeli olarak geçmek. Kayıt DNS'te tek bir TXT satırıdır, ama zor olan kısım o satırı yazmak değil, kayıt sertleşmeden önce bültenin, sipariş e-postalarının ve iletişim formunun hangi sistemlerden çıktığını bilmektir. Bu bilgi bülten ve e-posta kampanyası yürüten yayıncılar, blog sahipleri ve e-ticaret işletmeleri için gereklidir.

DMARC, SPF ve DKIM'in üstüne ne ekler

SPF ve DKIM, bir iletinin gönderen sunucusunu ya da imzasını doğrulayan iki ayrı mekanizmadır. Kendi başlarına alıcıya "bu doğrulama başarısız olursa ne yapmalısın" demezler ve doğrulanan alan adının, kullanıcının gördüğü From adresindeki alan adıyla ilgisini zorunlu kılmazlar. DMARC bu iki boşluğu kapatır. RFC 7489 (yeni sekmede açılır)'a göre alan adı sahibinin tercihleri, alan adının altındaki _dmarc alt alanında DNS TXT kaydı olarak tutulur; örneğin example.com için _dmarc.example.com.

Hizalama: doğrulamanın From alan adıyla eşleşmesi

DMARC'ın temel fikri hizalamadır. SPF ya da DKIM geçmiş olsa bile, doğrulanan alan adı kullanıcının gördüğü From alan adıyla uyuşmuyorsa DMARC açısından başarı sayılmaz. Google Workspace yönergesi bunu şöyle özetler: bir ileti, hizalı SPF ya da hizalı DKIM'den en az birini geçiyorsa DMARC'ı geçer. İki doğrulamanın ikisinin birden başarılı olması gerekmez, ama en az birinin From alan adıyla hizalı olması gerekir.

RFC 7489'a göre hizalama modu iki değer alabilir ve ikisi için varsayılan "r", yani gevşektir. Gevşek modda tam alan adı yerine kuruluşun ana alan adı karşılaştırılır; katı modda ise tam eşleşme aranır. Örneğin bülten sistemi mail.example.com altından imzalıyorsa, gevşek modda example.com ile hizalı sayılabilir; katı modda sayılmaz. Katı mod seçeneğini kaydın adkim ve aspf etiketleri belirler. Google yönergesi, katı hizalamanın ilişkili alt alanlardan gelen iletilerin reddedilmesine ya da spam klasörüne düşmesine yol açabileceği uyarısını yapar.

Politika ve raporlama: iki ayrı kazanım

DMARC iki şey ekler. Birincisi politikadır: alan adı sahibi, doğrulamayı geçemeyen iletiler için alıcıdan ne istediğini belirtir. İkincisi geri bildirimdir: alıcılar, alan adınız adına gelen iletilerin sonuçlarını size raporlar. Politika dikkat çeker, oysa yeni başlayan biri için asıl değer raporlardır; çünkü alan adınızı kullanan ve sizin bilmediğiniz gönderim kaynaklarını ancak raporlar gösterir. Bu yüzden izleme aşaması isteğe bağlı bir ön hazırlık değil, kurulumun ana işidir.

Bir not: RFC Editor sayfası RFC 7489'u eskimiş olarak işaretler ve yerine RFC 9989, RFC 9990 ve RFC 9991'i gösterir. Aşağıdaki etiket adları ve p değerleri RFC 7489 ve Google Workspace sayfasındaki tanımlarla örtüşür; uygulamadan önce hem DNS sağlayıcınızın hem de e-posta hizmetinizin güncel belgelerine bakın.

Başlamadan önce hazırlık

DMARC kaydını yazmak beş dakika sürer, ama kaydın doğru çalışması SPF ve DKIM'in önceden kurulmuş olmasına bağlıdır. Google Workspace sayfası (yeni sekmede açılır) net konuşur: DMARC'ı kullanmadan önce alan adınız için SPF ve/veya DKIM açık olmalıdır; bu ikisini kurduktan sonra DMARC'a geçmek için 48 saat beklemeniz önerilir ve aksi halde iletilerde teslim sorunları yaşanabilir. Yani bu sıra, atlanabilecek bir sıra değildir.

Gönderen envanterini çıkarın

Alan adınızdan e-posta gönderen her sistemi listeleyin. Bir bülten ya da kampanya yürütüyorsanız liste şunları içerebilir: bülten hizmeti, e-ticaret platformunun sipariş e-postaları, iletişim formundan çıkan bildirimler, destek yazılımı, fatura aracı, kendi posta kutunuz ve alan adı sağlayıcısının yönlendirmeleri. Google yönergesi de üçüncü taraf göndericiler için aynı noktaya işaret eder: sağlayıcıda SPF ve DKIM'in doğru kurulduğunu doğrulayın, sağlayıcının zarf gönderen alan adının sizin alan adınızla eşleştiğinden emin olun ve gerekiyorsa sağlayıcının gönderim IP adreslerini SPF kaydınıza ekleyin.

Uygulama önerisi: envanteri bir tabloya dökün. Her satırda sistemin adı, ne tür ileti gönderdiği, hangi alan adını kullandığı, SPF'nin mi DKIM'in mi hizalı olduğu ve sorumlu kişi bulunsun. Boş kalan "hizalı mı?" hücreleri, sonraki aşamanın iş listesidir.

Rapor için ayrı bir posta kutusu açın

Google yönergesi rapor adresi olarak kişisel adresinizin değil, bir grubun ya da ayrılmış bir posta kutusunun kullanılmasını önerir; çünkü büyük kuruluşlarda raporlar günde yüzlerce, hatta binlerce olabilir. Raporlar, kaydın bulunduğu alan adına ait bir adrese gönderilir; farklı bir alan adına göndereceğiniz zaman o alan adında ek bir DNS kaydı gerekir.

Küçük bir blog ya da bülten için de aynı mantık geçerlidir: raporlar kişisel gelen kutunuzu doldurmasın, ayrı bir adres bunları toplasın. Raporlar makine tarafından okunacak biçimde gelir; bu yüzden ya bir rapor çözümleme aracı kullanacaksınız ya da ham dosyalara bakmayı öğreneceksiniz. Hangisini seçtiğiniz kuruluşunuzun boyutuna bağlıdır.

Hazırlık kontrol listesi

• SPF ve DKIM, alan adınız için açık ve en az 48 saattir çalışıyor.
• Alan adınızdan e-posta gönderen her sistemin envanteri hazır.
• Üçüncü taraf göndericilerde SPF ya da DKIM'in, sizin alan adınızla hizalı olduğu doğrulandı.
• Rapor için kişisel olmayan bir posta kutusu ya da grup açıldı.
• DNS sağlayıcınızdaki TXT kaydı ekleme ekranı ve mevcut DMARC kaydı olup olmadığı kontrol edildi.
• Kayıt değişikliğini yapacak kişi ve onay alacak kişi belli.

İlk kayıt: p=none ve rapor adresi

İlk DMARC kaydı gözlem içindir. Google Workspace sayfası ilk adım olarak politika etiketini none yapmanızı, ardından öğrendikçe quarantine ya da reject'e geçmenizi önerir. RFC 7489'a göre p=none, alan adı sahibinin alıcıdan belirli bir işlem istemediği anlamına gelir; alıcılar iletinin normal teslimatını değiştirmemelidir. Yani bu aşamada hiçbir meşru ileti DMARC yüzünden kaybolmaz, ama raporlar akmaya başlar.

Kaydın parçaları

Aşağıdaki tablo, kayıtta karşılaşacağınız etiketleri RFC 7489 ve Google sayfasındaki anlamlarıyla özetler.

Pratikte ilk kayıt, v ve p'nin yanına yalnızca rua eklenmiş kısa bir metindir. Daha fazla etiket eklemek için neden yoksa kaydı kısa tutmak hata ihtimalini azaltır. Kaydı DNS'te TXT türünde, ana bilgisayar adı _dmarc.example.com olacak biçimde oluşturursunuz; example.com yerine kendi alan adınızı yazarsınız.

Rapor adresi başka bir alan adındaysa

Raporları kayıttaki alan adından farklı bir alan adına gönderirseniz alıcı bunu kendiliğinden kabul etmez. RFC 7489'un 7.1. bölümüne göre alıcı, rapor alan adı için "politika alan adı, _report, _dmarc, rapor alan adı" biçiminde kurulmuş bir TXT kaydını sorgular ve uygun bir DMARC1 kaydı bulamazsa o adresi yok sayar. Bunu, bir hizmetin ya da başka alan adınızın raporlarınızı toplamasını planlıyorsanız bilmeniz gerekir; yoksa raporların neden gelmediğini bulmak uzun sürer. Raporların aynı alan adındaki bir adrese gitmesi bu konuyu tümüyle ortadan kaldırır.

DNS panelindeki tuzaklar

Google yönergesi, bazı alan adı sağlayıcılarının kayıt adının sonuna alan adını kendiliğinden eklediğini belirtir. Bu durumda ana bilgisayar adı alanına tam alan adını yazarsanız kayıt _dmarc.example.com.example.com gibi hatalı bir adrese gider. Kaydı kaydettikten sonra sonucu bir DMARC denetleme aracıyla doğrulamak, Google'ın da önerdiği adımdır. Aynı alan adı için yalnızca tek bir DMARC kaydı bulunmalıdır; var olan bir kaydı düzenlemek yerine ikinci bir kayıt eklemek tutarsızlığa yol açar. Mevcut kayıt varsa önce onu okuyun, raporların beklediğiniz gibi doğrulama yaptığını görün, sonra değiştirin.

Gmail'e toplu e-posta gönderiyorsanız ayrıca bir zorunluluk var: Gmail gönderici yönergeleri (yeni sekmede açılır), 1 Şubat 2024'ten itibaren günde 5.000 ileti eşiğini aşan göndericiler için SPF, DKIM ve DMARC kurulmasını ister ve sayfaya göre DMARC politikası none olabilir. Sayfanın başlığı ile gövdesi eşiği "5.000 veya daha fazla" ve "5.000'den fazla" olarak farklı ifade eder; sınıra yakın gönderiyorsanız güncel sayfaya bakın. Bu, p=none kaydının yalnızca bir başlangıç değil, bazı göndericiler için kabul edilen bir asgari seviye olduğunu gösterir.

Raporlardan meşru göndericileri bulmak

p=none kaydını yazdıktan sonra beklenen şey, raporların gelmesidir. RFC 7489'a göre alıcılar günlük ya da daha sık aralıklarla toplu raporlar gönderir; raporda keşfedilen politika, ileti işlemi ve SPF ile DKIM sonuçları hizalama durumuyla birlikte yer alır. Raporlar tek tek iletileri değil, alıcı ve gönderen IP bazında gruplanmış sayıları gösterir. Bir rapor satırı kabaca şunu söyler: "Şu IP adresinden alan adınız adına şu kadar ileti geldi; SPF şöyle, DKIM şöyle sonuçlandı."

Rapor satırında neye bakılır

Her gönderim kaynağı için üç soruya cevap arayın. Bu IP adresi ya da sağlayıcı bizim envanterimizde var mı? İletiler hizalı SPF ya da hizalı DKIM geçiyor mu? Geçmiyorsa neden: kayıt eksik mi, imza yanlış alan adıyla mı atılıyor, yoksa gönderen gerçekten bizim bilmediğimiz biri mi? Envanterdeki bir sistem başarısız görünüyorsa düzeltme listesine girer; envanterde olmayan ve başarısız olan bir kaynak ise ya unutulmuş bir meşru sistem ya da sahte gönderimdir.

Yönlendirme ve e-posta listeleri

Bütün başarısız satırlar yetkisiz kullanım demek değildir. RFC 7489'un 9.1. bölümü, ileti yönlendirme düzenlemeleri varsa raporu isteyen alan adı sahiplerinin, tanımadıkları alan adlarına yönlendirilen iletilere ait verileri de alacağını söyler. RFC 3.1.1 bölümünde de bir iletinin, bir e-posta listesinin alan adı dahil herhangi bir alan adından geçerli imza taşıyabileceği, dolayısıyla geçerli imzanın tek başına gerçekliği kanıtlamadığı yazar. RFC bu bölümlerde yönlendirilen iletiler için ayrıntılı bir çözüm sunmaz; bu iletilerin raporlarda başarısız görünmesini bilmek, yanlış alarmla meşru bir hizmeti engellemenizi önler.

Örnek senaryo: bir mutfak blogunun haftalık bülteni

Örnek senaryo: haftalık tarif bülteni gönderen bir mutfak blogu, p=none kaydını yazıp bir hafta sonra raporlara bakıyor. Raporlarda üç kaynak görüyor: bülten hizmeti, alan adı sağlayıcısının sunucusundan çıkan iletişim formu bildirimleri ve tanımadığı bir IP adresi. Bülten hizmeti hizalı DKIM geçiyor; iletişim formu bildirimleri geçmiyor, çünkü form eklentisi iletileri alan adı sağlayıcısının sunucusundan SPF'siz gönderiyor; tanımadığı IP adresi ise başarısız. Blog sahibi iletişim formunu bir SMTP ayarıyla kendi posta hizmetine bağlıyor, böylece o akış da hizalı doğrulama kazanıyor; bilinmeyen IP adresini ise henüz müdahale gerektirmeyen yetkisiz kaynak olarak not alıyor. İki hafta sonra aynı kaynaklar yeniden listeleniyor ve tablo temiz.

Bülten abonelerinin izni, sıklığı ve gönderim kaydı, DMARC'tan bağımsız bir konudur; abonelik iznini kurma tarafı için ticari elektronik ileti izni ve KVKK yazısına bakabilirsiniz. DMARC yalnızca "bu ileti gerçekten bu alan adından mı geldi" sorusuna cevap verir.

quarantine ve reject'e geçiş

Raporlar temizlendiğinde politikayı sertleştirmek mümkündür. RFC 7489'a göre quarantine, alan adı sahibinin doğrulamayı geçemeyen iletilerin şüpheli sayılmasını istediği anlamına gelir; örneğin spam klasörüne konulması gibi. reject ise iletinin reddedilmesini ister ve RFC'de ret işleminin SMTP işlemi sırasında yapılmasının beklendiği yazar. Yani quarantine iletiyi kullanıcıya göstermeden önce tartışmaya açar, reject ise iletiyi teslim etmeden geri çevirir.

Geçiş için sabit gün sayısı yoktur, koşul vardır

Sık gelen bir soru şudur: "none aşamasında kaç gün beklemeliyim?" Google Workspace sayfası bir izleme süresi vermez; politikayı, alan adınızdan gelen iletilerin nasıl doğrulandığını öğrendikçe güncellemenizi söyler ve ayrıntı için başka bir sayfaya yönlendirir. Yani sabit bir bekleme süresi belirtilmiyor. Bu yüzden karar süre ile değil, koşullarla verilmelidir.

Uygulama önerisi, karar kuralı olarak şöyle kurulabilir: Önceki aşamadan sonraki aşamaya, aşağıdaki koşulların hepsi sağlandığında geçin.

1. Envanterdeki her meşru gönderen, raporlarda hizalı SPF ya da hizalı DKIM geçiyor.
2. Bilinmeyen kaynaklardan gelen başarısız gönderimlerin her biri açıklandı: yetkisiz, yönlendirme ya da henüz envantere eklenmemiş sistem.
3. Bülten, sipariş e-postası ve iletişim formu gibi alan adınızı kullanan akışların hepsi, haftalık gönderim düzeninizin tam bir döngüsünü raporlarda gösterdi. Ayda bir giden fatura ya da yıllık bildirim gibi nadir akışlar için bir döngü uzun sürebilir; bu akışları test iletisiyle ayrıca denemek, beklemekten hızlıdır.
4. Değişikliği geri alacak kişi ve DNS'e erişim hazır.

Koşullardan biri sağlanmıyorsa bir sonraki aşamaya geçmeyin. Bir koşul sağlanıyorsa takvim beklemesi gerekmez. Yeni bir gönderim aracı eklediğinizde karar yeniden başlar; çünkü yeni araç envanterde yoktur.

pct ile kademeli geçiş

Google Workspace sayfası, pct etiketini geçiş sırasında önerir: politikanın uygulanacağı doğrulanamayan ileti yüzdesini 1 ile 100 arasında belirler ve zamanla artırarak yüzde 100'e ulaşmanızı söyler. pct belirtilmezse politika iletilerin tamamına uygulanır. RFC 7489'a göre pct, DMARC'ın ürettiği raporlara uygulanmaz.

Pratik bir dizi şöyle olabilir: p=quarantine ile küçük bir yüzdeyle başlayın, raporlarda meşru bir gönderenin spam klasörüne düşüp düşmediğine bakın, sorun yoksa yüzdeyi artırın. Quarantine yüzde 100'de sorunsuz çalıştığında reject için aynı kademeli yolu uygulayın. Bu yolu dayatan bir kural yoktur, ama Google'ın pct etiketini rollout için önermesi bunu desteklemektedir. Küçük, kontrollü bir yüzde, hatayı küçük bir ileti kümesinde yakalamanızı sağlar.

Alt alan adları ve sp

Kayıt, alt alan adlarını da etkiler. RFC 7489'a göre sp etiketi yalnızca sorgulanan alan adının alt alan adlarına uygulanır, alan adının kendisine uygulanmaz; sp yoksa p alt alanlara da geçerlidir. Bülten hizmetiniz ya da başka bir ekip alt alan adı üzerinden gönderiyorsa p'yi sertleştirmeden önce o alt alan adının raporlarını da görün. Katı hizalama konusunda Google, alt alan adlarını başka bir kuruluşun yönettiği durumlar için katı modu bir seçenek olarak anar, ama yanlış kullanımın iletilerin spam'e düşmesine yol açabileceğini hatırlatır.

Bir de BIMI var: Google yönergesine göre BIMI kullanıyorsanız p değeri quarantine ya da reject olmalı ve pct 100 olmalıdır. Marka logosunun gelen kutusunda görünmesini hedefliyorsanız p=none ile kalmak seçenek değildir.

Bir şey bozulursa geri adım

Politikayı sertleştirdikten sonra bir meşru ileti kaybolursa ilk akla gelen, DMARC'ı tümüyle silmek olur. Bu yanlıştır; çünkü kaydı silmek raporlamayı da keser. Daha ölçülü bir yol, politikayı bir önceki aşamaya çekmektir: reject'ten quarantine'e, quarantine'den none'a. Kayıt yalnızca p değerinin değiştirilmesiyle güncellenir; bu bir TXT kaydı düzenlemesidir ve DNS önbelleği süresi kadar sürede yayılır.

Geri adım prosedürü

1. Hangi gönderenin ve hangi alıcının etkilendiğini belirleyin; mümkünse son raporlardaki ilgili satırı bulun.
2. Politikayı bir önceki aşamaya geri alın. Sorun çok sınırlıysa pct değerini düşürmek de yeterli olabilir.
3. Başarısız olan gönderenin hizalamasını düzeltin: DKIM'i kendi alan adınızla etkinleştirin ya da SPF'ye ekleyin.
4. Düzeltmeyi bir test iletisiyle ve yeni rapor satırıyla doğrulayın.
5. Koşullar yeniden sağlandığında kademeli geçişi baştan uygulayın.

Değişiklik kaydı tutmanın değeri

Her kayıt değişikliğinin tarihini, eski ve yeni p/pct değerini, değişiklik nedenini ve kimin onayladığını bir sayfada tutun. Bir ay sonra "neden bu yüzde?" sorusunun cevabını rapor arşivinde aramaktansa bu kayıttan okumak çok daha hızlıdır. Özellikle birden fazla kişi DNS'e eriştiğinde bu kayıt, çakışan değişiklikleri önler.

Ekip dışı akışları unutmayın

Rapor tablosu yalnızca alıcıların size gönderdiği veriyi gösterir; hiçbir belge her alıcının rapor göndereceğini vaat etmez. Bu yüzden tabloda görünmeyen ama alan adınızı kullanan bir akış olabilir: sponsor ya da reklam ortaklarının sizin adınıza gönderdiği bilgilendirmeler, bir yazarın kendi aracından yolladığı iletiler ya da bir iş ortağının bültene eklediği hatırlatmalar gibi. Sponsor ve ortaklarla ilişkiniz varsa sponsorlu içerik etiketleme yazısı iletişim ve işaretleme tarafında yardımcı olur; e-posta tarafında ise onlara alan adınız üzerinden gönderim yapıp yapmadıklarını doğrudan sormak gerekir.

Medya kitinizdeki iletişim adresi de bir gönderim kaynağıdır. İş birliği isteyenlerin yazdığı adresin alan adınızda olduğundan ve yanıtlarınızın hizalı bir sistemden çıktığından emin olmak için medya kiti hazırlama rehberindeki iletişim bölümünü kontrol listenize ekleyin.

Kurulum sonrası izleme

Reject aşamasına ulaşmak bitiş değildir. Raporları haftalık ya da aylık gözden geçirmek, yeni bir gönderim aracı eklendiğinde envanteri güncellemek ve DNS sağlayıcısını değiştirdiğinizde kaydın yerinde kaldığını doğrulamak kalıcı işlerdir. Bülten performansını Google Search Console ve GA4 ile birlikte okumak istiyorsanız UTM ve raporlama yazısı iletilerin yönlendirdiği trafiği etiketlemek için kullanılabilir; DMARC raporları ise teslim edilebilirlik tarafının ayrı bir göstergesidir.

Aylık gözden geçirme için şu soruları sorun: Yeni bir gönderen çıktı mı? Başarısız hizalama oranı arttı mı? Bir sağlayıcı DKIM anahtarını değiştirdi mi? Rapor kutusu hâlâ okunuyor mu? Soruların cevabı hayırsa kayıt sertleşmiş olsa da gözetimden çıkmış demektir.

Küçük bir yayıncı için çalışma sırası

Teori yerine somut bir sıra isteyenler için aşağıdaki akış, tek kişilik bir bülten ya da küçük bir e-ticaret mağazası düşünülerek kurulmuştur. Burada gün sayısı verilmez; her adımın bitiş koşulu yazılıdır, çünkü Google sayfası da süre değil koşul anlatır.

Örnek senaryo: tek kişilik bir ev dekorasyonu mağazası

Örnek senaryo: küçük bir ev dekorasyonu mağazası sipariş e-postalarını mağaza platformundan, kampanya bültenini ayrı bir bülten hizmetinden, müşteri sorularını ise alan adına bağlı bir posta kutusundan gönderiyor. Sahip önce bu üç akışı envantere yazıyor. Platformun sipariş e-postaları alan adıyla hizalı DKIM taşımıyor; bunu fark edince platformda alan adı doğrulamasını etkinleştiriyor. Sonra p=none kaydını ekliyor ve rapor adresini ayrı bir kutuya yönlendiriyor. Raporları gördükçe müşteri destek yazılımının da alan adı adına ileti gönderdiğini keşfediyor ve onu da düzeltiyor. Her akış hizalı doğrulamayı geçince quarantine aşamasına küçük bir pct ile geçiyor; sorun çıkmadığı sürece yüzdeyi artırıyor.

Çalışma sırasında kaçınılacak hatalar

• SPF ve DKIM'i kurmadan p=quarantine ya da p=reject yazmak. Google yönergesi bu sıranın atlanmasının teslim sorunlarına yol açacağını belirtir.
• Rapor adresini kişisel gelen kutusuna yönlendirmek ve kutunun dolmasıyla raporları görmez hale gelmek.
• Rapor adresi başka bir alan adındayken doğrulama kaydını eklemeyi unutmak.
• Yeni bir bülten ya da form aracı eklendiğinde envanteri ve DKIM ayarını güncellememek.
• Katı hizalamayı (s) gerekçesiz seçmek; Google yönergesi bunun alt alan adlarından gelen iletilerin reddine ya da spam'e düşmesine yol açabileceğini söyler.
• pct değerini bir kez artırıp raporları izlemeyi bırakmak.

Bu listedeki maddeler RFC 7489'daki ve Google sayfasındaki uyarı ve tanımlardan türetilmiştir; hiçbiri kesin sonuç vaadi değildir. Hata yaptığınızda raporların olduğu yere dönün: DMARC'ın size sağladığı en değerli şey, yanlışı hızlı görmenizdir.

Sık Sorulan Sorular

DMARC kaydı nereye yazılır ve nasıl görünür?

DMARC kaydı alan adınızın DNS ayarlarında TXT türünde bir kayıttır ve ana bilgisayar adı _dmarc.example.com biçimindedir; example.com yerine kendi alan adınızı yazarsınız. En kısa kayıt DMARC1 sürümünü ve p politikasını içerir; raporlar için buna rua etiketiyle bir mailto adresi eklenir. Bazı alan adı sağlayıcıları alan adını kendiliğinden eklediği için kaydettikten sonra sonucu bir denetleme aracıyla doğrulamak gerekir.

DMARC için SPF ve DKIM'in ikisi de gerekli mi?

Google Workspace sayfasına göre DMARC'tan önce SPF ve/veya DKIM açık olmalıdır ve bir ileti hizalı SPF ya da hizalı DKIM'den en az birini geçerse DMARC'ı geçer. İkisini birlikte kurmak yine de hizalı doğrulama için daha fazla güvence sağlar. Kurulumdan sonra DMARC'a geçmek için 48 saat beklenmesi önerilir.

p=none ne kadar süre kalmalı?

Google Workspace sayfası sabit bir süre vermez. Politikayı alan adınızdan gelen iletilerin nasıl doğrulandığını öğrendikçe güncellemenizi söyler. Bu yüzden süreyi gün sayısıyla değil, koşullarla belirleyin: bütün meşru gönderenler hizalı doğrulamayı geçiyor, bilinmeyen kaynaklar açıklanmış ve alan adınızı kullanan akışlar raporlarda görünmüş olmalıdır.

p=reject doğrudan yazılabilir mi?

Teknik olarak yazılabilir, ama hizalaması eksik bir meşru gönderen varsa iletileri reddedilir. Google, geçişte pct etiketiyle politikanın uygulanacağı ileti yüzdesini 1'den 100'e doğru kademeli artırmanızı önerir. Önce p=none ile raporları okumak, sonra quarantine, en son reject sırası bu riski küçültür.

Raporlar neden gelmiyor?

Kayıtta rua etiketi yoksa RFC 7489'a göre alıcılar toplu rapor üretmemelidir. Rapor adresi kayıttan farklı bir alan adındaysa o alan adında ek bir DMARC doğrulama kaydı da gerekir; yoksa alıcı adresi yok sayar. Raporlar günlük ya da daha sık gelebilir, ama bütün alıcıların rapor göndereceğinin garantisi yoktur.

Bülten hizmetim DMARC'ı geçmiyor, ne yapmalıyım?

Hizmetin ayarlarında DKIM'i kendi alan adınızla etkinleştirin ve sağlayıcının zarf gönderen alan adının sizinkiyle eşleşip eşleşmediğine bakın. Sağlayıcı bunu desteklemiyorsa SPF kaydınıza sağlayıcının gönderim IP adreslerini eklemeyi deneyin. Sonuçları yeni rapor satırlarıyla doğrulamadan politikayı sertleştirmeyin.

Sonuç

DMARC kurulumunun özü sırayı korumaktır: SPF ve DKIM, sonra p=none ve rapor adresi, sonra raporlardan çıkan düzeltmeler, en sonda koşullar sağlandıkça kademeli olarak quarantine ve reject. Her aşamada bir sonraki adımın koşulu yazılı olmalı, geri alma yolu hazır olmalı ve rapor kutusu bir kişiye ait olmalıdır. Sabit bir gün sayısı değil, envanterin ve raporların tutarlılığı sizi bir sonraki aşamaya taşır; Google sayfasındaki sınırların ve RFC durumunun değişebileceğini unutmayın.

Bülteniniz ya da kampanyanız için güvenilir bir yayın zemini kurduktan sonra dış görünürlük tarafını da düşünüyorsanız Akua Adforce'ta tanıtım yazısı ilanlarını inceleyebilirsiniz; kapsam ve koşullar ürün sayfasında yazılıdır.