DNS record reference for the four services

Look up which DNS records each service needs, which record name they go on, and which records can be shared between services.

This page is for looking things up, not for following step by step. Each service has its own guide with the full context and the checks — this page answers one question: which records does this service need.

Always copy values from the console

The tables below show the shape of each record, not your values. The verification token, the DKIM tokens and the destination host differ per domain. Copying another domain's values makes your outgoing mail look forged and your incoming mail get rejected.

Step 1 — the ownership record, shared by every service

All four services use the same record. A domain already verified for one service keeps that record valid for the others — you do not add it again.

Record name	Type	Content
`_cloudfly`	TXT	`cloudfly-verify=<your token>`

See Verify domain ownership for how to get the token and what to do when the record is in place but still reads as missing.

Step 2 — the configuration records, different per service

This is where records get copied wrongly most often. The four services do not share a step 2.

Service	Step 2 records	Touches the root MX?
Email Business	MX · SPF · DKIM · DMARC	Yes — MX points at CloudFly's mail system
Email Security	MX only	Yes — MX points at the filtering system, which forwards to your own server
Email API	3 signing CNAMEs · MX and TXT on the bounce subdomain · TXT `_dmarc`	No
Email Relay	Identical to Email API	No

The two sending services — Email API and Email Relay — leave the root MX alone, so adding them cannot interrupt mail delivery for the domain. The other two do change it.

A domain receives mail through one path only

Email Business and Email Security both claim the root MX, so they cannot serve the same domain at the same time. Email Business hosts mailboxes at CloudFly; Email Security filters mail for your own mail server.

Email Business — four required records

Record name	Type	Content shape
`@`	MX	mail host, priority `10`
`@`	TXT	`v=spf1 a mx ip4:… ~all`
`<token>._domainkey`	TXT	`v=DKIM1; k=rsa; p=…`
`_dmarc`	TXT	`v=DMARC1; p=none; rua=mailto:…`

The part before ._domainkey is a token generated for your domain, not a fixed word.

For the details of each record and how to read its status, see Configure the four DNS records for mail.

Four autodiscovery records — optional

These let Outlook, Thunderbird and phone mail apps find the server settings on their own. Skip them and mail still sends and receives normally; each person just types the host and port manually.

Record name	Type	Used for
`autodiscover`	CNAME	Outlook configuration lookup
`_imaps._tcp`	SRV	Receiving over IMAP, port 993
`_submission._tcp`	SRV	Sending, port 587
`_pop3s._tcp`	SRV	Receiving over POP3, port 995

All four point at smtp.cloudfly.vn.

Email Security — a single record

Record name	Type	Content shape
`@`	MX	filtering host, priority as shown in the console

The setup screen for this service does not show an SPF record. Your outgoing mail still leaves your own mail server, so keep your existing SPF record as it is — do not adapt it from another service's template.

Below the record table the screen also shows a destination routing block naming the server mail is handed back to after filtering. Check that block against your real mail server before you change the MX.

Email API and Email Relay — one shared set

Both services use the same records because they prove the same thing: this domain is allowed to send mail through CloudFly.

Record name	Type	Used to
`<token 1>._domainkey`	CNAME	Sign mail with DKIM
`<token 2>._domainkey`	CNAME	Sign mail with DKIM
`<token 3>._domainkey`	CNAME	Sign mail with DKIM
`bounces`	MX	Receive delivery failure reports (bounce)
`bounces`	TXT	SPF for the bounce subdomain
`_dmarc`	TXT	Policy for when SPF or DKIM fails

The three DKIM records are three separate records, not three lines of one record. With any of them missing, the domain never becomes active.

bounces is a subdomain reserved for delivery reports, for example bounces.example.com. It is not a sender address — your From address stays on the root domain.

Already using Email API on this domain? Do not add the set again for Relay

Both services share the bounces subdomain. If the domain is already active on one service, the same record set works for the other — overwriting it with a second set breaks both.

Where this usually goes wrong

Symptom	Common cause
Record is in place but still reads (not found)	The old record's TTL has not expired, or the record was added at a DNS provider that no longer serves the domain
Mail lands in spam although the console reports it sent	SPF or DKIM missing — neither blocks sending, they only make the receiver suspicious
Every outgoing message is flagged as forged	The domain has two SPF records, which invalidates both
The record name ends up doubled	Some DNS providers append the domain automatically; enter `_cloudfly`, not `_cloudfly.example.com`

Leave TTL at its default. Lowering it does not make a new record take effect any sooner for resolvers that already cached the old one.