最近、メール・アドレスの詐称、ウイルス添付等が多いのでメールセキュリティーを強化した方が良いでしょう。
小規模企業や個人事業主でも簡単にできますので、是非導入しましょう。サーバーが対応していない等の制約がある場合SAASを活用できます。
お手軽な価格の対応サーバーは、Xサーバーとコアサーバーです。
【2025年〜2026年最新】なぜ今SPF・DKIM・DMARCが必須なのか
メール認証の重要性は年々高まっており、2024年以降は大手メールサービスが相次いでSPF・DKIM・DMARCの設定を事実上の義務としています。この流れを知らずに放置していると、自社のビジネスメールが相手に届かなくなるリスクがあります。
Googleの送信者ガイドライン（2024年2月〜）
Googleは2024年2月1日より、Gmailアカウント宛にメールを送信するすべての送信者に対して、SPFまたはDKIMによる送信ドメイン認証を義務付けました。さらに、1日あたり5,000通以上のメールを送信する大量送信者に対しては、SPF・DKIM・DMARCの3つすべての設定が必須とされています。これらの要件を満たさないメールは、迷惑メールフォルダに振り分けられたり、受信を拒否される可能性があります。
Microsoftの新要件（2025年5月〜）
Microsoftも2025年5月5日より、Outlook.com（@outlook.com、@hotmail.com、@live.com）宛に1日5,000通以上のメールを送信するドメインに対して、SPF・DKIM・DMARCの3つの認証設定を必須化しました。未対応の場合、まず迷惑メールフォルダに振り分けられ、継続的に準拠しない場合は最終的にメール自体が拒否されるようになります。
日本企業のDMARC導入状況
プルーフポイント社の2025年12月の調査によると、日経225企業のDMARC導入率は92%に達しました。1年前の83%から9ポイント増加しており、大企業を中心に急速に普及が進んでいます。しかし、中小企業や個人事業主ではまだ対応が遅れているケースが多く、取引先へのメールが届かないといったトラブルが増えています。もはやSPF・DKIM・DMARCの設定は「やった方がいい」ではなく「やらなければならない」フェーズに入っています。
SPF・DKIM・DMARCの関係を理解する
SPF・DKIM・DMARCはそれぞれ独立した技術ですが、3つを組み合わせることで初めて強固なメール認証が実現します。それぞれの役割を郵便に例えると分かりやすいでしょう。
SPFは「この差出人名義の郵便を出してよい郵便局（IPアドレス）はここだけです」と届け出る仕組みです。受取人側は、届いた手紙がその届出済みの郵便局から実際に出されたかどうか（＝IPアドレスの一致）を確認します。レンタルサーバーの場合、SPFレコードにはサーバーのIPアドレスを指定するのが一般的です。
DKIMは、差出人が自分のドメイン名に紐づいた印鑑（秘密鍵）で手紙に封蝋（ふうろう）を押す仕組みです。受取人はその印鑑の照合情報（公開鍵）をDNS上で確認し、「確かにそのドメインの持ち主が送ったもので、途中で改ざんされていない」ことを検証します。SPFがIPアドレスによる送信経路の認証であるのに対し、DKIMはドメインに基づく送信者そのものの認証と改ざん検知を行う点が異なります。
そしてDMARCは「SPFのIPアドレス検証やDKIMのドメイン署名検証に失敗した手紙が届いた場合、こう処理してください」と受取人側に指示を出す仕組みです。さらに、処理結果を差出人に報告（レポート）する機能も備えています。
この3つが揃って初めて、なりすましメールを検知し、適切に処理し、さらにその状況をドメイン所有者に報告するという一連のセキュリティ対策が完成します。
SPF
SPF (Sender Policy Framework) は、メールの送信元アドレスを偽装することを防止するためのメール認証技術の1つです。
SPFでは、ドメイン名に関連付けられたDNSレコードに、送信元メールサーバーのIPアドレスが登録されます。メールサーバーがメールを送信する際に、受信側のメールサーバーは送信元メールサーバーのIPアドレスがドメイン名に関連付けられたIPアドレスと一致するかどうかを確認します。もし一致しない場合は、そのメールはSPF認証に失敗したとして、受信側のメールサーバーはそのメールをスパムとして処理することができます。
SPFは、スパムメールやフィッシング詐欺などの攻撃から受信者を保護するのに役立ちます。ただし、SPFは偽装された送信元アドレスを持つメールを完全に防ぐわけではなく、他のメール認証技術と併用することが推奨されます。
SPFレコードの設定方法と具体例
SPFレコードはDNSのTXTレコードとして設定します。基本的な書式は以下の通りです。
example.com. IN TXT "v=spf1 include:_spf.google.com ~all"この例では、example.comというドメインから送信されるメールは、Googleのメールサーバー（_spf.google.com）からの送信のみを正当と認めることを意味しています。末尾の「~all」はソフトフェイル（認証失敗でも完全拒否はしない）を示します。
SPFレコードで使用される主な要素は以下の通りです。「v=spf1」はSPFのバージョンを示す必須の宣言です。「include:」は外部ドメインのSPFレコードを参照する指定で、Google Workspace、Microsoft 365、各種メール配信サービスなどを利用している場合に使います。「ip4:」は送信を許可するIPv4アドレスを直接指定するもので、自社メールサーバーのIPアドレスを指定する際に使います。「a」はドメインのAレコードに設定されたIPを許可し、「mx」はMXレコードに設定されたサーバーのIPを許可します。末尾の「-all」はハードフェイル（認証失敗は拒否を推奨）、「~all」はソフトフェイル（認証失敗でもマークする程度）を意味します。
複数のメールサービスを利用している場合は、1つのSPFレコードにまとめて記述します。例えば、自社サーバーとGoogle Workspaceの両方を使っている場合は次のようになります。
example.com. IN TXT "v=spf1 ip4:203.0.113.1 include:_spf.google.com ~all"なお、SPFレコードには「DNSルックアップ回数は10回まで」という制限があります。includeを多数使う場合はこの上限に注意してください。
DKIM
DKIM (DomainKeys Identified Mail) は、メールの送信元認証技術の1つで、メールが改ざんされていないことや、本当にそのドメインから送信されたものであることを確認するために使用されます。
DKIMでは、メール送信元のドメインの秘密鍵を使用して、メールのヘッダーや本文に署名を付けます。受信側のメールサーバーは、その署名を公開鍵で検証し、メールが改ざんされていないことを確認します。また、ドメイン名が送信元と一致することも確認します。もし署名が正当でない場合は、そのメールは認証に失敗したとして、受信側のメールサーバーはそのメールをスパムとして処理することができます。
DKIMは、SPFと同様に、スパムメールやフィッシング詐欺などの攻撃から受信者を保護するために役立ちます。また、DMARCという別のメール認証技術と組み合わせて使用することで、メール送信元の認証をより強固にすることができます。
DKIMの仕組みをもう少し詳しく
DKIMは公開鍵暗号方式を使ったメール認証技術です。その仕組みを順を追って説明します。まず、ドメイン所有者が秘密鍵と公開鍵のペアを生成し、公開鍵をDNSのTXTレコードとして公開します。メールを送信する際、送信サーバーは秘密鍵を使ってメールヘッダーや本文からデジタル署名を生成し、メールヘッダーに「DKIM-Signature」として付与します。受信サーバーはメールを受け取ると、DKIM-Signatureヘッダーから署名ドメインとセレクタを読み取り、そのドメインのDNSから公開鍵を取得します。取得した公開鍵を使って署名を検証し、メールが改ざんされていないか、本当にそのドメインから送信されたものかを確認します。
DKIMレコードの設定例
DKIM用の公開鍵はDNSのTXTレコードとして以下のような形で設定します。
selector._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GN..."「selector」の部分はDKIMセレクタと呼ばれ、レンタルサーバーやメールサービスごとに指定された値を使います。例えばGoogle Workspaceでは「google」、エックスサーバーでは「default」がセレクタとして使われることが一般的です。「v=DKIM1」はDKIMのバージョン、「k=rsa」は暗号方式、「p=」以降が公開鍵のデータです。
多くのレンタルサーバーやクラウドメールサービスでは、管理画面からDKIMを有効化すると自動的に鍵ペアが生成され、設定すべきDNSレコードが表示されます。表示されたレコードをDNSに登録するだけで設定が完了するケースがほとんどです。
DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) は、メールの送信元認証技術の1つで、SPFとDKIMを組み合わせたものです。DMARCを使用することで、ドメインの所有者は、自分のドメイン名を悪用するスパムやフィッシング詐欺メールを防止することができます。
DMARCでは、SPFとDKIMの両方が成功したかどうかを確認し、その結果に基づいてメールの配信を決定します。具体的には、ドメインの所有者は、ドメインに関するDMARCポリシーを設定し、メール送信元がSPFとDKIMのどちらか、または両方に合格しなかった場合にどのように処理するかを指定します。このポリシーには、送信元が認証に失敗した場合にメールを拒否するか、スパムフォルダーに移動するか、受信者に通知するかなどの指示が含まれます。
また、DMARCでは、送信元ドメインの認証結果を報告するための仕組みも提供されます。これにより、ドメインの所有者は、誰が彼らのドメイン名を悪用しているかを把握し、それに対処することができます。
DMARCを使用することで、受信者は、ドメインの所有者が設定したポリシーに従ってメールが配信され、スパムやフィッシング詐欺メールなどの攻撃から保護されます。
DMARCの「アライメント」とは
DMARCを正しく理解する上で欠かせないのが「アライメント（整合性）」という概念です。アライメントとは、メールの「From:」ヘッダーに表示されるドメイン（受信者が目にする送信者アドレス）と、SPFやDKIMで認証されたドメインが一致しているかどうかを検証する仕組みです。
SPFの場合、エンベロープFrom（Return-Path）のドメインとヘッダーFromのドメインが一致しているかを確認します。DKIMの場合は、DKIM署名に含まれる「d=」タグのドメインとヘッダーFromのドメインが一致しているかを確認します。DMARCの認証に合格するためには、SPFまたはDKIMのいずれか一方が「認証成功」かつ「アライメント合格」である必要があります。
アライメントには「strict（厳格）」と「relaxed（緩和）」の2つのモードがあります。strictモードではドメインが完全一致している必要がありますが、relaxedモード（デフォルト）ではサブドメインも許容されます。例えば、ヘッダーFromが「example.com」でDKIM署名のドメインが「mail.example.com」の場合、relaxedモードなら合格しますが、strictモードでは不合格になります。
DMARCレコードの設定方法と具体例
DMARCレコードもDNSのTXTレコードとして設定します。ホスト名は「_dmarc.ドメイン名」とします。
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"この設定例の各要素について説明します。「v=DMARC1」はDMARCのバージョン宣言（必須）です。「p=」はポリシーを指定するもので、「none」は認証失敗しても何もしない（モニタリングのみ）、「quarantine」は認証失敗メールを隔離（迷惑メールフォルダへ）、「reject」は認証失敗メールを拒否、の3段階があります。「rua=」は集約レポート（Aggregate Report）の送信先メールアドレスです。
DMARCの導入は段階的に進めるのが推奨されています。最初は「p=none」で運用を開始してレポートを収集し、自ドメインからどのようなメールが送信されているかを把握します。問題がないことを確認した後に「p=quarantine」へ移行し、最終的に「p=reject」まで引き上げるのが理想的です。いきなり「p=reject」に設定すると、正当なメールまで拒否されてしまう恐れがあるため注意が必要です。
DMARCレポートの活用
DMARCレコードに「rua=」を設定すると、受信側のメールサーバーからXML形式の集約レポートが定期的に送られてきます。このレポートには、あなたのドメインを名乗って送信されたメールのSPF・DKIM認証結果、送信元IPアドレス、メール通数などの情報が含まれます。
レポートはXML形式のため、そのままでは読みにくいですが、DMARCレポート解析サービス（EasyDMARC、PowerDMARC、Valimail、dmarcianなど）を利用すると、グラフや表で視覚的に把握できます。レポートを分析することで、自ドメインを悪用したなりすましメールの実態を把握し、SPF・DKIMの設定漏れを発見し、ポリシーを段階的に強化するための判断材料を得ることができます。
SPF・DKIM・DMARCの設定手順まとめ
ここでは、SPF・DKIM・DMARCを実際に設定する際の一般的な手順を解説します。具体的な操作はお使いのレンタルサーバーやDNS管理サービスによって異なりますが、基本的な流れは共通しています。
ステップ1：SPFレコードの設定
まず、お使いのDNS管理画面にアクセスし、ドメインのTXTレコードとしてSPFレコードを追加します。レンタルサーバーの管理画面にSPFの設定項目がある場合は、そこから有効化するだけで自動的にDNSレコードが追加されるケースもあります。自社サーバーに加えて外部のメール配信サービス（MailChimp、SendGridなど）を使っている場合は、そのサービスのinclude指定も忘れずに追加してください。
ステップ2：DKIMの設定
レンタルサーバーやメールサービスの管理画面でDKIM署名を有効化します。有効化すると、DNSに登録すべきTXTレコード（公開鍵）が表示されるので、それをDNSに追加します。DNSの反映には数分〜数時間かかる場合がありますので、設定後すぐにテストが失敗しても焦らず待ちましょう。
ステップ3：DMARCレコードの設定
DNSに「_dmarc.ドメイン名」というホスト名でTXTレコードを追加します。最初はモニタリング用として「v=DMARC1; p=none; rua=mailto:あなたのメールアドレス」で開始するのがおすすめです。レポートを数週間〜数ヶ月収集し、問題がなければポリシーを段階的に強化していきます。
ステップ4：設定の確認
設定が完了したら、必ず動作確認を行いましょう。確認方法としては、自分宛にテストメールを送信してメールヘッダーを確認する方法と、オンラインのチェックツールを使う方法があります。Gmailでメールを受信した場合は、メールを開いて「メッセージのソースを表示」を選択すると、SPF・DKIM・DMARCそれぞれの認証結果が「PASS」「FAIL」等で表示されます。
設定確認に使えるチェックツール
SPF・DKIM・DMARCの設定が正しく行われているかを確認できる無料のオンラインツールがあります。
MXToolbox（mxtoolbox.com）は、SPF・DKIM・DMARCのレコード検証に加え、MXレコードやブラックリストのチェックも行える総合的なツールです。ドメイン名を入力するだけで各レコードの内容と問題点を確認できます。
Google Admin Toolbox（toolbox.googleapps.com）は、Google提供のDNSレコード確認ツールです。TXTレコードの内容をそのまま確認でき、SPFやDMARCの設定値を直接チェックする際に便利です。
dmarcian（dmarcian.com）は、SPF・DKIM・DMARCそれぞれの専用チェックツールを提供しており、レコードの構文チェックや問題点の指摘が詳細に行われます。
なりすまし対策ポータル ナリタイ（naritai.jp）は、日本語で利用できるDMARC・DKIMチェックツールです。check@naritai.jp に空メールを送信すると、そのメールのSPF・DKIM・DMARCの認証結果を返信で教えてくれます。
対応レンタルサーバー比較（2026年最新）
以下は、2026年2月時点でSPF・DKIM・DMARCに対応している主なレンタルサーバーの情報です。記事公開当初（2023年2月）と比べて対応サーバーが大幅に増えていますので、参考にしてください。
フル対応（SPF・DKIM・DMARC送受信認証 + DMARCレポート送付対応）
ConoHa WING / ConoHa VPSは、送信側のSPF・DKIM・DMARC署名に対応し、受信側でもSPF・DKIM・DMARCの認証を行います。DMARCレポートの送付にも対応しており、最も完全なメール認証環境を提供するサーバーの1つです。
お名前.com レンタルサーバー（RSプラン）／お名前メール（エコノミー・ベーシックプラン）も、ConoHaと同等のフル対応です。ただし、旧プラン（SDプラン、ライト/スタンダードプラン）は非対応のため、必要に応じてRSプランへの乗り換えが必要です。
送信側DKIM署名 + 受信側認証対応（DMARCレポート送付は非対応または一部対応）
エックスサーバーは、送信側のSPF・DKIM・DMARCに対応し、受信側でもSPF・DKIM・DMARCの認証を行います。DMARCレポートの送付には非対応ですが、メール認証の基本的な機能は十分に揃っています。国内シェアNo.1のレンタルサーバーであり、安心して利用できます。
さくらのレンタルサーバ／さくらのメールボックスは、SPF・DKIM・ARC・DMARCに対応しています。ARCにも対応しているため、メール転送時の認証破損にも対処できる点が特徴です。全プラン（ライト〜ビジネスプロ）で利用可能です。
コアサーバー（V1/V2プラン）は、送信側のSPF・DKIM・DMARCに対応し、受信側でもSPFとDKIMの認証を行います。低価格プランでもDKIM対応している点が魅力です。
XREA（エクスリア）は、無料プランでもSPF・DKIM・DMARCの送信に対応しています。コストをかけずにメール認証を始めたい場合の選択肢になります。
バリューサーバーもGMOデジロック系列として、SPF・DKIM・DMARCの基本的な送信対応が利用できます。
よくある質問（FAQ）
Q. SPF・DKIM・DMARCは個人のブログやサイトでも設定が必要ですか？
独自ドメインでメールを使っている場合は、個人であっても設定を強くおすすめします。設定していないと、お問い合わせフォームからの通知メールが相手に届かなかったり、メールマガジンが迷惑メール扱いされたりする原因になります。特に2024年以降、GmailやOutlookの基準が厳格化されているため、メールが相手に届かないトラブルが増えています。
Q. SPFだけ設定すれば十分ですか？
SPFだけでは不十分です。SPFは送信元IPアドレスの確認のみを行うため、メール本文の改ざんを検知できません。また、DMARCのアライメントチェックを通過するためにはDKIMの設定も重要です。GoogleやMicrosoftのガイドラインでも、SPF・DKIM・DMARCの3つすべてを設定することが推奨（大量送信者は必須）されています。
Q. DMARCのポリシーはいきなり「reject」にしても大丈夫ですか？
いきなりrejectにするのは危険です。自社が把握していないメール送信サービス（社内の別部署が使っているツール、SaaS連携メールなど）が認証に失敗して拒否されてしまう可能性があります。まずは「p=none」でレポートを収集し、すべての正当な送信元を把握してからポリシーを段階的に強化してください。
Q. SPFレコードの「~all」と「-all」はどちらがいいですか？
最終的には「-all」（ハードフェイル）が推奨されますが、設定直後はまず「~all」（ソフトフェイル）で運用を始め、問題がないことを確認してから「-all」に変更するのが安全です。DMARCをあわせて導入する場合は、DMARCポリシー側で処理を制御できるため、SPFは「~all」のままでも実質的な問題は少ないという考え方もあります。
Q. サーバーがDKIMに対応していない場合はどうすればいいですか？
サーバーがDKIMに対応していない場合は、メール配信にSaaS型のメールリレーサービス（SendGrid、Amazon SES、Mailgunなど）を利用する方法があります。これらのサービスではDKIM署名を付与してメールを送信できるため、サーバー側の制約を回避できます。また、DKIM対応のレンタルサーバーへの移行を検討するのも有効です。
Q. メール転送をしている場合、SPFやDKIMが壊れると聞きましたが？
メール転送はSPFやDKIMの認証を破損させる原因になりえます。転送時にIPアドレスが変わるためSPFが失敗し、メール本文が変更される場合はDKIM署名も無効化されます。この問題に対処するためにARC（Authenticated Received Chain）という技術があり、さくらインターネットなど一部のサーバーではARC対応が進んでいます。メール転送を多用する環境では、ARC対応のサーバーを選ぶとよいでしょう。
まとめ
SPF・DKIM・DMARCは、現在のメール運用において必須のセキュリティ対策です。2024年のGoogleの送信者ガイドライン強化、2025年のMicrosoftのOutlook認証義務化を経て、これらの設定なしにはビジネスメールが正常に届かない時代になりました。
設定自体はDNSにTXTレコードを追加するだけのシンプルな作業ですが、正しく設定しないと逆にメール配信に支障をきたす場合もあります。まずは現在の設定状況をチェックツールで確認し、不足があれば順にSPF → DKIM → DMARCの順で導入を進めましょう。DMARCは「p=none」からスタートし、レポートを分析しながら段階的にポリシーを強化していくことが、安全かつ確実な導入の鍵です。
