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

Mailtrapの​SPF・DKIM・DMARC設定。

Mailtrapのドメイン認証は、共通のSPFの行を貼り付ける方式ではなく、CNAMEによるドメイン確認で行います。Email Sendingで送信ドメインを追加すると、Domain Verificationページに5つのDNSレコードが表示されます。Domain VerificationのCNAME（SPF／return-pathも兼ねます）、rwmt1._domainkeyとrwmt2._domainkeyセレクターの2つのDKIM CNAME、ブランド独自の開封／クリック計測に使う任意のCustom Tracking DomainのCNAME、そしてDMARCのTXTレコードです。これらが解決されると、メールは自社ドメイン名義で署名・送信されます。DMARCはアライメントの一致したDKIMで成功し（自社ドメインのreturn-pathによりSPFでも成功します）、SPFのincludeを直接公開したり管理したりする必要はありません。最初につまずきやすい点が1つあります。これが当てはまるのはMailtrap Email Sendingだけです。別製品のEmail Testingサンドボックスは架空の受信トレイでメッセージを受け止めるもので、DNSは一切必要ありません。

CNAMEによるドメイン認証
Your DNSAdd the CNAME / TXT records
MailtrapSigns & sends as your domain
The inboxSPF · DKIM · DMARC pass

Mailtrapを認証すべき理由

Mailtrapでの送信ドメインの確認は、メールが受信トレイに届くか迷惑メールフォルダーに入るかの分かれ目です。さらにMailtrapは、本番メールを送信する前提条件としてこれを求めています。ドメインの確認が済むまで、Email Sendingのストリームで送れるのは自分のアカウントのメールアドレス宛てのテストメールだけで、実際の受信者への送信はブロックされます。加えて、時期も重要です。2024年2月以降、GmailとYahooは、すべての大量送信者（1日あたり約5,000通以上）に対し、SPF、DKIM、DMARCにアライメントが一致した状態で成功することを義務付けています。Microsoftも2025年に、Outlook/Hotmail/Liveで同じ基準の適用を始めました。最初は要件を満たさない大量メールを迷惑メールに振り分け、その後は完全な拒否へと移行しつつあります。Mailtrapはトランザクション／API送信のサービスなので、未確認のストリームでは、メールが送信されないか、送信されても自社ドメインとの結び付きが弱いままです。アライメントの一致したDKIMもDMARCの成功もなく、レピュテーションも自社ドメイン独自のものにならず、Mailtrapの共有インフラでまとめて扱われます。ドメインの確認を完了すれば、これらがすべて一度に解決します。2つのrwmt DKIMセレクターがd=yourdomain.comで署名するのでDKIMのアライメントが一致し、Domain VerificationのCNAMEがMailtrapのreturn-pathを自社ドメインに置くのでSPFも成功してアライメントが一致します。DMARCは両方の仕組みで成功し、築いた送信レピュテーションは自社ドメインに蓄積されます。

MailtrapにおけるSPFの実情

MailtrapはCNAMEでドメインを確認するサービスなので、ルートドメインに追加すべきSPFのincludeはありません。Mailtrapのドキュメントにも「メールのSPFチェックはドメイン確認レコードでカバーされます。送信ドメインに別途SPFレコードを追加する必要はありません。」と明記されています。仕組みは次のとおりです。送信ドメインを確認する際にMailtrapが提供するCNAMEの1つがDomain Verificationレコードで、自社ドメイン上のreturn-path／バウンス用ホストを兼ね、SPFのルックアップをMailtrapの送信インフラに委任します。Mailtrapの実際のSPFレコードは_spf.smtp.mailtrap.live（v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all）にありますが、これを自分で公開することはありません。Domain VerificationのCNAMEが自動的にそこへ解決されます。return-pathのホストは確認済みの自社ドメインの配下にあるため、SPFは成功し、緩和されたアライメントで組織ドメインとも一致します。SPFのアライメントが決して一致しない、DKIMのみをCNAMEで認証するサービス（Mailchimp、Klaviyo）に対する、実質的な利点です。知っておくべき点が2つあります。1つ目は古い情報です。include:_spf.mailtrap.ioを追加するという案内は無視してください。そのホスト名はSPFレコードとしてまったく解決されません。正しいインフラ用ホスト（_spf.smtp.mailtrap.live）も、ルートドメインに貼り付けるものではありません。手動で追加しても、SPFのDNSルックアップの10回のうち1回を無駄に消費するだけです。2つ目は、DNSがGoogle Cloud DNSの場合、コンソールに従来の「SPF」レコードタイプが今も表示されることです。Mailtrapは、これを無視し（非推奨です）、4つのCNAMEとDMARCのTXTを通常どおり追加するよう明示しています。ルートドメインのSPFへの影響としては、Mailtrapが追加するDNSルックアップは0回なので、Google Workspace、Microsoft 365、その他すでに記載している送信元と問題なく併用できます。

