Verifying domains
Set up the DNS records that authenticate your domain and keep your emails out of the spam folder
Before Bitelio will send email on your behalf, the sending domain has to be verified. Verification is what lets receiving mail servers authenticate your messages — it lifts deliverability and cuts the odds of landing in spam.
Verifying a domain
Add the domain in the domain tab of your project settings. Bitelio then generates the DNS records you need and displays them so you can add each one to your domain's DNS configuration.
DNS changes don't take effect instantly — after adding the records, allow some time for propagation. The domain tab shows the current verification status throughout.
DNS Records
Several DNS records are involved, and each plays its own role in authenticating and delivering your mail.
DKIM Records (3 CNAME records)
DomainKeys Identified Mail (DKIM) signs your outgoing emails cryptographically, letting receivers confirm nothing was altered in transit.
Bitelio provides 3 CNAME records for you to add. They point to the cryptographic keys that receiving servers check your signatures against.
Why it matters:
- Blocks spoofing and tampering with your emails
- Boosts deliverability and inbox placement
- Expected by virtually all major providers (Gmail, Outlook, etc.)
SPF Record (1 TXT record)
Sender Policy Framework (SPF) declares which mail servers may legitimately send email for your domain.
This is 1 TXT record enumerating the servers allowed to send.
Why it matters:
- Stops unauthorized servers from sending as your domain
- Makes your domain a less attractive vehicle for spam
- Complements DKIM to complete the authentication picture
Already have an SPF record?
A domain can only have one SPF TXT record. If you already use another email provider (Google Workspace, Microsoft 365, another sending platform), you must merge Bitelio's SPF mechanism into your existing record — don't add a second SPF record. For example, if your existing record is v=spf1 include:_spf.google.com ~all, the merged version is v=spf1 include:_spf.google.com include:<Bitelio's include from the dashboard> ~all. Two separate SPF records will cause both to fail.
Bounce Handling (1 MX record)
Through this MX record, bounce notifications and spam complaints from email providers flow back to Bitelio.
Why it matters:
- Bounces and complaints get attributed to the right contacts automatically
- Keeps your sender reputation intact
- Stops repeat sends to addresses that don't exist
- Deliverability monitoring depends on it
Bounce MX vs inbound MX
This MX record handles delivery feedback (bounces, complaints) for emails Bitelio sends out — it's separate from the inbound MX record used to receive emails sent to your domain. They serve different purposes; you can have either one or both.
DMARC (optional, recommended)
Domain-based Message Authentication, Reporting and Conformance (DMARC) lets you instruct receiving servers on how to treat mail that fails SPF or DKIM, and designates where authentication reports go.
DMARC isn't a Bitelio requirement, but the big mailbox providers (Gmail, Yahoo, Microsoft) now expect bulk senders to have it. Publish a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.comBegin at p=none, which reports without touching delivery. After a couple of weeks of reviewing the reports — and confirming every legitimate sender authenticates — step up to p=quarantine, and later p=reject.
MAIL FROM domain (optional)
Setting a custom MAIL FROM domain (usually a subdomain such as mail.yourdomain.com) aligns the bounce envelope address with your sending domain. That strengthens DMARC alignment, and some inbox providers require it for a full pass.
Enabling it on a verified domain adds one more MX record and one more TXT record on the subdomain — the dashboard shows the exact values once you turn it on.
Letting Bitelio publish the records for you
If your domain's DNS is on Cloudflare, you can skip the copying. Connect Cloudflare from the domain's panel, and Bitelio can write these records for you.
You always see the changes first. Bitelio reads your zone, works out what would have to change, and shows you the list — what it would add, what it would replace, and what is already correct. Nothing is written until you press the button. If everything is already in place, it says so and offers you nothing to press.
What it will never touch
Your domain's own SPF record. The SPF that Bitelio needs lives on the MAIL FROM subdomain, not on your root domain, so your existing one is neither read nor changed. If you send from other tools, their SPF setup is unaffected.
Anything it did not recognise. A name can hold several TXT records — domain verifications, keys, notes. Bitelio only touches an SPF record it is replacing, and leaves the rest alone.
A record it cannot decide about. If your MAIL FROM subdomain already has two mail server records, Bitelio stops and tells you: a custom MAIL FROM needs exactly one, and choosing which of yours to delete is not its call. You resolve that in your own DNS, then run it again.
Receiving email is a separate choice
The record that lets Bitelio receive mail for your domain is the one exception, and it is off by default behind its own checkbox.
That record goes on your domain itself — the same place your existing mail provider's records live. If you already receive email at this domain through Google Workspace, Microsoft 365 or anyone else, adding it makes Bitelio compete with them for your incoming mail. When you tick the box, the preview names the mail servers it would sit beside, so you can see exactly what you are getting into. Leave it unticked unless you are deliberately setting up inbound email.
Running it again is safe
Bitelio works out the plan fresh every time, against your zone as it is right now. Running it twice changes nothing the second time, and if something failed halfway, running it again finishes what is left.
Taking access away
Bitelio never sees a password or an API key for your Cloudflare account — you authorise it through Cloudflare's own consent screen, and you can withdraw that authorisation at any time from your Cloudflare dashboard, without asking us. Disconnecting from Bitelio's side forgets the credential here; revoking at Cloudflare stops it working everywhere.
Once connected, Bitelio also notices if one of these records later disappears from your zone, and tells you which one — instead of leaving you with a domain that has quietly stopped verifying.
Domains Bitelio authenticates for you
Domains added from now on use a shorter setup: three records instead of five, none of which mentions Amazon, and none of which ever needs changing again.
Your From address does not move. You still send as hello@yourdomain.com.
What you publish
| Type | Name | Points at |
|---|---|---|
| CNAME | bitelio1._domainkey.yourdomain.com | a name inside Bitelio's own DNS |
| CNAME | bitelio2._domainkey.yourdomain.com | a name inside Bitelio's own DNS |
| NS | bitelio.yourdomain.com | Bitelio's name servers |
The two CNAMEs are your DKIM signature. Bitelio holds the key behind them, which is why you will never be asked to rotate one — we change what sits behind the name, and your DNS stays exactly as you left it.
The second CNAME will look empty at first, and that is deliberate. It is the spare. Because a mail server signs with one key at a time, replacing a key in place would break messages already in flight; having a second name published from day one means the swap happens with nothing for you to do and no gap in signing.
The bounce address is a separate step
The NS record is optional and offered as its own choice in the dashboard. It hands Bitelio a single
subdomain — bitelio.yourdomain.com — used only for the return address on your messages. Nothing
else of yours lives there.
With it, recipients see your domain as the sender of record. Without it, Gmail shows "mailed-by amazonses.com" under your name. Your mail is authenticated either way: it is a question of whose name is on it, not of whether it arrives.
The four name servers are the same for every Bitelio customer:
ns-517.awsdns-00.net
ns-1633.awsdns-12.co.uk
ns-1050.awsdns-03.org
ns-113.awsdns-14.comYour dashboard shows them too — if the two ever disagree, trust the dashboard.
Some DNS providers will not let you delegate a subdomain. If yours is one of them, publish the MX and TXT records shown instead. That is a supported setup, not a fallback with a catch — it is the same pair the older setup uses.
After you publish the NS record it takes anywhere from minutes to a few hours to be visible. The dashboard says when it finds it. Your domain sends normally throughout — nothing is waiting on this.
Domains you already have are not affected
Every domain verified before this existed keeps its five records and carries on working, unchanged and indefinitely. There is no migration, and none is planned: switching an active domain's signing key opens a window where mail can go out unsigned, and under a strict DMARC policy unsigned mail is mail that does not arrive. That is not a risk worth taking with a domain that already works.
How many domains you can add
The free plan includes one sending domain. Paid plans have no limit.
The second domain needs a paid plan, and the dashboard says so before you type one in rather than after you submit it.
Nothing you already have is affected. If your project holds more domains than your plan includes — because you added them before this limit existed — they keep working and keep sending. The limit only applies when you add a new one.
Verification Status
With the records in place, Bitelio re-checks verification automatically in the background. Most domains verify within minutes, though DNS propagation can stretch the wait to as long as 72 hours.
Track progress in the Domains section of your project settings — each record type flips to verified as it's detected. Just added a record and impatient? Trigger a manual re-check from the dashboard.