BtoB EC通知メールの設計と運用｜法令要件と設計手順

◆監修・編集責任者　小園 将隆　2026年8月26日

B2B EC-COLUMN

BtoB EC通知メールの設計とは、法的性質の確定から始まる業務設計

BtoB EC通知メールの設計・運用とは、受注から出荷・請求までの各イベントで送るメールの法的性質（広告規制・保存義務・契約の意思表示）を確定する業務です。そのうえで宛先・記載項目・到達性まで一貫して設計します。国税庁の一問一答は、メール本文に取引情報が記載されている場合、当該メールの保存を義務づけています^*1。

文例を書く前に決める3つのこと

通知メールのテンプレートを作る前に、決めるべきことが3つあります。第一に、そのメールの法的性質です。広告規制がかかるのか、保存義務があるのか、契約の意思表示にあたるのかを先に切り分けます。

第二に宛先です。BtoB ECは発注者・承認者・経理・納品先担当が別人であることが珍しくありません。第三にイベント範囲、つまりどこまで自動送信すべきかという線引きです。この3点を決めずに文例集から書き始めると、後から法的性質があいまいなメールが量産されます。

特定電子メール法・電子帳簿保存法・民法という3層の法令

BtoB EC通知メールには、性質の異なる3層の法令がかかります。層①は特定電子メール法で、広告・宣伝の内容を含むかどうかで適用が分かれます^*2。層②は電子帳簿保存法で、本文に取引情報があるかどうかで保存義務が決まります^*1。

層③は民法と経済産業省の準則で、そのメールが契約の承諾にあたるかどうかを扱います^*4*5。3層は互いに独立しており、同じメールが複数の層に同時にかかることもあります。この整理を先に持っておくと、以降の設計判断が速くなります。

法的性質の確定からイベント定義・宛先設計・記載項目・到達性・運用へ

設計の流れは、3層それぞれの法的性質の確定から始まり、送信イベントの定義、宛先設計、記載項目の決定、到達性の確保、監視運用という順に進みます。この記事も同じ順番で解説します。

なお、以下の法令解釈は一般的な考え方の整理であり、個別の事案では所管官庁や弁護士への確認が必要です。経済産業省の準則自体も「個別具体的な事案の解決に際しては、それぞれの事案に即して個別具体的に判断する必要がある」と留保しています^*4。

その通知メールは広告メールか — 特定電子メール法の適用境界

取引関係に係る通知が特定電子メールに当たらない理由

特定電子メール法は、広告・宣伝を目的とする電子メールの送信を規制する法律です。総務省総合通信基盤局と消費者庁が公表したガイドラインは、特定電子メールに当たらないものを挙げています^*2。それは「取引上の条件を案内する事務連絡や料金請求のお知らせなど取引関係に係る通知であって広告又は宣伝の内容を含まず、広告又は宣伝のウェブサイトへの誘導もしない電子メール」を指します^*2。

注文確認メール・入金確認メール・発送完了メールは、この定義に沿って作られていれば特定電子メールに該当しません。ただし「広告又は宣伝の内容を含まない」という条件が付いている点に注意が必要です。

販促を1行加えると発生する第4条の表示義務

ガイドラインは逆に、特定電子メールに当たるものも挙げています^*2。「営業上のサービス・商品等に関する情報を広告又は宣伝しようとするウェブサイトへ誘導することがその送信目的に含まれる電子メール」がこれにあたります^*2。つまり注文確認メールに新商品キャンペーンのバナーと誘導リンクを1行入れた時点で、そのメールは特定電子メールになり得ます。

該当すれば、特定電子メールの送信の適正化等に関する法律第4条による表示義務が生じます^*3。送信者の氏名又は名称、受信拒否の通知を受けるための連絡先などを、受信者の端末画面に正しく表示させる義務です^*3。マーケティング部門から「1行だけ商品案内を足したい」という要望が来たときの判断基準は、ここにあります。

BtoBの例外 — 法第3条第1項第3号「取引関係にある者」

特定電子メール法第3条第1項は、原則として送信者があらかじめ同意を得た者以外への特定電子メールの送信を禁じるオプトイン規制です。ただし同項第3号は同意取得の例外を定めています^*3。「前二号に掲げるもののほか、当該特定電子メールを手段とする広告又は宣伝に係る営業を営む者と取引関係にある者」がこれにあたります^*3。

