USAePay のカスタム ブランドの領収書には、お客様が管理するドメインが必要です。ゲートウェイの電子メール送信者の選択により、受信者に表示される内容が変わるため、在庫販売業者の領収書、請求書、およびパートナーメールは個別に送信されます。顧客の実際のトランザクションを認証テストとして使用したり、診断サービスに支払いの詳細を入力したりしないでください。
カスタムドメイン認証を構成する
プロバイダーのドキュメントには次のinclude:spf.usaepay.com SPF。別のポリシーを公開するのではなく、端末のすべてのメカニズムの前に、既存の該当するSPFポリシーに追加します。 SPFレコード。公式ガイドでは、プロバイダーのアドレスは変更される可能性があるため、コピーした IP リストを保持することを推奨していません。
のために DKIM、3つ作成します CNAME 送信ドメインの下にあるレコード: gps1。 _domainkey gps1._default.dkim.safewebservices.comを指します。 gps2 と gps3 は同じ番号パターンに従います。プロバイダーのターゲットではなく、独自の送信ドメイン部分のみを置き換えます。ガイドには、gps2 と gps3 の公開キーはローテーションのために意図的に空の予約であると記載されています。キーバリデーターが空のターゲットにフラグを立てた場合でも、委任を公開します。今日のメッセージを受け入れるかどうかは、 セレクタ 実際に使用されています。 USAePay 構成リファレンス
ポータルではSPFとDKIM検証が提供されます。これを構成チェックとして使用し、配信されたテスト受領書を検査します。ドキュメントには、認証されていないカスタム ブランドは、 safewebservices.comにフォールバックできると記載されています。配信されたレシートにまだブランドが含まれていると仮定するのではなく、観察された差出人アドレスを記録します。希望のドメインを制御できない場合は、パブリック Web メール アドレスを偽造するのではなく、承認された送信者 ID に同意してください。
プロバイダーは、一括キャンペーンだけでなく、すべてのカスタム送信ドメインに対してこれらの認証レコードを必要とするようになりました。古い検証例で使用されたパブリック サンプル IP は、現在の出力 IP や実際に発行されたエンベロープ ID の証拠ではなく、診断の説明として扱います。
DNSと実際の受信結果を検証する
販売者の領収書と請求書の送信者の設定を変更する前に、既存のDNS値をエクスポートし、承認された差分を記録し、ロールバック所有者に名前を付けます。 DNSエディターが相対ラベルまたは完全修飾名を予期しているかどうかを確認します。ドメインサフィックスを2倍にすると、 記録 意図した検証者がそれを見つけることはできません。保存後に、エディターの成功バナーに依存するのではなく、 CNAMEターゲットを含む実際の所有者名を照会します。
SPF 、関連するドメインで 1 つのポリシーを維持し、DNS クエリ期間の制限内にとどまる必要があります。 RFC 7208。インクルードを追加するだけでは確立されません アライメント。下 RFC 9989, DMARC 少なくとも 1 つの成功したSPFまたはDKIM結果が、該当するモードで表示されている From ドメインと一致する場合に合格します。標準によって課せられる条件として両方のメカニズムを調整する必要はありません。また、プロバイダー ドメイン パスを調整されたカスタマー ドメイン パスと取り違えないようにしてください。
実際の販売者のワークフローによって生成された無害なテスト レシートを、管理するメールボックスに送信します。受信側システムの信頼できる認証結果、表示される From、エンベロープ ID、 DKIM d= および s= 値、タイムスタンプ、プロバイダーのステータスを保存します。 DNSルックアップでは、使用可能なキーのみが表示されます。 RFC 6376 検証では、受信したメッセージの署名も評価します。機密性の低いコンテンツを使用し、顧客メッセージ全体が公開チェッカーに公開されることを避けてください。
制限付きの受け入れとロールバックの決定を使用する
架空の書面による診断ケースのみ: UP-01 は、無害なレシートがreceipts@shop.exampleを使用することを意図していたが、その表示される From がnoreply@safewebservices.comであると想定します。 SPFおよびすべてのDKIMアイデンティティ/結果は不明です。配送がカスタムブランドの要件を満たしていません。マーチャント所有者はゲートウェイの ID と検証ステータスを確認する必要があり、 DNS所有者は新たに承認されたテストの前に、文書化された 3 つの委任をすべて比較する必要があります。空の予約キーだけでは、アクティブ セレクターの障害は確立されません。この例では、アカウント、 DNS 、リレー、またはメッセージはテストされませんでした。
テストが失敗した場合は、別の変更を行う前に、欠落しているDNS 、間違ったセレクター、非アクティブなプロバイダー構成、予期しないルーティング、およびメッセージの変更を分離します。修正が承認されるたびに、同じワークフローを再テストします。単一の送信者の問題を隠すためにドメイン全体のDMARCポリシーを弱めないでください。ロールバックが必要な場合は、承認された以前のルーティングまたは送信者の構成を復元し、キューに入れられた署名付きメッセージがまだ必要な間、キーのレコードを保持します。テストの証拠と未解決の例外をドメイン インベントリに保管します。このガイドを作成する際に、テナント アクセス、 DNS変更、または実際の送信は行われませんでした。
責任ある受け入れ記録を保管する
アカウント、ドメイン、および実質的に異なるルートごとに 1 行を作成します。ビジネス所有者、 DNS所有者、変更参照、意図した From、観察された From、エンベロープ ドメインとSPF結果、各DKIM d= および s= とその結果、適用可能なアライメント モード、信頼できる受信者とタイムスタンプ、プロバイダーのアクティベーション状態、配置の観察、未解決の質問、および次のアクションを記録します。欠損値を合格または不合格として扱うのではなく、不明な値としてマークします。所有者は、記録された証拠によってサポートされる意図されたルートと ID のみを受け入れます。それ以外の場合は、そのルートを保持し、承認された復旧計画に従います。
通過メッセージを施行の準備から切り離す
RFC 9989 セクション 7.4 では、ドメイン公開に有効なDKIMが必要です p=reject 間接メールの相互運用性に関する注意事項。単一の調整されたSPF結果だけでは、拒否ポリシーのロールアウトが正当化されるわけではありません。このプロバイダーの設定とは別に、すべての正当なルートとポリシーの所有権を確認します。