Domain Verification Email: DNS, DKIM, and DMARC for Developers

Block-style ASCII flow from DNS records to a verified sending domain.

If you’re verifying an email-sending domain for outbound mail, you can publish the provider’s verification TXT record or DKIM selector records in DNS. Ensure SPF, DKIM, and DMARC are working before sending at volume. The sequence is the same when you’re wiring up a transactional API, an AI agent mailbox, or a bulk-sending pipeline.

This guide explains how to verify domain email configuration without losing track of the separate ownership and authentication checks. The best email domain verification method is the one documented by your sending provider: copy its exact records, publish them at the expected names, and confirm each result independently.

Here’s a basic DNS checklist for most programmatic setups:

• Verification TXT record: provider-supplied token at @ or a specified subdomain, such as _sendmux-verification.example.com

• DKIM selector record: selector._domainkey.example.com as a CNAME for a provider-hosted key or TXT for a self-published public key

• SPF TXT record: at the provider-specified domain, authorising your sending IPs and providers

• DMARC TXT record: at _dmarc.example.com, with a policy and, when you want aggregate feedback, an rua reporting address

Quick rule of thumb: Use DNS TXT verification if you control the domain's DNS and the provider issues an ownership token. Set up DKIM if the provider requires signing. If the service supports email validation and DNS access is unavailable or restricted, use an emailed domain verification link.

Key Takeaways

To verify an email-sending domain, demonstrate control using the record type your provider specifies, then check DKIM, SPF, and DMARC separately. The complete domain verification process keeps ownership confirmation, message signing, sender authorisation, and policy enforcement separate.

What domain verification email methods should you use?

Domain authentication email has several verification paths. Taking the wrong path wastes time and can leave signing incomplete. DNSimple's DNS records reference gives a practical overview of record types, while your provider's current instructions remain the authority for exact names and values.

Programmatic setups often use DNS TXT verification. The provider gives you a unique value, you publish it as a TXT record, and the provider queries DNS to confirm control of the domain. Depending on the provider, that token may need to stay published, so do not remove it unless the documentation says you can.

DKIM configuration shows that mail can be signed for a domain. A provider may ask you to publish CNAME records pointing to public keys it hosts, or a TXT record containing the public key for a private key you control. A CNAME delegates public-key publication to the provider; BYODKIM keeps the signing key under your control.

Email validation is supported in some products when DNS access is restricted or controlled by a third party. AWS Certificate Manager's email validation sends messages to five common administrative addresses, and each token expires after 72 hours. DNS-validated ACM certificates can renew automatically while the required CNAME remains available; email-validated certificates require owner action at renewal.

Use email validation for domains only when the service explicitly supports it. A standard mailbox workflow that can verify email address ownership is not equivalent to DNS control over an entire sending domain.

How do you publish a DNS TXT verification record?

There are three primary fields in the record: Name/Host, which indicates where it lives; Value, which is the exact verification token; and TTL, which tells resolvers how long they can cache the answer. These are the basic domain verification steps for a TXT challenge.

Common field values

• Name/Host: @ for a zone apex when the provider requests it, or a label such as _provider-verify

• Value: the exact string supplied by the provider, such as provider-verification=abc123xyz

• TTL: use the provider's recommended value or your DNS host's default; a shorter TTL shortens future cache lifetimes but does not purge records already cached under an older TTL

Adding the record in common DNS panels

1. Cloudflare: Open DNS > Records > Add record. Choose TXT, enter the provider-supplied name and content, and select an allowed TTL. Cloudflare's email records guide explains the related DNS records for email.

2. Route 53: Open the hosted zone and create a TXT record at the required name. Route 53 represents each TXT string inside double quotation marks; its console and API documentation show how to split values longer than 255 characters into quoted chunks within one record.

3. GoDaddy: Open the domain's DNS records and add a TXT record. Use @ only when the provider requires the zone apex; for a named challenge, enter the host label in the format GoDaddy expects. Select an available TTL rather than assuming a universal value.

Confirming the record from the command line

dig +short TXT example.com
nslookup -type=TXT example.com

Query the exact record name the provider gave you. If the expected string is absent, either the name or value is wrong, the authoritative nameserver has not been updated, or a recursive resolver still holds a cached answer.

