EmailOctopusの​SPF・DKIM・DMARC設定。

EmailOctopusを認証すべき理由

EmailOctopusでのドメイン確認は、受信トレイへの到達に最も大きく効く手段であり、本格的な送信には今や事実上必須です。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年にOutlook/Hotmail/Liveへ同じルールを拡大し、EmailOctopus自身もgmail.comやyahoo.comのような無料の公開Fromアドレスからのキャンペーンをブロックしています。ドメインを確認するまで、EmailOctopusはブランドのない共有の送信元として送信します。メールが暗号学的に自社から送られたものであることを受信者に示せず、Fromアドレスのアライメントは一致せず、DMARCに成功できず、送信者レピュテーションは共有インフラ上の他の未認証の送信者すべてと共有されます。ドメイン確認は、これらを1つのフローですべて解決します。Easy DKIMがd=yourdomain.comで署名し、eomのmail-fromサブドメインにより、緩和されたアライメントで組織ドメインと一致するSPFの成功が得られ、両方の仕組みでDMARCに成功し、築いたレピュテーションは共有プールではなく自社ドメインに蓄積されます。

EmailOctopusにおけるSPFの実情

EmailOctopusはAmazon SES上で動く、CNAMEで認証するサービスです。そのため、ルートドメインに追加すべきinclude:amazonses.comはありません。古いチュートリアルのほとんどが誤っている点です。確認を行うと、EmailOctopusはeom.yourdomain.comという形式のmail-fromサブドメインを用意し、Amazon SESインフラを指す1つのCNAMEレコードとして公開するよう求めます。このサブドメインがキャンペーンのエンベロープ送信者/Return-Pathになり、その裏側のSPFレコードはEmailOctopusが公開します。これが「SPFレコードは当社側で対応します」という説明の意味です。エンベロープのドメイン（eom.yourdomain.com）は組織ドメインのサブドメインなので、DMARCのデフォルトである緩和されたアライメントでSPFに成功し、アライメントも一致します。つまり、Return-Pathがアライメントの決して一致しないmcsv.netドメインにあるMailchimpとは異なり、EmailOctopusではDKIMに加えて、アライメントの一致したSPFの成功も得られます。注意点は、SPFのアライメントが緩和のみであることです。エンベロープは素のyourdomain.comではなくeom.yourdomain.comのため、DMARCポリシーを厳格なSPF（aspf=s）に設定すると、SPFのアライメントの経路が失われます。実際に何かが壊れるわけではなく、Easy DKIMは引き続き厳格にアライメントが一致し、それだけでDMARCの成功を担えます。ただ、得るものはなく、2つ目の成功経路を失うだけなので、aspfは緩和（デフォルト）のままにしてください。ネイティブのEmailOctopusでは、ルートドメインのSPFレコードにinclude:amazonses.comを貼り付けないでください。10回のSPFルックアップのうち1回を消費するだけで、DMARCのアライメントには何の効果もありません。include:amazonses.comメカニズムが関係するのは、別の「EmailOctopus Connect」の経路だけです。そこでは自社のAmazon SESアカウント経由で送信し、SESのSPF、Easy DKIM、カスタムのMAIL FROMを自分で管理します。ルートドメインのSPFレコードは、Return-Pathに素のドメインを実際に使う送信者（Google Workspace、Microsoft 365、トランザクションメールのリレー）のために残し、EmailOctopusについてはeomサブドメインとDKIMに任せてください。

2つの設定方法

設定手順

追加するレコード

正確な値はEmailOctopusのセットアップウィザードで生成されます。以下は、DNSホストに追加するレコードの形式を示したものです。

DNSルックアップの10回制限

SPFのDNSルックアップは10回までに厳格に制限されており、超えるとpermerrorを返して、どの受信側でも検証されなくなります。EmailOctopusの設定がこの上限のうち何回を消費するかは、次のとおりです。

正しく設定できたか確認する

