GmailでSPFやDKIMやDMARCエラーが出る原因と確実に届く設定方法を徹底解説

「さっきまで普通に届いていたメールが、急にGmailで弾かれるようになった」「送信したメールがエラーで戻ってきて、DMARCポリシーがどうこうって書いてあるけど意味がわからない」そんな経験はありませんか?実は今、あなたと同じ悩みを抱えている人が世界中で急増しています。

2024年2月にGoogleが導入した「メール送信者のガイドライン」が、2025年11月から本格的な厳格化フェーズに突入しました。これにより、SPFやDKIMやDMARCの設定が不十分なメールは、一時的なエラーではなく恒久的な拒否を受けるケースが急増しているのです。Microsoft社も2025年5月から同様の規制を開始し、もはやメール認証の設定は「やったほうがいい」ではなく「やらなければメールが届かない」時代になりました。

この記事では、Gmail宛のメールがSPFやDKIMやDMARCで弾かれる原因を徹底的に解明し、初心者でも実践できる解決策から上級者向けの詳細な技術情報まで、すべてを網羅してお伝えします。

そもそもSPFやDKIMやDMARCとは何なのか?メール認証の基礎知識

メールが弾かれる原因を理解するには、まずSPFやDKIMやDMARCという3つの認証技術が何をしているのかを知る必要があります。難しそうに聞こえますが、郵便の仕組みに例えると実はとてもシンプルです。

電子メールには2種類の差出人住所がある

意外と知られていないことですが、電子メールには「封筒の差出人」と「便箋の差出人」という2種類の送信元情報があります。封筒の差出人はエンベロープFromと呼ばれ、メールサーバー間でやり取りされる技術的な情報です。一方、便箋の差出人はヘッダFromと呼ばれ、受信者がメールソフトで見る「送信元」として表示されます。

問題は、電子メールの仕組み上、この2つの差出人を自由に書き換えられてしまうことです。悪意のある人が「封筒には自分の住所を書きながら、便箋には有名企業の名前を書く」ようなことが技術的に可能なのです。これがフィッシング詐欺やなりすましメールの温床となっていました。

SPFはメールサーバーの住所確認を行う仕組み

SPF(Sender Policy Framework)は、メールを送信しているサーバーのIPアドレスが、本当にそのドメインから送信を許可されているかどうかを確認する技術です。ドメインの管理者は、DNSにSPFレコードを設定することで「このIPアドレスからのメール送信は正当です」と宣言できます。

受信側のメールサーバーは、メールを受け取るとエンベロープFromに記載されたドメインのSPFレコードを確認し、送信元IPアドレスがリストに含まれているかをチェックします。含まれていなければSPF認証は失敗となります。

DKIMは電子署名でメールの正当性を証明する

DKIM(DomainKeys Identified Mail)は、公開鍵暗号を使ってメールが改ざんされていないことを証明する技術です。送信側はメールに電子署名を付与し、その署名を検証するための公開鍵をDNSに公開します。

受信側は公開鍵を使って署名を検証し、メールの内容が送信後に改ざんされていないこと、そして署名に使われたドメインが正当であることを確認します。SPFがサーバーの身元確認なら、DKIMはメール本体の真正性確認といえます。

DMARCはSPFとDKIMを統合してポリシーを宣言する

DMARC(Domain-based Message Authentication, Reporting and Conformance)は、SPFとDKIMの結果を統合し、認証に失敗したメールをどう処理するかをドメイン管理者が指示できる仕組みです。

DMARCの重要な特徴はアライメントという概念です。SPFやDKIMが単独で成功しても、それだけでは不十分です。受信者が目にする「ヘッダFrom」のドメインと、SPFまたはDKIMで認証されたドメインが一致していなければ、DMARCの認証は失敗します。

DMARCポリシーには3つの設定があります。noneは認証失敗時も特別な処理をせずレポートのみを受け取る設定、quarantineは認証失敗メールを迷惑メールフォルダに振り分ける設定、rejectは認証失敗メールを完全に拒否する設定です。

なぜ今Gmailでメールが弾かれるようになったのか?背景と現状

Gmailは毎日約150億件のスパムメールをブロックしていますが、なりすましメールの手口は年々巧妙化しています。そこでGoogleは2023年10月に新しい送信者ガイドラインを発表し、2024年2月から段階的に適用を開始しました。

2024年から2026年にかけての規制強化タイムライン

Googleの規制強化は段階的に進められてきました。2024年2月には一般的なガイドラインが全送信者に適用され、4月からは非準拠メールの一部拒否が始まりました。6月にはワンクリック配信停止機能の義務化が完全施行され、2025年11月からは非準拠メールへの恒久的拒否が本格化しています。

