DBC Tech Academy

DBC Tech Academy / セキュリティ / 初級

送ったメールが迷惑メールに入る原因届いたメールの認証結果を読み、SPF・DKIM・DMARC のどこで落ちたかを突き止めて直す

取引先から「メールが迷惑メールに入っていました」と言われたとき、件名の言葉を変えたり、思いつく設定を足したりする前にできることがあります。受信したメールサーバーは、そのメールが本当に自社のドメインから来たかを 3 つの方法で確かめ、結果をメールの中に書き残しています。この講座では、その 1 行を自分で読み、どの判定で落ちたかから原因を突き止めて直すまでを、取引先に手間をかけずに進める手順として身につけます。

判定を動かして試す 先に結論を読む
gmail / show original
Authentication-Results: mx.google.com; dkim=none; spf=fail (google.com: domain of tanaka@example.jp does not designate 198.51.100.25 as permitted sender) smtp.mailfrom=tanaka@example.jp; dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=example.jp

送ってきたサーバーが、自社のドメインの許可リストに載っていません。本文の言葉ではなく、この 3 つの判定が振り分けを決めています。

01 / Start here

最初に見るのは認証結果の 1 行

この講座の軸は 1 つです。業務メールが迷惑メールに入るかどうかは、本文の言葉より先に「このメールは本当にそのドメインから来たか」という受信側の検査で決まる。その結果は、相手に届いたメールの中に 3 つの判定として残っている。原因を探すときは、設定を足す前にこの判定を読みます。

本文より
認証まず 3 つの判定を読む

3 つの判定が、それぞれ何を確かめているか。

判定 確かめていること fail のとき疑うもの spf 送ってきたサーバーが許可リストに載っているか SPF レコード・送信経路 dkim 電子署名が付いていて、改ざんされていないか DKIM の有効化・署名ドメイン dmarc 見た目の差出人と、上の 2 つのドメインが揃うか 上の 2 つの結果と方針

Gmail・Yahoo!・Outlook のような大手のメールサービスは、届いたメールが差出人のドメインから正しく送られたかを、送信ドメイン認証 (email authentication) と呼ばれる仕組みで確かめています。この検査に落ちたメールは、本文がどれだけ丁寧でも迷惑メールに入るか、受け取りを拒否されます。件名や本文の言葉が判定に効くのは、検査を通った後です。

検査の結果は、受信したメールの中に Authentication-Results という行で残ります。自分の Gmail の個人アドレスに 1 通送れば、取引先に頼まなくてもこの行を読めます。spf= dkim= dmarc= のどれが fail かで、疑う場所は数か所に絞れます。

02 / How it works

受信側がメールを確かめる仕組み

メールは、手紙と同じように封筒と中身でできています。受信側の検査を理解するには、まず 1 通のメールが差出人を 2 か所に持っていることを押さえます。

封筒の差出人と、見た目の差出人

封筒の差出人

Return-Path: <tanaka@example.jp>

送信サーバーどうしが受け渡しのときに使う差出人で、届かなかったときのエラーメールはここへ返ります。メールソフトの画面には出ません。SMTP の MAIL FROM、エンベロープ From (envelope from) とも呼ばれます。

見た目の差出人

From: 田中 一郎 <tanaka@example.jp>

受信者が画面で見る差出人です。ヘッダーの From (header from) と呼ばれます。普段の業務メールでは封筒の差出人と同じドメインですが、別の値を書くこともできます。

2 つの差出人が別のドメインになるのは、配信サービスや問い合わせフォームのサーバーが、届かなかったメールを自分で受け取るために封筒の差出人を自分のドメインにする場合が代表的です。

3 つの検査

送信サーバーMicrosoft 365、レンタルサーバー、フォームのサーバー
SPF封筒の差出人のドメインの DNS に、送ってきたサーバーの IP アドレスが許可されているかを確かめます。
DKIMメールに付いた電子署名を、署名したドメインの DNS にある公開鍵で検証し、途中で書き換えられていないかを確かめます。
DMARC見た目の差出人のドメインと、SPF・DKIM で通ったドメインが揃っているかを確かめ、揃わないときの扱いをドメインの方針から決めます。
受信サーバー受信トレイ・迷惑メール・受信拒否に振り分ける

図は、受信サーバーが振り分けを決める前に行う 3 つの検査を並べています。

