メール設定で出てくるSPF・DKIM・DMARC・ARCとは？MXレコードとの違いもやさしく解説

PHPでメールを送るファイルを書いたあと、次にやることとして出てきたのがこのメール設定です。

メール設定で出てくるSPF・DKIM・DMARC・MX。

私は独学でWebの仕事をしてきましたが、メールの設定まわりはまだ初学者で、この言葉たちが何を意味しているのかわかりませんでした。

アルファベットの略語が並んでいるだけなので、どれが何の役割なのか見分けがつきません…

そこで、自分の理解のためにも、調べた内容を初心者目線でまとめることにしました。

記事の後半では、私がさくらのレンタルサーバでDKIM・ARC・DMARCを設定した手順も載せています。

用語の解説部分は、Googleやさくらインターネットの公式ヘルプなどで調べた内容をもとにまとめた調査情報です。
実際に私が操作したのは、後半の「さくらのレンタルサーバで設定した手順」の部分です。
設定画面の見た目や手順は、使っているレンタルサーバー・ドメイン会社によって違うため、実際に設定するときは各社のマニュアルもあわせて確認をお願いします。

SPF・DKIM・DMARC・MX・ARCをひとことで言うと？全体像を郵便にたとえて整理
そもそもどこに書く設定なの？DNSとレコードの話
【1】MXレコードとは？メールの届け先を決める設定
1. MXレコードが間違っているとどうなる？
【2】SPFとは？送ってよいサーバーの名簿
1. SPFだけでは足りない理由
【3】DKIMとは？メールに押す電子の印鑑
【4】DMARCとは？確認に失敗したメールの扱い方を決めるルール
【5】ARCとは？転送されたメールの認証結果を引き継ぐ仕組み
なぜ今この設定が大事なの？Gmailの送信者ガイドライン
設定はドメイン会社？サーバー会社？ネームサーバーで決まる
【実践】さくらのレンタルサーバでDKIM・ARC・DMARCを設定した手順
設定できているか確認する方法
1. 初心者がつまずきやすいポイント
まとめ

SPF・DKIM・DMARC・MX・ARCをひとことで言うと？全体像を郵便にたとえて整理

細かい話に入る前に、５つの役割を郵便にたとえて一覧にしてみました。

調べていて、この５つはMXだけが受け取る側の設定、残りの４つは送る側のなりすまし対策という分け方をすると頭に入りやすいと思いました。

用語	ひとことで言うと	郵便でいうと	関係するのは
MX	このドメイン宛のメールを受け取るサーバーの住所	手紙の届け先の住所	受信
SPF	このドメインのメールを送ってよいサーバーの名簿	正規の郵便局の一覧表	送信
DKIM	メールにつける電子署名	封筒に押す印鑑と、その印鑑証明	送信
DMARC	SPF・DKIMで確認に失敗したメールの扱い方のルール	怪しい手紙を受け取ったときの対応マニュアル	送信
ARC	転送されたメールの認証結果を引き継ぐ仕組み	途中の郵便局が書き足していく確認済みの記録	転送

SPF・DKIM・DMARCの3つは、まとめて送信ドメイン認証と呼ばれています。

ARCは、その送信ドメイン認証を転送のときにも活かすための補助的な仕組みです。

ここからは、ひとつずつ解説していきます！

そもそもどこに書く設定なの？DNSとレコードの話

4つとも、書く場所は同じでDNS（ディーエヌエス）という仕組みの中です。

DNSは、ドメインに関する情報をまとめて登録しておく住所録のようなものです。

この住所録に1行ずつ登録する情報のことをレコードと呼びます。

ドメインの管理画面やレンタルサーバーの管理画面で「DNSレコード設定」のような項目を開くと、種別の欄にA・MX・TXTなどが並んでいます。

ここで覚えておきたいのは、MXはMX専用の種別があるのに対して、SPF・DKIM・DMARCはTXTという種別で書くということです。

TXTは、自由な文字列を登録できる種別です。

調べた範囲では、以前はSPF専用の種別も用意されていましたが、現在は使わないことになっていて、TXTで書くのが標準になっているようです。

ARCだけは少し違っていて、DNSに専用のレコードを書くのではなく、メールを中継するサーバーの側で動く仕組みです（詳しくは後ほど）。

