【2026年】送信ドメイン認証の設定｜迷惑メール判定を防ぐ

月曜の朝、配信ツールのレポートを開くと、先週送ったメールマガジンの到達率が前の月より大きく落ちている。エラーの内訳を追うと、届かなかった宛先の多くがGmailとYahoo!メール。文面を変えたわけでもリストを買い足したわけでもないのに、なぜか届かない——メール施策の相談で、こういう症状は珍しくありません。そして最初に確認するのは文面ではなく、DNSです。Googleは2024年2月から、Gmail宛に1日5,000件以上を送る送信者に対してSPFとDKIMの両方、そしてDMARCの設定を求めるようになりました。つまりメールが届くかどうかは、送る前にドメイン側の設定で決まっている部分が大きい。本記事では、SPF・DKIM・DMARCそれぞれの役割の違いから、DNSレコードの具体的な書き方、p=noneからrejectへの段階移行、集約レポートの読み方、MA・配信ツールを使う場合の設定、そして現場で頻発する失敗までを、手順に沿って整理します。

送信ドメイン認証とは：メールの身元を証明する3つの仕組み

メール送信の基盤であるSMTPというプロトコルは、差出人の欄を送信側が自由に書ける前提で設計されています。手紙の封筒に好きな差出人名を書けるのと同じで、技術的には誰でも他社を名乗ってメールを送れてしまいます。この構造的な弱点を埋めるために後から足されたのが送信ドメイン認証で、DNSという公開の場所に「このドメインから送られるメールはこう検証してください」と宣言しておくという考え方に立っています。

実装の中身は、ほぼすべてDNSレコードの追加です。SPFはドメインのTXTレコード、DKIMはセレクタ付きのサブドメインのTXTレコード、DMARCは_dmarcで始まるサブドメインのTXTレコードとして公開します。メール本文の書き方や配信ツールの画面設定ではなく、ドメインそのものの設定であることが重要です。したがって作業はマーケティング担当だけでは完結せず、DNSを管理している情報システム部門や制作会社との共同作業になるのが普通です。着手時点で、誰がDNSレコードを触れるのかを確認しておくと段取りが崩れません。

なお、迷惑メール判定は認証だけで決まるものではありません。開封や返信といった受信者の反応、迷惑メール報告の割合、配信停止の扱い、リストの鮮度なども総合的に評価されます。ただし、認証が欠けていると他の要素が良好でも足切りされるという順序があります。送信ドメイン認証は加点項目ではなく、その他の努力を成立させるための土台だと捉えてください。

SPF：送信を許可したサーバーをDNSで宣言する

SPF（Sender Policy Framework）は、そのドメインを名乗ってメールを送ってよい送信元を、DNSのTXTレコードに列挙しておく仕組みです。受信側のサーバーは、メールを受け取った時点でエンベロープFrom（Return-Path）のドメインのSPFレコードを引き、実際に接続してきたIPアドレスがそこに含まれているかを照合します。含まれていればpass、含まれていなければfailです。

記述はv=spf1で始まり、include・ip4・ip6・a・mxといったメカニズムを空白区切りで並べ、最後に該当しなかった場合の扱いを示す修飾子を置きます。自社メールをGoogle Workspaceで運用し、配信ツールを1つ併用している場合は、次のような形になります。

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.haishin-tool.example ~all"

末尾の~allはsoftfail（該当しない送信元は疑わしいが拒否まではしない）、-allはhardfail（該当しない送信元は拒否してよい）を意味します。運用の初期は~allで様子を見て、送信元の棚卸しが終わってから-allに寄せるのが安全です。またSPFには、後述するとおり1ドメインにレコードは1つだけ・DNS参照は10回までという厳しい制約があり、ここを踏み外すと認証そのものが成立しなくなります。加えてSPFはメールが転送されると経路が変わって失敗しやすいという弱点も持っており、これを補うのが次のDKIMです。

DKIM：電子署名で改ざんとなりすましを見抜く

DKIM（DomainKeys Identified Mail）は、送信側がメールのヘッダーと本文に対して秘密鍵で電子署名を付け、対応する公開鍵をDNSに公開しておく仕組みです。受信側は署名に書かれたドメインとセレクタから公開鍵を取得し、署名を検証します。検証が通れば、そのドメインの管理者が確かに送ったもので、途中で書き換えられていないことが確認できます。

