Publishing your DNS records

Adding a sending domain returns six DNS records. The domain reaches verified once its three DKIM CNAMEs and its MAIL FROM records 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. The MX and SPF pair authorize send.mail.acme.com, the MAIL FROM subdomain on the envelope, and route bounce feedback back to Mailfully. DMARC tells receivers what to do with a message that fails DKIM or SPF. It starts at p=none;, which only asks receivers to report failures.

If your domain or its parent domain already has a DMARC record, keep it and skip this one. A name can have only one DMARC record. The domain page checks DMARC only at the domain's own _dmarc name. With only a parent record, it shows DMARC as Pending, then Not found if checking stops, and shows no status once the domain is verified. None of this affects verification.

Relative names and the double-suffix trap

When you add the domain in the dashboard, Advanced settings has an optional Mail From subdomain field (mail_from_prefix in the API). It defaults to send.

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.

For a root domain, the domain page shows each name both ways (Host / Full name). For a subdomain it shows the full name; enter the part before the zone you manage, as in the table.

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:

Check which zone your DNS host 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 needs no record

Open and click tracking asks nothing of your DNS: turning it on returns an empty records array. If you published an email.mail.acme.com CNAME for tracking in the past, leave it in place, since links in mail you already sent still resolve through it. See Verify a domain for how tracking is turned on.

Receiving adds an MX record

If you turn on receiving for the domain, Mailfully returns one more MX record: mail.acme.com pointing to inbound-smtp.us-east-1.amazonaws.com at priority 10. It sits on the domain name itself, not on send.mail.acme.com, and it does not affect verification. With the acme.com zone its relative name is mail; with a delegated mail.acme.com zone it is @ or blank, depending on the host. Before handing it out, Mailfully refuses to turn receiving on when that name already has another provider's MX; see MX record conflicts.

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

Each answer should match the value on your domain page. For the example domain:

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

An empty answer means the record is missing or hasn't propagated yet. Re-check the record at your DNS host.

Propagation and TTL

Records usually resolve within minutes. A long TTL on a replaced record can stretch that to hours. The domain's 72-hour verification window is described in Verify a domain.

Provider guides