【1】MXレコードとは？メールの届け先を決める設定

MXはMail Exchange（メール・エクスチェンジ）の略です。

「このドメイン宛のメールは、このサーバーに届けてください」という届け先を示すレコードです。

たとえば sample@example.com 宛にメールが送られたとき、送る側のサーバーはまず example.com のMXレコードを見に行って、どこに届ければいいかを確認しています。

DNSの設定画面では、次のような形で登録されていることが多いです（ドメインは仮のものです）。

ホスト名：example.com
種別　　：MX
内容　　：mail.example.com
優先度　：10

優先度の数字は、小さいほうが優先されます。

届け先のサーバーを複数登録しておいて、1台目に届かなかったときに2台目へ、という使い方ができるようです。

MXレコードが間違っているとどうなる？

MXは受信の設定なので、ここが間違っているとメールを受け取れない、または意図しないサーバーに届いてしまう可能性があります。

サーバーを引っ越したときに、MXレコードが古いサーバーを指したままだと、メールが古いサーバーに届き続けることになります。

【2】SPFとは？送ってよいサーバーの名簿

SPFはSender Policy Framework（センダー・ポリシー・フレームワーク）の略です。

「example.com のメールを送っていいのは、このサーバーだけです」という名簿をDNSに公開しておく仕組みです。

メールを受け取った側は、送ってきたサーバーがその名簿に載っているかを確認します。

名簿に載っていないサーバーから example.com を名乗るメールが届いたら、なりすましの可能性がある、と判断できるわけです。

書き方の例はこちらです（中身は仮の値です）。

ホスト名：example.com
種別　　：TXT
内容　　：v=spf1 include:_spf.example.net ~all

呪文のように見えますが、分けて読むとそれぞれ意味があります。

v=spf1 は、この行がSPFの設定ですという宣言です。

include:〜 は、ほかのサービスが用意している名簿をまるごと取り込むという意味です。

メール配信サービスやレンタルサーバーのマニュアルに「このinclude〜を追加してください」と書かれているのは、このためです。

~all は、名簿にないサーバーから来たメールは怪しいものとして扱ってください、という意味です。

~all の代わりに -all と書くと、名簿にないものは受け取らないでください、というもっと強い意味になります。

SPFだけでは足りない理由

調べた範囲では、SPFには弱点もあるようです。

ひとつは、メールが転送されると、転送したサーバーが名簿に載っていないため確認に失敗しやすいことです。

もうひとつは、SPFが確認しているのはメールの裏側に記録される差出人で、メールソフトの画面に表示される差出人とは別のことがある点です。

この弱点を補うのが、次のDKIMとDMARCです。

【3】DKIMとは？メールに押す電子の印鑑

DKIMはDomainKeys Identified Mail（ドメインキー・アイデンティファイド・メール）の略で、「ディーキム」と読まれることが多いです。

送信するメールに電子署名をつけて、受け取った側がそれを確認する仕組みです。

郵便でいうと、封筒に印鑑を押して送り、受け取った側が印鑑証明と照らし合わせるイメージです。

送る側のサーバーは、外に出さない秘密の鍵（秘密鍵）で署名をつけます。

そして、照らし合わせるための鍵（公開鍵）をDNSに公開しておきます。

受け取った側は公開鍵で署名を確認することで、そのドメインが送ったメールであることと、途中で中身が書き換えられていないことを確かめられます。

DNSには次のような形で登録されます（鍵の中身は長いので省略しています）。

ホスト名：default._domainkey.example.com
種別　　：TXT
内容　　：v=DKIM1; k=rsa; p=MIIBIjANBgkq...（長い文字列が続く）

ホスト名の先頭にある default の部分はセレクタと呼ばれる名前で、サービスごとに違う名前が指定されます。

調べた範囲では、レンタルサーバーによっては管理画面でDKIMを有効にするとこのレコードが自動で用意されるものもあるようです。

DKIMは、メールが転送されても中身が書き換えられなければ署名の確認に通りやすいので、SPFの弱点を補う役割があります。

ここで大事なのは、署名をつける作業はメールを送るサーバーで行い、公開鍵はDNSに置くという、2か所に分かれた設定だということです。

この2か所に分かれていることが、後で出てくるネームサーバーの話につながります。

