How to Verify a Domain for Transactional Email Sending

Verify a domain for email sending before you send production messages. Domain verification proves you control the domain, while SPF, DKIM, and DMARC establish the authentication and policy signals mailbox providers use to evaluate mail that claims to be from it.

For a transactional email application, this work is not a one-time dashboard task. It is a DNS change, an authentication deployment, a testing exercise, and an ongoing operational responsibility. Whether you deliver through an email API, an SMTP relay, your own mail transfer agent, or a combination of platforms, the underlying model is the same: publish the exact records your sending service needs, wait for public DNS to reflect them, then send a real message and inspect the result.

What domain verification means for email

The phrase “verify a domain” is often used to describe several related but distinct jobs. Keeping them separate prevents a common mistake: seeing a green “verified” status in a sending provider and assuming every message will authenticate and reach the inbox.

Ownership verification

A transactional email provider needs evidence that you control example.com before it lets you send mail using addresses such as receipts@example.com or alerts@example.com. The provider usually gives you a DNS challenge record, most commonly a TXT record or CNAME record.

A generic TXT ownership challenge can look like this:

Host: _provider-verification.example.com
Type: TXT
Value: provider-verification=8c2b9f1a4d7e
TTL: 3600

The host name and value above are examples only. Do not substitute them for values generated by your provider. A verification token is intentionally unique to an account, domain, region, or sending configuration.

Once the provider can resolve the expected record from public DNS, it can mark the domain as controlled by you. This reduces the chance that an unrelated user can impersonate your domain through that provider.

Sending authentication

Ownership alone does not prove that a particular email was authorized or signed. Email authentication is handled by DNS records and message-level signatures:

• SPF authorizes sending infrastructure for a domain used in the SMTP envelope.
• DKIM lets a receiver validate a cryptographic signature using a public key published in DNS.
• DMARC tells receivers how SPF and DKIM should align with the visible From: domain and publishes a policy for failures.

These records solve different problems. An account can be authorized to use your domain but still send messages that fail DKIM, lack SPF alignment, or fail DMARC.

Delivery is a separate outcome

Passing verification and authentication does not guarantee inbox placement. A receiving server can accept a message with 250 during SMTP delivery and still later place it in spam, quarantine it, or route it to a category such as Promotions. Content, recipient engagement, reputation, complaint rates, sending patterns, and previous domain history all affect delivery.

Treat the process as a chain:

1. Prove ownership.
2. Publish accurate authentication records.
3. Confirm DNS resolves publicly.
4. Confirm outgoing messages actually use those records.
5. Monitor delivery, bounces, complaints, and authentication reports.

Before you verify a sending domain

Start with the right domain and a clear picture of who already sends mail on its behalf. DNS errors often happen because a developer adds records without knowing that Google Workspace, Microsoft 365, a help desk, an ecommerce system, or another email platform is already using the same domain.

Choose the domain used in the visible From address

If customers see mail from billing@example.com, verify and authenticate example.com. If they see mail from receipt@mail.example.com, you may instead verify and authenticate mail.example.com.

A subdomain is often a sensible choice for automated traffic:

• notify.example.com for product notifications
• mail.example.com for receipts and account events
• updates.example.com for opted-in lifecycle mail
• status.example.com for incident notices

Subdomains create useful separation. They can isolate sending streams, make DMARC reporting easier to interpret, and reduce the chance that an operational change for application email interferes with employee mail on the organizational domain. They do not eliminate the need for sound sending practices.

Inventory every sending system

Make a small inventory before editing SPF or rotating DKIM keys. Include the system, envelope sender domain, visible From domain, DKIM signing domain, and record it needs.

The purpose is not to use every mechanism for every vendor. It is to avoid deleting existing authorization while adding a new sender.

Confirm who can edit authoritative DNS

DNS records must be created at the authoritative DNS provider for the domain, not necessarily where the domain was registered. A domain may be registered with one company, use a CDN or DNS provider for its nameservers, and have a separate email service.

You can identify the current nameservers with:

dig NS example.com +short

If this returns names such as ada.ns.cloudflare.com, the DNS zone is likely managed through Cloudflare rather than the domain registrar. Make changes in the service that hosts the authoritative zone.

Add the provider’s domain ownership record

After adding a domain in an email platform, copy the generated record exactly. Providers may use a TXT challenge, a CNAME that points to a verification service, or a set of records that includes verification and DKIM at the same time.

