セキュリティーの問題がクリアできれば、独自ドメインでメールアドレス（サーバー）を運用するのにGoogle Apps（Gmail）を利用しない理由はないと思います。
無料版であるStandard Editionでは
- 無料（広告が表示されるだけ） で1アカウント7GBのメールボックスが独自ドメインで作成できる
- 50アカウントまで作成可能
- Gmailと同じUI、同等の機能（検索、スパムフィルター、POP/IMAP対応、携帯・iPhone対応など）
といった目に見える特徴と、なんと言ってもサーバーを保守する必要がないという絶大なメリットがあります。
そこで、メールサーバーとしてGoogle Appsを利用する際に行った設定（主にDNS）と、自戒を込めて、アプリケーションサーバーでメールを送信する場合のポイントを書きたいと思います。
※Google Apps の導入手順のステップ 4: ユーザー アカウントの作成以降の説明となります。
MXレコードを設定する
利用するドメインを管理しているDNSサーバーにMXレコードを追加します。
MX レコードの設定 – Google Apps ヘルプに設定すべきメールサーバーと、プライオリティーが記されているので、この通り設定します。cloudropではxxxxxx@cloudrop.jpというメールアドレスを利用するので、cloudrop.jpに対してMXレコードを以下のように設定しました。
bindの設定ファイル
cloudrop.jp. 900 IN MX 1 aspmx.l.google.com. cloudrop.jp. 900 IN MX 5 alt1.aspmx.l.google.com. cloudrop.jp. 900 IN MX 5 alt2.aspmx.l.google.com. cloudrop.jp. 900 IN MX 10 aspmx2.googlemail.com. cloudrop.jp. 900 IN MX 10 aspmx3.googlemail.com.
上記ヘルプはたびたび更新されていて、参考にしたタイミングによっては載っているプライオリティーの値やサーバーのアドレスが増減していることがあるようです。サーバーのアドレスがいきなり変わることはないと思いますが、リスクを考えてTTLはなるべく少なくして運用します。
メールサーバーの台数を見ても、同じように自前で5台用意して運用するコストを考えると、メリットは歴然ですね。
ちなみに、digコマンドを利用するとメールサーバーにGoogle Appsを利用しているかどうかがわかります。例えば、有名な事例となっている東急ハンズのドメインを引いてみると
dig tokyu-hands.co.jp MX ; <<>> DiG 9.6.0-APPLE-P2 <<>> tokyu-hands.co.jp MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54632 ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 3, ADDITIONAL: 5 ;; QUESTION SECTION: ;tokyu-hands.co.jp. IN MX ;; ANSWER SECTION: tokyu-hands.co.jp. 900 IN MX 5 ALT1.ASPMX.L.GOOGLE.COM. tokyu-hands.co.jp. 900 IN MX 5 ALT2.ASPMX.L.GOOGLE.COM. tokyu-hands.co.jp. 900 IN MX 10 ASPMX2.GOOGLEMAIL.COM. tokyu-hands.co.jp. 900 IN MX 10 ASPMX3.GOOGLEMAIL.COM. tokyu-hands.co.jp. 900 IN MX 1 ASPMX.L.GOOGLE.COM. ;; AUTHORITY SECTION: tokyu-hands.co.jp. 900 IN NS ns02.tokyu-hands.co.jp. tokyu-hands.co.jp. 900 IN NS dns2.broadcenter.jp. tokyu-hands.co.jp. 900 IN NS ns01.tokyu-hands.co.jp. ;; ADDITIONAL SECTION: ASPMX.L.GOOGLE.COM. 131 IN A 209.85.223.23 ALT1.ASPMX.L.GOOGLE.COM. 127 IN A 209.85.210.80 ALT2.ASPMX.L.GOOGLE.COM. 211 IN A 74.125.93.114 ASPMX2.GOOGLEMAIL.COM. 858 IN A 209.85.135.27 ns02.tokyu-hands.co.jp. 900 IN A 59.84.175.199
と、TTL900でGoogle AppsのMXレコードが５つ設定されているのがわかります。
SPFレコードを設定する
次に、SPFレコードを設定します。
SPFレコードについては、
が詳しいので、ご覧下さい。
この設定をしておくとことで、スパムフィルターに引っかかる確率が下がります。
SPF レコードの設定に詳細が載っていて、DNSのTXTレコードに設定をすれば済むのですが、そのドメイン内で何かしらサービスを動かしている場合、Gmailのサーバー以外からメールを送る可能性があるので、そのサーバーのアドレスも合わせてSPFレコードに登録するべきです。
例えば、Web上から入力されたフォームをinfo宛にメールで飛ばしたり、各サーバーでLogwatchのレポートメールを飛ばしたりする場合です。
cloudrop.jpでは、アプリケーションサーバー（67.23.44.103）も@cloudrop.jpとしてメールを送信するので、以下の設定をしています。
bindの設定ファイル
cloudrop.jp. 600 IN TXT "v=spf1 ip4:67.23.44.103 include:aspmx.googlemail.com ~all"
これを設定することで、アプリケーションサーバーが送信するメールのヘッダーが以下のように変ります（Gmailの場合）。
設定前
Received-SPF: neutral (google.com: 67.23.44.103 is neither permitted nor denied by best guess record for domain of example@cloudrop.jp) client-ip=67.23.44.103; Authentication-Results: mx.google.com; spf=neutral (google.com: 67.23.44.103 is neither permitted nor denied by best guess record for domain of example@cloudrop.jp) smtp.mail=example@cloudrop.jp
設定後
Received-SPF: pass (google.com: domain of example@cloudrop.jp designates 67.23.44.103 as permitted sender) client-ip=67.23.44.103; Authentication-Results: mx.google.com; spf=pass (google.com: domain of example@cloudrop.jp designates 67.23.44.103 as permitted sender) smtp.mail=example@cloudrop.jp
MTAの設定（Postfix）
後はアプリケーションサーバーのMTAの設定です。
サーバー導入当初、Postfixの設定を間違えてメールが配送されないというミスをしてしまったので、自戒を込めて。
Postfixは受け取ったメールの送信先ドメインが/etc/postfix/main.cfの$mydestinationに設定したドメイン（FQDN）のリストに含まれているかどうかを判定します。含まれていた場合は自分自身のユーザーへ配信、含まれていない場合は該当するサーバーまで配送します。
Google Appsで設定したドメイン宛のメールはGmailのサーバーへ配送しなければいけないので、$mydestinationに含んではいけません。Google Appsに限らずメールゲートウェイでないサーバーでは当たり前の設定なんですが…。
Gmailにrelayするという選択肢
いちいちSPFレコードを追加するのも面倒くさいし、いっそのことGmailのサーバーへrelayしてしまえばいいという考えもあります。Postfixでは設定ファイルに数行追加し、パスワードファイルを作成することで簡単にrelayさせることができます。
Postfixの設定ファイルに追加します。（以下、CentOS5の場合）
> sudo vi /etc/postfix/main.cf relayhost = [smtp.gmail.com]:587 smtp_use_tls = yes smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd smtp_sasl_tls_security_options = noanonymous
設定ファイルで追加したパスワードファイルを作成し、ハッシュ化します。
> sudo vi /etc/postfix/sasl_passwd [smtp.gmail.com]:587 example@cloudrop.jp:password > sudo postmap /etc/postfix/sasl_passwd > sudo /etc/init.d/postfix restart
（ハッシュ化するとsasl_passwd.dbというファイルが生成されます。）
参考サイト
この設定を行うと自サーバーから送信することはなくなるのですが、Gmailの仕様に引っ張られてしまい、使いにくい面が多々あります。
まず、送信元がGmailのアカウントに上書きされてしまいます。例えば、example@cloudrop.jpというアドレス所有者としてrelayした場合、envelope fromをinfo@cloudrop.jpで送信したとしても、example@cloudrop.jpに上書きされ送信されてしまいます。アプリケーションや用途によって送信元を変えたいのが普通ですので、この仕様では使いにくいところです。
また、relayしたメールは該当メールアドレスのGmail送信箱に保存されていきます。1ユーザーのアカウントでrelay設定をした場合、システムが送ったものと人間が送ったものが混ざってしまうということです。
逆に、システム専用のアドレスを用意し、そのアドレスでrelayすればGmailの送信箱にメールが残り、検索しやすくなるなどのメリットもありそうですが、そのサーバーが送信するメールの送信元が全てrelayしたユーザーのアドレスになることを前提にシステムを構築しないといけませんし、Gmailで検索するのにシステム専用のアカウントでログインする必要があるなど、やはり使いにくさは否めません。
Gmailのメリットを享受しようとするならば、Gmailの自分宛にCC（BCC）してラベルを付けるなどした方が楽で、残念ながらrelayして活用するメリットはなさそうです。
