集中力を維持。スマートなメールアプリ。
高速かつクロスプラットフォームなメールアプリは、重要なことに集中できるように設計されています。
💡 DMARCレコード:あなたのドメインからのものと主張するメールが認証チェックに失敗した場合に、受信メールサーバーがどう対応すべきかを指示するDNSエントリーです。 これは DKIMとSPFの上に構築されており、実際にメールセキュリティポリシーを執行するものです。 疑わしいメールを配信するか、隔離するか、あるいは完全に拒否するかを決めるルールだと考えてください。
個人用のGmailやOutlookのアドレスからメールを送信する場合、DMARCに触れる必要はありません。 GoogleとMicrosoftが代わりに対応してくれます。
しかし、カスタムドメイン(you@yourcompany.com)から送信する場合、これはあなたの責任です。 GoogleとYahooは2023年に、大量送信者はDMARCを設定しなければならないと発表しました。そして2025年後半にGmailは厳格な執行を開始し、非準拠のメッセージは一時的または恒久的な拒否に直面するようになりました。 Microsoftも2025年に大量送信者向けの同様のルールを導入しました。
明確な理由もなくメールが迷惑メールに振り分けられ始めたとき、初めてDMARCに遭遇するかもしれません。 あるいは、ドメインレジストラが認証レコードの欠落を指摘するかもしれません。 あるいは、クライアントのITチームから、なぜあなたのメッセージが彼らのセキュリティチェックに失敗しているのか尋ねられるかもしれません。 それが、これが抽象的なものではなくなる瞬間です。
カスタムドメインからニュースレターやクライアント向けメールを送信していますか? 設定してください。 もはや任意ではありません。
DMARCポリシーがないと、受信サーバーは認証チェックに失敗したメールを受け取ったときに、独自の判断を下さなければなりません。 配信することもあります。 配信しないこともあります。 可視性も制御もありません。
DMARCはそれを変えます。 あなたのレコードは、失敗したメールをどう扱うかを受信サーバーに正確に指示します。通常通り配信する(p=none)、迷惑メールに送る(p=quarantine)、または完全に拒否する(p=reject)。 レポートも取得できます。 受信サーバーは、どのメッセージが認証に成功し、どれが失敗したか、そしてどのIPアドレスがあなたのドメインを代表してメールを送信したかを示す日次データを送信します。
この最後の部分が、DMARCが中小企業にとってその価値を発揮するところです。 これがないと、あなたの会社のアドレスからのものとまったく同じに見えるフィッシングメールを誰かが送信できてしまいます。 あなたの顧客が詐欺に遭い、あなたのブランドを責め、そしてあなたはそれが起きていることに気づきません。 レポートがそれを教えてくれます。 執行ポリシーがそれを止めます。
これは単なるセキュリティ対策ではありません。 メールの到達率対策でもあります。
DMARCレコードは、_dmarc.yourdomain.comに公開されるTXTレコードとしてDNS内に存在します。 基本的なものは次のようになります:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
理解しておくべき重要な部分:
p=はあなたのポリシーです。 none(監視のみ、アクションなし)から始めます。 正当なメールが認証に成功していることを確認したら、quarantine、次にrejectに移行してください。
rua=は集計レポートの送信先です。 これは、受信サーバーから日次のXMLサマリーを受け取るメールアドレスです。 量がすぐに増える可能性があるため、これ専用の受信トレイを用意することをお勧めします。
v=DMARC1は単なるバージョンタグです。 常にDMARC1です。
正直なところ、基本的な設定に必要なものはほとんどこれで揃っています。 その他のタグ(adkim=、aspf=、sp=)はアライメントの厳格さとサブドメインポリシーを制御しますが、初日からそれらを気にする必要はありません。
DMARCはDNSの操作です。 ドメインにテキストレコードを追加します。 ただし、何かに手を付ける前に、SPFとDKIMがすでに設定され、成功していることを確認してください。 Googleは、SPFとDKIMを設定してからDMARCレコードを追加するまで48時間待つことを推奨しています。 このステップを省略すると、自分自身のメールに配信の問題を引き起こす可能性が高くなります。
一般的な設定(どのドメインレジストラでも機能します):
Google Workspaceの場合:Googleの 公式DMARC設定ガイドが、Workspaceドメイン向けに具体的な手順を説明しています。
Microsoft 365の場合:Microsoftの DMARC設定ドキュメントが、365環境の設定を説明しています。
Gmail、Outlook、Sparkの内部で何かを設定する必要はありません。 DMARCは完全にDNSレベルに存在し、メールクライアント内には存在しません。
まずSPFとDKIMを設定してください。 それらがないとDMARCは機能しません。 これを省略すると、何かを修正する前に、自分自身のメールに配信の問題を引き起こす可能性が高くなります。 省略しないでください。
p=noneから始めて待ってください。 急いでp=rejectにしないでください。 1〜2週間かけて、ただレポートを収集します。 あなたを代わりに送信していたことを忘れていたツールがおそらく見つかるでしょう。 それは普通のことです。 よくあるものには、Mailchimp、CRM、請求書ソフトウェアなど、あなたのドメインアドレスを使ってメールを送信するあらゆるものが含まれます。
あなたのためにメールを送信するすべてのツールを確認してください。 ポリシーを厳しくする前に、それぞれが適切に認証される必要があります。 一つ見逃すことが、これがうまくいかなくなる最も一般的な原因です。 p=reject に切り替えたところ、ESPを通じてDKIMを設定するのを忘れていたために、突然Mailchimpのニュースレターが配信されなくなります。
レポートにはダッシュボードツールを使ってください。 生のレポートはXMLファイルです。 ほとんどの人には読めません。 EasyDMARCやMXToolboxの無料プランは、それらを人間が読めるものに変換してくれます。 どれか一つ使ってください。
最終的にはp=rejectに移行してください。 p=noneは出発点であり、目的地ではありません。 そこに到達するまで、あなたのドメインはまだなりすまし可能です。 目標は完全な執行です。 安全にそこに到達するには数週間かかるだけです。