Common mistakes to avoid:

• Appending the root domain to the Name field in a panel that already appends it

• Changing punctuation, spacing, case, or quoting inside the provider-supplied value

• Removing a token that the provider periodically rechecks

• Publishing multiple policy records where a protocol requires one record

Pro Tip: Before hitting Verify in a provider dashboard, check the authoritative nameserver for the exact record directly. A public resolver like 8.8.8.8 can help check recursive visibility, but cached answers can lag behind the authority.

When setting up domain email, record the authoritative answer separately from the provider's status. DNS can be correct even while the provider is waiting for its next check.

How does DKIM work, and what records do you need?

DKIM (DomainKeys Identified Mail) adds a digital signature to outbound messages. Receiving servers retrieve the public key from DNS, verify the signature, and check whether signed parts of the message changed in transit. The lookup name is selector._domainkey.example.com, where the selector identifies the key.

CNAME vs. TXT: which approach applies to you?

Amazon SES and other managed sending platforms may use CNAME records pointing to provider-hosted DKIM public keys. This lets the provider manage those keys without requiring you to replace the DNS name. With a self-published TXT record, you publish the public key and retain the private key.

Self-published TXT records can look like this:

Name:  mail2026._domainkey.example.com
Type:  TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The p= field has the base64-encoded public key. DNS restricts each label to 63 octets and the full wire-format domain name to 255 octets, including the length octets and the terminating root label. A long DKIM key in a TXT record can be divided among several quoted character-strings in one TXT resource record.

Key length and rotation

• 1024-bit RSA keys meet the DKIM interoperability minimum but should not be the default for a new deployment when the provider and DNS host support 2048 bits.

• 2048-bit RSA keys are the recommended choice in current Google Workspace and Salesforce setup guidance, and Amazon SES uses 2048 bits by default for Easy DKIM.

• Rotation: generate the new key pair, publish a new selector, confirm it through DNS, switch the signer, keep the old public key available while old signatures can still be evaluated, and remove it only after that overlap window.

Pro Tip: Rather than assuming a fixed 48-hour wait, base the overlap on the selector's previous TTL and your message transit expectations. Confirm the new selector from an authoritative nameserver before signing with it.

How do SPF and DMARC complete the authentication stack?

SPF, DKIM, and DMARC work together, but test different identifiers. Proofpoint's authentication guide gives a practical overview; the current SPF, DKIM, and DMARC RFCs define the protocol rules. SPF authorises hosts for an envelope domain, DKIM validates a domain signature, and DMARC requires at least one passing result to align with the visible author domain.

SPF record structure

v=spf1 include:_spf.google.com include:amazonses.com ip4:203.0.113.10 ~all

Publish the policy your active senders need. SPF implementations count DNS-querying terms (include, a, mx, ptr, exists, and redirect), including recursive evaluation, and must return permerror when the total exceeds 10. The mechanisms all, ip4, and ip6 do not count toward that limit.

SPF best practices:

• Keep one SPF policy record at each owner name; multiple SPF records at one name produce permerror

• Remove providers you no longer authorise and retain every active sender's required mechanism

• Use a dedicated sending subdomain when you need separate policy and reputation boundaries

• Do not replace provider-managed include: mechanisms with copied IP ranges unless the provider explicitly supports that configuration

DMARC record for monitoring

_dmarc.example.com  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; sp=none; adkim=r; aspf=r"

At p=none, a domain expresses no DMARC-specific handling preference for failing messages and can receive aggregate reports through rua. Current DMARC guidance recommends collecting p=none data for at least one month and then comparing an equally long p=quarantine period before considering p=reject, especially where legitimate mail can pass through intermediaries such as mailing lists.

The alignment trap most teams miss

DMARC passes when SPF or DKIM both passes and aligns with the visible From: domain. Under default relaxed alignment, the authenticated domain and author domain can differ while sharing the same organisational domain. Under strict alignment, they must be identical. SPF and DKIM can therefore pass individually while DMARC still fails if neither passing identifier aligns. For SPF, the relevant authenticated identity is the MAIL FROM domain.

