How do verified sending domains work for email APIs?

Verified sending domains let email APIs (SendGrid, Mailgun, Amazon SES, Postmark, Resend, Bird, Mailtrap, etc.) prove you control the domain in the “From” address. This is required for good deliverability, to remove “via provider.com” branding, to build reputation on your domain, and to meet modern mailbox-provider rules (Gmail, Yahoo, Microsoft, etc.).

Why it matters

Without domain verification/authentication:

• Messages often land in spam or are rejected.
• You may be limited to low daily volumes or the provider’s shared domain.
• Recipients see the provider’s domain instead of yours.
• You risk spoofing accusations and poor sender reputation.

With a verified domain the API can send as you@yourdomain.com (or any address on that domain/subdomain), and receiving servers can cryptographically verify the mail.

Core authentication records

Almost every provider requires some combination of these DNS records:

Record	Type	Purpose
SPF (Sender Policy Framework)	TXT	Lists which servers/IPs are allowed to send mail for the domain. Receivers check the sending IP against this list.
DKIM (DomainKeys Identified Mail)	TXT or CNAME	The provider generates a key pair. It signs each outgoing message with the private key; you publish the public key in DNS. Receivers verify the signature (message integrity + origin).
DMARC	TXT (_dmarc.yourdomain.com)	Policy that tells receivers what to do when SPF/DKIM fail (none / quarantine / reject) and enables reporting. Increasingly required by major providers.
Return-Path / Bounce domain (often a CNAME)	CNAME	Routes bounces and feedback to the provider while keeping alignment with your domain. Some providers use this instead of (or in addition to) an apex SPF record.

Some providers also ask for tracking CNAMEs (opens/clicks) or MX records if they handle inbound mail.

Typical verification flow

1. Add the domain in the provider’s dashboard (or via their API).
2. Provider generates the exact records you need (hostnames + values). Copy them carefully.
3. Publish the records at your DNS host (Cloudflare, Route 53, GoDaddy, Namecheap, etc.).
4. Wait for DNS propagation (usually minutes to a few hours; can take up to 24–48 hours).
5. Provider verifies the records (they poll DNS). Status changes to “verified” / “authenticated.”
6. Start sending from addresses on that domain. Many providers also let you verify individual email addresses as a lighter alternative, but domain verification is preferred.

Once verified you can normally send from any address on the domain (and often subdomains) without further per-address checks.

Variations across providers

• Amazon SES: Verifies domain or individual addresses. Domain verification lets you send from any address/subdomain on it.
• Mailgun / SendGrid / Postmark / Resend / etc.: Similar DNS-based flow; some emphasize CNAMEs for DKIM and return-path so you don’t have to edit your existing apex SPF record.
• Bird and others: Separate “ownership verified” (usually via DKIM) from “ready to send” (DKIM + return-path + DMARC).
• Some allow temporary email-link verification if you can’t change DNS, but full DNS authentication is strongly preferred for production.

Best practices

• Prefer a subdomain (e.g. mail.yourdomain.com or tx.yourdomain.com) for transactional email so reputation stays isolated from your main corporate domain.
• Keep a single SPF record and stay under the 10-DNS-lookup limit (use include: mechanisms).
• Start DMARC at p=none with a reporting address (rua=), monitor reports, then tighten to quarantine or reject.
• After verification, test with tools such as mail-tester.com or by inspecting Authentication-Results headers in Gmail (“Show original”).
• Warm up volume gradually on a new domain; major authentication changes can temporarily affect reputation.
• Monitor ongoing alignment—providers re-check records periodically.

In short: you prove domain ownership and authorize the email API by publishing the DNS records it supplies. Once those records validate, the API can send authenticated mail on your behalf, which is the foundation of reliable deliverability with modern email APIs.