Dwa SPF zasady o tej samej nazwie DNS nie łączą się w większą listę autoryzowanych nadawców. Gdy Rekord SPF wybór zwraca więcej niż jeden odpowiedni rekord, ocena kończy się na permerror pod RFC 7208 §4.5. Naprawa to jedna spójna polityka, a nie trzeci wpis TXT .
Najtrudniejszą częścią jest podjęcie decyzji, które uprawnienia nadal należą. Skopiowanie każdego mechanizmu do pojedynczej linii może usunąć błąd składni, zachowując jednocześnie przestarzałych dostawców, nadmierne sieci i problem z limitem wyszukiwania.
Potwierdź, co faktycznie zostało zduplikowane
Zapytanie Rekordy TXT dokładnie w domenie używanej do sprawdzania SPF . Inne rekordy TXT , takie jak tokeny weryfikacji domeny, nie są automatycznie rekordami SPF i nie należy ich usuwać w ramach tej naprawy. Rozróżnij wiele rekordów zasobów od wielu ciągów znaków w cudzysłowie w jednym rekordzie TXT . Pod RFC 7208 §3.3, ciągi znaków w jednym rekordzie są łączone; oddzielne rekordy SPF nie są.
Zapisz pełną odpowiedź DNS , TTL i wiarygodne informacje o serwerze. Przed zmianą czegokolwiek potwierdź odpowiednią strefę i nazwę właściciela. Dostawca może automatycznie dodać nazwę strefy do pola hosta, przez co pozornie poprawny wpis w edytorze zostanie wyświetlony pod niewłaściwą nazwą.
Zrekonstruuj zamierzony zestaw nadawców
Utwórz jeden wiersz na każdy mechanizm z czterema polami: usługa biznesowa, właściciel odpowiedzialny, konfiguracja dostawcy pomocniczego i dowód bieżącego wysyłania. W przypadku jawnych zakresów adresów IP określ, kto obsługuje adresy i dlaczego ten zakres jest potrzebny. W przypadku dołączeń sprawdź aktualne instrukcje dostawcy i zależności zasad rekurencyjnych. Traktuj nieznany mechanizm jako kwestię do rozwiązania, a nie pozwolenie na zachowanie go na zawsze.
Oddziel nadawców korzystających z tej domeny kopertowej od usług korzystających z ich własnej domeny kopertowej. Widoczny adres nadawcy nie wystarczy, aby udowodnić, że jego ruch wymaga uwzględnienia w tym miejscu SPF . Podobnie nieobecność na krótkim okresie obserwacji nie oznacza przejścia na emeryturę: faktury lub kampanie sezonowe mogą być wystawiane rzadko.
Zbuduj jedną uporządkowaną politykę
Zachowaj wybrane uprawnienia i jedną zamierzoną ostateczną politykę. Nie łącz całych rekordów, pozostawiając sekundę v=spf1 token lub Wszystko mechanizm w środku. Pod RFC 7208 §5.1, wczesny Wszystko pasuje do każdego pozostałego źródła, więc późniejsze mechanizmy są nieosiągalne.
Przykładowy stan początkowy: jeden rekord to v=spf1 ip4:192.0.2.10 -all; inny jest v=spf1 ip4:198.51.100.20 ~all. Jeśli oba adresy służące wyłącznie do celów dokumentacyjnych reprezentują potwierdzonych, bieżących nadawców, możliwa jest fuzja zasad v=spf1 ip4:192.0.2.10 ip4:198.51.100.20 ~all. Wybór ostatecznego kwalifikatora wymaga własnego przeglądu trasy. Jeśli drugi nadawca zostałby wycofany, połączenie go pozwoliłoby zachować niepotrzebne uprawnienia.
Oceń pełną politykę, łącznie z zagnieżdżonymi dołączeniami i przekierowaniami. Pod RFC 7208 §4.6.4RFC 7208 nakłada limit dziesięciu terminów powodujących wyszukiwanie podczas oceny; liczenie tylko widocznych instrukcji włączania jest niewystarczające. Wyraźny ip4 I ip6 mechanizmy same w sobie nie zużywają tego budżetu, ale zastąpienie zarządzanych dołączeń skopiowanymi listami adresów IP stwarza obowiązek konserwacji.
Wdrażaj bez długotrwałego stanu niejednoznacznego
Preferuj aktualizację atomowego zestawu rekordów DNS , jeśli dostawca ją obsługuje: zastąp konkurencyjne zasady zatwierdzonym pojedynczym rekordem w ramach jednej zmiany. Jeśli interfejs wymaga oddzielnych edycji, zaplanuj sekwencję i uwzględnij przejściowe ryzyko braku lub zduplikowania zasad. Nie twórz „tymczasowego” dodatkowego rekordu SPF i nie pozostawiaj go do propagacji.
Sprawdź wiarygodne odpowiedzi, a następnie odpowiednie odpowiedzi rekurencyjne. Stare odpowiedzi zapisane w pamięci podręcznej zachowują wcześniejsze interwały świeżości; RFC 8767 §4 pozwala również na kwalifikujące się użycie nieaktualnych odpowiedzi po wygaśnięciu. TTL nie jest gwarantowanym globalnym terminem odstąpienia od umowy. Wysyłaj reprezentatywne wiadomości z każdej wybranej usługi i potwierdzaj ocenioną tożsamość oraz wynik u zaufanego odbiorcy. Przetestuj także niezrównane źródło pod swoją kontrolą, aby przypadkowe uniwersalne przejście nie zostało pomylone z sukcesem.
Zachowaj dowody sprzątania
Zapis zmian powinien wyjaśniać każdy zachowany i usunięty mechanizm, ocenę wyszukiwania, stan DNS przed i po oraz wyniki testów. Alert dotyczący zduplikowanego rekordu jest zamykany tylko wtedy, gdy wybrany jest jeden rekord SPF , a polityka określa zestaw sprawdzonych nadawców. Dzięki temu jednorazowa naprawa DNS staje się możliwym do utrzymania spisem autoryzacji.
Zapisz decyzję i jej ograniczenia
W przykładzie z dwoma adresami arkusz uprawnień powinien zawierać każdą decyzję właściciela i oczekiwane dopasowanie oddzielnie od ostatecznego kwalifikatora. Połączony przykład ~all nadal zwraca softfail dla niedopasowanego adresu; nie jest to zalecenie osłabiania dotychczasowej polityki -all . Zmiana tego kwalifikatora wymaga wyraźnej decyzji. Dla tej ilustracji nie przeprowadzono aktualizacji DNS ani testu dostarczania.