申請書を出したのに「受け付けられません」と戻された。書き方が悪いのか、窓口が違うのか。まず何を疑うだろうか。
これは、Google Workspaceの導入でよく起きることである（今回は自社の事故ではなく、実務の一般的な話として書く）。メールの認証設定（DKIM）を登録しようとして弾かれる。あるいは保存できたのに、「認証されていません」のまま変わらない。
結論を先に言う。仕様どおりに動いているものを「壊れている」と誤認しないこと。そして、近道のために安全の水準を下げないこと。
設定は間違っていなかった
原因はたいてい、DNS（ドメインの住所録）のTXTレコードにある「1つの文字列は255文字まで」という上限である。2048bitの鍵は、全体で400文字前後になる。管理画面の表示も正しく、DNSも正しい。誤っているのは、「1つの文字列として貼る」という操作だけである。
直し方は、値を複数の文字列に分けて登録することである。DNS側で連結されて、1つの値として扱われる。分け方は途中のどこでもよい。
人の職場なら、こうなる
つまり、ルールを知らないだけで、本人は正しいことをしている。
新人が申請書を戻されたとき、「間違えた」と思い込んで内容を作り直す。実際は、書式の決まりだけの問題だった。ここで責めたり、基準を緩めたりすると、別の問題が生まれる。
近道は、やってはいけない
鍵長を1024bitに下げれば255文字に収まる。しかし、1024bitは強度が不足しているとみなされており、受信側によっては認証が無効と判定される。認証を通すための設定が、認証を通さなくなる。 分割入力は5分で終わる。
最初の1手は、窓口の確認
反映されないときは、次の順で見る。権威DNS（本当に設定を読む窓口）が別のサービスでないか、セレクタ名、ホスト名の二重記載、反映待ちの時間である。
私たちの実務の実感として、最初の1つがいちばん事故が多い。ドメインの取得元、DNSの設定先、サーバーが別々だと、設定画面を開いて保存できているのに、世界からは見えない。画面にエラーは出ない。
たとえば日程調整の依頼を、別の人の窓口に出しても、受理はされるが誰も動かない。それと似ている。
自社で確かめる3つの問い
- 弾かれたとき、自分の誤りか、仕様の制約かを切り分けているか
- 通すために、安全の水準を下げていないか
- 設定を触る前に、本当の窓口がどこかを確認しているか
2つ以上「いいえ」なら、見直す余地があるかもしれない。目安であって実証ではないが、AI診断で確かめてみてほしい。