2つの設定方法

推奨

専用の送信用サブドメイン（例：mail.yourdomain.com）を確認

  • Mailtrap／トランザクションメールのレピュテーションをルートドメインの通常のメールから切り離せるので、送信上のミスがメインのドメインに波及しません。
  • DKIMはd=mail.yourdomain.comで署名します。緩和されたDMARCアライメントでは組織ドメインとも一致するので、DMARCに成功します。
  • Domain VerificationのCNAMEがreturn-pathをサブドメインに置くため、SPFもそこで成功し、アライメントが一致します。
  • 追加するのは同じく4つのCNAMEと1つのDMARC TXTです。ルートドメインのSPFは変更せず、DNSルックアップも消費しません。
従来方式

ルートドメイン／組織ドメイン（yourdomain.com）を確認

  • Mailtrapが唯一または主要な送信者で、ドメインそのものから送信していることを見せたい場合に最も簡単です。
  • DKIMとreturn-pathが組織ドメインに直接置かれるので、緩和モードに頼らず完全に一致します。
  • レピュテーションはルートドメインから送るすべてのメールと共有されます。Google WorkspaceやMicrosoft 365の通常のメールも同じドメインにある場合は、この点を考慮してください。
  • Mailtrapはルートドメインのincludeではなく、Domain VerificationのCNAMEを使うので、この場合もルートドメインのSPFのルックアップは増えません。

設定手順

Mailtrapで
  1. 1

    Email Testingではなく、Email Sendingを開く

    mailtrap.ioにサインインし、Email Testing（QA用にメッセージを受け止めるサンドボックスで、DNSは不要）ではなく、Email Sending（実際の送信メールを扱うサイドバーのセクション）を開いていることを確認します。ドメインの確認があるのはEmail Sendingだけです。

  2. 2

    送信ドメインを追加

    左側のナビゲーションでSending Domainsに進み、Add Domainをクリックします。送信に使うドメインを入力します（例：yourdomain.com、またはトランザクションメールを切り離したい場合はmail.yourdomain.comのようなサブドメイン）。Mailtrapは、入力したその名前に対するDNSレコードを生成します。

  3. 3

    Domain Verificationページを開く

    新しいドメインを選択して、Domain Verificationページを開きます。公開するレコードが、用途別のラベル付きで表示されます：Domain Verification（CNAME）、DKIM（2つのCNAME）、Custom Tracking / Domain Tracking（CNAME）、DMARC（TXT）。Type、Name、Valueの列を確認してください。NameとValueはアカウントごとに生成されます。

DNSホストで
  1. 4

    Domain VerificationのCNAMEを追加

    Mailtrapに表示されたNameとValueをそのまま使い、Domain VerificationレコードをCNAMEとして作成します。この1つのレコードで所有権の証明とSPF／return-pathの両方をカバーするため、別途SPFレコードを公開する必要はありません。タイプはCNAMEのままにし、TXTやAに変更しないでください。

  2. 5

    DKIM CNAMEを2つ追加

    2つのCNAMEレコードを作成します：Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io、Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io（ダッシュボードに表示された正確な値を使ってください）。セレクターが2つあるため、DNSを再度編集しなくても、MailtrapがDKIM鍵をローテーションできます。メールにd=yourdomain.comで署名し、DMARCの成功を支えるのはこれらのCNAMEです。

  3. 6

    Custom Tracking DomainのCNAMEを追加

    トラッキング用CNAME（通常はmt-linkのようなNameが表示されます）を作成し、提供されたValueを指定します。開封／クリック計測と配信停止リンクを、Mailtrapのホストではなく自社ドメインから提供するためのものです。リンク計測を使わない場合に省略できるのはこのレコードだけですが、追加すれば計測リンクをブランドに合わせられ、Mailtrapの汎用トラッキングホストが持つ共有ドメインのレピュテーションも避けられます。

  4. 7

    DMARCのTXTレコードを追加

    Name _dmarcに、Mailtrapに表示された値（v=DMARC1; p=none; …のポリシー）でTXTレコードを1つ作成します。ドメインにすでに_dmarcレコードがある場合、2つ目を追加してはいけません。DMARCレコードはドメインにつき1つだけでなければならないので、既存のものを残してください。

  5. 8

    ホストの重複を修正し、Cloudflareのプロキシをオフにする

    多くのレジストラはドメインを自動で付加するため、重複を避けるにはラベルのみ（rwmt1._domainkey.yourdomain.comではなくrwmt1._domainkey）を入力します。ただし、完全な形を求める管理画面も少数あるので、利用中のホストの仕様に合わせてください。Cloudflareでは、すべてのCNAMEを「DNS only」（グレーのクラウド）に設定します。Cloudflareはデフォルトでプロキシを有効にしますが、オレンジのクラウドでプロキシが有効なCNAMEはMailtrapに解決されず、確認に失敗します。

