Gmailの550-5.7.26で拒否されるときの直し方｜英文で原因が3つに分かれます

Gmail宛に送ったメールが届かず、550-5.7.26 を含むエラーメールが返ってくることがあります。このコードで検索すると「SPFとDKIMを設定してください」という説明が並びますが、それだけで直るとは限りません。

Googleが公開しているエラーコード一覧には、同じ 550-5.7.26 に対して3つの異なる英文が載っています。どれが返ってきたかで、原因も直す場所も変わります。SPFを設定しても直らない場合、そもそも別の英文が返っている可能性があります。

この記事では、返ってきた英文から原因を切り分け、それぞれの直し方を説明します。「そもそもメールが届いているのか分からない」という段階であれば、先に独自ドメインのメールが届かない原因の切り分けを確認してください。

返ってきた英文がどれかを確認する

エラーメールの本文に、コードと一緒に英文が入っています。まずどれに当たるかを確認してください。以下はGoogleのGmail SMTP エラーとコードに掲載されている原文です（2026年7月27日確認）。

3つとも「認証が通っていない」点は共通ですが、1つ目は認証設定が無いか届いていない状態、2つ目はSPFはあるが送信元が入っていない状態、3つ目は自分が公開しているDMARCポリシーが効いている状態です。順に見ていきます。

sender is unauthenticated と書かれている場合

原文は次のとおりです。

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

either SPF or DKIM と書かれているとおり、Googleがここで求めているのはSPFとDKIMのどちらかです。両方を揃えないと必ず拒否される、という意味ではありません。ただし送信量が多い場合は要件が変わります。送信量ごとの要件は独自ドメインのメールが届かない原因の切り分けに表でまとめてあります。

このエラーを解消するための最低条件は、SPFかDKIMのどちらかを実際に送っているメールで通すことです。DNSにレコードが存在することと、そのメールで認証が通ることは別です。たとえばSPFレコードがあっても、実際にメールを送り出しているサーバーがそこに含まれていなければ通りません。

DNSの設定で確認できること

診断ツールで確認できるのは、公開されているDNSの設定です。

• SPFレコードが存在するか、構文が正しいか、DNS参照回数が上限を超えていないか
• DKIMの公開鍵が引ける状態にあるか
• DMARCレコードの内容

ドメインを診断する

送信側でしか確認できないこと

一方、次の点はDNSを見ても分かりません。送信に使っているサービスの管理画面や送信ログで確認してください。

• 実際にメールを送り出しているサーバーのIPアドレス
• エンベロープの送信者（MAIL FROM）に使われているドメイン
• 送信時にDKIM署名が付いているか

問い合わせフォームの自動返信や、会員登録の確認メールのように、Webサーバーやアプリケーションから送っている場合は、メールソフトの設定とは別の経路になっていることがあります。そちらのIPがSPFに入っているかを確認してください。

hard fail policy (-all) と書かれている場合

原文は次のとおりです。

The (E)MAIL FROM domain [domain-name] has an SPF record with a hard fail
policy (-all) but it fails to pass SPF checks with the ip: [ip-address]

この文面が返っているとき、SPFレコード自体は存在しています。存在したうえで、そのレコードが -all で終わっており、実際の送信元IPが許可対象に入っていません。

all はどんな送信元にも一致する機構で、レコードの末尾に置いて既定の扱いを決めるために使います（RFC 7208 §5.1）。先頭に - が付いた場合の結果がfailで、これは「クライアントがそのドメインを名乗ることを認可されていないという明示的な宣言」と定義されています（RFC 7208 §8.4）。

~all（softfail）にすれば同じ状況でも即座に拒否されるとは限りません。softfailは「おそらく認可されていない」という弱い表明で、failほど強い宣言ではないためです（RFC 7208 §2.6.5）。ただし ~all に変えることは問題の先送りです。認可されていない送信元からメールが出ている事実は変わりません。

直す手順は次のようになります。

1. エラーメール本文の ip: に書かれているアドレスを確認します。これが実際の送信元です
2. そのIPが自分の使っているサービスのものかを確認します。心当たりが無い場合、第三者があなたのドメインを名乗っている可能性があります。その場合はSPFに追加してはいけません
3. 自分のサービスのものであれば、そのサービスが公開しているSPFの記述を確認し、既存のレコードに追記します

追記するとき、SPFレコードを2本に増やしてはいけません。1つのドメインにSPFレコードが2本以上あると、受信側は評価を打ち切って認証を失敗させます。既存の1本に include: を足す形にしてください。

また、include: を足すとDNS参照回数が増えます。10回を超えるとPermErrorになり、SPFでの認証はできなくなります。数え方と対処はSPFのDNS参照回数が10回を超える原因と直し方で扱っています。

値を推測で書き換えないでください。利用しているサービスが公開している値を確認して使うことが、この作業で最も重要な点です。

due to domain's DMARC policy と書かれている場合

原文は次のとおりです。

Unauthenticated email from domain-name is not accepted due to domain's
DMARC policy. Contact the administrator of domain-name domain if this
was legitimate email.

この文面は、拒否の判断を求めているのがGmailではなく、送信元ドメインの持ち主、つまりあなた自身であることを示しています。認証が通らなかったメールをどう扱うかは、DMARCレコードで指示できます。p=quarantine や p=reject を設定していると、Gmailはその指示に従って拒否します。

