コラム / メール運用 /
迷惑メールフォルダに落ちるのを今日終わらせる ─ DMARC/SPF/DKIM/BIMI の現実的な設定手順
問い合わせ自動返信がGmailに届かない、Outlookに弾かれる、なぜ営業メールがスパム判定されるのか
📖 約11分 / 公開日: 2026/05/17
問い合わせフォームから自動返信が送られているはずなのに、受信者が「届いていない」と言ってくる。スパムフォルダを確認すると、しっかり入っている。営業から「Gmailの相手にメールが届かない」と苦情が来る。Outlook相手は最初の1通だけ届いて2通目以降が消える。
この現象は2024年2月以降、明らかに増えた。理由ははっきりしている。Googleが新しい送信者ガイドラインを施行し、1日5,000通以上を送る送信者だけでなく、ある程度のボリュームを送る全ての送信者に対してDMARC設定を要求するようになった。Yahoo!（Yahoo! Inc. の方、ヤフー株式会社ではない）も同時に同じ方針を打ち出した。今ではマイクロソフトもこれに追随する動きを見せている。
問題の本質は、ほとんどの企業が SPF レコードしか設定していないことだ。20年前にスパム対策として登場した SPF は、もはや単独では「送ってきたメールが本物かどうか」を判別する材料として十分でない。攻撃者は SPF を回避するテクニックを持っているし、メールサーバの側もそれを知っている。
ではどう設定すべきか。順番に整理する。
まず SPF。送信元IPの宣言だ。`v=spf1 include:_spf.google.com include:sendgrid.net ~all` のように、自社が送信に使う全てのメールサービスを include に入れる。10個までという DNS lookup 上限があるので、不要なものは外す。`~all`（soft fail）でなく `-all`（hard fail）にしたい気持ちはわかるが、いきなり hard fail にすると正規の転送メールも弾かれることがあるので、最初は ~all から始めるのが現実的だ。
次に DKIM。送信したメールに電子署名を付ける仕組み。Google Workspace なら管理コンソールから DKIM 鍵を生成し、TXT レコードに `google._domainkey.ai-rescue.jp` のように追加する。SendGrid なら CNAME を3つ。Postmark なら2つ。各サービスごとに作法が違うので、ドキュメントを丁寧に追う必要がある。鍵の長さは 2048bit を推奨する。1024bit でも動くが、Gmail は近い将来 1024bit を deprecate する可能性がある。
そしてここからが本題、DMARC だ。SPF と DKIM の検証結果に基づいて「このドメインから送ったメールが認証に失敗したらどうするか」をポリシーとして宣言する。最初は `v=DMARC1; p=none; rua=mailto:dmarc-reports@ai-rescue.jp` で始める。これは「認証失敗してもブロックしない、ただし結果を報告メールで送ってくれ」というモード。1〜2週間運用してレポートを観察し、自社が把握していない送信元（マーケティングオートメーション、CRM、外注先など）から自社ドメインで送信されていないかを確認する。
この「観察期間」を飛ばして p=reject に行く事故が本当に多い。多くの企業が、自分の知らないツールから自社ドメインで送信していることに気づかず、いきなり p=reject にしてしまい、社内のExcel配信ツールや古いCMSが沈黙する事態を招く。
観察期間で問題ないことが確認できたら、`p=quarantine; pct=10` に進める。これは「認証失敗したものの10%をスパム判定する」という段階的な締め付け。1週間ごとに pct を上げて、最終的に `p=reject` に到達する。Google や PayPal のような大手は、この移行に半年〜1年かけている。中小企業でも最低3ヶ月は見るべきだ。
BIMI（Brand Indicators for Message Identification）は、ここまでやった企業へのご褒美のような仕組み。受信トレイに送信者ロゴを表示する。Gmail、Apple Mail、Yahoo! Mail で対応している。前提条件として DMARC が `p=quarantine` 以上、かつ VMC（Verified Mark Certificate）の取得が要る。VMC は DigiCert か Entrust が発行している証明書で、年間 1,500〜2,000ドル。商標登録済みのロゴが必要だ。
コストに見合うかは判断が分かれる。BtoC で受信者の認知度が重要な業態（ECサイト、金融、観光）なら投資する価値がある。BtoB でメール数が多くないなら、DMARC まででいいだろう。
配信ツール側の話もしておく。SendGrid、Mailgun、Postmark、Amazon SES のような Transactional Email サービスを使う場合、各サービスが提供する「Dedicated IP」を使うべきか「Shared IP」で済ますかは、月間配信数によって決まる。3万通/月未満なら Shared IP で十分。10万通超なら Dedicated IP を検討する。Shared IP は他の利用者の素行に評判が引きずられるリスクがあるからだ。
ウォームアップも忘れてはいけない。新規に Dedicated IP を取得したら、最初の2週間は送信量を段階的に増やす。いきなり1日1万通送るとレピュテーションを傷つける。SendGrid なら自動ウォームアップ機能が用意されている。
ここまでやれば、Gmail に届かない問題は劇的に減る。当方で対応した直近の事例では、BtoB SaaS企業で問い合わせ自動返信の Gmail 不達率 18% → 0.3% に改善した。設定だけで完結する話なので、コストは作業工数のみだ。
最後に、設定後の検証ツールを紹介しておく。MXToolbox、Mail-Tester、DMARC Analyzer。これらで自社ドメインの状態を月次で確認する運用にしておけば、設定の劣化（誰かが勝手にDNS触ったとか）を早期に検知できる。
この現象は2024年2月以降、明らかに増えた。理由ははっきりしている。Googleが新しい送信者ガイドラインを施行し、1日5,000通以上を送る送信者だけでなく、ある程度のボリュームを送る全ての送信者に対してDMARC設定を要求するようになった。Yahoo!（Yahoo! Inc. の方、ヤフー株式会社ではない）も同時に同じ方針を打ち出した。今ではマイクロソフトもこれに追随する動きを見せている。
問題の本質は、ほとんどの企業が SPF レコードしか設定していないことだ。20年前にスパム対策として登場した SPF は、もはや単独では「送ってきたメールが本物かどうか」を判別する材料として十分でない。攻撃者は SPF を回避するテクニックを持っているし、メールサーバの側もそれを知っている。
ではどう設定すべきか。順番に整理する。
まず SPF。送信元IPの宣言だ。`v=spf1 include:_spf.google.com include:sendgrid.net ~all` のように、自社が送信に使う全てのメールサービスを include に入れる。10個までという DNS lookup 上限があるので、不要なものは外す。`~all`（soft fail）でなく `-all`（hard fail）にしたい気持ちはわかるが、いきなり hard fail にすると正規の転送メールも弾かれることがあるので、最初は ~all から始めるのが現実的だ。
次に DKIM。送信したメールに電子署名を付ける仕組み。Google Workspace なら管理コンソールから DKIM 鍵を生成し、TXT レコードに `google._domainkey.ai-rescue.jp` のように追加する。SendGrid なら CNAME を3つ。Postmark なら2つ。各サービスごとに作法が違うので、ドキュメントを丁寧に追う必要がある。鍵の長さは 2048bit を推奨する。1024bit でも動くが、Gmail は近い将来 1024bit を deprecate する可能性がある。
そしてここからが本題、DMARC だ。SPF と DKIM の検証結果に基づいて「このドメインから送ったメールが認証に失敗したらどうするか」をポリシーとして宣言する。最初は `v=DMARC1; p=none; rua=mailto:dmarc-reports@ai-rescue.jp` で始める。これは「認証失敗してもブロックしない、ただし結果を報告メールで送ってくれ」というモード。1〜2週間運用してレポートを観察し、自社が把握していない送信元（マーケティングオートメーション、CRM、外注先など）から自社ドメインで送信されていないかを確認する。
この「観察期間」を飛ばして p=reject に行く事故が本当に多い。多くの企業が、自分の知らないツールから自社ドメインで送信していることに気づかず、いきなり p=reject にしてしまい、社内のExcel配信ツールや古いCMSが沈黙する事態を招く。
観察期間で問題ないことが確認できたら、`p=quarantine; pct=10` に進める。これは「認証失敗したものの10%をスパム判定する」という段階的な締め付け。1週間ごとに pct を上げて、最終的に `p=reject` に到達する。Google や PayPal のような大手は、この移行に半年〜1年かけている。中小企業でも最低3ヶ月は見るべきだ。
BIMI（Brand Indicators for Message Identification）は、ここまでやった企業へのご褒美のような仕組み。受信トレイに送信者ロゴを表示する。Gmail、Apple Mail、Yahoo! Mail で対応している。前提条件として DMARC が `p=quarantine` 以上、かつ VMC（Verified Mark Certificate）の取得が要る。VMC は DigiCert か Entrust が発行している証明書で、年間 1,500〜2,000ドル。商標登録済みのロゴが必要だ。
コストに見合うかは判断が分かれる。BtoC で受信者の認知度が重要な業態（ECサイト、金融、観光）なら投資する価値がある。BtoB でメール数が多くないなら、DMARC まででいいだろう。
配信ツール側の話もしておく。SendGrid、Mailgun、Postmark、Amazon SES のような Transactional Email サービスを使う場合、各サービスが提供する「Dedicated IP」を使うべきか「Shared IP」で済ますかは、月間配信数によって決まる。3万通/月未満なら Shared IP で十分。10万通超なら Dedicated IP を検討する。Shared IP は他の利用者の素行に評判が引きずられるリスクがあるからだ。
ウォームアップも忘れてはいけない。新規に Dedicated IP を取得したら、最初の2週間は送信量を段階的に増やす。いきなり1日1万通送るとレピュテーションを傷つける。SendGrid なら自動ウォームアップ機能が用意されている。
ここまでやれば、Gmail に届かない問題は劇的に減る。当方で対応した直近の事例では、BtoB SaaS企業で問い合わせ自動返信の Gmail 不達率 18% → 0.3% に改善した。設定だけで完結する話なので、コストは作業工数のみだ。
最後に、設定後の検証ツールを紹介しておく。MXToolbox、Mail-Tester、DMARC Analyzer。これらで自社ドメインの状態を月次で確認する運用にしておけば、設定の劣化（誰かが勝手にDNS触ったとか）を早期に検知できる。