Do I need to add an SPF include for Mailtrap?

No. Mailtrap's Domain Verification CNAME covers the SPF check for your mail — its own documentation says there's no need to add a separate SPF record on your sending domain. Because the return-path sits on your own verified domain, SPF passes and aligns without you publishing any include, and Mailtrap adds zero lookups to your root SPF.

What about include:_spf.mailtrap.io — I've seen it in old guides?

Ignore it: _spf.mailtrap.io returns no SPF record at all, so adding it does nothing but waste one of your 10 SPF lookups. Mailtrap's actual sending infrastructure publishes its SPF at _spf.smtp.mailtrap.live, but you never add that manually — the Domain Verification CNAME delegates to it for you.

Are the records CNAME or TXT?

Four CNAMEs and one TXT. The Domain Verification record, the two DKIM records (rwmt1._domainkey and rwmt2._domainkey), and the Custom Tracking Domain record are all CNAMEs. Only DMARC (_dmarc) is a TXT record. Keep each record the type Mailtrap labels it — a TXT where a CNAME is expected won't verify.

Why is my DKIM signed by mailtrap.io instead of my domain?

That means the two DKIM CNAMEs (rwmt1._domainkey / rwmt2._domainkey) haven't resolved yet — often because the Cloudflare proxy is still on, the host was doubled, or DNS hasn't propagated. Once both CNAMEs are green in Mailtrap, mail is signed as d=yourdomain.com and DKIM aligns.

Do I have to add the Custom Tracking Domain record?

It's optional. Skip it and Mailtrap still authenticates and delivers your mail — you just lose branded open/click tracking, and tracked links plus the unsubscribe link run through a shared Mailtrap host instead of your own domain. Add it if you use link tracking and want those URLs on-brand; the Domain Verification, DKIM, and DMARC records are the ones that actually carry authentication.

Does Mailtrap Email Testing need DNS records too?

No. Email Testing is a sandbox that captures messages in a fake inbox for QA — nothing leaves for real recipients, so there's nothing to authenticate and no DNS to add. Domain verification (these five records) applies only to the Email Sending product. If you can't find a DNS setup screen under Email Testing, that's why.

Can I verify a subdomain instead of my root domain?

Yes — add the domain in Mailtrap as, say, mail.yourdomain.com, and it generates the same record set scoped to that subdomain. Sending from a dedicated subdomain isolates your transactional/Mailtrap reputation from human email on the root, and DKIM signed as d=mail.yourdomain.com still aligns to your organizational domain under relaxed DMARC alignment, so DMARC passes.

How long does verification take?

Usually minutes, but allow 15 minutes to 24–48 hours for DNS to propagate. Mailtrap re-checks on its own schedule; click Re-check DNS Records to force it. Records often go green one at a time as each propagates — wait until the Domain Verification, both DKIM, and DMARC rows are all verified before wiring Mailtrap into live traffic.

SPF setup guide

SPF, DKIM & DMARC for Mailtrap.

Mailtrap authenticates your domain through CNAME-based domain verification, not by having you paste a shared SPF line. In its Email Sending product you add a sending domain, and Mailtrap hands you five DNS records on the Domain Verification page: a Domain Verification CNAME (which also covers SPF/return-path), two DKIM CNAMEs on the rwmt1._domainkey and rwmt2._domainkey selectors, an optional Custom Tracking Domain CNAME for branded open/click tracking, and a DMARC TXT record. Once those resolve, Mailtrap signs and sends as your own domain, DMARC passes on aligned DKIM (and on SPF via your own return-path), and you never have to publish or maintain a raw SPF include. One thing trips people up first: this only applies to Mailtrap Email Sending — the separate Email Testing sandbox catches messages in a fake inbox and needs no DNS at all.

CNAME domain authentication

Your DNSAdd the CNAME / TXT records

MailtrapSigns & sends as your domain

The inboxSPF · DKIM · DMARC pass

Why authenticate Mailtrap?

Verifying your sending domain in Mailtrap is the gate between the inbox and the spam folder — and Mailtrap enforces it before it will send production mail at all. Until a domain is verified, Mailtrap restricts an Email Sending stream to test messages addressed to your own account email; real recipients are blocked. Beyond that, the timing matters: since February 2024 Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and in 2025 Microsoft began enforcing the same bar for Outlook/Hotmail/Live — first routing non-compliant bulk mail to junk, then moving toward outright rejection. Because Mailtrap is a transactional/API sender, an unverified stream means your mail either doesn't go out or goes out weakly attributable to your domain — no aligned DKIM, no DMARC pass, and reputation pooled with Mailtrap's shared infrastructure instead of your own. Completing domain verification fixes all of it at once: the two rwmt DKIM selectors sign as d=yourdomain.com so DKIM aligns, the Domain Verification CNAME puts Mailtrap's return-path on your own domain so SPF passes and aligns too, DMARC passes on both mechanisms, and the sending reputation you build accrues to your domain.

