認証の設定は足すか整理するか｜参照の回数に上限がある

配信の道具を増やすたびに、認証の設定に一行を追記してきた。ある日から、届かない先が増えた。認証の設定には、参照できる回数の上限があります。上限を超えると、正しく書いてあっても認証そのものが失敗します。この記事では、上限の仕組み、超えているかの確かめ方、そして整理の手順を整理します。

届かない先が増えていく

配信の到達の問題は、段階的に現れます。最初は特定の会社にだけ届かない。次に、大手の受信の提供元で迷惑メールの箱に入る。そして、届かない先の割合が徐々に上がっていきます。この経過は、設定の上限を超えたときの典型的な現れ方です。

担当者は、まず内容を疑います。件名の書き方、本文の中の語、リンクの数。しかし内容を直しても改善しません。原因が送信元の確認の仕組みにあるためです。

次に、認証の設定を確かめます。設定は入っている。書き方も間違っていない。検査の道具で見ても、形式としては正しいと表示される。ここで手が止まります。

止まる理由は、上限という概念を知らないことです。設定が正しいかどうかとは別に、受信側が確認のために行える問い合わせの回数に制限があります。制限を超えると、正しい設定でも失敗として扱われます。

この問題は、成長している会社で起きます。配信の道具を増やし、営業の道具を増やし、問い合わせの道具を増やす。そのたびに設定に追記していくと、いつか必ず上限に達します。

参照の回数という仕組み

送信元の確認は、受信側が行います。届いたメールの送信元の情報を見て、そのドメインの管理者がそこから送ってよいと宣言しているかを確かめます。宣言は、ドメインの名前の情報として公開されています。

宣言の中には、「この一覧も見てください」という指定が書けます。配信の道具の提供元が用意している一覧を参照する形です。自社で個別の番号を書かずに済むため、この書き方が広く使われています。

参照の指定が入っていると、受信側はその一覧を見に行きます。つまり、追加の問い合わせが発生します。参照先の中にさらに参照の指定があれば、その分も発生します。入れ子になっていると、回数が急に増えます。

この問い合わせの回数が、10回までに制限されています。評価は左から順に進み、10回を超えた時点で打ち切られます。打ち切られると、確認できなかったという結果になります。この結果は、受信側の方針によって失敗と同等に扱われます。

制限が設けられている理由は、負荷の抑制です。無制限に参照を辿らせると、受信側の負担が大きくなり、悪用もされます。10回という数は、仕様として定められたものです。こちらの都合で増やすことはできません。

数え方の注意点

何が回数に数えられるかを知っておく必要があります。参照の指定、名前の指定、メールの受け取り先の指定、そして存在の確認の指定が、問い合わせを必要とします。これらが1つあるごとに1回と数えられます。

一方で、番号をそのまま書いた指定は問い合わせを必要としません。回数に数えられないため、番号で直接書けば上限に影響しません。これが、整理の際の重要な手がかりになります。

入れ子の数え方も注意します。参照先の一覧の中に、さらに参照の指定が3つ入っていれば、その3つも回数に加算されます。自社の設定には1行しか書いていなくても、実際には4回になることがあります。

だから、自社の設定の行数を数えても意味がありません。展開した結果の合計を数える必要があります。この計算を手で行うのは大変です。公開されている検査の道具を使えば、展開後の回数を表示してくれます。

検査の道具の結果は、その時点のものです。参照先の一覧は、提供元の側で変わります。今日は9回でも、来月には11回になっていることがあります。自社が何も変えていなくても、突然上限を超えることがあるのです。だから、定期的な確認が必要になります。

指定の種類	問い合わせ	整理の方向
別の一覧の参照	必要（入れ子分も加算）	使っていない道具の分を削る
名前による指定	必要	番号による指定に置き換える
受け取り先による指定	必要	不要なら削る
存在の確認による指定	必要	見直しの対象
番号をそのまま書いた指定	不要	上限を気にせず使える
すべてを表す指定	不要	末尾に置く

空の応答にも別の上限がある

回数の上限とは別に、もうひとつの上限があります。参照した先の名前が存在しなかった場合、あるいは応答が空だった場合。これを空の応答と呼びます。仕様では、空の応答は2回までとされています。3回目に出会った時点で、合計の回数が10回に達していなくても評価は打ち切られます。上限を2つ持っていることが、この仕組みの分かりにくさの原因です。

