Bir kurumun alan adı oltalama iletilerinde taklit ediliyor ve ekip hemen p=rejectyayımlamak istiyor. WordPress’in gönderdiği makbuz e-postaları DKIM doğrulamasından geçiyor; ancak destek sistemi, etkinlik platformu ve bölgesel bir relay de aynı From alanını kullanıyor ve henüz envantere alınmamış.
DMARC, alan adı sahteciliğini önemli ölçüde azaltabilir. Fakat katı bir politika yalnızca tüm meşru gönderim kaynakları biliniyor ve hizalı çalışıyorsa güvenlidir. Önce raporlama açılmalı, eksikler giderilmeli, ardından politika kontrollü adımlarla sıkılaştırılmalıdır.
Bu konu ne anlama gelir?
DMARC, iletinin From başlığında görünen alan adını SPF ve DKIM tarafından doğrulanan alanlarla karşılaştırır. SPF veya DKIM’den en az biri başarılı olmalı ve From alanıyla hizalanmalıdır. DNS kaydı ayrıca başarısız iletiler için istenen politikayı ve toplu raporların gönderileceği adresi belirtir.
p=none, iletilerin reddedilmesini istemeden rapor toplamayı sağlar.p=quarantinevep=reject, hizalanmayan iletiler için daha katı bir politika ister.sp,pct,adkimveaspfalt alanları, geçiş oranını ve hizalama katılığını yönetir.
Gerçekçi bir WordPress örneği
Kurum önce izleme amaçlı bir kayıt yayımlar ve toplu raporları düzenli işler. Raporlarda hizalı DKIM kullanan WordPress iletileri, ilgisiz bir envelope alanıyla gönderim yapan destek sistemi ve artık kullanılmayan bir relay görünür. Her kaynak ilgili ekibe atanır; politika sıkılaştırılmadan önce ya hizalı hâle getirilir ya da devreden çıkarılır.
Neden önemlidir ve ne zaman kullanılır?
DMARC, alıcının gördüğü gönderen alanını korur ve bu alan adına hangi sistemlerin e-posta gönderdiğini gösterir. SPF ile DKIM’in yerine geçmez ve iletinin gelen kutusuna düşeceğini garanti etmez.
Aynı alan adını birden fazla hizmet kullanıyorsa raporlama özellikle değerlidir. Parola sıfırlama, form, sipariş ve bildirim iletileri hizalı bir kimlikle sorunsuz çalışmadan daha katı bir politikaya geçilmemelidir.
Yeni başlayanlar için anlaşılır yol
- WordPress eklentileri, relay’ler, destek ve pazarlama sistemleri dâhil From alanını kullanan tüm hizmetleri listeleyin.
_dmarcaltındap=noneiçeren tek bir geçerli kayıt yayımlayın ve toplu raporları kurumun yönettiği bir adrese gönderin.- Hassas veri içermeyen WordPress iletileri gönderin; Authentication-Results başlığında SPF, DKIM ve DMARC hizalamasını inceleyin.
- Birkaç rapor dönemini karşılaştırın, bilinmeyen kaynakları düzeltin veya kaldırın; ardından quarantine ve reject politikalarına aşamalı geçin.
- Her değişiklikten sonra kritik ileti türlerini ve etkilenmemesi gereken bir gönderim yolunu yeniden test edin.
İleri teknik yol
Toplu XML raporlarını raporlayan kurum, kaynak IP, ileti sayısı, uygulanan işlem, SPF alanı ve DKIM alanına göre inceleyin. Her kaynağı gerçek bir hizmete ve sorumlu ekibe bağlayın. Hizmete göre hizalama katılığını, alt alan politikasını ve haricî rapor adresinin ek yetkilendirme gerektirip gerektirmediğini kontrol edin.
DMARC raporları operasyonel veri içerir. Ekleri doğrulayın, yinelenen rapor kimliklerini ayıklayın, erişimi sınırlandırın ve saklama süresini belirleyin. Yönlendirilen iletilerde SPF bozulabileceğinden hizalı bir DKIM imzası ayrıca önem taşır.
Riskler, sık hatalar, yedekleme ve geri alma
Yalnızca WordPress test edildikten sonra doğrudan p=rejectpolitikasına geçmek, unutulmuş bir hizmetin meşru iletilerini engelleyebilir. Birden fazla DMARC kaydı yayımlamak, rapor kutusunu izlememek, DKIM başarısını DMARC hizalaması sanmak ve SPF, DKIM ile DMARC’ı aynı anda değiştirmek de tanıyı zorlaştırır.
Önceki DNS değerini ve TTL bilgisini geri dönüş için saklayın. Politika sıkılaştırıldıktan sonra kritik bir kaynak başarısız olursa son çalışan ayara dönün; ilgili raporları ve gerekli ileti başlıklarını koruyup göndereni düzeltin.
AIOWS nasıl yardımcı olur?
AIOWS SMTP Yöneticisi
AIOWS SMTP Yöneticisi, DMARC çalışmasının WordPress tarafını tutarlı hâle getirir. Etkin SMTP yolu ve gönderen ayarları incelenebilir, kontrollü testler yapılabilir ve WordPress tarafındaki tanı bilgileri sağlayıcı yanıtlarıyla ve DMARC raporlarıyla eşleştirilebilir.
Tek bir onaylı gönderen kimliği kullanın; parola sıfırlama, form, sipariş ve bildirim gibi gerçek WordPress akışlarını ayrı ayrı sınayın. Başarılı bir test e-postası her eklentinin aynı From adresini kullandığını göstermez. Zaman damgalarını ve hassas olmayan ileti kimliklerini birkaç rapor dönemi boyunca karşılaştırın.
AIOWS DNS kaydı yayımlamaz, alıcı posta kutusunu yönetmez ve sağlayıcı politikasını aşamaz. DMARC politikasıyla raporların işlenmesi alan adı ve posta yöneticilerinin sorumluluğundadır. Yanlış gönderen, açıkta kalan kimlik bilgileri, kimlik doğrulama hatası veya kayıp ticari ileti görülürse önceki çalışan gönderim yoluna dönün.
AIOWS SMTP Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress E-posta Teslimatı İçin SPF Nasıl Ayarlanır?
- WordPress E-postaları İçin DKIM Nasıl Ayarlanır?
- WordPress Gönderen Adresi Uyuşmazlığı Nasıl Çözülür?
Sonuç ve önerilen yol
Önerilen yol bakımlı gönderen envanteri, korunan toplu rapor ve her meşru WordPress akışında hizalı SPF veya DKIM ile izlenen DMARC'tır. Raporlar ve kontrollü testler aynı sonucu göstermeden quarantine ya da reject'e geçmeyin. Her gönderim kaynağı için sorumlu ekip ve DNS değişikliğini geri alma yöntemi önceden belirlenmiş olmalıdır.
