Zdecyduj, jaką tożsamość powinni widzieć klienci
WeFact dokumentuje dwie metody nadawcy: domyślną tożsamość mijnweFact i wysyłanie z adresu e-mail firmy. Domyślna metoda przenosi nazwę firmy, a odpowiedzi kierowane są na jej własny adres. Wysyłanie na adres niestandardowy wymaga uwierzytelnienia domeny. Nie myl działającego miejsca docelowego odpowiedzi z niestandardową uwierzytelnioną domeną nadawcy. Metody nadawcy WeFact.
Przed edycją DNS poproś właściciela procesu fakturowania o potwierdzenie zamierzonej metody i adresu. Zapisz, która administracja i domena są zaangażowane, kto może edytować jej ustawienia i kto kontroluje autorytatywny DNS . Przypomnienia o zapasach, oferty i inne przepływy pracy wychodzące oddzielnie. Ich wspólny branding nie jest dowodem identycznych ustawień nadawcy. Zachowaj oryginalną wiadomość bazową i poprzednią konfigurację, aby można było cofnąć zmianę bez zakłócania obsługi należności.
Uzyskaj spersonalizowany dokument konfiguracyjny
W administracji otwórz Instellingen i wtedy SPF & DKIM. Wybierz weryfikację domeny i pobierz spersonalizowane instrukcje. Poproś odpowiedzialnego administratora DNS opublikowanie określonych rekordów. Artykuł publiczny nie dostarcza uniwersalnego klucza DKIM ani pełnej uniwersalnej receptury DNS , więc ten przewodnik ich nie wymyśla. Instrukcje sprawdzania poprawności WeFact.
Traktuj pobrane instrukcje jako dane wejściowe zmiany wersji. Zapisz domenę, datę wygenerowania, dokładne nazwiska właścicieli publicznych, typy rekordów i wartości. Jeśli dokument zawiera nazwę innej domeny niż zatwierdzony adres faktury, zatrzymaj i popraw konfigurację przed opublikowaniem czegokolwiek. Udostępniaj administratorowi wyłącznie informacje dotyczące publicznej konfiguracji DNS , a nie hasło do skrzynki pocztowej lub niepowiązaną fakturę zawierającą dane osobowe.
Spraw, aby zmiana DNS była możliwa do sprawdzenia
Wyeksportuj bieżącą strefę i zidentyfikuj istniejącą politykę SPF . Jeśli instrukcje wymagają uwzględnienia SPF , połącz odpowiedni mechanizm z jedną polityką w ocenianej domenie koperty, zamiast tworzyć kolejny rekord v=spf1 . Zachowaj innych autoryzowanych nadawców. Przed zatwierdzeniem sprawdź składnię i koszt wyszukiwania. DKIM wymaga rzeczywistego selektor i klucz publiczny dostarczony dla tej domeny, a nie klucz skopiowany od innej administracji. SPF, DKIM.
Sprawdź, jak edytor DNS obsługuje względne nazwy właścicieli i cytowanie TXT . Po zapisaniu prześlij zapytanie do autorytatywnej usługi, a następnie postępuj zgodnie z bieżącym przepływem pracy weryfikacji WeFact. W ramach tej zmiany nie zmieniaj routingu przychodzących MX . Zachowaj istniejący DMARC zasady nienaruszone, chyba że wymagana jest osobna zmiana zasad dla wszystkich nadawców w domenie.
Przetestuj przepływ pracy związany z fakturowaniem niebędącym klientem
Utwórz nieszkodliwy dokument testowy w ramach zatwierdzonego procesu testowego i wyślij go tylko do kontrolowanych odbiorców. Unikaj tworzenia prawdziwej faktury kolekcjonerskiej lub wysyłania przypomnienia o płatności do klienta tylko po to, aby sprawdzić nagłówki wiadomości. Przechwytuj zarówno obieg dokumentów, jak i otrzymany oryginał, ponieważ nadawca używany do podglądu może różnić się od operacyjnej ścieżki wysyłania.
- Dowód: administracja; Co należy zapisać: Zatwierdzona metoda i adres nadawcy; Pytanie dotyczące akceptacji: czy wybrano zamierzoną tożsamość niestandardową?
- Dowód: otrzymana wiadomość; Co zapisywać: Z koperty, wszystkie wartości DKIM d= i s=; Pytanie akceptacyjne: Która tożsamość została faktycznie użyta?
- Dowody: wyniki odbiorcy; Co rejestrować: wyniki SPF , DKIM i DMARC ; Pytanie dotyczące akceptacji: czy metoda przekazująca została dopasowana?
- Dowód: test odpowiedzi; Co należy zapisać: miejsce docelowe osiągnięte dzięki nieszkodliwej odpowiedzi; Pytanie akceptacji: Czy zespół finansowy otrzymuje odpowiedzi?
Macierz jest syntetycznym projektem testu, a nie rekord prawdziwego komunikatu WeFact. W przypadku From invoices@example.com zweryfikowany DKIM d=example.com jest dokładnym wyrównanie przykład. Odpowiedź skierowana na adres invoices@example.com sama w sobie nie dowodzi tej zgodności. DMARC.
Przywróć bezpiecznie przepływ pracy w firmie
Jeśli wiadomość nadal korzysta z domyślnej tożsamości, sprawdź wybraną metodę nadawcy i zakończenie bieżącego procesu sprawdzania poprawności. Jeśli pojawi się niestandardowe pole From, ale nie ma DKIM , przed zmianą kluczy porównaj skonfigurowaną domenę i selektor z komunikatem. Jeśli podpis się nie powiedzie, sprawdź lokalizację klucza publicznego i wszelkie modyfikacje przekaźnika. Zachowaj zredagowaną próbkę do celów wsparcia, zamiast wielokrotnie wysyłać aktualne faktury.
Jeśli ma to wpływ na dostawę o znaczeniu krytycznym dla klienta, wstrzymaj odpowiedni przepływ pracy wysyłania lub przywróć poprzednio zatwierdzoną metodę za zgodą właściciela finansowego. Sprawdź ponownie odpowiedzi i uwierzytelnianie. Zachowaj spersonalizowany dokument instrukcji, migawki DNS , oryginały testowe i potwierdzenie akceptacji razem. Przejrzyj je, gdy zmieni się adres nadawcy, administracja lub host DNS . Ten przewodnik ma charakter dokumentalny i nie obejmuje testu sprawdzania poprawności WeFact na żywo ani testu dostarczania.
Potwierdź granicę dostawcy
Strona publiczna określa dwie metody nadawcy i obieg dokumentów spersonalizowanych, ale nie zawiera uniwersalnego selektora, bieżącego stanu konta ani reguły automatycznego przełączania. Zachowaj te fakty dotyczące konta wyraźnie nierozwiązane, dopóki nie dostarczy ich administrator. Weryfikacja pobranej domeny to decyzja odrębna od zatwierdzenia przesłania faktury.
Przeanalizuj fikcyjny przypadek diagnostyczny
Tylko fikcyjny przypadek pisemny: WF-01 zakłada, że właściciel finansowy wybrał metodę domyślną i przychodzi nieszkodliwa faktura testowa z domeną dostawcy, z której odpowiedź to: invoices@atelier.example . Tożsamości/wyniki SPF i DKIM są nieznane. Pomyślna odpowiedź dociera do finansów, ale nie spełnia żądanego niestandardowego źródła. Właściciel finansów musi zatwierdzić metodę niestandardową, uzyskać dokument konfiguracyjny specyficzny dla domeny i zweryfikować nową kontrolowaną trasę faktury bez tworzenia ściągalnego długu. W tym przypadku nie testowano żadnego konta, DNS , CRM, faktury, kampanii ani dostawy.
Oddziel przekazywaną wiadomość od gotowości do egzekwowania
RFC 9989 Sekcja 7.4 wymaga ważnego DKIM do publikowania w domenie p=reject i ostrzega o interoperacyjności poczty pośredniej. Pojedynczy dopasowany wynik SPF sam w sobie nie uzasadnia wdrożenia zasady odrzucania. Przejrzyj wszystkie legalne trasy i zasady własności niezależnie od konfiguracji tego dostawcy.