さらに注目すべきは、この動きがGoogle単独ではないことです。Yahoo!やAppleは2024年2月からGoogleと同様の要件を導入し、Microsoft社も2025年5月からOutlook.comやHotmail.comへの送信に同様の規制を開始しました。Gmail、Yahoo!、Microsoft、Appleの4大プロバイダーで世界の個人・ビジネスメールユーザーの約90%をカバーしているため、もはやメール認証の設定は避けて通れない状況です。

1日5000通という基準の正しい理解

Googleのガイドラインでは、1日あたり5000通以上のメールをGmailアカウント宛に送信する「大量送信者」に対して、より厳しい要件が課されています。ただし、この5000通という数字には注意が必要です。

まず、サブドメインも含めた合計でカウントされます。example.comとpromotions.example.comからそれぞれ2500通送信している場合、合計5000通として扱われます。また、一度でも5000通に達したドメインは、その後ずっと大量送信者として扱われ続けます。さらに、自社ドメインを騙ったなりすましメールも、このカウントに含まれる可能性があります。

5000通未満の送信者でも、SPFまたはDKIMの設定、有効なDNS逆引き設定、TLS接続、0.3%未満のスパム報告率維持などは必須要件となっています。

GmailでSPFやDKIMやDMARCエラーが発生する7つの主要原因

メールが弾かれる原因はさまざまですが、実務上よく遭遇するのは以下の7つのパターンです。それぞれの原因と対処法を詳しく見ていきましょう。

原因1:SPFレコードが未設定または不完全

最も基本的な原因が、SPFレコードの設定漏れです。自社ドメインのDNSにSPFレコードが設定されていない場合、受信側はメールの送信元を検証できず、なりすましの可能性があると判断します。

また、SPFレコードは設定されていても、実際にメールを送信しているすべてのサーバーやサービスが含まれていないケースも多いです。Google Workspaceを使っているならinclude:_spf.google.com、SendGridを使っているならinclude:sendgrid.netなど、利用しているすべての送信サービスをSPFレコードに含める必要があります。

さらに、SPFレコードにはDNSルックアップが10回までという制限があります。複数のメール配信サービスを利用していると、この制限を超えてしまい、SPF認証が失敗することがあります。

原因2:DKIMの署名が正しく設定されていない

DKIMの設定では、秘密鍵による署名と公開鍵のDNS登録という2つの作業が必要です。メール配信サービスを利用している場合、サービス側で署名は行われますが、公開鍵の登録は自分でDNSに設定する必要があることが多いです。

特に注意が必要なのは、DKIM鍵のローテーションです。セキュリティ強化のために定期的にDKIM鍵を更新する組織がありますが、IT部門がDNSレコードの更新を忘れると、突然DKIMが失敗し始めます。

原因3:DMARCのアライメントが一致していない

SPFとDKIMが両方とも成功していても、アライメントが一致していないとDMARCは失敗します。これが最も見落とされやすい原因の一つです。

典型的な例として、独自ドメイン(例:fujiba.net)のメールアドレスを使いながら、実際にはGmailのSMTPサーバー経由で送信しているケースがあります。この場合、ヘッダFromはfujiba.netですが、Return-Path(エンベロープFrom)は@gmail.comになります。ドメインが一致しないため、SPFアライメントは失敗します。同様に、DKIMもGoogleの鍵で署名されるため、fujiba.netとは一致せずDKIMアライメントも失敗します。

原因4:サードパーティサービスの設定不備

現代のビジネスでは、メールマーケティングツール、CRMシステム、ヘルプデスクソフトウェアなど、さまざまなサードパーティサービスがメールを送信します。これらすべてのサービスで、自社ドメインを使ったSPFとDKIMの設定が正しく行われている必要があります。

Marketing AutomationツールでニュースレターをDKIM署名なしで送信していたり、CRMの自動フォローアップメールがSPFレコードに含まれていないサーバーから送信されていたりすると、それらのメールはDMARC認証に失敗します。

原因5:メール転送時の認証失敗

メールの転送は、SPFとDKIMの認証を複雑にします。メールが転送されると、送信元IPアドレスが変わるためSPF認証は通常失敗します。DKIMは署名が保持されていれば転送後も認証できますが、転送時にヘッダが改変されると失敗することがあります。

この問題に対処するため、ARC(Authenticated Received Chain)という技術があります。転送サービスやメーリングリストを運用している場合は、ARCヘッダを追加して認証のチェーンを維持することがGoogleのガイドラインで求められています。

原因6:DNS設定の基本的な不備

SPFやDKIMやDMARC以前の問題として、DNSの基本設定に問題があるケースも少なくありません。送信サーバーのIPアドレスに対する逆引きDNS(PTRレコード)が設定されていない、またはPTRレコードで得られるホスト名を正引きしてもIPアドレスが一致しないなどの問題があると、メールは拒否されやすくなります。