If a third-party sender uses its own return-path, configure DKIM signing with your domain or another supported aligned identity. Do not diagnose alignment using exact string comparison unless the DMARC record requests strict alignment.

How do you verify and test DNS and authentication after publishing?

Publishing records is step one; validating each layer before live traffic is step two. Query the exact ownership, DKIM, SPF, and DMARC names, then inspect a real test message.

dig NS example.com
dig @ns1.example.com TXT example.com
dig @ns1.example.com CNAME mail2026._domainkey.example.com
dig @ns1.example.com TXT _dmarc.example.com

DNSimple's quick reference lists common email-related DNS records. After sending a test message, inspect the Authentication-Results header in the received message. A passing stack can look like:

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

If dmarc=fail appears despite a passing SPF or DKIM result, use the alignment mode in your DMARC record to compare the authenticated domain with the visible author domain. A domain verification notice in a provider dashboard may summarise these checks, but the DNS answers and received-message header show the underlying state.

Recommended tools: dig and nslookup expose DNS answers directly. Header analysers can make a long Authentication-Results field easier to read, and validators can flag SPF or DMARC syntax mistakes, but verify every recommendation against the applicable RFC and provider documentation.

Why aren't your DNS records showing up yet?

There is no single universal propagation time for DNS updates. Authoritative servers can update quickly, while recursive resolvers continue serving an older answer until its TTL expires. A provider may also check on its own schedule after public DNS is ready.

Stepwise troubleshooting

1. Query an authoritative nameserver directly. Find it with dig NS example.com, then run dig @ns1.example.com TXT example.com. If the record appears there but not through a recursive resolver, inspect the prior TTL and cached answer.

2. Check for duplicate SPF records. Run dig +short TXT example.com and count strings beginning with v=spf1. More than one SPF record at the owner name is a protocol error.

3. Verify the Name field. If a panel appends the zone, entering _dmarc.example.com can create _dmarc.example.com.example.com. Use the format documented by that host.

4. Check for CNAME conflicts. A CNAME owner name cannot coexist with other data. Zone-apex SPF and DMARC therefore use TXT records, not CNAME records.

5. Confirm delegation. Query the domain's NS records and make changes at the DNS host those records identify, not merely at the registrar.

6. Check provider-specific CNAME handling. Keep email-authentication CNAME records DNS-only where a DNS host offers HTTP proxying, and follow the sending provider's exact name/value format.

7. Account for TTL caching. Lowering TTL affects answers cached after the change; it does not shorten the lifetime of an older cached answer.

These checks are important for email domain verification because a green ownership check does not indicate DKIM, SPF, or DMARC are set up correctly. Analyse each signal on its own.

Provider-specific notes for Amazon SES, ACM, Google Workspace, and Salesforce

Each provider has its own domain ownership confirmation and signing workflow. Follow its current primary documentation rather than copying example records from another account.

Amazon SES treats identities as regional resources. To send from a domain in more than one AWS Region, create and verify an identity in each Region, unless you deliberately use the documented Deterministic Easy DKIM replica workflow. Easy DKIM generates three CNAME records. SES uses 2048-bit keys by default, while BYODKIM accepts RSA private keys from 1024 through 2048 bits.

AWS Certificate Manager (ACM) supports DNS and email validation for public certificates. DNS validation uses a CNAME for ownership and ongoing automated renewal when the certificate remains in use and the record remains publicly available. Email validation sends links to five common administrative addresses; its token expires after 72 hours and renewal requires owner action.

Google Workspace separates domain ownership from DKIM signing. First, verify the Workspace domain using the unique google-site-verification= TXT value. Then open Apps > Google Workspace > Gmail > Authenticate email, generate the DKIM record, publish it, and select Start authentication. Google recommends 2048-bit keys when the DNS host supports them.

Salesforce requires email-sending domain verification for each organisation, including sandboxes. An active DKIM key whose domain matches the complete From domain satisfies domain-level verification. Create a primary and alternate selector under DKIM Keys, publish both generated CNAME records, wait until Salesforce sees them, then activate the key. Salesforce uses the alternate selector for automatic rotation.

Original ASCII comparison of the distinct Amazon SES, ACM, Google Workspace, and Salesforce verification flows.

