DNS
MX, SPF, DKIM, and DMARC explained
What each DNS record does for deliverability — and how xMailCloud verifies them in your workspace.
Email deliverability depends on DNS records most people never touch until something breaks. Here is what each record does and why the xMailCloud Go Live checklist checks all four.
MX — where mail is delivered
MX (Mail Exchange) records tell sending servers which host accepts mail for your domain.
Example:
Host: @
Type: MX
Priority: 10
Value: mail.xmailcloud.com
When someone sends to hello@yourdomain.com, their provider looks up MX for yourdomain.com and delivers to the listed host.
Only one primary MX path should be active for production. During migration you might temporarily dual-run with import jobs, but two competing MX targets on @ causes unpredictable delivery.
SPF — who may send for your domain
SPF (Sender Policy Framework) is a TXT record listing IP addresses and providers allowed to send mail claiming to be from your domain.
Example shape:
v=spf1 include:spf.xmailcloud.com ~all
Receivers compare the sending server against this list. If a newsletter tool, website, or CRM sends mail for your domain, its provider must be included in SPF — or messages may land in spam.
Common mistake: Multiple SPF TXT records on @. You must merge into one SPF record.
DKIM — cryptographic proof
DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing messages. Receivers verify the signature against a public key published in DNS (usually a TXT record on a selector like dkim._domainkey).
DKIM survives forwarding better than SPF in many cases and is required for strict DMARC alignment.
xMailCloud shows the exact DKIM record in your domain console — copy it verbatim.
DMARC — policy and reporting
DMARC tells receivers what to do when SPF and DKIM do not align with the From address, and where to send aggregate reports.
Example:
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com
Policies:
| Policy | Meaning |
|---|---|
p=none | Monitor only — good while testing |
p=quarantine | Suspect mail may go to spam |
p=reject | Failures may be rejected outright |
If you use p=reject, fix SPF and DKIM before cutover. Strict DMARC with broken records causes legitimate mail to bounce.
How they work together
Incoming: Sender → looks up MX → delivers to your mail host
Outgoing: Your server → signs with DKIM → receiver checks SPF + DKIM + DMARC
A message typically passes if either SPF or DKIM aligns with your domain and DMARC policy allows it.
How xMailCloud helps
The Go Live checklist and domain console:
- Show the exact records to copy
- Re-query public DNS until each check passes
- Highlight which row still fails (MX vs SPF vs DKIM vs DMARC)
You do not need to guess whether propagation finished — the workspace tells you.
Checklist before go-live
- MX points to xMailCloud
- Single SPF TXT on
@with xMailCloud include - DKIM TXT added from domain console
- DMARC TXT added (start with
p=noneif unsure) - Old provider MX and conflicting SPF includes removed
- Test send received at Gmail — view original → SPF pass, DKIM pass
Related guides
Ready to set up your domain?
Create an account and follow the Go Live checklist — live DNS checks walk you through every record.