Spark
Sign In
Skill

Add and verify Mailtrap sending domains with DNS records

Add and verify a Mailtrap sending domain via API or DNS-provider UI, with the proxied-DNS caveat that silently breaks SPF/DKIM.

Get skill
Works with mailtrapcloudflareawsroute53google cloud dns
Antigravity
Own this? Claim it

Maintainer of this project? Claim this page to edit the listing.

78
Spark score
out of 100
Updated 26 days ago
Version 13.6.1
Add to Favorites

Why it matters

Configure and verify a custom sending domain in Mailtrap by adding all required DNS records (SPF, DKIM, DMARC) at your DNS provider, troubleshooting propagation issues, and completing compliance steps to enable live email sending.

Outcomes

What it gets done

01

Retrieve DNS record requirements from Mailtrap UI or API for your sending domain

02

Publish SPF, DKIM, and DMARC records at Cloudflare, AWS Route 53, or other DNS providers

03

Troubleshoot DNS propagation delays using dig, nslookup, or verification polling

04

Complete domain compliance workflow after successful DNS verification

Install

Add it to your toolbox

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-mailtrap-setting-up-sending-domain | bash

Overview

Setting up a Mailtrap sending domain

Covers adding and verifying a Mailtrap sending domain via the Sending Domains API or DNS-provider UI, including the proxied-DNS caveat that breaks SPF/DKIM. Use when setting up or debugging Mailtrap domain verification before live sending, not for sandbox-only testing.

What it does

This skill covers adding and verifying a Mailtrap sending domain, required before any live email can go out. Mailtrap's UI or API shows the complete set of DNS records a domain needs - all of them must be added, never cherry-picked - and the hostname added must be the exact one used in the From address: if sending from notifications.mycompany.com, that subdomain is the sending domain, not just the root mycompany.com, unless mail is genuinely sent from the root.

When to use - and when NOT to

Use it for new Sending Domains setup, stuck verification, compliance questions, or DNS configuration at Cloudflare, AWS Route 53, Google Cloud DNS, Squarespace, GoDaddy, Namecheap, or DigitalOcean. It does not apply to sandbox-only testing without a custom domain, which is covered by mailtrap-testing-with-sandbox instead; this skill is the prerequisite step before mailtrap-sending-emails can actually deliver mail.

Inputs and outputs

For scripted or AI-assisted automation, the preferred path is entirely API-driven: GET /sending_domains lists domains, GET /sending_domains/{id} returns each dns_records entry (type, name, value, verification status) plus an overall dns_verified flag to poll after publishing; POST /sending_domains with a domain_name creates a domain programmatically; and the returned records get published at the DNS host via its own API (Cloudflare API, Route 53, Google Cloud DNS) or infrastructure-as-code, matching names and values exactly. All calls need Authorization: Bearer $MAILTRAP_API_TOKEN and an $MAILTRAP_ACCOUNT_ID resolved from GET /api/accounts. The manual fallback is Sending Domains > Add domain > copy each record into the registrar's UI > Verify, using dig/nslookup to confirm a record is publicly visible before re-clicking Verify if it stays pending.

GET /api/accounts/$MAILTRAP_ACCOUNT_ID/sending_domains/{id}
  -> dns_records: [{type, name, value, status}], dns_verified

Integrations

Mailtrap publishes click-path DNS guides for each major provider, to be followed alongside the live record values shown in the UI or API - for unlisted providers, the same rule applies: copy every record into whichever DNS zone serves the From domain. A critical, easy-to-miss caveat: if the DNS provider proxies records (Cloudflare's orange-cloud mode, or similar CDN/proxy modes elsewhere), verification records must stay DNS-only/non-proxied unless Mailtrap explicitly allows proxying, since a proxied CNAME silently breaks SPF/DKIM verification.

Who it's for

Developers and operators setting up or debugging Mailtrap domain verification before enabling live sending, whether automating the whole flow via the Sending Domains API and their DNS provider's API, or walking through the manual UI-plus-registrar path - and anyone whose verification is stuck should check first whether their DNS records are accidentally being proxied.

Source README

Setting up a Mailtrap sending domain

Overview

You must add and verify a domain you control before live sending. Mailtrap shows every DNS record required for that domain in the UI: add the complete set as given (do not cherry-pick). After DNS verifies, complete the compliance step if requested.

Subdomain vs root: add the exact hostname you will use in the From address. If you send from notifications.mycompany.com, add that subdomain as the sending domain-not only mycompany.com, unless you truly send from the root domain.

For step-by-step clicks at common hosts, open the matching guide on Sending domain setup (Cloudflare, Route 53, etc.) and follow it alongside the live UI values.

Related skills: mailtrap-sending-emails (after domain is ready).

When to use

  • New Sending Domains setup, stuck verification, or compliance questions
  • DNS at Cloudflare, AWS, Google, Namecheap, GoDaddy, DigitalOcean, etc.

When not to use

  • Sandbox-only testing without a custom domain (see mailtrap-testing-with-sandbox)

Authorization

The Sending Domains API calls below need Authorization: Bearer $MAILTRAP_API_TOKEN and an $MAILTRAP_ACCOUNT_ID in the path. Resolve $MAILTRAP_ACCOUNT_ID from GET https://mailtrap.io/api/accounts, and store tokens in environment variables or a secrets manager.

Automating setup (API and DNS providers)

Prefer this path when building scripts or AI-assisted automation:

  1. DNS records and status via API - Use the Sending Domains API:
  • GET https://mailtrap.io/api/accounts/$MAILTRAP_ACCOUNT_ID/sending_domains - lists domains
  • GET https://mailtrap.io/api/accounts/$MAILTRAP_ACCOUNT_ID/sending_domains/{sending_domain_id} - returns dns_records (each with type, name, value, and verification status) and dns_verified. Poll after you publish DNS.
  1. Create domain via API -
  • POST https://mailtrap.io/api/accounts/$MAILTRAP_ACCOUNT_ID/sending_domains with domain_name when your flow provisions domains programmatically.
  1. Publish DNS programmatically -
  • Create the returned records at your DNS host using their API (e.g., Cloudflare API, AWS Route 53, Google Cloud DNS) or IaC. Align record names and values exactly with the API response.

Human fallback: Sending Domains > Add domain > copy values into the registrar UI > Verify when API automation is not available.

Workflow (summary)

  1. Sending Domains > Add domain and enter the domain name.
  2. Obtain required records from the UI or Sending Domains API; create all listed records at your DNS host exactly as shown (names, types, values).
  3. Wait for DNS propagation. If verification stays pending, use dig, nslookup, or an online DNS lookup to confirm each record is visible publicly before clicking Verify again.
  4. Complete the compliance flow when prompted.

Product walkthrough: Sending domain setup.

DNS provider guides (documentation)

Mailtrap publishes click-path guides for common providers. Open the page that matches the user's DNS host and follow it together with the live UI records:

If the user's provider is not listed, the same rule applies: copy every record from Mailtrap into the DNS zone that serves the From domain.

Important DNS caveat (proxied DNS)

If your DNS provider proxies records (orange-cloud on Cloudflare, similar CDN/proxy modes elsewhere), verification-related records must be DNS-only (grey cloud / non-proxied) unless Mailtrap documentation explicitly allows proxying-proxied CNAMEs and similar often break SPF/DKIM verification. The same constraint applies to any host that fronts DNS with a proxy.

Limitations

  • DNS and compliance screens can change; always copy the exact current records from Mailtrap before publishing DNS.

FAQ

Common questions

Discussion

Questions & comments · 0

Sign In Sign in to leave a comment.