確認
  1. 9

    MailtrapでDNSを再チェック

    Domain Verificationページに戻り、Re-check DNS Recordsをクリックします。Mailtrapも定期的に自動チェックするので、反映されるにつれてレコードがMissing（赤）からVerified（緑）に変わります。通常は数分ですが、15分から24～48時間を見込んでください。先に確認が済むレコードもあります。すべてが緑になるまで待ちます。

  2. 10

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

    確認済みドメインのアドレスからメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS（yourdomain.comの署名、セレクターはrwmt1またはrwmt2）、SPF: PASS、DMARC: PASSを確認します。いずれもmailtrap.ioのホストではなく、自社ドメインとアライメントが一致している必要があります。

追加するレコード

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

タイプホスト値
CNAME(Mailtrap-generated verification host)(per-account target, e.g. under smtp.mailtrap.live)Domain Verificationレコードの例です。正確なNameとValueはアカウントごとに異なり、Domain Verificationページに表示されます。このCNAMEはSPF／return-pathもカバーするため、別途SPFレコードは必要ありません。
CNAMErwmt1._domainkeyrwmt1.dkim.mailtrap.ioDKIM鍵1（自動ローテーション）。正確な値はダッシュボードからコピーしてください。DNSホストによっては、完全な形のrwmt1._domainkey.yourdomain.comが必要です。
CNAMErwmt2._domainkeyrwmt2.dkim.mailtrap.ioDKIM鍵2。2つ目のセレクターにより、Mailtrapが鍵をローテーションできます。ダッシュボードに表示された正確な宛先を使ってください。
CNAMEmt-link(per-account tracking target)Custom Tracking Domainです。ホストと宛先は例です。ブランド独自の開封／クリック計測と配信停止リンクを自社ドメインで使えるようにします。任意ですが推奨です。正確なName/Valueはアカウントごとに表示されます。
TXT_dmarcv=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARCポリシーです。ドメインごとに1つだけにします。Mailtrapはp=noneの値を入力済みで表示します。_dmarcレコードは1つだけにし、後からquarantine/rejectへ引き上げてください。

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

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

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

SPF 10-lookup budget0 used · 10 free

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

DKIM

DKIMは、Mailtrapがドメインごとに生成する2つのCNAMEレコード（rwmt1._domainkeyとrwmt2._domainkey）で処理します。それぞれrwmt1.dkim.mailtrap.ioとrwmt2.dkim.mailtrap.ioを指します（正確な値はDomain Verificationページからコピーしてください）。貼り付けるTXTレコードではなくMailtrapに委任するCNAMEなので、Mailtrapが秘密鍵を保持し、2つのセレクターを使って公開鍵をローテーションします。DNSを再度編集する必要はありません。コピーするDKIM公開鍵も、自分で考えるセレクターもありません。ここでDMARCを主に支えるのはDKIMです。CNAMEが解決されると、Mailtrapは送信メールにd=yourdomain.comで署名します。署名は組織ドメインとアライメントが一致し、SPFを失敗させることがある転送の影響も受けず、これだけでDMARCの要件を満たします。実務上の注意点がいくつかあります。レコードタイプはCNAMEのままにしてください（CNAMEが必要な箇所にTXTを設定すると確認に失敗します）。管理画面がドメインを自動で付加する場合はラベルのみ（rwmt1._domainkey）を入力し、付加しない場合は完全な形（rwmt1._domainkey.yourdomain.com）を入力します。Cloudflareでは、mailtrap.ioの宛先に解決されるよう、両方を「DNS only」（グレーのクラウド）に設定します。2つのCNAMEを追加してRe-check DNS Recordsをクリックすると、DKIMの行が緑に変わります。

DMARC