空の応答が出る原因は、たいてい過去の設定の残りです。使わなくなった名前への参照、綴りを間違えた名前、退役したサーバーの名前。書いた当時は存在していたものが、今は存在しない。設定を消していないので、記述だけが残り続けます。回数に余裕があるのに認証が失敗する場合、まずここを疑います。

厄介なのは、検査の道具の表示の仕方です。回数の合計だけを大きく表示し、空の応答は小さな注記として扱う道具があります。合計が7回と表示されていれば、問題ないと判断してしまう。実際には3回目の空の応答で打ち切られている。道具の出力は、警告の欄まで読む必要があります。

対処は単純で、存在しない名前への参照を削るだけです。削る前に、本当に存在しないかを確かめます。一時的な障害で応答が返らないこともあるためです。日を変えて2回確かめ、どちらも空なら削ってよいと判断します。台帳にその判断と日付を書いておけば、次の担当者が迷いません。判断の根拠を残すことが、この作業の価値を長持ちさせます。

宣言を2つ書くと失敗する

参照の回数とは別に、記述そのものの数にも決まりがあります。1つのドメインに対して、送信元の宣言は1つだけです。2つ以上見つかった場合、内容を評価する前に失敗と判定されます。これは仕様に明記された扱いで、受信側の裁量ではありません。回数を整理しても直らない失敗の、もうひとつの原因がこれです。

2つになる経緯は、たいてい同じです。新しい配信の道具を導入すると、提供元から「この記述をドメインの情報に追加してください」という案内が届く。案内どおりに追加すると、既存の宣言とは別に、もう1つの宣言ができてしまいます。追加した側は正しく作業したつもりでいます。既存の宣言があることを知らされていないためです。

正しい対処は、既存の宣言の中に参照を足すことです。新しい行を作るのではなく、1行の中に参照を並べる。並べる順番は評価の順番でもあります。よく使う道具を前に置くと、途中で打ち切られたときの影響を減らせます。作業の依頼を出すときは、追加ではなく編集だと明記します。

確かめ方は、道具の出力の中の記述の一覧を見ることです。宣言が2つあれば、2行が並んで表示されます。この確認は、道具を追加した直後に必ず行います。追加の作業と確認の作業を別の担当が行うと、見落としが起きにくくなります。台帳には、そのとき何行あったかも書いておきます。行が増えていれば、直前の作業が原因だと分かります。

超えているかを確かめる

確かめ方は簡単です。公開されている検査の道具に自社のドメインを入れると、展開後の問い合わせの回数が表示されます。上限を超えていれば、その旨の警告も出ます。

複数の道具で確かめるのが安全です。道具によって数え方の実装に差があることがあります。2つ以上の道具で同じ結果が出れば、信頼できます。結果は画面の写しで保存しておきます。

配信に使っているドメインが複数ある場合は、すべてについて確かめます。本体のドメイン、配信専用のドメイン、取引の連絡に使うドメイン。それぞれ別に設定されているため、別に確認が必要です。

上限に近い状態も、問題として扱います。9回や10回ちょうどの状態は、参照先の変更ですぐに超えます。余裕として2回か3回を残しておくのが実務的な目安です。つまり、7回程度に収めておく。

確認の頻度は、四半期に一度を目安にします。道具を追加したときは、その都度確認します。追加の作業の手順に、確認の項目を入れておけば忘れません。

整理の手順

上限を超えている場合、あるいは近づいている場合の整理の方法は3つあります。不要な参照を削る、番号で直接書く、ドメインを分ける。この順に検討します。

最も効くのは、削ることです。使っていない道具の参照が残っていることが多いのです。契約を終えた配信の道具、使わなくなった問い合わせのフォーム、試しに導入して定着しなかった道具。これらの参照が残り続けています。

削る前に、本当に使っていないかを確かめます。削った結果、現役の道具からの送信が失敗するのは最悪の事態です。設定の台帳を作り、各参照がどの道具のためのものかを記録します。台帳がなければ、削る判断ができません。

次の手が、番号で直接書くことです。参照先の一覧が実際に含んでいる番号を調べ、その番号を自社の設定に直接書く。番号は問い合わせを必要としないため、上限に影響しません。ただし、この方法には保守の負担があります。