SPF (Sender Policy Framework) は、自社のドメインの DNS に「このドメインのメールを送ってよいサーバーの一覧」を TXT レコードで書いておく仕組みです。受信側は、メールを渡してきたサーバーの IP アドレスが一覧に入っているかを確かめます。確かめる対象は封筒の差出人のドメインで、見た目の From ではありません。また、メールが途中で転送されると、送ってくるサーバーが転送元に変わるので、SPF は落ちます。

DKIM (DomainKeys Identified Mail) は、送信サーバーがメールに電子署名を付け、受信側がその署名を、署名したドメインの DNS に公開してある公開鍵で検証する仕組みです。署名には署名したドメインが d= として書かれます。本文やヘッダーを書き換えなければ、転送されても署名は残ります。

DMARC は、SPF と DKIM の結果を見た目の From のドメインに結びつける仕組みです。SPF か DKIM のどちらかが pass し、しかもそのドメインが From のドメインと揃っていれば pass になります。この揃っていることをアライメント (alignment) と呼びます。揃わなかったときに受信側にどう扱ってほしいかを、ドメインの持ち主が p=none（何もしない）、p=quarantine（迷惑メールへ）、p=reject（受け取らない）で DNS に宣言します。

3 つは役割が分かれていて、1 つだけでは守りが閉じません。SPF だけでは From を偽ったメールを止められず、DKIM だけでは署名の無いメールをどう扱うかが決まりません。DMARC が 2 つの結果を From に結びつけて初めて、受信側は「このドメインを名乗るメールが本物か」を判断できます。

DNS に書くもの

3 つとも、自社のドメインの DNS に TXT レコードを書いて使います。どこに何を書くかは次のとおりです。

仕組み名前中身の例
SPFexample.jpv=spf1 include:spf.protection.outlook.com -all
DKIMselector1._domainkey.example.jp公開鍵（Microsoft 365 では CNAME で指す）
DMARC_dmarc.example.jpv=DMARC1; p=none; rua=mailto:dmarc@example.jp

情報処理技術者試験との対比

情報処理技術者試験は、SPF を何度も出題しています。令和 5 年度の情報セキュリティマネジメント試験は、正規の送信サーバーの IP アドレスを DNS に登録し、受信側がそれを参照して判定するという仕組みだけを正解にしていて、この説明は正しいものです。一方で、応用情報技術者試験は SPF を「受信した電子メールの送信元ドメインが詐称されていないことを検証する仕組み」と書き、目的を「メール送信のなりすましを検知する」とする問題も出しています。平成 30 年度の情報セキュリティマネジメント試験と基本情報技術者試験も、SPF で「ドメインの詐称がないことを確認する」を正解にしています。

誤っているのは「ドメインの詐称を検知する」という効果の説明です。SPF が検証するのは封筒の差出人のドメインだけで、受信者が画面で見る From は検証しません。攻撃者が自分で取ったドメインを封筒の差出人にして、From だけを取引先のドメインに偽れば、SPF は pass になります。試験の説明のまま「SPF を入れたので、自社を名乗るなりすましメールは防げる」と判断すると、そのなりすましメールを受信者に届けてしまいます。From の詐称を検知するのは、From と SPF・DKIM のドメインの一致を確かめる DMARC です。

03 / Reading headers

届いたメールのソースを読む

判定は、受信したメールのヘッダーに書かれています。取引先に頼んで転送してもらう必要はありません。自社のアドレスから自分の Gmail の個人アドレスへ 1 通送り、Gmail の側で開いてみましょう。Gmail は 3 つの判定をすべて書き残すので、最初の確認先に向いています。

Gmail で開く

  1. 自社のアドレスから Gmail へ送る

    迷惑メールに入ると言われた社員のパソコン・メールソフトから、普段どおりに送ります。送り方が人によって違うときは、それぞれの人から送ります。

  2. メールを開き、メニューからソースを表示する

    パソコンのブラウザで Gmail を開き、届いたメールの返信ボタンの横の「その他」（︙）から「メッセージのソースを表示」を選びます。迷惑メールフォルダに入っていても同じように開けます。

  3. 上の表で 3 つの判定を見る

    新しいタブの上部に、SPF・DKIM・DMARC がそれぞれ PASS か FAIL かを示す表が出ます。SPF の行には送ってきたサーバーの IP アドレス、DKIM の行には署名したドメインが添えられています。

  4. 本文の Authentication-Results を読む

    表の下に続くヘッダーから Authentication-Results の行を探します。表だけでは分からない、封筒の差出人と署名ドメインがここに書かれています。

Outlook で開く

