はじめに：メールが届かないと何が起こるか

取引先に送った見積書や請求書が迷惑フォルダに振り分けられると、確認が遅れたり未読のまま商談が停滞したりします。特に士業事務所や印刷会社のように「時間＝信用」と直結する業態では、数時間の遅延がクレームや機会損失につながります。メールマーケティングを開始した食品メーカーであれば、初回配信の段階で到達率が低いと「迷惑メール扱い＝ブランド毀損」の烙印を押されかねません。こうした損失は、SPF・DKIMという送信ドメイン認証を正しく設定するだけで大幅に防げます。本記事では専門用語を噛み砕きつつ、DNS設定に不慣れな方でも実践できる手順を解説します。

迷惑メール判定の仕組みと到達率の考え方

迷惑メールフィルタは日々高度化しており、内容だけでなく「送信元ドメインの信頼性」を重視します。下表は主要な要素と重みづけのイメージです。

判定要素	例	影響度
ドメイン認証（SPF・DKIM・DMARC）	DNSレコードの有無と正確性	高
送信IPの評価	スパム履歴、ブラックリスト登録	高
送信コンテンツ	過剰なHTML、禁止語、画像のみ	中
受信者行動	開封率・スパム報告	中
技術的ヘッダ	誤ったエンコード、逆引き未設定	低

「到達率90%」と聞くと高く感じますが、1,000通送って100通が届かない計算です。請求書のような重要メールが10通に1通届かなければ、事業継続に関わる問題となります。

SPF・DKIM・DMARC の基礎知識

SPF とは

Sender Policy Framework の略で、**「どのIPからの送信を許可するか」**を宣言する認証方式です。受信サーバーはメールヘッダの「Mail From」とDNSに登録されたSPFレコードを照合し、一致しなければ拒否または減点します。

DKIM とは

DomainKeys Identified Mail の略で、電子署名をメールヘッダに付与して改ざんを防ぎます。公開鍵をDNSに、秘密鍵をメールサーバーに保持し、受信側は署名を検証して正当な送信であることを確認します。

DMARC とは

Domain‑based Message Authentication, Reporting & Conformance の略で、SPFまたはDKIMが失敗した際にどのように処理するか（隔離・拒否・モニタリング）をポリシーとして宣言します。またレポート機能により偽装送信の状況を可視化できます。

ポイント

• SPF と DKIM は「合格・不合格」を判定するテスト。
• DMARC はその“試験結果”をどう扱うか決めるルールブック。
• この3つをそろえることで初めてドメインの信頼スコアが最大化されます。

【準備】自社環境を確認しよう

設定に入る前に、次の3点をチェックします。

1. DNS管理画面のログイン情報
   • レンタルサーバー会社（例：さくらインターネット、ロリポップ）か、クラウドDNS（Route 53、Cloudflare）かを確認
2. メール送信経路
   • 社内メールサーバー、Google Workspace、Microsoft 365、外部メール配信サービスなど複数ある場合は全経路を洗い出す
3. 既存のTXTレコード
   • すでにSPFやDKIMが登録されていないか、競合を避けるため事前に控えておく

下表は典型的な構成別の確認ポイントです。

送信経路	よくあるDNS管理権限	SPF登録例
共用レンタルサーバーのみ	サーバー会社のコントロールパネル	v=spf1 include:example.jp ~all
Google Workspace + メール配信サービス	ドメインレジストラのDNS	v=spf1 include:_spf.google.com include:spf.mta.service.com -all
社内SMTP + 取引先システム	社内DNSサーバー	v=spf1 ip4:203.0.113.10 ip4:198.51.100.22 ?all

この時点で送信元IPやサービスが把握できていない場合は、グループウェア管理者や外部システム担当者に確認しましょう。不明なまま設定を進めると、一部のメールが通らなくなる恐れがあります。

【STEP1】SPF レコードを追加する手順

SPF は「TXT レコード」という形式で DNS に登録します。作業ミスを防ぐため、以下の順序で進めると安全です。

手順 1: 送信元サービスの SPF 情報を集める

各メールサービスには推奨 SPF 文字列があります。公式ヘルプを検索し、include: の文字列を控えておきます。

