SPF・DKIM・DMARCとは？メール認証の設定方法と確認手順

SPF・DKIM・DMARCは、自社のドメインを名乗るメールが正規の送信かどうかを、受信側が判断するための仕組みです。SPFは送信元サーバーの許可、DKIMはメールの電子署名、DMARCは表示上の差出人ドメインとの整合を確認します。DNSへ三つの設定を書くだけでなく、実際に送ったメールで認証結果を確かめる必要があります。社員のメールが届いても、同じ会社のフォーム通知や請求メールまで正しく設定されているとは限りません。

まず正規の送信経路を調べ、経路ごとにSPFとDKIMを設定します。その結果がFromドメインと整合することを確認してから、DMARCの隔離・拒否方針を検討します。順番を逆にすると、自社の正規メールを受信側が拒否する原因になります。

社員メールとフォーム通知は送信元が異なることがある

最初に確認するのはDNSの値ではなく、自社ドメインで誰が送っているかです。社員のメールに加え、問い合わせフォームや予約システムも送信サービスとして扱います。

請求書の月次送信やメール配信サービスは、普段のテストでは見落としやすい経路です。利用中のサービスから送信例を取り、表示上の差出人であるヘッダーFromと認証結果を比べると、設定漏れを見つけやすくなります。

DNSを変える前に現在のレコードを保存し、送信サービスの公式設定値と照合します。新しいサービスを追加するとき、既存のメール設定を丸ごと置き換えてはいけません。停止したサービスの許可を削除する場合も、そのサービスからの定期送信が残っていないかを担当部署に確認します。

SPFは一つの方針へ統合し参照上限を確認する

SPFは、主にエンベロープFromのドメインがその送信サーバーを許可しているかを調べます。利用者に見えるFromと同じドメインを検証しているとは限らない点が重要です。

同じ名前にv=spf1で始まるTXTレコードを二つ作ると、正しいSPF方針として評価できません。複数のサービスを使う場合は、必要な許可を一つのSPFレコードへ統合します。一つのTXTレコード内で長い文字列が分割表示されている状態と、独立したレコードが二つある状態は区別してください。

また、SPFにはDNS参照を伴う評価項目の上限があります。SPFの仕様では、includeやaなどの対象項目を評価全体で10までに制限します。include先の参照も関係するため、送信サービスを10社まで登録できるという意味ではありません。上限を超えるとpermerrorになり、正規送信でも認証に失敗します。

参照が増えた場合は、まず使っていない許可を整理します。サービスの送信IPを独自に固定してincludeを置き換えると、事業者のIP変更に追従できなくなるため慎重に扱います。末尾の~allと-allも、現在使うサービスと公式案内を確認せずに切り替えないようにします。

DKIMは実際の署名から公開鍵をたどる

DKIMでは送信サービスが署名を付け、受信側が公開鍵で検証します。管理画面で有効にしたという記録だけでなく、送信したメールに署名が付いていることを確かめます。

受信メールのDKIM-Signatureには、署名ドメインを示すd=と、鍵を識別するセレクタs=があります。例えばd=example.com、s=s2026なら、鍵を確認するDNS名はs2026._domainkey.example.comです。セレクタの名前はサービスが指定するものであり、この例の名前をそのまま登録するわけではありません。

登録方法は公開鍵をTXTへ置く方式だけでなく、指定先へCNAMEを向ける方式もあります。DNS管理画面がドメイン名を自動で補う場合は、末尾を重複させないようにします。秘密鍵をDNSや問い合わせ文面へ貼り付けてはいけません。

転送を経ても署名対象が変わらなければDKIMは合格できる一方、メーリングリストなどによる本文変更で失敗する場合があります。SPFが失敗しているからDKIMも必ず失敗する、という関係ではありません。受信結果からそれぞれを確認します。

DMARCはFromとの整合で判定する

DMARCは、SPFまたはDKIMの合格に加え、その認証ドメインがヘッダーFromと整合することを求めます。単に二つの欄がpassになっているかだけでは判断できません。

ヘッダーFromがinfo@example.comの場合を考えます。表の「自社」はexample.com、「配信元」は別ドメインのvendor.exampleです。SPF欄は認証ドメイン、DKIM欄は署名ドメインとの組み合わせを示しています。以下は説明用の例で、実際の配信結果ではありません。

