Publishing your DNS records

Adding a sending domain returns six DNS records. The domain reaches verified once its three DKIM CNAMEs and its MX and SPF pair resolve; the sixth record, DMARC, never gates that status. The records come back in the POST /v1/domains response, or from the domain's page in the dashboard if you added it there.

The six records

For domain mail.acme.com, the response lists:

The three DKIM CNAMEs sign your outgoing mail with Amazon SES's keys. The MX and SPF pair authorize send.mail.acme.com, the MAIL FROM subdomain SES puts on the envelope, and route bounce feedback back to SES. DMARC tells receivers what to do with a message that fails DKIM or SPF. It starts at p=none; because that policy only asks receivers to report failures rather than reject them, so DMARC is advisory: only the DKIM and MAIL FROM records decide whether the domain becomes verified.

Relative names and the double-suffix trap

Most DNS hosts append your zone name to whatever you type in the Name field, which is what makes this one easy to get wrong. Paste the full name Mailfully returned, <token>._domainkey.mail.acme.com, into a host that auto-appends the acme.com zone, and the saved record lands at <token>._domainkey.mail.acme.com.acme.com instead. The DKIM lookup then targets a name that doesn't exist, and verification never completes.

The correct relative value depends on which zone actually holds the record. If your DNS is managed at the acme.com zone, drop the trailing .acme.com. If it's managed at a delegated mail.acme.com zone instead, drop .mail.acme.com as well:

Verify a domain publishes the full names in its record table, but its "DKIM CNAMEs don't resolve" accordion gives the relative form, <token>._domainkey, which is this table's third column, because its worked example manages DNS at the delegated mail.acme.com zone. The provider guides on this site all use the second column, because each one's worked example manages DNS at the parent acme.com zone. Both are correct for their zone; neither is correct for the other. Check which zone your DNS host actually lists the domain under, and use the matching column.

Whichever value you enter, read the record back after saving. If the name your host displays ends in your domain twice, the suffix doubled and the record needs the shorter, relative form instead.

Tracking is a seventh record

If you enable open or click tracking, Mailfully returns one more record to publish: a CNAME at email.mail.acme.com pointing to r.us-east-1.awstrack.me. It carries no DKIM or SPF role and doesn't affect verification either way; it exists only so tracking links resolve on your own domain instead of a shared one. See Verify a domain for how tracking is enabled and how this record is returned.

Verify with dig

These four lookups are provider-independent, so they work no matter which host holds the records and never go stale:

dig +short <token>._domainkey.mail.acme.com CNAME
dig +short send.mail.acme.com MX
dig +short send.mail.acme.com TXT
dig +short _dmarc.mail.acme.com TXT

A correct answer looks like this:

• The DKIM lookup returns <token>.dkim.amazonses.com.
• The MX lookup returns 10 feedback-smtp.us-east-1.amazonses.com.
• The MAIL FROM TXT lookup returns "v=spf1 include:amazonses.com ~all"
• The DMARC TXT lookup returns "v=DMARC1; p=none;"

An empty answer means the record is either missing or hasn't propagated yet; it doesn't distinguish between the two, so re-check the record at your DNS host before assuming it's just slow.

Propagation and TTL

Once published, records usually resolve within minutes, though a long TTL on a replaced record can stretch that to hours. The real budget is the domain's 72-hour verification window, not propagation time; see Verify a domain for how that window and re-verification work.

Provider guides