メール認証代行の相場｜制作会社向けの見積もり方
目次
この記事でわかること
- 制作会社が請け負う「メール認証代行」の作業範囲を 4 工程に分解する考え方
- 各工程の所要時間と難易度の目安、見積もりを積み上げる順序
- 内製で対応するか専門業者に切り出すかの判断軸
「DMARC 対応してくれませんか」と相談されたとき
2024 年 2 月に Google が一括送信者向けの要件を強化して以降、Web 制作会社のディレクターやデザイナーがクライアントから「DMARC（ディーマーク）に対応してほしい」「SPF や DKIM の設定を見直してほしい」と相談されるケースが急に増えています。
ところがいざ見積もりを出そうとすると、
- 「メール認証って、何にどれくらい時間がかかるのか分からない」
- 「クライアントに提示する金額の目安が立てられない」
- 「自社で対応するか、外注するかの判断もつかない」
という壁にぶつかります。これは、メール認証が デザイン・コーディングと違って成果物が目に見えにくい 領域であることが原因です。本記事では、SPF・DKIM・DMARC の代行業務を 4 つの工程に分解し、見積もりを組み立てる順序を整理します。
メール認証代行の作業範囲を 4 工程に分ける
メール認証の代行業務は、丸ごと「DMARC 対応」と呼ばれがちですが、中身を分けると次の 4 工程になります。
工程 1: 現状調査（ヒアリング + DNS 確認）
クライアントが現在使っているメール送信経路（自社サーバー、Google Workspace、Microsoft 365、Mailchimp などの配信サービス）と、SPF・DKIM・DMARC の現在の設定値を洗い出します。
ここで把握すべき情報：
- メール送信に使っているサービスとアカウント
- 現状の SPF レコード（TXT レコードの内容）
- 現状の DKIM セレクタと公開鍵
- 現状の DMARC ポリシー（あれば）
- DNS の管理画面にログインできる体制
工程 2: 設計（SPF / DKIM / DMARC の値を決める）
調査結果をもとに、3 つのレコードを設計します。
- SPF: include で並べる送信元の数を整理し、上限 10 個（RFC 7208 で規定）に収める設計
- DKIM: 送信サービスごとに別々の DKIM セレクタを発行し、鍵長は 2048 ビットを推奨
- DMARC: 最初は
p=noneでレポートだけ集める設計から始め、段階的に強化する
各レコードの考え方はSPF・DKIM・DMARC の違いに整理しています。
工程 3: 反映（DNS への書き込みと送信側の鍵設定）
設計した値を実際に DNS に書き込み、送信側のサービス（Google Workspace、Microsoft 365 など）で DKIM 署名を有効化します。
- DNS 管理画面で TXT レコードを追加
- 送信サービスの管理画面で DKIM 署名を ON
- 反映後 24〜48 時間ほど、TTL の伝搬を待つ
ここで誤った設定を入れるとメールが届かなくなる可能性があります。作業前のレコード保存と、変更後の即時確認を必ずセットにします。
工程 4: レポート分析と継続運用
DMARC を設定すると、毎日大量の XML 形式のレポートが届きます。これを継続的に確認しないと、「設定したつもりが届いていなかった」という事態を見逃します。
- 受信した DMARC レポートの読み方はDMARC レポートの見方を参照
- 異常値（認証失敗の急増）を検知したらクライアントへ通知
- 数週間〜数ヶ月かけて
p=noneからp=quarantine→p=rejectへ段階強化
この継続運用部分は、初期設定とは別の課金体系で扱うのが一般的です。
各工程の所要時間と見積もりの積み上げ方
工程ごとに難易度・所要時間が大きく異なるため、見積もりは「一式いくら」ではなく 工程別に積み上げるのが現実的です。
工程 1（現状調査）の特徴
- 情報がすぐ揃うクライアントなら 1〜2 時間
- アカウント情報が散らかっている、前任業者と連絡がつかないケースは半日〜1 日
- ここで時間がかかると後工程の見積もり精度も落ちるため、最初に着手金として切り出すケースが増えています
工程 2（設計）の特徴
- 単純なケース（送信経路が 1 つ）は 1〜2 時間
- 複雑なケース（送信サービスが 3 つ以上、社内サーバーと配信サービスを併用）は半日〜1 日
- ここでミスると後工程ですべて壊れるため、最も知見が問われる部分
工程 3（反映）の特徴
- DNS 反映自体は 30 分〜1 時間
- 反映後の動作確認（外部送受信テスト）に 1〜2 時間
- 反映タイミングはクライアントの業務時間外を選ぶケースが多い
工程 4（レポート分析と継続運用）の特徴
- 月次で 1〜2 時間の確認作業
- 異常検知時のスポット対応は別途
- 月額固定で運用契約にすると、案件納品後も関係が継続するため制作会社側の継続収益にもなる
具体的な金額レンジは案件規模・業種・対応スピード（夜間・休日対応の有無）で変動するため、本記事では金額そのものを断定しません。ただし「工程ごとに積み上げる」アプローチを取れば、クライアントに「何にいくら払っているか」を説明できる見積もりが作れます。
内製で対応するか、外注に切り出すかの判断軸
すべての工程を制作会社が内製で抱えると、知見の蓄積・管理画面アクセスの保持・夜間対応など負担が大きくなります。工程ごとに内製・外注を分けるのが現実的です。
内製で持つ価値が高い工程
- 工程 1（現状調査）の前段、つまりクライアントとのヒアリング: 業務状況の把握はディレクターが直接やるほうがスムーズ
- 工程 3 のうち DNS 書き込み: 既に Web サイトの DNS を管理している場合、追加でメール認証 TXT を入れるのは手間が増えない
外注に切り出しやすい工程
- 工程 2（設計）: SPF include 上限・DKIM セレクタ・DMARC の段階強化は専門知識が要る領域
- 工程 4（レポート分析と継続運用）: XML レポートを毎月確認するのは負担が大きく、専門業者に出すと工数が一気に減る
具体的に「下請け業者を選ぶ視点」はディレクター向けのドメイン下請け活用ガイドで 5 つの観点に整理しています。
クライアントへの見積もり提示のコツ
技術的な工程をそのまま見積書に書くと、クライアントには伝わりません。ビジネスインパクトの言葉に翻訳するのがコツです。
技術用語からビジネス語への翻訳例：
- 「SPF レコードを設計します」→「Gmail に確実に届くよう、送信元情報を整えます」
- 「DKIM セレクタを発行します」→「メールが改ざんされていない証明書を付けます」
- 「DMARC を
p=quarantineに強化します」→「なりすましメールを取引先のスパム箱に送る設定にします」
そして見積書には次の 3 点をセットで記載します。
- 作業範囲: 4 工程のどこを対応するか（範囲外もはっきり書く）
- 成果物: 設定変更前後のレコード値と、外部からの動作確認レポート
- 責任範囲: クライアント側で操作する部分（管理画面ログイン情報の準備など）と、業者側で操作する部分の境界
このフォーマットで提示すると、クライアントが「何に対していくら払っているか」を理解しやすくなり、追加対応依頼にもスムーズにつながります。
まとめ
- メール認証代行は「現状調査・設計・反映・継続運用」の 4 工程に分解できる
- 見積もりは「一式」ではなく工程ごとに積み上げると、クライアントへの説明がしやすい
- 内製・外注の切り分けは工程単位で考える。設計と継続運用は外注に切り出す価値が高い
クライアント案件のメール認証状態を診断
引き継ぎたばかりの案件や、既存クライアントから「メールが届かない」と相談された案件は、まず無料のドメイン診断で現状を把握できます。SPF・DKIM・DMARC・SSL の状態を 3 分でレポート化でき、クライアントへの提案資料としてもそのまま使えます。
「設計や継続運用部分だけ切り出して任せたい」という制作会社さま向けには、制作会社向けの単発相談もご用意しています。