サービス	公開されている include 値	備考
Google Workspace	_spf.google.com	Google 以外の送信 IP を許可しない場合 -all を推奨
Microsoft 365	spf.protection.outlook.com	旧 Office365 でも同一
SendGrid	u123456.wl.sendgrid.net	アカウント固有サブドメインが割り当てられる
Amazon SES	amazonses.com	リージョンごとに IP プールが異なる

手順 2: 既存 SPF を編集または新規追加

1. DNS 管理画面で TXT レコード を選択
2. ホスト名（名前）が空欄または @ になっているか確認
3. 値に v=spf1 から始まる文字列を入力し、最後に ~all または -all を付ける
4. 保存してから TTL（反映時間）が最短になっているかチェック

ヒント

• 既に v=spf1 レコードが存在する場合は 追記 し、重複して別行を作らない。
• + は既定で許可を意味するため、明示的に書く必要はほぼない。

手順 3: テスト送信で確認

DNS の反映が終わったら、自社と外部のフリーメール宛てに送信し、メールヘッダを開いて spf=pass になっているか確認します。反映まで数分～72時間かかるケースがあるため、慌てず待ちましょう。

ここまでで SPF が機能していれば、送信ドメインとして最低限の信頼を獲得できます。次のパートでは DKIM の署名設定を行い、ドメインの真正性をさらに高めていきます。

【STEP2】DKIM レコードを追加・有効化する手順

DKIM はメールに“電子署名”を付けることで、第三者による改ざんやなりすましを防ぎます。設定の流れは以下のとおりです。

1. 秘密鍵と公開鍵を生成する

• 共用レンタルサーバー：コントロールパネルの「メール認証」メニューでワンクリック生成できるケースが増えています。
• 自社 SMTP：openssl で 1024 ビット以上の RSA 鍵を生成し、秘密鍵をサーバー内に保管します。

2. セレクタ（selector）を決める

セレクタは公開鍵を識別する“ラベル”です。年月を含めておくとローテーション管理が楽になります。例：dkim2025a。

3. DNS に TXT レコードを追加

ホスト名は <selector>._domainkey.<自社ドメイン> となります。値には v=DKIM1; k=rsa; p=公開鍵 を記載します。公開鍵は改行とコメントを除いた 2048 文字程度の文字列です。

サービス	推奨セレクタ例	公開鍵長	備考
Google Workspace	google	2048bit	自動生成されるため DNS に貼り付けるだけ
Microsoft 365	selector1	2048bit	2 本同時に発行されローテーションに対応
SendGrid	s1, s2	1024bit	2 つのセレクタをセットで設定
Amazon SES	amazonses	1024bit	リージョンごとに異なる公開鍵

4. 署名機能をオンにする

メールサーバー側の管理画面で「DKIM を有効化」し、署名に使用するセレクタを選択します。秘密鍵ファイルを指定する形式の場合はパーミッションを 600 に設定し、root 以外から読み取れないようにします。

5. テスト送信で dkim=pass を確認

Gmail ではメール詳細の「認証結果」で即時に判定が分かります。合格表示まで 72 時間程度かかる場合もあるため、時間をおいて再テストしましょう。

コツ

• 公開鍵が 255 文字を超える場合は RFC に従いダブルクォーテーションで改行を入れる。
• 一度有効化した後でもセレクタを追加し、旧鍵を無効化すればローテーションが可能。

【検証】メールテストとスコアの見方

設定が完了したら、第三者の検証サービスで総合スコアをチェックします。

検証手順

1. mail‑tester.com でランダムアドレスを取得
2. 自社アドレスからテストメールを送信
3. 表示された評価レポートで SPF・DKIM の項目が満点か確認
4. Gmail や Outlook.com 宛てにも送信し、ヘッダの Authentication‑Results を確認

評価項目	推奨スコア	改善アクション
SPF	pass	include が不足していないか確認
DKIM	pass	公開鍵誤り・DNS 未反映を疑う
DMARC	ポリシー none → モニタリング開始	レポート受信先を設定
コンテンツ	7/10 以上	HTML とテキストのマルチパートにする
ブラックリスト	0 件	もし登録されていれば解除申請

9/10 以上が安定して取れれば、多くの主要メーラーで迷惑フォルダ行きを回避できます。