Operational security: key rotation, revocation, and limiting exposure

Verification records and DKIM keys need an operating plan. Keep ownership tokens only as long as the provider requires them, rotate signing keys with overlap, and remove authorisation for providers you stop using.

DKIM key rotation uses two selectors to avoid breaking validation. Publish the new public key first, confirm the authoritative and recursive answers, switch signing to the new selector, and keep the old selector available while previously signed messages may still be evaluated. Remove the old key after the overlap period.

Changing providers requires overlap, not a verification gap. Publish and verify the new provider's required records before removing the old provider. Update the single SPF policy to remove obsolete authorisation and add the new supported mechanism. Retire old DKIM selectors only after the new signing path is confirmed.

Subdomain isolation can separate authorisation and reputation. A third-party sender can use a dedicated subdomain such as mail.example.com or bounce.example.com with its own aligned identifiers and provider records. This makes later revocation more targeted, but it does not remove the need to configure DMARC alignment correctly.

Pro Tip: Start DMARC aggregate-report ingestion while the policy is p=none. The reports help identify authorised and unauthorised sources before enforcement. Protect report data as operational information and use a parser that supports the current aggregate-report format.

Original ASCII sequence showing publish, confirm, switch, observe, and retire steps.

What I actually do before pushing to p=quarantine

I publish the provider records, enable DKIM signing, and collect DMARC aggregate reports at p=none for at least one month. I identify every legitimate sending source, correct failed authentication, and account for forwarding or mailing-list traffic before changing the policy.

Then I use p=quarantine for an equally long comparison period before considering p=reject. I confirm that each legitimate source has at least one aligned passing identifier. DKIM is often the more durable path through forwarding, but a DMARC pass requires only one aligned SPF or DKIM result.

Sendmux handles this domain verification workflow through the Management API. It returns the ownership, SPF, DKIM, DMARC, and bounce-handling records, exposes their verification state, supports an on-demand verification request, and automatically rechecks domains every six hours. A deployment pipeline can query that state before routing live traffic.

Sendmux handles domain verification so you can focus on sending

An SPF DKIM DMARC setup becomes harder when multiple providers, regions, and subdomains are involved. Sendmux centralises custom-domain records and verification status while keeping provider routing and message delivery observable.

Original ASCII view of verified domain records feeding Sendmux sending routes.

For developers building on Sendmux, the current workflow includes:

• Programmatic verification status via REST: the Management API can list domain DNS records and status, then trigger an on-demand ownership, SPF, DKIM, DMARC, and bounce-handling check

• Weighted sending accounts and failover: configured SMTP, Gmail API, Outlook API, and managed Amazon SES accounts expose routing weights and quota windows; the sending path can try another available account when the selected account is unavailable

• Delivery logs and CSV export: the Management API lists message-level logs, and the dashboard exports filtered rows as CSV; Sendmux does not provide DMARC aggregate-report ingestion

SDKs for TypeScript, Python, Go, PHP, Ruby, and Rust cover the public APIs. The domain management documentation explains the verification workflow. A shared @myagent.mx mailbox can be used without custom DNS; move to a verified custom domain when you need branded sending.

If you're comparing email domain verification options, the importance of domain verification is practical: ownership checks prevent unauthorised configuration, while SPF, DKIM, and DMARC give receivers evidence about the messages themselves. Keep the exact provider records and the final verification state in your deployment evidence.

Sources

These references cover record syntax, provider-specific steps, and operational DMARC guidance:

• Email DNS Records Quick Reference - DNSimple Help

• SPF, DKIM and DMARC: Setup Guide | Proofpoint US

• Set up email records · Cloudflare DNS docs

• RFC 7208: Sender Policy Framework

• RFC 6376: DomainKeys Identified Mail

• RFC 9989: Domain-based Message Authentication, Reporting, and Conformance

• Amazon SES DKIM authentication

• AWS Certificate Manager DNS validation

• Google Workspace domain verification

• Google Workspace DKIM setup

• Salesforce DKIM key setup

The term “setting up domain email” may involve several different controls. Preserve each provider-issued value byte-for-byte, and make every email validation for domains decision from that provider's current documentation rather than a generic template.