取引先が Outlook を使っていて、届いたメールそのものを見せてもらえる場合は、次の場所で同じ行を読めます。Microsoft 365 で受信したメールでは、Authentication-Results の行に、受信側の総合判定である compauth= も書かれます。

  • 新しい Outlook・Outlook on the web：メールの「その他のアクション」（...）から「表示」→「メッセージの詳細を表示する」を選びます。
  • クラシック Outlook：メールをダブルクリックで開き、「ファイル」→「プロパティ」の「インターネット ヘッダー」を見ます。

行の読み方

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.jp header.s=selector1 header.b=Kx3f9a2Q;
       spf=pass (google.com: domain of tanaka@example.jp designates
         192.0.2.10 as permitted sender) smtp.mailfrom=tanaka@example.jp;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.jp

spf= の括弧の中には、送ってきたサーバーの IP アドレスと、許可されていたかどうかが書かれています。smtp.mailfrom= が封筒の差出人です。

dkim= の後ろの header.i= か header.d= が署名したドメインです。ここが自社のドメインではなく、メールサービスのドメインになっていないかを見ます。

dmarc= の後ろの header.from= が見た目の差出人のドメイン、括弧の中の p= が DNS に宣言した方針、dis= が受信側が実際に取った扱いです。

Authentication-Results の行が複数あるときは、いちばん上の行を読みます。メールが複数のサーバーを経由すると、サーバーごとに行が足され、最後に受け取ったサーバーの行が上に来ます。Received-SPF という行は SPF の結果だけを書く古い形式で、同じ内容が Authentication-Results にもあれば、そちらを読みます。

転送を経たメールには arc= の判定が付くことがあります。ARC (Authenticated Received Chain) は、転送したサーバーが、自分が受け取った時点の認証結果に署名して次のサーバーへ引き継ぐ仕組みです。Gmail や Microsoft 365 は、信頼できる転送元の ARC を見て、転送で SPF が落ちたメールを救うことがあります。救うかどうかは受信側が決めるので、送る側が転送に備えられるのは独自ドメインの DKIM の署名です。

判定値意味設定の誤りを指すか
pass検査に通った指さない
failSPF では、送ってきたサーバーが許可されていない。DKIM では、署名が検証できない。DMARC では、揃ったドメインで通ったものが無い指す。送信経路か DNS の設定がずれている
softfailSPF で許可されていないが、レコードの末尾が ~all なので弱い不合格として扱われた指す。fail と同じ原因を疑う
neutralSPF のレコードが、許可も不許可も言っていない（末尾が ?all）指す。レコードが判定の役に立っていない
none検査の材料が無い。SPF や DMARC のレコードが無い、DKIM の署名が付いていない指す。設定が入っていない
permerrorレコードの書き方の誤りで、検査ができなかった指す。レコードを直すまで毎回起きる
temperrorDNS の一時的な障害で検査ができなかった指さない。時間をおいて送り直して確かめる

04 / Simulator

迷惑メール判定のシミュレーター

自社 example.jp は、レンタルサーバーのメールから Microsoft 365 に移ったばかりです。 送信経路と、DNS に書いた SPF・DKIM・DMARC を切り替えて、Gmail に届いたメールの判定と振り分けがどう変わるかを確かめてみましょう。


          

            
SPF-

            
DKIM-

            
DMARC-

            
振り分け-

          

          

        

        

          
送信経路

          

            
            
          

          
自社の DNS

          

            
            
          

          

            
            
          

          

            
            
          

          
旧サーバーとフォームのサーバーは、DKIM の署名を付けない設定のままとしています。

        

      

      
振り分けは、Gmail が認証の結果と DMARC の方針に従って扱う場合を再現しています。ヘッダーの書式は Gmail の例に合わせ、署名やレコードが無いときは none で示しています。


      

        

          
動かすと見えること

          
移行後に SPF を旧サーバーのままにすると、Microsoft 365 から送る全員のメールで SPF が落ちます。それでも DKIM を独自ドメインで署名していれば、DMARC は DKIM で通ります。どちらも整っていないと、全員のメールが迷惑メールに入ります。

          
SPF を正しく直しても、旧サーバーの SMTP で送り続けている人のメールだけは落ちます。メールソフトの送信サーバーの設定が移行前のまま残っている人がいると、「一部の人だけ迷惑メールに入る」という症状になります。

          
取引先の社内で転送されると SPF は落ちますが、独自ドメインの DKIM 署名は残り、DMARC は通ります。SPF だけに頼っていると、転送先で迷惑メールに入ります。

          
DMARC を p=reject にすると、SPF にも DKIM にも載っていない問い合わせフォームのメールは受け取りを拒否されます。方針を強める前に、自社のドメインで送っているサーバーをすべて洗い出す必要があります。

        

      

    


    

      

        
05 / Fixes

        
判定ごとの原因と直し方

        
03 で読んだ判定から、疑う場所を決めます。下の表は、判定ごとに多い原因と、その確かめ方を並べたものです。上の行から順に当たってみましょう。

      

      

        

          
判定多い原因確かめ方直し方

          
            