TXT verification record anatomy

A DNS control panel typically asks for four fields:

• Type: TXT
• Name, Host, or Label: the record name relative to your domain
• Content, Value, or Target: the verification string
• TTL: cache lifetime, often in seconds

Suppose the provider supplies this full record name:

volanea-verification.example.com

In a DNS zone already scoped to example.com, most dashboards expect only:

volanea-verification

Some DNS interfaces accept the full name, while others append the zone automatically. Entering volanea-verification.example.com into an interface that automatically appends the zone can accidentally publish this incorrect name:

volanea-verification.example.com.example.com

Always inspect the resulting record with an external query rather than relying only on the DNS dashboard preview.

CNAME verification record anatomy

Some systems use CNAME records to verify ownership or delegate a service-specific hostname. An illustrative record looks like this:

Host: verify-8c2b9f.example.com
Type: CNAME
Target: verify-8c2b9f.provider-validation.example
TTL: 3600

CNAMEs have a key constraint: a hostname with a CNAME generally cannot also have other ordinary DNS records, such as TXT, MX, or A records. Avoid trying to place a CNAME at your root domain (example.com) unless you understand the DNS provider’s special flattening behavior and its limitations. Email providers normally request CNAMEs at a unique subdomain for this reason.

Do not alter generated values

Do not add quotation marks unless the DNS interface adds them automatically. Do not remove semicolons from TXT record values. Do not split, concatenate, lowercase, or “clean up” a verification token or DKIM public key.

DNS tools may display a long TXT value as several quoted strings. That does not necessarily mean the record is broken: DNS represents TXT data in character strings, and resolver output can show those chunks separately. What matters is that the published value reassembles exactly to the value the provider supplied.

Configure SPF without creating conflicting records

SPF is a TXT record that begins with v=spf1. It authorizes servers for an SMTP identity—normally the envelope sender domain in MAIL FROM, or, when that is absent, the HELO/EHLO identity. SPF does not directly authenticate the visible From: header recipients see.

A simple example is:

Host: @
Type: TXT
Value: v=spf1 include:spf.example-sender.net -all
TTL: 3600

Here, include:spf.example-sender.net asks a receiving server to evaluate the sender service’s SPF policy, while -all means servers not authorized by the preceding mechanisms should fail.

Publish one SPF policy per hostname

The most important SPF rule is simple: publish one SPF record for a given hostname. Do not create separate records like these:

example.com TXT "v=spf1 include:_spf.google.com ~all"
example.com TXT "v=spf1 include:spf.example-sender.net ~all"

Multiple records beginning with v=spf1 can produce an SPF permerror. Instead, merge legitimate mechanisms into one policy:

example.com TXT "v=spf1 include:_spf.google.com include:spf.example-sender.net ~all"

Use only includes that correspond to systems you actually operate. An old include can authorize a former provider to send for your domain, so remove it only after confirming it is no longer needed.

Understand SPF qualifiers

The final all mechanism declares the default result for anything that did not match earlier authorization.

• -all means fail.
• ~all means soft fail.
• ?all means neutral.
• +all means pass and is almost never appropriate for a production sending domain.

A strict record is not automatically better. Move to -all only after your inventory is complete and authenticated sending works from every legitimate source. A soft fail can be a temporary migration state, but it is not a replacement for proper authorization and DMARC.

Stay below SPF’s DNS lookup limit

SPF evaluation has a limit of 10 DNS-querying mechanisms and modifiers. Nested include directives count as their referenced policies are evaluated. A record can look short yet exceed the limit because each provider’s include expands into more lookups.

For example, this can become fragile over time:

v=spf1 include:_spf.google.com include:spf.crm.example include:spf.helpdesk.example include:spf.email.example ~all

Audit the fully expanded policy with an SPF checker before deployment. If you exceed the limit, remove unused senders, move a particular service to a dedicated subdomain, or work with the relevant provider on an appropriate design. Do not “flatten” SPF blindly into IP addresses unless you can maintain changes safely; provider IP ranges can change.

Configure DKIM signing and DNS records

DKIM is usually the most important authentication layer for transactional email because it applies a cryptographic signature to the message. The sending service holds a private key; receivers obtain its public counterpart from DNS and use it to verify the signature.