番号が変わったときに、自社の設定も直す必要があるからです。提供元が番号を変えても、こちらには通知されません。気づかないうちに、送信が失敗するようになります。この方法を取るなら、定期的な確認が必須になります。

展開を自動で更新する仕組み

番号を直接書く方法の負担を減らす仕組みもあります。参照先の一覧を定期的に調べ、展開後の番号の一覧を自動で更新してくれる外部の仕組みです。有料の道具として提供されています。

この仕組みを使えば、上限の問題を回避しつつ保守の手間も抑えられます。配信の道具が多い会社では、検討に値する選択肢です。費用と手間を比べて判断します。

ただし、外部の仕組みに依存することになります。その仕組みが停止すると、認証の設定が古い状態のまま残ることになります。提供元の信頼性と、停止時の対応を確かめておきます。

導入の判断は、配信の道具の数と変更の頻度で決めます。道具が3つか4つで安定しているなら、手作業の管理で足ります。10を超え、頻繁に入れ替わるなら、自動化の価値が出てきます。

導入する場合も、台帳は作ります。自動化しても、どの道具のためにどの参照が必要かは記録しておく必要があります。台帳がなければ、道具を解約したときに参照を消せません。

ドメインを分けるという設計

三つめの手が、送信の用途ごとにドメインを分けることです。配信の案内は配信用のドメインから、取引の連絡は本体のドメインから送る。それぞれのドメインの設定を小さく保てます。

分けることには、別の利点もあります。配信の評判が悪化しても、取引の連絡には影響しません。逆に、取引の連絡が確実に届く状態を守れます。この分離は、到達の管理の基本の考え方でもあります。

分けるときは、配信用のドメインを本体の下に作る形が一般的です。本体のドメインとの関係が示せるため、受け取る側にも自社からの送信だと分かります。まったく別のドメインを取ると、その関係が見えません。

新しいドメインからの送信は、評判がゼロの状態から始まります。急に大量に送ると、迷惑メールと判定されやすくなります。少量から始めて徐々に増やす作業が必要です。この作業には数週間かかります。

分ける判断は、時間をかけて行います。設定の整理だけで上限を下回るなら、分ける必要はありません。整理しても収まらない場合、あるいは評判の分離が必要な場合に検討します。

5つの工程で整える

確認から整理までの流れを整理します。削る前に台帳を作る順番にしておきます。

台帳に書く項目

台帳は、この作業の中心になります。1つの参照について、1行を書きます。項目は6つあれば足ります。

• 参照の記述そのもの（設定に書かれている文字列）
• どの道具や仕組みのために必要か
• その道具の契約の状態と担当の部署
• 追加した日と追加した担当者
• 削ってよいかの判断と、判断した日
• その参照が消費している問い合わせの回数

最後の項目があると、どれを削れば何回減るかが分かります。入れ子が深い参照は、1つ削るだけで3回や4回減ることがあります。優先して検討すべき対象が見えます。

台帳の置き場所も決めておきます。ドメインの名前の情報を扱う部門と、配信の道具を選ぶ部門は、たいてい別です。片方だけが見られる場所に置くと、更新が止まります。両方が編集できる共有の場所に1つだけ置き、複製を作らない。複製ができた時点で、どちらが正しいか分からなくなります。

更新のきっかけも書き添えておきます。道具を追加したとき、契約を終えたとき、四半期の確認をしたとき。この3つのときに台帳を開くと決めておけば、内容が古びません。開いた日と開いた人を1行足すだけでも、放置されている期間が見えるようになります。見えれば、確認を促す理由になります。

道具を追加するときの手順

新しい道具を導入するとき、認証の設定に追記する作業が発生します。この作業の前に、現在の回数を測る手順を入れておきます。測らずに追記すると、上限を超えてから気づくことになります。

追記の前に測り、追記した後にも測る。2回測れば、その道具が何回消費したかが分かります。台帳に書く数字も、この測定から得られます。

上限に近い状態で新しい道具を導入する場合は、先に整理を行います。整理せずに追記すると、既存の配信が止まります。導入の予定に、整理の期間を組み込んでおきます。

道具の選定の段階で確かめる方法もあります。提供元に、参照の指定がいくつの問い合わせを消費するかを尋ねる。答えられない提供元もありますが、尋ねる価値はあります。

解約のときの手順も決めておきます。契約を終えたら、認証の設定からその参照を削る。解約の手続きの一覧に、この項目を入れておきます。入れておかないと、参照が残り続けます。