spf=fail
spf=softfail		メールの移行後に SPF レコードを書き換えていないDNS の TXT レコードを引き、新しい送信サービスの値が入っているかを見る新しいサービスの include: を加え、使わなくなったサーバーを外す

            
spf=fail（一部の人だけ）メールソフトの送信サーバーが旧サーバーのままその人のメールの spf= の括弧に出る IP アドレスを、ほかの人と見比べるメールソフトの送信サーバーを新しいサービスに直す

            
spf=fail（自動送信だけ）問い合わせフォーム・請求書システム・複合機が、別のサーバーから自社のドメインで送っている自動送信のメールを自分宛てに出し、IP アドレスを見るそのサーバーを SPF に加えるか、送信を Microsoft 365 などの SMTP 経由にする

            
spf=permerrorSPF レコードが 2 行ある、または include: の重ねすぎで DNS の参照が 10 回を超えたv=spf1 で始まる TXT レコードの行数と、include: の数を数える1 行にまとめる。使っていない include: を外す

            
dkim=noneMicrosoft 365 や Google Workspace で、独自ドメインの DKIM 署名を有効にしていないdkim= の行が none か、署名が無いかを見る管理画面で独自ドメインの DKIM を有効にし、表示される CNAME か TXT を DNS に書く

            
dkim=pass（署名ドメインが別）配信サービスやフォームのサービスが、自社ではなくサービスのドメインで署名しているheader.i= か header.d= のドメインを見るサービスの案内に従い、自社のドメインで署名する設定にして DNS にレコードを書く

            
dmarc=fail（From がフリーメール）問い合わせフォームが、問い合わせた人の @yahoo.co.jp や @gmail.com のアドレスを From にして、自社のサーバーから送っているheader.from= が自社のドメインではないかを見る。yahoo.co.jp や icloud.com は DMARC を p=quarantine にしているFrom は自社のドメインのアドレスにし、問い合わせた人のアドレスは Reply-To に入れる

            
dmarc=fail上のどれかの結果として、From と揃ったドメインで通ったものが無い同じメールの spf= と dkim= を見る上の行の原因を直す。DMARC 自体は直す場所ではない

          
        

      


      

        

          
DNS を確かめる

          
SPF と DMARC のレコードは、パソコンのコマンドで引けます。Windows ならコマンドプロンプトで nslookup、Mac ならターミナルで dig を使います。

          
# Windows
nslookup -type=txt example.jp
nslookup -type=txt _dmarc.example.jp

# Mac
dig +short txt example.jp
dig +short txt _dmarc.example.jp

          
v=spf1 で始まる行が 2 行以上返ってきたら、それが permerror の原因です。SPF は 1 つのドメインに 1 行しか持てず、2 行あると受信側は判定を止めます。新しいサービスを足すときに、既存の行に書き加えずに行を新しく作ってしまうと、この状態になります。

          
SPF レコードの末尾

          
SPF レコードの末尾の -all は「一覧に無いサーバーからのメールは不合格」、~all は「一覧に無ければ弱い不合格」を意味します。DMARC と組み合わせて使うなら、どちらでも DMARC の判定は同じように fail になります。移行の途中で送信元を洗い出しきれていない間は ~all にしておき、洗い出しが済んでから -all にすると、見落としたサーバーのメールが即座に拒否される事故を避けられます。

        

        

          

            
Microsoft 365 と Google Workspace の DKIM

            
Microsoft 365 は、自社のドメインを追加しただけでは、そのドメインから送るメールに DKIM の署名を付けません。Microsoft Defender ポータルの「メール認証の設定」の DKIM のタブで自社のドメインを選んで鍵を作り、表示される 2 つの CNAME（selector1._domainkey と selector2._domainkey）を DNS に書いてから、署名を有効にします。

            
Google Workspace は、管理コンソールの「アプリ」→「Google Workspace」→「Gmail」→「メールの認証」で独自ドメインの DKIM の鍵を生成し、表示される TXT レコード（google._domainkey）を DNS に書いてから「認証を開始」を押します。

          

          
SPF を書き換えるときは、消す前に送信元をすべて洗い出します。旧サーバーやフォームのサーバーを一覧から消すと、そこから送っているメールが届かなくなります。問い合わせフォームの自動返信、請求書の発行、複合機のスキャン送信、予約システムの通知のように、人ではなく機械が送るメールを特に確かめます。

          
DMARC をいきなり p=reject にしません。認証を通らない正規のメールが、受信側で受け取りを拒否されて消えます。まず p=none にして rua= でレポートを受け取り、自社のドメインで送っているサーバーがすべて pass しているのを確かめてから、p=quarantine、p=reject と強めます。

        

      

    


    

      

        
06 / Sender rules

        
Gmail・Yahoo!・Outlook の送信者要件

        
大手のメールサービスは、送信者に満たしてほしい要件を公開しています。2024 年 2 月に Gmail と米国の Yahoo が要件を強め、2025 年 5 月に Outlook.com が続きました。要件は、すべての送信者に求めるものと、1 日に大量のメールを送る送信者だけに求めるものに分かれます。

      

      

        

          
要件すべての送信者1 日 5,000 通以上を送る送信者

          
            