【4】DMARCとは？確認に失敗したメールの扱い方を決めるルール

DMARCはDomain-based Message Authentication, Reporting and Conformanceの略で、「ディーマーク」と読まれることが多いです。

SPFとDKIMの確認結果をもとに、確認に失敗したメールをどう扱ってほしいかを、ドメインの持ち主が宣言しておく仕組みです。

もうひとつ大事な役割として、メールソフトの画面に表示される差出人のドメインと、SPFやDKIMで確認できたドメインが一致しているかもチェックします。

SPFの弱点だった、表示される差出人とは別のところを確認しているという部分を、ここで補っているわけです。

書き方の例はこちらです。

ホスト名：_dmarc.example.com
種別　　：TXT
内容　　：v=DMARC1; p=none; rua=mailto:dmarc-report@example.com

p= の部分が、失敗したメールの扱い方の宣言です。

選べるのは次の3つです。

設定値	意味
none	特に何もしない（様子見）
quarantine	迷惑メールフォルダに入れてほしい
reject	受け取りを拒否してほしい

rua= の部分は、受け取った側から集計レポートを送ってもらうメールアドレスです。

このレポートを見ると、自分のドメインを名乗るメールがどこから送られていて、確認に通っているかどうかがわかります。

調べた範囲では、最初は p=none で始めてレポートを確認し、問題がなければ quarantine、reject と段階的に強めていく進め方が一般的なようです。

なお、DMARCは単体では働きません。

SPFかDKIMの少なくともどちらかが設定されていることが前提になります。

【5】ARCとは？転送されたメールの認証結果を引き継ぐ仕組み

ARCはAuthenticated Received Chain（オーセンティケイテッド・レシーブド・チェーン）の略で、「アーク」と読まれることが多いです。

ARCが必要になるのは、メールが転送されたときです。

たとえば、独自ドメインのアドレスに届いたメールを、自動でGmailに転送している場合を考えます。

転送の途中で件名やヘッダーが書き換えられることがあり、そうなるとDKIMの署名の確認に失敗することがあります。

SPFも、転送したサーバーが名簿に載っていないため失敗しやすいのは前に書いたとおりです。

つまり、もともとは正しいメールなのに、転送されたせいでなりすましのように見えてしまうことがあるわけです。

そこでARCでは、メールを中継したサーバーが、自分が受け取った時点での認証結果をメールのヘッダーに書き足していきます。

郵便でいうと、途中の郵便局が「うちに届いた時点では印鑑は本物でした」と記録を書き足して、次へ渡していくイメージです。

最後に受け取ったサーバーは、この記録の鎖（Chain）をたどって、転送前は正しいメールだったかを判断できるようになります。

さくらのレンタルサーバの公式マニュアルによると、さくらではDKIMを設定するとARCも自動的に利用開始になり、ARCだけの個別の設定項目はないとのことです。

また、同じサーバー内のメールアドレス宛の転送（内部配送）には、ARC署名はつかないと案内されています。

なぜ今この設定が大事なの？Gmailの送信者ガイドライン

送信ドメイン認証の話題でよく出てくるのが、Gmailの送信者ガイドラインです。

Googleの公式ヘルプによると、2024年2月から、Gmail宛にメールを送る送信者への要件が厳しくなりました。

調べた範囲では、すべての送信者はSPFかDKIMのどちらかを設定すること、

そしてGmail宛に1日5,000件以上送る送信者はSPF・DKIMの両方とDMARCを設定することが求められています。

5,000件以上送る送信者のDMARCは、p=none の設定でもよいとされています。

要件を満たしていないメールは、迷惑メールに振り分けられたり、届かなかったりする可能性があります。

個人ブログのお問い合わせフォームから送られる通知メールや、独自ドメインのメールアドレスでも関係してくる話なので、無関係ではないと思います。

（2026年9月時点で、私が確認できる範囲の情報です。最新の要件はGoogleの公式ヘルプで確認をお願いします）

設定はドメイン会社？サーバー会社？ネームサーバーで決まる

いざ設定しようとして迷ったのが、ドメインを取得した会社で設定するのか、サーバーを契約した会社で設定するのかでした。

調べてみると、その答えはネームサーバーがどこになっているかで決まるようです。

ネームサーバーとは