公開鍵は「セレクタ._domainkey.ドメイン名」という位置にTXTレコードとして置きます。セレクタは送信元ごとに別の名前を付けられるため、自社メールサーバーとMAツールと配信ツールがそれぞれ独立にDKIMを持つことができます。レコードの形は次のようなものです。

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

鍵の長さについて、Gmailのガイドラインは1,024ビット以上のDKIM鍵が必要とし、セキュリティ上の理由から2,048ビットの鍵を推奨しています。配信ツール側で鍵を生成する場合は、既定値が1,024ビットになっていないかを確認しておくとよいでしょう。SPFが「どの経路から来たか」を見る仕組みなのに対し、DKIMは「中身が誰のものか」を見る仕組みです。この違いがあるため、転送された結果SPFが失敗しても、DKIMが生き残っていればDMARCは通るという関係が成立します。

DMARC：認証に失敗したメールの扱いを宣言する

SPFとDKIMは検証の方法を提供するだけで、検証に失敗したメールをどう扱うかは受信側の判断に委ねられていました。DMARC（Domain-based Message Authentication, Reporting and Conformance）は、その扱いを差出人側から宣言できるようにした仕組みです。加えて、自ドメインを名乗るメールの認証結果を集計したレポートを受け取れるという、運用上きわめて重要な機能を持っています。

レコードは_dmarc.ドメイン名にTXTレコードとして公開します。最小構成は次のようになります。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

pが扱いを示すポリシーで、値は3種類です。noneは何もせず通常配信し結果だけ報告させる監視モード、quarantineは迷惑メールフォルダなどに隔離、rejectは受信側サーバーがSMTPのやり取りの中で受け取り自体を拒否します。導入直後にrejectを設定すると、設定漏れのある正規メールまで消えてしまうため、まずnoneで実態を把握するのが定石です。そしてDMARCの判定は、SPFやDKIMが単にpassしただけでは通りません。次に説明するアライメントという条件が絡みます。

アライメント：SPFが通ってもDMARCが落ちる仕組み

アライメント（identifier alignment）とは、受信者の画面に表示されるヘッダーFromのドメインと、SPFで検証されたドメイン、またはDKIM署名のd=に書かれたドメインが一致しているかという条件です。Gmailのガイドラインも「送信者のFrom:ヘッダー内のドメインは、SPFドメインまたはDKIMドメインと一致している必要があります」と明記しています。どちらか一方でもアライメント付きでpassしていればDMARCは通ります。

実務でつまずくのはここです。配信ツールを既定設定のまま使うと、エンベロープFromがツール側の共有ドメインになり、ヘッダーFromだけが自社ドメインという状態になります。この場合、ツールのドメインとしてはSPFがpassするのに、自社ドメインとのアライメントが成立せずDMARCはfailするという、一見矛盾した結果が出ます。「SPFは設定済みなのに届かない」という相談の多くは、この形です。解決策は、ツール側で自社サブドメインをバウンス用ドメインとして登録し、あわせて自社ドメインでDKIM署名させることです。

アライメントには2つのモードがあります。既定のrelaxed（r）は組織ドメインが一致していればよく、news.example.comとexample.comは一致扱いになります。strict（s）は完全一致を要求します。aspf=sやadkim=sで厳格化できますが、サブドメインで配信している構成では正規メールが落ちやすくなるため、通常はrelaxedのまま運用し、必要が生じてから検討する順序が安全です。

GmailとYahooの送信者要件：2024年2月からの必須事項

2024年2月1日から、Gmailのメール送信者ガイドラインは要件を明確に線引きしました。すべての送信者に対しては、送信元ドメインへのSPFまたはDKIMの設定、送信元のドメインまたはIPに有効な正引きおよび逆引き（PTR）のDNSレコードがあること、メール送信にTLS接続を使うこと（この項目は2023年12月に追加）、RFC 5322に準拠した形式、GmailのFrom:ヘッダーのなりすましをしないこと、そして迷惑メール率を0.3%未満に維持することが求められます。