原因7:スパム報告率の閾値超過

認証設定が完璧でも、受信者からのスパム報告率が0.3%を超えるとメール配信に悪影響が出ます。Googleは0.1%未満の維持を推奨しており、この閾値を常に超えている場合は、メール配信の根本的な見直しが必要です。

GmailでメールがSPFやDKIMやDMARCで弾かれたときの具体的な対処法

原因が分かったところで、具体的な対処法を見ていきましょう。まずは現状の確認方法から始め、段階的に設定を改善していく手順を解説します。

ステップ1:現在の認証状況を確認する

最初にすべきことは、自分のドメインから送信されたメールが実際にどのような認証結果になっているかを確認することです。

最も簡単な方法は、自分のGmailアカウントにテストメールを送信して確認することです。受信したメールを開き、右上の三点メニューから「メッセージのソースを表示」を選択すると、SPF、DKIM、DMARCそれぞれの認証結果が表示されます。PASSと表示されていれば認証成功、FAILなら失敗です。

より詳細な分析には、Google Postmaster Toolsを利用することをお勧めします。自社ドメインを登録すると、IPレピュテーション、ドメイン評価、スパム報告率、送信ドメイン認証の成功率、配信エラー率などを継続的に監視できます。2024年半ばからはコンプライアンスステータスダッシュボードも追加され、Googleの要件への準拠状況が一目で確認できるようになっています。

ステップ2:SPFレコードを正しく設定する

SPFレコードは、ドメインのDNSにTXTレコードとして設定します。基本的な構文は以下のとおりです。

v=spf1 include:_spf.google.com include:sendgrid.net ~all

この例では、Google WorkspaceとSendGridからのメール送信を許可しています。自社で利用しているすべてのメール送信サービスを確認し、それぞれのSPFレコード情報を追加してください。

重要なポイントとして、SPFレコードはドメインに1つだけ設定します。複数のサービスを利用している場合は、1つのSPFレコード内にすべてのincludeステートメントを記載します。また、DNSルックアップ10回の制限に注意し、必要に応じてSPFフラット化やサブドメイン分離などの対策を検討してください。

ステップ3:DKIMを設定してメールに署名する

DKIM設定は通常、メール送信サービス側の設定とDNSへの公開鍵登録の2段階で行います。

Google Workspaceを使用している場合は、管理コンソールからDKIMを有効化し、表示される公開鍵情報をドメインのDNSにTXTレコードとして追加します。SendGridやMailchimpなどの外部サービスを使用している場合も、各サービスの管理画面でDKIM設定を行い、指示されたCNAMEまたはTXTレコードをDNSに追加します。

設定後は48時間程度でDNSが浸透し、DKIM認証が有効になります。テストメールを送信して認証結果を確認しましょう。

ステップ4:DMARCレコードを設定する

SPFとDKIMの設定が完了したら、DMARCレコードを追加します。DMARCレコードは_dmarc.yourdomain.comというサブドメインにTXTレコードとして設定します。

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

最初はp=noneのポリシーから始めることを強くお勧めします。このポリシーでは認証失敗メールも配信されますが、ruaで指定したアドレスにDMARCレポートが送られてきます。このレポートを分析することで、予期せぬ送信元からのメールや認証失敗の原因を特定できます。

数週間から数ヶ月かけてレポートを監視し、すべての正当なメールが認証に成功していることを確認できたら、p=quarantine、最終的にはp=rejectへとポリシーを段階的に強化していきます。

ステップ5:アライメントを確認して修正する

SPFとDKIMが両方PASSしていても、DMARCがFAILする場合はアライメントの問題です。ヘッダFromのドメインと、SPFで認証されたドメイン(Return-Path)またはDKIMで署名されたドメインが一致しているかを確認してください。

サードパーティサービスを使用している場合、そのサービスがカスタムReturn-PathとカスタムDKIMドメインをサポートしているかを確認します。多くの主要なメール配信サービスはこれらの機能を提供しており、自社ドメインでアライメントを一致させることができます。

ステップ6:ワンクリック配信停止機能を実装する

Googleの大量送信者要件では、マーケティングメールにワンクリックで配信停止できる機能を搭載することが義務付けられています。これはメール本文内のリンクとは別に、メールヘッダにList-UnsubscribeおよびList-Unsubscribe-Postヘッダを追加することで実現します。

クラウド型のメール配信サービスを利用している場合は、サービス側でこの機能が提供されていることが多いです。自社システムでメールを送信している場合は、RFC 8058に準拠した実装が必要になります。

情シス歴10年超の現場で学んだDNS設定の落とし穴と回避策

