スキップしてメイン コンテンツに移動

iCloudに移行するための作業(1/27までの作業:DNS設定)

 iCloud+ 50GBプラン契約してしまった・・・

というわけで、カスタムメールドメインの追加を始めましたよ。

DNSにはメールサーバーを指定するMXレコードとドメイン認証用のTXTレコード、SPFとDKIM用レコードの5行追加です。

現時点ではGsuiteアカウントでメールしたいのでMXとSPFは変更を加えて登録してみた。

MXレコードはGoogle向けより優先順をさげて登録。

既存の設定
MX ASPMX.L.GOOGLE.COM         10
MX ALT2.ASPMX.L.GOOGLE.COM 20
MX ALT1.ASPMX.L.GOOGLE.COM 20
MX ASPMX3.GOOGLEMAIL.COM   30
MX ASPMX5.GOOGLEMAIL.COM   30
MX ASPMX2.GOOGLEMAIL.COM   30
MX ASPMX4.GOOGLEMAIL.COM   30
今回の設定(優先順は10から100に変更)
MX mx01.mail.icloud.COM 100
MX mx02.mail.icloud.COM 100

SPFの指定はredirectだけどincludeで登録。

TXT "v=spf1 include:_spf.google.com include:icloud.com ~all"

まだ切替は先という場合はこのような設定になると思います。
iCloudのチェックはMXの存在と認証用TXTレコードくらいしかしないだろうと思てたんですけど甘かったです。うまくいきませんでした。

MXレコードのチェック

指定した2行以外の応答があるとNGと判断するようです。

MXレコードは優先順位を指定の10に変更してもPassできない。
Google用レコードを消すとPassできました。

もちろん、この設定をしている間に届いたメールはiCloud側に届いてしまいました。

SPFレコードのチェックも完全一致要求されました。
SPFはGsuiteアカウントからも送信する可能性があるのでredirectではなくincludeに変更してたのですがNG判断されました。仕様上はこれが正しいはずなんですけどね~

指定されたレコードに置き換える前に、DMARCのポリシーをrejectからnoneに変更しました。この変更をしておかないとメール破棄されますね。


カスタムドメインメールを使うような利用者は逸般の誤家庭だと思うので、MXレコードは無視してほしかったな~と思う。法人の立場だと、移行先サーバーの事前設定のフェーズではMXレコードは複数存在することは当たり前だし、なんだかな~という感じです。

たぶん、メールサーバーのお引越しは想定していないんでしょうね~


あと、ファミリー共有としてドメイン追加したけど、ファミリーのアカウントは制御できないんだね~。設定が終わったら自分のアカウントしか表示されていなくて、あれ?選択失敗した?と思た。

カスタムドメインアカウントの制御くらいは出来てほしかったけど。


現在は、カスタムドメインの設定が終わったのでMXレコードを元に戻してiCloudは低優先にしたのでGoogle様が停止しなければカスタムドメイン側には届かない状態です。

メールヘッダー等をチェックして問題なければ、切替日を決めようと思う。

コメント

このブログの人気の投稿

SharePoint アイテム保管ライブラリをのぞいてみよう

Office 365 Advent Calendar 2021  の12月16日投稿です。 警告: 個人的な理解に基づく内容、表現です。疑いを持って取り扱ってください。 SharePoint と OneDrive の保持の詳細 - Microsoft 365 Compliance | Microsoft Docs SharePoint Onlineをご利用の方にとっては普通?の機能ですが、SharePoint Server 2010以前から利用している方にとっては2013からの新機能「インプレース保持」で使われる「アイテム保管ライブラリ」をちょっとのぞいてみようという内容です。 Exchangeのインプレース保持とSharePointの保持は違うよ~ Exchange のインプレース保持はごみ箱から消えたメッセージを含むすべてを保持することができるのですが、SharePointでは対象外アイテムが存在しますし、編集についてはバージョン履歴に依存しています。また、情報管理ポリシーの「ごみ箱に移動する」が動作しなくなるなど利用者への影響もありますので注意が必要です。また、保持してることを内緒にしたくてもサイト管理者にはバレバレな点は認識しておかないとね。あとE3相当以上の方はExchangeは容量無制限ですけど、SharePointはしっかりと契約容量に含まれているので上司の方から説明のたびに叱られる可能性がありますね。 SharePointの保持は、Exchangeが連携して利用する大容量添付ファイル送信やTeamsメッセージの添付ファイルを保持する目的のために存在する機能なのかな~という感じがします。SharePointの情報調査や監査という意味では、バックアップ製品などでこまめに世代管理する必要があると感じます。 SharePointで削除されたアイテムは各サイトの「アイテム保管ライブラリ」にコピーされ設定期間保持されます。 各サイトというのがミソですね。しかも、サイト管理者から参照可能な場所に保持されるため、保持について理解のないサイト管理者はこのライブラリのアイテムURLを見ることができないユーザーに渡すなど困った行動を起こす可能性があります。 それでは保持を確認するために保持されるアイテムを準備します。 そうそう、アイテム保持ポリシーの対象にするのを忘れない

あけまして

コロナから始まり、コロナに終わる。 今年は別の話題で終わると良いですね。 モーそろそろアフターコロナになりたいな〜と思います。  今日は何人でした。とかね、なんか昭和最後の年末年始をちょっと思い出す。 なんだかな〜って感じですね。

1000ユーザーの役職情報を削除しなさい

ActiveDirectoryを管理していると、「1,000ユーザーの役職情報を削除しなさい」なんてオーダーが出る可能性はある。 理由は何でもいい。似たような状況に置かれたと考えてほしい。 Q.急いでいるんだけど、いつまでに完了できる? A.ん~~1ユーザー30秒かからないとして500分程度。大体8時間  ちょっと残業すれば今日中に終わると思います。 これ、あなたの答えですか? 先日までは私の答えもこれだったかもしれません。 でも、今の私なら、「それなら30分くらいもらえれば終わります」(余裕) なぜなら私にはPowerShellという武器があるから。 まぁ、以前から便利なのは知ってたんですけどね、使う機会がなくてスクリプトとしては使っていなかったんですよ。やっても「Export-SPWeb」みたいな単発の命令ばっかりで~ じゃぁ、スクリプトっぽくいくよ~ Import-Module ActiveDirectory $users = Get-ADUser -Filter * ForEarch($user in $users) { Set-ADUser -Identity $user -Clear Title } あとはActiveDirectoryを編集できる権限で実行するだけ。 5分で書いて1分実行。 ついでに確認用のコマンドをちょっと打って まぁ、20分は忙しそうなふりして遊びましょうか? 本当に動かすときは、編集対象に問題がないかとか、ちゃんと編集できた確認とか やるべきことは色々あるけど、たった6行・・・ いや、最小限でいよく Import-Module ActiveDirectory Get-ADUser -Filter * | Set-ADUser -Clear Title 2行で終わるかも・・・ つぶしてもいい環境だったらこれでいいよね。 PowerShellの何がすごいかって、 今までの方法だと、サーバーに接続して・・・って言語すらまともに使えないのに~ って感じだったのが、それぞれのコマンドが勝手に必要な手順をこなしてくれるんですよね。 スクリプトやプログラム言語でActiveDirectoryからユーザー一覧を取得する。 これだけでも結構な行数のプログラムを書かなければならなかった?わけなんですが、 Get-ADuser -Filter