そのため、この文面が返っているときは「Gmailに拒否された」ではなく「自分のポリシーが適用された」と読むほうが正確です。

DMARCが成功する条件

DMARCの認証は、SPFかDKIMのどちらかが成功していれば通ります。ただし条件がもう1つあります。RFC 9989 §5.3.5は次のように定めています。

If one or more of the Authenticated Identifiers align with the Author Domain, the message is considered to pass the DMARC mechanism check.

認証された識別子が「Author Domain と整合している」ことが要ります。この整合をアラインメントと呼びます。Author Domain はFromヘッダーに表示されるドメインのことで、SPFが検証したドメイン（エンベロープの MAIL FROM）またはDKIM署名の d= がこれと揃っている必要があります。

つまり、SPF単体はpassしていてもDMARCは失敗する、という状態がありえます。メール配信サービスを使っていて、エンベロープの送信者がそのサービスのドメインになっている場合が典型です。この場合、そのサービス側でDKIM署名を自分のドメインで行う設定にすると解決します。

なお、DMARCの仕様は2026年5月に更新され、RFC 7489 は RFC 9989（本体）、RFC 9990（集計レポート）、RFC 9991（失敗レポート）に置き換わりました。この記事は新しい方を参照しています。

p=none に下げれば直るのか

直りますが、原因は残ります。RFC 9989 §4.7 は none を次のように定義しています。

none: The Domain Owner offers no expression of preference.

ドメインの持ち主として扱いの希望を示さない、という意味です。DMARCの評価やレポートの送信が止まるわけではありません。ポリシーを下げれば、この文面での拒否は起きなくなります。

ただし、認証が通っていない状態そのものは変わりません。認証が通らないメールは、拒否されない代わりに迷惑メールと判定されやすくなります。ポリシーを下げるのは、原因を調べるあいだの一時的な措置と考えてください。SPFかDKIMを通してから、段階的に p=none から p=quarantine、p=reject へ戻すのが本来の手順です。

421 や 451 で返った場合

同じ 4.7.26 でも、先頭が 421 や 451 の場合があります。Googleのコード一覧には次の2つが載っています。

421-4.7.26 This email has been rate limited because it is unauthenticated.
           Gmail requires all senders to authenticate with either SPF or DKIM.

451-4.7.26 Unauthenticated email from domain-name is not accepted due to
           domain's DMARC policy, but temporary DNS failures prevent
           authentication.

先頭が4で始まる応答と5で始まる応答は、意味が違います。RFC 5321 §4.2.1 は次のように定めています。

• 4yz（Transient Negative Completion reply）は「the error condition is temporary, and the action may be requested again」で、送信側は再試行してよい状態です
• 5yz（Permanent Negative Completion reply）は「The SMTP client SHOULD NOT repeat the exact request」で、同じ要求をそのまま繰り返すべきではない状態です

421 や 451 で返っているあいだは、送信側のサーバーが自動で再送を試みます。そのため一部のメールだけ遅れて届いたり、時間をおいて届いたりします。ただし、これは「まだ猶予がある段階」ではありません。421 から 550 へ段階的に進むという規定はGoogleにもRFCにもありません。 設定を変えないまま再試行が成功する保証もないので、原因の切り分けは同じように進めてください。

451-4.7.26 は特殊で、DMARCポリシーによる拒否でありながら、一時的なDNS障害が認証を妨げているケースです。DNSレコードを直した直後にこれが出る場合は、まだ反映されていない可能性があります。確認方法はDNSが反映されないときの確認方法で扱っています。

末尾の数字が違うエラー

5.7.26 以外にも、拒否されたときに返るコードがあります。末尾の数字が違えば原因も違うので、混同しないでください。以下も同じGoogleのコード一覧に掲載されている原文です。

550-5.7.25 はDNSの設定で直せますが、逆引きの設定は使っているサーバーやクラウドの側で行います。ドメインのDNSにレコードを足すのとは別の作業になります。

なお、SPFの仕様は、failを理由にSMTPの途中で拒否する場合、応答コードに 550 と拡張ステータスコード 5.7.1 を使うことを推奨しています（RFC 7208 §8.4）。Gmailはこの状況で 5.7.26 を返しますが、他社のメールサーバーからは 5.7.1 で返ってくることがあります。末尾の数字だけを見て別の問題と判断せず、本文の英文を確認してください。

直したあとに確認する

設定を変えたら、次の順で確認してください。

1. DNSに反映されているかを確認します。追加した直後は、再帰リゾルバのキャッシュが残っていて古い応答が返ることがあります。DNSが反映されないときの確認方法を参照してください
2. Gmailのアドレス宛にテストメールを送ります。問い合わせフォームからの自動返信など、実際に問題が起きている経路と同じ方法で送ってください
3. 届いたメールのヘッダーで Authentication-Results を確認します。spf=pass dkim=pass dmarc=pass のどれが出ているかで、実際の判定結果が分かります

診断ツールで確認できるのは公開されているDNSの設定までです。実際に送ったメールがどう判定されたかは、受け取ったメールのヘッダーを見るまで分かりません。両方を突き合わせることで、設定が意図どおり効いているかを確かめられます。

ドメインを診断する