この条文により、既存の取引先に対しては、事前の同意取得なしに広告・宣伝の内容を含むメールを送れる余地があります。BtoB EC事業者が既存顧客に新商品の案内を送る場面で、実務上の根拠になる条文です。

例外に乗っても残るオプトアウトと表示義務

取引関係にある者への例外に該当する場合でも、義務がすべてなくなるわけではありません。第3条第3項は、受信者から受信拒否の通知を受けたときは、その意思に反して特定電子メールを送信してはならないと定めています^*3。

加えて第4条の表示義務、第5条の送信者情報を偽った送信の禁止は、取引関係の有無にかかわらず適用されます^*3。既存取引先への広告メールであっても、受信拒否の申出があればすぐに止められる仕組みと、送信者の表示は必要です。

自社の通知メールが特定電子メールに該当するかどうかの最終判断は、個々の文面・目的によって変わります。無料相談で現行の文面を確認することで、判断の分かれ目を具体的に整理できます。

その通知メールは保存対象か — 電子帳簿保存法の適用範囲

電子取引の定義とメールで取引情報を授受した場合の扱い

電子帳簿保存法は、電子取引（電子メールによる取引情報の授受を含む）で得た取引情報の電磁的記録の保存を義務づけています。国税庁の一問一答は、「電子メールにおいて授受される情報の全てが取引情報に該当するものではありません」とし、取引情報が含まれないメールは保存不要としています^*1。

取引情報とは、注文書・領収書等に通常記載される事項を指します。通知メールすべてを一律に保存する必要はなく、取引情報を含むかどうかで判断します。

国税庁一問一答 問6が示す本文と添付ファイルの保存対象の違い

国税庁一問一答【電子取引関係】（令和8年7月）の問6は、次のように回答しています^*1。「電子メール本文に取引情報が記載されている場合は当該電子メールを保存する必要がありますが、電子メールの添付ファイルにより授受された取引情報（領収書等）については当該添付ファイルのみを保存しておけばよいことになります」^*1。

本文に明細を書けばメール自体が保存対象になり、添付ファイルで送ればファイルのみが保存対象になるという違いです。この一文が、BtoB EC通知メールの本文設計に直接影響します。

本文設計が保存対象を左右する — 明細記載かPDF添付かリンクか

設計上の選択肢は主に3つです。第一に、商品名・数量・単価・納期などの明細をメール本文にすべて書く方式です。この場合、メール自体が電子取引データとして保存対象になります^*1。

第二に、明細をPDF等の添付ファイルにして送る方式です。この場合は添付ファイルのみが保存対象になり、本文は保存の対象から外れます^*1。第三に、明細をEC上の受注詳細ページへのリンクで案内する方式で、この場合はEC側のデータが保存の正本になり得ます。どの方式を選ぶかで、通知メール自体を保存の入口にするかどうかが変わります。

保存期間は原則7年、欠損金の事業年度は10年

電子帳簿保存法は帳簿書類の保存方法を定めるものであり、保存期間そのものは所得税法・法人税法など各税法の規定に従います。国税庁一問一答の問17によれば、法人（青色申告者・白色申告者とも）の帳簿・書類の保存期間は原則7年です^*1。

青色申告書を提出した事業年度で欠損金額が生じた場合は10年（平成30年4月1日前に開始した事業年度は9年）です^*1。個人事業者（青色申告者）は帳簿・決算関係書類が7年、請求書・見積書など一部の書類は5年とされています^*1。通知メールを保存の正本にするかどうかは、この保存期間の負荷とも関係します。

その通知メールは承諾か — 契約成立時期を決める民法と経産省準則

契約は申込みと承諾の合致で成立し意思表示は到達時に効力を生ずる

民法第522条第1項は「契約は、契約の内容を示してその締結を申し入れる意思表示（以下『申込み』という。）に対して相手方が承諾をしたときに成立する」と定めています^*5。また第97条第1項は「意思表示は、その通知が相手方に到達した時からその効力を生ずる」と定めています^*5。

この2条を組み合わせると、電子メールで承諾の意思表示がなされた場合、そのメールが申込者に到達した時点で契約が成立するという考え方になります。BtoB ECの注文確認メールが、この承諾の意思表示にあたるかどうかが論点です。

承諾通知のメールが到達した時点で契約が成立する

経済産業省の「電子商取引及び情報財取引等に関する準則」（令和7年2月）は、契約成立の考え方を整理しています^*4。価格表示のあるウェブサイトの掲載は契約の申込みの誘引にとどまります。購入希望者の申込みに対して売主から承諾の意思表示が電子メールで到達した時点、または画面上に表示された時点で契約が成立すると考えられます^*4。

