Mailtrap SPF and DKIM setup

What you are setting up

Mailtrap Email Sending (the production product, not the Email Sandbox) sends your transactional and bulk mail through Mailtrap's servers. You authenticate a sending domain by publishing the records on its Domain Verification page: four CNAME records and one DMARC TXT record. There is no SPF value to paste, which surprises people who have set up other ESPs. Mailtrap says the SPF check is covered by the domain verification record, so the CNAMEs are the whole job.

Publish SPF and DKIM

In Mailtrap, open Domains in the left navigation, click Add Domain, and enter the domain you send from. The Domain Verification page then lists the records under Type, Name, and Value. Copy each one into your DNS host:

Type:  CNAME   (Domain Verification)
Host:  the name Mailtrap shows you
Value: the target Mailtrap shows you

Type:  CNAME   (DKIM 1)
Host:  rwmt1._domainkey
Value: rwmt1.dkim.mailtrap.io

Type:  CNAME   (DKIM 2)
Host:  rwmt2._domainkey
Value: rwmt2.dkim.mailtrap.io

Type:  CNAME   (Domain Tracking)
Host:  mt-link
Value: the target Mailtrap shows you

The two DKIM records are CNAMEs, not TXT keys. They delegate the selectors rwmt1 and rwmt2 to Mailtrap, which hosts the public keys and rotates them for you. Because the selectors live under your domain, the signature carries d=yourdomain.com and aligns for DMARC. Some DNS hosts want the full name; if so, enter rwmt1._domainkey.yourdomain.com and rwmt2._domainkey.yourdomain.com. Leave TTL at the default Mailtrap shows.

Back in Mailtrap, click Re-check DNS Records (it also checks hourly on its own). Each record moves from Missing to Verified, then the domain goes through Mailtrap's compliance check before it can send. If your Domain Verification page shows an SPF TXT record as well, its value is v=spf1 include:_spf.mailtrap.io ~all; merge that include into your existing SPF record rather than adding a second one.

Add DMARC

Mailtrap lists a DMARC record on the same page, with the value v=DMARC1; p=none;. That is a valid starting point, but it has no reporting address, so you would never see the aggregate reports. Publish this instead:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Mailtrap checks only that a DMARC record exists, so the extra tag does not affect verification. Build it with our DMARC builder and progress past p=none once your reports are clean.

The Mailtrap gotcha

Do not go hunting for an SPF include. Every other ESP guide starts with one, so people add a guessed include: or paste a stale value from a blog post, and then wonder why the Domain Verification page still shows a red dot. Mailtrap covers SPF through the verification CNAME; the only SPF text you should ever publish for it is the one the console shows you. Two smaller traps: on Cloudflare, turn the orange proxy cloud off on all four CNAMEs, since a proxied CNAME resolves to Cloudflare's addresses instead of Mailtrap's and never verifies. And if your domain has CAA records, they must allow Let's Encrypt and Google Trust Services, or Mailtrap cannot issue the certificate for mt-link.yourdomain.com and click tracking on your own domain gets blocked. That last one affects tracking links only; SPF, DKIM, and DMARC are unaffected.

Confirm it worked

• Check the status in Mailtrap. Every record on the Domain Verification page should read Verified, and the domain should carry the Verified badge after the compliance check.
• Send a test and read the headers. Send through Mailtrap, open the message, and confirm the DKIM signature shows d=yourdomain.com with s=rwmt1 or s=rwmt2, and dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports. Mailtrap should appear as an aligned, passing source in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.