日本酒応援サイト「サケナビ」掲載日本酒絶賛募集中です。

常連さんに送ったお知らせ、本当に届いていますか — 独自ドメインのGmailで迷惑メールに入らないための、DNSの3行

来月、久しぶりにコースを入れ替える。常連のお客様に、先にお知らせしたい。

住所は分からなくても、メールアドレスなら持っている。予約のときにいただいた分、名刺をいただいた分、ご宴会の幹事さんの分。300人分くらいはある。

そこで、パソコンを開いて、お店のアドレスから一斉にお知らせを送ります。「来月から秋のコースが始まります」と。

……そして、何も起きません。

いつもなら数件は入るはずの予約が、入らない。しばらくして常連のお客様がふらりと来店されて、こうおっしゃる。

「え、メール? 来てないですよ。……あ、これかな。迷惑メールのところに入ってました」

これ、ご経験ありませんか。

私は、この話を本当によく耳にします。そしてほとんどの場合、店主さんはこうおっしゃるんです。

「うちは独自ドメインだし、Gmail(Google Workspace)をちゃんとお金払って使ってるんですよ。それなのに、なんで?」

お気持ち、よく分かります。フリーメールではなく、お店のドメインで、有料のサービスを使っている。それなのに迷惑メール扱いされる。理不尽に感じますよね。

でも、理由ははっきりしています。

そして、その理由を知っている人が、飲食業界にはほとんどいません。IT担当者がいる会社なら当たり前にやっている設定が、飲食店ではまず誰もやっていない。 だから、届かない。

もっと言うと、Google Workspaceを契約しただけでは、必要な設定の半分は「オフ」のままです。 契約すれば自動で有効になるものだと、私も長いこと思っていました。違うんです。自分で管理画面を開いて、有効にしないと効きません。

この記事では、その設定を、最初から最後までお見せします。


先に、お約束をしておきます。

これから SPF(エスピーエフ)/DKIM(ディーキム)/DMARC(ディーマーク) という、呪文のような3つの言葉が出てきます。専門の記事なら1行で済ませるところですが、この記事は飲食店の経営者・店長さんに向けて書いています。

「DNS」「SMTP」「レコード」を一度も聞いたことがない方が、
最後まで読んで分かるように書きます。

専門用語は、出てくるたびに全部郵便のたとえに翻訳します。メールの仕組みは、驚くほど郵便に似ているからです。封筒があって、便箋があって、郵便局があって、消印がある。

そして最後には、Google Workspaceの管理画面のどこを押すかと、DNSに書き込む「3行」まで、そのまま真似できる形でお見せします。

お茶でも淹れてから、読んでください。


目次

第1章 なぜ弾かれるのか — 受信側には「3つの関門」がある

「送信済み」は「届いた」ではありません

最初に、いちばん大事な前提を共有させてください。

メールソフトの「送信済み」に入っていることと、相手に届いたことは、まったく別のことです。

これは郵便で言えば、ポストに投函したという意味しかありません。その後、郵便局が受け取るかどうか、配達員が相手の家まで運ぶかどうかは、また別の話です。

そしてメールの世界では、受け取る側の郵便局(相手のGmailやOutlook)が、驚くほど厳しい門番になっています。

なぜそんなに厳しいのか。世界中を飛び交うメールの大半が、迷惑メールと詐欺メールだからです。GmailやOutlookは、その泥水の中から、あなたのお店の「秋のコースのお知らせ」という本物の一滴を選り分けなければいけない。

だから彼らは、届いたメールを3つの関門で審査しています。

受信側の3つの関門。第1関門「本人確認(認証)」、第2関門「素行(評判)」、第3関門「中身(内容)」を順に通過して初めて受信箱に届くことを示した図
受信側は3つの関門で審査している。どれか1つでも引っかかれば、受信箱には届かない

第1関門:本人確認(認証)

「あなた、本当にそのお店の人ですか?」

差出人のところに「〇〇亭」と書いてあっても、それを名乗るのは誰にでもできます。手紙の裏に他人の名前を書くのと同じで、メールの差出人欄は、技術的には書きたい放題なんです。ここには何の保証もありません。

だから受信側は、「その名前を名乗る資格が本当にあるのか」を機械的に確かめます。この確認に使われるのが、SPF・DKIM・DMARCの3つです。この記事の主役たちですね。

ここで落ちると、多くの場合、迷惑メールフォルダにすら入りません。 門の外で追い返されます。

第2関門:素行(評判)

「あなた、普段どんな送り方をしている人ですか?」

本人確認を通っても、まだ安心できません。受信側は、あなたのお店のドメイン(@より後ろの部分)の「素行」を、日々採点しています。

  • 存在しないアドレスに、何通も送りつけていないか
  • 送ったメールを、受け取った人が「迷惑メール」と報告していないか
  • 昨日まで1日3通だったのに、今日いきなり300通送っていないか

信用情報のようなものだと思ってください。厄介なのは、この点数が誰にも見えないことです。「あなたのお店は現在68点です」と教えてくれる窓口は、どこにもありません。

第3関門:中身(内容)

「その手紙、書いてあることは怪しくないですか?」

件名に「!!!」が並んでいる、本文がリンク1本だけ、といった書き方をしていないか。ここは、飲食店さんが普通に日本語で書いているぶんには、そう心配は要りません。

この記事が扱うのは、第1と第2です

関門 何を見ているか 対策
① 本人確認 あなたが本物か SPF / DKIM / DMARC
② 素行 普段の送り方が真っ当か 名簿の鮮度・送る量・送り方
③ 中身 文面が怪しくないか 普通に書けばOK

①は、正しく設定すれば1日で終わります。(第3章から第7章)
②は、日々の運用の話です。(第9章)