つまり、注文確認メールの文面が承諾の意思表示と評価されれば、そのメールが到達した時点で売買契約は成立します。在庫がない、与信が通らないといった事情があっても、承諾の意思表示が到達済みであれば、契約自体は成立してしまう可能性があります。

「本メールは受信確認メールであり、承諾通知ではありません」と明記する設計

準則は、この帰結を避ける設計例も示しています^*4。例えば「本メールは受信確認メールであり、承諾通知ではありません。在庫を確認の上、受注が可能な場合には改めて正式な承諾通知をお送りします」と明記する設計です^*4。契約の申込みへの承諾が別途なされることが明記されている場合、受信の事実を通知したにすぎず、そもそも承諾通知に該当しないと考えられます^*4。

この一文の有無が、注文確認メールを「単なる受信確認」にとどめるか「契約の承諾」にしてしまうかを分けます。BtoB ECは在庫確認・与信審査・社内承認が挟まる取引が多く、この設計の重要性がBtoCより高くなります。

利用規約で契約成立時期を定める場合との関係

準則は別の設計パターンも示しています^*4。サイト利用規約で「発送完了メールの送信をもって契約成立とする」ことが明記されている場合の考え方です^*4。その規約が有効に契約に組み入れられていれば、規約に沿って承諾通知が特定されます^*4。

この場合、注文確認メールは承諾通知ではなく、発送完了メールこそが承諾通知になります。どちらの設計を採るにせよ、利用規約と通知メールの文面が矛盾しないよう、両方をあわせて設計する必要があります。

与信否決・在庫不足・承認差戻しで断れるかを分ける一文

BtoB ECでは、受注後に与信審査で否決される、在庫が確保できない、社内承認で差し戻されるという場面が起こり得ます。注文確認メールに「本メールは受信確認メールであり、承諾通知ではありません」という但し書きがあれば、これらの場面で契約が未成立であることを説明しやすくなります^*4。

逆に但し書きがなく、文面が承諾の意思表示と読める場合、受注を取り消すことは契約の解除に近い扱いになりかねません。この一文の有無は、BtoB特有の実務リスクに直結する設計項目です。ただし、この整理は一般的な解釈であり、個別の契約条件・利用規約の内容によって結論が変わり得ます^*4。

送るべき通知イベントを定義する — BtoB固有のイベントを落とさない

BtoCと共通する受付・入金・出荷・アカウント系イベント

BtoB ECでも、注文受付・入金確認・出荷完了・アカウント登録や再設定といった、BtoC通販と共通のイベントは基本のラインナップになります。これらは競合の文例集記事でも広く扱われている領域であり、本記事では法的性質の確定だけを確認しておきます。

受付・入金・出荷の各メールは、層①（広告非該当）と層②（本文設計次第で保存対象）に関わります。層③（契約成立）は主に注文確認メールで論点になります。

見積・承認ワークフロー・与信・分納・締め請求というBtoB固有イベント

BtoB EC特有のイベントとして、見積提示・見積承諾、社内承認ワークフローの申請・承認・差戻しが挙げられます。ほかにも与信審査結果の通知、分納・分割出荷の案内、締め請求のお知らせ、単価改定・商品改廃の案内があります。これらは汎用的なBtoCカートのメールテンプレート機能には存在しないことが多く、受発注業務のイベント設計と一体で考える必要があります。

見積承諾メールや与信結果メールは、内容によって契約成立や取引条件確定の意思表示にあたる可能性があり、層③の観点での文面設計が重要です。承認ワークフローの通知は社内向けであることが多く、外部向けの通知とは宛先ルールを分けて考えます。

イベントごとに「誰の何のアクションを促すメールか」を1行で定義する

通知イベントを洗い出す際は、各メールについて「誰の、何のアクションを促すメールか」を1行で書き出すことが有効です。目的が定義できないメールは、送る理由がないメールである可能性があります。

例えば「発送完了メール」であれば、「納品先担当者の、着荷確認と検品準備を促すメール」というように定義します。この定義がそのままメールの記載項目（何を書くべきか）の起点になります。

システム内通知やステータスページで足りる場面は送らない

すべてのステータス変化をメールで通知する必要はありません。受注管理システムやEC上のマイページで随時確認できる情報、頻度の高い状態変化については、システム内通知やステータスページに任せる判断もあります。

