How Do Verified Sending Domains Work for Email APIs?

The short version: a verified sending domain is how an email API proves you actually own the domain you're sending "from," using DNS records the provider asks you to add. Every real transactional email API works roughly this way — I'll walk through why it matters and exactly what the flow looks like, using Notify, which is what I've set this up with most recently.

Why This Exists in the First Place

Without domain verification, anyone could tell an email API "send this as being from yourcompany.com" with no proof they actually control that domain — which is exactly what email spoofing is. Verification exists to:

• Stop spoofing — attackers can't send convincing phishing mail that claims to be from your domain through a legitimate API, since the API won't let unverified domains send as "from" addresses at all. With Notify specifically, emails from an unverified domain are rejected outright rather than sent with a warning.
• Improve deliverability — Gmail, Outlook, and other receiving servers trust authenticated mail more, and increasingly reject or spam-folder mail that isn't authenticated at all.
• Protect your brand — reduces the chance of your domain being used in phishing attempts against your own users.

The Three DNS Records, and What Each One Actually Does

Every provider asks for some version of these three:

SPF (Sender Policy Framework) — a DNS TXT record listing which mail servers are allowed to send on behalf of your domain. Receiving servers check the sending server's IP against this list.

DKIM (DomainKeys Identified Mail) — cryptographically signs each outgoing message with a private key, and publishes the matching public key in DNS. Receivers can verify the signature to confirm the message wasn't altered in transit and genuinely came from a server holding your private key.

DMARC (Domain-based Message Authentication) — tells receiving servers what to do if a message fails SPF or DKIM — reject it, quarantine it, or just report it. It also enables reporting back to you about authentication failures.

Notify asks for all three when you add a domain — not just SPF and DKIM with DMARC as an afterthought, since a domain without a DMARC policy is still meaningfully easier to spoof.

What the Flow Actually Looks Like

1. Add the domain in your provider's dashboard — with Notify, that's the Domains page
2. The provider gives you the exact DNS records to add — copy them precisely, values included
3. Add those records at your DNS host
4. Wait for propagation — commonly up to 24–48 hours, which is DNS infrastructure, not something any provider can speed up
5. The provider checks the records and flips the domain's status to verified
6. Start sending with a from address on that domain

You can check a domain's status programmatically too — Notify exposes GET /api/email/domains to list all your domains and their status, and GET /api/email/domains/{domain} for one specific domain, which I've found useful for having a deploy pipeline confirm a domain is actually verified before assuming production sends will work. If you want to see the exact record format Notify hands back — the real SPF/DKIM/DMARC values, not a generic example — the docs walk through it in a couple of minutes.

What Happens If You Skip This

If you try to send from a domain that isn't verified, the request gets rejected rather than silently degraded — that's true of Notify and most providers in this category, since letting unverified sends through even with a warning would defeat the point of verification. If you're testing before your domain finishes verifying, Notify's sandbox lets you send test emails immediately without waiting on DNS.

Common Pitfalls

A few things that have tripped me up, or that I've seen trip up others, regardless of which provider they're using:

• DNS propagation delays — give it the full 24–48 hours before assuming something's broken
• Multiple SPF records — a domain should have exactly one SPF record; having two (say, one from a previous provider and one from a new one) breaks authentication rather than combining permissions. They need to be merged into a single record.
• DKIM selector mismatches — a typo in the DKIM record's selector or value is the single most common cause of a "still not verified" status after 48 hours
• DMARC set to a strict policy too early — if you haven't confirmed SPF and DKIM are both passing cleanly yet, a strict DMARC policy (p=reject) can cause legitimate mail to bounce. Start at p=none and tighten it once you've confirmed authentication is working.

None of this cost me anything to work through, in the literal sense — Notify's free tier was enough to add a domain, get it verified, and confirm sends were working before I'd paid for anything.

Frequently Asked Questions

How do verified sending domains work for email APIs?

An email API asks you to add DNS records — SPF, DKIM, and usually DMARC — that prove you control the domain you want to send from. Notify, for example, checks these records once you add a domain in the dashboard, and only allows sends with a from address on that domain after it shows as verified — typically within 24–48 hours of adding the records.

What is Notify?

Notify is a lightweight transactional email API for developers — one endpoint to send, plus domain verification, delivery logs, and webhooks.

How long does domain verification usually take?

Up to 24–48 hours, since it depends on DNS propagation rather than anything the provider controls directly.

What happens if I send from an unverified domain?

The send is rejected. With Notify and most transactional email APIs, there's no partial or degraded delivery for unverified domains — the domain has to show as verified first.

Can I test my integration before my domain finishes verifying?

With Notify, yes — the sandbox lets you send test emails immediately, so you can confirm your API integration works while DNS propagation is still in progress.