Custom domain email DNS is the unglamorous part of professional email — and the part that decides whether mail arrives. AzAd Admin shows guided records for your domain. This article explains what each record is for so you can review changes calmly.
The three records that matter most
MX (where inbound mail goes)
MX points your domain at a mail exchanger. For a full AzAd cutover, MX targets AzAd/Mailcow hosts as shown in admin. For hybrid Google / Microsoft mail, Google or Microsoft keeps MX; AzAd receives only routed unrecognized recipients.
Changing MX too early — before mailboxes exist — causes bounces. Changing MX too late leaves new mail in the old system after users already switched clients.
SPF (who may send as you)
SPF lists authorized senders. AzAd publishes an include for its sending infrastructure. Hybrid setups usually need both Google (or Microsoft) and AzAd includes until one side stops sending.
Broken SPF shows up as spoofing warnings and spam folder placement. Do not invent duplicate conflicting SPF TXT records on the same name.
DKIM (cryptographic signing)
DKIM proves the message was authorized by your domain. AzAd provides DKIM keys to publish. Keep them active before you ramp outbound volume.
Suggested order of operations
- Create the org and domain in AzAd (/start/).
- Publish SPF and DKIM early (safe before MX cutover).
- Create mailboxes and test webmail.
- Configure clients with IMAP/SMTP on
server.azademail.com. - Move MX only when inbound should land on AzAd (or enable hybrid routing instead).
- Send external tests; fix spam issues with content and reputation, not only DNS.
Hybrid DNS reminder
Hybrid keeps suite MX, merges SPF, and retains AzAd verification + DKIM. Google host routes use port 25 to server.azademail.com — not 587. See the hybrid page for Admin Console routing details.
Pricing context
DNS is included with the product; you pay for mailbox storage. Display reference: 15 GB ≈ US$2.86/mo (800 PKR ÷ 280). Confirm on pricing.
Common mistakes
- Using
mail.azademail.comas IMAP after DNS is “done” - Multiple SPF TXT records instead of one merged policy
- Skipping DKIM then blaming the provider for spam
- Full MX cutover when hybrid would have reduced risk
TTL and cutover windows
Lower MX TTL to 300–600 seconds a day before changes when your DNS host allows it. After cutover, raise TTL again for stability. Make the MX change during a quiet hour; keep a rollback of the previous MX values in a notepad.
Propagating vs “it’s broken”
DNS caches lie. Test with multiple resolvers and an external mail-tester after changes. Colleagues on corporate DNS may see old MX longer than your phone on cellular DNS.
DMARC (optional next step)
After SPF and DKIM are clean, many orgs add a monitoring DMARC policy (p=none) before enforcement. AzAd docs focus on MX/SPF/DKIM first — add DMARC when you are ready to read reports, not on the same afternoon as first MX cutover.
Checklist copy-paste
- Domain added in AzAd Admin
- SPF single TXT merged
- DKIM published and verified
- Mailboxes exist before MX points to AzAd (full cutover)
- Hybrid routing verified if Google/Microsoft keeps MX
- External send/receive tested
- Clients use
server.azademail.comfor IMAP/SMTP
Verification vs propagation
AzAd Admin may show “verified” while some resolvers still cache old TXT records. Test from more than one network (office Wi‑Fi and mobile data). Corporate DNS filtering sometimes blocks external MX lookups — involve IT if inbound tests fail only inside the office.
Hybrid SPF example (conceptual)
When Google keeps MX and AzAd sends for AzAd mailboxes, SPF typically merges Google’s include with AzAd’s authorized senders in one TXT record on the root domain. Duplicate SPF TXT records break validation. Remove old includes only when that provider stops sending as your domain.
When to involve a DNS host
If your registrar UI only allows one TXT and you already use SPF for another product, plan the merge before cutover. Some hosts require support tickets for DKIM CNAME/TXT at specific names — start early in the trial, not the night before MX change.
Post-cutover monitoring
Watch bounce rates and spam folder placement for the first two weeks. DNS being correct does not fix bad list purchases or sudden volume spikes. Keep a mailbox on Gmail and Outlook.com for manual inbox checks.
Related migration content
MX cutover rollback
Keep previous MX values and TTL notes in admin runbook. If inbound fails after change, revert MX first while diagnosing — users notice mail failure faster than SPF theory.
DMARC when you are ready
After SPF and DKIM validate, some orgs add monitoring DMARC (p=none) before enforcement. Not required on day one — add when someone will read aggregate reports.
Next step
Start domain verification during trial signup at /start/, and keep pricing open while you choose a storage tier.