Gmailに送ったメールが届かない原因と対処法｜SPF, DKIM, DMARCとは何か？メールのなりすまし防止方法について実例で解説

info＠example.comなど自分が持っているドメインのメールアドレスからGmail宛てにメールを送った場合に、Gmailにメールが届かないことがあります。

相手に送信済みのメールBOXを確認してもらったら、メールは送信済みになってる、、、なのに、こちらのGmailには届いていないといった場合です。

この場合、メールサーバーのなりすまし防止の設定（SPF、DKIM、DMARC）が不十分であることが多いです。

ここでは、なぜGmailにメールが届かない状況が発生するのか？や「SPF」「DKIM」「DMARC」とは何か？を実例を交えて解説しています。

なぜGmailにメールが届かない状況が発生するのか？

Gmailは、なりすましメールやスパムを排除するため、受信メールの内容を厳しくチェックしています。

その際にチェックするのが「SPF」「DKIM」「DMARC」です。これらの設定がされていなかったり、不適切だとメールを正しく受信しません。

具体的には次のような場合に、メールを受信しません。

以下で、「SPF」「DKIM」「DMARC」のそれぞれについて詳しく解説していきます。

DNSのTXTレコードに追加する

なお、「SPF」「DKIM」「DMARC」のいずれも、実際に設定するときは、DNS（ドメインネームシステム）のTXTレコードに記述します。

DNSはインターネット上の住所録のようなもので、どのドメインがどのIPアドレスと紐づくといった情報を記載しておくためのものです。

TXTレコード（テキストレコード）とは、ドメインに関する自由なテキスト情報を記述するための、DNSのレコードタイプの一つです。

▼DNSレコード設定の実例

SPFとは何か？

SPF（エスピーエフ）は、特定のドメインからメールを送信する場合に使用するIPアドレスやドメインを指定するものです。メールのなりすましを防ぐための基本的なルールの一つです。

SPFの仕組みは、送信側と受信側の連携によって成り立っています。

SPFにIPアドレスやドメインを記載することで「このメールはこのIPアドレスやドメインから送ります」と前もって宣言することができます。

メールを受信した側は、送られてきたメールのドメインと、SPFで宣言されているドメインやIPアドレスが一致するかを判定することで、本物かどうかを判断することができます。

SPFの仕組み（メール受信/拒否までの流れ）

STEP1：ドメイン所有者(送信側)がルールを宣言する

SPFを使うには、メールを送信するドメイン（例：example.com）の管理者は、そのドメインのDNSレコード（インターネット上の住所録のようなもの）に「SPFレコード」という特別な情報を追記します。

SPFレコードには、「example.comからのメールは、192.0.2.1というIPアドレス持つサーバーやGoogleのサーバーから送られます」といったルールが書かれています。

STEP2：メールを受け取ったサーバーがチェックする

メールを受け取ったGmailなどのサーバーは、メールの送信元ドメイン（example.com）を調べます。

次に、そのドメインのSPFレコードを読み取り、許可されているIPアドレスを確認します。そして、実際にメールを送ってきたサーバーのIPアドレスと、SPFレコードに書かれたIPアドレスを照合します。

STEP3：受信 or 拒否

IPアドレスが一致した場合、「このメールは本物だ！」と判断され、正常に受信箱に届けられます。

IPアドレスが一致しない場合、「このメールは、正規のサーバーから送られていない。なりすましかもしれない！」と判断され、メールは迷惑メールフォルダに振り分けられたり、最悪の場合、受信が拒否されたりします。

SPFの設定方法

SPFレコードは、DNSのTXTレコードとして設定します。

v=spf1 で始まる1行テキスト。ip4:, ip6:, include:, mx, a などの仕組みで送信元を列挙して最後に -all（厳格拒否）や ~all（ソフトフェイル）を記述します。

例えば、自分が使っているドメイン「example.com」にSPFレコードを作成する場合は以下のようにします。

ホスト　　　　  テキストレコード　　SPFの記述
example.com    TXT   　　　　　 　"v=spf1 ip4:203.0.113.5 include:_spf.google.com include:sendgrid.net -all"

SPFの具体的な書き方：例１

例えば、簡単な記述だと以下のように書けます。

v=spf1 ip4:192.0.2.1 -all

これは、192.0.2.1というIPアドレスからのメール送信のみを許可し、それ以外からの送信はすべて拒否するという設定です。

SPFの具体的な書き方：例２

v=spf1 ip4:192.0.2.1 ip4:198.51.100.2 include:_spf.google.com ~all

この設定では、指定した2つのIPアドレスからの送信に加え、includeタグで指定したGoogleの送信サーバーからのメールも許可します。

末尾の~allは、リストにない送信元からのメールを「ソフトフェイル（迷惑メールとして扱う）」ことを意味します。

