手順#
レポートの受け取り先を決める
dmarc@ninefold.example のようなアドレスを作るか、レポート分析サービスを使います。レポートは圧縮された XML ファイルで届きます S2。
監視用のレコードを公開する
ホスト名
_dmarc、値v=DMARC1; p=none; rua=mailto:dmarc@ninefold.exampleの TXT レコードを追加します。ポリシーが none の間は、メールの扱いは変わりません S1。レコードを確認する
dig +short TXT _dmarc.ninefold.exampleを実行するか DNS ルックアップツールを使い、返ってくるレコードがちょうど 1 つで、v=DMARC1 から始まっていることを確かめます。quarantine に移行する
ポリシーを
p=quarantineに変え、不合格のメールが迷惑メールフォルダに入るようにします。レポートの確認は続けます。reject に移行する
同じくらいの期間レポートに問題がなければ、ポリシーを
p=rejectに変え、不合格のメールを受信側が拒否するようにします S1。
始める前に必要なこと#
DMARC は、それ自体では何も認証しません。SPF と DKIM の結果を読み取り、表示される From アドレスと一致するドメインで、そのどちらかが合格しているかを確認します S1。メール配信ツールが自社のドメインで署名していると、DKIM は合格していても DMARC は不合格になります。先にここを直さないと、レポートが自分のメールの不合格で埋まってしまいます。
Ninefold のような小さなアパレルブランドなら、送信元はスタッフのメールボックス、ストアの注文・発送メール、問い合わせ管理ツール、メール配信ツールあたりが一般的です。そのそれぞれで、ninefold.example の SPF か DKIM を設定する必要があります。各レコードの仕組みは SPF・DKIM・DMARC の解説をご覧ください。
Gmail は、個人の Gmail アカウントへ 1 日 5,000 通を超えて送る送信者に DMARC レコードを求めており、ポリシーは none でも認められます S4。Yahoo も大量送信者に少なくとも p=none を求めています S5。公開は数分で終わるため、送信量にかかわらず設定しておく価値があります。
DMARC レコードの書き方#
DMARC レコードは、ドメインの _dmarc に公開する TXT レコードです。セミコロンで区切ったタグを並べて書きます。v=DMARC1 のタグは必ず先頭に置く必要があり、そうでないと受信側はレコード全体を無視します S1。ショップに必要なタグは次のとおりです。
| タグ | 例 | 役割 |
|---|---|---|
| v | v=DMARC1 | バージョン。必ず先頭のタグにします |
| p | p=none | ドメインのポリシー：none、quarantine、reject のいずれか |
| rua | rua=mailto:dmarc@ninefold.example | 毎日の集計レポートの送り先 |
| sp | sp=reject | 既存のサブドメインのポリシー（p と異なる場合） |
| np | np=reject | 存在しないサブドメインのポリシー |
| adkim / aspf | adkim=r | DKIM と SPF のアラインメント：緩やか（初期設定）または厳格 |
| t | t=y | テスト：記載したポリシーより 1 段階弱い扱いを受信側に求めます |
特に理由がなければ adkim と aspf は省略してください。初期設定の緩やかなアラインメントなら、mail.ninefold.example のようなサブドメインで署名したメールも、ninefold.example の From アドレスと一致するとみなされます S1。Yahoo も緩やかなアラインメントを認めています S5。
段階ごとの DMARC レコード例#
以下の例では ninefold.example を使っています。ドメインとレポートの送り先を自分のものに置き換え、どれもホスト名 _dmarc に公開してください。
監視
v=DMARC1; p=none; rua=mailto:dmarc@ninefold.example
隔離（quarantine）
v=DMARC1; p=quarantine; rua=mailto:dmarc@ninefold.example
拒否（reject）
v=DMARC1; p=reject; np=reject; rua=mailto:dmarc@ninefold.example
Google の導入手順のページを含め、以前の解説ではメールの一定割合にだけポリシーを適用する pct= が使われています S3。RFC 9989 では、受信側が 0 か 100 でしか確実に適用していなかったことからこのタグが削除され、代わりにテスト期間用の t=y が追加されました S1。受信側は知らないタグを無視することになっているため、np や t にまだ対応していない受信側は、それらを読み飛ばすだけです S1。
rua レポートからわかること#
集計レポートを送るメールボックス事業者は、通常ドメインごとに 1 日 1 通、圧縮された XML ファイルで送ってきます S2。各レポートには、あなたのドメインでメールを送った IP アドレス、それぞれの送信数、SPF と DKIM の結果、アラインメントの有無、受信側がそのメールをどう扱ったかが記載されています S2。
- 見覚えのある送信元がアラインメントで不合格なら、設定を忘れていた送信元です。そのサービスで自分のドメインの DKIM を有効にするか、SPF に追加してください。
- 見覚えのない送信元は、チームの誰かが登録したサービスか、あなたのドメインのなりすましです。強制に移る前に、社内で確認してください。
- 転送されたメールは、SPF で不合格、DKIM で合格になることがよくあります S1。これは想定どおりの結果で、アラインメントの取れた DKIM が最も重要な理由のひとつです。
XML をそのまま読むのは大変なため、rua をレポート分析サービスに送り、グラフにして確認するショップも多くあります。そのサービスが別のドメインを使う場合は、そのドメインに承認用のレコードが必要で、ないと受信側はその送り先を無視します S2。この設定はレポートサービス側で行います。
p=none から quarantine、reject への移行#
順序は常に同じで、監視、隔離、拒否の順に進みます。変わるのは各段階の長さです。Google は none で少なくとも 1 週間を勧めています S3。RFC 9989 は、none で少なくとも 1 か月、reject の前に quarantine でも同程度の期間を置くよう勧めています S1。送信元が数個でレポートに問題のないショップなら、十数個のツールを使っているショップより早く進められます。
| ポリシー | 不合格のメール | 使う時期 |
|---|---|---|
| p=none | 通常どおり配信され、レポートのみ届く | すべての送信元を洗い出している間 |
| p=quarantine | 疑わしいメールとして扱われ、通常は迷惑メールフォルダへ | すべての送信元のアラインメントがレポートで確認できたら |
| p=reject | 受信側が拒否する | quarantine で問題のない期間を経たら |
ポリシーを変える前には、直近 1 週間のレポートで、見覚えのある送信元が不合格になっていないかを確認してください。スタッフがショップのドメインからメーリングリストに投稿している場合、RFC 9989 は p=reject を避けるよう助言しています。受信側に拒否されたリストのメールはリストの運用に支障をきたし、購読者が登録解除されることもあるためです S1。その場合は quarantine でとどめるのが妥当です。
サブドメインの DMARC#
news.ninefold.example のようなサブドメインは、独自のレコードがなければ ninefold.example のポリシーに従います。既存のサブドメインに別のポリシーを適用するには sp を、存在しない名前には np を使います。存在しないサブドメインは、ブランドのなりすましによく使われる手口です S1。
スタッフのメールと分けるため、メルマガをサブドメインから送るショップもあります。そのサブドメインには独自の _dmarc レコードを置けます。RFC 9989 では、サブドメインをまず p=quarantine; t=y でテストし、その後 p=reject に切り替えてテスト用のフラグを外す方法が紹介されています S1。
Claude や ChatGPT で Tellnod を使って DMARC を設定する#
Tellnod は、Claude や ChatGPT の中でメルマガを作成、プレビュー、送信するための MCP コネクタです。Tellnod の共用ドメイン上のアドレス（例：hello@yourshop.tellnodmail.com）からすぐに送信でき、その場合は 1 回のキャンペーンにつき 500 人まで、1 か月 1,000 通までという制限があります。独自ドメインを認証すると、この制限はなくなります。
チャットで「ninefold.example を送信ドメインとして設定して」と頼むと、Tellnod が SPF・DKIM・DMARC のレコードを示し、設定されたかを確認します。DNS を別の方が管理している場合は、設定用のリンクを作って送ってください。管理者はアカウントを作らずに、対応しているプロバイダならワンクリックでレコードを追加でき、コピーして設定することもできます。ドメインの認証が完了すると、チャットとメールでお知らせします。すでに DMARC レコードがある場合は、レコードを 1 つだけに保ち、ポリシーを強める前に Tellnod から送るメールのアラインメントが取れていることを確認してください。
どのキャンペーンも、パソコンとスマートフォンでのプレビューと、あなただけが押せる確認カードを経て送信されます。送信はすべて、あなたが承認します。無料プランで始めるには Tellnod を接続し、プランの比較は料金ページをご覧ください。Gmail と Yahoo が求めるそのほかの点は、メール到達率の基本にまとめています。
よくある質問#
最初はどんな DMARC レコードにすればよいですか？
v=DMARC1; p=none; rua=mailto: のあとに、自分が確認するアドレスを付けたレコードから始めてください。配信には何も影響せず、毎日のレポートが届き始めます S1。
Gmail と Yahoo の要件は p=none で満たせますか？
大量送信者の要件としては満たせます。From のドメインが SPF か DKIM と一致していれば、どちらも none のポリシーを認めています S4S5。あとから強制に移ると、なりすましへの防御が強まります。
p=none はどのくらいの期間続ければよいですか？
正規の送信元がすべてアラインメントで合格していることが、レポートで確認できるまでです。Google は少なくとも 1 週間、RFC 9989 は強制の前に 1 か月程度を勧めています S1S3。
DMARC レコードを 2 つ設定できますか？
できません。_dmarc には TXT レコードを 1 つだけ公開してください。照会で DMARC レコードが複数返ってくると、受信側はそのすべてを破棄するため、1 つにまとめる必要があります S1。
DMARC レコードはルートドメインとサブドメインのどちらに置きますか？
From アドレスに使うドメインのホスト _dmarc に置きます。メインドメインのレコードは、p・sp・np のタグを通じて、独自のレコードを持たないサブドメインにも適用されます S1。
出典#
- [S1] RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), 確認日
- [S2] RFC 9990: DMARC aggregate reporting, 確認日
- [S3] Google Workspace Admin Help: Recommended DMARC rollout, 確認日
- [S4] Google Workspace Admin Help: Email sender guidelines, 確認日
- [S5] Yahoo Sender Hub: Sender best practices, 確認日