📬

GoogleAppsScriptではMailAppではなく素直にGmailAppを使いましょう

2025/11/10に公開

GASではメール配信用にMailApp/GmailAppという二つの標準サービスが存在している。どちらもライブラリ設定もいらず、コードに書いてあればそのまま使える機能である。
タイトルにもあるように、レポート報告用に外部メール通知機能をMailAppで記載したところ、組織外ドメインではバウンスが発生。これに困って色々調べた結果、最終的にはシンプルにGmailAppへと書き換えをしたところ、スムーズにメール送信が完了した。
今回の件で、MailApp/GmailAppやドメイン認証の仕組みであるDMARCについても理解が深まったので、備忘として記録を残していく。

 MailAppとGmailAppどっちがいいの？GAS標準で利用可能なメールサービスの特徴と使い分けについては、以下の通り。

タイトルにもあるように、実務上はGmailAppを使えるならそちらを優先すべき。


項目
MailApp
GmailApp


送信経路
Googleの共有サーバーを使用して匿名的に送信
スクリプト実行ユーザーの Gmail アカウントを直接使用

メリット
- 基本的なメール送信が可能
 - スコープが狭く、権限付与が最小限で済む


- 確実な外部送信が可能
 - エイリアス（別名アドレス）や - HTML メール、添付ファイルなど高度な送信が可能



デメリット
- 外部サーバーでバウンスしやすい
- 広範なユーザー権限付与が必要



MailApp は、最小限の権限で「とりあえずメールを流す」ことを目的に設計されたシンプルな通信手段。そのため、セキュリティチェックの厳しい外部サーバーから見ると、匿名的な送信元と判断され、拒否（バウンス）されやすくなる。
GmailApp は、ユーザーの本人認証済みのメールボックス（送信トレイ）からメールを出すため、送信元としての信頼性が高く、バウンスのリスクが低減する。その代わり、利用するためにはユーザーのGmail データ全体にアクセスするための広範な権限を許可する必要があり。
今回の件、当初はMailAppを利用したのも「Gmail利用権限付与で仰々しい承認UIが出ないから」というシンプルな理由から。導線シンプルにしたほうが、ユーザーへの説明や問い合わせ対応が減るかなと考えたから。
メールの宛先が同一ドメインで完全内部レポート用だとか、権限管理が厳しくてどうしてもgmailデータアクセスの権限が付与できない場合はMailAppを使うことも視野に入れてもよいですが、そうでないならば、GmailAppを使うほうがトラブルは起きづらいはず。

 一体なぜバウンスされたのか前述のとおり、MailApp経由のメールは外部送信すると拒否されてしまったわけだが、その背景にはDMARC (Domain-based Message Authentication, Reporting, and Conformance) という仕組みが存在する。さらにDMARCは、SPFとDKIMという2つの認証結果を活用し、最終的な処理（アクション）を決定する監督者のような役割である。
そのため、まずは認証実務を担うSPFとDKIMについて理解しなければならない。
両者はどちらも「なりすましメール」を防ぐための認証技術だが、何を検証するかが根本的に異なっている。


認証技術
検証対象
仕組みのイメージ


SPF (Sender Policy Framework)
送信元IPアドレスの正当性
郵便の「差出人住所」が、その住所を名乗ることを許可されたリストにあるか確認。

DKIM (DomainKeys Identified Mail)
メールの内容の正当性
郵便の「封筒」に、ドメイン（差出人）が付けた電子署名があり、途中で改ざんされていないか確認。


 SPF（送信元IPアドレスの検証）
送信者側の設定: 送信ドメインの管理者は、DNSサーバーにSPFレコードという特別なテキストレコードを公開する。
SPFレコード: このレコードには、「このドメインのメールは、リストに記載されたIPアドレスを持つメールサーバーからのみ送信を許可する」という情報が記述されている。
受信者側の検証: メールを受信したサーバーは、メールのヘッダーにある エンベロープ From（Return-Path）のドメインを確認し、そのドメインの SPFレコードを DNS に問い合わせする。
認証: 実際にメールを送ってきたサーバーの IPアドレスが、SPFレコードの許可リストに含まれていれば Pass (合格) となる。

 DKIM（電子署名による検証）