既定の緩和モードでは、同じ組織ドメインのサブドメインも整合対象になり得ます。adkim=sやaspf=sを指定した厳格モードでは完全一致が必要です。配信サービスで独自ドメインのDKIM署名を設定する意味は、認証を合格させるだけでなく、この整合を成立させることにもあります。

ただし、DMARCの合格条件と送信先の利用要件は別です。Gmailの送信者ガイドラインは、大量送信者にSPFとDKIMの両方およびDMARCを求めています。「片方があればDMARCは通る」ことを理由に、必要な認証を省略しないでください。

DNSと受信ヘッダーを別々に検証する

DNSに値が公開されていることと、その経路のメールが認証に合格することは別です。まず設定先を確認し、その後に各サービスから外部の検証用アドレスへ送信します。

digが使える環境では、次のように公開値を読み取れます。example.comとs2026は説明用の値なので、自社のドメインと実際の署名セレクタへ置き換えます。これはDNSを書き換えるコマンドではありません。

dig +short TXT example.com
dig +short TXT s2026._domainkey.example.com
dig +short TXT _dmarc.example.com

DKIMがCNAME方式なら、参照先の公開鍵まで確認します。回答がない場合は、待つだけでなく登録名と権威DNSの管理先を調べます。旧DNSへ設定していたり、ドメイン名を二重に入力していたりすれば、時間が経っても解決しません。

次に、受信サービスの「メッセージのソース」などから認証結果を確認します。見るのは受信側が付けた信頼できるAuthentication-Resultsで、送信者が任意に付けた同名ヘッダーではありません。次は読み方を示すための架空の結果です。

Authentication-Results: mx.receiver.example;
 spf=pass smtp.mailfrom=bounce.vendor.example;
 dkim=pass header.d=example.com header.s=s2026;
 dmarc=pass header.from=example.com

この例ではSPFは配信サービスのドメインで合格しています。Fromとは整合しませんが、DKIMのheader.dがFromと一致しているためDMARCも合格しています。社員メールとフォーム通知で結果が違う場合は、同じドメインのメールでも送信経路や署名設定が異ならないかを見ます。

問い合わせ時は送信時刻とMessage-IDを保存し、どの経路で失敗したかを伝えます。ヘッダーを第三者へ渡す場合は、アドレスなどの個人情報を必要に応じて伏せます。認証に合格しても送信評判や内容で迷惑判定されるため、受信箱への到達を保証するものではありません。

拒否設定をすべてのドメインの目標にしない

DMARCの方針は、正規メールを止めずに運用できるかを確認してから強めます。初めて導入する場合は監視用のp=noneを使い、レポートの受信先と確認担当を決めます。

例えば_dmarc.example.comのTXTをv=DMARC1; p=none; rua=mailto:dmarc-reports@example.comとする設定が考えられます。これは説明例であり、既存の方針を上書きするための値ではありません。実際には受信可能なレポート用アドレスを用意し、外部ドメインへ送る場合は送信先による受信許可の設定も確認します。すべての受信者からレポートが届く保証はありません。

社員の通常送信だけでなく、月次請求や一斉配信を含む業務周期で正規メールを確認します。失敗した送信元は、設定漏れなのか不正な送信なのかを分けます。そのうえで、隔離を求めるp=quarantineや拒否を求めるp=rejectが用途に合うかを判断します。

現行仕様のRFC 9989は、利用者が外部のメーリングリストへ投稿する可能性のあるドメインでのp=rejectを推奨していません。転送やメーリングリストで正規メールまで失敗し得るためです。用途を限定した通知用ドメインなどとは分けて考えます。最終的な処理は受信側の判断も受けます。

古い手順にあるpctで対象割合を増やす方法は、現行仕様のRFC 9989では削除されています。受信側が期待どおりの割合で処理する前提を置かず、利用サービスの現行案内と検証結果を基に変更します。

同じ会社のメールでも、社員のメールとフォーム通知では送信元が違う場合があります。片方だけ認証に失敗するなら、会社全体のDNSを作り直すより、その経路の設定と署名を見る方が原因を絞れます。Webとメールを別の会社で使う構成は、Webサーバーとメールサーバーの分離でも説明しています。