Dripの​SPF・DKIM・DMARC設定。

Dripを認証すべき理由

Dripでの認証は任意の形式的な作業ではなく、今やDrip自身が必須としています。2024年2月1日以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook.comに同じルールの適用を始めました。これを受けてDripは、確認済みのCustom Sending Domainと、要件を満たすDMARCレコードをすべてのアカウントに義務付けました。これらがないと、キャンペーンはスロットリングされるか、Dripの共有の送信元として送信されます。その場合、受信者には「via Drip.com」と表示され、Fromアドレスのアライメントは一致せず、DMARCに成功できず、レピュテーションはプラットフォーム上の他の未認証アカウントすべてと共有されます。カスタム送信ドメインを設定すれば、これらはすべて一度に解決します。SPFとDKIMはどちらも組織ドメインとアライメントが一致し、「via」の表記は消え、DMARCに成功し、受信トレイへの到達は共有プールではなく自社の送信履歴に結び付きます。

DripにおけるSPFの実情

DripはCNAMEでドメインを認証するサービスのため、ルートドメインのSPFレコードに追加すべき「include:...」メカニズムはありません。Custom Sending Domainを追加すると、DripはReturn-Path/バウンス用のサブドメイン（例：em.yourdomain.com）をSendGridのインフラを指すCNAMEレコードとして生成し、SendGrid側がそのサブドメインのSPFレコードを公開します。エンベロープ/MAIL FROM（Return-Path）がこのサブドメインを使い、このサブドメインがSendGridのSPF認可範囲に解決されるため、SPFはそこで自動的に満たされます。さらに、サブドメインは組織ドメインを共有しているので、緩和されたSPFアライメントにより、DMARCにも引き続き成功します。実務上の結論として、ルートドメインのSPFレコードにinclude:sendgrid.net（またはDripのinclude）を追加しないでください。Dripはそれを求めておらず、アライメントの改善にもならず、10回のSPF DNSルックアップのうち1回を無駄に消費します。ルートドメインのSPFレコードはそのままで構いません。DripのSPF認可は、すべて委任されたサブドメイン上にあります。

設定手順

追加するレコード

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

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

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

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

確認は2か所で行います。まずDrip内です。Settings > Email Setup > Sending Domainでは、3つのCNAMEが解決されるとそれぞれに緑のチェックマークが表示されます。公開後にCheck Againをクリックし、問題があると判断する前にDNSの反映を24～48時間待ってください。次に受信側です。Gmailアカウント宛てにテストを送り、「Show original」を開いて、SPF=PASS、DKIM=PASS、DMARC=PASSと表示され、両方の仕組みのアライメントが自社ドメインと一致していること、Fromの行から「via Drip.com」の表記が消えていることを確認します。外部からのチェックとして、ドメインとDripのセレクターを送信ドメイン認証チェックまたは総合的なドメイン診断にかけ、レコードが世界中から参照でき、有効であることを確かめます。

よくある注意点

• DNS設定

  Cloudflareのオレンジのクラウドがオンだと認証が機能しません。プロキシ有効のCNAMEはSendGridではなくCloudflareのエッジに解決されるため、Dripのチェックに成功しません。DripのCNAMEレコードはすべてDNS-only（グレーのクラウド）に設定してください。

• 適用範囲

  s1/s2セレクターの衝突：同じドメインをSendGridまたはSendGridベースの別のツールですでに認証している場合、s1._domainkeyとs2._domainkeyのレコードが競合します。既存のものを上書きせず、Dripサポートにカスタムセレクター（drp/drp2など）を依頼してください。

• DNS設定

  ルートドメインにSPFのincludeを追加しない：DripのSPFは委任されたReturn-Pathサブドメインで処理されます。そのためルートドメインのinclude:sendgrid.netは不要で、アライメントも改善せず、10回のSPFルックアップのうち1回を無駄にします。

• DNS設定

  アンダースコアを含むCNAME：一部のレジストラはアンダースコア（_domainkeyのホスト）を受け付けなかったり、組み込みのサブドメインを外部ターゲットに向けられなかったりします。その場合は、Dripサポートに連絡し、回避策として同等のTXT/MXレコードを依頼してください。

• DNS設定

  DMARCレコードの重複：_dmarcのTXTレコードは1つしか許可されません。別の送信者用のDMARCがすでにある場合は、既存のレコードを編集してください。2つ目を追加すると両方が無効になります。

• DNS設定

  反映を急がない：CNAMEが登録されるまで24～48時間かかることがあります。公開直後に赤いチェックマークが出るのは、レコードの誤りではなく、DNSがまだ反映されていないことがほとんどです。

• DNS設定

  ホスト名の二重付加：多くのDNS管理画面はホスト欄にドメインを自動で付加します。s1._domainkeyだけを入力してください（s1._domainkey.yourdomain.com.yourdomain.comのようにしないでください）。ホスト名が二重になると、レコードが解決されません。

• DNS設定

  Return-Path用のCNAMEレコードの追加漏れ：2つのDKIMレコードを追加して、1つ目の（バウンス用の）CNAMEを忘れがちです。これがないと、DKIMは成功してもSPFのアライメントが一致せず、Dripでもドメインが完全には確認されません。

SPFレコードを作成

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

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

関連記事

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

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

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