さらに、Gmailのアカウント宛に1日あたり5,000件以上を送る送信者には追加の要件が課されます。SPFとDKIMの両方の設定、DMARCの設定、FromヘッダーとSPF／DKIMのアライメント、そしてワンクリックで登録解除できる仕組みです。後者はList-UnsubscribeとList-Unsubscribe-Postの両ヘッダーを実装し、メッセージ本文にも解除リンクをわかりやすく表示することが要件になっています。DMARCのポリシーはp=noneでも要件を満たします。

項目	すべての送信者	1日5,000件以上の送信者
認証	SPFまたはDKIMのいずれか	SPFとDKIMの両方＋DMARC（p=noneでも可）
アライメント	明示の要件なし	FromヘッダーがSPFまたはDKIMのドメインと一致
登録解除	本文に解除手段	ワンクリック解除（List-Unsubscribe系ヘッダー）＋本文リンク
解除の処理	速やかに	2日以内に処理
迷惑メール率	0.3%未満	0.10%未満を目標・0.30%以上にしない

Yahoo（米国のYahoo Inc.）も同じ時期に足並みをそろえ、公式の送信者ベストプラクティスで「2024年2月から次の送信基準の適用が始まる」と告知し、上半期にかけて段階的に適用していくと説明しています。内容はほぼ共通で、一括送信者にはSPFとDKIMの両方、少なくともp=noneの有効なDMARCポリシー、ワンクリック登録解除の実装、そして解除要求を2日以内に処理することを求めています。迷惑メール率の基準は0.3%未満です。

• 5,000件の判定はGmailアカウント宛の1日の通数。第三者の解説では、一度この規模に達した送信者は以後も一括送信者として扱われると説明されている
• ここで挙げたYahooはYahoo! JAPAN（LINEヤフー）とは別の事業者。国内向けの要件は各社の公式情報で個別に確認すること
• 迷惑メール率はGoogle Postmaster Toolsで確認する。数値が跳ねる日があっても、0.30%を継続して超えない運用を目標にする

設定の手順：診断からrejectまでの5ステップ

ここからは実際の作業手順です。順番を入れ替えると事故につながるため、この並びのまま進めてください。特に、DMARCのポリシー強化は必ず最後です。

この5ステップは、早ければ1か月半、丁寧に進めるなら3か月程度を見込む工程です。期間の大半はステップ4のレポート収集に費やされます。ここを短縮したい気持ちが、そのままrejectでの事故につながるため、待つこと自体が作業だと考えてください。

SPFレコードの書き方と直し方

SPFの設定作業は、実質的に送信元の棚卸し作業です。棚卸しの精度がそのままレコードの正しさになります。各サービスのヘルプページには「SPFにこれを追加してください」というinclude文字列が必ず案内されているので、それを集めて1行にまとめます。逆に言えば、ヘルプに書かれていないサービスからのメールは認証されないということです。

最も多い事故は、SPFレコードを2つ以上公開してしまうことです。新しいツールを導入するときに既存のレコードへ追記せず、別のTXTレコードとして追加してしまうと、受信側は複数のSPFレコードを検出してPermErrorと判定し、SPF認証そのものが成立しなくなります。追記ではなく統合が原則で、既存レコードの中身にincludeを足す形にしてください。

もう1つの制約がDNS参照回数の上限です。SPFの評価はレコードを左から順に処理し、includeやa、mxのようにDNS問い合わせを必要とするメカニズムに当たるたびに参照を1回消費します。この回数が10回を超えた時点で評価を打ち切り、PermErrorを返します。ip4やip6での直接指定は参照を消費しないため、includeを展開してIPアドレスを直接書く「フラット化」で回数を減らすという手法もあります。ただし提供側のIP変更に追従できないと逆に認証が壊れるので、追従の運用を決められる場合に限って採用してください。

DKIMの有効化と鍵の公開

DKIMは送信元ごとに個別に設定します。Google Workspaceであれば管理コンソールでドメインのDKIM鍵を生成し、表示されたセレクタとTXT値をDNSに追加してから「認証開始」を実行します。配信ツールやMAツールも流れは同じで、管理画面で発行された値をDNSに登録し、ツール側で検証させます。DNSに登録しただけでは有効にならず、ツール側で有効化の操作が必要な製品が多い点に注意してください。