A receiver uses the d= domain and s= selector in a DKIM-Signature header to query a name in this format:

selector._domainkey.example.com

For example, a message signed with d=example.com and s=tx2026 prompts a lookup of:

tx2026._domainkey.example.com

DKIM TXT record example

Some systems ask you to publish a TXT record directly:

Host: tx2026._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArExamplePublicKeyOnly...
TTL: 3600

The p= value is a public key and commonly makes the record long. Copy it in full. Do not use the example key above; generate or obtain a valid key from your sending system.

DKIM CNAME record example

Other providers use CNAME delegation, often with one or more selectors:

Host: s1._domainkey.example.com
Type: CNAME
Target: s1.example-com.dkim.provider-mail.example
TTL: 3600

CNAME-based DKIM lets a provider publish and rotate the underlying public key without asking you to change DNS for every rotation. The required hostnames and targets vary by provider, so publish the exact records supplied by the service.

Use the signature to verify reality

A record existing in DNS is only half of DKIM setup. Send a message to a mailbox you control, open the raw source or “show original” view, and locate the DKIM-Signature header.

Look for values similar to:

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=tx2026; ...

Then inspect the receiving mailbox’s authentication result. A successful result generally says dkim=pass. If it says dkim=fail, compare the selector in the message (s=) with the hostname you published. If the sender signs as a provider-owned domain rather than your domain, the provider may not have finished applying your verified domain configuration.

Use a selector that identifies the sending system or rotation period, such as transactional1, api2026, or s1. Multiple selectors can coexist, which supports key rotation without breaking messages that were signed with an older selector.

Add DMARC and understand alignment

DMARC connects authentication results to the visible From: domain. Its core benefit is alignment: passing SPF or DKIM is useful for DMARC only when the authenticated domain aligns with the domain recipients see in the From: header.

Publish DMARC as a TXT record at _dmarc:

Host: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=r; pct=100
TTL: 3600

This starts in monitoring mode. It asks receivers to send aggregate reports to the rua address while taking no requested enforcement action for failed messages.

Start with monitoring, then enforce deliberately

A sensible rollout is:

1. Publish p=none and collect reports.
2. Identify every legitimate sending source and fix authentication or alignment failures.
3. Change to p=quarantine when the data is consistently clean.
4. Move to p=reject when you are confident unauthorized mail should be rejected.

An example enforcement record is:

_dmarc.example.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

The pct=25 tag requests policy application to a subset of failing mail, which can help stage a migration. Strict alignment (adkim=s and aspf=s) requires exact domain matches. Relaxed alignment (r) permits aligned subdomains in many cases. Start relaxed unless your domain architecture and reporting demonstrate that strict alignment is safe.

Why SPF can pass but DMARC can fail

Suppose your visible header is:

From: Example App <receipts@example.com>

But the SMTP envelope sender is:

bounce@mailer.provider-example.net

SPF may pass for provider-example.net, yet it is not aligned with example.com. If DKIM signs with d=example.com, DMARC can still pass through aligned DKIM. If DKIM also signs only with provider-example.net, DMARC will fail.

This is why custom return-path domains, branded tracking domains, and provider domain verification are often part of a complete sending-domain setup. They are not cosmetic DNS changes; they can affect alignment and diagnostics.

Check DNS from outside your provider dashboard

DNS propagation is not magic and it is not always instant. A resolver can retain an older answer until the previous TTL expires. New records can appear quickly, but a cautious production change should account for caching, DNS provider behavior, and accidental record-name errors.

Query TXT records with dig

On macOS and Linux, use dig:

dig +short TXT _provider-verification.example.com
dig +short TXT example.com
dig +short TXT tx2026._domainkey.example.com
dig +short TXT _dmarc.example.com

For a CNAME:

dig +short CNAME s1._domainkey.example.com

On Windows PowerShell, use:

Resolve-DnsName -Type TXT _dmarc.example.com
Resolve-DnsName -Type CNAME s1._domainkey.example.com

Compare output character-for-character with the values your provider requested. Remember that dig may display a TXT value in separate quoted segments; check the combined content.

Query an authoritative nameserver when needed

If public resolvers disagree or a change seems delayed, query the authoritative server directly. First retrieve nameservers:

dig NS example.com +short

Then query one of them:

dig @ada.ns.cloudflare.com TXT _dmarc.example.com +short