正直なところ、SPFやDKIMやDMARCの設定で一番厄介なのは「設定したつもりなのに動かない」という状況です。マニュアル通りにやったはずなのに認証が通らない。この原因の大半は、DNSまわりの細かい罠にハマっているケースです。ここでは、私が10年以上の情シス経験で実際に遭遇した「誰も教えてくれないDNSの落とし穴」をお伝えします。

TXTレコードの文字数制限という見えない壁

DNSのTXTレコードには255文字という制限があることをご存知でしょうか。SPFレコードに複数のincludeを追加していくと、あっという間にこの制限に引っかかります。特に、Google Workspace、Microsoft 365、SendGrid、Mailchimp、Salesforceなど複数のサービスを利用している企業では、SPFレコードが肥大化しがちです。

厄介なのは、DNSプロバイダによって挙動が異なる点です。お名前.comやムームードメインなどの一部のサービスでは、255文字を超えると自動的に分割してくれますが、分割方法が正しくないと認証に失敗します。AWS Route 53やCloudflare DNSでは、ダブルクォーテーションで区切って複数の文字列として登録する必要があります。

実際の現場での対処法としては、SPFレコードのフラット化が有効です。includeで参照している先のIPアドレスを直接記載することで、DNSルックアップ回数を削減しつつ文字数も節約できます。ただし、参照先のIPアドレスが変更された場合は手動で更新が必要になるため、定期的なメンテナンスが必須になります。

DNSキャッシュのTTL設定で泣いた話

これは本当に痛い目を見た経験なのですが、SPFレコードを修正したのに24時間経っても反映されないというトラブルがありました。原因は、元のTXTレコードのTTL(Time To Live)が86400秒(24時間)に設定されていたことでした。

DNS変更を行う前に、まずTTLを短く(300秒程度)に変更して、そのTTLが浸透してから本番の変更を行う。これが鉄則です。変更後に問題がなければTTLを元に戻す。この手順を踏まないと、設定ミスがあった場合にリカバリーに時間がかかりすぎます。

特にDKIMの鍵更新やDMARCポリシーの変更など、影響が大きい変更の前には必ずTTLを確認してください。私は今では変更作業の2日前にTTLを300秒に下げることをルーティンにしています。

サブドメインのDMARC継承問題

「メインドメインにDMARCを設定したから大丈夫」と思っていたら、サブドメインからのメールが弾かれた。これもよくあるパターンです。DMARCにはsp(サブドメインポリシー)というパラメータがあり、これを明示的に設定しないと予期せぬ動作をすることがあります。

さらに注意が必要なのは、サブドメインに個別のDMARCレコードを設定した場合、親ドメインの設定は継承されないという点です。marketing.example.comに独自のDMARCレコードを設定すると、example.comのsp設定は無視されます。これを理解していないと、サブドメインごとに設定がバラバラになり、管理が破綻します。

メールヘッダーを読み解く実践テクニック

トラブルシューティングで最も重要なスキルは、メールヘッダーを正確に読み解く能力です。Gmailの「メッセージのソースを表示」で見られる情報は氷山の一角で、本当に必要な情報は生のヘッダーの中に埋もれています。

Authentication-Resultsヘッダーの正しい読み方

認証結果を確認する際、多くの人はSPF、DKIM、DMARCがPASSかFAILかだけを見ますが、それだけでは不十分です。Authentication-Resultsヘッダーには、認証に使われたドメインやセレクタ、詳細な失敗理由が記載されています。

例えば、DKIMの結果が「dkim=pass header.d=sendgrid.net」となっている場合、DKIMは成功していますが、署名ドメインがsendgrid.netであることがわかります。ヘッダーFromがexample.comだとすると、アライメントは失敗します。この詳細を見ないと、「DKIMはPASSしてるのになぜDMARCがFAILなの?」という疑問の答えにたどり着けません。

Receivedヘッダーでメールの経路を追跡する

メールが複数のサーバーを経由する場合、Receivedヘッダーを下から上に読むことで、メールがどのような経路を辿ったかを追跡できます。各Receivedヘッダーには、受信したサーバー、送信元サーバー、タイムスタンプが記録されています。

転送やメーリングリストを経由している場合、途中でSPF認証が失敗するポイントを特定できます。また、予期せぬ中継サーバーを経由していることが判明し、セキュリティ上の問題を発見できることもあります。

実務で使えるヘッダー解析コマンド

Gmailから「メッセージのソースを表示」でコピーしたヘッダーを解析する際、私がよく使うのは以下のようなgrepコマンドです。LinuxやMacのターミナル、またはWindows Subsystem for Linuxで実行できます。

認証結果だけを抽出したい場合はgrep -i “authentication-results” mailheader.txtを実行します。メールの経路を確認したい場合はgrep -i “^received:” mailheader.txtで一覧表示できます。SPFの詳細を見たい場合はgrep -i “spf” mailheader.txtが便利です。