DMARCは自社ドメインに設定する別のポリシーレコードで、MailtrapはこれをDomain Verificationページのレコード一式に含めています。通常はv=DMARC1; p=none; …のように入力済みです。_dmarc.yourdomain.comにTXTレコードとして公開してください。p=noneは監視のみのため、配信には影響しません。その間に集計レポート（rua）で、MailtrapのメールがDKIM（とSPF）に自社ドメインとアライメントの一致した状態で成功していることを確認します。Mailtrapでは、アライメントの一致したDKIM（rwmtセレクター）とreturn-path（Domain VerificationのCNAME）の両方が得られるので、正しく確認されたドメインは両方の仕組みでDMARCに成功します。転送にも強い構成です。1～2週間、レポートを確認し、正当な送信者がすべて認証されていることを確かめてから、p=quarantine、最終的にp=rejectへと段階的に引き上げます。ルールは2つです。送信者がいくつあっても_dmarcレコードはドメイン全体で1つだけにしてください。すでにある場合はMailtrapの分を追加せず、既存のものを残してください。また、ruaの宛先は実際に確認しているメールボックス（またはDMARCレポートサービス）にしてください。そうでなければ、p=noneは何の役にも立ちません。

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

Domain Verificationページの緑の「Verified」バッジだけで判断しないでください。バッジが示すのはレコードが解決されることだけで、実際のメールが認証されることではありません。確認済みドメインのアドレスから自分宛てにテストメールを送り、Gmailで開いて⋮ → Show originalを選びます。DKIM: PASS（yourdomain.comの署名、セレクターはrwmt1またはrwmt2）、SPF: PASS、DMARC: PASSがいずれもmailtrap.ioのホストではなく自社ドメインで表示されていれば成功です。Mailtrapでは、定期チェックを待たずにRe-check DNS Recordsボタンで強制的にチェックできます。レコードそのものは、dig CNAME rwmt1._domainkey.yourdomain.comとdig TXT _dmarc.yourdomain.comで個別に確認できます。次に、Qualisendのドメイン診断でドメインをチェックし、Domain VerificationのCNAME、両方のDKIMセレクター、トラッキング用CNAME、DMARCレコードがすべて正しく解決され、ルートドメインのSPFが10回の上限内に収まっていることを確認します。DMARCの集計レポートが届き始めたら、DMARCレポート解析にレポートをドロップします。Mailtrapが、アライメントが一致して成功している送信元として表示されるはずです。

ドメイン診断 DMARCレポート解析

よくある注意点

  • 適用範囲

    Email TestingとEmail Sendingの違い：ドメインの確認があるのはEmail Sendingだけです。Email Testingサンドボックスは、QA用に架空の受信トレイでメッセージを受け止めるもので、DNSレコードは一切必要ありません。Email TestingでDNSの設定を探しているなら、場所が違います。

  • DNS設定

    追加すべきSPFレコードはありません。MailtrapのDomain VerificationのCNAMEがSPF／return-pathをすでにカバーしています。include:_spf.mailtrap.io（解決されません）やinclude:_spf.smtp.mailtrap.live（Mailtrap内部のインフラ用ホスト）をルートドメインに貼り付けないでください。SPFのルックアップを無駄に消費するだけで、Mailtrapのドキュメントにも別途SPFレコードは不要と明記されています。

  • DNS設定

    Cloudflareのプロキシは確認の妨げになります。MailtrapのCNAMEはすべて「DNS only」（グレーのクラウド）に設定してください。Cloudflareはデフォルトでオレンジのクラウドのプロキシを有効にしますが、プロキシが有効なCNAMEはmailtrap.io / mailtrap.liveの宛先に解決されず、レコードの確認がいつまでも完了しません。

  • DNS設定

    ホスト欄の重複：多くのレジストラはドメインを自動で付加するため、rwmt1._domainkeyがrwmt1._domainkey.yourdomain.com.yourdomain.comになることがあります。管理画面がドメインを付加する場合はラベルのみを入力してください。逆に、完全な形を求めるホストも少数あります（Squarespaceに似た管理画面の一部など）。利用中のサービスの仕様に合わせてください。

  • DNS設定

    DMARC（TXT）以外のレコードはすべてCNAMEです。タイプを変更しないでください。Google Cloud DNSの場合は特に、コンソールにある従来の「SPF」レコードタイプを無視してください。Mailtrapも非推奨としています。4つのCNAMEと1つのDMARC TXTを追加します。

  • 適用範囲

    ドメインがVerifiedになるまで、Email Sendingのストリームで配信できるのは自分のアカウントのメールアドレス宛てのテストメールだけです。実際の受信者への本番送信はブロックされたままなので、アプリの本番トラフィックにMailtrapを接続する前に確認を完了してください。

  • DNS設定

    DMARCとSPFのレコードはそれぞれ1つだけにしてください。Google Workspace、Microsoft 365、SendGridなどでも送信している場合、2つ目の_dmarcや2つ目のSPFのTXTを追加してはいけません。MailtrapはルートドメインのSPFに何も追加しないので、既存の1つずつのレコードをそのまま残します。

  • 適用範囲

    確認はすぐには完了しません。DNSの反映には15分から24～48時間かかることがあり、Mailtrapは独自のスケジュールで再チェックします。強制的にチェックするにはRe-check DNS Recordsを使ってください。先に緑になるレコードがあっても想定どおりです。