セレクタが送信元ごとに異なるため、DKIMはいくつでも並列に存在できます。これはSPFと対照的な性質で、送信元が増えても上限に当たりません。したがって送信元が多い会社では、SPFで全部を通そうとせず、DKIMのアライメントでDMARCを通す設計に寄せるのが現実的です。SPFは自社の主要な送信経路に絞り、それ以外はDKIMで担保するという分担です。

運用面では、鍵の入れ替えを想定しておきます。セレクタを変えた新しい鍵をDNSに追加し、切り替え後に旧セレクタのレコードを残したまま一定期間置いてから削除する、という手順にすれば配信を止めずに交換できます。また、2,048ビット鍵の公開鍵はTXTレコードの1文字列上限を超えることがあり、DNSサービスによっては複数文字列に分割して記述する必要があります。登録後に検証ツールでpassするかを必ず確認してください。

DMARCレコードの書き方とタグの意味

DMARCレコードは複数のタグをセミコロンで区切って並べます。監視段階から少し進んで、サブドメインのポリシーや適用割合まで指定した例を挙げます。

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; sp=reject; pct=50; adkim=r; aspf=r; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"

タグ	必須／任意	意味と使いどころ
v	必須	DMARCのバージョン。v=DMARC1で固定
p	必須	ポリシー。none／quarantine／rejectのいずれか
sp	任意	サブドメインに適用するポリシー。親と別扱いにしたいときに指定
rua	推奨	集約レポートの送信先。mailto:を付ける
ruf	任意	失敗レポートの送信先。送ってこない事業者も多い
pct	任意	ポリシーを適用する割合（0〜100）。段階移行に使う
adkim / aspf	任意	アライメントの厳格度。r=relaxed（既定）／s=strict
fo	任意	失敗レポートを生成する条件の指定

設定ミスの定番は4つあります。ホスト名の_dmarcのアンダースコアを落とす、タグの区切りのセミコロンを忘れる、ruaの値にmailto:を書き忘れる、そしてSPFとDKIMが整っていないうちにpをrejectにする、です。前の3つはレコードが解釈されずDMARCが機能しないだけで済みますが、最後の1つは正規メールの消失につながります。公開直後に検証ツールでレコードが正しく読めているかを確認する工程を、必ず挟んでください。

レポートの受け取り先を自社ドメイン以外（外部の解析サービスなど）に指定する場合、受け取る側のドメインに「このドメインのレポートを受け取ってよい」という許可のDNSレコードが必要になります。解析サービスを使うときは、案内された許可レコードの登録漏れがないかを確認してください。レポートが1件も届かないときは、この登録漏れが原因であることが少なくありません。

p=noneからrejectへ：段階移行の進め方

段階移行の目的は、知らない送信経路を炙り出してから締めることです。実務では、経理システムの通知メール、採用管理ツールからの自動返信、社内の別部署が契約していた配信ツールなど、マーケティング部門が把握していない経路が必ず出てきます。p=noneの期間はそれを見つけるための時間です。目安は2〜4週間で、月次の定期配信がある場合は少なくとも1サイクル分を含めます。

次にpctタグを使って部分適用します。p=quarantineでpct=25とすれば、認証に失敗したメールのうち25%だけが隔離され、残りは受信側の判断に委ねられます。ここで1〜2週間ずつ様子を見ながら50%、100%へ広げ、問題がなければrejectへ移します。各段階で「配信できていない」という社内からの申告がないかを確認するのが、実質的な検証手段になります。

見落としがちなのがサブドメインの扱いです。DMARCは親ドメインのポリシーがサブドメインにも継承されますが、spタグで別扱いにできます。逆に、メール送信に使っていないドメインやサブドメインは、最初からp=rejectで宣言しておくのが安全です。休眠ドメインは、なりすましに使われやすい割に自社の正規配信を壊す心配がありません。使っていないドメインこそ真っ先に締めるという順序を覚えておいてください。

DMARCレポートの読み方

DMARCのレポートには2種類あります。ruaで受け取る集約レポート（Aggregate Report）はXML形式の統計情報で、通常24時間ごとに送られてきます。運用の中心はこちらです。もう一方のrufで受け取る失敗レポートは個別メールに関する情報を含むため、プライバシーへの配慮から送信しない事業者も多く、届かない前提で設計するのが現実的です。