オンラインツールを使いたくない機密性の高いメールの場合、このようにローカルで解析する方法を知っておくと重宝します。

複数ドメインやサブドメインを運用する際の認証設計

企業規模が大きくなると、複数のドメインやサブドメインを運用することになります。このとき、認証設計を事前にしっかり考えておかないと、後から収拾がつかなくなります。私が関わったプロジェクトで効果的だったアプローチを紹介します。

ドメイン・サブドメインの役割分担を明確にする

まず、どのドメイン・サブドメインから何を送るのかを一覧表にまとめます。例えば、example.comは社内コミュニケーション用、marketing.example.comはマーケティングメール用、support.example.comはカスタマーサポート用、noreply.example.comはシステム通知用、といった具合です。

この分類が重要な理由は、Gmailの大量送信者判定がヘッダーFromドメイン単位で行われるからです。マーケティングメールで大量送信者として認定されても、その影響をsupport.example.comに波及させないようにできます。また、万が一特定のサブドメインがブラックリストに登録されても、他への影響を最小限に抑えられます。

SPFレコードの設計パターン

複数サブドメインを運用する場合、SPFレコードの設計には大きく2つのパターンがあります。

一つ目は各サブドメインに個別のSPFレコードを設定する方法です。marketing.example.comにはMailchimpのSPF、support.example.comにはZendeskのSPF、というように分離します。管理は複雑になりますが、各サブドメインで使用するサービスが明確に限定されるメリットがあります。

二つ目は共通のSPFレコードを参照させる方法です。_spf.example.comというサブドメインにすべてのincludeをまとめ、各サブドメインからはinclude:_spf.example.comで参照します。変更が一箇所で済むため管理は楽ですが、不要な許可が含まれるリスクがあります。

私の経験では、セキュリティを重視するなら前者、運用効率を重視するなら後者という使い分けが現実的です。

DKIM鍵の管理戦略

複数のメール送信サービスを利用している場合、DKIMセレクタの命名規則を統一しておくと管理が楽になります。例えば、s1._domainkey.example.comはGoogle Workspace用、sg._domainkey.example.comはSendGrid用、mc._domainkey.example.comはMailchimp用、といった具合です。

また、DKIM鍵のローテーションスケジュールを立てておくことも重要です。セキュリティ的には1年に1回程度の更新が推奨されますが、更新作業を忘れると突然メールが届かなくなります。私はカレンダーにリマインダーを設定し、更新の2週間前から準備を始めるようにしています。

突然メールが届かなくなったときの緊急対応マニュアル

「今朝から顧客へのメールが全然届いていないらしい」という連絡が来たとき、パニックにならないための対応手順をまとめます。これは私が実際に何度も経験した状況から構築した初動対応チェックリストです。

最初の15分でやるべきこと

まず、問題の範囲を特定します。すべての宛先に届かないのか、特定のドメイン(Gmail、Yahoo!など)だけなのか、特定の送信元(特定のサブドメインやサービス)だけなのか。これによって原因の絞り込みが大きく変わります。

次に、直近で何か変更を行ったかを確認します。DNS設定の変更、メール配信サービスの設定変更、サーバーの移行、新しいツールの導入など。変更があれば、それが原因である可能性が高いです。

そして、外部サービスの障害情報を確認します。Google Workspace Status Dashboard、SendGridのステータスページ、利用しているDNSプロバイダのステータスなど。自社の問題ではなく、サービス側の障害である可能性もあります。

原因切り分けの具体的手順

問題の範囲が特定できたら、原因を切り分けます。私がいつも使う手順は以下の通りです。

まず、テストメールを自分のGmailに送信して、メールヘッダーを確認します。SPF、DKIM、DMARCの認証結果を見れば、認証周りの問題かどうかがすぐにわかります。

認証がFAILしている場合は、digコマンドやnslookupでDNSレコードを確認します。「dig txt example.com」でSPFレコード、「dig txt _dmarc.example.com」でDMARCレコード、「dig txt selector._domainkey.example.com」でDKIMレコードが確認できます。設定した内容と実際にDNSで返ってくる内容が一致しているか確認してください。

認証が成功しているのに届かない場合は、IPレピュテーションの問題を疑います。MXToolBoxやSenderScoreで送信IPアドレスの評価を確認し、ブラックリストに登録されていないかチェックします。

一時的な回避策の選択肢

根本的な解決に時間がかかる場合、ビジネスを止めないための一時的な回避策を講じる必要があります。

DNS設定の問題であれば、TTLが短い別のサブドメインを新規作成して、そこから送信することで急場をしのげることがあります。example.comの設定に問題がある場合、temp.example.comを作成してそこにSPF、DKIM、DMARCを新規設定するという方法です。