よくあるエラーと対処法

下表は問い合わせの多い失敗例をまとめたものです。

エラー表示	主な原因	即効対策
spf=softfail	~all で許可外 IP から送信	正式 IP を追記する
dkim=fail (bad signature)	署名文字列が改行で途切れた	公開鍵を再貼付し、折り返しを削除
No DKIM signature	メーラーが DKIM を付与していない	SMTP リレーのどこで署名が外れたか追跡
550 5.7.1 Unauthenticated email	DMARC ポリシーが reject	テスト段階は p=none に戻して調整
DNS 更新が反映されない	TTL が長い	一時的に 300s 程度へ短縮し、反映後に戻す

業種別アドバイス

士業事務所

• 取引先に官公庁が含まれる場合、SPF だけでも “softfail” を嫌われる傾向があるため -all（完全拒否）を推奨。
• 電子契約書サービスを介したリマインドメールは別ドメインになることが多いので include: を追加。

印刷会社

• 見積出力システムがオンプレミスに残っているケースがあり、プライベート IP を誤って公開しがち。ip4: で正確なグローバル IP を記述。
• 大容量 PDF 添付はコンテンツスコアを下げる可能性があるため、ダウンロード URL 方式に切り替えると評価アップ。

食品メーカー

• EC サイト用メール配信システム（カートサービス）が別ドメインで送信することが多く、ブランド統一のためにカスタムドメイン機能を有効に。
• 年間 4 回以上キャンペーンを行う場合は DKIM セレクタを半期ごとにローテーションし、鍵漏えいリスクを低減。

これで SPF と DKIM の両輪が整いました。最終パートでは DMARC の設定と長期運用のポイントをまとめ、定期チェック方法を解説します。

【STEP3】DMARC を設定して信頼性を完成させる

SPF と DKIM が “合格” しても、それだけでは受信側のポリシーに左右される余地が残ります。DMARC を導入すると「SPF か DKIM が失敗した場合にどう処理してほしいか」を明示でき、ブランドを保護できます。

1. ポリシーを決める

選択肢	値	推奨シーン
none	p=none	設定直後のモニタリング期間
quarantine	p=quarantine	到達率が安定し、誤検知を減らしたい
reject	p=reject	大規模なフィッシング被害を抑止したい

スタートは none を推奨。最低 2 週間レポートを確認し、問題がなければ quarantine → reject と段階的に強化します。

2. DNS に TXT レコードを追加

ホスト名は *_dmarc.example.jp ではなく _dmarc 固定です。値の例：

iniコピーするv=DMARC1; p=none; rua=mailto:dmarc-report@example.jp; ruf=mailto:dmarc-fail@example.jp; fo=1;

• rua：集計レポート（XML）が送られる先
• ruf：失敗サンプル（メッセージ全体）が送られる先
• fo=1：SPF か DKIM のどちらかが失敗した時点でレポート

3. レポートの読み方

XML 形式で届くため、DMARC Analyzer や Postmark DMARC の無料プランにアップロードすると可視化できます。下記の点をチェックしましょう。

チェック項目	目安	対処
pct（適用率）	100% で統一	0% の行は無視されたレポート
失敗送信元 IP	0 件	不審 IP は即時ブロック
Alignment 失敗率	1% 未満	高ければ SPF・DKIM の設定漏れ

今後の運用と定期チェック

1. セレクタのローテーション
   • 半年～1 年ごとに新しい DKIM 鍵を追加し、旧鍵を無効化。
2. ブラックリスト監視
   • mxtoolbox.com のアラートを設定し、登録即日で対処。
3. 新規システム導入時の手順書化
   • マーケ施策や外部 SaaS を導入する前に「送信ドメイン認証確認チェックリスト」を回付。

まとめ

• SPF が「送信を許可する住所録」、DKIM が「本人確認のサイン」、DMARC が「不正時の指示書」。三位一体で到達率は劇的に向上します。
• 士業事務所は -all、印刷会社は正確な IP 記述、食品メーカーはカスタムドメイン化が主要ポイント。
• 導入後こそレポートと鍵ローテーションの継続が重要。チェックを怠らなければ迷惑フォルダ入りはレアケースとなり、顧客接点のロスを最小化できます。