DNSを編集する前にビジネス ID を選択してください
FreeAgent は、独自のデフォルトの From ID または検証済みのカスタム ドメインを使用して見積もりと請求書を送信できます。顧客にどの ID を表示する必要があるか、またどのメールボックスが顧客の返信を受信するかを決定します。いずれかを変更する前に、請求書と見積もりのワークフロー、その所有者、 DNS管理者を文書化してください。財務アプリケーションの送信が成功したことは、目的のビジネス ドメインが認証されたことを証明するものではありません。
レビュー済みの FreeAgent ガイドには、デフォルトの差出人アドレスはnoreply@remail.freeagentcentral.comであると記載されています。所有するドメインは、カスタム ドメインのセットアップを通じて認証できます。共有パブリック ドメイン上のコンシューマ メールボックスでは、そのドメインのDNSを制御できません。個々のアドレスの検証とそのドメインの承認は別の手順です。出典: FreeAgent、FreeAgent にビジネス アドレスからメールを送信する権限を与えます。
現在のカスタム ドメイン ワークフローを完了する
[設定] > [電子メールの送信] を開き、[カスタム電子メール ドメインの追加] を選択して、検証済みの送信者アドレスに関連付けられたドメインを選択します。存在しない場合は、まずそのドメイン上のアドレスを追加して確認します。手順 2 で表示されたホスト/キーと値の情報を権威DNSサービスにコピーし、戻ってドメインを追加します。 FreeAgent はそれらの記録をチェックします。出典: FreeAgent のカスタム ドメイン ガイド。
アカウントの表示されたレコードを、この設定に対して権限のあるものとして扱います。歴史的なものに置き換えないでください。 セレクタ、キーまたは SPF 古い記事で見つかった値。変更レコード内のレコード タイプ、完全な所有者名、値、および日付をキャプチャします。画面とドキュメントが異なる場合は、両方の世代のセットアップを組み合わせるのではなく、続行する前に不一致を解決してください。
編集する前に、各所有者の既存のレコードを検査します。 TXT公開キーと検証トークンは、両方が 1 つのウィザードに表示される場合でも、異なる目的を持つ可能性があります。他のアプリケーションのエントリを保存します。レジストラとDNSホストが異なる場合があります: 委任されたホストを確認してください ネームサーバー ドメインを購入した会社がその記録を公開していると仮定するのではなく、
コンテキスト内でSPF命令を確認してください
現在の FreeAgent ガイド名には、既存の厳密なSPFポリシーが-allで終わる場合、 include:spf.mtasv.net 。通常、そのワークフローには別の新しいSPFポリシーは必要ないとされています。他の場所で見つかった古い FreeAgent インクルードを置き換えないでください。出典: FreeAgent のSPFセクション。
この製品の指示は、有効なSPFポリシーを削除したり、その最終修飾子を弱めたり、すべてのメールが通過すると仮定したりする理由にはなりません。 DMARC。 SPF変更が必要な場合は、すべての送信者のインベントリを作成し、DNS ルックアップ制限を確認した後、承認を 1 つの既存のポリシーにマージします。他のサービスを維持します。この限定的な承認タスクは、ドメイン全体のポリシーの再設計とは別にしてください。
管理された請求書ルートを使用して変更を検証する
テストする前に、実際の顧客との取引や金銭的な約束は避けてください。明らかに架空のコンテンツを使用して、承認されたテスト ワークフローと管理された受信者を使用します。どの FreeAgent ワークフローがメッセージを送信したか、およびその表示されている差出人が承認されたビジネス アドレスと一致するかどうかを記録します。返信先を検査し、必要に応じてテストして、返信先を個別に確認します。
元の受信メッセージを信頼できる受信者に保持する Authentication-Results、From、エンベロープ ID、および DKIM 署名ドメイン/セレクター。 SPF 、From を自動的に認証するのではなく、エンベロープ ID を認証します。 DKIM 、その d= ドメインに関連付けられた署名を検証します。 DMARCは、該当する From に合わせたSPFまたはDKIM ID を渡す必要があります。 アライメント モード。製品の検証や受信箱の外観は、この証拠に代わることはできません。
合成例: From accounts@example.com 、プロバイダー所有のエンベロープ ドメインのSPFパス、および d=example.com のDKIMパスで見積もりが届きますd=example.com.完全一致 DKIM署名 調整されたDMARCパスを提供できます。無関係なSPFは成功しません。後のメッセージがプロバイダーのデフォルト From を使用する場合、そのデフォルト ID に対して正しく認証される可能性がありますが、ブランドの受け入れ条件には失敗したままになります。配信と意図したアイデンティティを別の結果として扱います。
復帰を診断し、安全な回復を維持する
FreeAgent は、必要なDNSレコードを削除または変更すると、カスタム ドメインが未検証になり、From アドレスがデフォルトに戻る可能性があると警告しています。通知も送信されます。新しいゾーンが読み込まれるかどうかだけでなく、 DNS移行の運用上の影響も監視します。 DNSプロバイダーを変更するときに必要なレコードを保存し、その後、顧客向けのワークフローをテストします。
検証が失敗した場合は、キャッシュの有効期限が切れるまで待つ前に、アカウント値を権威DNSと比較し、所有者名のサフィックスの重複と省略された文字をチェックします。構成は正しいがメールが見つからない場合は、正確な送信ステータスと受信者の証拠を保持し、配信を個別に調査します。時間の遅れだけで問題が解決するとは約束しないでください。
FreeAgent 固有の履歴レコードを削除する前に、それらのレコードが廃止されており、別のアクティブなルートで使用されていないことを確認してください。可逆コピーと承認済みの動作確認済みの送信者取り決めを保管してください。完了には、アカウントの検証、信頼できる記録、および関連する請求書と見積もりのルートに関する実際の受信メッセージの証拠が必要です。このドキュメンタリー ガイドでは、これらのライブ操作は一切実行されませんでした。独立した審査、SME による承認、出版は保留中です。
支払テストを作成せずに、納品された見積を分類する
文書化されたケース FA-01 では、承認された From がaccounts@example.comであると想定されていますが、架空の見積もりサンプルでは、必要なDNSレコードが削除された後の文書化されたプロバイダーのデフォルト From が示されています。受信者の認証結果および Reply-To は不明です。配信が成功しただけでは、意図した ID も、 example.comの調整された認証も確立できません。財務ワークフローの所有者は、現在のアカウントの検証とDNS管理者と調整し、承認された拘束力のないテストを使用して、実際の送信者フィールドと返信フィールドを検査する必要があります。ヘッダーを取得するためだけに実際の請求書や支払い義務を作成しないでください。このケースでは、顧客、トランザクション、記録、またはメッセージにはアクセスされませんでした。
施行境界を維持する
RFC 9989 セクション 7.4 では、ドメイン公開にはSPFのみではなく有効なDKIMが必要です p=reject、間接メールとメーリングリストの相互運用性について警告します。ダイレクト メッセージ テストが 1 回成功しただけでは、すべての正当なルートがより強力なポリシーに対応できるようになっているという証拠にはなりません。実際のギャップを診断しながら、既存の承認された保護を維持します。政策変更には独自の決定が必要です。