Glossary — SPF, DKIM, bounce and the other abbreviations
Short definitions of the terms you meet across the CloudFly docs, from DNS records such as SPF and DKIM to sending concepts such as webhook and bounce.
The abbreviations you meet while setting up your mail services. Each entry gives you one sentence of definition, one sentence on why it concerns you, and a link to the guide that covers the task.
DNS records
These are lines you add wherever your domain is managed. They do not live in the CloudFly console — the console only shows you the value to publish and checks whether you published it correctly.
MX
The record that says which server receives mail sent to your domain.
Why it matters: this record decides where your incoming mail lands. Changing it changes where the whole domain receives mail, so publishing the MX of a send-only service on your root domain loses every incoming message.
→ Point MX through the filtering gateway
TXT
A record holding a free-form string. SPF, DKIM, DMARC and the ownership record are all TXT records — they differ in name and content, not in type.
Why it matters: having several TXT records on one domain is normal. Do not delete an old TXT record when adding a new one, unless a guide tells you to.
TTL
How long other DNS servers may remember your record before asking again.
Why it matters: the higher the TTL, the longer a record you just edited takes to reach someone far away. Lowering the TTL a day before a planned change shortens the switchover.
SPF
The record listing which servers may send mail on behalf of your domain.
Why it matters: without it, or with an incomplete list, the mail you send is easily filed as spam — even when the system reports a successful send. A domain may have exactly one SPF record; if you use several sending services, merge them into that one line rather than adding a second.
→ Publish the four mail DNS records
DKIM
A digital signature attached to every message you send. The receiver checks it against the public key you publish in DNS.
Why it matters: DKIM proves the message really came from your domain and was not altered on the way. It is also the record that lets the platform sign mail on your behalf — without it the sending service does not work at all, rather than merely looking untrustworthy.
→ Publish the four mail DNS records
DMARC
The record telling receivers what to do with mail that impersonates your domain, and where to send reports.
Why it matters: SPF and DKIM only answer "is this message legitimate". DMARC is where you say "if it is not, reject it". Without it, impersonating your domain is considerably easier.
→ Publish the four mail DNS records
Sending and receiving protocols
SMTP
The protocol used to send mail. Every piece of mail-sending software speaks it.
Why it matters: when software asks you for an "SMTP server", it is asking who to hand outgoing mail to. This is the section you fill in when connecting an existing application to the sending service.
→ Point your software at the relay
IMAP
The protocol a mail application uses to read messages stored on the server.
Why it matters: IMAP keeps messages on the server and syncs their state, so the same mailbox opened on your phone and your laptop looks the same. It is the right choice in almost every case.
→ Set up Outlook and your phone
STARTTLS
A way to upgrade a plain SMTP connection to an encrypted one, right after the connection opens.
Why it matters: this is the encryption used on port 587. Your software has to pick the right kind
for the right port; mismatch it and the connection hangs or gets refused.
→ Point your software at the relay
SMTPS
A connection encrypted from the start, with no upgrade step like STARTTLS.
Why it matters: this is the encryption used on port 465. Some software calls it SSL/TLS to tell
it apart from STARTTLS in the same dropdown.
→ Point your software at the relay
relay
A server that accepts mail from your application and forwards it to the internet on your behalf.
Why it matters: your application does not have to manage sending reputation, suppression lists or message signing — it only has to hand the message to the relay. In exchange the relay requires authentication, so nobody can borrow your domain to send.
→ What Email Relay is and when to use it
Automated sending
API key
The secret string your application sends with every call, in place of a username and password.
Why it matters: the full value is shown only once, when you create it. Copy it straight into your secret store; if you lose it you cannot look it up again, only create a new key.
webhook
A URL of yours that the platform calls whenever something happens — a message delivered, a message bounced, a recipient reporting spam.
Why it matters: without a webhook you only know a message was accepted for sending, not whether it arrived. This is how your system keeps itself up to date instead of polling.
→ Receive events through a webhook
bounce
A message returned by the receiver, undeliverable. A hard bounce means the address does not exist.
Why it matters: repeatedly sending to addresses that do not exist is the clearest signal of a low-quality sending system, and it drags down the reputation of every message on your domain. Hard-bounced addresses go straight onto the suppression list.
→ Read and manage the suppression list
suppression list
Addresses the platform will no longer send to.
Why it matters: mail addressed to anything on this list is dropped before it leaves the platform — you still get an acceptance response, but nobody receives anything. When a message reports "sent successfully" and the recipient says otherwise, check here first.