SPF・DKIMSPF か DKIM のどちらかSPF と DKIM の両方

            
DMARC-レコードを置く（p=none でよい）。From のドメインが SPF か DKIM のドメインと揃っている

            
送信サーバーの逆引き送信サーバーの IP アドレスから逆引きした名前と、その名前から引いた IP アドレスが一致する同左

            
暗号化メールを TLS で送る同左

            
迷惑メール報告率0.3% 未満（目安は 0.1% 未満）同左

            
登録解除-宣伝のメールにワンクリックの登録解除を付け、2 日以内に処理する

          
        

      

      
要件は Gmail の「メール送信者のガイドライン」を軸に、米国の Yahoo と Outlook.com の公表内容と重なる部分を並べています。数値と施行時期は各社のページで更新されます。


      

        

          
普段の業務メールを送る会社が満たすべきなのは、左の列です。SPF か DKIM のどちらかが通っていて、送信サーバーの逆引きと TLS が整っていれば要件は満たします。逆引きと TLS は、Microsoft 365 や Google Workspace、主なレンタルサーバーでは事業者の側で整っています。自社で持つのは SPF と DKIM の DNS の設定です。

          
要件を満たさないメールの扱いは強まっています。Gmail は 2025 年 11 月から、要件を満たさないメールを一時的なエラーや受信拒否で返す扱いを広げています。Outlook.com は 2025 年 5 月 5 日から、1 日 5,000 通を超えて送るドメインのうち認証を満たさないメールを、550 5.7.515 のエラーで拒否しています。日本の Yahoo!メールは送信ドメイン認証を推奨という形で示し、DMARC の方針が quarantine なら迷惑メール、reject なら受信をブロックとして扱います。

          
ただし、要件を満たすことと迷惑メールに入らないことは別です。DMARC が無いドメインは、なりすましメールにそのドメイン名を使われやすく、そのぶん受信側の評価が下がります。社員数が少なく送信数が少ない会社でも、SPF・DKIM・DMARC の 3 つをそろえておくのが、取引先の受信トレイに届き続けるための標準になっています。

        

        

          
1 日 5,000 通を数えるとき

          
5,000 通は、同じドメインから Gmail の個人アカウントへ 24 時間に送った通数で数え、サブドメインからの送信も合算します。一度この数に達すると、その後はずっと大量送信者として扱われます。会社全体の業務メールにメールマガジンや自動通知が加わると、思ったより早く届く数です。

          
メールマガジンを同じドメインで送っているなら、配信サービスの側でも自社のドメインの SPF・DKIM を通す設定が要ります。配信サービスの案内に従って、DNS にレコードを足します。

        

      

    


    

      

        
07 / Beyond auth

        
認証が全部 pass でも迷惑メールに入るとき

        
3 つの判定がすべて pass なのに迷惑メールに入るなら、原因は認証の外にあります。ここで初めて、送信元の評価や本文を疑います。

      

      

        

          
送信サーバーの IP アドレスの評価

          
共有のレンタルサーバーでは、同じサーバーを使うほかの利用者が迷惑メールを送ると、IP アドレスがブラックリストに載り、同居している全員のメールが疑われます。MXToolbox や Spamhaus の照会ページに、03 で読んだ IP アドレスを入れると、載っているかを確かめられます。載っていたら、レンタルサーバーの事業者に連絡するか、Microsoft 365 などの送信サービスに移ります。

        

        

          
ドメインの評価

          
取ったばかりのドメインは、受信側に実績が無いため慎重に扱われます。Gmail 宛てに一定量を送っているなら、Google Postmaster Tools に自社のドメインを登録すると、Gmail から見たドメインの評価と迷惑メール報告率を確かめられます。

        

        

          
本文とリンク

          
短縮 URL、画像 1 枚だけの本文、本文のリンク先のドメインと From のドメインが無関係なメールは、フィッシングの特徴と重なります。業務メールでは、リンクは自社のドメインか取引先が知っているドメインのものを、短縮せずに書きます。

        

        

          
受信者の側の設定

          
受信者が過去にそのアドレスを迷惑メールとして報告したり、ブロックしたりしていると、その人宛てのメールだけが迷惑メールに入ります。ほかの受信者には届いていて、1 人だけが迷惑メールに入るなら、その人に「迷惑メールではない」を押してもらうのが効く場面です。

          
件名の先頭に [SPAM] のような印が付いて届くときは、受信者のメールソフトではなく、その手前のメールサービスや会社のメールサーバーが判定しています。メールソフトの「信頼できる差出人のリスト」に入れても効かないので、判定したメールサービスの Web 画面で「迷惑メールではない」と報告してもらいます。

        

      

    


    

      

        
08 / Read the symptom

        
よくある相談 3 例

        
社内でメールの管理を兼ねている人に持ち込まれる相談です。いずれも理解のための架空の状況です。届いたメールの判定から、何が起きているかを考えてみましょう。

      

      

      

        

        

          

          

          
        

      

    


    

      

        
09 / Myth vs. reality

        
よくある勘違い

        
どれももっともらしく、メールに詳しそうな人ほど口にしがちな話です。

      

      

        
MISCONCEPTION 01
「件名や本文の言葉が原因だから、言い回しを変えれば直る」
業務メールで先に効くのは送信ドメイン認証です。認証に落ちたメールは、言葉を変えても迷惑メールに入り続けます。言葉を疑うのは、03 届いたメールのソースを読むで 3 つの判定がすべて pass だと確かめた後です。

        
MISCONCEPTION 02
「SPF を登録したから、もう大丈夫」
SPF レコードが 2 行あると permerror になり、登録していないのと同じになります。正しく 1 行でも、取引先の社内で転送されると SPF は落ちます。転送に耐えるのは DKIM で、From と揃えるのは DMARC です。04 迷惑メール判定のシミュレーターで、転送を選んで確かめられます。

        
MISCONCEPTION 03
「取引先に迷惑メールの解除を頼めば解決する」
解除が効くのは、その取引先のその受信者だけです。原因が認証にあるなら、ほかの取引先でも、同じ取引先の別の人でも同じことが起きています。解除を頼むのは、認証がすべて pass で、1 人だけが迷惑メールに入るときです。

      

    


    

      

        
10 / Knowledge check

        
理解度チェック

        
答えを当てるだけでなく、なぜそう判断できるのかを説明できれば合格です。

      

      

        

          YOUR PROGRESS
          01 / 08
          

        

        

          

          

          
選択肢を1つ選んでください。

          

        

      

    


    

      
Take it home

      
本文を疑う前に、認証結果を読む

      

        
自分宛てに送るGmail の個人アドレスへ 1 通

        
3 つの判定を読むspf・dkim・dmarc のどれが落ちたか

        
DNS と経路を確かめるレコードの行数、送信サーバー、署名ドメイン

        
直して送り直す判定がすべて pass になるまで

      

      

        
業務メールが迷惑メールに入るかどうかは、本文の言葉より先に、受信側の送信ドメイン認証で決まります。SPF は送ってきたサーバーを、DKIM は電子署名を、DMARC は見た目の差出人とそれらのドメインが揃っているかを確かめ、その結果は届いたメールの Authentication-Results に残ります。

        
原因を探すときは、設定を足す前に自分宛てに 1 通送り、どの判定で落ちたかを読みます。SPF ならレコードと送信経路、DKIM なら署名ドメイン、DMARC なら上の 2 つの結果に原因があります。直したら同じ手順で送り直し、3 つがすべて pass になったのを確かめてから、DMARC の方針を強めます。

      

      
      
 ほかの講座を見る

      

        
参考資料