SPFの具体的な書き方：例３

v=spf1 +a:sv111111.xserver.jp +a:example.com +mx include:spf.sender.xserver.jp include:_spf.google.com ~all

v=spf1: これは、SPFレコードのバージョンを示すもので、SPFのバージョン1を使用していることを意味します。すべてのSPFレコードはこれで始まります。

+a:sv11111.xserver.jpは、sv11111.xserver.jpというホスト名のAレコード（IPアドレス）からのメール送信を許可します。+aは「許可」を意味します。これは、Xserverの特定のサーバーからのメール送信が正当であることを示しています。

+a:example.comは、example.comというドメインのAレコード（IPアドレス）からのメール送信を許可します。このドメインのウェブサイトが設置されているサーバーからのメール送信を許可していることを意味します。ウェブサイトのお問い合わせフォームなどからメールを送信する場合に必要になります。

+mx: このドメインのMXレコードに設定されているすべてのメールサーバーからのメール送信を許可します。これにより、メールの送受信に利用しているサーバーからの送信が正当と見なされます。

include:spf.sender.xserver.jpは、とspf.sender.xserver.jpいうドメインのSPFレコードの内容をこのレコードに含めることを意味します。これは、Xserverが管理している、メール送信に利用されるすべてのIPアドレスを許可リストに加えるために使われます。

include:_spf.google.comは、 _spf.google.comというドメインのSPFレコードの内容をこのレコードに含めることを意味します。これは、Google Workspace（旧G Suite）やGmailのSMTPサーバーを経由してメールを送信する場合に必要です。これにより、Googleのメール送信サーバーからのメールも正当と見なされます。

~all: 上記のルールに一致しないすべてのメールを「ソフトフェイル（SoftFail）」として扱います。これは、SPF認証に失敗したメールであっても、すぐに拒否するのではなく、迷惑メールとしてマークするなど、受信側に判断を委ねることを意味します。~（チルダ）は、SPFレコードの終端を示すものです。

include:_spf.google.comが必要になるのはどんなとき？

SPFはあくまで送信時に必要となる情報です。受信には関係ありません。このため「include:_spf.google.com」と記述したから、Gmailで受信できるわけではありません。

「include:_spf.google.com」という記述が必要になるのは、Google Workspaceを導入した場合など、自分のドメインをGoogleアカウントとして登録し、Googleのサーバーからメールを送信するときです。

SPF設定時の注意点

SPFを設定する際は以下に注意してください。

DKIMとは何か？

DKIM（ディーキム）とは、電子署名を使ってメールの内容が送信中に改ざんされていないことや、送信元が正当であることを証明する仕組みです。

簡単に言うと、送信するメールに暗号をかけ、公開されている情報と照合したときに送信元が一致していれば暗号が解けてメールの本文が読めるという仕組みです。

なぜDKIMが必要なのか？

インターネットの世界では、メールの「差出人」を偽って送ることが簡単にできます。

例えば、受信したメールを見ると、差出人（From）に「○○銀行」と表示されているとします。この場合、本物の○○銀行のメールアドレスでなくても、他のメールアドレスの差出人が名前を自由に指定することができます。

こうした「なりすまし」を防ぐために、DKIMが生まれました。

DKIMの仕組み（送受信の流れ）

STEP1：公開鍵を登録しておく

送信側はDNSのTXTレコードに、自分のドメインと紐づけたDKIMの公開鍵を登録しておきます。

こうすることで、世界中のサーバーがドメイン名で検索したときに登録してある公開鍵を参照することができます。

STEP2：メールに暗号化した署名をつける

メールを送信するときに、メールの内容（誰から、誰へ、件名、本文など）をコンピューターが計算し、A社だけが持っている「秘密の鍵」を使って、「DKIM署名」という一意の文字列を生成します。

この署名は、メールの内容が少しでも変わると、まったく違う文字列になります。

STEP3：メールの受信と検証

メールを受信したサーバーは、メールのヘッダー情報にDKIM署名が付けられているかを確認します。

DKIM署名があった場合、DNSに送信元のメールアドレスに紐づくドメインの公開鍵を訪ねます。得られた公開鍵を使って、検証作業を行います。

STEP4：検証結果の判断

検証が成功した場合は、ユーザーの受信トレイにメールを配信します。

DKIMが設定されていないと受信しない

Gmailでメールを受信する際に、そもそもメールにDKIM署名がされていない時点で、迷惑メールフォルダに振り分けたり、受信を拒否したりします。

つまり、Gmail宛てに送ったメールが正しく届くために、送り側のドメインでDKIMを設定しておくことが必須といえます。

DKIMは複数設定できる

DKIMは同じドメインに対して複数設定することができます。

