Bulut tabanlı gönderenler için Kimden adresinin etki alanını doğrulamak üzere DMARC'yi yapılandırın

İpucu

Office 365 Plan 2 için Microsoft Defender'deki özellikleri ücretsiz olarak deneyebileceğinizi biliyor muydunuz? Microsoft Defender portalı deneme hub'ında Office 365 deneme sürümü için 90 günlük Defender'ı kullanın. Office 365 için deneme Microsoft Defender'nda kaydolabilecek kişiler ve deneme koşulları hakkında bilgi edinin.

Etki alanı tabanlı İleti Kimlik Doğrulaması, Raporlama ve Uyumluluk (DMARC), Microsoft 365 kuruluşunuzdan gönderilen postaları doğrulamak için bir e-posta kimlik doğrulaması yöntemidir. Bu doğrulama, iş e-posta güvenliğinin aşılması (BEC), fidye yazılımı ve diğer kimlik avı saldırılarında kullanılan sahte gönderenlerin önlenmesine yardımcı olur.

DNS'de txt kaydı oluşturarak etki alanı için DMARC'yi etkinleştirebilirsiniz. E-posta iletisinin DMARC doğrulaması aşağıdaki öğeleri içerir:

  • MAIL FROM ve FROM adreslerindeki etki alanlarının uyumlu olduğunu doğrulayın: SPF ve DKIM , aşağıdaki e-posta adreslerindeki etki alanlarının "hizalamasını" (eşleşmesini) gerektirmez:

    • POSTA KIMDEN adresi: İletinin SMTP e-posta sunucuları arasında iletiminde kullanılan e-posta adresi. Bu adres, 5321.MailFrom adresi, P1 göndereni veya zarf göndereni olarak da bilinir.
    • Gönderen adresi: E-posta istemcilerinde iletinin göndereni olarak gösterilen, From başlık alanındaki e-posta adresi. Bu adres, 5322.From adresi veya P2 göndereni olarak da bilinir.

    Bu e-posta adreslerinin farklı etki alanlarında nasıl bulunabileceği ve kimlik sahtekarlığına yönelik olarak nasıl kullanılacağı hakkında daha fazla bilgi için bkz. İnternet e-postasında kimlik doğrulamasına neden ihtiyaç vardır.

    • DMARC, aşağıdaki koşulların ikisini de doğrulamak için SPF'den elde edilen sonucu kullanır:

      • İleti, MAIL FROM adresinde kullanılan etki alanı için yetkili bir kaynaktan geldi (SPF'nin temel gereksinimi).
      • İletideki MAIL FROM ve From adreslerindeki etki alanları uyumludur. Bu sonuç, mesaj için geçerli kaynakların From adresinin etki alanında olmasını fiilen zorunlu kılar.

    • DMARC, iletiyi imzalayan etki alanının (s= seçici değeri tarafından doğrulanan DKIM-Signature üst bilgi alanındaki d= değeri) Kimden adresindeki etki alanıyla hizalandığını doğrulamak için DKIM'den alınan sonucu kullanır.

    Açıklanan SPF veya DKIM denetimlerinden biri veya her ikisi de geçerse bir ileti DMARC'yi geçirir. Açıklanan SPF ve DKIM denetimlerinin her ikisi de başarısız olursa bir ileti DMARC'de başarısız olur.

  • DMARC ilkesi: DMARC başarısız olan iletilerle ne yapacağını belirtir (reddetme, karantinaya al veya yönerge yok).

  • DMARC raporları: Raporların gönderileceği yeri belirtir:

    • Raporları toplama (pozitif ve negatif DMARC sonuçlarının düzenli bir özeti).
    • Adli raporlar ( Hata raporları olarak da bilinir; teslim edilmeyen rapora veya geri dönen iletiye benzer neredeyse anında DMARC hata sonuçları).

Başlamadan önce, e-posta etki alanınıza bağlı olarak Microsoft 365'teki DMARC hakkında bilmeniz gerekenler şunlardır:

  • E-posta için yalnızca Microsoft Online Email Yönlendirme Adresi (MOERA) etki alanını kullanıyorsanız (örneğin, contoso.onmicrosoft.com): SPF ve DKIM *.onmicrosoft.com etki alanınız için zaten yapılandırılmış olsa da, Microsoft 365 yönetim merkezi *.onmicrosoft.com etki alanı için DMARC TXT kaydını oluşturmanız gerekir. Yönergeler için bkz. Microsoft 365'da *.onmicrosoft.com etki alanları için DMARC TXT kayıtlarını eklemek için Microsoft 365 yönetim merkezi kullanma. *.onmicrosoft.com etki alanları hakkında daha fazla bilgi için bkz. Neden "onmicrosoft.com" etki alanım var?.

  • E-posta için bir veya daha fazla özel etki alanı kullanıyorsanız (örneğin, contoso.com): Henüz kullanmadıysanız, e-posta için kullandığınız tüm özel etki alanları ve alt etki alanları için SPF'yi yapılandırmanız gerekir. Ayrıca, iletiyi imzalamak için kullanılan etki alanının Gönderen adresindeki etki alanıyla uyumlu olması için DKIM imzalamayı özel etki alanınızı veya alt etki alanınızı kullanacak şekilde yapılandırmanız gerekir. Yönergeler için aşağıdaki makalelere bakın:

    Bundan sonra, bu makalede açıklandığı gibi özel etki alanlarınız için DMARC TXT kayıtlarını da yapılandırmanız gerekir. Ayrıca aşağıdaki hususları da göz önünde bulundurmalısınız:

    • Alt alan adları:

      • Doğrudan denetiminiz altında olmayan e-posta hizmetleri için (örneğin, toplu e-posta hizmetleri), ana e-posta etki alanınız (örneğin, contoso.com) yerine bir alt etki alanı (örneğin, marketing.contoso.com) kullanın. Bu e-posta hizmetlerinden gönderilen postalarla ilgili sorunların, ana e-posta etki alanınızdaki kullanıcılar tarafından gönderilen postaların saygınlığını etkilemesini istemezsiniz. Alt etki alanları ekleme hakkında daha fazla bilgi için bkz. Microsoft 365'e özel alt etki alanları veya birden çok etki alanı ekleyebilir miyim?.
      • SPF ve DKIM'nin aksine, bir etki alanının DMARC TXT kaydı, kendi DMARC TXT kaydı olmayan tüm alt etki alanları (var olmayan alt etki alanları dahil) otomatik olarak kapsar. Başka bir deyişle, bu alt etki alanında bir DMARC TXT kaydı oluşturarak bir alt etki alanında DMARC devralmayı kesintiye uğratabilirsiniz. Ancak, her alt etki alanı DMARC için bir SPF ve DKIM kaydı gerektirir.

    • Kayıtlı ancak kullanılmayan etki alanlarınız varsa: E-posta veya herhangi bir şey için kullanılmayan kayıtlı etki alanlarınız varsa ( park edilmiş etki alanları olarak da bilinir), söz konusu etki alanlarındaki DMARC TXT kayıtlarını bu etki alanlarından hiçbir e-posta gelmemesi gerektiğini belirtecek şekilde yapılandırın. E-posta için kullanmıyorsanız bu yönerge *.onmicrosoft.com etki alanını içerir.

  • DMARC gelen posta denetimlerinin yardıma ihtiyacı olabilir: Microsoft 365'e teslim edilmeden önce aktarımda olan iletileri değiştiren bir e-posta hizmeti kullanıyorsanız, hizmeti güvenilir bir ARC sealer olarak tanımlayabilirsiniz. Güvenilen ARC mühürleyicileri, değiştirilen iletilerin DMARC denetimlerinin otomatik olarak başarısız olmasını önler. Daha fazla bilgi için bkz. Sonraki Adımlar.

Bu makalenin geri kalanında DMARC TXT kaydı oluşturma, özel etki alanları için aşamalı dağıtım ve Microsoft 365'te gelen DMARC işleme ele alınmaktadır.

İpucu

Microsoft 365 yönetim merkezi içinde *.onmicrosoft.com etki alanınız için DMARC TXT kaydını oluşturmak için bkz. Microsoft 365 yönetim merkezi kullanarak Microsoft 365'da *.onmicrosoft.com etki alanları için DMARC TXT kayıtlarını ekleme.

Özel etki alanlarınızdaki DMARC TXT kayıtlarını yönetmeniz için Microsoft 365'te yönetici portalı veya PowerShell cmdlet'leri yoktur. Bunun yerine, etki alanı kayıt şirketinizde veya DNS barındırma hizmetinizde (genellikle aynı şirket) DMARC TXT kaydını oluşturursunuz.

Microsoft 365 için alan adı sahipliğini doğrulayan TXT kaydını oluşturmanıza yönelik yönergeler, birçok alan adı kayıt şirketinde sunulmaktadır. Bu yönergeleri başlangıç noktası olarak kullanarak DMARC TXT kayıtları oluşturabilirsiniz. Daha fazla bilgi için bkz. Etki alanınıza bağlanmak için DNS kayıtları ekleme.

DNS yapılandırması konusunda bilginiz yoksa etki alanı kayıt şirketinize başvurun ve yardım isteyin.

DMARC TXT kayıtlarının söz dizimi

DMARC TXT kayıtları RFC 7489'da ayrıntılı olarak açıklanmıştır.

Microsoft 365'te bir etki alanı için DMARC TXT kaydının temel söz dizimi:

Ana bilgisayar adı: _dmarc
TXT değeri: v=DMARC1; <DMARC policy>; <Percentage of DMARC failed mail subject to DMARC policy>; <DMARC reports>

veya

Ana bilgisayar adı: _dmarc
TXT değeri: v=DMARC1; p=<reject | quarantine | none>; pct=<0-100>; rua=mailto:<DMARCAggregateReportURI>; ruf=mailto:<DMARCForensicReportURI>

Örneğin:

Ana bilgisayar adı: _dmarc
TXT değeri: v=DMARC1; p=reject; pct=100; rua=mailto:rua@contoso.com; ruf=mailto:ruf@contoso.com

  • Konak adı değeri _dmarc gereklidir.

  • v=DMARC1; TXT kaydını DMARC TXT kaydı olarak tanımlar.

  • DMARC ilkesi: Hedef e-posta sistemine, DMARC'yi başarısız olan iletilerle (reddetme, karantinaya al veya eylem yok) ne yapacağını bildirir:

    • p=reject: İletiler reddedilmelidir. İletiye gerçekte ne olacağı hedef e-posta sistemine bağlıdır, ancak iletiler genellikle atılır.
    • p=quarantine: İletiler kabul edilmeli ancak işaretlenmelidir. İletiye gerçekte ne olacağı hedef e-posta sistemine bağlıdır. Örneğin, ileti istenmeyen posta olarak karantinaya alınabilir, Gereksiz Email klasörüne teslim edilebilir veya Konu veya ileti gövdesine eklenmiş bir tanımlayıcıyla Gelen Kutusu'na teslim edilebilir.
    • p=none: DMARC'de başarısız olan iletiler için önerilen eylem yok. İletiye ne olacağı, hedef e-posta sistemindeki e-posta koruma özelliklerine bağlıdır. DMARC ilkesini test etmek ve ayarlamak için bu değeri kullanırsınız.

    İpucu

    Microsoft 365’te, hedef e-posta hizmeti tarafından DMARC denetimlerini geçemeyen etki alanlarından gelen giden e-postalar, etki alanının DMARC ilkesi veya p=reject ise p=quarantine üzerinden yönlendirilir. Bu davranış geçersiz kılınamaz.

  • DMARC ilkesine tabi olan, DMARC doğrulamasında başarısız e-postaların yüzdesi: Hedef e-posta sistemine, DMARC doğrulamasında başarısız olan iletilerin yüzde kaçına DMARC ilkesinin uygulanacağını bildirir. Örneğin, pct=100 DMARC'de başarısız olan tüm iletilere DMARC ilkesinin uygulandığı anlamına gelir. DMARC ilkesini test etmek ve ayarlamak için 100'den küçük değerler kullanırsınız. kullanmıyorsanız pct=, varsayılan değer olur pct=100.

  • DMARC raporları:

    • DMARC Toplama raporu URI'si: Değer, rua=mailto: DMARC Toplama raporunun gönderileceği yeri tanımlar. Toplama raporu aşağıdaki özelliklere sahiptir:

      • Toplama raporunu içeren e-posta iletileri genellikle günde bir kez gönderilir (rapor önceki güne ait DMARC sonuçlarını içerir). Konu satırı, raporu gönderen hedef etki alanını (Gönderici) ve DMARC sonuçları için kaynak etki alanını (Rapor Etki Alanı) içerir.
      • DMARC verileri büyük olasılıkla GZIP sıkıştırılmış bir XML e-posta ekindedir. XML şeması RFC 7489'un Ek C'sinde tanımlanır. Rapor aşağıdaki bilgileri içerir:
        • Etki alanınızı kullanarak posta gönderen sunucuların veya hizmetlerin IP adresleri.
        • Sunucuların veya hizmetlerin DMARC kimlik doğrulamasını geçirip geçirmediği veya başarısız olup olmadığı.
        • DMARC’nin, DMARC kimlik doğrulamasını geçemeyen e-postalara uyguladığı işlemler (DMARC politikasına göre).

      İpucu

      Toplama raporundaki bilgiler çok büyük olabilir ve ayrıştırılması zor olabilir. Verileri anlamlı hale getirmek için DMARC raporlaması için aşağıdaki seçenekleri kullanabilirsiniz:

      • PowerShell veya Microsoft Power BI kullanarak otomasyon oluşturun.
      • Dış hizmet kullanın. Hizmetlerin listesini görmek için Microsoft Akıllı Güvenlik İşbirliği (MISA) Kataloğu’nda https://www.microsoft.com/misapartnercatalog DMARC’ı arayın. DMARC raporlama hizmetleri, DMARC TXT kaydında gerekli olan tüm özel değerleri açıklar.

    • DMARC Adli Rapor URI'siruf=mailto:: Değer, DMARC Adli Raporu'na (DMARC Hata raporu olarak da bilinir) nereye gönderileceği tanımlar. Rapor, teslim edilmeyen rapor (NDR veya geri dönen ileti olarak da bilinir) gibi bir DMARC hatasından hemen sonra oluşturulur ve gönderilir.

    İpucu

    Etki alanlarınızdan gelen e-postaların nereden geldiğini izlemek ve istenmeyen DMARC hatalarını (hatalı pozitifler) denetlemek için DMARC Toplama raporlarını düzenli olarak gözden geçirmeniz gerekir.

    Tek tek hedef e-posta sistemleri DMARC raporlarını size geri göndermekten sorumludur. DMARC raporlarının miktarı ve çeşitliliği, kuruluşunuzdan gönderilen posta hacmi ve çeşitliliğiyle aynı şekilde değişir. Örneğin, tatillerde daha düşük posta hacmi ve kuruluş olayları sırasında daha yüksek posta hacmi bekleyebilirsiniz. DMARC raporlarını izlemek için belirli kişileri ve DMARC raporlarını almak için belirli bir posta kutusunu veya Microsoft 365 Grubunu kullanmak en iyisidir (raporları kullanıcının posta kutusuna teslim etmeyin).

DMARC hakkında daha fazla bilgi için aşağıdaki kaynakları kullanın:

  • M3AAWG'den DMARC Eğitim Serisi (Mesajlaşma, Kötü Amaçlı Yazılım, Mobil Kötüye Kullanım Önleme Çalışma Grubu).
  • Bilgi için DMARC.org.

Microsoft 365'te *.onmicrosoft.com etki alanları için DMARC TXT kayıtları eklemek için Microsoft 365 yönetim merkezi kullanın

Microsoft 365 yönetim merkezi *.onmicrosoft.com etki alanınız için DMARC TXT kaydı eklemek için aşağıdaki adımları gerçekleştirin.

  1. https://admin.microsoft.com konumundaki Microsoft 365 yönetim merkezinde Tümünü göster>Ayarlar>Etki Alanları öğesini seçin. Veya doğrudan Etki Alanları sayfasına gitmek için kullanın https://admin.microsoft.com/Adminportal/Home#/Domains.

  2. Etki Alanları sayfasında, etki alanı adının yanındaki onay kutusundan başka bir satıra tıklayarak listeden *.onmicrosoft.com etki alanını seçin.

  3. Açılan etki alanı ayrıntıları sayfasında DNS kayıtları sekmesini seçin.

  4. DNS kayıtları sekmesinde Kayıt ekle'yi seçin.

  5. Açılan Özel DNS kaydı ekle açılır öğesinde aşağıdaki ayarları yapılandırın:

    • Tür: TXT (Metin) öğesinin seçili olduğunu doğrulayın.

    • TXT adı: _dmarc girin.

    • TXT değeri: girin v=DMARC1; p=reject.

      İpucu

      DMARC Toplama ve DMARC Adli Raporları için hedefleri belirtmek için söz dizimini v=DMARC1; p=reject; rua=mailto:<emailaddress>; ruf=mailto:<emailaddress>kullanın. Örneğin, v=DMARC1; p=reject; rua=mailto:rua@contoso.onmicrosoft.com; ruf=mailto:ruf@contoso.onmicrosoft.com.

      konumundaki MISA Kataloğu'ndaki https://www.microsoft.com/misapartnercatalog DMARC raporlama satıcıları, DMARC sonuçlarını görüntülemeyi ve yorumlamayı kolaylaştırır.

    • TTL: 1 saatin seçili olduğunu doğrulayın.

    Özel DNS kaydı ekle açılır öğesinde işiniz bittiğinde Kaydet'i seçin.

Microsoft 365'te etkin özel etki alanları için DMARC ayarlama

İpucu

Özel etki alanları veya alt etki alanları için DMARC'yi yapılandırmadan önce SPF TXT kayıtları oluşturmanız ve Microsoft 365 e-posta göndermek için kullandığınız tüm özel etki alanları ve alt etki alanları için DKIM imzalamasını yapılandırmanız gerekir.

Microsoft 365 etki alanlarınız için DMARC'yi ayarlamaya yönelik aşamalı bir yaklaşım önerilir. Amaç, tüm özel etki alanlarınız ve alt etki alanlarınız için bir p=reject DMARC ilkesine ulaşmaktır, ancak hedef e-posta sistemlerinin istenmeyen DMARC hataları nedeniyle iyi postaları reddetmesini önlemek için test etmeniz ve doğrulamanız gerekir.

DMARC dağıtım planınız aşağıdaki adımları kullanmalıdır. Düşük posta hacmine ve/veya daha az olası e-posta kaynağına sahip bir etki alanı veya alt etki alanıyla başlayın (bilinmeyen kaynaklardan gelen geçerli postaların engellenme olasılığı daha düşüktür):

  1. DMARC ilkesiyle p=none başlayın ve etki alanının sonuçlarını izleyin. Örneğin:

    marketing.contoso.com için DMARC TXT kaydı:

    Ana bilgisayar adı: _dmarc
    TXT değeri: v=DMARC1; p=none; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    DMARC Toplama ve DMARC Adli Raporları, DMARC denetimlerinden geçen ve başarısız olan iletilerin sayılarını ve kaynaklarını verir. Geçerli posta trafiğinizin ne kadarının DMARC kapsamında olmadığını görebilir ve sorunları giderebilirsiniz. Ayrıca, kaç sahte ileti gönderildiğini ve bunların nereden gönderildiğini de görebilirsiniz.

  2. DMARC ilkesini p=quarantine olarak artırın ve etki alanının sonuçlarını izleyin.

    etkilerini p=noneyeterince izledikten sonra etki alanı için DMARC ilkesini p=quarantine olarak artırabilirsiniz. Örneğin:

    marketing.contoso.com için DMARC TXT kaydı:

    Ana bilgisayar adı: _dmarc
    TXT değeri: v=DMARC1; p=quarantine; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Ayrıca, giderek daha fazla mesajı etkilemek ve sonuçları doğrulamak için pct= değerini kullanabilirsiniz. Örneğin, aşağıdaki artış miktarlarıyla hareket ettirebilirsiniz:

    • pct=10
    • pct=25
    • pct=50
    • pct=75
    • pct=100

  3. DMARC ilkesini p=reject olarak artırın ve etki alanının sonuçlarını izleyin.

    etkilerini p=quarantineyeterince izledikten sonra etki alanı için DMARC ilkesini p=reject olarak artırabilirsiniz. Örneğin:

    marketing.contoso.com için DMARC TXT kaydı:

    Ana bilgisayar adı: _dmarc
    TXT değeri: v=DMARC1; p=reject; pct=100; rua=mailto:rua@marketing.contoso.com; ruf=mailto:ruf@marketing.contoso.com

    Ayrıca, giderek daha fazla mesajı etkilemek ve sonuçları doğrulamak için pct= değerini kullanabilirsiniz.

  4. Artan hacim ve/veya karmaşıklıktaki kalan alt etki alanları için önceki üç adımı yineleyin; üst etki alanını en sona bırakın.

    İpucu

    Meşru e-postaların kayda değer ölçüde engellenmesi kullanıcılar açısından kabul edilemez, ancak bir miktar yanlış pozitif ortaya çıkması neredeyse kaçınılmazdır. Yavaş ve yöntemsel olarak DMARC raporlamasında ortaya konulabilen sorunlarla başa çık. konumundaki MISA Kataloğu'ndaki https://www.microsoft.com/misapartnercatalog DMARC raporlama satıcıları, DMARC sonuçlarını görüntülemeyi ve yorumlamayı kolaylaştırır.

  5. Alt etki alanları, üst etki alanının DMARC TXT kayıt ayarlarını devralır ve alt etki alanındaki ayrı bir DMARC TXT kaydıyla geçersiz kılabilirsiniz. Bir etki alanında DMARC'yi ve tüm alt etki alanları ayarlamayı bitirdiğinizde ve DMARC ayarları üst etki alanı ve tüm alt etki alanları için etkili bir şekilde aynı olduğunda, alt etki alanındaki DMARC TXT kayıtlarını ortadan kaldırıp üst etki alanındaki tek DMARC TXT kaydını kullanabilirsiniz.

Microsoft 365'te park edilmiş etki alanları için DMARC TXT kayıtları

İpucu

Posta göndermeyen park edilmiş etki alanları için önerilen SPF TXT kaydı , özel bulut etki alanları için SPF TXT kayıtları bölümünde açıklanmıştır. DKIM'i bulut etki alanınızdan posta imzalamak için ayarlama bölümünde açıklandığı gibi, park edilmiş etki alanları için DKIM CNAME kayıtları önerilmez.

  1. İnternette hiç kimsenin kendilerinden e-posta almayı beklememesi gereken alan adlarını kaydettiyseniz, alan adı için kayıt şirketinde aşağıdaki DMARC TXT kaydını oluşturun:

    Ana bilgisayar adı: _dmarc
    TXT değeri: v=DMARC1; p=reject;

    • pct= Varsayılan değer olduğundan değer pct=100dahil değildir.
    • Bu senaryoda rua=mailto: ve ruf=mailto: değerleri muhtemelen gerekli değildir, çünkü etki alanındaki gönderenlerden hiçbir zaman geçerli bir e-posta gelmemelidir.

  2. Posta göndermek için *.onmicrosoft.com etki alanını kullanmıyorsanız, *.onmicrosoft.com etki alanınız için DMARC TXT kaydını da eklemeniz gerekir.

Microsoft 365'e gelen posta için DMARC

Aşağıdaki özellikler ve davranışlar, Microsoft 365 gelen iletiler için DMARC'yi nasıl değerlendirdiğini ve DMARC raporlarının gönderilip gönderilmediğini etkiler.

  • Tüm bulut posta kutuları için aşağıdaki yerleşik güvenlik özellikleri, gelen postalarda DMARC denetimlerini etkiler:

    • İletiyi denetleyen kimlik avı önleme ilkesinde sahtecilik analizinin etkin mi yoksa devre dışı mı olduğu. Sahtecilik zekâsını devre dışı bırakmak, yalnızca bileşik kimlik doğrulama denetimlerinden gelen örtük sahteciliğe karşı korumayı devre dışı bırakır.
    • İleti sahte olarak algılandığında DMARC kayıt ilkesine uy ayarının, iletiyi denetleyen kimlik avı önleme ilkesinde etkin mi devre dışı mı olduğu ve kaynak etki alanının DMARC ilkesine (p=quarantine veya p=reject, DMARC TXT kaydında) göre belirtilen eylemler.

    Ayrıntılı bilgi için bkz: Kimlik sahteciliğine karşı koruma ve gönderen DMARC ilkeleri.

    Kimlik avı önleme ilkelerinde bu ayarların varsayılan değerlerini görmek için tüm bulut posta kutuları için Kimlik avı önleme ilkesi ayarları bölümündeki tabloda yer alan ayar değerlerini denetleyin.

  • Microsoft 365, kaynak etki alanının DMARC TXT kaydında geçerli ruf=mailto: bir adres olsa bile DMARC Adli Raporları (DMARC Hata raporları olarak da bilinir) göndermez.

  • Microsoft 365 etki alanının MX kaydı doğrudan Microsoft 365'i gösterdiği sürece, Microsoft 365 DMARC TXT kayıtlarında geçerli rua=mailto: bir adrese sahip tüm etki alanlarına DMARC Toplama raporları gönderir.

    Microsoft 365'e (MX kayıt noktaları Microsoft 365 dışında bir yere) teslim etmeden önce İnternet postasını Microsoft dışı bir hizmet veya cihaz üzerinden yönlendirirseniz, DMARC Toplama raporları gönderilmez. Bu sınırlama, postanın bağlayıcı kullanılarak Microsoft 365'e yönlendirilmeden önce şirket içi ortama teslim edildiği karma senaryoları içerir.

    İpucu

    Microsoft olmayan bir hizmet veya cihaz Microsoft 365'e akan postanın önünde durduğunda , Bağlayıcılar için Gelişmiş Filtreleme ( liste atlama olarak da bilinir), SPF, DKIM (hizmet iletileri değiştirirse) ve DMARC doğrulaması için İnternet iletilerinin kaynağını doğru şekilde tanımlar.

DMARC sorunlarını giderme

DMARC hatalarının, nedenlerinin ve düzeltmelerinin hızlı başvuru tablosu için bkz. Microsoft 365'te e-posta kimlik doğrulaması sorunlarını giderme.

Bu bölüm yaygın DMARC hatalarını tanılamanıza ve çözmenize, Microsoft 365'in farklı DMARC ilkeleri üzerinde nasıl davranacağını anlamanıza ve DMARC toplam ve adli raporlarını yorumlamanıza yardımcı olur.

DMARC sorun giderme işleminin diyagramı

Hizalama arızasının tanılanması

Bulut gönderenler için Kimden adresinin etki alanını doğrulayacak şekilde DMARC ayarlama bölümünde açıklandığı gibi, en az bir hizalama denetimi başarılı olursa (SPF veya DKIM), bir ileti DMARC denetimini geçer. Bir ileti, yalnızca iki hizalama denetimi de başarısız olursa DMARC denetiminden geçemez.

Hizalama modları

DMARC TXT kaydındaki aspf (SPF) ve adkim (DKIM) etiketleri, From etki alanının kimliği doğrulanmış etki alanıyla ne kadar sıkı eşleşmesi gerektiğini belirler. Her ikisi de isteğe bağlıdır ve varsayılan olarak r (gevşetilir) ancak s (katı) da kullanılabilir. Aşağıdaki örnekte, katı SPF hizalaması () ve gevşek DKIM hizalaması (aspf=sadkim=r) kullanan bir DMARC TXT kaydı gösterilmektedir:

Hostname: _dmarc
TXT value: v=DMARC1; p=reject; aspf=s; adkim=r; pct=100; rua=mailto:dmarc@contoso.com
  • Esnek (r, varsayılan): Kuruluş alan adları (kök alan adları) eşleşmelidir. Alt alan adlarına izin verilir.
  • Katı (s): FQDN'lerin tam olarak eşleşmesi gerekir. Alt alan adı eşleşmesi yok.

Not

aspf ve adkim etiketleri birbirinden bağımsızdır. Örnekte gösterildiği gibi her mod için farklı modlar kullanabilirsiniz. Bir ileti, iki hizalama denetiminden herhangi biri başarılı olursa DMARC denetimini geçer; bu nedenle, bir denetimin katı hizalamada başarısız olması, diğer denetim gevşek hizalamayla geçerse önemli değildir.

Örnekler:

Gönderen adresi MAIL FROM / DKIM-Signature d= adresi Gevşek (r) Katı (s)
user@contoso.com contoso.com ✅ Başarılı ✅ Başarılı
user@contoso.com bounces.contoso.com ✅ Başarılı ❌ Başarısız
user@marketing.contoso.com contoso.com ✅ Başarılı ❌ Başarısız
user@contoso.com contoso.onmicrosoft.com ❌ Başarısız ❌ Başarısız
user@contoso.com adatum.net ❌ Başarısız ❌ Başarısız

Yaygın hizalama hatası senaryoları

Aşağıdaki tabloda yaygın DMARC hizalama hatası senaryoları, belirtileri, kök nedenleri ve önerilen düzeltmeler listelenmiştir.

Senaryo Belirti Kök neden Çözüm
Microsoft dışı hizmet sizin yerinize gönderir adatum.com için SPF doğrulaması geçer ancak DMARC başarısız olur MAIL FROM hizmetin etki alanını (örneğin, bounce.adatum.com) kullanır ve etki alanınızla DKIM imzalaması yapmaz Hizmette etki alanınızla DKIM imzalamayı yapılandırın veya MAIL FROM'u etki alanınıza/alt etki alanınıza değiştirin
Microsoft 365 otomatik iletme DMARC hedefte başarısız oluyor Yönlendirme zarf göndericisini değiştirir; DKIM imzası bozulabilir Hedefte güvenilir ARC mühürleyicileri kullanın veya DKIM kullanın (ileti gövdesi değiştirilmezse yönlendirmeden sonra da geçerliliğini korur)
Alt etki alanı, katı hizalamayla gönderir aspf=s alt alan adından gönderim yapanlar için hatalara neden olur MAIL FROM sub.contoso.com iken From contoso.com## aspf=r (gevşek) olarak değiştirin veya Kimden adresinin alt etki alanıyla eşleştiğinden emin olun
DKIM imzalama etki alanı uyuşmazlığı DKIM geçer ancak DMARC yine başarısız olur DKIM d= değeri (örneğin, adatum.com) Gönderen etki alanıyla (contoso.com) uyumlu değil Etki alanınızı kullanarak hizmette özel DKIM imzalamayı yapılandırma
Paylaşılan posta kutusu veya dağıtım grubu DMARC aralıklı olarak başarısız oluyor Yanıt adresi veya yeniden yönlendirme zarf adreslerini değiştirir DKIM'in bozulmadığını doğrulayın; ara hizmetler için ARC'i göz önünde bulundurun

İleti üst bilgilerinden hizalama hatalarını tanılama

1. Adım: İleti üst bilgilerini açın ve Microsoft 365 Authentication-Results üst bilgisini bulun. Aşağıdaki örnek, SPF ve DKIM'in ayrı ayrı başarılı olduğu, ancak hiçbir etki alanı From adresindeki etki alanıyla hizalanmadığı için DMARC'nin başarısız olduğu bir Authentication-Results başlığını gösterir:

Authentication-Results: spf=pass (sender IP is 198.51.100.10)
  smtp.mailfrom=bounces.adatum.com; dkim=pass (signature was verified)
  header.d=adatum.com; dmarc=fail action=oreject
  header.from=contoso.com;compauth=fail reason=000

2. Adım: Hizalama hatasını belirleyin:

Kontrol et Başlık alanı Örnekteki değer Kimden (contoso.com)? ile hizalanır
SPF hizalaması smtp.mailfrom= bounces.adatum.com ❌ Hayır (farklı kuruluş etki alanı)
DKIM hizalaması header.d= adatum.com ❌ Hayır (farklı kuruluş etki alanı)
DMARC sonucu dmarc= fail Her iki denetim de başarısız oldu

3. Adım: Aşağıdaki soruları yanıtlayarak düzeltmeyi belirleyin:

  1. MAIL FROM adresini kendi etki alanınız olarak değiştirebilir misiniz (örneğin, bounces.adatum.com yerine bounces.contoso.com)?
    • Evet: SPF hizalamasını düzeltmek için hizmette MAIL FROM değişikliğini yapılandırın.
    • Hayır: Bunun yerine DKIM hizalamasını kullanın (2. adıma gidin).
  2. Hizmet, alan adınızla (d=contoso.com) imzalayabilir mi?
    • Evet: Hizmette özel DKIM imzalamasını yapılandırın.
    • Hayır: Alt etki alanı stratejisini göz önünde bulundurun:
      • Gönderimi bir alt alan adından yapın (örneğin, sub.contoso.com).
      • Bu alt etki alanı için ayrı bir DMARC kaydı yayımlayın.
      • Hizmetin d=sub.contoso.com ile DKIM imzalamasını sağlayın.

PowerShell'de son iletilerin hizalamasını denetleme

Exchange Online PowerShell'e bağlanın ve aşağıdaki komutları çalıştırın:

# Get recent messages and check authentication results
$messages = Get-MessageTrace -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -PageSize 100

foreach ($msg in $messages) {
    $details = Get-MessageTraceDetail -MessageTraceId $msg.MessageTraceId -RecipientAddress $msg.RecipientAddress
    $authEvent = $details | Where-Object { $_.Event -eq "Receive" }
    if ($authEvent.Detail -match "dmarc=fail") {
        Write-Output "DMARC FAIL: From=$($msg.SenderAddress), Subject=$($msg.Subject)"
    }
}

DMARC ilkenin Microsoft 365 davranışı üzerindeki etkisi

Gelen postalar için DMARC'de açıklandığı gibi Microsoft 365 davranışı, DMARC kaydı ilke ayarını kabul eder. Tüm ayrıntılar için bkz. Kimlik sahtekarlığına karşı koruma ve gönderen DMARC ilkeleri.

Aşağıdaki özet, DMARC kayıt ilkesine uy ayarı Açık olduğunda DMARC denetimini geçemeyen gelen iletiler için genel davranışı gösterir (önerilen):

Gönderenin DMARC ilkesi İleti durumu Kimlik Doğrulama Sonuçları CompAuth
p=none DMARC'ye özgü eylem yok. Diğer filtreleme hala geçerlidir. dmarc=fail action=none Birleşik kimlik doğrulamasını temel alan (SPF, DKIM, sahtecilik istihbaratı)
p=quarantine Gereksiz Email klasörü (karantinaya alınacak şekilde yapılandırılabilir) dmarc=fail action=quarantine compauth=fail reason=100
p=reject SMTP sırasında reddedildi (550 5.7.1) dmarc=fail action=oreject compauth=fail reason=100

Dikkat

Meşru gönderenler için p=reject geçersiz kılınırken dikkatli olun. Kuruluşunuz DMARC başarısız olan bir gönderenden (örneğin, iletilen posta, posta listeleri) postayı yasal olarak alıyorsa, şu yaklaşımlardan birini kullanın:

  • Göndereni güvenilen bir ARC imzalayıcısı olarak yapılandırın (tercihen).
  • İstenmeyen posta filtrelemeyi atlamak için belirli koşullara (gönderen IP + gönderen etki alanı) sahip bir posta akışı kuralı oluşturun.
  • Kiracı İzin Ver/Engelle Listesi'ne bir izin verme girdisi ekleyin (geçici, süresi 30 gün içinde dolar).

Authentication-Results'de DMARC eylem değerleri

Authentication-Results üst bilgisinde şu DMARC eylem değerlerini görebilirsiniz:

Eylem değeri Anlamı
action=none Gönderen yayımlandı p=none; hiçbir işlem yapılmamış
action=quarantine Gönderen yayımlandı p=quarantine; ileti karantinaya alındı veya istenmeyen postaya taşındı
action=oreject Gönderen yayımlandı p=reject; ileti reddedildi ("o" = kaynak)
action=pct.quarantine Gönderen, p=quarantine 100'den küçük olduğundan pct= yayımladı; bu ileti örneklenen yüzdeye dahildi
action=pct.reject Gönderen, p=reject 100'den küçük olduğundan pct= yayımladı; bu ileti örneklenen yüzdeye dahildi

DMARC rapor yorumlaması

Bu bölüm, alıcıların rua ve ruf adreslerinize gönderdiği DMARC toplu ve adli raporlarını yorumlamanıza yardımcı olur. DMARC TXT kaydındaki rua ve ruf değerlerini yapılandırma hakkında bilgi için bkz. DMARC TXT kayıtları için söz dizimi.

Toplu raporlar

Aşağıdaki örnekte bir toplama raporunun XML yapısı gösterilmektedir:

<?xml version="1.0" encoding="UTF-8"?>
<feedback>
  <report_metadata>
    <org_name>microsoft.com</org_name>           <!-- Reporting organization -->
    <email>dmarceng@microsoft.com</email>
    <report_id>unique-report-id</report_id>
    <date_range>
      <begin>1700000000</begin>                   <!-- Unix timestamp: start -->
      <end>1700086400</end>                       <!-- Unix timestamp: end -->
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>contoso.com</domain>                  <!-- Your domain -->
    <adkim>r</adkim>                              <!-- DKIM alignment mode -->
    <aspf>r</aspf>                                <!-- SPF alignment mode -->
    <p>reject</p>                                 <!-- Domain policy -->
    <sp>quarantine</sp>                           <!-- Subdomain policy -->
    <pct>100</pct>                                <!-- Percentage -->
  </policy_published>

  <record>
    <row>
      <source_ip>198.51.100.10</source_ip>        <!-- Sending IP -->
      <count>1523</count>                         <!-- Number of messages -->
      <policy_evaluated>
        <disposition>none</disposition>           <!-- What receiver did -->
        <dkim>pass</dkim>                         <!-- DKIM alignment result -->
        <spf>fail</spf>                           <!-- SPF alignment result -->
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>contoso.com</header_from>      <!-- From address domain -->
      <envelope_from>bounces.adatum.com</envelope_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>contoso.com</domain>
        <result>pass</result>
        <selector>selector1</selector>
      </dkim>
      <spf>
        <domain>bounces.adatum.com</domain>
        <result>pass</result>                     <!-- SPF passed but... -->
      </spf>
    </auth_results>
  </record>
</feedback>

Toplu raporları okuma

DMARC toplama raporundaki en önemli alanları yorumlamak ve hangi sorun giderme eylemini gerçekleştireceğini belirlemek için aşağıdaki tabloyu kullanın.

XML öğesi Size ne söylüyor? Sorun giderme eylemi
<source_ip> İletileri gönderen IP adresi Bunun geçerli bir gönderen mi yoksa yetkisiz mi olduğunu belirleme
<count> Bu kaynaktan gelen ileti sayısı Bilinmeyen IP’den yüksek sayıda istek = sahtecilik olasılığı
<disposition> Alıcının yaptığı eylem (none, quarantine, reject) Alıcının ilkenize saygı duyduğunu doğrulayın
<dkim>, <policy_evaluated> altında DKIM’in uyumlu olup olmadığı (yalnızca doğrulamayı geçip geçmediği değil) fail = DKIM etki alanı, From etki alanıyla eşleşmiyor
<spf>, <policy_evaluated> altında SPF'nin uyumlu olup olmadığı (yalnızca geçip geçmediği değil) fail = MAIL FROM alan adı, From alan adı ile eşleşmiyor
<domain>, <auth_results><spf> altında SPF'nin denetlenildiği etki alanı Etki alanından farklıysa = hizalama sorunu
<domain>, <auth_results><dkim> altında DKIM imzalama alan adı DMARC hizalaması için From etki alanı ile eşleşmelidir
<result>, <auth_results> altında Ham SPF/DKIM başarılı/başarısız (hizalama kontrolü öncesinde) pass + hizalama fail = klasik hizalama sorunu

İpucu

Toplu raporlardan elde edilen en önemli çıkarım, kimlik doğrulamasını geçen ile hizalamayı geçen arasındaki farkı belirlemektir:

  • <auth_results><spf><result>pass</result> + <policy_evaluated><spf>fail</spf> = SPF’ten geçti ancak alan adları eşleşmiyor.
  • Bu kombinasyon, gönderenin yetkili olduğu (SPF doğrulamasını geçiyor) ancak DMARC açısından doğru şekilde yapılandırılmadığı (hizalamanın başarısız olduğu) anlamına gelir.

Yaygın toplu rapor kalıpları ve düzeltmeleri

Aşağıdaki tabloda, toplu raporlarda bulabileceğiniz yaygın desenler ve normalde gerekli olan eylemler gösterilmektedir.

Rapordaki desen Yorum Düzelt
Bilinen IP, SPF kimlik doğrulaması=pass, SPF uyumlu=fail Yanlış MAIL FROM etki alanına sahip meşru hizmet Hizmeti, MAIL FROM içinde etki alanınızı kullanacak şekilde yapılandırın veya etki alanınızla DKIM imzalamayı ayarlayın
Bilinen IP adresi, DKIM auth=pass, DKIM aligned=fail Hizmet, DKIM'i kendi etki alanıyla imzalar d=contoso.com ile hizmette özel DKIM yapılandırın
Bilinmeyen IP, yüksek hacim, hepsi başarısız oluyor Olası kimlik sahtekarlığı/kimlik avı kampanyası Eylem gerekmez. DMARC ilkeniz alıcıları koruyor.
Bilinen IP (Microsoft 365), SPF aligned=pass Normal Microsoft 365 posta akışı Sağlıklı. Eylem gerekmez.
Meşru hizmetten gelen düşük hacim, SPF+DKIM başarısız Hizmet SPF'ye dahil değil ve DKIM imzalamaya dahil değil SPF kaydına hizmet ekleme ve/veya DKIM'yi yapılandırma
İletilen postalar (posta listesi IP'leri), tümü başarısız oluyor Posta yönlendirme SPF'yi bozar; gövde değişikliği DKIM'i bozar İletilen postalar için normal. ARC kullanın veya bazı hataları kabul edin.

Adli raporlar

Gelen posta için DMARC bölümünde belirtildiği gibi, Microsoft 365 adli rapor göndermez. Ancak, bunları diğer sağlayıcılardan alabilirsiniz. Aşağıdaki tablo iki rapor türünü karşılaştırır:

Görünüm Toplu raporlar (rua) Adli raporlar (ruf)
Sıklık Günlük (genellikle) Neredeyse gerçek zamanlı (hata başına)
İçerik Kaynak IP'ye göre özet istatistikler Tek tek ileti ayrıntıları
Ses düzeyi Muhabir başına günde bir rapor Hata başına bir rapor (yüksek hacimli olabilir)
Gizlilik Yalnızca IP adresleri ve adet sayıları İleti üst bilgilerini/gövdesini içerebilir (yeniden işlem yapılmış)
Destek Alıcılar tarafından yaygın olarak desteklenir Sınırlı destek (birçok alıcı ruf göndermez)
Kullanım örneği Eğilim analizi, bilinmeyen gönderenleri belirleme Belirli arızalarda hata ayıklama, adli inceleme

Not

Microsoft 365'in ileti başına hata ayrıntılarına ihtiyacınız varsa, adli raporlar yerine ileti izleme ve ileti üst bilgisi analizini kullanın.

Aşağıdaki örnekte, bir ileti DMARC başarısız olduğunda alıcının adresinize ruf gönderdiği DMARC adli raporunun (AFRF/RFC 6591 biçimi) yapısı gösterilmektedir. Hata ayrıntılarını tanımlamak için Feedback-Type, Source-IPve Authentication-Results alanlarını arayın:

From: noreply-dmarc-support@fabrikam.com
To: ruf@contoso.com
Subject: Report Domain: contoso.com Submitter: fabrikam.com

Feedback-Type: auth-failure
User-Agent: fabrikam.com/dmarc-reporter
Version: 1
Original-Mail-From: bounces@adatum.com
Arrival-Date: Mon, 15 Jan 2024 10:30:00 -0000
Source-IP: 198.51.100.10
Authentication-Results: fabrikam.com; dmarc=fail (p=reject)
  header.from=contoso.com
Reported-Domain: contoso.com
Original-Envelope-Id: <abc123@mail.adatum.com>

DMARC raporları için en iyi yöntemler

DMARC raporlamasını etkili bir şekilde yönetmek için aşağıdaki en iyi yöntemleri kullanın.

Öneri Ayrıntılar
rua için özel bir posta kutusu kullanın Paylaşılan posta kutusu oluşturma (örneğin, dmarc-reports@contoso.com). Tek tek kullanıcı posta kutularını kullanmayın.
Microsoft 365 Grubu kullanma Gruplar, güvenlik ekibi için daha iyi işbirliği ve paylaşılan erişim sağlar
DMARC raporlama hizmetini göz önünde bulundurun DMARC raporlama hizmetleri XML'i panolara ayrıştırıyor. MISA Kataloğu'nda DMARC'yi arayın.
Yalnızca rua ile başlayın Gerekirse daha sonra ekleyin ruf . Adli raporlar yüksek hacimde üretilebilir.
Düzenli olarak izleme İlk dağıtım aşamasında toplu raporları haftalık olarak gözden geçirin; sistem kararlı hâle geldikten sonra aylık olarak gözden geçirin.
Gerçekçi beklentiler belirleme Tüm alıcılar rapor göndermez. Kapsam genellikle toplam posta hacminin %70-90'dır

Etki alanları arası raporlama

DMARC rua veya ruf adresiniz, izlenen etki alanından farklı bir etki alanındaysa, alıcı etki alanının rapor teslimini yetkilendiren bir DNS TXT kaydı yayımlaması gerekir:

Örnek: contoso.com için DMARC, raporları dmarc@fabrikam.com adresine gönderir

adına DMARC raporlarını alma yetkisi fabrikam.com vermek için yöneticisinin contoso.comfabrikam.com aşağıdaki DNS TXT kaydını yayımlaması gerekir:

Hostname: contoso.com._report._dmarc
Type: TXT
Value: v=DMARC1;

Bu kayıt olmadan alıcılar DMARC raporlarını dış adrese teslim etmez.

DMARC sorun giderme için hızlı başvuru

Aşağıdaki tabloda yaygın DMARC belirtileri, olası nedenleri, tanılama adımları ve çözümleri için hızlı bir başvuru sağlanmaktadır.

Belirti Olası neden Tanılama adımı Çözüm
dmarc=fail ancak SPF ve DKIM ayrı ayrı geçer Hizalama hatası: etki alanları Kimden ile eşleşmiyor Authentication-Results içinde smtp.mailfrom= ve header.d= ile header.from= değerlerini karşılaştırın SPF/DKIM'i hizalanmış etki alanlarıyla yapılandırma
dmarc=bestguesspass Gönderen (From) etki alanı için yayımlanmış bir DMARC kaydı yok TXT kaydını sorgulama _dmarc.domain.com Microsoft bunun bir geçer sonucu olduğu çıkarımında bulunur. Açık bir DMARC kaydı yayımlayın.
dmarc=fail action=oreject ancak ileti teslim edildi DMARC'yi devre dışı bırakın veya liste/geçersiz kılmaya izin verin Kimlik avı önleme ilkesi ayarlarını ve Kiracı İzin Verme/Engelleme Listesi'ni denetleme Sıkı zorlama isteniyorsa Honor DMARC kayıt ilkesini etkinleştirin
dmarc=fail iletilen iletiler için İletme, SPF hizalamasını keser; gövde değişiklikleri DKIM'i bozar İletinin bir aracı sunucudan geçip geçmediğini denetleyin (X-MS-Exchange üst bilgileri) İletme hizmeti için güvenilir ARC imzalayıcısını yapılandırın
dmarc=fail Microsoft olmayan SaaS göndereni için Hizmet, MAIL FROM ve DKIM'de kendi etki alanını kullanır d= Hizmetin IP adresine ilişkin toplu raporları kontrol edin Hizmet için özel DKIM imzalamayı yapılandırma + MAIL FROM’u hizalama
dmarc=temperror Veya dmarc=permerror DMARC kaydını alma DNS sorunları (zaman aşımı, söz dizimi hatası) nslookup -type=TXT _dmarc.domain.com ile DMARC kaydı söz dizimini doğrulayın DNS söz dizimi hatalarını düzeltme; yalnızca bir _dmarc TXT kaydının var olduğundan emin olun
compauth=fail reason=000 Bileşik kimlik doğrulaması başarısız oldu (açık başarısız) Tüm kimlik doğrulama sonuçlarını denetleyin (SPF, DKIM, DMARC, ARC) Temel SPF/DKIM/DMARC sorunlarını düzeltme
compauth=fail reason=100 İlke uygulamasıyla DMARC açık başarısızlığı Başarısızlığa gönderenin DMARC ilkesi neden oldu Kaynakta hizalamayı düzeltin veya geçerliyse ARC/geçersiz kılmayı yapılandırın
Toplu raporlar alınmıyor rua adrese ulaşılamıyor veya etki alanları arası kimlik doğrulaması eksik Dış etki alanları için posta kutusunun mevcut olduğunu ve DNS yetkilendirme kaydını doğrulama Posta kutusu yönlendirmeyi düzeltme; TXT kaydı ekleme domain._report._dmarc

DMARC tanılama iş akışı

ile dmarc=failbir iletiyi tanılamak için aşağıdaki adımları kullanın:

  1. From alan adını belirleyin: header.from= üst bilgisinde bulunan değerini bulun.

  2. SPF hizalamasını denetleyin: smtp.mailfrom= etki alanı, header.from= etki alanıyla eşleşiyor mu?

    • Evet (aspf=r ile aynı kuruluş etki alanı): SPF hizalıdır.
    • Hayır: SPF hizalaması başarısız oluyor.
    • SPF hiç başarılı oldu mu (spf=pass vs spf=fail)? ise spf=fail, göndereni SPF kaydına ekleyerek önce SPF'yi düzeltin.

  3. DKIM hizalamasınıheader.d= denetleyin: DKIM-Signature değeri etki alanıyla header.from= eşleşmiyor mu?

    • Evet (adkim=r ile aynı kuruluş etki alanı): DKIM hizalıdır.
    • Hayır: DKIM hizalaması başarısız oluyor.
    • DKIM hiç başarılı oldu mu (dkim=pass vs dkim=fail)? ise dkim=fail, anahtarı yayımlayıp imzalamayı doğrulayarak DKIM'i düzeltin.

  4. Her iki hizalama da başarısız olursa DMARC başarısız olur. Çözüm seçenekleri:

    • SPF hizalamasını düzeltin: MAIL FROM adresini etki alanınız olarak değiştirin.
    • DKIM hizalamasını düzeltin: d=contoso.com ile imzalayın.
    • Bir alt alan adı kullanın: Kendi DMARC kaydına sahip sub.domain.com'dan gönderin.
    • İleti iletilirse: Güvenilir bir ARC imzalayıcısı yapılandırın.

  5. Politika eylemini kontrol edin:

    • p=none: Teslimat üzerinde hiçbir etkisi yoktur (yalnızca monitör).
    • p=quarantine: İleti, (DMARC ilkesine uy açıksa) Önemsiz E-posta’ya gönderilir.
    • p=reject: İleti reddedilir ( DMARC ilkesi açıksa). Geçerli posta reddedilirse ARC, izin verme listesi kullanın veya kaynakta kimlik doğrulamasını düzeltin.

DMARC sorun giderme için yararlı PowerShell komutları

Exchange Online PowerShell'e bağlanın ve kimlik avı önleme ilkesi DMARC ayarlarınızı doğrulamak için aşağıdaki komutları kullanın, DMARC ve DKIM DNS kayıtlarını denetleyin, son DMARC hatalarını gözden geçirin ve ARC yapılandırmasını inceleyin:

# Check your organization's anti-phishing policy DMARC settings
Get-AntiPhishPolicy | Format-List Name, HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

# Verify DMARC record for a domain
Resolve-DnsName -Name "_dmarc.contoso.com" -Type TXT | Select-Object -ExpandProperty Strings

# Check DKIM configuration (alignment prerequisite)
Get-DkimSigningConfig | Format-List Domain, Enabled, Selector1CNAME, Selector2CNAME

# Review messages that failed DMARC in the last 24 hours
Get-MailDetailSpamReport -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) |
  Where-Object { $_.MessageTraceId } |
  Select-Object Date, SenderAddress, RecipientAddress, Subject, SpamScore

# Check ARC configuration (for forwarding scenarios)
Get-ArcConfig | Format-List ArcTrustedSealers

# View anti-phishing policy DMARC override actions
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" |
  Select-Object HonorDmarcPolicy, DmarcQuarantineAction, DmarcRejectAction

İpucu

Belirli bir gönderen için DMARC hatalarını giderirken:

  1. Hata türünü tanımlamak için Authentication-Results üst bilgisi ile başlayın.
  2. Hacmi ve kaynak IP'lerini görmek için DMARC toplu raporlarınızla karşılaştırın.
  3. Belirli iletileri bulmak için Get-MessageTrace ve teslim olaylarını incelemek için Get-MessageTraceDetail kullanın.
  4. Gönderen geçerliyse, geçersiz kılmalar oluşturmadan önce SPF/DKIM hizalamasını düzeltmek için onlarla birlikte çalışın.

Sonraki adımlar

Microsoft 365'e gelen postalar için, kuruluşunuza teslim etmeden önce ileti aktarımında değişiklik yapan hizmetleri kullanıyorsanız güvenilen ARC mühürleyicilerini de yapılandırmanız gerekebilir. Daha fazla bilgi için Güvenilir ARC mühürleyicilerini yapılandırma konusuna bakın.

E-posta kimlik doğrulaması hatalarını tanılamak ve düzeltmek için bkz. Microsoft 365'te e-posta kimlik doğrulaması sorunlarını giderme.

  • Last updated on