ニュースレター時代に必須となったドメイン認証——SPF・DKIM・DMARC を今すぐ確認すべき理由

ここ1〜2年、まわりの個人クリエイターや中小事業者から、メール配信に関する相談が急に増えた。「Gmail への到達率がガクッと落ちた」「Yahoo! メール宛に送ったメールが迷惑メール扱いされる」「ドコモ宛のメールに『なりすましの可能性』という警告が表示される」。話を聞くと、ほぼ全員、自分のドメインから直接メールを送っているのに SPF・DKIM・DMARC のどれも設定していない、もしくは中途半端な設定のまま放置されていた。

これは偶然ではない。2024年2月、Google と Yahoo! が大量送信者向けの新ガイドラインを実運用に乗せて以降、メール業界の景色は完全に変わった。その波は2024年12月の Yahoo! JAPAN、2025年5月の Microsoft Outlook.com にも広がり、認証していないドメインからのメールは「届かない」が当たり前になりつつある。

そしてもうひとつ、この話題と切り離せないのが 「ニュースレターの再評価」 という潮流だ。

SNS アルゴリズムから逃れたい、という疲労感

X、Instagram、Threads、TikTok、LinkedIn——どのプラットフォームを開いても、自分のフォロワーに本当に届いているのかが分からない。タイムラインの大半は、もはや知らない誰かのアルゴリズム推薦で構成されている。Substack は2025年、わずか3か月でアプリ内から3,200万人の新規購読者を獲得したと公表しており、読者の獲得が外部 SNS や SEO ではなく、配信プラットフォーム自身のディスカバリ機能を通じて起こる現象が加速している。

その流れと並行して、書き手のあいだで繰り返し語られているのが「自分のリストを持て」という呪文だ。プラットフォームから締め出される、ある日突然リーチが落ちる、アルゴリズムが嗜好を変える——そうした不確定性に対して、メールアドレスのリストはおそらく現存する最も古典的で、かつ最も「自分のもの」と言える資産になる。だからこそニュースレターは2026年も静かに重要性を増し続けている。

ところが、ここに大きな落とし穴がある。そのメール、ちゃんと届いてますか？

2024〜2025年に起きた、メール配信の構造変化

Google は Gmail 宛に1日5,000通以上送る送信者に対し、SPF・DKIM・DMARC の設定を必須化した。Yahoo! も同様に DMARC を含む認証を要求し、Microsoft Outlook.com は2025年5月以降、要件を満たさないメールを 550; 5.7.515 Access denied で拒否するようになっている。docomo は2024年10月から、認証エラーのメールに端末画面で「なりすましメールの可能性」と注意喚起を表示している。Yahoo! メールも2024年12月、SPF・DKIM・DMARC のいずれも通っていないメールは迷惑メール判定もしくは受信拒否の対象になりうると公表した。

「自分は1日5,000通も送ってないから関係ない」と思うかもしれない。でもそれは半分しか正しくない。受信側プロバイダのスパム判定エンジンは、大量送信者向けに引き上げた基準を全送信者にじわじわ反映させていく。送信ドメインのレピュテーション（信頼スコア）は静かに下がり、気付いたときには個人事業者からの請求書メールが顧客のスパムフォルダに沈んでいる、という事例が頻発している。

加えて、日本の状況は世界平均よりも深刻だ。Proofpoint によれば、2025年2月に世界で観測された新種のメール攻撃のうち、なんと80.2%が日本をターゲットにしていた。4月にはこの比率が83.6%まで上昇している。生成 AI の普及で「日本語が不自然だから詐欺メールと分かる」という時代も終わり、本物との見分けはほぼ目視では不可能になった。フィッシング対策協議会への報告件数は2025年で累計約245万件にのぼり、6年連続で過去最多を更新している。

ドメイン認証はもはや「セキュリティ意識の高い大企業のたしなみ」ではなく、ニュースレターを発行するなら欠かせないインフラになった。

SPF、DKIM、DMARC——三層防御をフラットに整理する

3つの専門用語に毎回めまいがするので、自分も復習を兼ねて改めて整理しておきたい。

SPF（Sender Policy Framework） は、「うちのドメインから送るメールは、これらのサーバー（IP）からだけです」と DNS に宣言する仕組みだ。DNS の TXT レコードに v=spf1 include:_spf.google.com include:mailgun.org ~all のような文字列を書くと、受信メールサーバーはまずそこを参照する。送信元 IP がリストに無ければ、そのメールは怪しいと判定される可能性が高くなる。ただし SPF は Envelope From（Return-Path）ドメインしか見ないので、表示される From: ヘッダーが偽装されていても素通りしてしまう。SPF だけでは、なりすまし防止としては不完全だ。

DKIM（DomainKeys Identified Mail） は、メールに電子署名を貼る仕組みだ。送信側はメールのヘッダーや本文の一部を秘密鍵で署名し、受信側は DNS に公開された公開鍵でその署名を検証する。署名が一致すれば「このメールは確かにこのドメインから出ており、途中で改ざんされていない」と確認できる。2026年時点では1024ビット鍵は弱いとされ、2048ビット鍵が推奨水準になっている。Resend、SendGrid、Mailgun のような SaaS は通常2048ビットで DKIM を発行してくれるので、設定をサボらず最後まで通しておきたい。

