GitHub Actions を使用してプッシュごとにドメインの電子メール セキュリティを監査する

チームの誰かが DNS レコードを更新します。 TXT エントリは、プロバイダーの移行中に削除されます。 SPF レコードが 10 件のルックアップ制限を静かに超えています。 電子メールがスパムに分類されるようになります。 誰も 顧客が請求書を受け取っていないと言うまで 2 週間通知します。

DNS ベースの電子メール セキュリティ レコード (SPF、DMARC、DKIM) は、 動作しなくなるまでは完璧に動作します。 壊れた場合、故障モードはサイレントです。エラーは発生しません。 警告がなければ、電子メールはスパムフォルダーに消えます。

このガイドでは、プッシュごとに 3 つのレコードすべてを検証する GitHub アクションを設定します。 もし レコードが欠落しているか設定が間違っている場合、ワークフローは失敗し、何が壊れたのかがわかります。

ワークフローの内容

プッシュするたびに main、アクション:

1. ボットイを呼び出します /v1/dns-security/spf-check SPF レコードを検証するためのエンドポイント
2. 電話 /v1/dns-security/dmarc-check DMARC ポリシーを検証するには
3. 電話 /v1/dns-security/dkim-check DKIM キーが公開されていることを確認するには
4. いずれかのチェックが失敗した場合はゼロ以外のコードで終了し、マージをブロックします。

GitHub アクションのワークフロー

作成する .github/workflows/dns-security.yml リポジトリ内:

交換する yourdomain.com あなたのドメインと google と 電子メールプロバイダーの DKIM セレクター。 ワークフローは、プッシュされるたびに実行されます。 main、 毎日のスケジュールで実行され、[アクション] タブから手動でトリガーできます。

各チェックで検証される内容

SPF (送信者ポリシー フレームワーク)

SPF は、ドメインに電子メールを送信する権限をどのメール サーバーに与えるかを宣言します。 API 生のレコード、解析されたメカニズムのリスト、およびレコードが有効かどうかを返します。

注目すべき主要なフィールド:

• has_spf: で始まる TXT レコードはありますか v=spf1? false の場合、どのサーバーでもドメインから電子メールを送信できると主張できます。
• valid: レコードは正しく解析されていますか? SPF レコードが壊れると、 10 件の DNS ルックアップ制限を超えているか、構文エラーが含まれています。
• all_policy：トレーリング機構。 -all （ハードフェイル）は 最強の設定。 ~all (ソフトフェール) 不正なメールを次のようにマークします 疑わしい。 +all SPF の目的を完全に無効にします。

正常な SPF レコードに対する API 応答の例:

DMARC (ドメインベースのメッセージ認証、レポート、および適合性)

DMARC は、受信サーバーに SPF または DKIM チェックが失敗した場合の対処方法を指示します。 それがなければ、 有効な SPF および DKIM レコードでもスプーフィングを防ぐことはできません。

注目すべき主要なフィールド:

• policy: 失敗したメッセージはどうなりますか。 reject 滴る 彼ら、 quarantine それらをスパムに送信し、 none 何も行動を起こさない (モニタリングのみ)。
• pct: ポリシーが適用されるメッセージの割合。 低いところから始める ロールアウト中に数値を変更し、その後 100 に移動します。
• reporting.rua: 集計レポートが送信される場所。 これがなければ、あなたは 認証の失敗を認識することはできません。

DMARC レコードの API 応答の例:

DKIM (ドメインキー識別メール)

DKIM は、送信メッセージに暗号署名を追加します。 受信サーバーは、 DNS で公開されている公開キーに対する署名。 キーが紛失しているか回転している場合 DNS を更新しないと、署名の検証が失敗します。

注目すべき主要なフィールド:

• has_dkim: DKIM キーは指定されたセレクターに対して公開されていますか? 各メール プロバイダーは別のセレクター名を使用します。
• public_key_length: NIST は最小 2048 ビットを推奨しています。 キーを短くする 1024 ビットよりも弱いと見なされます。
• key_type: ほとんどのキーは RSA を使用します。 Ed25519 キーは小さくて高速ですが、 メールプロバイダー全体でのサポートは限られています。

DKIM チェックの API 応答の例:

プロバイダー別の一般的な DKIM セレクター

電子メールプロバイダー	DKIMセレクター
Google ワークスペース	google
マイクロソフト 365	selector1、 selector2
アマゾンSES	UUID ベース (SES ダッシュボードを確認してください)
メイルチンパンジー / マンドリル	k1
送信グリッド	s1、 s2
消印	ドメインごとに生成 (DNS 設定を確認してください)

ワークフローの拡張

複数のドメイン

複数のドメインを管理している場合は、マトリックス戦略を使用してそれぞれをチェックします。 ボットイを追加する 無料枠のレート制限に達しないようにするための GitHub シークレットとしての API キー。

失敗時の Slack 通知

いずれかのチェックが失敗したときに起動する通知ステップを追加します。 これは、 公式 Slack GitHub アクション:

モノレポのセットアップ

モノリポジトリでは、すべてのリポジトリへのプッシュごとに DNS チェックを実行したくないでしょう。 パッケージ。 トリガーの範囲をインフラストラクチャ関連ファイルの変更に設定します。

スケジュールされたトリガーはパス フィルターに関係なく毎日実行されるため、DNS をキャッチします。 リポジトリの外部で行われた変更。

API キーを使用してレート制限を引き上げる

複数のドメインをチェックする場合、またはワークフローを頻繁に実行する場合は、botoi API キーを追加してください GitHub Actions シークレットとして:

1. リポジトリの [設定] > [設定] に移動します。 シークレットと変数 > アクション
2. という名前のシークレットを追加します BOTOI_API_KEY
3. 各curlコマンドにauthヘッダーを追加します。

チェックが失敗した場合の対処方法

• SPF レコードがありません: TXT レコードをドメインの DNS に追加します。 から始める v=spf1 include:_spf.google.com ~all ( include をあなたのものに置き換えてください 電子メールプロバイダーの SPF ドメイン）。
• 無効な SPF レコード: DNS ルックアップの制限 10 に達する可能性があります。 を使用してください 交換するSPF平坦化ツール include: IP アドレスを使用したメカニズム、 またはプロバイダーを統合します。
• DMARC レコードがありません: TXT レコードを追加します _dmarc.yourdomain.com。 から始める v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com 監視する 施行する前に。
• DMARC ポリシーは「なし」です。 ロールアウト中はこれで問題ありません。 確認したら 正規の電子メールは SPF と DKIM に合格し、次の場所に移動します。 p=quarantine その後 p=reject。
• DKIM レコードがありません: 正しいセレクターがあることを確認してください 電子メールプロバイダー (上の表を参照)。 キーは TXT レコードとして公開する必要があります。 [selector]._domainkey.yourdomain.com。
• DKIM キーが短すぎます: DKIM キーを 2048 ビットにローテーションします。 電子メールプロバイダーの管理パネルにアクセスして、DNS TXT レコードを更新します。