IPレピュテーションの問題であれば、別のメール配信サービスを一時的に利用する方法があります。SendGridに問題があればAmazon SESを使う、といった具合です。ただし、SPFレコードの追加が必要になるため、DNS変更の時間は考慮してください。

外部ベンダーやクラウドサービスとの連携で躓くポイント

現代のビジネスでは、さまざまなSaaSやクラウドサービスがメールを送信します。これらのサービスとの連携で、情シス担当者が必ず確認すべきポイントがあります。

サービス導入時の認証設定チェックリスト

新しいサービスを導入する際、営業担当者やマーケティング担当者は機能面ばかりに注目しがちですが、情シスとしてはメール認証のサポート状況を必ず確認すべきです。

具体的には、カスタムReturn-Path(エンベロープFrom)の設定が可能か、カスタムDKIM署名ドメインの設定が可能か、送信IPアドレスは専用か共有か、SPFレコードに追加すべき情報は何か、APIでの送信とSMTP送信の両方がサポートされているか、といった点を確認します。

これらの情報は、サービスのヘルプドキュメントに記載されていることが多いですが、見つからない場合は導入前にサポートに問い合わせることを強くお勧めします。導入後に「カスタムDKIMはエンタープライズプランのみ」と言われて困った経験が何度もあります。

マーケティングオートメーションツールとの連携の罠

HubSpot、Marketo、Pardotなどのマーケティングオートメーション(MA)ツールは、メール配信機能を持っていますが、認証設定の方法がサービスによって大きく異なります。

例えば、HubSpotでは専用送信ドメイン(Dedicated IP)を利用する場合と共有IPを利用する場合で設定方法が異なります。Marketoでは、DKIMの設定に加えてブランデッドリンク(トラッキングリンクのカスタムドメイン化)の設定も推奨されています。

特に注意が必要なのは、MAツールの「デフォルト設定」では自社ドメインのアライメントが取れないことが多い点です。初期状態ではMAベンダーのドメインで署名されるため、DMARCがFAILします。必ずカスタムドメインでの署名設定を行ってください。

CRMやヘルプデスクツールの見落としがちな設定

Salesforce、Zendesk、Freshdeskなどのツールからも自動メールが送信されます。これらのツールは、営業部門やサポート部門が独自に導入していることが多く、情シスが把握していないケースもあります。

私の経験では、「なぜかZendeskからのメールだけDMARCがFAILする」という問題が発生し、調べてみたらカスタマーサポート部門が情シスに相談なくZendeskを導入していた、ということがありました。SPFレコードにZendeskのincludeが含まれていなかったのが原因です。

対策として、定期的に全部門にメール送信ツールの利用状況をヒアリングすることを推奨します。また、DMARCレポートを分析することで、把握していない送信元を発見できることもあります。

Gmailの管理者向け機能を最大限活用する

Google WorkspaceやGmailには、メール配信のトラブルシューティングに役立つ機能がいくつかあります。意外と知られていない機能も含めて紹介します。

Email Log Search(メールログ検索)の活用法

Google Workspace管理者であれば、管理コンソールからメールログを検索できます。レポート、監査と調査、メールログ検索の順にアクセスし、送信者、受信者、件名、日時などで検索できます。

この機能が特に役立つのは、「送ったはずのメールが届いていない」という問い合わせへの対応です。メールログを確認することで、メールがGoogleのサーバーから送信されたのか、送信時にエラーが発生したのか、受信サーバーに拒否されたのかを特定できます。

また、配信ステータスの詳細を見ることで、具体的なエラーコードやエラーメッセージを確認できます。「550 5.7.26 This message does not pass authentication checks」といったメッセージが表示されていれば、認証の問題であることがすぐにわかります。

メッセージヘッダーアナライザーの使い方

Googleが提供しているGoogle Admin Toolbox Messageheaderというツールをご存知でしょうか。メールヘッダーを貼り付けると、SPF、DKIM、DMARCの認証結果、メールの遅延、経由したサーバーなどを視覚的に表示してくれます。

生のヘッダーを目で追うよりもはるかに効率的に問題を特定できます。特に、メールの配信遅延がどこで発生しているかを特定するのに便利です。各サーバー間の遅延時間がグラフで表示されるため、ボトルネックが一目でわかります。

Gmailの検索演算子でトラブルメールを素早く見つける

受信者側として問題のあるメールを探す場合、Gmailの検索演算子が役立ちます。in:spamで迷惑メールフォルダを検索、in:allですべてのメール(迷惑メール、ゴミ箱含む)を検索、from:example.comで特定ドメインからのメールを検索できます。

