Google Workspace DNS kurulumu: MX, SPF, DKIM ve DMARC

Adımlar

1. Alan adını doğrulayın. Alan adınızı Google Yönetici konsoluna ekleyin ve gösterdiği doğrulama TXT kaydını yayımlayın. Değer hesabınıza özeldir.
2. Kullanıcıları oluşturun. MX’i taşımadan önce bütün posta kutularını ve takma adları oluşturun; geçişten sonra hiçbir adres geri dönmesin.
3. MX kaydını yayımlayın. Eski sağlayıcının MX kayıtlarını silin ve smtp.google.com adresine işaret eden, önceliği 1 olan tek bir MX kaydı ekleyin.
4. SPF’i yayımlayın. Alan adının köküne tek bir TXT kaydı ekleyin: v=spf1 include:_spf.google.com ~all. Alan adınız adına başka hizmetler de gönderim yapıyorsa onların include: ifadesini aynı kayda ekleyin.
5. DKIM’i açın. Yönetici konsolunda 2048 bitlik bir anahtar üretin, gösterilen TXT kaydını google._domainkey adına yayımlayın, sonra aynı DKIM ayarlarına dönüp kimlik doğrulamayı oradan başlatın. Başlatmadığınız sürece Google kendi alan adıyla imzalar ve DKIM sizin alan adınızla hizalanmaz.
6. DMARC ekleyin ve kontrol edin. p=none ile bir DMARC kaydı yayımlayın, ardından bu sayfadaki kontrolleri çalıştırın.

DMARC

DMARC her sağlayıcıda aynıdır: _dmarc.example.com adında tek bir TXT kaydı. p=none ve bir rapor adresiyle başlayın; böylece teslimatı etkilemeden rapor almaya başlarsınız.

Raporları birkaç hafta okuyun. Adınıza e-posta gönderen bütün meşru kaynaklar alan adınızla hizalı biçimde SPF ya da DKIM’den geçiyorsa önce p=quarantine, sonra p=reject’e geçin. Meşru e-postaların kaybolmasının en sık nedeni, bütün göndericilerde DKIM açılmadan reject’e geçilmesidir.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

İsteğe bağlı: MTA-STS, TLS-RPT ve BIMI

MTA-STS, size e-posta teslim eden sunuculara TLS’i zorunlu tutmalarını söyler. Bir TXT kaydı ve mta-sts.example.com adresinde HTTPS ile sunulan bir politika dosyası gerekir; politikada sağlayıcınızın MX sunucuları birebir yazmalıdır.

TLS-RPT, göndericilerden TLS teslimat hatalarını seçtiğiniz adrese raporlamalarını ister. Tek bir TXT kaydıdır, teslimatı etkilemez.

BIMI, bazı e-posta sağlayıcılarının logonuzu göstermesini sağlar. DMARC’ın quarantine ya da reject olması gerekir; sağlayıcıların çoğu ayrıca doğrulanmış marka sertifikası ister.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

TTL önerisi

Hâlihazırda e-posta alan bir alan adında MX kayıtlarını değiştirmeden önce TTL değerini 300 saniyeye indirin ve eski TTL süresinin dolmasını bekleyin. Böylece çözümleyiciler yeni kayıtları dakikalar içinde alır.

Yeni kurulum birkaç gün sorunsuz çalıştıktan sonra TTL’i yeniden yükseltin; 3600 saniye yaygın bir değerdir. SPF, DKIM ve DMARC kayıtları seyrek değişir, 3600 onlar için uygundur.

Değişiklikler ne kadar sürede görünür?

DNS sağlayıcınız kaydı yayımladığı anda yetkili nameserver’larınız yeni yanıtı verir. Eski yanıtı önbelleğine almış bir çözümleyici onu eski TTL dolana kadar tutar; daha önce hiç var olmamış bir ad ise SOA kaydınızdaki negatif önbellek süresi boyunca "yok" olarak hatırlanabilir.

Bir değişikliğin her yerde aynı anda geçerli olduğu bir an yoktur. Yayılım aracı, belirli bir genel çözümleyici kümesinin kontrol anında ne yanıt verdiğini "12 çözümleyiciden 9’u" gibi bir sayıyla gösterir; bundan fazlasını söylemez.

Sağlayıcılar kayıtlarınızı kendi takvimlerine göre yeniden kontrol eder; bu yüzden DNS doğru olduğu hâlde paneldeki doğrulama bir süre daha kırmızı kalabilir.

Sık yapılan hatalar

• DKIM kaydını yayımlayıp Yönetici konsolunda kimlik doğrulamayı hiç başlatmamak.
• Google ile ~all değerini kalıcı olarak kullanmak kabul edilebilir; yönlendirme hizmetlerini ve toplu gönderim araçlarını bozan şey, bütün göndericiler listelenmeden -all’a geçmektir.
• İki SPF kaydı. Bir alan adında v=spf1 ile başlayan yalnızca bir TXT kaydı olabilir; ikincisi SPF’in kalıcı hatayla başarısız olmasına yol açar. include: ifadelerini tek kayıtta birleştirin.
• Eski sağlayıcının MX kayıtlarını yenilerin yanında bırakmak. E-posta o zaman önceliğe ve şansa göre ikisinden birine teslim edilir.
• Alan adını kendisi ekleyen bir ad alanına tam adı yazmak; sonuç google._domainkey.example.com.example.com olur. Kaydı kaydettikten sonra sorgulayıp bakın.
• Yarıda kesilmiş DKIM anahtarı. Uzun TXT değerleri en çok 255 karakterlik tırnaklı parçalara bölünmelidir; DNS panellerinin çoğu bunu kendisi yapar, bazıları yapmaz.
• Birkaç include: ekledikten sonra SPF’te onu aşan DNS sorgusu. SPF kontrol aracı bunları sayar.
• Bir CNAME’e ya da IP adresine işaret eden MX kaydı. MX, A ya da AAAA kaydı olan bir sunucu adına işaret etmelidir.