Gmailメール認証DMARC中小企業

Gmail 5.7.26エラーの原因と対処法|中小企業向け

ドメイン番人7 分で読めます
目次

この記事でわかること

  • 「550-5.7.26 Unauthenticated email」の意味と、Gmailが拒否に踏み切る条件
  • SPF・DKIM・アラインメントのどこが落ちているかの切り分け手順
  • 復旧までの優先順位と、再発を防ぐための運用ポイント

5.7.26エラーが出たときに起きていること

取引先のGmailに請求書を送った直後、送信者のメールボックスに次のような英文エラーが返ってきた経験はありませんか。

550-5.7.26 This mail has been blocked because the sender is
unauthenticated. Gmail requires all senders to authenticate with
either SPF or DKIM.

または、自社ドメインのDMARCポリシーが quarantinereject のとき、以下のような文面になります。

550-5.7.26 Unauthenticated email from example.co.jp is not accepted
due to domain's DMARC policy.

どちらも共通するのは、「認証に通らなかったメールを、Gmail側のルールで拒否した」という意思表示です。Googleは 550 5.7.26 を「送信ドメインが認証されていない、またはDMARCポリシーで拒否された」エラーとして定義しています(Gmail SMTP errors and codes|Google Workspace Admin Help)。

背景には、2024年2月に施行されたGmailの送信者ガイドライン改訂があります。1日5,000通以上をGmail宛てに送る一括送信者にはSPF・DKIM・DMARCの全てとドメインアラインメントが必須となり、それ未満の送信者にもSPFまたはDKIMの設定が求められるようになりました(Email sender guidelines|Google Workspace Admin Help)。2025年以降は非準拠の送信元に対する拒否が段階的に強化されており、以前は黙って迷惑メールに振り分けられていたメールが、明確な拒否(5.7.26)として跳ね返ってくるケースが増えています。

Gmailが5.7.26で拒否するまでの判定フロー

エラー本文の末尾には SPF check for [...] did not pass のような補足が含まれていることが多く、どの認証が落ちているかのヒントになります。まずはその一文をそのまま控えておいてください。

前提として、SPF・DKIM・DMARCそれぞれの役割を整理したい方は、先にSPF・DKIM・DMARCの違いをわかりやすく解説をご一読ください。

原因をSPF・DKIM・アラインメントの3点で切り分ける

5.7.26エラーの原因は、ほぼ次の3つのいずれかです。

  1. SPFが失敗している:送信元IPがSPFレコードで許可されていない
  2. DKIMが失敗している:DKIM署名がDNSの公開鍵で検証できない
  3. アラインメントが失敗している:SPFやDKIMは通っているが、From欄のドメインと一致していない

切り分けの起点は、受信側に届いた(届きかけた)メールの Authentication-Results ヘッダです。社内の別アドレスや個人のGmailに同じメールを送り、受信側で「メッセージのソースを表示」を開くと、次のような行が見つかります。

Authentication-Resultsヘッダの読み方

読み取るべきポイントは3つだけです。

  • spf=pass かどうか、smtp.mailfrom= のドメインがFrom欄のドメインと揃っているか
  • dkim=pass かどうか、header.d= のドメインがFrom欄のドメインと揃っているか
  • dmarc=pass かどうか

SPFとDKIMのどちらか一方でも pass かつドメインが揃っていればDMARCは通ります。逆に、SPFもDKIMも pass だがどちらも header.dsmtp.mailfrom がFrom欄と別ドメインになっている状態は、アラインメント失敗です。外部のメール配信サービス(請求書発行、マーケティング、CRM通知など)を経由している場合にとくに起きやすく、「設定したのに拒否される」現象の大半はこれに該当します。

Authentication-Results が取れないほど早く拒否されている場合は、自社で保有する送信サーバーのログを確認するか、DMARCのレポート(rua)を受信して失敗メールの集計を見るのが近道です。レポートの読み方については別記事で改めて扱います。

原因別の具体的な対処手順

切り分けが済んだら、原因に対応する箇所だけを直すのが復旧最短ルートです。全てを同時に書き換えると、副作用で別のメールが止まる恐れがあります。

原因別の修正優先順位

SPFが失敗している場合

まずは自社ドメインのSPFレコードを確認します。

nslookup -type=txt example.co.jp

返ってきたレコードに、実際に使っている送信サービスの include: が全て含まれているかを確認してください。Google Workspaceなら _spf.google.com、Microsoft 365なら spf.protection.outlook.com のように、各サービスの公式ドキュメントで指定されたホスト名を使います。推測で書くと外れます。