多くの記事は①だけを説明して終わりますが、常連のお客様に一斉にお知らせを送るなら、②のほうが効いてきます。 両方お話しします。


第2章 メールには、差出人が「2つ」あります

ここだけは、飛ばさないでください

3つの呪文を説明する前に、たった1つだけ、腹に落としていただきたいことがあります。

ここが分かれば、3つは全部つながります。逆にここが曖昧だと、どれだけ設定しても「なぜこれが必要なのか」が永遠に分かりません。

その1つとは、これです。

メールには、差出人が「2つ」あります。

「え?」と思われましたよね。でも本当に2つあって、しかもこの2つは、別々に書けるのです。

封筒の差出人(Envelope From/Return-Path)と便箋の差出人(Header From)の違いを、封筒と中の便箋の絵で示した図
メールには差出人が2つある。お客様が見ているのは「便箋」のほうだけ

差出人①:封筒の差出人

正式には Envelope From(エンベロープ・フロム/封筒の差出人)、または Return-Path(リターンパス/返送先) と呼びます。

郵便で言えば、封筒の裏に書く「不着の場合はこちらへ返送してください」の住所です。

  • 配達に失敗したとき、エラー通知が戻ってくる先
  • 受け取った人には、基本的に見えません
  • メールを運ぶサーバー同士が、裏でやり取りするための住所

つまり、運送業者のための情報です。お客様は見ません。

差出人②:便箋の差出人

正式には Header From(ヘッダー・フロム/ヘッダの差出人) と呼びます。

郵便で言えば、便箋の右下に書いた署名です。

  • メールソフトの「差出人」欄に表示される、まさにその名前とアドレス
  • お客様が見ているのは、こちらだけです
  • 「〇〇亭 予約担当」と表示されるのは、ここに書いてあるからです

なぜ、なりすましが成立してしまうのか

この2つが別々に書けると、どうなるか。

封筒の裏には自分の本物の住所を書いておいて、中の便箋の署名だけ「〇〇銀行」と書く。 これができてしまいます。

受け取った人は便箋しか見ません。だから「〇〇銀行から手紙が来た」と思う。でも配達の仕組みから見れば、その手紙は正真正銘、詐欺師の家から出ている。封筒と便箋が食い違っていても、長いあいだ誰も文句を言わなかった。 これが、フィッシング詐欺メールが世に溢れた根本的な理由です。

さて、ここからが本題です。3つの呪文は、それぞれ違う場所を見ています。

呪文 何を見ているか
SPF 封筒の差出人
DKIM 便箋と中身(電子署名)
DMARC 便箋の差出人と、認証が通ったドメインが一致しているか

もう一度読んでください。SPFは、封筒しか見ていません。

だからSPFだけを完璧に設定しても、なりすましは防げないのです。封筒だけ本物にして、便箋を偽ればいいのですから。

この「食い違い」を潰すために生まれたのが、DMARCです。 DMARCは新しい検査を足すものではありません。「封筒と便箋、ちゃんと同じ人ですよね?」を確認するだけの仕組みです。

ここを押さえていただけたなら、この記事の半分は読み終わったも同然です。


第3章 SPF — 「うちの郵便は、この局からしか出しません」という届出

たとえ話

SPF(Sender Policy Framework / 送信者ポリシー・フレームワーク /「この店の郵便は、この郵便局からしか出しません」という届出名簿)

これがSPFの正体です。名簿を、誰でも見られる場所に貼り出しておく。

お店で例えるなら、こういう貼り紙です。

「当店の名前で出される郵便物は、A郵便局からしか出されません。
それ以外の局から出たものは、当店とは無関係です」

受け取った側は、この貼り紙を見に行きます。届いた手紙がC局の消印だったら、「この店はC局からは出さないと言っているぞ」となる。これが SPF不合格 です。

貼り紙はどこに貼るのか = DNS

では、この貼り紙をどこに貼るのか。

ここで DNS(Domain Name System / ドメイン名システム / インターネット全体の「電話帳」) が登場します。

DNSは、インターネット上の巨大な電話帳だと思ってください。「example.com というお店のホームページは、どのサーバーにありますか?」「メールはどこに届けますか?」といった問い合わせに答える、世界に公開された台帳です。

お店のドメインを取ったとき、たいていは同じ会社の管理画面でこの台帳をいじれるようになっています。「DNS設定」「ネームサーバー設定」「レコード設定」といったメニューがそれです。

そして、この台帳にはメモ欄があります。正式には TXTレコード(テキストレコード / 文字列を自由に書ける備考欄) といいます。

SPFの貼り紙は、このメモ欄に書きます。

SPFの仕組み。受信サーバーが、届いたメールの送信元IPアドレスとDNSに公開されたSPFレコードを照合する流れを示した図
受信側は、メールの「出どころ」とDNSに公開された名簿を突き合わせている

実物は、こう書いてあります

Google Workspaceだけでメールを送っているお店なら、SPFはこの1行です。

v=spf1 include:_spf.google.com ~all

暗号のようですが、分解すれば大したことは書いていません。

部分 意味
v=spf1 「これはSPFの貼り紙です、様式は第1版です」という宣言
include:_spf.google.com 「Googleの郵便局から出します」(Googleの名簿を丸ごと取り込む書き方)
~all 「上に書いた以外から出たものは、たぶん偽物です」

最後の ~all だけ、補足させてください。ここには主に2種類の書き方があります。

  • ~all(ソフトフェイル)…「たぶん偽物です。疑ってください」(やや弱め)
  • -all(ハードフェイル)…「間違いなく偽物です。捨てて構いません」(厳格)

