<?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>DMARCは受信者の協力も必要 &#8211; 業務改善コンサルティング情報ブログ</title>
	<atom:link href="https://www.trilogyforce.com/blog/dmarc-also-needs-recipient-cooperation/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>
	</channel>
</rss>
