Microsoft 365 SPF, DKIM ve DMARC Nasıl Yapılandırılır? (2026)

Özet (TL;DR): Microsoft 365'te giden e-postanızın Outlook, Gmail ve Yahoo gibi alıcılar tarafından reddedilmemesi veya gereksiz (junk) klasörüne düşmemesi için üç DNS kaydını bu sırayla kurmanız gerekir: önce SPF (yetkili gönderen sunucuları tanımlar), sonra DKIM (mesajı dijital olarak imzalar), en sonunda DMARC (SPF/DKIM başarısız olduğunda ne yapılacağını söyler ve rapor toplar). 5 Mayıs 2025'ten itibaren Outlook, günde 5.000'den fazla e-posta gönderen etki alanlarında bu üçünü zorunlu tutuyor; eksik yapılandırma 550 5.7.515 Access denied hatasıyla reddedilmeyle sonuçlanıyor. Bu rehber; SPF TXT kaydını oluşturmaktan, DKIM'i Microsoft Defender portalında etkinleştirip iki CNAME kaydını yayınlamaya, DMARC'ı p=none'dan p=reject'e kademeli olarak sertleştirmeye kadar her adımı ekran adlarıyla ve PowerShell komutlarıyla anlatır.

Neden SPF, DKIM ve DMARC Artık Zorunlu?

SMTP protokolü tasarımı gereği bir e-postanın göndereninin gerçekten iddia ettiği kişi olup olmadığını doğrulamaz. Bu açık; iş e-postası dolandırıcılığı (BEC), kimlik avı (phishing) ve marka taklidi saldırılarının temelini oluşturur. Saldırgan, sizin etki alanınızı (From adresinde) taklit eden sahte e-postalar göndererek müşterilerinizi veya çalışanlarınızı kandırabilir. SPF, DKIM ve DMARC bu boşluğu kapatan, birbirini tamamlayan üç yapı taşıdır — üçünden biri eksikse koruma da eksik kalır.

Teknik gerekliliğin ötesinde, artık ticari bir zorunluluk da var. Microsoft, Outlook'un yüksek hacimli gönderen gereksinimleri kapsamında 5 Mayıs 2025 itibarıyla şu kuralı uyguluyor: Outlook.com, Hotmail.com ve Live.com kullanıcılarına günde 5.000'den fazla e-posta gönderen etki alanları, SPF + DKIM + DMARC kayıtlarının tamamına sahip olmalıdır. Microsoft önce uyumsuz iletileri gereksiz klasörüne yönlendirdi; ardından politikayı sertleştirerek bu iletileri doğrudan reddetmeye başladı. Uyumsuz gönderen şu hatayı alır:

550 5.7.515 Access denied, sending domain [EtkiAlanı] does not meet the required authentication level.

Bu eşik bugün yalnızca Microsoft için geçerli değil; Google ve Yahoo da benzer gönderen gereksinimlerini yürürlüğe koydu. Yani 2026'da kurumsal e-postanızın teslim edilebilirliği, doğrudan bu üç kaydın doğru yapılandırılmasına bağlıdır. Microsoft Security tarafında anti-spoofing korumasının da temeli budur.

Ön Gereksinimler

Başlamadan önce aşağıdakilerin hazır olduğundan emin olun:

• Yönetici rolü: SPF/DKIM/DMARC'ı yapılandırmak için Genel Yönetici ya da Güvenlik Yöneticisi rolü gerekir. DKIM ayarları Microsoft Defender portalında (security.microsoft.com) yapılır.
• DNS erişimi: Etki alanınızın kayıt sağlayıcısında (GoDaddy, Cloudflare, Natro, İşNet vb.) TXT ve CNAME kaydı ekleyebilmeniz gerekir. Microsoft 365 yönetim merkezinden DNS'i otomatik yönetiyorsanız bazı kayıtlar oradan da eklenebilir.
• Doğrulanmış özel etki alanı: Örneğin sirketiniz.com etki alanı Microsoft 365'e eklenmiş ve doğrulanmış olmalı. Varsayılan onmicrosoft.com etki alanı yalnızca test içindir; düzenli gönderim için kullanmayın.
• Tüm gönderen kaynaklarınızın listesi: Microsoft 365'in yanı sıra kimler sizin adınıza e-posta gönderiyor? Pazarlama platformu (Mailchimp, HubSpot), CRM/ERP, fatura otomasyonu, yazıcı/tarayıcı SMTP relay'i — hepsini önceden çıkarın. SPF kaydının doğruluğu buna bağlıdır.
• Exchange Online PowerShell (isteğe bağlı ama önerilir): DKIM CNAME değerlerini almak ve imzalamayı etkinleştirmek için kullanışlıdır. Connect-ExchangeOnline ile bağlanın.

