Skip to content
無料の100クレジットで検証を始める
Qualisend
SPF設定ガイド

Resendの​SPF・DKIM・DMARC設定。

Resendは開発者向けのメールAPIで、貼り付けて使う共有のSPF行ではなく、ドメインごとに生成される少数のDNSレコードでドメインを認証します。ドメインを追加すると、Resendは3つのレコードを表示します。resend._domainkeyに置くDKIMのTXTレコード(Resendが生成する署名鍵)と、Return-Pathとして機能するsend.サブドメインに置くSPFのTXTレコードおよびMXレコードです。内部ではAmazon SES上で動作していますが、SESのEasy-DKIM CNAMEは表に出さず、独自のDKIM鍵1つにまとめています。3つのレコードが解決されると、メールへのResendの署名は自社ドメインの名義になります。DKIMはd=yourdomain.comと厳格なアライメントで一致し、SPFはsendサブドメインを介して緩和されたアライメントで一致するため、DMARCは両方の仕組みで成功します。

アカウント単位の認証
Your DNSAdd the CNAME / TXT records
ResendSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Resendを認証すべき理由

Resendのドメイン認証は、受信トレイに届くか迷惑メールフォルダーに振り分けられるかを分けるものです。認証が済むまでは、Resendの共有テストドメインであるonboarding@resend.devからしか送信できず、これは自社のものではまったくありません。2024年2月以降、GmailとYahooは、すべての大量送信者(1日あたり約5,000通以上)に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail宛ての大量メールに同じ要件の適用を始めました。Resendが担うことが多いのは、まさにこれらのルールで最も厳しく判断されるメールです。パスワードリセット、領収書、確認コード、そして増えつつあるマーケティング向けブロードキャストなど、1度迷惑メールに振り分けられるだけでサインアップの流れが途切れるものばかりです。その点、Resendの構成は際立ってシンプルです。SPFとReturn-Pathは自社ドメインのsend.サブドメインに置かれるため(MailchimpやSendGridの従来方式のように、サービス側がバウンス用ドメインを持つのではありません)、SPFは緩和モードで実際にアライメントが一致します。さらに、resendのDKIMセレクターによる署名は自社ドメインの名義になるため、DKIMは厳格にアライメントが一致します。レコードを公開すれば、Resendのドメインは両方の仕組みでDMARCに成功します。転送にも耐える、堅牢な構成です。公開しなければ、メールはresend.devとして送信されるか未認証のままとなり、レピュテーションは共有インフラに集約されます。

ResendにおけるSPFの実情

ResendはAmazon SES上に構築された、アカウント単位のサービスです。そのため、ルートドメインに追加する共有のincludeはありません。これは設計上の仕様です。ドメインを追加すると、Resendはsend.サブドメイン(SESのカスタムMAIL FROM、エンベロープ用のドメイン)を用意し、そこにSPFレコードを置きます。send.yourdomain.comに設定する値はv=spf1 include:amazonses.com ~allで、対応するMXレコード(feedback-smtp.{region}.amazonses.com)がバウンスと迷惑メール報告を受け取ります。ルートドメインのSPFレコードには一切手を加えないため、ResendによるDNSルックアップの消費はゼロです。多くのメール配信サービス(ESP)より優れている点が2つあります。1つ目は、Return-PathがResend所有のバウンス用ドメインではなく自社ドメインのサブドメインであるため、DMARCのSPFアライメントが緩和モードで一致することです(send.yourdomain.comは組織ドメインyourdomain.comを共有しています)。2つ目は、ResendがSESの3つのEasy-DKIM CNAMEセレクターを使わないことです。独自のDKIM鍵を生成し、resend._domainkey.yourdomain.comに1つのTXTレコードとして公開し、d=yourdomain.comで署名するため、DKIMは厳格にアライメントが一致します。つまり、ルートドメインのSPFレコードには何も追加しません。目にするinclude:amazonses.comはsendサブドメイン専用です。最も強いアライメントを担うのは、ルートドメインのincludeではなくDKIMです。古いチュートリアルでルートドメインにinclude:amazonses.comを追加するよう案内されていても、無視してください。Resendには何の効果もなく、ルートドメインの10回のルックアップのうち1回を消費し、SES全体にルートドメインとしての送信を不必要に許可してしまいます。

設定手順