厳しくしたい気持ちは分かりますが、いきなり -all にするのはおすすめしません。 名簿に書き忘れた郵便局が1つでもあると、そこから出したメールが全部消えます。まずは ~all から始めるのが安全な順番です。

【最重要】SPFの貼り紙は、1枚しか貼れません

ここが、いちばん多い事故です。

1つのドメインに、SPFの貼り紙は「1枚」しか貼れません。

なぜかというと、貼り紙が2枚あったら、受け取った側は「どっちを信じればいいの?」となるからです。そして機械は、そういうとき親切に判断してくれません。2枚見つけた瞬間、「この店の名簿は壊れている」と判定して、両方とも無効にします。

これが本当によく起きます。典型的なのは、こういう流れです。

  • Google Workspaceを導入したとき、案内どおりに1行書いた
  • あとから予約システムやメール配信サービスを契約して、その案内どおりにもう1行書いた
  • 結果、2行になって、両方とも効かなくなった

どちらの案内も間違っていません。ただ、どちらも「あなたが他にも郵便局を使っている」ことを知らないだけなんです。

正解は、1行にまとめて書くことです。

v=spf1 include:_spf.google.com include:【配信サービスが指定する文字列】 ~all

こうやって、使っている郵便局を全部、1行の中に並べる。 これが唯一の正解です。

もう一つの罠:「参照は10回まで」

SPFには、あまり知られていない上限があります。

include: は「よその名簿を見に行ってこい」という指示です。便利なのでみんな並べたがるのですが、この「見に行く回数」は、仕様上10回までと決まっていますRFC 7208 §4.6.4)。

11回目に達した瞬間、SPFの判定は permerror(パーマネントエラー / 恒久的な失敗 /「この名簿は読めません」という判定) になります。参照先の名簿が存在しない場合も、同じくpermerrorです。

そして、この壊れ方がいちばんたちが悪いんです。

名簿が「無い」だけなら、受信側は「まだ設定していないんだな」と考えます。ところが「壊れている」場合は、設定しようとして失敗している=管理がずさんな送信者と見なされます。

書いてあるのに、書いていないより悪い。

しかも本人は、管理画面に文字列が入っているので「設定済み」だと思っています。誰も疑わないから、何年でも放置されます。 SPFを触ったら、必ずチェックツールで「permerrorが出ていないか」を確かめてください。


第4章 DKIM — 割れたら分かる、封蝋

たとえ話

DKIM(DomainKeys Identified Mail / ドメインキー識別メール / 手紙に「偽造できない封蝋」を押す仕組み)

中世の手紙には、蝋を垂らして印章を押す封蝋がありました。あれには2つの意味があります。

  1. 本人が出したという証明(その印章を持っているのは本人だけだから)
  2. 途中で開けられていないという証明(開ければ蝋が割れるから)

DKIMは、これを電子的にやるものです。

DKIMの仕組み。送信サーバーが秘密鍵で署名し、受信サーバーがDNSに公開された公開鍵で検証する流れを封蝋のイメージで示した図
DKIMは「本人が出したこと」と「途中で書き換えられていないこと」を同時に証明する

仕組み

DKIMには、対になる2つの鍵が登場します。

  • 秘密鍵…封蝋を押すための印章。メールを送るサーバーの中にだけしまっておく。絶対に外に出さない
  • 公開鍵…その封蝋が本物か照合するための見本。DNS(例の電話帳)に公開しておく

メールを送るとき、サーバーは秘密鍵を使って、件名と本文から計算した「封蝋」をメールにこっそり貼り付けます。受け取ったサーバーは、DNSから公開鍵を取ってきて照合する。合っていれば DKIM合格 です。

封蝋は件名と本文から計算されているので、途中で1文字でも書き換えられたら、照合が合わなくなります。

飲食店にこそ効く理由 = 転送に強い

DKIMには、SPFに無い大きな利点があります。

メールが転送されても、生き残ります。

SPFは「どの郵便局から出されたか」を見ています。ですから、メールが転送されると壊れます。 お客様が「会社のアドレスに来たメールを、自分のGmailに自動転送」していると、Gmailから見た出どころは「お客様の会社のサーバー」です。あなたのお店の名簿には載っていない局ですから、SPFは不合格になる。

一方、DKIMの封蝋は手紙そのものに貼り付いているので、何回転送されても、中身が変わらなければ有効です。

そして、飲食店さんのお客様は、本当によく転送しています。

  • 幹事さんが、会社のアドレスで受けた案内を、参加者に転送する
  • お客様が、会社のメールを個人のスマホに自動転送している
  • 店長宛の連絡が、社長のアドレスにも自動転送されている

転送が多い相手に送るなら、DKIMは必須だと思ってください。

【最大の見落とし】鍵を作っても、DNSに載せるまでは効きません

DKIMの設定は、たいていこの3ステップです。

  1. 管理画面で「DKIMを有効にする」を押す
  2. 公開鍵の文字列が表示される
  3. その文字列を、DNSに自分でコピーして貼り付ける

お分かりでしょうか。3番目が、別作業なんです。

管理画面には「生成済み」と表示されます。緑のチェックが付くこともある。でも、公開鍵をDNSに公開していなければ、受信側は照合のしようがありません。

封蝋は押されている。けれど、それが本物かを照らし合わせる見本が、世界のどこにも公開されていない。受け取った側は「知らない印章だ」としか判断できません。

「管理画面で有効にした」は、「効いている」ではありません。 ここは、この記事で二度でも三度でも申し上げます。


第5章 DMARC — 「一致の確認」と、毎日届く成績表

DMARCだけは、性格が違います

SPFとDKIMは「検査」です。DMARCは違います。DMARCは、検査結果をどう扱うかを決める「方針」です。