本記事の対象外である障害発生時の告知についても、通知メールとステータスページは役割が異なります。障害通知メールは影響を受ける取引先への個別連絡、ステータスページは継続的な状況確認の場という役割分担で運用するのが一般的です。

宛先を設計する — 発注者・承認者・経理・納品先が別人という前提

BtoB特有の宛先構造 — 発注者・承認者・経理・納品先担当

BtoB ECの宛先設計が難しいのは、1つの取引の中に複数の役割の担当者が存在するためです。発注する担当者、社内承認をする担当者、支払い処理をする経理担当者、実際に商品を受け取る納品先担当者が、それぞれ別人であることが珍しくありません。

BtoCの通販であれば購入者本人に送れば足りるメールも、BtoB ECでは「誰に送るべきか」自体が設計項目になります。この構造を前提にしないと、必要な担当者にメールが届かないという事態が起こります。

宛先の持ち方とイベント×宛先マトリクス

宛先の持ち方には主に3通りがあります。利用者アカウント単位（担当者個人のメールアドレス）、取引先単位（会社の代表アドレス）、部署共有アドレスです。イベントごとにどの持ち方を使うかを、あらかじめマトリクスにしておくと運用がぶれません。

このマトリクスは自社の承認フローに合わせて調整が必要ですが、まず「誰がTo、誰がCCか」を1枚の表にすることが、設計の出発点になります。

To・CC・BCCの使い分けと複数取引先一括送信の禁止

Toには主担当者、CCには関係者を置き、BCCは基本的に社内モニタリング用途に限定するという使い分けが一般的です。特に避けるべきなのは、複数の取引先を1通のCC欄に並べて送ることです。

この設計は、他社の存在やメールアドレスを別の取引先に露出させることになります。取引先ごとに個別送信する設計を、システムの仕様として組み込む必要があります。

誤送信の重み — 個人情報保護委員会への報告対象になり得る4類型

宛先を誤ると、他社の単価や取引条件が別の取引先に届くという事態が起こります。誤送信で個人データが漏えいした場合、個人情報保護委員会は4つの類型のいずれかに該当すれば報告を義務としています^*6。その4類型は次のとおりです^*6。「①要配慮個人情報が含まれる事態、②財産的被害が生じるおそれがある事態、③不正の目的をもって行われた漏えい等が発生した事態、④1,000人を超える漏えい等が発生した事態」です^*6。

該当する場合は「速やか（概ね3〜5日以内）に個人情報保護委員会への報告」を行うことが求められ、本人への通知も必要になります^*6。取引先の担当者名・メールアドレスを含む誤送信は、事態の内容によってはこの報告対象になり得ます。宛先設計のミスが、通知メール1通の問題にとどまらないことを示す規定です。

退職・異動によるアドレス失効の棚卸し

宛先設計は一度作って終わりではありません。取引先担当者の退職・異動でメールアドレスが失効し、必要な通知が届かなくなるケースは実務でよく起こります。

定期的にアドレスを棚卸しする運用、バウンス（配送不能）を検知した際に取引先へ確認する運用をあわせて設計しておく必要があります。

通知メールを設計する6ステップ

ここまでの内容を、実際の設計手順に落とし込みます。順位の根拠は実施順序です。

各ステップの成果物

各ステップには、決めごとを一覧にした成果物が対応します。ステップ1は「イベント×法的性質の一覧表」、ステップ2は「イベント×宛先マトリクス」、ステップ3は「記載項目チェックリスト」です。

ステップ4は「文面テンプレート集」、ステップ5は「送信ドメイン・認証設定台帳」、ステップ6は「バウンス監視・再送手順書」になります。成果物を先に決めておくと、設計作業の完了条件が明確になります。

件名の設計 — 取引先が検索で引ける識別子を入れる

件名には、取引先が自社の受信箱で検索して引ける識別子を入れます。注文番号・取引先コード・見積番号などです。「ご注文ありがとうございます」のような識別子のない件名では、後から取引先がメールを探し出せません。

件名の型を「【識別子】イベント名（会社名）」のように統一しておくと、取引先側でもフィルタリングや検索がしやすくなります。

届かなければ設計は無意味 — 到達性の外形要件

2024年2月1日から全送信者に適用、1日5,000件超はSPF・DKIM・DMARCが必須