よくある原因は次のとおりです。

  • 新しいメール配信サービスを導入したが、SPFに include: を追加し忘れた
  • SPFレコードが2行存在し、RFC 7208上のPermErrorで評価が無効化されている
  • include: を足し続けた結果、DNSルックアップが10回の上限を超えている

具体的な書き方と上限対処はSPFレコードの設定方法|書き方と確認の手順にまとめています。

DKIMが失敗している場合

DKIMはメール本文のハッシュに秘密鍵で署名し、DNSに公開した公開鍵で検証する仕組みです。dkim=fail が出るときの典型は次のとおりです。

  • DNSに公開鍵(selector._domainkey.example.co.jp 形式のTXTレコード)が登録されていない
  • 公開鍵の改行位置や p= の値がズレて、受信側が復号できない
  • 利用中のメールサービスでDKIM署名をオンにし忘れている

Google Workspaceの場合、管理コンソールの「メール」>「ドメインの認証」で署名を開始するとDKIMが有効化されます。Microsoft 365はDefender管理センターの「メールフローポリシー」>「DKIM」から切り替えます。DNS側の公開鍵は各サービスが生成する値をそのまま貼り付ける形になり、手で書き写さないのが鉄則です。

確認手順はDKIM設定の確認方法に手順を掲載しています。

アラインメントが失敗している場合

SPF・DKIMは pass でも、From欄のドメインと smtp.mailfromheader.d が一致していないとDMARCで落ちます。典型的なのは、自社ドメインをFromに使いつつ、実際の送信はメール配信サービスのサブドメインから出ているケースです。

対処は「配信サービス側で自社ドメインを送信ドメインとして登録し、DKIM署名を自社ドメインで行う」ことに尽きます。多くのサービスは設定ガイドに「カスタムドメイン認証」「送信ドメイン認証」といった項目を用意しており、指示どおりにDNSへCNAMEまたはTXTを追加すれば、DKIMの header.d がFrom欄と一致するようになります。

一時回避は基本的に非推奨

「急ぎで送りたいから、DMARCを p=none に下げてしまえばよいか」と考える方がいますが、中長期的には逆効果です。p=none は拒否ではなく「報告のみ」となるため、その間、なりすましの検出が効かなくなるだけでなく、Gmailが他の指標(スパム率やレピュテーション)で拒否する動機を強めます。緊急時は送信元を一時的に別ドメインに切り替えるか、別のメールサービス経由で送る方が安全です。

再発を防ぐために仕込んでおきたい運用

一度直しても、新しいメール配信サービスを契約したり、ドメインを統合したりするたびに同じ問題は再発します。以下の3点を運用に組み込んでおくと、再発時の気づきが早くなります。

  • DMARCのレポート(rua=)を受信する:日次で認証失敗メールの送信元IPと件数が届くため、異常に気づけます
  • Google Postmaster Toolsに登録する:自社ドメインの認証成功率、スパム率、レピュテーションがGmail側から無料で可視化されます
  • 設定変更時のチェックリストを持つ:メールサービス追加時にSPF・DKIM・アラインメントを毎回点検する運用を標準化します

DMARCレポートの受信設定は、DNSにTXTレコードを1行追加するだけで始められます。具体的な進め方はDMARC設定方法を徹底解説|中小企業でもできる3ステップを参照してください。Gmailに届かない問題を包括的に見直したい方は、Gmailにメールが届かない原因と対処法に全体像を整理しています。

まずは現状を把握しましょう

要点を整理します。

  • 5.7.26はGmailの明示的な拒否。原因はSPF・DKIM・アラインメントのいずれか
  • Authentication-Results ヘッダで、どのチェックが落ちているかを必ず特定してから直す
  • 配信サービス経由のメールはアラインメント失敗が多い。DKIM署名を自社ドメインで行う設定を必ず確認
  • 一時回避でDMARCポリシーを下げるのは避け、レポート受信とPostmaster Toolsで再発を検知する体制を作る

無料のドメイン診断ツールでは、自社ドメインのSPF・DKIM・DMARCの状態と、Gmailの送信者要件に対する充足度をまとめて確認できます。「エラーが出ているが、どこから手をつければよいかわからない」という方は、お問い合わせフォームから状況をお知らせください。エラーメッセージの原文と送信元メールサービスを添えていただければ、専門家が内容を確認したうえで、復旧手順と必要なDNS変更をご案内します。

次の一歩は無料診断から。