If the authoritative server has the correct record but public recursive resolvers do not, the likely issue is caching. If the authoritative server does not have it, you edited the wrong DNS zone, the record was not saved, or the name was entered incorrectly.

MXToolbox can help inspect public DNS, SPF, DKIM, DMARC, MX, blacklist, and SMTP-related signals. It is useful as a second opinion, but command-line checks give you a direct and repeatable way to document production configuration.

Send a real authentication test

The best verification test is a message sent through the exact path your application will use. A dashboard’s DNS check proves discoverability; it does not prove that your API integration or SMTP relay selects the right sender identity.

Test both API and SMTP paths

If your service supports both REST API sending and SMTP relay, test whichever paths your application uses. They can have separate credentials, message construction libraries, sender restrictions, or configuration defaults.

For an HTTP API, log the request ID and provider response. A successful HTTP response such as 200 OK or 202 Accepted usually means the provider accepted the request for processing; it does not mean a mailbox provider delivered the message to the inbox.

For SMTP, preserve the server response and queue identifier where available. Typical reply classes include:

• 250 — the remote SMTP server accepted the command or message.
• 421 — a temporary service or connection issue; retry according to your queue policy.
• 450, 451, or 452 — temporary recipient, server, or resource issue.
• 550 — a permanent rejection, often a nonexistent recipient or rejected policy condition.
• 554 — a transaction failure, often related to content, policy, or reputation.

A 250 after DATA is evidence that the receiving server accepted responsibility for the message. It is not proof that a human saw it, that it avoided spam, or that a later system did not generate a bounce.

Inspect headers, not just the inbox view

Send to at least two mailbox providers you control. In the full message headers, look for an Authentication-Results field resembling:

Authentication-Results: mx.google.com;
       spf=pass smtp.mailfrom=bounce.example.com;
       dkim=pass header.d=example.com;
       dmarc=pass header.from=example.com

The exact presentation differs by mailbox provider. The goal is clear:

• SPF should pass for the appropriate envelope domain.
• DKIM should pass using your expected signing domain and selector.
• DMARC should pass for your visible From domain.

Use mail-tester.com for an additional end-to-end check. It provides a generated test address and evaluates message construction, authentication, and some mail-server configuration signals. It is a diagnostic tool, not a guarantee of real-world inbox placement, but it can expose missing authentication or malformed messages quickly.

Troubleshoot common domain verification failures

Most failures are predictable. Work from DNS visibility toward message authentication instead of making random record edits.

The provider cannot find the verification record

Check these conditions in order:

1. The record type matches: TXT versus CNAME matters.
2. The published hostname is correct and does not have the domain duplicated.
3. The value or CNAME target exactly matches the generated requirement.
4. You edited the authoritative DNS zone.
5. The record is publicly resolvable with dig or Resolve-DnsName.
6. You allowed time for cached records to expire.

Do not delete and recreate records repeatedly while waiting. Each change can complicate diagnosis and introduce a fresh cache window.

DKIM says “record not found”

Compare the selector in the message’s DKIM-Signature header to the DNS hostname. If the header says s=s1; d=example.com, the lookup must be s1._domainkey.example.com.

Also check whether you accidentally made a TXT record where the provider required a CNAME, whether a DNS UI appended the zone twice, and whether the provider is still signing with an old default domain. A sender can have valid DNS records for one selector while messages use another selector entirely.

SPF returns permerror or fails unexpectedly

First, look for more than one v=spf1 TXT record. Then count DNS-querying mechanisms across nested includes and examine the actual envelope sender domain rather than only the visible From address.

Do not add a, mx, or broad IP ranges “just in case.” Every authorization decision should map to a known sending system. Overly permissive SPF increases the number of systems that can claim your domain.

DMARC fails while SPF and DKIM appear to pass

This is usually alignment. Read the domains in the results, not only the pass/fail words. A passing SPF result for a provider’s domain does not align with your From domain, and a passing DKIM signature from a provider domain may not align either.

Configure the provider to use your verified sending domain for DKIM when supported. If it supports a custom return-path or MAIL FROM domain, evaluate that setting as part of SPF alignment too.

Operational practices after verification

Domain verification should become part of your release and incident process. Treat DNS records and email identity settings as production infrastructure.

Keep a source-of-truth record

