このツールはサーバーで実行されます。
仕組み
メールのプロトコルは送信者を検証しません。どのサーバーでも差出人にあなたのドメインを書けてしまいます。この穴を塞ぐのが 3 つの DNS レコードです。SPF はドメインの名義で送信できるサーバーを列挙します。DKIM は各メッセージを秘密鍵で署名し、その公開鍵を DNS に公開します。DMARC は両者を結び付け、少なくとも一方が合格して見た目の差出人ドメインと一致することを求め、失敗したメールの扱いを受信側に伝え、あなたの名義で送られたすべてのメールについてレポートを求めます。
2024 年 2 月以降、Gmail と Yahoo は自社ユーザーに 1 日 5000 通を超えて送信する送信者に SPF・DKIM・DMARC を必須としており、どれか 1 つでも欠けるとメールは拒否されるか迷惑メールになります。だからこそ 3 つをまとめて確認する価値があります。完璧な SPF も DMARC がなければ効果は薄く、DKIM の公開を誤ったまま DMARC を reject にすると自分のメールまで締め出してしまいます。
確認は、一般的なメールサーバーと同じく当サイトのサーバーから公開 DNS への問い合わせで行います。SPF は include と redirect をすべてたどって完全に評価し、DNS 参照回数を数えます。上限の 10 回を超えるとレコード全体が無効になるためです。MX レコードと、任意の MTA-STS・TLS-RPT・BIMI レコードも照会します。
例
github.comSPF · 10 / 10プロバイダーの include が 8 つ（Microsoft、Google、Zendesk、Salesforce、Mailchimp、SendGrid…）あり、それらがさらに include するものを合わせると、評価はちょうど DNS 参照 10 回の上限に達します。プロバイダーをもう 1 つ追加すると SPF 全体が恒久エラーになります。example.comMX 0 . · v=spf1 -all · v=DMARC1;p=reject;sp=reject;adkim=s;aspf=sメールを送受信しないドメインの正しい設定です。Null MX、誰も許可しない SPF、reject に設定した DMARC。なりすましの標的になりやすいパーキングドメインを守ります。v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@example.comquarantine · 25 %段階的な導入です。失敗したメッセージのうち迷惑メールになるのは 4 通に 1 通だけで、レポートは rua で指定した受信箱に届くため、まだ認証されていない正規の送信元を見つけられます。ユースケース
- ドメインのメールが迷惑メールになる理由や、Gmail・Outlook・Yahoo に拒否される理由を診断する。
- CRM やメルマガ配信サービスなど新しい送信プロバイダーを追加する前に、SPF が DNS 参照 10 回以内に収まるか確認する。
- プロバイダーの DKIM 鍵が設定後に正しく公開されたかを確認する。
- 正規のメールを止めずに、DMARC を none から quarantine、reject へ移行する計画を立てる。
- 顧客や買収した企業のドメインを、メールを送るべきでないパーキングドメインも含めて監査する。
- フィッシングを分析する際に、疑わしい送信者の設定を確認する。
よくある質問
ドメインは署名しているのに DKIM が見つからないと表示されるのはなぜ？
DKIM ではドメインの鍵を一覧できないからです。鍵はそれぞれ <selector>._domainkey.<domain> にあり、照会するにはセレクターを知っている必要があります。このツールは一般的なセレクターを試しますが、独自の名前や日付入りの名前を使うプロバイダーも多くあります。ドメインから送られたメールを開き、DKIM-Signature ヘッダーの s= の値をコピーしてください。そのセレクターなら正確に確認できます。
SPF が DNS 参照 10 回を超えるとどうなる？
RFC 7208 は受信側に恒久エラー（permerror）を返すよう定めており、DMARC ではこれが SPF の失敗として扱われます。参照回数を消費するのは include・a・mx・ptr・exists の各メカニズムと redirect 修飾子で、各 include の中にあるものも含みます。ip4 と ip6 は消費しません。回数を減らすには、使っていないプロバイダーを削除する、include を ip4 の範囲に置き換える、独自の SPF を持つサブドメインから送信する、といった方法があります。
~all と -all のどちら？
DMARC が有効なら違いは小さく、受信側は SPF の修飾子ではなく DMARC ポリシーを適用します。~all が一般的なのは、-all だと DKIM を評価する前に即座に拒否する受信側があり、DKIM なら救えたはずの転送メールを失うことがあるためです。DMARC がない場合は、許可されていないメールの拒否を求める手段は -all しかありません。
メールを失わずに DMARC を none から reject に移行するには？
まず p=none と rua のアドレスを設定し、数週間は集計レポートを読みます。レポートにはあなたのドメインで送信しているすべてのサーバーと、それが SPF や DKIM に合格しているかが示されます。足りない正規の送信元を認証し、低い pct で quarantine に移行し、pct を少しずつ上げて最後に reject にします。いきなり reject にすると、請求システムや CRM、誰も覚えていなかった社内システムを締め出しがちです。
1024 ビットの DKIM 鍵で十分？
動作はします。RFC 8301 は受信側に 1024〜4096 ビットの鍵を受け入れるよう求めていますが、同じ規格は署名側に 2048 ビット以上を推奨しています。1024 ビット未満の鍵は有効とみなされません。2048 ビットへの切り替えは簡単で、新しい鍵を別のセレクターで公開し、署名を切り替えてから、古い鍵を p を空にして失効させます。
MTA-STS・TLS-RPT・BIMI は何のため？
MTA-STS（RFC 8461）は、あなたの MX に配送する際に TLS を必須にするよう送信サーバーに求め、接続を平文に格下げする攻撃を防ぎます。TLS-RPT（RFC 8460）はそうした配送が失敗したときにレポートを送ります。BIMI は対応クライアントで差出人の横にブランドのロゴを表示し、DMARC が quarantine か reject のときだけ機能します。どれも必須ではありませんが、3 つとも効果があります。