集約レポートで見るべき点は絞れます。第一にsource_ip——どのIPアドレスから自ドメインを名乗るメールが送られているか。見覚えのないIPが継続的に出ているなら、なりすましか、把握していない社内経路です。第二にcount——その経路の通数。第三にSPFとDKIMの結果、そしてそれぞれのアライメントの成否。第四にdisposition——受信側が実際にどう扱ったか。この4点を突き合わせると、「正規なのに認証で落ちている経路」が特定できます。

XMLは人が読む形式ではないため、可視化ツールを使うか、生成AIに整形させるのが実務的です。レポートのXMLを貼り付けて「送信元IPごとに通数とSPF／DKIMのアライメント結果を表にまとめ、認証に失敗している経路を通数の多い順に並べてください」と指示すれば、確認すべき経路の一覧を短時間で作れます。ただしIPアドレスや宛先ドメインが含まれるため、社外に出せるデータかどうかは事前に社内ルールで確認する必要があります。判断そのものは人が行い、AIは整形と要約に使うという分担が安全です。

MA・配信ツールを使う場合の認証設定

MAツールやメール配信ツールを使う場合、既定設定のままではDMARCが通りません。理由はアライメントの節で触れたとおり、エンベロープFromがツールの共有ドメインになるためです。対処は製品によって名称が異なりますが、「送信ドメイン設定」「カスタムドメイン」「バウンスドメイン」「Return-Pathドメイン」といったメニューから、自社のサブドメインを登録する流れになります。指定されたCNAMEやTXTレコードをDNSに追加すると、自社ドメインでの署名と検証が成立します。

このとき、配信専用のサブドメインを切るかどうかを決めておきます。たとえばnews.example.comを販促メール専用にし、取引に関わるシステム通知は別のサブドメインか本体ドメインから送る構成です。片方のドメインで迷惑メール報告が増えても、もう片方の評価に波及しにくくなるという利点があります。一方で、サブドメインごとに評判を育て直す必要があるため、送信量が小さい会社では本体ドメインに集約したほうが安定することもあります。送信量と用途の数を見て決めてください。

複数のツールを併用している会社では、SPFのinclude数がすぐに増えてDNS参照の上限に近づきます。ここで思い出したいのが、DMARCはSPFとDKIMのどちらか一方がアライメント付きでpassすれば通るという性質です。ツールごとにDKIMを確実に設定し、SPFは主要経路に絞る。この方針にすると、ツールを増やしてもSPFの上限に触れずに済みます。SPFを増やす前にDKIMを固める——これが送信元の多い環境での定石です。

よくある失敗：10ルックアップ超過・複数SPF・サブドメイン放置

設定作業そのものは難しくありませんが、失敗のパターンは驚くほど共通しています。相談の場で実際に見つかるものを挙げます。

• SPFレコードが2つ以上公開されており、PermErrorでSPF認証が成立していない
• includeを足し続けた結果DNS参照が10回を超え、レコードの後半が評価されていない
• 解約済みのツールや使っていない旧システムのincludeが残ったまま放置されている
• 配信ツールを既定設定のまま使い、ヘッダーFromとのアライメントが成立していない
• DMARCをp=noneで公開したまま数年放置し、ruaのレポートを誰も見ていない
• メール送信に使っていないサブドメインにDMARCがなく、なりすましの入口になっている

これらに共通する根っこは、送信元の棚卸しが一度きりで終わっていることです。ツールの導入と解約はマーケティング部門で日常的に起きるのに、DNSレコードはその変化を自動で追いかけてくれません。半年に一度、契約しているツールの一覧とSPF・DKIMの設定状況を突き合わせる時間を取るだけで、この種の不整合はほぼ防げます。

SPFのフラット化についても補足します。includeを展開してip4で直書きすればDNS参照は減りますが、サービス提供側がIPを変更したときに自動では追従しません。手動運用なら変更通知を追う担当を決め、自動化ツールを使うならその費用と管理コストを見込む必要があります。回数削減の第一手は、まず不要なincludeの削除です。使っていないサービスを消すだけで上限を下回るケースが多く、フラット化はその次の手段と位置づけてください。

BIMIと確認の運用：認証の先にあるロゴ表示