「Verified」バッジだけで判断せず、実際のメールで確認してください。テストキャンペーン（または確認済みFromアドレスからのテスト）を自分宛てに送り、Gmailで開いて⋮ → Show originalを選びます。確認する項目は次のとおりです。SPF: PASS、DKIM: PASSでsigned-by / d=yourdomain.com（amazonses.comやemailoctopus.comではない）、DMARC: PASSで、すべて自社ドメインが表示されていること。EmailOctopusのSenders画面には、Partially verifiedではなくVerifiedと表示されるはずです（Partially verifiedはDMARCのTXTがまだないことを意味します）。レコード自体はdig CNAME eom.yourdomain.com、dig CNAME <token>._domainkey.yourdomain.com、dig TXT _dmarc.yourdomain.comで確認できます。最後に、Qualisendのドメイン診断でドメインをチェックし、eomのCNAME、3つのDKIMセレクター、DMARCレコードがすべて正しく解決され、ルートドメインのSPFレコードが10回制限に収まっていることを確かめます。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。EmailOctopus（Amazon SES経由）が、アライメントの一致した、完全に成功している送信元として表示されるはずです。

よくある注意点

• 適用範囲

  「Verify email address」はドメイン確認ではありません。1つのFromアドレスを承認するだけで、DKIMもSPFのアライメントもDMARCも得られません。SendGridのSingle Senderに相当します。実際に認証するには、Verify domain (recommended)を選ぶ必要があります。

• DNS設定

  「Partially verified」は、ほとんどの場合DMARCのTXTレコードがないことを意味します。4つのCNAMEを追加して止まってしまう人が多く、生成された_dmarcのTXTレコードも公開してComplete verificationをクリックするまで、ドメインは完全なVerifiedになりません。

• 認証失敗の原因

  ネイティブのEmailOctopusでは、ルートドメインのSPFレコードにinclude:amazonses.comを追加しないでください。SPFはeomのmail-fromサブドメインの裏側で処理されるため、このincludeは不要で、10回のSPFルックアップのうち1回を消費し、DMARCのアライメントにも効果はありません。このincludeが該当するのはEmailOctopus Connect/自社のSESだけです。

• DNS設定

  eomのCNAMEは永久に残してください。Return-Pathであり、SPFのアライメントとバウンス処理の源です。後から（DNSの整理中に）削除すると、DKIMには成功し続けても、SPFとバウンス処理が気づかないうちに機能しなくなります。

• DNS設定

  CloudflareのプロキシはCNAMEレコードを壊します。eomのレコードと3つのDKIMセレクターをすべて「DNS only」（グレーのクラウド）に設定してください。オレンジのクラウドでプロキシ有効のCNAMEはamazonses.comに解決されず、確認に失敗します。

• DNS設定

  ホスト欄の二重化：多くのレジストラはドメインを自動で付加するため、eom.yourdomain.comと入力するとeom.yourdomain.com.yourdomain.comになります。ラベル（eom、またはtoken._domainkeyのセレクター）だけを入力してください。確認が止まったら.yourdomain.comを取り除く、というのがEmailOctopus自身のトラブルシューティングのヒントです。

• 適用範囲

  SPFのアライメントは緩和のみ可能です。エンベロープのドメインは素のルートドメインではなくeom.yourdomain.comなので、aspf=s（厳格なSPF）を設定したDMARCレコードでは、SPFのアライメントが失敗します。DKIMがDMARCの成功を担うので何も壊れませんが、2つ目の成功経路を無駄に失います。aspfは緩和（デフォルト）のままにしてください。厳格なDKIMアライメント（adkim=s）は問題ありません。

• DNS設定

  ネイティブのEmailOctopusとEmailOctopus Connectは別の設定です。ネイティブでは上記のCNAMEフローを使います。Connectでは自社のAmazon SESアカウント経由で送信し、Easy DKIMの有効化、カスタムのMAIL FROMの設定、そのドメインのSPFレコードへのinclude:amazonses.comの追加、DMARCの公開をAWS上で自分で行います。

SPFレコードを作成

EmailOctopusでは、ルートドメインにSPFのinclude:を追加する必要はありません。作成ツールを使って他の送信元用のクリーンなレコードを1つ組み立て、1行に収めてください。

EmailOctopusのSPFに関するよくある質問

関連記事

マーケティング・ESPの他のサービス

• GetResponse
• Kit (ConvertKit)
• Klaviyo
• Mailchimp
• MailerLite
• Marketo
• Moosend
• Omnisend

公開したら、ドメイン診断ですべてのレコードが正しく解決されることを確認し、DMARCレポート解析で自社ドメインを名乗って送信している送信元を把握します。作成ツールではすべての送信元を確認できます。ただし、認証は到達率対策の半分にすぎません。送信IPやドメインがブラックリストに掲載されていると、SPFの設定がどれほど適切でも迷惑メールに振り分けられます。そのため、ブラックリスト監視で掲載状況を確認しておくことをおすすめします。