送信者側の設定: 送信ドメインの管理者は、公開鍵を DNS サーバーに登録し、秘密鍵をメール送信サーバーに保管。
署名の付与: 送信サーバーは、秘密鍵を使ってメールヘッダーと本文の一部を暗号化し、その暗号化されたデータ（電子署名）をメールのヘッダーに付与。
受信者側の検証: メールを受信したサーバーは、ヘッダーの署名を確認し、署名に使われたドメインの公開鍵を DNS に問い合わせ。
認証: 公開鍵で電子署名を復号し、元のメールの内容と一致すれば Pass (合格) となります。一致しない場合（改ざんされた場合など）は Fail (不合格) となる。

 DMARCとSPF/DKIMの関係DMARCは、SPF と DKIM の認証結果を活用し、最終的な処理（アクション）を決定するための枠組みです。
アライメント (Alignment) チェック: DMARC の最も重要な機能は、SPF または DKIM の認証に使用されたドメインと、ユーザーがメールソフトで確認する From アドレスのドメインが一致しているか（アライメント）を確認する。
ポリシー設定: 送信ドメインの管理者は、DMARC ポリシーを DNS に公開し、「SPFとDKIMのアライメントチェックに失敗したメールをどう処理するか」を受信者に指示。ポリシーには主に以下の3つがあります。
p=none: 何もせず、レポートを送信者に送る。
p=quarantine: 迷惑メールフォルダに入れる（隔離）。
p=reject: 受信を拒否する（バウンスさせる）。
レポート機能: DMARC は、認証に失敗したメールがどこから送られてきたかなどの詳細なレポートを、送信ドメインの管理者に送信（DSNレポート）。これにより、なりすましの実態把握や認証設定の改善が可能になる。
結論として、SPF と DKIM は個々の認証の「道具」であり、DMARC はそれらの道具の結果を総合して、「このメールを受け取るか、捨てるか、どう処理するか」を最終的に判断・制御する「ルールブック」の役割を果たす。

 調査でお世話になったツール今回の調査にあたり活用したツールたちについても触れておく。
Email log search
Google work spaceのアドミン権限で管理画面よりアクセス
対象メールを選択すると、送信状況がチェックできる
SPFレコードチェックツール

mxtoolbox.comを利用
インターネット上に公開されているDNS情報としてSPFレコードを手軽に確認
DMARC集計レポート
カスタムレコードとしてDNSへレコード登録する際に、データ"v=DMARC1; p=none; rua=mailto:admin@example.com"と設定
バウンスされた場合、admin@example.comへ下記のようなリジェクト理由のレポートが飛んでくる
<feedback>
  <version>1.0</version>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <extra_contact_info>https://support.google.com/a/answer/2466580</extra_contact_info>
    <report_id>7457835210456705671</report_id>
    <date_range>
      <begin>1762387200</begin>
      <end>1762473599</end>
    </date_range>
  </report_metadata>

  <policy_published>
    <domain>sample.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
    <np>none</np>
  </policy_published>

  <record>
    <row>
      <source_ip>209.85.222.44</source_ip>
      <count>1</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>

    <identifiers>
      <header_from>sample.com</header_from>
    </identifiers>

    <auth_results>
      <dkim>
        <domain>sample.com</domain>
        <result>pass</result>
        <selector>google</selector>
      </dkim>
      <spf>
        <domain>sample.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

 まとめ意図せずMailAppを使ったことにより、冒頭で書いたように素直にGmailAppを使っていくべきだというノウハウとメール認証技術について知見を得られたので、まぁよい経験だった。
いつかここぞという場面であえてMailAppを選択肢に提示できる開発者に私はなりたい。

 参考Google Work Space Admin Help: Email sender guidelines
Gmail Help: Fix bounced or rejected emails

項目	MailApp	GmailApp
送信経路	Googleの共有サーバーを使用して匿名的に送信	スクリプト実行ユーザーの Gmail アカウントを直接使用
メリット	- 基本的なメール送信が可能 - スコープが狭く、権限付与が最小限で済む	- 確実な外部送信が可能 - エイリアス（別名アドレス）や - HTML メール、添付ファイルなど高度な送信が可能
デメリット	- 外部サーバーでバウンスしやすい	- 広範なユーザー権限付与が必要

認証技術	検証対象	仕組みのイメージ
SPF (Sender Policy Framework)	送信元IPアドレスの正当性	郵便の「差出人住所」が、その住所を名乗ることを許可されたリストにあるか確認。
DKIM (DomainKeys Identified Mail)	メールの内容の正当性	郵便の「封筒」に、ドメイン（差出人）が付けた電子署名があり、途中で改ざんされていないか確認。

MailAppとGmailAppどっちがいいの？

一体なぜバウンスされたのか

SPF（送信元IPアドレスの検証）

DKIM（電子署名による検証）

DMARCとSPF/DKIMの関係

調査でお世話になったツール

まとめ

参考

Discussion