DMARC（Domain-based Message Authentication, Reporting and Conformance） は、SPF と DKIM の結果を踏まえ、「認証に失敗したメールをどう扱ってほしいか」を送信側が宣言するレイヤーだ。p=none（観測のみ）、p=quarantine（迷惑メール扱い）、p=reject（受信拒否）という3段階のポリシーがあり、rua=mailto:dmarc@example.com のように指定して認証結果のレポートも受け取れる。

DMARC の本当の価値は、From: ヘッダーのドメインと、SPF や DKIM で認証されたドメインが一致しているかという アライメント検証 にある。これによって From 詐称型のなりすましを構造的に塞げる。SPF と DKIM だけだと、From を別ドメインにすり替えた攻撃を素通しさせてしまうため、DMARC が三層目の蓋として機能する。

日本の現状——「導入はしたけど運用していない」が圧倒的

JSSEC の調査によると、東証 Top 225企業の DMARC 導入率は2025年9月時点で約90%まで急増した。2024年2月の Gmail と Yahoo! の要件発表に押された結果と言える。日経も2024年2月時点で「日経平均225社の DMARC 導入率は85.8%に急増した」と報じており、大企業層では一気に対応が進んでいる。

ただ、問題はその先だ。Hornetsecurity が2025年6月に行った調査では、日本語サイトを持つ約20万ドメインのうち DMARC を設定していたのは40%、しかし最も厳格な p=reject を運用していたのはわずか 1.8% にとどまる。多くのドメインが p=none（観測のみ）で止まっており、実効性のある防御ができていない。レコードを書いただけで「やった気になっている」状態だ。

そして攻撃者はそこを突いてくる。p=none のドメインを狙ってなりすましを送りつけるという手口は、すでに日本で恒常化している。自分のドメインがなりすまし攻撃の踏み台になれば、IP やドメインのレピュテーションはどんどん下がり、最終的に 正規のメールも顧客に届かない 状態に追い込まれる。

警察庁の2025年上半期のレポートによると、法人を狙ったインターネットバンキング不正送金被害額は22.7億円に達し、すでに2024年通年の11.2億円を半年で超えている。なりすましメールは入口の一つだ。

今すぐの確認方法と、最初のアクション

技術ブロガーとして、Claude Code を開いて DNS をいじりに行く前に確認しておきたい現実的な手順を3つだけ挙げておく。

まず、自分のドメインの現状を把握する。MXToolbox の SuperTool、CheckDMARC、Red Sift Investigate などのオンラインツールで SPF・DKIM・DMARC のレコードがあるかを一発で確認できる。手元のターミナルからなら dig TXT yourdomain.com と dig TXT _dmarc.yourdomain.com を打てば DNS から直接見える。

次に、DMARC をまず p=none で立てて、レポートを受け取る。これによって、自分のドメイン名で実際にどこから何通のメールが送信されているかが可視化される。社内で誰も把握していない外部サービス（古い SaaS、過去のメール配信ツール、退職者が契約したツールなど）が今もメールを送り続けている、というのは想像以上によくある話だ。レポートを数週間眺めて全送信元を洗い出してから、p=quarantine、p=reject へと段階的に上げていくのが王道だ。

最後に、ニュースレター用の送信サービスを選ぶ際、必ず SPF/DKIM/DMARC 対応を確認する。Substack、Beehiiv、Buttondown、ConvertKit、Mailchimp、Resend など、まともな配信サービスはどれも DKIM と SPF をドメインに紐付ける手順を提供している。だが、自分のドメインで配信するなら、その手順を最後まで完了させること。「とりあえず立てて公開」で放置すると、最初の数百通でドメインのレピュテーションを焼くことになる。

ニュースレターを「自分のチャネル」として育てるために

自分は Claude Code のヘビーユーザーで、ターミナルで DNS レコードを編集すること自体は苦にならない。それでも、SPF・DKIM・DMARC の設定を「まあ後でいいか」と先延ばしにしていた時期があった。「とりあえず動いているからいいか」 という心理は、エンジニアでも普通にある。

でも今、ニュースレターという媒体に賭けるなら、その入口で最も効くのは「届ける技術」だと感じている。文章の質も、配信頻度も、ニッチ選びも当然大事だが、読者の受信箱に届かないニュースレターには価値が積み上がらない。SNS のアルゴリズムから降りて自分のチャネルを持とうとしているのに、その自分のチャネルが受信側プロバイダに門前払いされていては元も子もない。

SNS がどれだけアルゴリズムを変えても、自分のドメインから送るメールは自分のものだ。だからこそ、その土台にあるドメイン認証は今日にでも触っておきたい。ドメインを持っていてメールを送ったことがあるすべての人に、まずは dig TXT _dmarc.あなたのドメイン を打ってみることをおすすめしたい。何も返ってこなければ、そこがスタート地点だ。