DMARC(Domain-based Message Authentication, Reporting and Conformance / ドメインベースのメッセージ認証・報告・適合 / SPFとDKIMの結果を突き合わせて、合わなかったときの扱いを指示し、毎日レポートを受け取る仕組み)

長いですね。でも、やっていることは3つだけです。

DMARCの3つの役割。①アライメント(一致)の確認 ②不合格時の扱いの指示(none/quarantine/reject) ③毎日届くレポート、を並べた図
DMARCがやっているのは、この3つだけ

役割①:一致(アライメント)の確認 — ここが本体です

第2章を思い出してください。メールには差出人が2つあって、SPFは封筒しか見ていない。

だから、こんなことができてしまいます。

  • 封筒の差出人:bounce@詐欺師のドメイン.com(SPF的には完全に合格。詐欺師は自分のドメインを正しく設定しているので)
  • 便箋の差出人:info@あなたのお店.com(お客様に見えるのはこっち)

SPF合格。でも、なりすまし。

これを潰すのがDMARCです。DMARCはこう問います。

「便箋の差出人のドメインと、認証が通ったドメインは、同じですか?」

同じなら合格。違うなら、SPFが通っていようがDKIMが通っていようが、DMARC不合格です。

この「同じかどうか」の確認を アライメント(alignment / 整合・一致) と呼びます。DMARCの本体は、ここです。

アライメントの図。SPFが合格していても、封筒の差出人ドメインと便箋の差出人ドメインが違えばDMARC不合格になることを示した図
SPFが合格していても、便箋の差出人と揃っていなければDMARCは不合格になる

飲食店さんでこれが問題になりやすいのは、予約システムやメール配信サービスを併用しているときです。

外部サービスからメールを送ると、封筒の差出人はたいていそのサービス会社のドメインになります。一方、便箋の差出人はお店のドメインにしてある。この時点で、一致していません。

ですから外部サービスを使う場合は、必ず管理画面で「送信ドメイン認証」「独自ドメインの設定」といったメニューを開いて、お店のドメインで署名してもらう設定をしてください。ここは第9章でもう一度触れます。

役割②:破れていたときの扱いを指示する

DMARCでは、「一致しなかったとき、どう扱ってほしいか」を送る側が指定できます。3段階です。

指定 読み方 意味
p=none ピー・イコール・ナン 何もしないでください(普段どおり配達して、結果だけ報告して)
p=quarantine ピー・イコール・クアランティン 迷惑メールフォルダに入れてください(隔離)
p=reject ピー・イコール・リジェクト 受け取らないでください(拒否)

quarantine は「検疫・隔離」という意味の英語です。空港の検疫所と同じ言葉ですね。

この設定を、いきなり p=reject にしてはいけません。 理由は第8章で詳しくお話しします。

役割③:毎日届く「成績表」

そして、私がDMARCの真の価値だと思っているのが、これです。

DMARCを設定すると、世界中の受信サーバーが、あなたのドメインの認証結果を毎日レポートで送ってくれます。

「昨日、あなたのドメインを名乗るメールを120通受け取りました。うち115通はSPFもDKIMも合格でした。残り5通は、203.0.113.55 というサーバーから来ていて、認証は全部不合格でした」

こういうレポートが、指定したアドレスに毎日届きます。これを rua(report URI for aggregate / 集計レポートの送り先) といいます。

第1章で「素行の点数は誰にも見えない」と書きました。DMARCのレポートは、その闇の中に差し込む、唯一の懐中電灯です。

そして、これを1ヶ月眺めると、ほぼ確実に「自分が知らない送信元」が見つかります。何年か前に契約した予約システム、以前の制作会社が作った仕組み、誰も覚えていない配信ツール。自分の家から、自分の知らない郵便が毎日出ている。 これを可視化できるのがDMARCです。

なお、レポートはXMLという機械向けの形式で届くので、そのまま開いても人間にはまず読めません。無料のレポート解析サービスがいくつもあるので、そこに転送してグラフで見るのが現実的です。


第6章 Google Workspaceの設定 — 管理画面のどこを押すか

さて、ここからが本題です。

Google Workspaceをお使いなら、ここの作業がいちばん重要です。というのも、

Google Workspaceは、契約しただけではDKIMが有効になっていません。

これを知らない方が、本当に多い。私も最初は「有料で契約しているんだから、当然やってくれているだろう」と思っていました。やってくれていません。 自分で管理画面を開いて、鍵を作って、DNSに載せて、最後に「開始」を押す。この4手が要ります。

逆に言えば、この4手をやるだけで、あなたのお店のメールは「封蝋つき」になります。 費用はかかりません。作業時間は20分ほどです。

順にお見せします。

Google Workspaceの管理コンソールでDKIMを有効にする4ステップ。①メールの認証を開く ②新しいレコードを生成 ③DNSにTXTレコードを登録 ④認証を開始、を並べた図
やることは4手。20分ほどで終わります

前提:管理者アカウントが要ります

この作業は、Google Workspaceの「特権管理者」の権限がないとできません。

普段お使いのメールアカウントとは別に、契約したときに作った管理者アカウントがあるはずです。分からなければ、導入をお願いした会社に「管理コンソールに入れる管理者アカウントを教えてください」と聞いてください。

ステップ1:管理コンソールで「メールの認証」を開く

管理コンソール(admin.google.com)にログインして、こう進みます。

メニュー → アプリ → Google Workspace → Gmail → メールの認証