送信ドメイン認証を整えた先には、受信箱の送信者欄に自社ロゴを表示するBIMI（Brand Indicators for Message Identification）という仕組みがあります。対応する受信環境で送信者名の横にブランドロゴが出るため、開封前の識別性が上がります。前提条件は、DMARCがp=quarantineまたはp=rejectで運用されていること、規定の形式のSVGロゴを用意すること、そしてBIMI用のDNSレコードを公開することです。

ロゴの正当性を示す証明書には2種類あります。VMC（Verified Mark Certificate）は登録商標を必要とし、対応環境が広いのが特徴です。もう一方のCMC（Common Mark Certificate）はGmail向けに2025年初頭に導入された選択肢で、商標登録は不要ですが、ドメイン上でロゴを12か月以上公開してきた証跡が求められると説明されています。証明書の取得には費用と手続きが伴うため、BIMIは「認証が整い、DMARCをrejectで運用できている会社が次に検討するもの」という位置づけで十分です。

最後に、設定後の点検を運用に落とし込みます。DNSは一度書けば動き続けますが、周囲の環境は変わります。月に一度、次の項目を確認する時間を確保してください。

• SPFレコードが1つだけ公開されており、DNS参照回数が10回以内に収まっている
• 契約中のすべての送信元でDKIMが有効になり、検証ツールでpassしている
• DMARCの集約レポートを確認し、正規経路がすべてアライメント付きでpassしている
• 見覚えのない送信元IPから自ドメインを名乗るメールが出ていない
• Google Postmaster Toolsの迷惑メール率が0.10%未満に収まっている
• 解約したツールのincludeやDKIMレコードが残っていない
• メール送信に使っていないドメイン・サブドメインにp=rejectのDMARCがある

SPFのDNS参照回数は、レコードを可視化する検証サービス（dmarcianのSPF Surveyorなど）を使うと一目で分かります。迷惑メール率はGoogle Postmaster Toolsで確認します。点検の頻度と担当者を先に決めてから設定作業に入ると、公開後に放置される事態を避けられます。

よくある質問

SPFだけ設定してあれば十分ですか？

送信量が小さければ、Gmailの「すべての送信者」向け要件はSPFまたはDKIMのいずれかで満たせます。ただしSPFはメールが転送されると失敗しやすく、配信ツールを使うとアライメントが成立しないことも多いため、実務ではDKIMも設定しておくほうが安定します。1日5,000件以上をGmail宛に送る場合は、SPFとDKIMの両方とDMARCが要件です。

DMARCをp=noneのままにしていても意味はありますか？

あります。p=noneは認証に失敗したメールの扱いを変えませんが、集約レポートが届くようになるため、自ドメインを名乗るメールの実態が見えるようになります。Gmailの一括送信者要件もp=noneで満たせます。とはいえ、noneのままではなりすましを止められないため、レポートで正規経路を確認できた段階でquarantine、rejectへ進めるのが本来の使い方です。

送信量が少ない会社でも設定は必要ですか？

必要です。要件の線引きは1日5,000件ですが、それ未満でもSPFまたはDKIMは全送信者向けの要件に含まれています。さらに、自社ドメインを名乗るなりすましメールは送信量と無関係に発生し得ます。取引先に偽の請求メールが届くリスクを考えれば、送信量の大小ではなくドメインを持っている会社が備えるべき設定と捉えるのが妥当です。

まとめ

SPFは送信サーバーの許可をDNSで宣言し、DKIMは電子署名で内容の正当性を示し、DMARCはその検証に失敗したメールの扱いを宣言する。3つは役割が違い、互いの代わりにはなりません。Gmailは2024年2月から、1日5,000件以上を送る送信者にSPFとDKIMの両方、DMARC、Fromヘッダーとのアライメント、ワンクリック登録解除を求めており、Yahooも同じ時期に同等の基準を示しました。作業の順序は、送信元の棚卸し、SPFの統合、送信元ごとのDKIM、p=noneでのレポート収集、そしてquarantineからrejectへの段階移行です。つまずくのはいつも、複数のSPFレコード、10回を超えたDNS参照、既定設定のままの配信ツール、そして棚卸しの不在。送信ドメイン認証は書いて終わりではなく、送信元が変わるたびに見直す運用です。まずは自社のSPFが1つだけか、参照回数が10回以内かを検証ツールで確かめるところから始めてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。