DMARCレポートで異常がないかを確認しよう
DKIM・DMARCの設定をしたところ、DMARCレポートが届くようになった。「レポートが届くということは何か問題があったということ!?」「届いたのはいいけど、どうやって見ればいいの?」という人向けに、ぼくが調べた内容を共有します。
どんな内容が書かれているかを知りたい方、必見です。
なるべく分かりやすく伝えるためにまとめたので、見方に困った人の参考になりましたら幸いです。
更新履歴情報(最新:2024年12月3日)
情報提供を受けて修正した内容について(2024年6月12日)
身も蓋もない話をすると、可視化ツールに頼った方がいいと思います。
使える時間が限られているのに、ひとつひとつチェックするよりも、自動的に集計して問題があったら報告してくれるような、またはファイルをアップロードすると、パッと見て結果が分かる方が効率的です。
使いやすい可視化ツール(サービス)があるようです。
ぼくは使ったことがないため、ここでの紹介はできないのですが、参考ページ先で紹介されていますので、利用を検討してみると良いかと。
とはいえ、「ファイルのアップロードの権限がないから……(この場合の権限は上司やクライアントの許可が出ないということを示しています)」というような人もいると思います。「情報を外に出したくない!」というような会社やクライアントがいないとは限りません。
いかに時間を削減して有効に使えるか、コストパフォーマンスの効果を含めてツールの利用を提案しても駄目だった場合も考えられます。
そうなってしまうと、結局は自力でどうにか確認しないといけません。
そのため、次から「どう確認するのか」見方について学んだことを書いていきます。
DMARCレポートに何が書かれているの?
まず、「DMARCレポートとは何か?」というところからですが、
DMARCレポートは【受信者側のメール認証結果を送信者側にフィードバックしたレポート】のことです。
DMARCレポートは、XMLファイルを圧縮したファイルがメールに添付されて届きます。
中身はHTMLソースのような感じです。
どんな内容なのかは、実際に、ブラウザのタブにドラッグ・アンド・ドロップしてみると分かるのでやってみてください。
「じゃあ、これで読めるよね?」と言わんばかりのファイルを見て、心が折れそうですが、用語の意味さえ分かれば、どんなことが書いてあるかが多少分かりやすくなるので、一覧化してみました。
調べていくうちに新しい用語がいっぱい出てくるから、その都度調べることを繰り返していたので少し大変でした……。
DMARCレポートの見方(用語一覧)【2024年2月6日作成、2024年6月6日更新】
結果が「pass」となっていて、不審なドメイン(自社/自分のドメイン以外で知らないドメイン)がレポート内になければ、「問題ない」と判断して良いはずです。
もしあれば、送信ドメイン認証の検証結果が「fail」となっているかを確認しましょう。検証結果が「fail」となっている場合は、原因を調べて「DMARCのポリシーを拒否にする」「登録漏れがないか、社員が異なるメールサーバーから送信していないかを確認する」「転送メールを確認する」「メーリングリストの設定を確認する」といった対応を検討・実施しましょう。
参考までに、Googleから届くレポートの用語一覧
Googleとdocomoはほぼ同じ項目の構成でした。
これらが基本形として見て良いと判断して良いと考えています。
ただ、レポートによって項目は同じでも並び方が違ったりするんですよ。並びも合わせてくれませんか……(泣)
項目名 | 意味・説明 |
---|---|
【大項目】report_metadata | レポートに関する情報 |
org_name | レポーターの名称(レポート送信者は、どの受信サーバーで処理したのかのサーバーの名前) |
レポーターのemail(レポート送信者のメールアドレス) | |
extra_contact_info | 直訳すると「追加の連絡先情報」(Google翻訳) 調べても情報が出てこなかったことと実際にアクセスして内容を確認した結果から、おそらくはレポーター側の追加情報の入力欄(DMARCレポートの送信について「うちの会社はこうしてますよ。こういうところに気をつけてね」というポリシーページまたは注意喚起等のページへ誘導するためのもの)だと考えられる(余談・補足1) |
report_id | レポートID |
date_range | レポートの集計期間 begin「開始」end「終了」 なお、UNIX時間で表記されているので、日付形式にしたい場合は、次の計算式で出す必要がある。(計算式はエクセルとスプレッドシートに対応) 「=(レポートに書かれているUNIX時間/86400)+date(1970,1,1)」 |
【大項目】policy_published | 公開しているDMARCレコードの仕様 |
domain | 対象のドメイン |
adkim | DKIMのアライメントモード(アライメントとは、認証したドメインと一致するか照合すること) 「strict モード(aspf=s)」は、署名ドメイン(DKIMの署名をしたドメイン)とヘッダの差出人(送信元)のドメインが完全に一致している(サブドメインも含めたドメイン) 「relaxed モード(aspf=r)」は、署名ドメイン(DKIMの署名をしたドメイン)とヘッダの差出人(送信元)の組織ドメインが一致している(サブドメインの有無問わず、ドメイン名が一致していればOK) |
aspf | SPFのアライメントモード(アライメントとは、認証したドメインと一致するか照合すること) 「strict モード(aspf=s)」は、エンベロープ(配信時に問題のあるときの戻り先)のドメインとヘッダの差出人(送信元)のドメインが完全に一致している(サブドメインも含めたドメイン) relaxed モード(aspf=r)」は、エンベロープ(配信時に問題のあるときの戻り先)のドメインとヘッダの差出人(送信元)の組織ドメインが一致している(サブドメインの有無問わず、ドメイン名が一致していればOK) |
p | DMARCポリシー none, quarantine, reject(なし、隔離、拒否) |
pct | DMARCポリシーを適用するメールの割合 |
sp | サブドメインに対するポリシー none, quarantine, reject(なし、隔離、拒否) |
np | 不明 検索して「DMARC Tag Registry」というページを見つけたのでGoogle翻訳してみたところ「存在しないサブドメインに対して要求された処理ポリシー」というようなことが書かれていた。 そのため、ポリシーの宣言は「none, quarantine, reject(なし、隔離、拒否)」で良さそう。 調べても他に情報が出てこなかったことから、今のところはGoogleから届くDMARCレポートのみで使われていると考えられる。 |
【大項目】record | レポーターが受け取ったメールの送信元IPや認証結果 (rowは行を示している) |
source_ip | 送信元IPアドレス |
count | 集計期間にメールが送信された回数 |
policy_evaluated | 認証結果の概要 「disposition」は、メッセージに適用されたポリシー none, quarantine, reject(なし、隔離、拒否) 「dkim」は、DKIM認証 & DKIMアライメントの結果(pass=成功) 「spf」は、SPF認証 & SPFアライメントの結果(pass=成功) |
identifiers | 識別子(深く考えなくて問題なさそう) 「header_from」は、ヘッダfrom |
auth_results | 認証結果(dkim、spf) 「domain」は、認証を行ったドメイン 「result」は、認証の結果(pass=成功) (DKIMだけ、「selector(セレクタ)」の項目もある) |
(余談・補足1)
今のところは、Googleから届くDMARCレポートとKDDIのみ使われていると考えられるが、KDDIの場合はリンク先がエラーで見れなかった……。なお、KDDIはGmailで迷惑メールの判定がされてしまっていて、迷惑メールフォルダを確認し、さらには圧縮ファイルをダウンロードするときに「問題ない」としないといけないので、非常に面倒に感じている……。Gmailに届くものをスプレッドシートに自動で反映するようなスクリプトもあったけど、こういうときって反映されないんじゃないかと思うので、本当に使い勝手がぁぁぁぁっ!!(2024年6月6日時点で修正されているかは不明。「このメールは迷惑メールじゃありません」とするのは簡単だけど、ひねくれ者ゆえに、あえてしていない)
Google以外から届くレポートの用語一覧(その他の用語)
Googleから届くレポートの基本形の補足するような項目が多かったので、問題の原因調査に役立ちそうです。
とはいえ、基本形とは異なっているためか、どういう意味を持つのかの情報が見つかりにくかったので、補足情報として見ていただくと良いのかなと考えています。
項目名 | 意味・説明 |
---|---|
fo (【大項目】policy_published内) | 失敗レポートを送信する条件 「0」は、全ての認証がpassでなかったとき 「1」は、いずれかの認証がpassでなかったとき 「d」は、DKIMの署名認証が失敗したとき 「s」は、SPFの検証が失敗したとき (Googleでは使われていない項目の模様です) |
envelope_to (【大項目】recordのidentifiers内) | エンベロープ(配信時に問題のあるときの戻り先)の配信先 |
envelope_from (【大項目】recordのidentifiers内) | エンベロープ(配信時に問題のあるときの戻り先)の送信元 |
human_result (【大項目】recordのidentifiers内) | 不明 公開鍵の鍵長を示している模様 |
scope (auth_resultsのSPF内) | 不明 仕様のことを示している模様 |
問題を見つけたら、どう対応したら良いのか?(対処法もまとめたよ!)【2024年2月6日作成、2024年12月3日更新】
原因を調べて対応します。
当方が確認している問題パターンと対処方法は次の通りです。
問題パターン | 対処方法 |
---|---|
【問題ありの可能性が高いと考えられ、なりすましメールの可能性が高いと考えられる】 IPがいつもと違い、SPF認証結果の概要が「fail」で、SPFのDomainが心当たりがない場合で、DKIM認証結果の概要が「fail」およびDKIMの認証結果(Results)も「fail」であり、「IP・ドメインを調べると怪しいサイトが見つかる」場合。(SPF認証結果(Results)は判断基準としては問わない。「softfail」ならまだしも「pass」だったりするので) | 社内にメールの設定不備の人がいないかを念のため確認した後、問題がなければ、なりすましメールの可能性が高いと考えられる。 ただ、「サイトや利用ユーザーに『なりすましメールに注意してください!』という注意喚起をしましょう」と提案することはできるが、仕組み上、なりすましメールを送れないようにする等の対処ができない。 「迷惑メールには入れず、疑わしいものは受信もさせない」という設定はできるものの、これだと問題ないメールまで受信されないといったトラブルが生じてしまいかねない。 諸般の事情で「それだと困る!(何か対処しないと……!)」という場合は「なりすましメールの対策について」を参考に。 |
【問題ありの可能性は低いと考えられ、一時的な取得不可だと考えられる】 IPもドメインもいつもと同じで問題ではないと考えられるのに、DKIM認証結果の概要が「fail」で、DKIMの認証結果(Results)が「temperror」となっている場合 (類似ケースで、IPもドメインもいつもと同じで問題ではないと考えられるのに、DKIM認証結果の概要が「fail」で、DKIMの認証結果(Results)が「fail」となっている場合も含む) | 「temperror」を調べたところ「一時的な取得エラー」とのことだったので、この状況ではなりすましメールの可能性は低いと考えられる。このため、当方はこのパターンでは特に何もしていない。 同様に、DKIM認証結果の概要が「fail」で、DKIMの認証結果(Results)が「fail」となっている場合に稀に遭遇するようになったが、「temperror」を検知したところと同じところから届いたレポートに限っていることから、同様に「一時的な取得エラー」の可能性が高いと判断している。 |
【問題ありの可能性は低いと考えられ、転送メールの可能性が高いと考えられる】 IPとSPFドメインに心当たりがなくてSPF認証結果の概要が「fail」だけど、それ以外は問題がない(DKIM認証結果の概要が「pass」、DKIMドメインが「心当たりがある(所有)ドメイン」、SPFの認証結果(Results)とDKIMの認証結果(Results)が「pass」となっている)場合 | この現象は、次のような流れのときに発生すると考えられる。 1.メールを送信する 2.送信先(相手)はサーバーで設定しているメールアドレスだけど、送信先(相手)は届いたメールをGmailアドレス等に転送する設定をしていた このため、当方はこのパターンでは特に何もしていない。 |
【問題ありの可能性は低いと考えられ、転送メールの可能性が高いと考えられる】 IPもドメインも問題もいつもと同じで問題ではないと考えられるのに、SPF認証結果の概要が「fail」で、SPFの認証結果(Results)が「none」となっている場合かつSPFのDomainが「心当たりがある(所有)ドメインを紐づけしているサーバーのホスト名」になっている場合 または、 IPもドメインもいつもと異なり、SPF認証結果の概要が「fail」で、SPFの認証結果(Results)が「fail」となっているが、SPFドメインが心当たりがあるか信頼できると感じる(取引先の会社、Googleが含まれていて、Googleのサービスの可能性が高いと思われる、プロバイダー等のサービス)場合 | 主に、転送メールを設定している場合に発生すると考えられる。 当方では「(WordPressでGmailの利用が難しいという理由などで)管理者メールアドレスは同ドメインの管理専用のメールアドレスを用意してGmailに転送する設定をしている」場合や取引先がGoogle等のサービスを利用して転送しているなどで、この状況が発生していることを確認している。このため、当方はこのパターンでは特に何もしていない。 |
なりすましメールの対策について
結論から言うと、「サイトや利用ユーザーに『なりすましメールに注意してください!』という注意喚起をしましょう」と提案することはできるが、仕組み上、なりすましメールを送れないようにする等の対処ができない。
ただ、意味があるとは言えないし、Domainがレンタルサーバーじゃなく特定のドメインであり、ホスト名も固有のものだった場合に限るが、Googleにスパム報告を送っておき、自身のサイトにIPとホスト名を拒否してアクセスできないようにするという手(方法)はある。
「やることやっていない」と言われかねないときや「何も対処ができないなんて……!!」と自身のメンタルがしんどいときは、やっておいても良いかと。個人的には、「問題があるものはしかるべきところに報告・拒否する」というのは悪くはないのかなと思うので、このように対応することにしています。
外部のメールフォームサービスを使っている人は、外部のメールフォームサービス側から「IPアドレスの拒否(投稿拒否)」を設定しておくと良いかと!
これは、「ついうっかり」で失念していたのですが、外部のメールフォームサービスを使っている場合、いくら、サイト内に埋め込みで表示させていたとしても、「外部のメールフォームサービス」のメールフォーム単体でアクセスされたら意味がないなと。
気づいたなら、早速対応した方が良いと対応したのですが、外部のメールフォームサービスは大体IPアドレス拒否ができるようになっているはずなので、該当する人は、こちらも対応しておくと良いでしょう。
「結局(結論)、どういう状態がなりすましメールの可能性が高いって言えるの?」
正直、自分も書いてみて混乱しかねないなと感じたため、簡潔に「こういうときは、なりすましメールの可能性が高い」「こういうときは、なりすましメールの可能性が低い」とまとめて書いてみました。
下記の条件すべてに当てはまるときが「なりすましメールの可能性が高い」と判断することができます。
そのため、「普段とは違うIPアドレスだった」場合は、調べる癖をつけておくと良いでしょう。
- DKIMとSPFの認証結果(Results)の両方またはDKIMの認証結果(Results)が「pass」以外(temperrorは除く)
- IPアドレス(ホスト名)で調べると、明らかに「善良ではないサイト(ホスト)」が見つかる
「確信がつかないものは罰せず」とした方がトラブルにつながりにくいのかなと思いますので、
IPアドレス(ホスト名)で調べても怪しい情報が見つからない場合は様子見の方が良さそうです。
特に怪しいサイトが見つからず、レンタルサーバーやビジネス系のメールサービス(マーケティングツールも兼ねているものやビジネス用途で契約しているサービスに多い)のホストだった場合は問題がない可能性が高いと考えています。
(相手のメールアドレスがそれらを利用していて普段使っているメールアドレスに転送していた可能性が高いと考えられる)
どちらにしても、この状況だと問題があるものに対して特定することは難しいので、下手に対処しない方が良さそうではあります。
逆に言うなら、下記の場合は問題がない可能性が高く、「なりすましメールの可能性が低い」と考えられます。
(相手のメールアドレスがそれらを利用していて普段使っているメールアドレスに転送していた可能性が高いと考えられる)
- DKIM認証結果の概要が「pass」
- DKIM認証結果(Results)が「pass」
- DKIMドメインが「心当たりがある(所有)ドメイン」
参考
考えられる原因について、すごく分かりやすくまとめられたサイトを共有します。最初の頃は分からないパターンが出てくる度に確認して対応していました。(載っていても困ることが増えてきたので、最近は見ていませんが……)
上記のリストにないものは、そこまで問題視する必要はないと考えられますが、上記のパターンにない場合は「どの可能性が考えられるだろう」と推察しやすくなるので、参考にすると良いかと。
【余談1】なりすましのことについて、すごく分かりやすいサイトを見つけました!
すごく分かりやすいサイトを見つけたので共有します。
はじめから、これを見れば良かった(早かった)かもしれない……(笑)
読んだときは、「DMARCレポートの見方」が載っているというわけではなく、「なりすまし」のことについて詳しくなれるという印象でした。
【余談2】DMARCレポートの拒否反応が出てしまい、やむなく、DMARCレポートを可視化できる半自動化ツール(HTML 形式のレポートに変換するスクリプト)を導入することに……!【2024年6月6日追記】
基本的には「基本営業時間内」に確認しているのですが、無理がないように「一日に一度を目途に、状況により確認ができない場合は翌営業日に確認することがある」というような形で、確認していました。
そして、問題があったときに報告するため、クライアントが見ても分かるように項目の意味も記載した「確認用レポート(中身をコピー・アンド・ペーストして、確認日と確認結果を追加した確認用のシート。スプレッドシートで作成。スクリプトで自動で反映させるのは余力がなくてできておらず、手動で反映していた)」にまとめていました。
事は、GW明けに起こりました。
「DMARCレポートを見るのはいいけど、確認レポートにまとめたくないよぅ……!!(涙)」
完全に拒否反応を起こしちゃって、それでも少しは反映したんですが、完全に心が折れちゃいました。
土日祝日で数日経過した上に問題があったときに調査するので1時間くらいかかることもありますが、こまめに対応したら15分~30分で終わるような内容です。
ただ、項目の並び順が違うし、レポート送信元によっては別の項目もついてくるので、その都度考慮して対応して、手作業故に完璧は難しくてもできる限り間違いがないように確認してきたことすべてに疲れてきていたのは否定できません。
GWは自身の体調面を考慮して、長い期間お休みをいただいたために、溜まりに溜まりまくったレポートの数……!!
具体的な数は伏せますが、心が折れても無理のない数ではありました。4つとか5つとかじゃないということだけは言えます。
これは無理。サービス続行不可……!!(汗)
と思ったので、ローカル環境かつ無料で確認できないかを調べて対応すること数時間。
正直、その時間で他のことをしたかったくらいには暇じゃなかったのですが、今後のためには必要な犠牲だと割り切りました。
半自動化に成功しました!!
本当は、生成したHTMLレポートをGoogleドライブにアップロードして、報告と同時に「詳しくはこれを見て!」と言えれば良かったのですが、ファイルが常に溜まっていくことになりますし、将来的にオーナー権限を渡すときに大変なことになるので、多少の手作業(コピー・アンド・ペーストをしてGoogleスプレッドシートに貼り付けて、レイアウトを整えて確認結果を追記すること)は許容することにしました。
詳しくは、次の参考サイトをご覧ください。
この方がスクリプトを作ってくれていなかったら、ぼくは困り果てていたと思います……!
スクリプト導入で困ったときに確認してみてね!
(Windows環境の方限定で書いていますが、Mac環境の方も参考になるかも?)
導入したいのでやってみたものの、スクリプト導入以前に「Node.js」と「npm」の導入がうまくいかず、「winget」が使えなくて困っているWindows環境の方は、次の参考サイトを確認して対応してみてください。これらがうまくいけば、あとはどうにでもなります。
(補足1)「Assets」のプルダウンを開くとファイル一覧があるので、そこからmsixbundleファイルがダウンロードできるよ!
(補足2)「アプリを正しく機能させるには、Windows アプリ パッケージを起動してみてください」という画面が表示されたらインストール完了。画面を閉じてOK。
【補足】上記対応後に「新機能と改善のために最新のPowerShellをインストールしてください! (URLが入ります)」というメッセージが表示されてしまう方は、次の方法をお試しください。
「新機能と改善のために最新のPowerShellをインストールしてください! (URLが入ります)」というメッセージが表示されてしまう方は、結論から言うと「バージョン5を使っている」ために表示されてしまうと考えられます。
そのため、まずは、アプリ検索で「PowerShell 7」を探してみてください。(「PowerShell」と入力することで、「バージョン7」があるかどうかを見つけることができるはず……!)
PowerShell 7 は、Windows PowerShell 5.1 と共存するように設計されています。
https://learn.microsoft.com/ja-jp/powershell/scripting/whats-new/migrating-from-windows-powershell-51-to-powershell-7?view=powershell-7.4
最新バージョンが立ち上がればいいのにね。
上記の説明の通り、バージョン「5」と「7」は共存していて、アプリケーション名に「7」がついていないものを起動すると「バージョン5」が起動されます。
だから、バージョンアップしようと思って対応しても、対応しても、「7」がついていないものを起動すると、いつまで経っても「新機能と改善のために最新のPowerShellをインストールしてください!」のメッセージが消えない……!
気づかなかったぼくが悪いんだけど、正直に言うと分かりにくいと思うんだ……!!(泣)
というわけで、もし、アプリケーション名に「7」がついているものが見つからなかったら、次のページから「MSI パッケージのインストール」を選び、64ビットの人は「x64」を選んでインストールしよう。
不安だったら、一度アンインストール(Remove)してインストールし直してもOK。
インストールするときは、基本的にはデフォルトの状態(チェックはそのまま)にして次へ進んでいけばインストールが完了する。
インストールするときの参考ページも共有します。
正直ね、PowerShellの問題を解決するためにあれこれ対応した時間の方がDMARCレポートに関するスクリプト導入する時間より長かったです。今回も、気づかなかったとはいえ、解決するのに数時間かかっちゃったからね……っ!(泣)
せっかくなので、共存に気づくまでめっちゃ見ていた「PowerShellをアップデートするときの参考になるなと思った参考ページ」を共有します。PowerShell 7を使っても「最新にして」というメッセージが出てきたら見てみてね!
PS C:\Users\(ユーザー名が入ります)> winget upgrade PowerShell
【余談】今は下記を使っています(2024年12月3日時点)
PS C:\Users\(ユーザー名が入ります)> winget install --id Microsoft.Powershell --source winget
「スクリプトの導入には成功したけど、結局、どうやって使うの?」とスクリプト制作者のページを読んでも分からなかった人は、次の手順でご対応ください。
(初心者向けの情報です)
初心者向けの説明です。「Node.js」と「npm」を使える人はそのまま問題なく使えるはずなので、見ないで良いよ!
管理者じゃなくても大丈夫だったけど、「管理者で起動する」ってしておけばOK。
例のフォルダ名は忘れにくいように自分で適当につけたもの。英数字で分かりやすい名前をつけよう。
フォルダ名をそのまま使っても問題ないですよ。よければどうぞ。
PS C:\Users\(ユーザー名が入ります)>
となっているから、
PS C:\Users\(ユーザー名が入ります)> cd (インストールしたスクリプトのフォルダのパスが入ります)
と入力してエンターキーを押下してね!
圧縮フォルダをそのまま入れるんじゃないぞ!
PS (インストールしたスクリプトのフォルダのパスが入ります)>
となっているから、
PS (インストールしたスクリプトのフォルダのパスが入ります)> npm run dev
と入力してエンターキーを押下してね!
【余談3】最近の事例について【2024年12月3日追記】
最近確認している事例としては新しく2パターンあります。
「ホスト名が不明で海外からのIP(IPv4、XXX.X.X.XXXのようなパターンのこと)」のものと「IPv6のもので、ホスト名が不明で海外からのIP」の2パターンです。前者については、念のため、サーバー側でIPアドレスを拒否しているものの、IPv6については、同一のものがなく除外したときに問題なく動作するのかの確証が持てないので「除外したことに伴う影響」を懸念して対応を保留としています……。
正直な話、IPアドレスおよびホストで除外したとしても、今までで同一のIPアドレスも検出されているため、劇的な効果が出るとは考えにくいなと思っているのも理由の一つです。
Webサーバー上(お問い合わせフォーム)のものを悪用されないようにしておくのはやっておくこと自体は悪いことではないと判断して対応しているだけに過ぎないので……。
更に、外部のメールフォームサービスを利用している場合はIPv6の登録ができない可能性もあるな、と。今後の動向を見ながら、対応を検討していきたいと思います。
参考にしたページ一覧【2024年2月6日作成、2024年6月6日更新】
スクリプト導入時にトラブルが起きたときの参考ページは追加していません。(記事内部をご確認ください)
(注)「DMARCレポートって何?」ってそういえば書いてなかったなと思って、勘違いしていたら困るし……と改めて調べたときに見たページです。
(注)「dmarcレポート googleスプレッドシート」で調べたときに見たページ。スプレッドシートで管理できないかなと思って……。
結局、自分で確認用のファイルをGoogleスプレッドシートで作りました。需要があるなら共有するよ!
(注)その後、手動で対応するのが苦痛に感じてしまって導入したHTML形式のレポートに変換するスクリプトです。
そのため、以前作ったGoogleスプレッドシートは使わなくなっちゃいました。慣れるまで使うなら使えるんだけどね……。
今は、HTML形式のレポートをコピー・アンド・ペーストしてGoogleスプレッドシートに貼り付けて、「どこからのレポートなのか」と確認結果を追記する形で整えて更新しています。
(注)実は、UNIX時間だと気づく(知る)のに時間がちょっとかかってしまいました……。
ご相談・お問い合わせをお待ちしています!
ホームページ制作・リニューアル・運用・SEO・Web集客、Webマーケティング・Webサイト制作技術・タスク・スケジュール・プロジェクト管理や業務改善のお悩みなどを遠慮なくご相談ください。
資料のダウンロードをご希望の方へご案内です
サービスのご利用を社内で検討したい方のために、実績やサービス概要、料金表などのクリエイトアコードの案内資料をPDFでダウンロードすることができます。ご自由にダウンロードください。