<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>SPF認証 &#8211; 業務改善コンサルティング情報ブログ</title>
	<atom:link href="https://www.trilogyforce.com/blog/tag/spf%e8%aa%8d%e8%a8%bc/feed/" rel="self" type="application/rss+xml" />
	<link>https://www.trilogyforce.com/blog</link>
	<description>業務改善で収益改善！</description>
	<lastBuildDate>Mon, 17 Jun 2024 01:21:12 +0900</lastBuildDate>
	<language>ja</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>https://wordpress.org/?v=6.9.1</generator>
	<item>
		<title>DMARCは受信者の協力も必要</title>
		<link>https://www.trilogyforce.com/blog/dmarc-also-needs-recipient-cooperation/</link>
		<comments>https://www.trilogyforce.com/blog/dmarc-also-needs-recipient-cooperation/#respond</comments>
		<pubDate>Mon, 28 May 2018 11:30:27 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[ITに関する情報]]></category>
		<category><![CDATA[情報セキュリティ]]></category>
		<category><![CDATA[DKIM]]></category>
		<category><![CDATA[DMARC]]></category>
		<category><![CDATA[IPアドレス]]></category>
		<category><![CDATA[SPF]]></category>
		<category><![CDATA[SPF認証]]></category>
		<category><![CDATA[none]]></category>
		<category><![CDATA[quarantine]]></category>
		<category><![CDATA[reject]]></category>
		<category><![CDATA[サーバ]]></category>
		<category><![CDATA[ドメイン]]></category>
		<category><![CDATA[フィルター]]></category>
		<category><![CDATA[ポリシー]]></category>
		<category><![CDATA[メール]]></category>
		<category><![CDATA[メールサーバ]]></category>
		<category><![CDATA[偽装]]></category>
		<category><![CDATA[受信]]></category>
		<category><![CDATA[拒否]]></category>
		<category><![CDATA[自動転送]]></category>
		<category><![CDATA[転送元]]></category>
		<category><![CDATA[送信元]]></category>
		<category><![CDATA[隔離]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=6061</guid>
		<description><![CDATA[少し前に投稿した『ドメイン偽装は防ぎようがない』や『ロシアからのDMARCレポート』の記事のように、ドメイン偽装を防ごうとすると問題が発生する場合があります。 皆さん、こんにちは。 業務改善を行うIT・業務コンサルタント&#8230;]]></description>
				<content:encoded><![CDATA[<p>少し前に投稿した『<a class="sb-line" href="/blog/domain-camouflage-can-not-be-prevented/">ドメイン偽装は防ぎようがない</a>』や『<a class="sb-line" href="/blog/dmarc-report-from-russia/">ロシアからのDMARCレポート</a>』の記事のように、ドメイン偽装を防ごうとすると問題が発生する場合があります。</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2018/05/mail.jpg" alt="メール認証" width="450" height="450" class="size-full wp-image-6066"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2018/05/mail.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2018/05/mail-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2018/05/mail-300x300.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2018/05/mail.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="450"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行うIT・業務コンサルタント、高橋です。</p>
<p class="pdt20">今日の記事ですが、中小・零細企業、小規模事業者において『DKIM』まで導入することは難しい（レンタルサーバが対応していない場合が多い）などの理由から、それが行えない前提として読んでください。</p>
<p class="pdt20">『DKIM』導入可能な場合においては下記の限りではありません。</p>
<p class="pdt20">さて、自社や自店のドメインが偽装されたメールなどに使われていたことを知っても、ある意味では八方塞がりになってしまう可能性があります。</p>
<p class="pdt20">それはどういった状態だと思いますか？</p>
<h2 class="contTitle">DMARCのポリシーは受信者の協力も必要</h2>
<p>事業者が使っているドメインであれば、DNSのTXTレコードにSPF認証に関する記述が加えられていることは昨今においては普通のことと言えます。</p>
<p class="pdt20">逆に、記述がないのであれば追加しておくべきです。</p>
<p class="pdt20">例：example.com. IN TXT &#8220;v=spf1 ip4:***.***.***.*** include:example.com -all&#8221;</p>
<p>（***.***.***.***の部分はv4のIPアドレスが入ります。）</p>
<p class="pdt20">さて、このSPFに関する記述が入っている場合でDMARCの記述も追加されている場合、Appleなどはポシリーを『none（指定なし）』にしていますが、MicrosoftやGoogleは『reject（拒否）』にしています。</p>
<p class="pdt20">これ、受信者が転送処理などを行わずにストレートにメールを受信している場合においては『none（指定なし）』から『quarantine（隔離）』、『quarantine（隔離）』から『reject（拒否）』と、フィルター処理の割合を組み合わせながら段階的にポリシー変更を行っていけば良いですが、受信者が転送処理などを行っている場合、相手のサーバ設定によっては『none（指定なし）』から他に変更することで問題が生じます。</p>
<p class="pdt20">例えば、受信者が自動転送設定をしていた場合で、その際のIPアドレスの出力を転送元IPアドレスとしていた場合、送信元ドメインとそのIPアドレスが一致せず、SPF認証は『Pass』とならないため受信者がメールを受け取れない可能性が出てきます。</p>
<p>（DMARCのフィルター処理（PCT）の設定値にもよります。）</p>
<p class="pdt20">このような場合においては正直八方塞がりのような状態になります。</p>
<p class="pdt20">従って、受信者側に自動転送をやめてもらうか、受信者側に転送先メールアドレスを開示いただくか、何らかの協力をお願いすることになります。</p>
<p>（メールサーバの仕様を簡単に変更するわけにもいきませんので。）</p>
<p class="pdt40">まずは偽装されたメールが出回っていることをアナウンスすることからスタートですが、『全く関係のない消費者などが被害にあわない』、『自社や自店のドメインを傷つけない』ためには、最終的にはDMARCのポリシーを『reject（拒否）』にできる環境整備を行っていく必要性があるでしょう。</p>
<p class="pdt20">また、冒頭でも書きました通り、これを送信者側のみで解決しようとした場合は『DKIM』の導入が必要となります。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/dmarc-also-needs-recipient-cooperation/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>ドメイン偽装は防ぎようがない</title>
		<link>https://www.trilogyforce.com/blog/domain-camouflage-can-not-be-prevented/</link>
		<comments>https://www.trilogyforce.com/blog/domain-camouflage-can-not-be-prevented/#respond</comments>
		<pubDate>Tue, 08 May 2018 11:54:36 +0900</pubDate>
		<dc:creator><![CDATA[Shingo Takahashi]]></dc:creator>
				<category><![CDATA[ITに関する情報]]></category>
		<category><![CDATA[情報セキュリティ]]></category>
		<category><![CDATA[DMARC]]></category>
		<category><![CDATA[DNS]]></category>
		<category><![CDATA[IT]]></category>
		<category><![CDATA[SPF認証]]></category>
		<category><![CDATA[apple.com]]></category>
		<category><![CDATA[rakuten.co.jp]]></category>
		<category><![CDATA[ウェブ]]></category>
		<category><![CDATA[セキュリティ]]></category>
		<category><![CDATA[ドメイン]]></category>
		<category><![CDATA[フィッシング詐欺]]></category>
		<category><![CDATA[ヘッダ情報]]></category>
		<category><![CDATA[マニュアル]]></category>
		<category><![CDATA[メール]]></category>
		<category><![CDATA[メールサーバー]]></category>
		<category><![CDATA[ルール]]></category>
		<category><![CDATA[中小企業]]></category>
		<category><![CDATA[件名]]></category>
		<category><![CDATA[偽装]]></category>
		<category><![CDATA[名前解決]]></category>
		<category><![CDATA[周知徹底]]></category>
		<category><![CDATA[差出人]]></category>
		<category><![CDATA[本文]]></category>
		<category><![CDATA[消費者]]></category>
		<category><![CDATA[認証]]></category>

		<guid isPermaLink="false">https://www.trilogyforce.com/blog/?p=5962</guid>
		<description><![CDATA[日々、あらゆるところで行われているドメイン偽装。 これにより、あらゆるところに偽のメールが送りつけられるなどし、フィッシング詐欺などが多発しています。 皆さん、こんにちは。 業務改善を行うIT・業務コンサルタント、高橋で&#8230;]]></description>
				<content:encoded><![CDATA[<p>日々、あらゆるところで行われているドメイン偽装。</p>
<p class="pdt20">これにより、あらゆるところに偽のメールが送りつけられるなどし、フィッシング詐欺などが多発しています。</p>
<div class="mgt10 mgb10" itemprop="image" itemscope itemtype="https://schema.org/ImageObject"><img decoding="async" src="//www.trilogyforce.com/blog/wp-content/uploads/2018/05/camouflage.jpg" alt="ドメイン偽装" width="450" height="450" class="size-full wp-image-5964"  loading="lazy" srcset="https://static.trilogyforce.com/blog/wp-content/uploads/2018/05/camouflage.jpg 450w, https://static.trilogyforce.com/blog/wp-content/uploads/2018/05/camouflage-150x150.jpg 150w, https://static.trilogyforce.com/blog/wp-content/uploads/2018/05/camouflage-300x300.jpg 300w" sizes="auto, (max-width: 450px) 100vw, 450px" /><meta itemprop="url" content="https://www.trilogyforce.com/blog/wp-content/uploads/2018/05/camouflage.jpg"><meta itemprop="width" content="450"><meta itemprop="height" content="450"></div>
<p>皆さん、こんにちは。</p>
<p>業務改善を行うIT・業務コンサルタント、高橋です。</p>
<p class="pdt20">さて、皆さんもご存知の通り、送られてきたメールの差出人が『rakuten.co.jp』であったり、『apple.com』であったりし、件名や本文も本物にそっくりの状態で作られているために本物と勘違いしてしまう偽装メール。</p>
<p class="pdt20">こういったものを防ぐ手立てはないものでしょうか？</p>
<h2 class="contTitle">ドメイン偽装は防ぎようがないのか？</h2>
<p>まず、ドメインを偽装するというのは簡単にできてしまいます。</p>
<p class="pdt20">そして、これを完全に防ぐことはできません。</p>
<p class="pdt20">そのため、大手企業はもちろんのこと、中小企業などにおいてもドメインの名前解決に用いられるDNSというものに対してそれなりのものが書かれていたりします。</p>
<p class="pdt20">それによって本物であることを認証させたりしているわけですが、正直なところ、メールを受け取る側においても意識をしない限り、実際のところは役に立たないことも多いです。</p>
<p class="pdt20">例えば、常日頃からIT系の業務に携わっている人であったりセキュリティ意識の高い人であれば、疑わしいメールが送られてきた瞬間にメールのヘッダ情報を確認したりします。</p>
<p class="pdt20">しかし、そうでない人はそこまでのことは行いませんし、ヘッダー情報を見てもわからないという人が大半です。</p>
<p class="pdt20">ではどうすれば良いのか？</p>
<p class="pdt20">１．業務上、メールのやりとりを行う相手先とは一定のルールを設ける</p>
<p>例えば、双方においてSPF認証は必須とし、メールサーバーにおいては認証していないものを隔離するか削除する措置を取るというのも1つの手でしょう。</p>
<p class="pdt20">２．社内においてマニュアルを作成し、全体に周知徹底を図る</p>
<p class="pdt20">３．一般の消費者に対して偽装メールが届いてしまった場合、ウェブ上で確認方法や注意喚起などのアナウンスを行う</p>
<p class="pdt20">ただし、３に関しては受信者からの問い合わせ連絡などがない限り大半の企業では把握していないことも多いかと思います。</p>
<p class="pdt20">それを早期に把握するため、DNSにDMARCというものを記述し、レポートが受け取れる状態にしておくことがお勧めです。</p>
]]></content:encoded>
			<wfw:commentRss>https://www.trilogyforce.com/blog/domain-camouflage-can-not-be-prevented/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