ネームサーバーは、そのドメインのDNS（住所録）を実際に管理している場所のことです。

ドメインを取得した会社とサーバーを契約した会社が別々でも、ネームサーバーはどちらか一方に向けて設定されています。

MXやSPF、DKIMの公開鍵、DMARCのレコードは、ネームサーバーになっている会社の管理画面に登録しないと、外から見えるようになりません。

役割を分けて考えるとわかりやすい

DKIMの章で書いたように、DKIMは設定する場所が2か所に分かれています。

メールに署名をつけるのは、メールを送るサーバーです。

なので、秘密鍵の作成や署名のオン・オフは、サーバーを契約した会社（今回はさくらのレンタルサーバ）の管理画面で行います。

一方で、公開鍵やDMARCのレコードは、ネームサーバーを管理している会社のDNSに登録します。

ネームサーバーもさくらになっていれば、この2つが同じ管理画面で完結するので迷いにくいです。

ネームサーバー	DKIMの鍵作成・署名	DKIM・DMARCのレコード登録
さくらのネームサーバー	さくらのコントロールパネル	さくらのコントロールパネルでチェックを入れると登録される
他社のネームサーバー	さくらのコントロールパネル	ネームサーバーになっている会社のDNS設定画面に自分で追加する

ネームサーバーの確認方法

ネームサーバーは、ドメインを取得した会社の管理画面の「ネームサーバー設定」のような項目で見られることが多いです。

ほかにも、さくらのマニュアルで紹介されているGoogle Admin Toolbox の Digで、ドメイン名を入れてNSを選ぶと、今のネームサーバーを調べる方法があります。

他社のネームサーバーを使っている場合

さくらのマニュアルによると、他社のネームサーバーを使っている場合は、さくらのDKIM設定画面で「利用する」にチェックを入れただけではDKIM・DMARCのレコードは登録されません。

さくらで鍵を作ったあと、表示される公開鍵の情報を、ネームサーバーになっている会社のDNS設定画面にTXTレコードとして自分で追加する流れになります。

マニュアルに載っている形を、仮の値に置き換えるとこのようになります。

sample._domainkey.example.com. IN TXT ( "v=DKIM1; k=rsa; p=（公開鍵）" )
_dmarc.example.com. IN TXT ( "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com" )

DNS設定画面によっては、ホスト名の欄にはドメインを除いた部分（sample._domainkey や _dmarc）だけを入れる形式もあるので、各社のマニュアルで入力のしかたを確認する必要があります。

【実践】さくらのレンタルサーバでDKIM・ARC・DMARCを設定した手順

ここからは、私が実際にさくらのレンタルサーバで設定した手順です。

設定自体は簡単にできました！

設定の流れ

①さくらのサーバーコントロールパネルにログイン

②左のメニューの「メール」→「メールドメイン」

③設定したいドメインの「設定」→「DKIM設定」

④次の内容で設定

秘密鍵　　　　：新規作成
セレクタ　　　：表示された値のまま
DKIMレコード　：利用する
DMARCレコード ：利用する
DMARCポリシー ：none（報告のみ）

公式マニュアルでは、最後に「設定する」ボタンを押すと設定完了で、反映までには数時間程度かかる場合があると案内されています。

また、公式マニュアルによると、サーバーコントロールパネルにはメールアドレスではなく、初期ドメインか追加したドメインでログインしないと設定項目が表示されないそうです。

それぞれの項目の意味

秘密鍵：新規作成は、DKIMの署名に使う鍵を、さくらのサーバーで新しく作ってもらうという意味です。

セレクタ：表示された値のままは、DKIMの章で出てきたセレクタの名前です。

公式マニュアルでも、必要な場合以外は表示された値をそのまま使うよう案内されていたので、私は変えていません。

DKIMレコード：利用するは、公開鍵のレコードを、さくらのネームサーバーに登録するためのチェックです。

前の章で書いたとおり、他社のネームサーバーを使っている場合は、ここにチェックを入れただけでは登録されません。

DMARCレコード：利用するは、DKIMと同時にDMARCのレコードも登録するためのチェックです。

DMARCポリシー：none（報告のみ）は、確認に失敗したメールがあっても特に何もしない、様子見の設定です。

さくらのマニュアルでは、Googleは初回はnoneに設定してレポートで状況を確認することを推奨している、と紹介されています。