Resendで
  1. 1

    ドメインを追加(リージョンも選択)

    resend.comにログインし、左のナビゲーションでDomainsを開いて、Add Domainをクリックします。送信ドメインを入力します。ルートドメイン(yourdomain.com)でも構いませんが、updates.yourdomain.comのような専用の送信用サブドメインがより適しています。次に、ユーザーに最も近いAWSリージョン(N. Virginia us-east-1、Ireland eu-west-1、São Paulo sa-east-1、Tokyo ap-northeast-1)を選びます。リージョンはMXホストに組み込まれ、後から変更するにはドメインを削除して追加し直す必要があるため、慎重に選んでください。

  2. 2

    Recordsタブを開く

    ResendがDNSレコードを生成し、ドメインのRecords/DNSタブに一覧表示します。内容は、DKIMのTXTレコード(resend._domainkey)が1つ、sendサブドメインのSPFのTXTレコードが1つ、sendサブドメインのMXレコードが1つです。send.yourdomain.comですでにサービスを運用している場合は、レコードをコピーする前にCustom Return Pathオプションで別のサブドメインを選んでください。

DNSホストで
  1. 3

    DKIMのTXTレコードを追加

    DNSホストでTXTレコードを作成します。ホストはresend._domainkey、値はResendに表示される長い公開鍵(p=で始まる)です。このレコードがメールをd=yourdomain.comに厳格なアライメントで一致させるので、値は正確に貼り付けてください。鍵の一部だけの貼り付けや余分な引用符は、正しく見えるドメインがDKIMに失敗する最も多い原因です。このレコードはルートドメイン(または送信用サブドメイン)のセレクターに置き、sendの下には置きません。

  2. 4

    sendサブドメインにSPFのTXTレコードを追加

    ホストをsend(つまりsend.yourdomain.com)、値をv=spf1 include:amazonses.com ~allとしてTXTレコードを作成します。これはReturn-PathのSESエンベロープを許可するものです。ルートドメインのSPFレコードには手を加えず、include:amazonses.comを追加しないでください。レジストラがドメインを自動で付加する場合は、send.yourdomain.comではなくsendとだけ入力します。

  3. 5

    sendサブドメインにMXレコードを追加

    MXレコードを作成します。ホストはsend、優先度は10、値は選択したリージョンに合わせたfeedback-smtp.{region}.amazonses.com(例:feedback-smtp.us-east-1.amazonses.com)です。レジストラが値にドメインを付加しないよう、値の末尾にドットを付けてください。このMXレコードはSESのバウンスと迷惑メール報告のフィードバックを受け取るだけで、通常の受信メールの配送先は変わりません。

  4. 6

    DMARCレコードを公開

    ResendはDMARCポリシーを推奨しますが、作成はしません。ホストを_dmarc、値をv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comとしてTXTレコードを追加します。p=noneは監視のみのため、アライメントを確認している間、配信には何も影響しません。_dmarcレコードは1つのドメインにつき1つだけにしてください。

確認
  1. 7

    Verify DNS Recordsをクリック

    Resendに戻り、Verify DNS Recordsをクリックします。DNSの反映は通常数分ですが、最大72時間かかることがあります。3つのレコードがすべて解決されると、ステータスがVerifiedに変わります。進まない場合は、ホストの二重付加、リージョンが合っていないMX、末尾のドットの欠落がないかを見直し、もう一度確認を実行してください。

  2. 8

    実際のテストメールを送信してヘッダーを確認

    ダッシュボードのVerifiedは、メールのアライメントが一致している証拠にはなりません。確認済みドメインのアドレス(@resend.devは不可)からGmailアカウントへメッセージを送り、開いて⋮ → Show originalを選びます。SPF: PASS(mailed-byがsend.yourdomain.comのホスト)、DKIM: PASS(signed-by: yourdomain.com、セレクターはresend)、DMARC: PASSと表示され、いずれもresend.devやamazonses.comではなく自社ドメインを指していれば成功です。

追加するレコード

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