例えば、A社が以下のようにメールを使い分けているとします。

• 自社のメールサーバー: 従業員の日常業務用のメール
• メール配信サービス（例:Gmailを使用）: 顧客向けのメルマガやプロモーションメール
• クラウドサービス（例: Salesforceを使用）: 顧客サポートや通知メール

これらのサービスは、それぞれ別のメールサーバーからメールを送信します。

それぞれのサービスが、自社の秘密鍵で署名できるように、複数のDKIM公開鍵をDNSに設定する必要があります。

この場合、それぞれの公開鍵に異なる「セレクタ（defaultの部分）」を付けて区別します。例えば以下のように設定します。

• default._domainkey.example.com （自社メールサーバー用）
• google._domainkey.example.com （Mailchimp用）
• salesforce._domainkey.example.com （Salesforce用）

DKIMの設定実例

ホスト　　　　　　　　　　　　　　　TXTレコード　　DKIMの記述（公開鍵）
default._domainkey.example.com   TXT  　　　　　v=DKIM1; k=rsa; p=CDBAIjANBgk～

default._domainkey.example.comとは何か？

・example.com
メールのドメイン（差出人メールアドレスの @ の後ろの部分）です。

・_domainkey
DKIMの「お決まりの印」です。インターネット上の「ここにDKIMの公開鍵が置いてあるよ」という目印になります。

・default
セレクタ（Selector）と呼ばれる部分です。一つのドメインで複数のDKIM鍵を使うことができるので、その鍵を識別するための名前です。

これら3つを合わせると、「example.comというドメインの、defaultという名前のDKIM公開鍵」という特定の場所を示しています。メールを受け取ったサーバーは、この場所を探しに行って、公開鍵の情報を入手します。

v=DKIM1; k=rsa; p=CDBAIjANBgk～

・v=DKIM1
v は「Version（バージョン）」の略です。「DKIM1」は、この情報がDKIMのバージョン1であることを示しています。

・k=rsa
k は「Key Type（鍵のタイプ）」の略です。「rsa」は、RSAという有名な暗号方式で鍵が生成されていることを示しています。

・p=MIIBIjANBgk～
p は「Public Key Data（公開鍵データ）」の略です。。「MIIBIjANBgk～」から始まる長い文字列が、実際の公開鍵の情報です。

この文字列は、誰でも見ることができ、メールのDKIM署名を検証するために使われます。

DMARCとは何か？

DMARC（ディーマーク）はDMARCは、SPFとDKIMの検証結果をどう扱うかを定めた、いわば「ルールブック」のようなものです。

もう少し具体的に言うと、SPFとDKIMの検証に失敗したらどう扱ってほしいかを受信側に指示し、集計レポートを受け取れるようにするためのものです。

つまり、DMARCを記述することで、受信側のメールサバ―のメール処理をコントロールできます。

DMARCを使ったメール処理の指示内容

DMARCで、SPFとDKIMの検証に失敗した場合に、受信側のメールサーバーに次の３つの指示をすることができます。

DMARCの記述方法

DMARCは対象のドメイン名の頭に「_dmarc.」とつけます。最低限の構成は v=DMARC1; p=... です。

ホスト　　　　　　　　 TXTレコード　　DMARCの内容
_dmarc.example.com   TXT    　　　　v=DMARC1; p=none;

• _dmarc
  これは、DMARCであることを示すお決まりの表現です。
  
• v=DMARC1
  DMARCのバージョン１であることを示しています。
  
• p=none
  pはpolicyを意味しています。noneなので、メールの処理方法は受信メールサーバーにお任せし、レポートだけをもらいます（＝監視。レポートだけ受け取る）

レポートを受け取る方法

結果のレポートを受け取るためには「ruaでmailto」を指定する必要があります。

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com"

• rua=は、集計レポート（RUA）の送信先です。
• mailto: でレポートの送り先を指定します。

こうすることで、XML形式のレポートが指定したメール宛てに毎日送られます。

ruaがないとどうなる？

ruaを記述しない場合でも、DMARCのポリシー（p=none, p=quarantine, p=reject）は正常に機能します。

ただし、ruaを指定しないと、集約レポートが送信されません。

集計レポートがないと、自社ドメインのメールがどのくらい認証に成功・失敗しているか、また、なりすましメールがどのくらい出回っているかを把握することができなくなります。

DMARCの実際の運用方法（pctを上手に活用する）

DMARCの一般的な運用は、最初は「p=none」で認証に失敗したメールの処理方法は受信サーバーにお任せし、監視レポートだけを受け取ります。

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.com; pct=100"

pct=100とすることで、全てのメールに対してDMARCのポリシーを適用します。

