Gerçek DreamHost gönderme yolunu tanımlayın
Bu kılavuz DreamHost'ta barındırılan postalar için geçerli olup, DreamHost'a kayıtlı bir etki alanına bağlı her uygulama veya posta hizmeti için geçerli değildir. Kayıt, yetkili DNS barındırma ve giden posta aktarımı ayrı gerçeklerdir. Envanter web postası, masaüstü posta istemcileri, web sitesi iletişim formları ve bülten eklentileri ayrı ayrı. Bir etki alanının sıradan posta kutusu DreamHost SMTP kullanırken, web sitesi yerel olarak PHP postasını kullanarak gönderir ve bu da imzalama davranışını değiştirir.
DreamHost, posta sunucusu aracılığıyla web postası, posta istemcisi veya SMTP formu aracılığıyla gönderilen postaların otomatik olarak DKIM imzalı olduğunu söylüyor. Belgeleri, normal sendmail veya PHP posta yolu da dahil olmak üzere, SMTP kullanmayan web sitesi postalarını açıkça hariç tutar. Yayınlanan bir anahtar, bir mesajı tek başına imzalayamaz. Eksik imzaları düzeltmek için DNS düzenlemeden önce, uygulamanın gerçekten kimliği doğrulanmış posta sunucusu aracılığıyla gönderilip gönderilmediğini kontrol edin.
Hesap DKIM kaydını bulun ve yayınlayın
DreamHost tarafından barındırılan postalar için DreamHost oluşturur ve yönetir DKIM E-posta hizmetini kullanarak alan adı ve alt alan adları için kayıtlar. Web Sitelerini Yönet'i açın, alan adının üç noktalı menüsünü kullanın ve DNS Ayarları'nı seçin. Izgara görünümünde menü etki alanının altında görünür; liste görünümünde sağda görünür. Şunu inceleyin: TXT kaydı adında _domainkey ile. Belgeler dreamhost'u göstermektedir. _domainkey seçici Ve 2048 bit anahtarlar, ancak alan adınızın değerinin kendi panelinizden gelmesi gerekir.
Yetkili ise ad sunucuları DreamHost'un dışındaysanız, o hesabın tam kaydını gerçek DNS hizmetine kopyalayın. Bir kayıt DreamHost'un panelinde görünür olması, başka bir sağlayıcı yetkili olduğunda herkese açık yayın sağlamaz. Sahibin adını o editörün göreceli adı veya tam nitelikli adı kurallarına uyarlayın ve ortaya çıkan genel adı inceleyin. Anahtar verilere boşluk eklemeden genel anahtarı koruyun. Bir yardım makalesinde basılan örnek anahtarı yayınlamayın.
Farklı bir aktif hizmet tarafından kullanılan seçicinin sağlam kalması gerekir. Farklı hizmetler farklı seçiciler yayınlayabilir, ancak her imzanın kendi d= alanı altında kendi s= seçicisini çözümlemesi gerekir. Örnek seçiciyi kullandığını varsaymadan önce iletinin gerçek imzasını doğrulayın. Etki alanı başka bir sağlayıcı üzerinden gönderiliyorsa, bir DreamHost anahtarının trafiğinin kimliğini doğrulamasını beklemek yerine, o sağlayıcının imzalama talimatlarını alın.
Varsayılan ve özel SPF dikkatlice inceleyin
DreamHost, posta hizmeti için bu otomatik politikayı belgelemektedir: v=spf1 mx include:netblocks.dreamhost.com include:relay.mailchannels.net -all . Bunu mevcut çoklu sağlayıcı politikasının evrensel bir alternatifi olarak değil, mevcut yapılandırmanızla karşılaştırmak için belgelenmiş bir varsayılan olarak değerlendirin. Hangi ana bilgisayarların ve zarf alanlarının gerçekte yetkilendirmeye ihtiyacı olduğunu doğrulayın. SPF alt alanlar için ayrı olarak değerlendirilir, dolayısıyla bir apex kaydı otomatik olarak ayrı bir zarf alt alanını kapsamaz.
Özel ekleme SPF kaydı DreamHost'ta varsayılan kaydını kaldırır. DreamHost hâlâ yetkili bir gönderense etkin rotaları ve arama bağımlılıklarını inceledikten sonra birleştirilmiş özel ilkedeki uygun izinleri koruyun. Belgelerde ayrıca özel bir SPF kaydının silinmesinin varsayılanın otomatik olarak geri dönmesine neden olduğu belirtiliyor. Kurtarma sırasında bu davranış önemlidir: silme işlemi mutlaka SPF yetkilendirmesinin kaldırılması anlamına gelmez ve geri yüklenen varsayılan, diğer yasal hizmetlerin atlanmasına neden olabilir.
Harici yetkili DNS , ilgili politikayı orada yönetin. Sahibinde tam olarak geçerli bir SPF TXT politikası bulundurun. Varsayılanı korumak için ikinci bir tane eklemeyin ve tarihsel bir örnekte gösterilen her eklemenin sonsuza kadar gerekli olduğunu varsaymayın. Otomatik olarak geri yüklenen kayıtların etkisi de dahil olmak üzere, değişikliklerden ve herhangi bir geri alma işleminden sonra yayınlanan politikayı yeniden kontrol edin.
Web sitesi postasını taşıma katmanında düzeltin
Sendmail veya PHP posta kullanan bir iletişim formu veya WordPress eklentisi için, amaçlanan rotanın DreamHost tarafından barındırılan posta olması durumunda desteklenen, kimliği doğrulanmış bir SMTP yapılandırmasını tercih edin. Yalnızca eklentinin bağlantı testi yerine formun gerçek çıktısını doğrulayın. Gerçek iş akışını tetikleyin, alınan mesajı saklayın ve imzalayanı ve görünen Kimden kimliğini onaylayın. Bir uygulama başarıyla bağlanabilir ancak üretimde yine de farklı bir gönderen adresi kullanabilir.
DreamHost ayrıca yönetici kullanıcılı bir Özel Sunucuya veya DreamCompute'a kendi kendine yönetilen DKIM kurulumunu da belgeliyor, ancak manuel olarak yüklenen yazılımı destekleyemediğini söylüyor. Bu, yönetilen SMTP yoluna eşdeğer bir onay kutusu değil, ayrı bir sistem yönetimi projesidir. Bunu bir iletişim formu için incelenmemiş bir geçici çözüm olarak tanıtmayın. Bunu seçerseniz anahtarlar, imzalama, güncellemeler ve kurtarma için ayrı bir operasyonel plan isteyin.
Yalnızca kontrol panelini değil gönderen kimliğini de doğrulayın
Yeşil kurulum göstergesi yalnızca ürünün gerçekleştirdiği kontrolü belirler. Kabul için, gerçek iş akışı üzerinden, alınan başlıklarını inceleyebileceğiniz bir posta kutusuna kontrollü bir mesaj gönderin. Başarılı bir DNS aramasının ekran görüntüsü yerine orijinal mesajı koruyun. Alıcı sistem tarafından gösterilen görünür Kimden etki alanını, yani SMTP zarf etki alanını kaydedin. DKIM imzası'sd= imzalama alanı ve s= seçici ve alıcı sistemin Authentication-Results. Bir gönderen ekledi diye Authentication-Results alanına güvenmeyin.
SPF görünür Kimden adresinin değil, zarf kimliğinin kimliğini otomatik olarak doğrular. DKIM imzalama alanı için bir imzayı doğrular. DMARC Geçerli olanın altında görünür Kimden alanıyla aynı hizada olan bir geçiş yolu gerektirir hizalama modu. Sağlayıcıya ait bir zarf, markanız için uyumlu SPF üretmeden SPF geçebilir. Bunun tersine, geçerli bir hizalanmış DKIM imzası, SPF hizalanmadığında bile geçen DMARC yolunu sağlayabilir. DNS değiştirmeden önce gerçek kimlikleri inceleyin.
Bu açıklayıcı kabul durumunu, sağlayıcının varsayılan durumu hakkında bir iddia olarak değil, kullanın: Bir iletide From learning@example.com , zarf bounce@vendor.example.net ve d=example.com. ile doğrulanmış bir DKIM imzası bulunur. vendor.example.net SPF başarısı tek başına example.com ile uyumlu değildir; d=example.com ile geçerli imza, tam DKIM hizalamasını sağlar. Alıcı bunun yerine geçersiz bir imza bildirirse örnekte artık o geçiş hizalı yol yoktur. Hem kimlik doğrulama sonucunu hem de geçerli olduğu etki alanını kaydedin.
Arızaları sabit bir sırayla teşhis edin
Öncelikle, tam alan adı için yetkilendirilen ad sunucularının, düzenlediğiniz sunucular olduğunu doğrulayın. Beklenen sahip adı ve kayıt türü için yetkili sunucuları sorgulayın. Yanıtlarını hesabın sağladığı değerlerle karşılaştırın, yanlışlıkla alan adı son eki çoğaltmasını, eksik seçici etiketlerini, kısaltılmış anahtarları ve CNAME çakışmalarını kontrol edin. Ancak yetkili yanıt doğru olduktan sonra özyinelemeli önbelleğe almayı araştırmalı veya daha önceki bir TTL'nin süresinin dolmasını beklemelisiniz. Dünya çapında garantili tek bir yayılma tarihi yoktur.
Daha sonra başarısız rotada mesaj testini tekrarlayın. Bir web uygulaması, insan posta kutusundan farklı bir aktarım kullanabilir ve başarılı bir önizleme, üretim bildirimlerinin aynı kimliği kullandığının kanıtı değildir. DNS doğruysa ancak imza eksikse ilgisiz SPF izinleri eklemek yerine gönderen aktarım ve ürün yapılandırmasını araştırın. Kimlik doğrulama başarılı olursa ancak posta spam klasörüne yerleştirilirse, başlıkları saklayın ve itibarı, içeriği ve alıcı işlemlerini ayrı ayrı araştırın. Kimlik doğrulama, gelen kutusunun yerleşimini garanti etmez.
Kontrol ve tamamlama kanıtlarını değiştirin
Değişiklik yapmadan önce önceki kayıt kümelerini, onaylanmış yeni değerleri, etki alanı sahibini, etkilenen her iş akışının iş sahibini ve belirli bir kurtarma kararını saklayın. Gönderen eklemek için asla aynı sahipte ikinci bir SPF politikası oluşturmayın. Birleştirilmiş bir politikayı ve onun DNS arama bağımlılıklarını gözden geçirin; ilgisiz TXT kayıtları bir arada bulunabilir ancak birden fazla aday SPF politikası bir hatadır. Başka bir gönderenin seçicisinin üzerine yazmayın. Başarısız bir entegrasyonu gizlemek için tüm alanın DMARC politikasını zayıflatmayın.
Kabul, kapsam dahilindeki her gönderme yolu için yetkili DNS kanıtını, ürün doğrulamasını ve alınan ileti kimlik kaydını gerektirir. İş akışının beklediği yanıtları ayrı ayrı test edin. Bunlar, tamamlanmış testler değil, önerilen kontrollerdir: Bu kılavuz, canlı kiracı değişiklikleri, DNS ölçümleri veya teslim edilen mesaj sonuçları olmaksızın, tutulan belgelere ve sentetik muhakemeye dayanmaktadır. Bir insan sahibi, kanıtları incelemeli ve herhangi bir üretime geçiş işlemini onaylamalıdır. Değiştirme işlemi gösterilene kadar mevcut çalışma rotalarını kullanılabilir durumda tutun ve eski izinleri yalnızca kalan bağımlılığın bunları kullanmadığını doğruladıktan sonra kaldırın.
Politikayı değiştirmeden önce aktarım uyumsuzluğunu değerlendirin
Yazılı durum DH-01 için, help@example.com adresinden gelen personel web postasının güvenilir bir geçen DKIM imzasına sahip olduğunu varsayalım d=example.com, s=dreamhost. Web sitesi formu bunun yerine PHP postasını kullanıyor ve gözlemlenen DKIM imzası yok; SPF sonucu bilinmiyor. İlk rota öngörülen hizalanmış yola sahipken, ikincisi her mekanizmayı otomatik olarak başarısızlığa uğratmak yerine çözümlenmeden kalır. Web sitesi sahibinden desteklenen SMTP yapılandırmasını doğrulamasını ve yetkili bir testte zararsız bir form olayı tetiklemesini isteyin. Panel anahtarı eksik imzayı sağlamaz. Hiçbir gerçek mesaj, eklenti veya DNS kaydı test edilmedi veya değiştirilmedi.
Kurtarma için herhangi bir özel politikayı silmeden önce mevcut SPF kaydını onaylanmış temel değerle karşılaştırın. Bu sağlayıcının belgelenen davranışında, silme işlemi varsayılan ayarı geri yükler; bu, önceki çoklu gönderici ilkesinin tamamının geri yüklenmesiyle aynı şey olmayabilir.
Uygulama sınırını koruyun
RFC 9989 Bölüm 7.4, p=reject, yayınlayan alan adları için yalnızca SPF değil, geçerli DKIM gerektirir ve dolaylı posta ve posta listesi birlikte çalışabilirliği konusunda uyarıda bulunur. Tek bir başarılı doğrudan mesaj testi, her meşru yolun daha güçlü politikaya hazır olduğunun kanıtı değildir. Gerçek açığı teşhis ederken mevcut onaylı korumayı koruyun; Herhangi bir politika değişikliğinin kendi kararına ihtiyacı vardır.