SPF、DKIM、DMARC がすべて必要な理由

企業にとって重要な理由

メールには、送信者が誰かを確かめる仕組みが標準では備わっていません。これらのレコードがなければ、誰でも From 行にあなたのドメインを入れられるため、経理担当から届いたように見える偽の請求書が届くことがあります。

逆のことも起こります。大手プロバイダーは認証されていないメールを信用しないため、本物の返信が迷惑メールに入ってしまいます。Google と Yahoo は、2024 年から大量送信者に認証を義務付けています。

それぞれが加えるもの

• SPF:ドメインとして送信してよいサーバーを一覧にします。
• DKIM:各メッセージに署名し、どのドメインが署名したか、途中で内容が変わっていないことを証明します。
• DMARC:From アドレスのドメインで SPF または DKIM が合格したかを確認し、どちらも合格しなかった場合の扱いを受信側に伝え、レポートを送ります。

単独で十分なものはありません。SPF と DKIM は、読み手に見えるドメインとは別のドメインで合格することがあり、どちらも受信側に何かをブロックさせるものではありません。DMARC はそのどちらかが機能していることを前提とし、SPF は転送されたメールでは失敗するため、DKIM がその備えになります。

よくある間違い

• SPF レコードが 2 つある:新しいサービスのために 2 つ目のレコードを追加すると、すべてのメールで SPF が失敗します。
• 誰も追加していない送信元:マーケティングプラットフォームや請求システムがドメインとして送信しているのに、SPF エントリも DKIM 鍵も設定されていません。
• DMARC がずっと none のまま:ポリシーが先に進まず、偽造メールが配信され続けます。
• いきなり reject にする:レポートを読む前に強制適用すると、偽造メールと一緒に自社のメールまでブロックされます。

設定の順序

1. 送信元をすべて洗い出す:メールプロバイダーと、ドメインとしてメールを送る各サービス。
2. SPF レコードを 1 つ公開し、すべてを網羅します。
3. DKIM を有効にする。すべての送信サービスで行います。
4. DMARC を none で公開し、レポート用のアドレスを付けて、レポートを読みます。
5. quarantine、次に reject へ移行する。自社のサービスだけが表示されるようになってから行います。

3 つとも DNS にあります。残りの設定はビジネスメールのガイドで説明しています。

KawaConnect におけるメール認証の扱い方

Microsoft 365 のセットアップ、移行、管理では、メールを配送する MX レコードとあわせて、SPF、DKIM、DMARC のレコードも作業に含まれます。当社がホスティングする Web サイトでは、メールを送信する問い合わせフォームも同じレコードに加えます。

詳しく見る

• Wikipedia のメール認証メールの送信元を確認する各方式の概要。
• Cloudflare の DMARC、DKIM、SPF3 つのレコードの解説。
• dmarc.org の DMARC 概要DMARC が SPF と DKIM の上にどう成り立っているかを、標準の公式サイトから。
• Google のメール送信者のガイドラインGmail が送信者に求める認証。
• Microsoft 365 のメール認証Microsoft 365 向けの 3 つすべてについての Microsoft のガイド。