How to Verify Your Domain for Email Sending

Before any email service — SendGrid, Mailgun, Amazon SES, Postmark, Google Workspace — will send mail *as* your domain, you have to prove you own it and authorise them to send. That's domain verification, and it's all DNS records. This guide explains what each record does and how to get verified without the usual back-and-forth.

Why verification exists

If anyone could send as your domain, spammers would spoof you constantly. Verification proves two things: you control the domain (via a TXT or CNAME the service asks you to add), and you authorise this service to send for you (via SPF and DKIM). Once verified, receivers trust that mail signed by that service really represents your domain. This is the applied version of email DNS explained: SPF, DKIM and DMARC.

The records you'll typically add

Most senders ask for some combination of these:

• A verification TXT (or CNAME): proves ownership, e.g. example.com TXT "sendgrid-verify=abc123" or a CNAME they specify.
• SPF: authorises the service's servers, e.g. include:sendgrid.net in your SPF record.
• DKIM: one or more CNAME/TXT records publishing the service's signing keys, often at selectors like s1._domainkey and s2._domainkey.
• A custom return-path / bounce domain: a CNAME so bounce handling aligns with your domain (helps DMARC alignment).

Step 1: Add the ownership record

The service gives you an exact record — copy it verbatim. Example (Amazon SES domain verification):

_amazonses.example.com.  TXT  "pmBGN/7MjnfhTKUZ06Enqq1PeGUaOkw8lGhcfwefcHU="

Watch for two things people botch: don't double up the domain (many panels append it to the Host automatically), and paste the value exactly, quotes and all.

Step 2: Add SPF (merge, don't duplicate)

Add the service's include to your single SPF record:

example.com.  TXT  "v=spf1 include:sendgrid.net include:_spf.google.com ~all"

Never publish two separate SPF records — merge every sender into one. Full rules: how to set up SPF, DKIM and DMARC step by step.

Step 3: Add the DKIM records

DKIM is usually one or more CNAMEs pointing at the sender's key host:

s1._domainkey.example.com.  CNAME  s1.domainkey.u123.wl.sendgrid.net.
s2._domainkey.example.com.  CNAME  s2.domainkey.u123.wl.sendgrid.net.

These are CNAMEs, so the sender rotates keys for you without you touching DNS again — a nice benefit of the CNAME approach explained in how to set up a CNAME record. For self-hosted DKIM where you generate the key yourself, see how to set up DKIM on a self-hosted mail server.

Step 4: Click verify, then confirm with dig

Add every record, wait for propagation (minutes usually), then hit Verify in the service dashboard. If it fails, check the records yourself:

dig _amazonses.example.com TXT +short
dig s1._domainkey.example.com CNAME +short
dig example.com TXT +short

The commonest failure is a doubled domain in the host field (s1._domainkey.example.com.example.com). Query help: diagnosing DNS problems with dig and nslookup. Once verified, your sending reputation still depends on the fundamentals — keep an eye on how to stop your emails going to spam.

Set a custom return-path for alignment

Verification gets a service *authorised*; DMARC alignment is what makes big receivers fully trust the mail. Most senders let you set a custom return-path (also called a bounce or MAIL FROM domain) via a CNAME:

bounces.example.com.  CNAME  pm.mtasv.net.

This makes the invisible envelope-sender use *your* subdomain instead of the provider's shared domain, so SPF aligns with your visible From and DMARC passes cleanly. It's optional for basic sending but strongly recommended for anything at volume — it's the difference between "authenticated" and "authenticated *and* aligned." The DMARC side is covered in how to set up SPF, DKIM and DMARC step by step.

Verifying multiple sending services

Real businesses often send through several services at once — a CRM, a marketing tool, a transactional API. Each needs verifying on the same domain, and they coexist fine if you follow two rules:

• Merge all SPF includes into one record. Two v=spf1 records break SPF. Combine them: v=spf1 include:sendgrid.net include:mailgun.org include:_spf.google.com ~all.
• Give each service its own DKIM selector. Because DKIM lives at a unique selector per provider (s1._domainkey, k1._domainkey, google._domainkey), they never collide.

Watch the 10-lookup SPF limit as you add includes; too many and SPF returns permerror.

Re-verification and key rotation

Verification isn't always one-and-done:

• CNAME-based DKIM (as most senders use) rotates keys for you automatically — you never touch DNS again. That's a real advantage of the CNAME approach from how to set up a CNAME record.
• TXT-based keys (common when you self-host — see how to set up DKIM on a self-hosted mail server) you rotate manually by publishing a new selector.
• Some services periodically re-check your records and mark the domain unverified if one goes missing. If a working sender suddenly can't send, re-run the dig checks — a record was probably edited or deleted.

FAQ

How long does domain verification take?

Usually minutes once records propagate, though DNS can take up to a few hours. If it's still failing after that, a record is wrong — verify with dig.

Why does verification keep failing?

Almost always a copy-paste error or a doubled domain in the Host field. Check the record with dig and compare it character-for-character to what the service specified.

Do I need SPF and DKIM, or just the verification record?

The verification record proves ownership; SPF and DKIM are what actually authorise and authenticate your sending. You want all of them for mail to be trusted and delivered.

Can I verify one domain with multiple senders?

Yes. Add each sender's records — SPF includes merged into one record, plus each sender's own DKIM selectors — and every service verifies independently.

What's the difference between verifying a domain and authenticating email?

Verification proves you *control* the domain; authentication proves a specific message is *legitimately from* it — and you need both. Verification is a one-time check where you add a token (a TXT or CNAME the service specifies) so the sender knows you own the domain before letting you send as it. Authentication is ongoing: SPF authorises which servers may send, DKIM cryptographically signs each message, and DMARC ties them together with a policy. A service can verify your ownership yet still have your mail land in spam if SPF and DKIM aren't set up, because receivers judge each message on authentication, not on the initial verification. So complete the verification record to unlock sending, then make sure SPF, DKIM and alignment are all in place for mail that actually reaches inboxes.

Verified sending is the foundation of email that lands. Skip the setup entirely with managed Nxeon business email, or run your own sender on a fast VPS with a clean static IP.