SPF、DKIM、DMARCによるメール認証は、送信ドメインの基本設定になりました。2025年または2026年に業務メールを送るドメインでは、これらのレコードが受信側の分類や拒否判断に影響しますが、受信トレイへの到達を単独で保証はしません。まず全体像を把握するなら、小規模事業者向け業務メールから始めてください。
SPF、DKIM、DMARCの問題について、多くのチームは内容を原因と考えます。内容が影響することもありますが、ドメイン設定の誤りもよくあります。SPFレコードの不備、DKIM鍵の欠落、未公開のDMARCポリシーなどです。その場合、Outlookでの拒否、Gmailの速度制限、Yahooでの不適切な分類、転送障害が発生する可能性があります。
理論は単純でも、実装には注意が必要です。SPFは実際のMAIL FROMドメインについて送信を許可するIPを示し、DKIMは署名と署名対象データを確認し、DMARCは失敗時の処理を要求して認証ドメインと表示上のFromドメインのアライメントを確認します。適切な設定は重要な信号を提供しますが、受信側の判断をすべて決めるものではありません。
SPF、DKIM、DMARCが実際に行うこと
これはメールボックス事業者がメッセージを評価する多層システムです。SPFは送信経路、DKIMは署名、DMARCはアライメントとポリシーを確認します。適用対象の一括送信規則ではSPFとDKIMの両方の公開が必要な場合がありますが、DMARC成功にはSPFまたはDKIMの一方が成功し、アライメントすれば足ります。
| プロトコル | 主な役割 | 確認対象 | 一般的な障害 |
|---|---|---|---|
| SPF | 承認 | 接続元IPがenvelopeドメインについて許可されているか | DNSルックアップ過多、または転送によるIP変更 |
| DKIM | 完全性 | 署名が有効で署名対象データが保たれたか | 誤ったセレクター、古い鍵、転送中の署名対象変更 |
| DMARC | ポリシーとアライメント | SPFまたはDKIMが成功し、表示上のFromドメインと一致したか | SaaSが自社ドメインで送りアライメントに失敗 |
覚えておくべき点は、DMARCがSPFとDKIMの両方の成功を求めないことです。どちらかが成功し、受信者に見えるFromドメインとアライメントする必要があります。
SPF：ドメインからの送信を許可する相手
SPFはメール認証の第一層で、送信元の許可リストとして働きます。受信サーバーは実際のenvelope sender、つまりMAIL FROMドメインのSPF TXTレコードを調べ、接続元IPが許可されているか判断します。有用ですが、転送と長いincludeチェーンの影響を受けやすい仕組みです。
SPFはDNSにTXTレコードとして公開します。一般的な例：
v=spf1 include:_spf.google.com include:spf.trekmail.net -all各要素の意味：
v=spf1はレコード種類を宣言します。include:は別ドメインが公開する送信基盤を参照します。-allはその他の送信元をfailとする指定です。
多くの設定が最初に直面するのは、10回のDNSルックアップ上限です。詳細はRFC 7208にあり、関連するメカニズムと修飾子、include配下のネストした参照も数えます。上限を超えると受信側がPermErrorを返し、SPF評価を正常に完了できない場合があります。
二年前にCRMを解約しても、その
include:を残していました。マーケティング基盤がさらに三つ、サポートシステムがもう一つの参照を追加しました。受信側がチェーン全体を評価するまで、レコードは正常に見えていました。
転送でもSPFは失敗し得ます。大学がメッセージをGmailへ転送すると、Gmailには元のサーバーではなく大学のIPが見える場合があります。正しいSPFでも転送後に失敗する可能性があるため、SPFだけでは不十分です。
TrekMailで送信する場合、必要なincludeと、SPFレコードを重複させず既存レコードへ統合する方法が文書にあります：必須DNSレコード。
DKIM：誰が署名し、署名対象が変わったか
第二層はDKIMです。送信システムが秘密鍵で選択したデータに署名し、受信側がDNSの公開鍵で検証します。SPFと異なり、有効な署名と正規化された署名対象ヘッダーや本文が互換性を保っていれば、DKIMは転送後も通常維持されます。
DKIMレコードは、selector1._domainkey.example.comやdkim._domainkey.example.comなどのセレクター配下に置きます。送信側が対応するセレクターで署名し、受信側がDNSから公開鍵を取得して検証します。
一般的なDNS値：
Host: dkim._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G...運用上の原因は概して単純です。
- 鍵をローテーションした後も、メールサーバーが古いセレクターを使っている。
- 事業者変更後に新しい公開鍵を公開していない。
- DNSホストが長いTXT値を壊した。
- メーリングリストが本文を書き換え、署名を無効にした。
新しい互換性のある導入では、基盤とDNSが対応する場合、2048ビット鍵が通常は妥当な推奨既定値です。1024ビットの古い構成も2026年には残っていますが、実際の署名サービスの対応範囲を確認して選びます。
TrekMailの有料プランでは、現在の条件に従い、マネージドSMTP使用時にドメインのDKIM鍵でメールを署名できる場合があります。署名が有効でアライメントしていれば、SPFのみの設定より転送時に役立つことがあります。設定後の障害にはメールが迷惑メールになる場合を参照してください。
DMARC：受信側へ処理を要求するルール
DMARCはSPFとDKIMの上にあるポリシー層です。認証失敗時に希望する処理を公開し、表示上のFromと成功したSPFまたはDKIMのドメインとのアライメントを調べます。アライメントがなければDMARCは成功しません。
DMARCレコードは_dmarc.example.comに公開します。まず単純な設定から始めます。
v=DMARC1; p=none; rua=mailto:dmarc@example.com台帳と試験に基づいて段階的に強化します。
v=DMARC1; p=quarantine; rua=mailto:dmarc@example.comv=DMARC1; p=reject; rua=mailto:dmarc@example.comp=noneはDMARC結果による制限を要求しません。p=quarantineは失敗を疑わしいものとして扱うよう求め、p=rejectは拒否を求めます。これらは公開されたポリシー要求であり、すべての受信側が同じ処理をする保証ではありません。
より大きな落とし穴はアライメントです。例：
表示上のFrom：
newsletter@yourcompany.com
Return-Path：bounce.vendor.com
DKIMドメイン：vendor.com
SPFは成功するかもしれません。DKIMも成功するかもしれません。それでも、どちらもyourcompany.comとアライメントしないためDMARCは失敗します。
これはMailchimp、HubSpot、Zendesk、CRMでよくある構成ミスです。送信サービスの画面は緑でも、実際のメールがアライメントしていない場合があります。Googleの現在のガイダンスでは、個人向けGmailへ送る対象の一括送信者にSPFとDKIMを求め、直接メールでは少なくとも一方をFromドメインとアライメントさせます。最低限のDMARCレコードも求められ、p=noneでも構いません：Googleメール送信者ガイドラインFAQ。
SPF、DKIM、DMARCで最も重要なのはどれか
各プロトコルの仕事が異なるため、一つだけを最重要とする質問は適切ではありません。条件が保たれればDKIMは転送に強く、SPFも重要な承認信号で、DMARCがアライメントとポリシーを加えます。適用規則と堅実な運用には全体が必要です。
| 質問 | SPF | DKIM | DMARC |
|---|---|---|---|
| 送信元IPを確認する？ | はい | いいえ | SPF結果を通じて間接的に確認 |
| メッセージ完全性を確認する？ | いいえ | はい | DKIM結果を通じて間接的に確認 |
| 転送に強い？ | いいえ | 通常は強いが、署名対象データの維持が条件 | SPFまたはDKIMが成功しアライメントする場合のみ |
| 受信側ポリシーを公開する？ | いいえ | いいえ | 要求ポリシーとして公開 |
| なりすまし抑制に役立つ？ | 一部 | 一部 | ポリシー適用時に役立つが、すべての悪用は防げない |
メールサーバーが一つでSaaS送信元もない単純な構成なら、設定は比較的容易です。同じドメインでサポート、ニュースレター、CRM、転送を使う場合、DMARCレポートによって実際にアライメントする経路と、画面上だけそう見える経路を確認できます。
転送とメーリングリストが異常な失敗を起こす理由
転送では、元のサーバーではなく転送サーバーが続きを送るためSPFが失敗することがあります。署名が有効ならDKIMが役立つことがありますが、中継が署名対象の本文や件名を互換性のない形で書き換えるとDKIMも失敗します。
このためDNS上の設定が正常でも、受信者がメールを見られない場合があります。間接経路でIPが変わってSPFが失敗し、メーリングリストのフッター追加でDKIMが失敗し、成功してアライメントする信号がなくDMARCも失敗します。
転送メールでSPF、DKIM、DMARCが失敗した場合、ARCにより中継者は受信時に観測した結果を記録し、後段の受信側がローカル規則で評価できます。ARCは信頼を自動維持せず、DMARCをpassにも変えません。Googleのガイダンスには転送やメーリングリスト向けのDMARCアライメント条件があり、間接メールにはARCヘッダーを推奨しています。送信者がARCを自分で設定することは通常ありません。実務ではDKIMを有効に保ち、壊れやすい転送チェーンを避けます。転送が中心ならメール転送ガイドも確認してください。
メール処理に影響する追加チェック
認証レコードを正しく公開しても、受信トレイへの配置は保証されません。受信事業者は逆引きDNS、TLS、苦情率、配信停止方法も考慮します。SPF、DKIM、DMARCは基礎であり、すべてではありません。
- 正引き確認済み逆引きDNS：送信IPにはPTRレコードが必要で、そのホスト名は同じIPへ正引きできるべきです。Googleは適用対象の送信者について有効な正引きと逆引きDNSを要件に挙げています。
- TLS：大手事業者はTLSでの転送を求めます。GoogleのFAQでは、適用状況においてTLSを使わないメールが一時的または恒久的な失敗の要因になり得ると説明しています。
- 迷惑メール報告：Googleは対象送信者に苦情率を0.1%未満に保ち、0.3%に達しないよう求めています。
- ワンクリック配信停止：対象の販促メールではRFC 8058形式の配信停止ヘッダーが必要で、フッターのリンクだけでは不十分です。
新しいドメインでは特に重要です。履歴が少ない段階の突発的なキャンペーンや管理不良のリストは、安定した信号が蓄積する前にレピュテーションへ影響し得ます。
本番メールを壊さずSPF、DKIM、DMARCを設定する方法
最初に全送信元を棚卸しし、整合したレコードを公開し、実際のメールで確認して、DMARCを段階的に強化します。棚卸しを省くと、忘れていたSaaSを止める可能性があります。
- ドメインを使う全サービスを列挙する：メールボックス、CRM、サポート、ニュースレター、フォーム、請求、サーバー。
- 全送信元を一つのSPFレコードに統合する。SPF TXTレコードを二つ公開しない。
- 独自セレクターが必要な送信元ごとにDKIMを公開する。
- まず
p=noneでDMARCを公開し、レポートの不完全性を考慮して確認する。 - 外部送信元でカスタムドメイン認証を有効にし、実際のメールでアライメントを検証する。
- 複数の代表期間、低頻度の重要経路、ロールバックを確認してから
p=quarantine、続いてp=rejectへ進む。
TrekMailドメインでマネージド送信を使う場合、基本レコードは次のようになりますが、実際の値は現在の画面と文書から取得してください。
MX @ mail.trekmail.net. priority 10
TXT @ v=spf1 include:spf.trekmail.net -all
TXT dkim._domainkey v=DKIM1; k=rsa; p=...unique key from dashboard...
TXT _dmarc v=DMARC1; p=quarantine; rua=mailto:dmarc@trekmail.netTrekMailの必須DNSレコードとDNSステータス確認では、正確な配置と実環境での検証手順を説明しています。より前の段階には自分のドメインでメールを設定するも役立ちます。
従来の方法と新しい方法
従来は不要な大型スイートをユーザー単位で契約するか、メール基盤、DNS、TLS、DKIMセレクター、レピュテーションを自前で管理しました。別の方法ではメールボックスと送信を分離し、選択プランに応じてレコード、検証、移行経路を提供する基盤を利用します。
TrekMailはこのモデルで利用できます。本記事に記載した現在の条件では、Nanoは最大10ドメイン、共有5 GB、自前SMTPに対応します。有料プランは月額$3.50からで、マネージドSMTPを含む場合があります。カスタムドメイン、IMAPメールボックス、catch-all、転送、組み込みIMAP移行、APIアクセスはプランによって異なります。有料プラン向けに、開始時にクレジットカードが必要な14日間の無料トライアルが提供される場合があります。Nanoは現行条件ではカード不要で無料を継続できます。最新料金、機能、上限を確認してください。
SPF、DKIM、DMARCの管理は継続的な運用作業です。多数のドメインでは、一つの画面、共有ストレージ、用意されたDNSレコード、サーバー側移行により手順をまとめられる場合がありますが、検証は省けません。この用途にはマルチドメインメールホスティングを比較してください。数字を確認する場合はTrekMail料金を参照できます。
まとめ：SPF、DKIM、DMARCは現在の基礎
SPF、DKIM、DMARCによるメール認証は、もはや一部の高度な対策ではありません。SPFはenvelopeドメインに許可されたIP、DKIMは選択データの有効な署名、DMARCは成功した経路と表示上のFromドメインとの結び付き、および要求ポリシーを示します。
今週一つだけ取り組むなら、送信元を棚卸しし、有効なSPFレコード一つ、動作するDKIMレコード一つ、p=noneのDMARCを公開してください。次に低頻度経路と転送を含む実際の送信元を検証します。複数の代表期間を確認し、ロールバックを準備してからポリシーを強化します。この準備は後の拒否調査リスクを減らしますが、配信やコスト削減を保証しません。