タイプホスト値
TXTresend._domainkeyp=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(long public key from Resend)DKIM公開鍵です。セレクターはresendで、ルートドメインまたは送信ドメインに置きます。これによりメールがd=yourdomain.comに厳格なアライメントで一致します。例です。実際の1024ビットの鍵はドメインごとに生成され、1つのp=…の文字列(v=DKIM1の接頭辞なし)として表示されるので、表示どおりに貼り付けてください。
TXTsendv=spf1 include:amazonses.com ~allsendサブドメイン用のSPFレコード(SESのエンベロープ、MAIL FROM)です。置き場所はルートドメインではなくsend.yourdomain.comです。ルートドメインのSPFレコードにinclude:amazonses.comを追加しないでください。
MXsendfeedback-smtp.us-east-1.amazonses.comSESのバウンスと迷惑メール報告のためのReturn-Pathです。優先度は10、sendサブドメインに置き、末尾にドットを付けます。リージョンごとに異なり、ドメイン追加時に選んだリージョン(us-east-1 / eu-west-1 / sa-east-1 / ap-northeast-1)に合わせます。
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com自分で追加します。Resendは推奨ポリシーを表示しますが、DNSには書き込みません。1つのドメインにつき1つだけにし、p=noneから始めて段階的に引き上げます。

ルートドメインのSPF(v=spf1)のTXTレコードは1つだけにし、すべての送信元をこの1行にまとめてください。SPFレコードが2つあると、それ自体がエラーになります。

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

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

SPF 10-lookup budget0 used · 10 free

Resendの推奨設定はルックアップを消費しません。10回すべてを、includeが必要な他の送信元に使えます。

DKIM

DKIMはResendの設定で最も重要なレコードであり、素のAmazon SESとの違いが表れる部分でもあります。ResendはSES上で動作していますが、SESの3つのEasy-DKIM CNAMEセレクターは提供しません。代わりに、ドメインごとに独自のDKIM鍵ペアを生成し、TXTレコードを1つだけ提示します。ホストはresend._domainkey.yourdomain.com、値は公開鍵(Recordsタブに表示されるp=…の文字列)、セレクターはresendです。Resendが対応する秘密鍵を保持し、すべてのメッセージにd=yourdomain.com; s=resendで署名します。このd=はamazonses.comでもResend所有のドメインでもなく自社ドメインであるため、DKIMはDMARCに対して厳格にアライメントが一致し、メッセージが転送された場合でも成功し続けます。転送はまさにSPFが失敗しやすい場面です。実務上の注意点は2つあります。1つ目は、これは公開するTXTレコードでありCNAMEによる委任ではないため、CNAMEで認証するサービスのようにResend側で密かに鍵をローテーションできないことです。ローテーションする場合は、新しい値を公開し直します。2つ目は、値をResendの表示どおりに貼り付けることです。Resendは1024ビットの鍵で署名するため、p=の値は約216文字の1つの文字列で、DNSの文字列あたり255文字というTXTの上限に収まります。一部のサービスが提供する、より長い2048ビットの鍵とは異なり、複数の引用符付き文字列には分割されないので、途切れのない1つの値として貼り付けてください。一部だけのコピー、紛れ込んだスペース、DNS管理画面が文字列に付ける余分な引用符は、設定済みに見えるドメインがDKIMチェックに失敗する最も多い原因です。DKIMレコードは、ルートドメイン(または送信用サブドメイン)のセレクターに置きます。SPFとMXを置くsendサブドメインの下ではありません。

DMARC

DMARCは別のポリシーレコードで、Resendは推奨はするものの作成はしません。DNSホストで自分で追加します。_dmarc.yourdomain.comに、v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comで始まるTXTレコードを公開します。p=noneは監視のみのため配信には何も影響せず、受信側に集計レポート(rua)をメールで送るよう伝えます。これにより、ResendのメールがSPFとDKIMに成功し、自社ドメインとアライメントが一致していることを確認できます。この点でResendは優秀です。sendサブドメインを介した緩和されたSPFアライメントと、resendセレクターによる厳格なDKIMアライメントの両方が得られるため、ほぼすぐにDMARCの成功を確認できるはずです。d=yourdomain.comはFromドメインと完全に一致するので、必要であればadkim=s(厳格なDKIMアライメント)を追加しても問題ありません。1~2週間レポートを確認し、正規の送信者(Resendと、メールボックスサービスやその他のツール)がすべて認証できていることを確かめたら、ポリシーをp=noneからp=quarantine、最終的にp=rejectへと段階的に引き上げます。送信者の数にかかわらず、_dmarcレコードは組織ドメイン全体で1つだけにしてください。Resendのために2つ目のDMARCレコードを追加してはいけません。

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