SPFレコードを作成

Mailtrapでは、ルートドメインに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:はカウントされません。

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

リストを検証

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

いいえ。メールのSPFチェックはMailtrapのDomain VerificationのCNAMEでカバーされます。Mailtrapのドキュメントにも、送信ドメインに別途SPFレコードを追加する必要はないと記載されています。return-pathは確認済みの自社ドメインにあるため、includeを公開しなくてもSPFは成功してアライメントが一致し、ルートドメインのSPFのルックアップも増えません。

無視してください。_spf.mailtrap.ioはSPFレコードをまったく返さないので、追加しても10回のSPFルックアップのうち1回を無駄に消費するだけです。Mailtrapの実際の送信インフラはSPFを_spf.smtp.mailtrap.liveで公開していますが、これを手動で追加することはありません。Domain VerificationのCNAMEが自動的にそこへ委任します。

4つのCNAMEと1つのTXTです。Domain Verificationレコード、2つのDKIMレコード（rwmt1._domainkeyとrwmt2._domainkey）、Custom Tracking DomainレコードはすべてCNAMEです。TXTレコードはDMARC（_dmarc）だけです。各レコードはMailtrapが示すタイプのままにしてください。CNAMEが必要な箇所にTXTを設定すると確認が完了しません。

2つのDKIM CNAME（rwmt1._domainkey / rwmt2._domainkey）がまだ解決されていないということです。よくある原因は、Cloudflareのプロキシがオンのまま、ホストの重複、DNSの未反映のいずれかです。Mailtrapで両方のCNAMEが緑になれば、メールはd=yourdomain.comで署名され、DKIMのアライメントが一致します。

任意です。省略してもMailtrapはメールを認証して配信します。失われるのはブランド独自の開封／クリック計測で、計測リンクと配信停止リンクは自社ドメインではなくMailtrapの共有ホストを経由します。リンク計測を使い、そのURLをブランドに合わせたい場合に追加してください。実際に認証を支えるのは、Domain Verification、DKIM、DMARCのレコードです。

いいえ。Email Testingは、QA用に架空の受信トレイでメッセージを受け止めるサンドボックスです。実際の受信者には何も届かないので、認証するものも追加するDNSもありません。ドメインの確認（この5つのレコード）が当てはまるのはEmail Sendingだけです。Email TestingでDNSの設定画面が見つからないのは、そのためです。

はい。Mailtrapにたとえばmail.yourdomain.comとしてドメインを追加すると、そのサブドメインを対象に同じレコード一式が生成されます。専用のサブドメインから送信すれば、トランザクション／Mailtrapのレピュテーションをルートドメインの通常のメールから切り離せます。d=mail.yourdomain.comで署名したDKIMは、緩和されたDMARCアライメントで組織ドメインとも一致するので、DMARCに成功します。

通常は数分ですが、DNSの反映には15分から24～48時間を見込んでください。Mailtrapは独自のスケジュールで再チェックします。強制的にチェックするにはRe-check DNS Recordsをクリックします。レコードは反映されたものから順に緑になることがよくあります。Domain Verification、両方のDKIM、DMARCの行がすべて確認済みになるまで待ってから、本番トラフィックにMailtrapを接続してください。

関連記事

SPF・DKIM・DMARCの解説MailtrapのCNAME委任による設定の土台となる、3つのレコードの連携の仕組みを解説します。DMARCの設定手順Mailtrapで入力済みのp=noneポリシーを、監視からquarantine、rejectへと正しく進める方法を解説します。DMARCレポートの読み方ポリシーを引き上げる前に、ruaの集計レポートを読み解き、Mailtrapが認証されてアライメントが一致していることを確認します。GoogleとYahooの送信者ガイドラインドメインの確認を必須にしている、2024年以降の大量送信者向けルール（SPF、DKIM、DMARC、アライメント）です。ドメイン診断Domain VerificationのCNAME、両方のDKIMセレクター、トラッキング、DMARCがすべて解決され、ルートドメインのSPFが10回のルックアップ以内に収まっていることを確認します。DMARCレポート解析集計レポートをドロップして、Mailtrapがアライメントが一致して成功している送信元として表示されることを確認します。

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

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

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

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

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

検証を始める