(出典:Google Workspace ヘルプ/DKIM を設定する

「メールの認証」という名前のとおり、ここがDKIMの設定場所です。開くと、あなたのドメイン名が表示されているはずです。

ステップ2:「新しいレコードを生成」を押す

画面に 「新しいレコードを生成」 というボタンがあるので、これを押します。

すると、2つ聞かれます。

① 鍵の長さ(DKIM鍵のビット数)

  • 2048ビットこちらが推奨です
  • 1024ビット … ドメインの管理会社が2048ビットに対応していない場合のみ

(出典:Google Workspace ヘルプ

鍵は長いほど頑丈です。よほど古いDNSサービスでない限り2048で通りますので、まず2048を選んでください。 もし後でDNSへの登録がエラーになるようなら、1024に作り直します。

② プレフィックス(セレクタ)

既定の google のままでかまいません。

セレクタというのは、鍵に付ける名札のようなものです。1つのドメインで複数のサービスから署名する場合に、どの鍵で照合すればいいかを区別するために使います。Google Workspaceを使うなら、既定の google が推奨です(出典:同上)。

「生成」を押すと、長い長い文字列が表示されます。これが公開鍵です。

ステップ3:表示された値を、DNSに登録する

ここが、Googleの画面の外に出る唯一の作業です。そして、いちばん忘れられる作業でもあります。

ドメインを管理している会社の管理画面を開いて、DNSに次のレコードを追加します。

項目
ホスト名(名前) google._domainkey
種別(タイプ) TXT
値(内容) 管理コンソールに表示された v=DKIM1; k=rsa; p=MIIBIjANBg... という長い文字列

(出典:Google Workspace ヘルプ

ここでのコツを3つ。

コツ① 手で打たない。 数百文字あります。必ずコピー&ペーストしてください。DKIMが効かないときの原因で最も多いのは、この貼り付けミスです。途中に改行が混ざる、末尾が切れる、前後に余計な空白が入る。これで動かなくなります。

コツ② ホスト名の書き方は、会社によって少し違う。 google._domainkey だけを入れる会社もあれば、google._domainkey.example.com とドメインまで書かせる会社もあります。同じ画面にある他のレコードの書き方に合わせてください。 それが一番確実です。

コツ③ 既存のレコードを消さない。 これは第7章でも書きますが、追加であって、置き換えではありません。

ステップ4:管理コンソールに戻って「認証を開始」を押す

そして、最後の1手を忘れないでください。

DNSに登録しただけでは、まだ署名は始まりません。管理コンソールに戻って、「認証を開始」を押します。

ここを押していないケースが、本当によくあります。鍵は作った。DNSにも載せた。でも「開始」を押していないので、1通も署名されていない。

正しく進むと、画面の表示が 「DKIM でメールを認証」 という状態に変わります(出典:Google Workspace ヘルプ)。

【重要】効きはじめるまで、最長48時間かかります

そして、すぐには効きません。

Googleの案内によれば、DKIM鍵を追加してからDKIM認証が機能するようになるまでに、最長で48時間ほどかかることがあります(出典:Google Workspace ヘルプ)。

これは覚えておいてください。設定した直後にテストメールを送って「効いてない!」と慌てて、設定を元に戻してしまう。 これがいちばんもったいない失敗です。

設定したら、いったん寝かせてください。 翌日、もう一度テストする。それでもだめなら翌々日。48時間経ってもだめなら、そこで初めてDNSの値を見直します。

なお、日本語の設定手順の解説としては、こちらの記事も画面の流れが分かりやすいです(G-Workspace/Google WorkspaceのDKIM・SPF設定)。

SPFのほうは、1行書くだけです

DKIMに比べれば、SPFは拍子抜けするほど簡単です。管理コンソールでの作業はありません。 DNSに1行書くだけ。

v=spf1 include:_spf.google.com ~all

これだけです。ただし第3章のとおり、すでにSPFの行があるなら、新しく作らずに、その行に足してください。


第7章 DNSに書く「3行」

ここまでの内容を、実際に書き込む形にまとめます。

ドメイン名は example.com(説明用の架空のドメイン)とします。あなたのお店のドメインに読み替えてください。

実際に書くDNSの3行。SPF、DKIM、DMARCそれぞれのホスト名・種別・値を表形式で示した図
書くのは3行だけ。ホスト名・種別・値の3項目を入れる

1行目:SPF

項目
ホスト名 @(または空欄。example.com そのもの)
種別 TXT
v=spf1 include:_spf.google.com ~all
  • 他にもメールを送るサービスを使っているなら、この1行の中に include: を並べて書く
  • 繰り返します。SPFの行は、ドメインに1つだけです

2行目:DKIM

項目
ホスト名 google._domainkey
種別 TXT
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOC...(管理コンソールが表示した長い文字列)
  • SPFと違い、DKIMは複数あってかまいません。 セレクタ(名札)が違えば共存できます
  • 貼り付けたら、必ず管理コンソールで「認証を開始」を押す

3行目:DMARC

項目
ホスト名 _dmarc
種別 TXT
v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

いちばん短くて、いちばん費用対効果の高い1行です。

部分 意味
v=DMARC1 DMARCの宣言
p=none まずは何もしない(観測モード。ここから始めます)
rua=mailto:... 成績表の送り先。 ここに毎日レポートが届く
fo=1 認証が1つでも失敗したら、詳細も報告して

rua= のアドレスは、専用のものを作ることを強くおすすめします。 毎日、世界中から機械的なレポートが届きます。普段使いの受信箱に流し込むと、確実にうんざりします。

DNSを触るときの、3つの注意

① 既存のレコードを消さない

DNSの画面には、すでにいくつも行が並んでいます。それを消してはいけません。 やるのは「追加」です。分からない行があっても、触らないでください。

② MXレコードだけは、絶対に触らない

MXレコードというのは、「このドメイン宛のメールは、ここへ配達してください」という指定です。郵便で言えば、あなたのお店の受取住所そのもの。

これを消すと、メールが送れなくなるのではなく、届かなくなります。 お客様からの返信も、予約の連絡も、全部です。SPFやDKIMを触るとき、隣にMXの行がありますが、指1本触れないでください。

③ 反映には時間がかかる

DNSは世界中に配られる台帳なので、書き換えてから世界中に行き渡るまで、数十分から数時間かかります。DKIMはさらに、前述のとおり最長48時間焦らないことです。

最後は、必ず「実物」で確かめる

設定が終わったら、チェックツールで「OK」と出ても、そこで終わりにしないでください。

私は必ず、実際にメールを1通送って、Gmailで受け取って、原文を見て確かめます。

  1. お店のアドレスから、自分のGmailに1通送る
  2. 受け取ったメールの右上「︙」から、「メッセージのソースを表示」をクリック
  3. 上のほうに、こう出ていれば完成です
SPF:   PASS
DKIM:  'PASS'
DMARC: 'PASS'

設定画面の「設定済み」は、あくまで送る側の言い分です。 効いているかどうかは、受け取った側の画面にしか書いていません。


第8章 いきなり reject にしない — 3ヶ月のロードマップ

なぜ急いではいけないのか

DMARCの解説を読むと、たいてい「最終的には p=reject を目指しましょう」と書いてあります。それは正しい。でも、明日そこへ行ってはいけません。

p=reject は、「認証が揃っていないメールは、受け取らないでください」という指示です。

もし、あなたが忘れている送信経路が1つでもあったら——その経路のメールは、その日から全部この世から消えます。 何年か前に入れた予約システムの確認メール。会計ソフトが自動で送っている請求書。誰かが個人のパソコンで設定した自動返信。

これらが迷惑メールフォルダにすら入らずに消える。しかも、送った側には何のエラーも出ないことがあります。

届かないメールを直そうとして、届いていたメールまで殺してしまう。 これは避けなければいけません。

3ヶ月かけて、階段を上る

だから、3段階で進めます。

p=none から quarantine を経て reject に至る3ヶ月のロードマップを、月ごとの階段で示した図
3ヶ月かけて、一段ずつ上る。急いで得をすることは何もない

【1ヶ月目】p=none — 見るだけ

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

この1ヶ月、メールの届き方は何も変わりません。 ただ、レポートが届き始めるだけです。

この1ヶ月でやることは1つ。

「自分のドメインから、誰が、どこから、何通送っているか」を全部洗い出す。

先ほども書きましたが、たいてい、知らない送信元が出てきます。 それを1つずつ潰していく。この1ヶ月を飛ばした人が、3ヶ月目に事故ります。

【2ヶ月目】p=quarantine; pct=10 から

正規の送信元が全部SPF・DKIMを通るようになったら、次の段階です。

v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc@example.com; fo=1

pct=10 は、「この方針を、10%のメールにだけ適用してください」という意味です。試験運用ですね。

いきなり全部に適用せず、10% → 25% → 50% → 100% と上げていく。問題が起きても、影響が10分の1で済みます。

この段階なら、万一漏れがあっても迷惑メールフォルダに入るだけです。消えはしません。お客様に「迷惑メールフォルダをご覧ください」と言えば救えます。

【3ヶ月目】p=reject

レポートを見て、不合格が正真正銘のなりすましだけになったら、最後の段階へ。

v=DMARC1; p=reject; rua=mailto:dmarc@example.com; fo=1

ここまで来ると、あなたのお店の名前をかたった詐欺メールは、受信側で拒否されるようになります。 これは守りの話に見えて、お店のブランドを守る話でもあります。お店の名をかたる詐欺メールが出回れば、被害に遭うのはお客様で、疑われるのはお店です。

3ヶ月かけられないなら、1ヶ月目だけでも

正直に申し上げると、そこまで到達しなくても、大きな効果があります。 p=none を入れてレポートを1ヶ月見るだけで、問題の大半は見つかる。見つかった問題を直せば、それだけで届き方は変わります。

いちばん費用対効果が高いのは、1ヶ月目です。


第9章 常連のお客様に「一斉に」送るときの注意

さて、ここまでで認証(第1関門)の話は終わりです。

ここからは、この記事のもう一つの主題——常連のお客様300人に、お知らせを送るという場面の話をします。

第1章の「第2関門:素行」ですね。認証を全部通しても、送り方を間違えると届かなくなります。

常連のお客様への一斉送信。GmailのBCCで送る場合の4つの問題と、配信サービスを使う場合の違いを比較した図
同じ300人に送るのでも、送り方でまったく別のことが起きる

結論から:GmailのBCCで一斉送信しないでください

いちばんやりがちなのが、これです。

Gmailを開いて、BCC欄に300人のアドレスを貼り付けて、送信。

気持ちはよく分かります。手元にアドレスがあって、Gmailもある。他に何が要るのか、と。

でも、これはやめてください。理由が4つあります。

理由①:1日の送信上限に、あっさり届く

Gmailには、1日に送れる量の上限があります。Google Workspaceのアカウントで、1日あたり約2,000通が目安とされています(個人の無料Gmailは約500通)(出典:blastengine)。

「2,000通なら300人くらい平気だろう」と思われますよね。ここに落とし穴があります。

この上限は「送信ボタンを押した回数」ではなく、宛先の人数で消費されると考えておくのが安全です。つまりBCCに300人入れた1通は、300通分。これを1日に何度かやれば、上限に届きます。

そして上限に達すると、その日はメールが送れなくなります。 メルマガだけでなく、お客様への返信も、業者さんへの発注も、全部止まります。 復旧するまで最大24時間かかることもある。

告知を送りたかっただけなのに、お店の連絡手段が丸一日止まる。 これは、避けたい事故です。

理由②:配信停止リンクを付けられない

これが、いちばん重い理由かもしれません。

お知らせを受け取ったお客様が「もう要らないな」と思ったとき、何が起きるか。

  • 配信停止リンクがあれば → クリックして、静かに去ってくれます
  • 無ければ「迷惑メール」ボタンを押します

同じ「もう要らない」でも、後者はあなたのお店のドメインの信用を直接削ります。

配信停止リンクは、迷惑メール報告を吸収するための避雷針なんです。親切心の問題ではなく、自分の身を守る仕組みとして要ります。

そして、これは法律の話でもあります。日本には 特定電子メール法(正式名称:特定電子メールの送信の適正化等に関する法律) があり、広告・宣伝を含むメールは、原則としてあらかじめ同意を得た相手にのみ送ることとされています。あわせて、送信者の氏名・名称の表示と、受信拒否(配信停止)の通知先の明示が求められます。

「秋のコースが始まりました」は、立派な宣伝です。この枠組みの中で送るものだと考えておいてください。

理由③:普段の業務メールまで、巻き添えになる

これが、いちばん怖い理由です。

BCCでの一斉送信は、普段お客様や業者さんとやり取りしているのと、まったく同じ経路で出ていきます。

ということは、その一斉送信で迷惑メール報告をされたり、宛先不明が大量に出たりすると、その悪い評価が、日常の業務メールにそのまま乗ります。

告知メールの不始末が、明日の予約の返信を殺す。

一方、メール配信サービスを使えば、告知の送信経路を、日常業務と分けられます。 これは、リスクの隔離としてとても意味があります。

理由④:宛先不明を、回収できない

BCCで300人に送ると、存在しないアドレス宛のエラー通知が、あなたの受信箱に何十通も返ってきます。

そして、たいていの人はそれを見ずに消します。 忙しいですから。

結果、死んでいるアドレスが名簿に残り続けます。 そして次回も送る。また返ってくる。また消す。この繰り返しが、じわじわとドメインの評判を削っていきます。

では、どうするか — メール配信サービスを使う

常連のお客様に定期的にお知らせを送るなら、メール配信サービスを使ってください。 月に数千円から使えるものがいくつもあります。

配信サービスを使うと、こうなります。

GmailでBCC送信 メール配信サービス
独自ドメインでのDKIM署名 自分のGmailの署名のまま 設定すれば、お店のドメインで署名できる
配信停止リンク 付けられない(手書きするしかない) 自動で付く
宛先不明の処理 自分で受信箱を見て消す 自動で検出して、次回から除外
送信上限 業務メールと共有 配信用の枠で別
開封の状況 分からない 分かる
業務メールへの影響 同じ経路なので直撃 経路が分かれる

ここで1つだけ、忘れずにやってほしいことがあります。

配信サービスを契約したら、必ず管理画面の「送信ドメイン認証」「独自ドメインの設定」といったメニューを開いて、お店のドメインで署名する設定をしてください。第5章のアライメントの話です。

これをやらないと、便箋の差出人はお店の名前なのに、封蝋は配信会社のもの、という食い違いの状態になります。配信サービスを使っているのに届かない、というときの原因は、たいていここです。

アドレスは、古くなります

そしてもう1つ、名簿そのものの話をさせてください。

メールアドレスは、放っておくと古くなります。

3年前にいただいた名刺のアドレスは、そこそこの割合で、もう存在しません。 転職された。部署が変わった。会社のドメインが変わった。個人の方でも、プロバイダを解約すればアドレスは消えます。

そして、存在しないアドレスに送ると、メールは戻ってきます。 これを バウンス(bounce / 跳ね返り / 宛先不明などで配達できずに戻ってくること) といいます。郵便の「宛先不明・転居先不明」の赤いハンコと同じですね。

問題は、このバウンスが受信側にカウントされていることです。

「この送信者は、存在しない宛先に何度も送っている。
=名簿をどこかから買ってきたか、名簿を管理していない送信者だ」

こう判定されます。そして、その判定は、あなたのドメイン全体に及びます。

古い名簿のせいで、店長が書いた「昨日はありがとうございました」の1通まで、迷惑メールフォルダに落ちるようになる。 道連れです。

だから、久しぶりの一斉送信は「新しい順に、少しずつ」

何年も送っていない名簿に、いきなり全員分を送る。これがいちばん危ないです。

やり方は2つあります。

① 新しくいただいた順に、少しずつ送る

名簿を、アドレスをいただいた日付の新しい順に並べ替えてください。そして、新しいほうから少しずつ送る。

新しいアドレスほど生きている確率が高いので、最初のうちは宛先不明がほとんど出ません。 送りながら「戻ってくる数」を見て、増えてきたらそこで一度止める。名簿の鮮度は、送ってみないと分かりません。だから、少しずつ確かめながら送るんです。

② 送る量を、少しずつ増やす

これを ウォームアップ(warm-up / 助走 / 送信量を少しずつ増やして、受信側に「まともな送信者だ」と認識してもらう期間) といいます。

考えてみてください。昨日まで1日3通だったお店のドメインが、今日いきなり300通送ったら、受信側からどう見えるか。乗っ取られたか、業者になったか、どちらかです。

初回は30通、次は50通、次は100通。面倒に思えますが、これが一番の近道です。

GmailとMicrosoftが引いた、明確な線

そしてこの「素行」の話は、もはや心構えの問題ではありません。大手のメールサービスが、数値の基準を公表しています。

Gmail(Google)の送信者ガイドライン

  • すべての送信者に、SPFまたはDKIMのいずれかと、送信元IPアドレスの逆引き(PTR / IPアドレスから名前を引けるようにする設定)が必須
  • 個人用Gmail宛に1日約5,000通以上送る「一括送信者」には、さらに次が必須
  • DMARCのアライメント(第5章の「便箋と封筒の一致」)
  • ワンクリックでの配信解除
  • 迷惑メール率 0.10% 未満の維持
  • (出典:blastenginebaremail。いずれも施行済み)

この「0.10%未満」を、よく見てください。

1,000通に1通、迷惑メール報告をされたら、もう黄色信号ということです。100人に1人ではありません。1,000人に1人です。想像よりずっと厳しいはずです。

Microsoft(Outlook.com)の要件

  • 2025年5月5日から、1日5,000通以上の送信者に、SPF・DKIM・DMARCのすべてを必須化
  • 未対応のメールは、即時ブロック(reject / 受け取り拒否)
  • 5,000通未満の送信者についても、Microsoft自身が設定を推奨している
  • (出典:baremailblastmail

「うちは1日5,000通も送らないから関係ない」——そう思われたかもしれません。私は、そうは思いません。

理由は2つ。1つは、Microsoft自身が5,000通未満にも推奨していること。もう1つは、業界の基準は必ず上から降りてくるということです。今は5,000通が線引きでも、この線が下がらない保証はどこにもありません。

そして何より、認証を通すことに、デメリットが1つもありません。 費用もかからない。かかるのは、DNSに3行書く手間だけです。


第10章 今日からのチェックリスト

長くなりました。最後に、今日・今月・3ヶ月でやることを整理します。

今日からのチェックリスト。今日15分でやること、今月やること、3ヶ月でやることを段階的に示した図
まずは「今日の15分」だけでも。それだけで現在地が分かります

🔵 今日、15分でできること

① お店のアドレスから、自分のGmailに1通送ってみる

普段お客様に送っているのと同じアカウントから送ってください。

② 届いたメールの原文を見る

Gmailで開いて、右上の「︙」→「メッセージのソースを表示」。上のほうに SPF DKIM DMARC の判定が出ています。

③ そもそも、どこに届いたか

迷惑メールフォルダも見てください。 そこにあったなら、それは「届いた」ではありません。

この15分で、あなたのお店の現在地が分かります。 3つとも PASS なら、第1関門は突破しています。

🟡 今月やること

  • [ ] Google Workspaceの管理コンソールで、DKIMを有効にする(第6章の4手。ここが最優先)
  • [ ] SPFが「1行かどうか」を確かめる(「SPF チェック」で検索すると無料ツールが出ます。2行あれば即まとめる/permerrorが出たら壊れています)
  • [ ] DMARCを p=none で追加する(第7章の3行目。届き方は今日と変わりません)
  • [ ] メールの送信経路を、紙に書き出す
  • 普段のメールは?(Google Workspace)
  • 予約システムは、お店の名前でメールを出していないか?
  • 昔契約して、まだ生きているサービスはないか?

最後の2つが、たいてい伏兵です。

🟢 3ヶ月でやること

  • [ ] DMARCのレポートを1ヶ月眺める(無料の解析サービスに転送してグラフで見る)
  • [ ] 知らない送信元を、1つずつ潰す
  • [ ] p=quarantinepct=10 から)→ p=reject へ、段階的に上げる
  • [ ] 常連のお客様への配信を、メール配信サービスに移す
  • [ ] 名簿の棚卸し
  • [ ] このアドレスは、送っていいと言っていただいたアドレスか?
  • [ ] いつ、いただいたアドレスか?(3年以上前のものは要注意
  • [ ] 配信停止の案内は、全部のメールに入っているか?

おわりに — メールだけが、「自分の名簿」です

長い記事にお付き合いいただき、ありがとうございました。最後に、少しだけ思うところを書かせてください。

飲食店の集客の話をすると、たいていSNSの話になります。私も本を1冊書いたくらいですから、否定するつもりは毛頭ありません。

ただ、メールというのは、いまだに恐ろしく強い道具です。理由は単純で、メールだけが「自分の名簿」だからです。

SNSのフォロワーは、借り物です。プラットフォームの都合で表示されなくなることもあれば、アカウントごと止まることさえある。あの数字は、あなたのものではありません。

でも、メールアドレスの名簿は、あなたのお店の資産です。 誰にも取り上げられない。明日サービスが変わっても、手元に残ります。

そして、常連のお客様というのは、あなたのお店にとっていちばん価値のある名簿のはずです。何度も足を運んでくださって、アドレスまで教えてくださった方々です。

その方々に送ったお知らせが、迷惑メールフォルダで死んでいるとしたら。

これほどもったいない話は、そうありません。しかも、そのことは誰も教えてくれません。 料理が遅ければ怒られます。予約が取れなければ怒られます。でも、お知らせが届かなかったお客様は、怒りません。ただ、知らないまま来店されないだけです。

だから、こちらから見に行くしかないんです。

やることは、管理コンソールで4手、DNSに3行。 費用はかかりません。かかるのは、半日ぶんの手間だけです。それで、常連のお客様に届くはずだったお知らせが、届くようになる。

まずは、今日の15分。

お店のアドレスから自分のGmailに1通送って、原文を開いてみてください。PASS が3つ並んでいたら、素晴らしい。並んでいなかったら——それは、直せるということです。

あなたのお店からのお知らせは、今日、ちゃんと常連さんの受信箱に入っていますか。


㈱デリシャスノーツでは、飲食店さまの独自ドメインのメール環境(Google Workspace/送信ドメイン認証 SPF・DKIM・DMARC)の設定代行と、常連のお客様へのメール配信のご支援もしています。「うちの店のメール、ちゃんと届いているか調べてほしい」というご相談は、お問い合わせフォームよりお寄せください。

この記事が気に入ったら
いいね または フォローしてね!

是非シェアしてもらえると嬉しいです!
  • URLをコピーしました!
目次