Mail that reaches the inbox, not the spam folder.
A receiving server asks three questions about every message before it decides where to put it. All three are answered by DNS records on your domain. Here is what they are, what is set up for you on every email product we sell, and the part that stays yours.
Three records
SPF, DKIM and DMARC
Generated for you
On your service page
Published in-account
TXT, MX and CNAME editor
Every platform
Business Email, Titan, Google
The three questions
What a receiving server checks before it trusts you.
None of this is exotic. Every large mail provider runs these checks on every message, and a domain that answers none of them is treated as a stranger.
SPF — who may send as you
One TXT record on the domain listing the servers allowed to send mail from it. A message from anywhere else fails the check. A domain may carry only one SPF record, so every service that sends for you belongs inside the same one.
DKIM — was it changed in transit
Your mail server signs each message with a private key; a TXT record on your domain publishes the public half. The receiver verifies the signature, which proves the message left your platform and arrived untouched.
DMARC — what to do when they fail
A TXT record at _dmarc that tells receivers how to treat mail failing SPF and DKIM — observe it, quarantine it or reject it — and where to send the reports. It is the policy that turns the other two into protection against people forging your address.
What is done for you
The records are generated. Publishing them is one step.
On every email product here the platform produces the exact records your domain needs. They are shown on the service page in your account, and the DNS editor next to it takes them as they are.
- 01 Records generated at setup When a mailbox service is created, the platform generates its MX, SPF and DKIM records for your domain. There is nothing to compose and no key to make yourself.
- 02 Shown on the service page Open the service in your account and choose DNS records. The list is the platform's own — the same rows its administrators see — with host and value ready to copy.
- 03 Published from the same account A domain registered here answers from our nameservers at no charge, and the DNS editor accepts TXT, MX and CNAME records. Paste, save, done. A domain held elsewhere takes the same records at its own DNS provider.
- 04 Signed on your own domain Messages are DKIM-signed under your domain rather than the platform's, so the reputation you build belongs to your name. Titan runs and maintains its own sending reputation on top of that.
- 05 Checked from the outside Records take an hour or two to reach the rest of the internet. Then send a message to an address at a large provider and open its original view: it states whether SPF and DKIM passed. That is the test that matters.
The shape of each record
Three TXT records. Here is what they look like.
Shapes, not values: the exact hosts and keys for your domain are on your service page and differ per platform. These show what you are looking at when you see them.
-
SPF
Host @
Type TXT
v=spf1 include:<platform> ~allOne per domain. Add every sender inside it. -
DKIM
Host <selector>._domainkey
Type TXT
v=DKIM1; k=rsa; p=<public key>Copy the key exactly. One missing character fails every signature. -
DMARC
Host _dmarc
Type TXT
v=DMARC1; p=none; rua=mailto:<you>@<your domain>Start with p=none and read the reports before tightening.
Anything in angle brackets is a placeholder. The real host names and keys for your domain are on the service page in your account, and the TXT record guide walks through adding them.
Keeping it that way
Four habits that protect a domain's reputation.
The records get you trusted. What you send afterwards decides whether you stay trusted, and no provider can do this part for you.
One SPF record, ever
Newsletter tool, shop, CRM, mail platform: each wants an include. Put them all in the single record. A second SPF record is not a stricter check — it is an invalid one, and receivers treat it as none.
No bulk from a mailbox
Campaigns sent from a personal mailbox are the fastest way to undo a good reputation. Use a service built for volume, add its include to SPF, and keep your mailboxes for conversations.
Tighten DMARC in stages
p=none reports without blocking. Once the reports show only your own senders passing, move to quarantine, then reject. Jumping straight to reject silences a forgotten system along with the forgers.
Send from where you said
A website contact form that sends as you from the web server fails SPF and DKIM unless that server is in the record and signs with the key. Route it through the mail platform instead, and it carries the same signature as the rest of your mail.
Questions
Before you decide.
No, and be wary of anyone who says otherwise. A receiving server decides for itself what to accept and what to file as junk. What SPF, DKIM and DMARC do is remove the reason most legitimate mail is treated as suspicious: the receiver can verify that the message came from a server you authorised and was not altered. With them in place and ordinary sending behaviour, mail from a new domain lands where it should in the great majority of cases.
No. When your mailbox service is created, the platform generates the MX, SPF and DKIM records for your domain. They are listed on the service page in your account under DNS records, with host and value ready to copy. DMARC is the one you choose the policy for, and the shape above is the safe starting point.
Yes. The records are ordinary DNS records and go wherever your domain's DNS is hosted. Copy them from the service page and add them at that provider. Nothing about them depends on the domain being registered here — only the convenience of publishing them from the same account does.
Increasingly, yes. The largest receivers now expect a DMARC record from any domain sending them meaningful volume, and treat its absence as a mark against the sender. A p=none policy costs nothing, blocks nothing, and sends you reports on who is using your name. There is no good reason to leave it out.
Usually within an hour or two, occasionally longer where a previous record was cached with a long time-to-live. Wait before testing, then send to an address at a large provider and open the message's original view, which reports each check as pass or fail.
All three. Business Email generates its records at setup and shows them on the service page. Titan signs with DKIM on your domain and runs its own sending reputation. Google Workspace publishes its SPF, DKIM and DMARC guidance in its admin console. The records differ per platform; the questions they answer do not.
Mailboxes on your own domain, with the records to match.
Three platforms, each generating what your domain needs and each signing under your name. Pick the one that fits the team, and the deliverability work above is already half done.