Sıralama kritik: SPF → DKIM → DMARC sırasını izleyin. DMARC, SPF ve DKIM sonuçlarına dayandığı için onları DMARC'tan önce kurmuş olmalısınız; aksi halde DMARC'ı p=reject yaparsanız meşru e-postanız da reddedilir.

Adım 1: SPF TXT Kaydını Oluşturun

SPF (Sender Policy Framework), etki alanınız adına e-posta göndermeye yetkili sunucu ve servisleri tanımlayan bir DNS TXT kaydıdır. Microsoft 365'te SPF için portal içinde bir ayar yoktur; kaydı doğrudan DNS sağlayıcınızda oluşturursunuz.

1.1. Temel senaryo: yalnızca Microsoft 365

Tüm e-postanız yalnızca Microsoft 365'ten gidiyorsa, etki alanınızın kökünde (@) tek bir TXT kaydı oluşturun:

v=spf1 include:spf.protection.outlook.com -all

Burada include:spf.protection.outlook.com Microsoft 365'i geçerli gönderen olarak tanımlar; -all ise "bu kayıttaki kaynaklar dışında hiçbir yerden gelen mesajı kabul etme" anlamına gelen katı (hard fail) kuraldır.

1.2. Ek gönderen kaynakları varsa

Microsoft 365'in yanında şirket içi sunucu veya üçüncü taraf servis kullanıyorsanız, bunları aynı tek SPF kaydına ekleyin. Örneğin bir IP adresi ve bir pazarlama servisi:

v=spf1 ip4:192.0.2.10 include:spf.protection.outlook.com include:servers.mcsv.net -all

Geçişi güvenli yapmak için ilk aşamada -all yerine yumuşak (soft fail) kuralı ~all kullanabilir, raporları izleyip tüm kaynakları doğruladıktan sonra -all'a geçebilirsiniz.

1.3. Kritik SPF kuralları

• Etki alanı başına yalnızca BİR SPF kaydı olabilir. İkinci bir SPF kaydı eklerseniz teslimat ve istenmeyen e-posta sınıflandırma hataları oluşur. Mevcut bir SPF kaydınız varsa yenisini oluşturmayın; Microsoft değerlerini var olan kayda ekleyin.
• 10 DNS arama sınırı: SPF değerlendirmesi en fazla 10 DNS aramasına izin verir. Çok sayıda include: kullanıyorsanız bu sınırı aşıp permerror alabilirsiniz. Gerekirse alt etki alanlarıyla bölün veya kararlı IP aralıklarına sahip sağlayıcılar için SPF düzleştirme (flattening) uygulayın — ancak spf.protection.outlook.com'u asla düzleştirmeyin; Microsoft'un IP'leri sık değişir.
• Yaygın yazım hataları: include:'tan sonra boşluk bırakmak, alan adı sonuna nokta koymak (outlook.com.) veya iki nokta yerine eşittir (include=) kullanmak kaydı bozar.
• Her alt etki alanı kendi SPF kaydını ister; alt etki alanları üst etki alanının kaydını miras almaz.

Tam söz dizimi ve sağlayıcıya özel örnekler için Microsoft'un SPF yapılandırma belgesine bakın.

Adım 2: DKIM İmzalamayı Etkinleştirin

DKIM (DomainKeys Identified Mail), giden mesajın önemli öğelerini (From adresi dahil) özel bir anahtarla dijital olarak imzalar ve imzayı ileti başlığına ekler. Alıcı sunucu, yayımladığınız ortak anahtarla imzayı doğrulayarak mesajın yolda değiştirilmediğini teyit eder. DKIM, mesaj iletildiğinde (forward) bile geçerliliğini koruduğu için SPF'in zayıf kaldığı senaryoları kurtarır.