さらに便利なのは、has:nouserlabelsという演算子です。これは、どのラベルにも分類されていないメールを検索します。フィルタの設定ミスで意図せずアーカイブされてしまったメールを見つけるのに使えます。

社内への説明と予算獲得のための実践的アプローチ

メール認証の設定は技術的には可能でも、予算や人員の確保が難しいという声をよく聞きます。上司や経営層を説得するためのポイントをまとめます。

リスクを数字で示す

「メールが届かなくなるかもしれません」では説得力に欠けます。具体的な数字でリスクを示すことが重要です。

例えば、「月間のメール送信数が10万通、そのうち30%がGmail宛と仮定すると、3万通が届かなくなる可能性があります。平均的なメールマーケティングのコンバージョン率を0.5%とすると、150件の商談機会を失う計算です。1件あたりの平均契約額が10万円なら、月間1500万円の売上リスクがあります」といった具合です。

また、競合他社の対応状況を調査して示すのも効果的です。「主要競合5社のうち4社はすでにDMARC p=rejectを設定済みです。当社だけが対応していない状況です」といった情報は、経営層の危機感を煽るのに有効です。

段階的な対応計画を提示する

一度にすべてを完璧にしようとすると、予算も時間も膨大になります。フェーズを分けた段階的なアプローチを提案することで、承認を得やすくなります。

例えば、フェーズ1(1ヶ月目)ではSPFとDKIMの設定を完了させ、フェーズ2(2〜3ヶ月目)ではDMARC p=noneを設定してレポートを収集し、フェーズ3(4〜6ヶ月目)ではレポート分析に基づいて問題を修正しp=quarantineに移行、フェーズ4(7ヶ月目以降)でp=rejectに移行する、といった計画です。

各フェーズで達成すべき目標と必要なリソースを明確にすることで、経営層も進捗を把握しやすくなります。

外部リソースの活用を検討する

社内に専門知識を持つ人材がいない場合、DMARC管理サービスの利用を検討する価値があります。Proofpoint EFD、Valimail、dmarcianなどのサービスは、DMARCレポートの可視化、問題の自動検出、設定変更の推奨などを提供しています。

これらのサービスは月額費用がかかりますが、専任担当者を雇用するよりは安価であることが多いです。また、設定ミスによるメール配信停止のリスクを軽減できるため、保険的な意味合いもあります。

ぶっちゃけこうした方がいい！

ここまで読んでいただいた方には、SPFやDKIMやDMARCの設定がいかに複雑で、落とし穴が多いかがおわかりいただけたと思います。正直なところ、完璧を目指そうとすると終わりがないのがこの分野です。

で、ぶっちゃけた話をしますと、私が10年以上この仕事をしてきて行き着いた結論は「最初からGoogle WorkspaceかMicrosoft 365を使え」です。

なぜかというと、これらのサービスを使っていれば、SPFもDKIMも基本的には自動で設定されます。DMARCだけは自分で設定する必要がありますが、それも_dmarc.example.comにTXTレコードを1行追加するだけです。サードパーティのメール配信サービスを使う場合も、Google WorkspaceやMicrosoft 365との連携ドキュメントが充実しているので、設定で迷うことがほとんどありません。

「独自のメールサーバーを運用したい」「コストを抑えたい」という気持ちはわかります。でも、メールが届かないことによるビジネスへの影響と、トラブル対応に費やす時間と労力を考えると、月額数百円〜数千円のクラウドサービス利用料は安い投資です。

特に中小企業の場合、情シス担当者が1人しかいない、あるいは兼任しているというケースが多いでしょう。そんな状況で、DNSのTTLがどうとか、DKIMセレクタがどうとか、アライメントがどうとかに時間を取られていたら、本来やるべき仕事ができなくなります。

どうしても独自運用が必要な場合は、最低限、DMARCレポートの可視化サービスだけは導入することをお勧めします。XMLのレポートを手動で解析するのは現実的ではありませんし、問題が起きてから対応するのでは遅すぎます。レポートを見ていれば、問題が大きくなる前に気づけることが多いです。

そして最後に、「設定して終わり」ではなく「設定してからが始まり」という意識を持ってください。新しいサービスの導入、組織変更、ドメインの追加など、メール環境は常に変化します。その変化に合わせて認証設定も更新していく必要があります。四半期に1回でいいので、DMARCレポートを確認し、SPFレコードに不要なincludeがないか見直し、DKIMの鍵が適切に管理されているか確認する。この習慣さえ身につければ、突然メールが届かなくなるという最悪の事態は防げるはずです。

結局のところ、メール認証は「やるかやらないか」ではなく「いつやるか」の問題になっています。Googleの厳格化は今後も進むでしょうし、Microsoftも追随しています。今日対応を始めれば、明日からのリスクを減らせます。この記事を読んだ今日が、その「いつ」になることを願っています。

