---
title: "Publishing your DNS records"
description: "The six records Mailfully asks you to publish, what each one does, the naming traps common to every DNS host, and how to verify with dig."
last_reviewed: "2026-09-17"
---

> **For AI agents:** the complete documentation index is at [llms.txt](/docs/llms.txt). Append `.md` to any page URL for its markdown version.

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:

| # | Type | Name | Value | Priority |
|---|---|---|---|---|
| 1-3 | CNAME | `<token>._domainkey.mail.acme.com` | `<token>.dkim.amazonses.com` | n/a |
| 4 | MX | `send.mail.acme.com` | `feedback-smtp.us-east-1.amazonses.com` | 10 |
| 5 | TXT | `send.mail.acme.com` | `v=spf1 include:amazonses.com ~all` | n/a |
| 6 | TXT | `_dmarc.mail.acme.com` | `v=DMARC1; p=none;` | n/a |

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:

| Record | Full name | Relative, zone `acme.com` | Relative, zone `mail.acme.com` |
|---|---|---|---|
| DKIM | `<token>._domainkey.mail.acme.com` | `<token>._domainkey.mail` | `<token>._domainkey` |
| MAIL FROM MX and SPF | `send.mail.acme.com` | `send.mail` | `send` |
| DMARC | `_dmarc.mail.acme.com` | `_dmarc.mail` | `_dmarc` |

[Verify a domain](/guides/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](/guides/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:

```bash
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](/guides/verify-a-domain#verification-statuses) for how that window and re-verification work.

## Provider guides

| Provider | Guide |
|---|---|
| Cloudflare | [DNS in Cloudflare](/dns/cloudflare) |
| GoDaddy | [DNS in GoDaddy](/dns/godaddy) |
| Namecheap | [DNS in Namecheap](/dns/namecheap) |
| Route 53 | [DNS in Route 53](/dns/route53) |
| Vercel | [DNS in Vercel](/dns/vercel) |
| Porkbun | [DNS in Porkbun](/dns/porkbun) |