## この記事でわかること

- 「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ポリシーが `quarantine` や `reject` のとき、以下のような文面になります。

```
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](https://support.google.com/a/answer/3726730)）。

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

![Gmailが5.7.26で拒否するまでの判定フロー](/blog/gmail-550-5726-fix/bounce-flow.svg)

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

前提として、SPF・DKIM・DMARCそれぞれの役割を整理したい方は、先に[SPF・DKIM・DMARCの違いをわかりやすく解説](/blog/spf-dkim-dmarc-difference)をご一読ください。

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

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

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

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

![Authentication-Resultsヘッダの読み方](/blog/gmail-550-5726-fix/auth-results-reading.svg)

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

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

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

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

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

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

![原因別の修正優先順位](/blog/gmail-550-5726-fix/fix-priority.svg)

### 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レコードの設定方法｜書き方と確認の手順](/blog/spf-setup-guide)にまとめています。

### DKIMが失敗している場合

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

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

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

確認手順は[DKIM設定の確認方法](/blog/dkim-verification)に手順を掲載しています。

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

SPF・DKIMは `pass` でも、From欄のドメインと `smtp.mailfrom` や `header.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 ステップ](/blog/dmarc-setup-guide)を参照してください。Gmailに届かない問題を包括的に見直したい方は、[Gmailにメールが届かない原因と対処法](/blog/gmail-not-receiving)に全体像を整理しています。

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

要点を整理します。

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

類似のエラーコードでは、認可拒否系の [Gmail 5.7.1エラーの対処](/blog/gmail-550-571-fix) や、Outlook 側のIPブロック [Outlook 5.7.708 の解除申請手順](/blog/outlook-550-57708-fix) も併読すると、Gmail / Outlook 双方で発生する拒否系エラーに対応できます。

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