よくある質問への回答

DMARCをnoneで設定していれば問題ないですか?

Googleの現在の要件では、p=noneでも要件を満たします。ただし、Googleは将来的にquarantineまたはrejectポリシーが必要になる可能性を示唆しています。また、p=noneではなりすましメールを防ぐことができないため、セキュリティの観点からはp=rejectへの移行を目指すべきです。

無料のGmailアカウントから独自ドメインのメールを送信できますか?

技術的には可能ですが、DMARC認証に失敗する可能性が高いです。無料のGmailのSMTPサーバーを経由して独自ドメインのアドレスから送信すると、Return-PathがGmail.comになり、アライメントが一致しません。この問題を解決するには、Mailtrapやpostmarkのような認証付きメール送信サービスを利用するか、Google Workspaceを契約して独自ドメインでの送信環境を整える必要があります。

5000通未満しか送信していない場合も設定が必要ですか?

はい、必要です。5000通未満の送信者にも、SPFまたはDKIMの設定、有効なDNS逆引き設定、TLS接続、RFC 5322準拠のメール形式などが求められています。また、将来的に送信量が増える可能性や、なりすましメールによるカウント増加も考慮すると、最初から大量送信者要件を満たす設定にしておくことをお勧めします。

設定が正しいはずなのにまだ弾かれる場合は?

複数の可能性があります。まずDNSの反映に時間がかかっている可能性があるため、設定変更後48時間は様子を見てください。次に、IPレピュテーションの問題があるかもしれません。共有IPアドレスを使用している場合、他の利用者の行為によってレピュテーションが低下している可能性があります。また、ブラックリストへの登録も考えられます。SpamhausやMXToolBoxなどのサービスで自社ドメインやIPアドレスがブラックリストに登録されていないか確認してください。

トランザクションメールも同じ要件が適用されますか?

認証要件(SPF、DKIM、DMARC)はすべてのメールに適用されます。ただし、ワンクリック配信停止機能はマーケティングメールやプロモーションメールのみが対象で、パスワードリセットや注文確認などのトランザクションメールは対象外です。

2026年以降を見据えたメール認証のベストプラクティス

メール認証の要件は今後も厳格化が進むと予想されています。現時点でのベストプラクティスをまとめておきましょう。

すべてのドメインでSPFとDKIMの両方を設定する

現在の要件ではSPFまたはDKIMのいずれかで認証成功すればよいとされていますが、Googleは将来的に両方の設定と両方でのアライメント成功が要件になる可能性を示唆しています。今から両方を設定しておくことで、将来の要件変更にもスムーズに対応できます。

DMARCポリシーを段階的にrejectまで強化する

p=noneから始めてレポートを収集し、問題がないことを確認しながらp=quarantine、最終的にはp=rejectまで強化していくことをお勧めします。p=rejectに設定することで、自社ドメインを騙ったなりすましメールを完全にブロックでき、ブランドと顧客を保護できます。

定期的なモニタリングと監査を実施する

Google Postmaster Toolsやサードパーティの監視ツールを活用して、認証成功率、スパム報告率、IPレピュテーションを継続的に監視してください。新しいメール送信サービスを導入する際は、必ずSPFとDKIMの設定を更新することを運用フローに組み込みましょう。

すべての送信元を把握して管理する

組織内のどの部門がどのサービスを使ってメールを送信しているかを把握することは、意外と難しい課題です。マーケティング部門のMA(マーケティングオートメーション)ツール、営業部門のCRM、カスタマーサポートのヘルプデスクツール、経理部門の請求書送信システムなど、すべての送信元をリストアップして認証設定を確認してください。

まとめ

GmailでメールがSPFやDKIMやDMARCで弾かれる問題は、2025年11月からの厳格化によって深刻度を増しています。しかし、正しい知識と適切な設定があれば、確実に解決できる問題でもあります。

この記事で解説した内容をまとめると、まずGoogle Postmaster Toolsやメールヘッダの確認で現状を正確に把握することが出発点です。次に、SPF、DKIM、DMARCの順で段階的に設定を追加・強化していきます。特にアライメントの一致には注意を払い、ヘッダFromドメインとSPF/DKIMドメインが一致していることを確認してください。

設定後も継続的なモニタリングを怠らず、新しいサービスの導入時には必ず認証設定を更新するフローを確立しましょう。そして、現在のp=noneから始めて、最終的にはp=rejectまでDMARCポリシーを強化することで、なりすましメールから自社ブランドと顧客を守ることができます。

メール認証の設定は一見複雑に見えますが、一度正しく設定してしまえば、その後は安心してメールを送信できるようになります。今日から一つずつ対策を進めて、Gmail宛のメールが確実に届く環境を整えていきましょう。