Document each record with its purpose, owner, related service, creation date, and rotation process. Keep the original provider instructions in a secure internal system, but do not store API keys or SMTP passwords in a public DNS document.

A useful change record answers:

• Which application sends using this domain or subdomain?
• Which service owns this DKIM selector?
• Is the SPF include still active and necessary?
• Who receives DMARC aggregate reports?
• What must be changed before a provider account is removed?

Rotate credentials and keys safely

SMTP credentials and API keys should be treated as secrets. Store them in a secret manager, use separate keys by environment where practical, limit their scopes if the provider supports it, and revoke keys that are no longer needed.

For DKIM rotation, publish the new selector first, configure sending to use it, verify passing signatures, then retire the old key after an appropriate overlap period. Never delete an old selector before you have confirmed the new signer is active.

Watch for unauthorized senders

DMARC aggregate reports can reveal mail sources claiming to use your domain, including systems your team forgot about and infrastructure you never authorized. Monitoring matters most after you move from p=none to enforcement, because you want to distinguish a legitimate system that needs repair from an impersonator that should be blocked.

For recipient quality, validate addresses before high-value or sensitive transactional flows when appropriate. A free email address verification tool can help identify obvious syntax, domain, and mailbox-risk issues before you create avoidable bounces. Do not treat verification as permission to email a person; consent and the purpose of the message still matter.

A practical verification checklist

Use this checklist for each production sending domain or subdomain:

1. Select the exact From domain and decide whether a dedicated subdomain is appropriate.
2. Inventory all existing email senders before changing SPF.
3. Add the provider-generated ownership TXT or CNAME record exactly as provided.
4. Add the provider-generated DKIM records, using TXT or CNAME as required.
5. Merge new SPF authorization into the existing single SPF record, if the setup requires SPF for your envelope domain.
6. Publish a DMARC record at _dmarc, beginning with p=none if you do not already have a monitored policy.
7. Validate public DNS using dig, Resolve-DnsName, or a reliable DNS checker.
8. Trigger verification in the email provider only after public DNS matches.
9. Send real messages through the production-like REST API or SMTP relay path.
10. Inspect raw headers for spf=pass, dkim=pass, and dmarc=pass.
11. Test a realistic message with mail-tester.com and investigate authentication failures before increasing volume.
12. Record the configuration, monitor DMARC data, and review records whenever a sender is added or removed.

If you are implementing an API or SMTP integration, consult your provider’s email API setup documentation for its exact domain, sender, credential, and message-format requirements. DNS authentication is standardized, but the generated verification names, DKIM selectors, and sender-identity configuration are provider-specific.

Conclusion

To verify a domain for email sending, first prove control with the DNS challenge supplied by your provider. Then configure SPF carefully, publish the required DKIM keys or CNAME delegations, add DMARC for alignment and policy, and validate all of it with real delivered messages.

The durable lesson is that email identity exists in both DNS and the message itself. A correct TXT record is necessary, but an authenticated message using the expected envelope sender, DKIM domain, selector, and visible From domain is the actual proof that your configuration works. Test that end-to-end before relying on the domain for receipts, password resets, alerts, and other critical transactional mail.

FAQ

How long does it take to verify a domain for email sending?

Many DNS changes become visible within minutes, but cached responses can remain until their prior TTL expires. Verify the record from public DNS first; if authoritative DNS is correct but a provider cannot yet see it, wait for resolver caches to refresh rather than repeatedly changing the record.

Do I need SPF, DKIM, and DMARC to send transactional email?

At minimum, configure the authentication required by your provider and mailbox-provider requirements. In practice, use DKIM and DMARC in addition to SPF where your sending architecture supports it. DKIM plus aligned DMARC is especially important when the visible From domain is your brand domain.

Can I have more than one DKIM record?

Yes. A domain can publish multiple DKIM selectors at the same time. This is normal when multiple sending platforms sign on behalf of a domain or when rotating keys. Each selector has its own record under _domainkey.

Can I have more than one SPF record?

No. A hostname should publish only one SPF policy record beginning with v=spf1. Combine all legitimate sending mechanisms into that one record, then test it for lookup-limit and syntax problems.

Why is my domain verified but DMARC failing?

Provider verification only proves that you control DNS for the domain. DMARC can still fail if SPF and DKIM do not pass with a domain aligned to the visible From address, or if your sending service continues to sign with a provider-owned domain instead of your configured domain.