逆引きに頼る指定は使わない

指定の種類の中に、送信元の番号から名前を引き直して照合するものがあります。仕様では、この指定を公開すべきではないとされています。受信側の負担が大きく、結果も安定しないためです。回数を1回消費するうえに、空の応答にもなりやすい。古い設定の中に残っていることが多い指定です。

残っている理由は、昔の案内が広まったことです。かつては、この指定を書けば自社のサーバーからの送信をまとめて許可できると説明されていました。今の仕様では推奨されません。受信側によっては、この指定を無視する実装もあります。無視されれば、許可したつもりの送信が許可されません。

置き換え先は、番号をそのまま書く指定です。自社のサーバーの番号は、めったに変わりません。変わったときに直す手順さえ決めておけば、番号で書くほうが確実です。番号は回数を消費しないため、上限の余裕も増えます。1つの指定を置き換えるだけで、回数と空の応答の両方が減ります。

置き換えの作業は、送信の実態を確かめてから行います。その指定に頼って送っている経路がないかを、送信の記録で確かめる。確かめずに削ると、社内のサーバーからの通知が届かなくなります。削る前と後で、実際にメールを送って認証の結果を見る。この確認を省くと、気づくのは数日後の問い合わせになります。作業の当日に確認まで終える段取りにしておきます。

他の認証の仕組みとの関係

送信元の確認には、複数の仕組みがあります。今回の上限は、そのうち番号の一覧を照合する仕組みに固有のものです。署名を使う仕組みには、この上限はありません。

署名を使う仕組みは、メールに電子的な署名を付け、受信側がその署名を確かめる方式です。参照の入れ子が発生しないため、道具が増えても上限の問題は起きません。

ただし、署名の仕組みも設定は必要です。道具ごとに署名の鍵を用意し、ドメインの名前の情報に登録します。こちらは登録の数に実務上の上限がないため、増やしても問題になりません。

両方を設定しておくのが基本です。受信側の方針によって、どちらを見るかが変わります。片方だけだと、特定の受信の提供元で失敗することがあります。

三つめの仕組みとして、この2つの結果をどう扱うかを宣言する仕組みもあります。この宣言も、参照の回数とは別のものです。3つを揃えるのが現在の標準的な設定になっています。

よくある失敗

この領域で繰り返される失敗を挙げます。どれも台帳と定期の確認で防げます。

• 道具を追加するたびに追記し、いつのまにか上限を超えていた
• 自社の設定の行数だけを見て、入れ子の分を数えていなかった
• 契約を終えた道具の参照が残り続けていた
• どの参照がどの道具のためか分からず、削る判断ができなかった
• 番号を直接書いたが、提供元が番号を変えたことに気づかなかった
• 本体のドメインだけを確かめ、配信用のドメインを見ていなかった
• 整理せずに新しい道具を追加し、既存の配信が止まった

4つめの型が、対応を最も長引かせます。台帳がないと、消してよいかの判断に関係部署への確認が必要になります。確認に数週間かかることもあります。追記する時点で1行書いておけば、この時間は不要になります。

社内の運用に落とす

この作業は、担当者が替わると引き継がれにくいものです。ドメインの名前の情報の設定は、情報の部門が管理していることが多く、マーケティングの側から見えません。だから、台帳を共有の場所に置く意味があります。

• 上限の回数や数え方の詳細は仕様として定められています。実装の前に公式の資料で確かめてください
• 設定の変更は配信の到達に直結します。変更の前に現在の状態を保存し、段階的に行います
• ドメインの名前の情報の設定は情報の部門が管理していることが多いため、作業の分担を事前に決めます

運用に組み込む項目は3つです。道具の追加のときに測る。解約のときに削る。四半期に一度測る。この3つを手順書に書けば、上限の問題は起きなくなります。

まとめ

送信元の確認のために受信側が行う問い合わせは、10回までに制限されています。上限を超えると評価が打ち切られ、認証は失敗として扱われます。自社の設定の行数ではなく、入れ子を展開した合計が対象です。参照先は提供元の側で変わるため、自社が何もしなくても超えることがあります。まず検査の道具で展開後の回数を測り、各参照がどの道具のためのものかを台帳に書いてください。そのうえで使っていない参照を削り、7回程度に収める。道具の追加と解約の手順に、測ることと削ることを組み込めば再発しません。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。