レポートの結果、正しく処理されている（問題が少ない）ようであれば「p=quarantine」にして、迷惑メールに送るように指示します。このとき、pct=10のように適用する割合を少なくします。

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-report@example.com"

レポートの内容に問題がなければ、隔離を適用するメールの範囲をさらに広げます。（pct=50で50%のメールに適用）

_dmarc.example.com. TXT "v=DMARC1; p=quarantine; pct=50; rua=mailto:dmarc-report@example.com"

これで問題がなければ、最終的に、pct=100、p=rejectとして認証に失敗した全てのメールの受信を拒否します。

_dmarc.example.com. TXT "v=DMARC1; p=reject; pct=100; rua=mailto:dmarc-report@example.com"

DMARCで使えるタグ

DMARCでは「p」や「rua」「pct」以外にも使えるタグが用意されています。

• p= … ポリシー（none/quarantine/reject）。
• rua= … 集計レポート（RUA）の送信先（mailto: 形式）。日次のXMLを受け取れる。
• ruf= … フォレンジック（失敗）レポート送信先（※多くのプロバイダはプライバシーの観点で送らない場合が多い）。
• pct= … ポリシーをどの割合で適用するか（例：pct=5 は5% のメールに適用）
• adkim / aspf … DKIM/SPF のアラインメント（r relaxed / s strict）
• fo= … 失敗レポートの条件を細かく指定（fo=0,1,d,s 等）

DMARCで届くレポート

DMARCのruaで届く実際のメールは、メール本文はシンプルで、添付ファイルとしてXML形式のレポートが送られてくるのが一般的です。このXMLファイルは、通常ZIP形式やGZ形式で圧縮されています。

メールの件名

メールの件名は以下のようになっています。

送信元

メールの送信元はdmarc_reports@google.com のように、レポートを生成した組織のドメインから送られてきます。

メール本文

メールの本文自体は簡潔です。

レポートの集計期間やレポートのIDが記載されています。

添付ファイルの内容（レポート）

添付されているXMLのファイル（rua-report.xml.gz など）の中身は以下のようになっています。

※//およびコメントアウトはこちらで追記した補足です。

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  
  //レポート集計期間など
  <report_metadata>
    <org_name>Google Inc.</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>1234567890123456789</report_id>
    <date_range>
      <begin>1650639600</begin>　 <!-- 2022-04-22 00:00 UTC 頃 -->
      <end>1650725999</end>　<!-- 2022-04-22 23:59 UTC 頃 -->
    </date_range>
  </report_metadata>
  
  //DMARCの設定内容
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>　  <!-- DKIM の緩和モード (relaxed) -->
    <aspf>r</aspf>      <!-- SPF の緩和モード (relaxed) -->
    <p>quarantine</p>　 <!-- DMARC ポリシーは「隔離（迷惑メール行き）」 -->
    <pct>100</pct>　　　<!-- 全てのメールに適用 -->
  </policy_published>

　//1つ目の集計結果
  <record>
    <row>
      <source_ip>203.0.113.10</source_ip>
      <count>150</count>
      <policy_evaluated>
        <disposition>quarantine</disposition>
        <dkim>pass</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>pass</result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>

　//２つ目の集計結果
  <record>
    <row>
      <source_ip>192.0.2.20</source_ip>
      <count>5</count>
      <policy_evaluated>
        <disposition>reject</disposition>
        <dkim>fail</dkim>
        <spf>fail</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>amazon.com</domain>
        <result>fail</result>
      </dkim>
      <spf>
        <domain>amazon.com</domain>
        <result>fail</result>
      </spf>
    </auth_results>
  </record>
</feedback>

• <report_metadata>：レポートそのものに関する情報（どの組織から、いつの期間のレポートかなど）
• <policy_published>：レポート対象のドメイン（example.com）に設定されているDMARCポリシー。この例ではp=quarantine（隔離）が設定されています。
• <record>：メールのトラフィックに関する個別の記録。この例では2つの記録があります。
  • 1つ目の記録：
    • source_ip：203.0.113.10から送信されたメール。
    • count：150通。
    • policy_evaluated：SPFは失敗したが、DKIMが合格したので、DMARCのポリシーにpassと判定され、受信サーバーはメールを隔離しました。
  • 2つ目の記録：
    • source_ip：192.0.2.20から送信されたメール。
    • count：5通。
    • policy_evaluated：SPFもDKIMも失敗したので、DMARCポリシーにfailと判定され、受信サーバーはメールを拒否しました。これはなりすましの可能性が高いメールだと判断できます。

このように、ruaレポートはそのままでは読みにくいXML形式ですが、このデータを分析することで、自社ドメインのメールが正常に認証されているか、あるいは悪意のある第三者によってなりすまし行為が行われていないかを詳細に把握できるのです。

<disposition>quarantine</disposition>