通知メールは、正しく設計しても届かなければ意味がありません。Googleの「メール送信者のガイドライン」は、2024年2月1日以降、Gmailアカウントにメールを送信するすべての送信者に要件を課しています^*7。1日5,000件を超える送信者には、さらに上乗せの要件が適用されます^*7。

すべての送信者には、SPF（送信元ドメインを認証する仕組み）またはDKIM（電子署名でメールの改ざんを検知する仕組み）のいずれかの設定が求められます^*7。これに対し1日5,000件を超える送信者には、SPFとDKIMの両方に加えて、DMARC（SPF・DKIMの結果をもとに受信側の扱いを指定する仕組み）の設定が必須となります^*7。ただしDMARCの適用ポリシーはnoneに設定してもよいとされています^*7。

SPF・DKIM・DMARCの役割分担

3つの認証技術は役割が異なります。SPFは送信元のIPアドレスが正当かどうかを検証し、DKIMはメールの内容が改ざんされていないかを電子署名で検証します。DMARCはSPF・DKIMの検証結果を踏まえ、認証に失敗したメールをどう扱うかを送信ドメイン側が指定する仕組みです。

総務省の調査事業で作成されたガイドライン案（令和6年3月29日版）は、SPF・DKIM・DMARCの設定水準を3段階で整理しています^*8。「設定しなければならない」「設定した方が良い」「設定を勧める」の3段階です^*8。DMARCにはポリシーとして none（監視のみ）・quarantine（隔離）・reject（拒否）の3段階があり、段階的に強めていく運用が現実的です。

迷惑メール率0.3%未満という運用指標

Googleのガイドラインは、Postmaster Toolsで報告される迷惑メール率を0.3%未満に維持することを求めています^*7。通知メールは受信者が業務上必要とするメールですが、文面や送信頻度によっては迷惑メール報告を受けることがあります。

この指標は、通知メールを「届いて当然」と考えず、継続的に監視すべき運用指標として扱う必要があることを示しています。

送信ドメインを分ける — 取引通知と販促メールを同じ評判に載せない

取引通知メールと販促メールを同じ送信ドメインで送ると、販促メールの評判（迷惑メール率や到達率）が取引通知メールにも影響します。送信ドメインまたはサブドメインを分けることで、片方の評判が下がっても、もう片方への影響を抑えられます。

ドメインを分ける設計は、SPF・DKIM・DMARCの設定作業自体は増えますが、取引通知メールという業務上重要なメールの到達性を守るための対策になります。

バウンス・エラーの検知と届かなかったときの代替手段

宛先の失効や受信側の設定変更により、通知メールがバウンス（配送不能）することがあります。バウンスを検知する仕組みと、検知した場合の代替連絡手段（電話・別担当者への再送など）を、運用ルールとしてあらかじめ決めておく必要があります。

この監視と再送の運用が、6ステップの最後（ステップ6）に位置づけられている理由です。設計を作って終わりにせず、継続的に運用する前提で設計します。

やってはいけない設計と、まず着手する2つのこと

注文確認メールに販促バナーを入れる

特定電子メール法の適用境界で見たとおり、注文確認メールに広告・宣伝の内容や誘導リンクを含めると、特定電子メール法上の表示義務が発生する可能性があります^*2*3。マーケティング施策は、取引通知メールとは別のメール種別・別の同意取得プロセスで行う設計が、表示義務の発生を避けるうえでは確実です。

「注文を承りました」とだけ書いて承諾か否かを曖昧にする

契約成立時期の項で見たとおり、承諾か否かを明記しない文面は、契約成立時期をめぐる争点を生みます^*4。「受信確認であり承諾通知ではない」旨を明記するか、逆に「このメールをもって契約成立とする」旨を利用規約とあわせて明記するか、どちらかを意図的に選ぶ必要があります。

明細を本文に全部書き、そのメールを保存の正本にする

電子帳簿保存法の適用範囲で見たとおり、本文に明細を書き込むほど、そのメール自体が電子帳簿保存法上の保存対象になります^*1。保存の正本をシステム側（受注管理・基幹システム）に置く設計であれば、通知メールは要点のみの記載で足ります。詳細はシステム上のリンクへ誘導する方が、保存の負荷を抑えられます。

複数取引先を1通のCCに載せる

宛先設計の項で見たとおり、複数取引先を1通のCCに載せる設計は、取引先間の情報露出のリスクを常に抱えます^*6。取引先ごとの個別送信を、システムの標準仕様として組み込む必要があります。

まず着手する2つ — 現行メールの棚卸しと注文確認メールの但し書きの確定