2.1. Defender portalında CNAME değerlerini alın

1. Microsoft Defender portalında (security.microsoft.com) E-posta ve işbirliği > İlkeler ve kurallar > Tehdit ilkeleri > E-posta kimlik doğrulama ayarları sayfasına gidin. Doğrudan adres: https://security.microsoft.com/authentication.
2. DKIM sekmesini seçin. Özel etki alanınızın Durum değeri NoDKIMKeys ve geçiş düğmesi Devre Dışı olmalıdır.
3. Etki alanınızın satırında geçiş düğmesini Etkinleştir'e kaydırmayı deneyin. Henüz CNAME kayıtları olmadığı için bir İstemci hatası iletişim kutusu açılır; Tamam'a basın. Durum artık CnameMissing olur.
4. Etki alanı satırına tıklayarak ayrıntılar bölmesini açın ve Publish CNAMEs (CNAME'leri Yayımla) bölümündeki iki değeri kopyalayın.

Alternatif olarak değerleri Exchange Online PowerShell'den de alabilirsiniz:

Get-DkimSigningConfig -Identity sirketiniz.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

2.2. İki CNAME kaydını DNS'te yayımlayın

DKIM, anahtar rotasyonunu desteklemek için iki CNAME kaydı (selector1 ve selector2) gerektirir. DNS sağlayıcınızda şu iki kaydı oluşturun (değerler etki alanınıza özeldir, mutlaka portaldan/PowerShell'den alın):

• Ana bilgisayar adı: selector1._domainkey → Hedef: selector1-sirketiniz-com._domainkey.sirketiniz.n-v1.dkim.mail.microsoft
• Ana bilgisayar adı: selector2._domainkey → Hedef: selector2-sirketiniz-com._domainkey.sirketiniz.n-v1.dkim.mail.microsoft

Önemli (Mayıs 2025 yeni format): Microsoft, yeni eklenen özel etki alanları için DKIM CNAME formatını güncelledi. Yeni formatta hedef değeri ...<onmicrosoftöneki>.<dinamikkarakter>-v1.dkim.mail.microsoft yapısındadır; buradaki dinamik karakter (örneğin n veya r) Microsoft tarafından otomatik atanır ve değiştirilemez. Mayıs 2025'ten önce eklenmiş etki alanları ise eski formatı (...._domainkey.sirketiniz.onmicrosoft.com) kullanmaya devam eder. Doğru değeri tahmin etmeyin — her zaman portaldan veya PowerShell'den kopyalayın.

2.3. İmzalamayı etkinleştirin ve doğrulayın

CNAME kayıtları DNS'te yayıldıktan sonra (birkaç dakika ile birkaç saat arası sürebilir) imzalamayı etkinleştirin. Defender portalında geçiş düğmesini tekrar Etkinleştir'e kaydırın veya PowerShell kullanın:

Set-DkimSigningConfig -Identity sirketiniz.com -Enabled $true

Doğrulamak için yapılandırmayı yeniden sorgulayın; etki alanının Enabled değeri True ve Status değeri Valid olmalıdır:

Get-DkimSigningConfig -Identity sirketiniz.com | Format-List Enabled,Status

Microsoft, parolaları periyodik değiştirmeniz gibi DKIM anahtarlarını da düzenli döndürmenizi (key rotation) önerir; bu yüzden iki seçici (selector) kaydı vardır. Anahtar döndürmede yeni özel anahtarın imzalamaya başlaması 96 saat (4 gün) sürer. Tüm adımların ayrıntısı için DKIM yapılandırma belgesine bakın.

Adım 3: DMARC Kaydını Yayınlayın (Kademeli)

DMARC (Domain-based Message Authentication, Reporting and Conformance); SPF ve DKIM'in From adresindeki etki alanıyla hizalanıp hizalanmadığını kontrol eder, başarısız mesajlara ne yapılacağını söyler ve sonuçları rapor olarak toplar. Bir mesaj, SPF veya DKIM kontrollerinden en az biri hizalı geçerse DMARC'tan geçer; yalnızca ikisi de başarısız olursa DMARC başarısız olur.

3.1. DMARC TXT kaydının söz dizimi

_dmarc ana bilgisayar adıyla bir TXT kaydı oluşturun. Temel söz dizimi:

v=DMARC1; p=<reject | quarantine | none>; pct=100; rua=mailto:[email protected]; ruf=mailto:[email protected]

• p=none — Başarısız mesajlar için eylem önerilmez; yalnızca izleme/test amaçlıdır.
• p=quarantine — Başarısız mesajlar karantinaya/gereksiz klasörüne alınır.
• p=reject — Başarısız mesajlar reddedilir. Nihai hedef budur.
• rua=mailto: — Toplu (aggregate) raporların gönderileceği adres; hangi kaynakların DMARC'tan geçip kaldığını görürsünüz.
• pct= — Politikanın uygulanacağı mesaj yüzdesi; pct=10, pct=25 gibi kademeli artırılabilir (varsayılan 100).

3.2. Kademeli yaklaşım: none → quarantine → reject

Microsoft'un önerdiği güvenli yol, meşru e-postayı yanlışlıkla engellememek için düşük hacimli bir etki alanından başlayıp kademeli sertleştirmektir:

1. p=none ile başlayın ve toplu raporları izleyin. Raporlar; meşru trafiğinizin ne kadarının DMARC kapsamında olduğunu ve nereden sahte mesaj gönderildiğini gösterir. Örnek: v=DMARC1; p=none; pct=100; rua=mailto:[email protected]
2. p=quarantine'a yükseltin. p=none'ı yeterince izledikten sonra başarısız mesajları karantinaya alın ve sonuçları izlemeye devam edin.
3. p=reject'e geçin. Yanlış pozitif kalmadığından emin olduğunuzda nihai politikaya geçin. Outlook'un yüksek hacimli gönderen gereksinimi en az p=none ister; ancak gerçek koruma p=reject ile gelir.

Hizalama modu: aspf (SPF) ve adkim (DKIM) etiketleri, From alanının doğrulanan etki alanıyla ne kadar katı eşleşmesi gerektiğini belirler. Varsayılan r (relaxed/gevşek) alt etki alanlarına izin verir; s (strict/katı) tam eşleşme ister. Çoğu kurum için varsayılan gevşek mod uygundur.

3.3. onmicrosoft.com etki alanı için DMARC

Yalnızca *.onmicrosoft.com (MOERA) etki alanını kullanıyorsanız, SPF ve DKIM zaten yapılandırılmıştır ama DMARC kaydını Microsoft 365 yönetim merkezinden eklemeniz gerekir: Ayarlar > Etki Alanları → onmicrosoft.com etki alanı → DNS kayıtları → Kayıt ekle → Tür TXT, ad _dmarc, değer v=DMARC1; p=reject. Tüm söz dizimi için DMARC yapılandırma belgesine bakın.

Doğrulama ve Test Adımları

Üç kaydı da yayınladıktan sonra gerçekten çalıştığını teyit edin:

• Kendinize bir test e-postası gönderin (örneğin bir Gmail veya Outlook.com adresine). Alıcıda iletiyi açın, ileti başlığını/kaynağını göster seçeneğiyle Authentication-Results satırına bakın. İdeal sonuç: spf=pass, dkim=pass ve dmarc=pass.
• DKIM imzasını teyit edin: İleti başlığındaki DKIM-Signature alanında d=sirketiniz.com ve s=selector1-sirketiniz-com değerlerini görmelisiniz. d= değerinin From etki alanınızla eşleşmesi (hizalama) DMARC için kritiktir.
• PowerShell ile DKIM durumu: Get-DkimSigningConfig çıktısında Status: Valid görün.
• DMARC raporlarını izleyin: rua adresine gelen toplu raporlarla hangi kaynakların geçtiğini/kaldığını takip edin. Raporları okumayı kolaylaştıran MISA Kataloğu'ndaki DMARC raporlama hizmetlerini kullanabilirsiniz.
• İleti izleme: Reddedilen giden iletiler için Defender portalında Message trace ile hata kodunu ve nedenini görün.

Yaygın Hatalar ve Çözümleri

Yapılandırma sırasında en sık karşılaşılan sorunlar ve doğru çözümleri:

• Pazarlama servisi DMARC'tan kalıyor (hizalama hatası): Mailchimp/HubSpot gibi servisler kendi altyapısından gönderir; SPF ve DKIM kendi etki alanları için geçse de sizin From adresinizle hizalanmaz. Çözüm: servisi sizin etki alanınızla DKIM imzalayacak şekilde yapılandırın (tercih edilen) veya pazarlama için ayrı bir alt etki alanı (pazarlama.sirketiniz.com) kullanın.
• İki SPF kaydı: Etki alanında birden fazla SPF TXT kaydı varsa SPF permerror verir ve mesajlar reddedilebilir. Tüm include'ları tek SPF kaydında birleştirin.
• 10 DNS arama sınırını aşma: Çok sayıda include: kullanmak SPF'i geçersiz kılar. Alt etki alanlarıyla bölün veya kararlı IP'li sağlayıcılar için düzleştirme uygulayın.
• DKIM CnameMissing takılı kalıyor: CNAME değerlerinde tire, nokta veya alt çizgi yazım hatası olabilir. Değerleri portaldan tekrar kopyalayın, DNS yayılımını bekleyin ve Set-DkimSigningConfig'i yeniden çalıştırın.
• E-posta yönlendirme (forwarding) SPF/DKIM'i bozuyor: Sunucu tabanlı yönlendirme SPF'i kırar; mesajı değiştiren ağ geçitleri DKIM'i kırar. Bu meşru senaryolar için güvenilir ARC mühürleyiciler yapılandırın.
• DMARC'ı erken p=reject yapma: SPF/DKIM'i tam doğrulamadan reject'e geçmek meşru e-postanızı reddettirir. Her zaman p=none ile başlayın, raporları izleyin, sonra sertleştirin.

İleri Yapılandırma ve En İyi Uygulamalar

• Park edilmiş (parked) etki alanlarını koruyun: E-posta göndermeyen etki alanlarında bile v=spf1 -all ve v=DMARC1; p=reject; yayınlayın; böylece taklit edilemezler.
• Toplu ve işlemsel e-postayı ayrı alt etki alanlarına taşıyın: Örneğin pazarlama için m.sirketiniz.com, fatura/bildirim için t.sirketiniz.com. Bu, ana etki alanınızın gönderen itibarını korur.
• Çok yüksek hacimli gönderimi Exchange Online dışına çıkarın: Exchange Online toplu gönderim için tasarlanmamıştır. Bülten ve kampanyalar için Azure üzerindeki Azure Communication Services e-postasına geçin. Bu konuyu Exchange Online dış alıcı gönderim sınırı (TERRL) çözümü yazımızda ayrıntılı ele aldık.
• DKIM anahtarlarını döndürün: Güvenlik için DKIM anahtarlarını periyodik olarak yenileyin; iki seçici tam da bunun içindir.
• DMARC raporlamasını sürekli izleyin: rua raporları, yeni/bilinmeyen gönderen kaynaklarını ve taklit girişimlerini erken yakalamanızı sağlar.
• Tüm tabloyu birlikte değerlendirin: SPF, DKIM ve DMARC Microsoft 365 e-posta güvenliğinin temel katmanıdır; üstüne Defender for Office 365 ile Güvenli Bağlantılar ve Güvenli Ekler korumasını ekleyin.

Sıkça Sorulan Sorular (SSS)

SPF, DKIM ve DMARC'ı hangi sırayla kurmalıyım?

Her zaman SPF → DKIM → DMARC sırasıyla. DMARC, SPF ve DKIM sonuçlarının From etki alanıyla hizalanmasına dayanır; bu yüzden ikisini DMARC'tan önce kurmuş ve doğrulamış olmanız gerekir. SPF ve DKIM hazır olmadan DMARC'ı p=reject yaparsanız kendi meşru e-postanız da reddedilir.

Sadece SPF yeterli değil mi, DKIM ve DMARC şart mı?

Hayır, tek başına SPF yetersizdir. SPF yalnızca zarftaki MAIL FROM etki alanını doğrular, görünen From adresini denetlemez; ayrıca yönlendirme ile kırılır. DKIM mesajı imzalayarak yönlendirmede bile geçerli kalır, DMARC ise ikisinin From ile hizalanmasını zorlar ve raporlama sağlar. 2026'da Outlook, Google ve Yahoo yüksek hacimli gönderenlerden üçünü de talep ediyor; biri eksikse e-postanız reddedilebilir veya gereksize düşer.

DMARC'ı doğrudan p=reject ile başlatabilir miyim?

Önerilmez. Her zaman p=none ile başlayın ve toplu (rua) raporları izleyerek tüm meşru gönderen kaynaklarınızın (pazarlama platformu, CRM, fatura otomasyonu vb.) SPF/DKIM'den geçtiğini doğrulayın. Ardından p=quarantine, en son p=reject'e geçin. Erken reject, gözden kaçan bir gönderen yüzünden meşru e-postanızın toplu reddine yol açar.

DKIM CNAME değerlerimi neden tahmin etmemeliyim?

Microsoft, Mayıs 2025'te yeni özel etki alanları için DKIM CNAME formatını değiştirdi; artık hedef değer Microsoft tarafından atanan bir dinamik karakter içeriyor (örneğin ...sirketiniz.n-v1.dkim.mail.microsoft). Eski ve yeni format aynı seçici için bir arada kullanılamaz. Bu yüzden değerleri her zaman Defender portalındaki Publish CNAMEs bölümünden veya Get-DkimSigningConfig komutundan kopyalayın; eski örneklerden tahmin ederseniz DKIM Valid olmaz.

DNS kayıtları ne kadar sürede etkin olur?

DNS değişiklikleri sağlayıcıya ve TTL (yaşam süresi) ayarına göre birkaç dakikadan birkaç saate kadar yayılır. DKIM imzalamayı etkinleştirmeden önce CNAME kayıtlarının yayılmasını bekleyin; aksi halde "CNAME bulunamadı" hatası alırsınız. DKIM anahtar döndürmesinde ise yeni anahtarın imzalamaya başlaması ayrıca 96 saat sürer.

550 5.7.515 hatası alıyorum, ne yapmalıyım?

Bu hata, etki alanınızın Outlook'un yüksek hacimli gönderen kimlik doğrulama gereksinimini karşılamadığını gösterir. Üç kaydı da (SPF, DKIM, DMARC) doğru yapılandırın; özellikle en az p=none DMARC politikasının yayınlandığından ve SPF ya da DKIM ile hizalandığından emin olun. Kayıtları yayınladıktan sonra DNS yayılımını bekleyin ve test e-postasıyla dmarc=pass sonucunu doğrulayın.

Sonuç: E-posta Teslimatınızın Temelini Sağlamlaştırın

SPF, DKIM ve DMARC artık "iyi olsa güzel olur" değil; 2026'da kurumsal e-postanızın teslim edilebilirliğinin ön koşulu. Outlook, Google ve Yahoo'nun yüksek hacimli gönderen gereksinimleri sayesinde, bu üç kaydı eksik bırakmak doğrudan 550 5.7.515 reddine veya gereksiz klasörüne düşmeye yol açıyor. Doğru yol bellidir: önce tüm gönderen kaynaklarınızı tek bir SPF kaydında toplayın, ardından DKIM'i Defender portalında etkinleştirip iki CNAME'i yayınlayın, en sonunda DMARC'ı p=none'dan başlatıp raporları izleyerek p=reject'e kadar kademeli sertleştirin.

Bu disiplin yalnızca teslimatı düzeltmez; markanızı taklit eden kimlik avı saldırılarına karşı da güçlü bir kalkan kurar. Kademeli ilerleyin, her aşamada raporlarla doğrulayın ve değerleri asla tahmin etmeyin — daima Microsoft'un resmi portalından veya PowerShell'den alın.

Microsoft İstanbul — Xen Bilişim ekibi olarak, kurumunuzun e-posta kimlik doğrulama yolculuğunda SPF/DKIM/DMARC kayıtlarının kurulumundan kademeli DMARC sertleştirmeye, pazarlama e-postasının doğru alt etki alanına ve Azure Communication Services'a taşınmasına kadar uçtan uca destek sağlıyoruz. İletişim sayfamızdan bize ulaşın.