ARCの項目がないことに最初は戸惑いそうですが、前に書いたとおり、さくらではDKIMを設定するとARCも自動で使われるようになる仕組みです。

PHPからメールを送るときの注意

PHPでメールを送るファイルを書いたあとにこの設定をする場合、ひとつ気をつけたい点がありました。

さくらの公式マニュアルによると、DKIM署名がつくのは、メールソフトからSMTP認証で送ったとき、ウェブメールで送ったとき、sendmailコマンドで送ったときなどに限られています。

PHPやCGIのプログラムで、sendmailコマンドを使わずに相手先のメールサーバーへ直接つないで送っている場合は、署名されないと案内されています。

調べた範囲では、PHPのmail関数やmb_send_mail関数は、サーバー上のsendmailを通して送る仕組みになっているようです。

ライブラリなどを使って別の方法で送っている場合は、送信方法を確認しておかないと、せっかく設定してもDKIM署名がつかない可能性があります。

設定できているか確認する方法

さくらのレンタルサーバでは、公式マニュアルによると「メールドメイン」の一覧画面で、SPF・DKIM・DMARCが設定済みかを確認できるそうです。

実際にメールが確認に通っているかは、Gmailで受信したメールから見る方法があります。

自分のドメインのメールが確認に通っているかは、Gmailで受信したメールから見る方法があります。

Gmailでメールを開き、右上のその他メニュー（縦の3つの点）→「原文を表示」を選ぶと、SPF・DKIM・DMARCそれぞれの結果が表示されます。

ここが PASS になっていれば確認に通っていて、FAIL などになっていれば設定を見直す必要がある、という見方になります。

独自ドメインのアドレスから自分のGmail宛てにメールを1通送れば確かめられるので、手軽な確認方法だと思います。

設定直後はDNSの反映が終わっていないことがあるので、時間をおいてから確認するほうが確実です。

初心者がつまずきやすいポイント

設定する場所はネームサーバーで決まる

鍵の作成や署名はサーバー側、レコードの登録はネームサーバーになっている会社の側です。他社のネームサーバーを使っている場合は、さくらでチェックを入れただけでは登録されないので、DNS側への追加が必要です。

SPFのレコードは1つのドメインに1行だけ

複数のサービスを追加したいときにSPFの行を2つ書くとエラーになるので、include〜を1行の中に並べてまとめます。

MXとSPFは別物

MXは受け取る側の設定、SPFは送る側の設定なので、どちらか一方を直しても、もう一方には影響しません。

DNSの変更はすぐには反映されない

設定直後に確認して失敗していても、時間をおくと反映されている場合があります。

サーバーやメールサービスを乗り換えたとき

MX・SPF・DKIMが古いサーバーのままになっていないかを確認する必要があります。
ここをチェックしておかないと、メールが届かなくなったり、なりすまし判定されたりする可能性があります。

まとめ

SPF・DKIM・DMARC・ARC・MXは、略語だけ並ぶと難しそうですが、役割を分けてみるとそれぞれ違うことをしていました。

MXはメールを受け取るための届け先の住所で、SPF・DKIM・DMARCの3つは、自分のドメインを名乗る偽物のメールを見分けてもらうための仕組みです。

SPFが送ってよいサーバーの名簿、DKIMがメールに押す電子の印鑑、DMARCがその2つで確認に失敗したメールの扱い方のルールで、ARCは転送されたときにその認証結果を引き継ぐための記録、と分けて考えると整理しやすいと思います。

設定する場所は、鍵の作成はサーバー側、レコードの登録はネームサーバーになっている会社の側、というところがポイントでした。

私はさくらのレンタルサーバで、コントロールパネルのDKIM設定からDKIM・DMARCを設定し、ARCもあわせて使える状態にしました。

ローカルではMailpit（無料）を使ってメールの送受信確認を行いました。

それについては別記事にしているのでご参照ください！

Mailpit(メールピット)ってなんぞや！？お問い合わせフォームのテストメールをDockerで確認する方法｜初心者

Mailpit(メールピット)は、開発中のお問い合わせフォームから送ったメールを受け止めて画面で確認できるテスト用ツールです。Dockerでの起動方法や画面の見方を初心者向けにまとめました。