The SPF reality for Mailtrap

Mailtrap is a CNAME-based domain-verification provider, so for your root domain there is NO SPF include to add — and Mailtrap's own docs say so plainly: "The SPF check for your mail is covered by the domain verification record. There is no need to add a separate SPF record on your sending domain." Here's the mechanism. When you verify a sending domain, one of the CNAMEs Mailtrap gives you is the Domain Verification record, which doubles as the return-path/bounce host on your own domain and delegates the SPF lookup into Mailtrap's sending infrastructure. Mailtrap's real, live SPF record lives at _spf.smtp.mailtrap.live (v=spf1 ip4:45.158.83.0/24 ip4:5.181.200.0/24 … ~all) — but you never publish that yourself; the Domain Verification CNAME resolves into it for you. Because that return-path host sits under your own verified domain, SPF both passes and aligns to your organizational domain under relaxed alignment, which is a genuine advantage over pure-DKIM CNAME senders (Mailchimp, Klaviyo) where SPF can never align. Two things to know. First, ignore any old guidance to add include:_spf.mailtrap.io — that hostname does not resolve as an SPF record at all, and even the correct infra host (_spf.smtp.mailtrap.live) is not something you paste onto your root; adding it manually would just burn one of your 10 SPF DNS lookups for nothing. Second, if your DNS is on Google Cloud DNS, its console still offers a legacy "SPF" record type — Mailtrap explicitly tells you to ignore it (it's deprecated) and add the four CNAMEs plus the DMARC TXT as normal. Net effect on your root SPF: Mailtrap adds zero DNS lookups, so it stacks cleanly with Google Workspace, Microsoft 365, or any other sender you already list.

Two ways to set it up

Recommended

Verify a dedicated sending subdomain (e.g. mail.yourdomain.com)

Isolates Mailtrap/transactional reputation from the human email on your root domain, so a sending mistake can't drag down your primary domain.
DKIM signs as d=mail.yourdomain.com and, under relaxed DMARC alignment, still aligns to your organizational domain — so DMARC passes.
The Domain Verification CNAME puts the return-path on the subdomain, so SPF passes and aligns there too.
You still add the four CNAMEs plus one DMARC TXT; your root SPF is untouched, adding zero DNS lookups.

Legacy

Verify the root/organizational domain (yourdomain.com)

Simplest if Mailtrap is your only or primary sender and you want mail visibly from the bare domain.
DKIM and the return-path sit directly on the organizational domain, so alignment is exact rather than relying on relaxed mode.
Reputation is shared with everything else you send from the root — weigh that if Google Workspace or Microsoft 365 human mail lives there too.
Still zero added lookups to your root SPF, since Mailtrap uses the Domain Verification CNAME, not a root include.

Step by step

In Mailtrap

1
Open Email Sending, not Email Testing
Sign in at mailtrap.io and make sure you're in the Email Sending product (the sidebar section for real outbound mail), not Email Testing (the sandbox that captures messages for QA and needs no DNS). Domain verification only exists for Email Sending.
2
Add your sending domain
In the left navigation, go to Sending Domains and click Add Domain. Enter the domain you'll send from (e.g. yourdomain.com, or a subdomain like mail.yourdomain.com if you want to isolate transactional mail). Mailtrap generates the DNS records for that exact name.
3
Open the Domain Verification page
Select the new domain to open its Domain Verification page. You'll see the records to publish, each labeled by purpose: Domain Verification (CNAME), DKIM (two CNAMEs), Custom Tracking / Domain Tracking (CNAME), and DMARC (TXT). Note the Type, Name, and Value columns — the Name and Value are generated for your account.

In your DNS

4
Add the Domain Verification CNAME
Create the Domain Verification record as a CNAME using the exact Name and Value Mailtrap shows. This one record both proves ownership and covers SPF/return-path — it's why you don't publish a separate SPF record. Keep the type as CNAME; don't convert it to TXT or A.
5
Add the two DKIM CNAMEs
Create two CNAME records: Name rwmt1._domainkey → Value rwmt1.dkim.mailtrap.io, and Name rwmt2._domainkey → Value rwmt2.dkim.mailtrap.io (use the exact values from your dashboard). Two selectors let Mailtrap rotate DKIM keys without you touching DNS again. These CNAMEs are what sign your mail as d=yourdomain.com and carry the DMARC pass.
6
Add the Custom Tracking Domain CNAME
Create the tracking CNAME (Mailtrap typically shows a Name like mt-link) pointing to the Value it provides. This serves open/click tracking and unsubscribe links from your own domain instead of a Mailtrap host. It's the one record you can skip if you don't use link tracking, but adding it keeps tracked links on-brand and avoids the shared-domain reputation of a generic Mailtrap tracking host.
7
Add the DMARC TXT record
Create a single TXT record at Name _dmarc with the value Mailtrap shows (a v=DMARC1; p=none; … policy). If your domain already has a _dmarc record, do NOT add a second one — a domain must have exactly one DMARC record; keep your existing one instead.
8
Fix host doubling and disable the Cloudflare proxy
Many registrars auto-append your domain, so enter just the label (rwmt1._domainkey, not rwmt1._domainkey.yourdomain.com) to avoid doubling — though a few panels want the full postfix form, so match what your host expects. On Cloudflare, set every CNAME to DNS only (grey cloud); Cloudflare enables the proxy by default, and an orange-cloud proxied CNAME won't resolve to Mailtrap so verification fails.

Verify

9
Re-check DNS in Mailtrap
Back on the Domain Verification page, click Re-check DNS Records. Mailtrap also auto-checks periodically, so records flip from Missing (red) to Verified (green) as they propagate — usually minutes, but allow 15 minutes to 24–48 hours. Some records verify before others; wait until all are green.
10
Send a test and read the headers
Send a message from an address on the verified domain, open it in Gmail, and choose ⋮ → Show original. Confirm DKIM: PASS signed by yourdomain.com (selector rwmt1 or rwmt2), SPF: PASS, and DMARC: PASS — all aligned to your domain, not to a mailtrap.io host.

Records to add

Mailtrap generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.

Type	Host	Value
CNAME	(Mailtrap-generated verification host)	(per-account target, e.g. under smtp.mailtrap.live)Domain Verification record — illustrative. Mailtrap shows the exact per-account Name and Value on the Domain Verification page. This CNAME also covers SPF/return-path, which is why no separate SPF record is needed.
CNAME	rwmt1._domainkey	rwmt1.dkim.mailtrap.ioDKIM key 1 (auto-rotated). Copy the exact value from your dashboard; some DNS hosts need the postfix form rwmt1._domainkey.yourdomain.com.
CNAME	rwmt2._domainkey	rwmt2.dkim.mailtrap.ioDKIM key 2 — the second selector lets Mailtrap rotate keys. Use the exact target shown in your dashboard.
CNAME	mt-link	(per-account tracking target)Custom Tracking Domain — illustrative host/target. Enables branded open/click tracking and unsubscribe links on your domain. Optional but recommended; the exact Name/Value is shown per-account.
TXT	_dmarc	v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comDMARC policy — one per domain. Mailtrap pre-fills a p=none value; keep just one _dmarc record and tighten to quarantine/reject later.

Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.

The 10-lookup budget

SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Mailtrap's setup costs against that budget.

SPF 10-lookup budget0 used · 10 free

Mailtrap's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.

DKIM

DKIM is handled by two CNAME records — rwmt1._domainkey and rwmt2._domainkey — that Mailtrap generates for your domain, pointing to rwmt1.dkim.mailtrap.io and rwmt2.dkim.mailtrap.io respectively (copy the exact values from the Domain Verification page). Because these are CNAMEs delegated to Mailtrap — not TXT records you paste — Mailtrap holds the private keys and uses the two selectors to rotate the published keys behind them without you ever editing DNS again. There is no DKIM public key to copy and no selector to invent. DKIM is the mechanism that does the heavy lifting for DMARC here: once the CNAMEs resolve, Mailtrap signs outbound mail as d=yourdomain.com, so the signature aligns to your organizational domain and satisfies DMARC on its own — independent of forwarding, which can break SPF. A few practicalities: keep the record type as CNAME (a TXT where a CNAME is expected breaks validation); enter just the label (rwmt1._domainkey) if your panel auto-appends the domain, or the full rwmt1._domainkey.yourdomain.com if it doesn't; and on Cloudflare set both to DNS only (grey cloud) so they resolve to the mailtrap.io targets. You add the two CNAMEs, click Re-check DNS Records, and the DKIM rows turn green.

DMARC

DMARC is a separate policy record on your domain, and Mailtrap includes it in the record set on the Domain Verification page — typically pre-filled as v=DMARC1; p=none; … . Publish it as a TXT record at _dmarc.yourdomain.com. p=none is monitor-only: it changes nothing about delivery while you confirm, from the aggregate (rua) reports, that Mailtrap mail is passing DKIM (and SPF) aligned to your domain. Because Mailtrap gives you both aligned DKIM (the rwmt selectors) and an aligned return-path (the Domain Verification CNAME), a correctly verified domain passes DMARC on both mechanisms — the resilient setup that survives forwarding. Watch the reports for a week or two, make sure every legitimate sender authenticates, then tighten to p=quarantine and eventually p=reject. Two rules: keep exactly one _dmarc record for the whole domain no matter how many senders you use — if you already have one, don't add Mailtrap's second copy, just keep yours — and point rua at a mailbox (or a DMARC report service) you actually monitor, or p=none is doing nothing for you.

Check it actually worked

Don't trust the green "Verified" badge on the Domain Verification page alone — that only confirms the records resolve, not that a real message authenticates. Send yourself a test from an address on the verified domain, open it in Gmail, and choose ⋮ → Show original: you want DKIM: PASS signed by yourdomain.com with selector rwmt1 or rwmt2, SPF: PASS, and DMARC: PASS, all showing your domain rather than a mailtrap.io host. In Mailtrap, use the Re-check DNS Records button to force a check rather than waiting for the periodic poll. You can spot-check the raw records with dig CNAME rwmt1._domainkey.yourdomain.com and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm the Domain Verification CNAME, both DKIM selectors, the tracking CNAME, and the DMARC record all resolve cleanly and your root SPF stays under the 10-lookup limit — and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer, where Mailtrap should show up as an aligned, passing source.

Domain health check DMARC report analyzer

Common gotchas

Coverage
Email Testing vs Email Sending: domain verification only exists for the Email Sending product. The Email Testing sandbox captures messages in a fake inbox for QA and needs no DNS records at all — if you're looking for a DNS setup under Email Testing, you're in the wrong place.
DNS setup
There is no SPF record to add. Mailtrap's Domain Verification CNAME already covers SPF/return-path, so don't paste include:_spf.mailtrap.io (it doesn't resolve) or include:_spf.smtp.mailtrap.live (Mailtrap's internal infra host) onto your root — doing so wastes an SPF lookup and Mailtrap's docs explicitly say a separate SPF record isn't needed.
DNS setup
Cloudflare proxy breaks verification: set every Mailtrap CNAME to DNS only (grey cloud). Cloudflare enables the orange-cloud proxy by default, and a proxied CNAME won't resolve to the mailtrap.io / mailtrap.live targets, so the records never verify.
DNS setup
Host-field doubling: many registrars auto-append your domain, so rwmt1._domainkey can become rwmt1._domainkey.yourdomain.com.yourdomain.com. Enter just the label if the panel adds the domain; conversely a few hosts (some Squarespace-style panels) want the full postfix form — match what your provider expects.
DNS setup
Every record is a CNAME except DMARC (TXT) — don't switch types. On Google Cloud DNS specifically, ignore the console's legacy 'SPF' record type; Mailtrap notes it's deprecated. Add the four CNAMEs and the one DMARC TXT.
Coverage
Until the domain is Verified, Mailtrap only lets an Email Sending stream deliver test messages to your own account email address. Production sends to real recipients stay blocked, so finish verification before you wire Mailtrap into your app's live traffic.
DNS setup
Keep one DMARC and one SPF record. If you also send via Google Workspace, Microsoft 365, SendGrid, etc., don't add a second _dmarc or a second SPF TXT — Mailtrap adds zero to your root SPF, so just keep your existing single records.
Coverage
Verification isn't instant: propagation can take 15 minutes to 24–48 hours, and Mailtrap re-checks on its own schedule. Use Re-check DNS Records to force a check, and expect some records to go green before others.

Build your SPF record

Mailtrap doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.

Sending sources

Search for each platform you send email through and tick it.

Search for your email platform above, or .

This domain's own servers

Authorize the domain itself, if it sends mail directly (not through a platform above).

a — the domain's own A recordmx — the domain's MX hosts

Other senders & IPs

Anything not in the list — another provider's SPF host, or specific IP addresses.

Additional includes

We add the include: prefix — enter the hostname your provider documents.

IPv4 addresses

IPv6 addresses

Policy for everyone else

What receivers should do with mail from any server not listed above (the all mechanism).

-all (fail)Strict — receivers should reject mail from any server not listed.~all (softfail)Recommended default — unlisted senders are accepted but marked suspicious.?all (neutral)No opinion — provides almost no protection; use only while testing.

Your SPF record0/10 DNS lookups

v=spf1 ~all

No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.

Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.

Authentication published? The next step is sending to a clean, verified list.

Verify a list