Resendの緑のVerifiedバッジだけで判断しないでください。これは3つのレコードが解決されたことを示すだけで、実際のメールのアライメントが一致することまでは意味しません。確認済みドメインのアドレス(例:no-reply@yourdomain.com。@resend.devのアドレスは不可)からGmailアカウントへテストメールを送り、開いて⋮ → Show originalを選びます。SPF: PASS(mailed-byがsend.yourdomain.comのホスト)、DKIM: PASS(signed-by: yourdomain.com、セレクターはresend)、DMARC: PASSと表示され、いずれもresend.devやamazonses.comではなく自社ドメインに紐づいていれば成功です。DKIMが自社ドメインなのにSPFがamazonses.comのままでアライメントが一致しない場合は、sendサブドメインのレコードが設定されているか確認してください。生のレコードは、dig TXT resend._domainkey.yourdomain.com、dig TXT send.yourdomain.com、dig MX send.yourdomain.comで個別に確認できます。最後に、Qualisendのドメイン診断でドメインをチェックし、すべてのレコードが解決され、ルートドメインのSPFレコードが10回の上限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Resend/Amazon SESが、アライメントが一致し認証に成功している送信元として表示されるはずです。

よくある注意点

  • 適用範囲

    Resendのレコードはルートドメインではなくsendサブドメインに置きます。ドメインを自動で付加するレジストラでは、sendがsend.yourdomain.com.yourdomain.comに、resend._domainkeyが二重のホストになります。ラベル(send、resend._domainkey)だけを入力し、ドメインの付加は管理画面に任せてください。

  • 適用範囲

    MXの値はリージョンごとに異なり、ドメイン追加時に選んだリージョンと一致している必要があります。eu-west-1のドメインにus-east-1のfeedback-smtpのMXレコードを設定しても確認は完了しません。作成後のドメインのリージョンは変更できないので、ドメインを削除して新しいリージョンで追加し直し、MXレコードを更新してください。

  • 適用範囲

    レジストラがドメインを付加してfeedback-smtp.us-east-1.amazonses.com.yourdomain.comという値にならないよう、MXの値(feedback-smtp.{region}.amazonses.com.)の末尾にドットを付けてください。

  • 認証失敗の原因

    ルートドメインのSPFレコードにinclude:amazonses.comを追加しないでください。ResendのSPFレコードはsendサブドメインに置くものです。ルートドメインのincludeはResendには何の効果もなく、ルートドメインの10回のルックアップのうち1回を無駄に消費し、Amazon SES全体にルートドメインとしての送信を許可してしまいます。

  • DNS設定

    ResendはSES上に構築されていますが、SESの3つのEasy-DKIM CNAMEは使いません。生成した鍵を1つのDKIMのTXTレコード(セレクターはresend)として公開します。CNAMEセレクターを探す必要はありません。この1つの鍵を正確に貼り付けてください。一部だけの貼り付けや余分な引用符は、「設定済み」のドメインでDKIMが失敗する最大の原因です。1024ビットの鍵なので値は1つの文字列に収まります。分割しないでください。

  • 適用範囲

    共有の@resend.devアドレス(onboarding@resend.dev、delivered@resend.devなど)は、APIを試すためだけのものです。自社ドメインではなく、SPF/DKIMのアライメントは一切得られません。自社として送信するには、自社ドメインを追加して確認を完了する必要があります。

  • DNS設定

    これらはCNAMEではなくTXTレコードとMXレコードなので、Cloudflareのオレンジのクラウド(プロキシ)の問題はありません。ただし、Cloudflareがすでにルートドメインに自動でSPFレコードを作成している場合は、そのままにしてください。ResendのSPFレコードは別物で、sendサブドメインに置きます。

  • 適用範囲

    send.yourdomain.comですでにメールやサービスを運用している場合(既存のSPF、MX、またはサブドメイン)は、既存の設定と衝突しないよう、ResendのCustom Return Path機能で別のReturn-Path用サブドメインを選んでください。

SPFレコードを作成

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

1

送信元

メールの送信に使っているサービスを検索して、それぞれチェックを入れてください。

上の検索欄で利用中のメールサービスを検索するか、してください。

2

このドメイン自身のサーバー

ドメインが(上記のサービスを経由せず)直接メールを送信する場合は、ドメイン自体を許可します。

3

その他の送信元・IP

リストにないもの(別のサービスのSPFホストや特定のIPアドレス)を追加します。

接頭辞のinclude:は自動で付加されます。サービスのドキュメントに記載されているホスト名を入力してください。

4

その他すべての送信元へのポリシー

上記に記載されていないサーバーからのメールを、受信側がどう処理すべきかを指定します(allメカニズム)。

生成されたSPFレコードDNSルックアップ0/10回
v=spf1 ~all