まず着手すべきことは2つです。第一に、現行の通知メールをすべて洗い出し、イベント×宛先×法的性質の一覧表を1枚作ることです。第二に、注文確認メールに契約成立に関する但し書きがあるかどうかを確認し、なければ追記することです。この2つは、大がかりなシステム改修をせずに着手できます。

この先の設計を自社だけで一から見直すには、法務（法令解釈）・システム（送信設定・宛先マスタ）・運用（監視体制）という3領域の知識を横断して確認する工数が必要です。専門パートナーに依頼する場合との違いは、法令解釈の一次情報確認と、受発注システム側のイベント設計を同時に検討できる点にあります。

まとめ：通知メール設計の3つの判断軸

本稿では、BtoB EC通知メールの設計と運用を、法令に基づく3層の判断軸として整理しました。要点を3つに集約すると次のとおりです。第一に、通知メールは広告規制（特定電子メール法）・保存義務（電子帳簿保存法）・契約の意思表示（民法・経産省準則）という3層の法的性質を持ちます。この性質は文面の書き方次第で変わります。

第二に、BtoB EC特有の宛先構造（発注者・承認者・経理・納品先）と固有イベント（承認ワークフロー・与信・分納）を踏まえたイベント定義と宛先設計が必要です。第三に、正しく設計しても届かなければ意味がなく、SPF・DKIM・DMARCによる到達性の確保と監視運用まで含めて設計する必要があります。この3つの軸に沿って現行メールを棚卸しすることが、設計の出発点になります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

注文確認メールは特定電子メール法の規制対象になりますか。

広告・宣伝の内容や、広告サイトへの誘導を含まなければ、原則として規制対象になりません。総務省・消費者庁のガイドラインは、取引関係に係る通知で広告・宣伝を含まないメールを特定電子メールに当たらないものとしています^*2。商品案内やキャンペーンバナーを1行でも加えると該当する可能性があるため、注文確認メールは取引情報のみで構成し、販促要素を混ぜない設計が安全です。

注文確認メールを送った時点で売買契約は成立しますか。

文面によって結論が変わります。承諾の意思表示と評価される文面であれば、メールが到達した時点で契約が成立すると考えられます^*4*5。一方「本メールは受信確認メールであり、承諾通知ではありません」と明記されていれば、そもそも承諾通知に該当しないと考えられます^*4。個別の事案では利用規約の内容もあわせて確認する必要があります。

BtoB ECの通知メールは電子帳簿保存法の保存対象になりますか。

メール本文に取引情報が記載されていれば保存対象になります。国税庁の一問一答は、本文に取引情報がある場合は当該メールの保存を、添付ファイルで取引情報を授受した場合は添付ファイルのみの保存を求めています^*1。取引情報を含まない通知メール（発送完了の一報のみ等）は保存対象になりません。

既存の取引先に新商品の案内メールを送るのに同意は必要ですか。

特定電子メール法第3条第1項第3号により、取引関係にある者への送信は事前の同意取得義務の例外とされています^*3。ただし受信拒否の通知を受けた場合はその意思に反して送信できず、送信者情報の表示義務も残ります^*3。同意取得が不要でも、表示義務とオプトアウトへの対応は必要です。

通知メールが取引先の迷惑メールフォルダに入ってしまう場合、何を確認すればよいですか。

まずSPF・DKIMの設定を確認し、1日5,000件を超える送信量であればDMARCの設定も確認します^*7。あわせてPostmaster Toolsで迷惑メール率が0.3%未満に収まっているかを確認します^*7。取引通知メールと販促メールを同じ送信ドメインで送っていないかも、あわせて点検が必要です。

1. *1　出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（令和8年7月）
2. *2　出典：総務省総合通信基盤局・消費者庁「特定電子メールの送信等に関するガイドライン」（平成23年8月）
3. *3　出典：デジタル庁 e-Gov法令検索「特定電子メールの送信の適正化等に関する法律」（現行版施行日：2025年6月1日）
4. *4　出典：経済産業省「電子商取引及び情報財取引等に関する準則」（令和7年2月）
5. *5　出典：デジタル庁 e-Gov法令検索「民法」
6. *6　出典：個人情報保護委員会「漏えい等報告・本人への通知の義務化について」
7. *7　出典：Google「メール送信者のガイドライン」（Google Workspace 管理者ヘルプ）
8. *8　出典：総務省「DMARCガイドライン案（参考資料4）」（令和6年3月29日版）