送信元がまだないため、すべてのメッセージに~allポリシーが適用されます。ステップ1で利用中のサービスを追加してください。

  • ルートドメインにTXTレコードとして公開します。ホストは@(ドメインそのもの)、値は上記の文字列全体です。
  • SPFレコードは1つのドメインにつき1つだけにします。すべての送信元をこの1行にまとめてください。v=spf1で始まるTXTレコードが2つあると、両方とも無効になります。
  • DNSルックアップは10回以内に収めてください。include:、a、mxはそれぞれ1回とカウントされ、includeは内部でさらにルックアップを発生させることがあります。ip4:とip6:はカウントされません。

送信ドメイン認証の設定が済んだら、次は検証済みのクリーンなリストへの配信です。

リストを検証

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

いいえ。ResendのSPF(v=spf1 include:amazonses.com ~all)は、ルートドメインではなく、SESのエンベロープ兼Return-Pathとして機能するsendサブドメインに置きます。このサブドメインは組織ドメインを共有しているため、SPFはDMARCに対して緩和モードでアライメントが一致します。ルートドメインにinclude:amazonses.comを追加してもResendには何の効果もなく、ルートドメインの10回のルックアップのうち1回を無駄に消費するだけです。

いいえ。Resendは独自のDKIM鍵を生成し、resend._domainkeyに置く公開鍵のTXTレコードを1つ提示します。SESを直接操作することはなく、SESの3つのCNAMEセレクターも追加しません。この1つのTXTレコードを正確に貼り付けて公開すると、Resendはd=yourdomain.comで署名するようになります。

認証する対象がそれぞれ異なるためです。DKIMのresendセレクターはd=yourdomain.comで署名するので、DMARCに対して厳格にアライメントが一致し、転送にも耐えます。SPFレコードとfeedback-smtpのMXレコードは、SESのMAIL FROM兼Return-Pathであるsend.yourdomain.comに置き、緩和モードでアライメントが一致します。両方の仕組みでアライメントが一致する構成は、多くのESPで実現できるものより強固です。

どちらでも機能しますが、トランザクションメールやブロードキャストのレピュテーションを主要ドメインから切り離せるよう、Resendは専用の送信用サブドメイン(例:updates.yourdomain.comまたはmail.yourdomain.com)を推奨しています。その場合、レコードはその下に入ります。SPF/MXはsend.updates.yourdomain.com、DKIMはresend._domainkey.updates.yourdomain.comです。

ほとんどの場合、次の4つのいずれかです。ホストの二重付加(レジストラがドメインを付加)、誤ったAWSリージョンを指すMX、MXの値の末尾のドットの欠落、DKIM鍵の一部だけの貼り付けや余分な引用符です。digで各レコードが解決され、ResendのRecordsタブと完全に一致することを確認してから、もう一度Verifyをクリックしてください。DNSの反映には最大72時間かかることがあります。

いいえ。Resendは推奨のDMARCポリシーを表示しますが、_dmarc.yourdomain.comへの公開は自分で行います。_dmarcレコードは1つのドメインにつき1つだけにし、まずp=noneで監視します。ResendではDKIMとSPFの両方でアライメントが一致するので、レポートに問題がなければp=quarantine、さらにp=rejectへと引き上げます。

いいえ。リージョンはfeedback-smtpのMXホストに組み込まれるため、ドメイン追加時に固定されます。リージョンを移すには、Resendでドメインを削除し、新しいリージョンで追加し直してから、MXの更新とすべてのレコードの再確認を行います。その場で切り替える方法はないので、最初に受信者に最も近いリージョンを選んでください。選択肢はus-east-1(N. Virginia)、eu-west-1(Ireland)、sa-east-1(São Paulo)、ap-northeast-1(Tokyo)です。

関連記事

トランザクションメール・APIの他のサービス

すべてのSPFガイド
ResendのSPF、DKIM、DMARCを毎日監視レコードの設定は、最初の一歩にすぎません。ドメイン診断の監視は、SPFのルックアップ数、DKIMキー、DMARCポリシーを毎日再チェックし、どれかが壊れたときにメールでお知らせします。ドメイン診断の監視を見るSPFのDNSルックアップが多すぎる場合:数え方とpermerrorの直し方

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

認証の次は、リストをクリーンに保つ

SPF、DKIM、DMARCに成功すれば受信トレイに届き、クリーンなリストならその状態を維持できます。お手持ちのリストも検証してクリーニングできます。100クレジット無料、クレジットカード登録不要で始められます。

検証を始める