The 6-record full setup
Every robust email-sending domain needs:
| Record | Purpose | Required? |
|---|---|---|
| SPF (TXT) | Authorize sending IPs | Yes — base authentication |
| DKIM (TXT or CNAME) | Cryptographically sign emails | Yes — base authentication |
| DMARC (TXT) | Tell receivers what to do if SPF/DKIM fails | Yes — base authentication |
| MX (for return-path / bounce subdomain) | Route bounces to AcelleMail | If using custom envelope-sender |
| Tracking domain CNAME (CNAME) | Brand the click-redirect | Optional (recommended) |
| BIMI (TXT) | Show your logo in inbox | Optional (advanced) |
This guide walks each.
Open the sending-domain detail
In AcelleMail's sidebar, Sending → Sending domains. The list shows every domain you've registered with status chips (Verified / Pending / Failed) and per-auth indicators:

Click into your domain row. The detail page surfaces exactly which DNS records to publish (TXT for SPF, CNAMEs for DKIM, TXT for DMARC) with copy-paste-ready values + current verification state per check:

Record 1: SPF (Sender Policy Framework)
Tells receiving servers which IPs are authorized to send from your domain.
Publish at the apex domain (yourdomain.com):
Type: TXT
Name: yourdomain.com (root)
Value: v=spf1 include:amazonses.com include:_spf.mailgun.org -all
TTL: 3600
Includes:
include:amazonses.comif using Amazon SESinclude:_spf.mailgun.orgif using Mailguninclude:sendgrid.netif using SendGridinclude:spf.example.comfor any other vendor (check their docs)
-all (hard fail) tells receivers to REJECT messages from any IP not listed. Use ~all (soft fail) if you're still bringing new vendors online; switch to -all once production-stable.
See SPF record deep dive for the full reference + edge cases.
Record 2: DKIM (DomainKeys Identified Mail)
Cryptographically signs your outgoing emails so receivers can verify authenticity.
AcelleMail generates the DKIM keypair when you add a sending domain. Per the verify-domain wizard:
Type: CNAME
Name: acellemail._domainkey.yourdomain.com
Value: acellemail._domainkey.acellemail.com (or your AcelleMail-side selector)
TTL: 3600
The exact CNAME target varies per AcelleMail install — the sending-domain detail page shows yours specifically. Most installs use AcelleMail's auto-generated 1024-bit or 2048-bit keys.
See DKIM key rotation playbook for rotation discipline.
Record 3: DMARC (Domain-based Message Authentication, Reporting & Conformance)
Tells receivers what to do when SPF/DKIM fails for your domain. Plus collects aggregate reports.
Publish at _dmarc subdomain:
Type: TXT
Name: _dmarc.yourdomain.com
Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-reports@yourdomain.com; fo=1; pct=100
TTL: 3600
Key parameters:
p=— what to do with failed messages (none= monitor only,quarantine= junk folder,reject= bounce)rua=— where to send aggregate reports (typicallydmarc-reports@yourdomain.com)ruf=— where to send forensic reports (per-failure detail; some receivers don't send these)fo=— what failure types to report (1= SPF or DKIM fail;s= SPF fail;d= DKIM fail;0= both fail)pct=— what percentage of failed messages to apply the policy to (use 100 for full enforcement; useful for staged rollout)
Staged rollout: start p=none for 30 days. Move to p=quarantine once SPF/DKIM pass rate >99%. Move to p=reject for hardest enforcement.
See DMARC enforcement migration for the staged plan.
Record 4: MX for return-path / bounce subdomain (custom envelope-sender)
If you use a custom envelope-sender (e.g. bounce.yourdomain.com), AcelleMail needs an MX record so bounces route correctly:
Type: MX
Name: bounce.yourdomain.com
Value: feedback.acellemail.com (or your install's bounce processor)
Priority: 10
TTL: 3600
Without this, bounce messages get rejected by the receiving server's MX lookup. AcelleMail's sending-domain detail page tells you the exact MX target.
For default vendor envelope-senders (e.g. SES's bounces+xxx@amazonses.com), the MX is on AWS's side — no action needed.
Record 5: Custom tracking domain CNAME
If using a custom click-tracking domain (recommended for brand consistency):
Type: CNAME
Name: click.yourdomain.com
Value: track.acellemail.com (or your install's tracking endpoint)
TTL: 3600
See Custom tracking domain for click URLs for the full setup.
Record 6: BIMI (show your logo in inbox)
After DMARC enforcement is stable, add BIMI:
Type: TXT
Name: default._bimi.yourdomain.com
Value: v=BIMI1; l=https://yourdomain.com/bimi/logo.svg; a=https://yourdomain.com/bimi/vmc.pem
TTL: 3600
Required: DMARC at p=quarantine or p=reject. See BIMI setup walkthrough.
Verify everything in AcelleMail
After all 6 records published, the sending-domain detail in AcelleMail shows green chips per auth check:
The auth chips on the sending-server detail
Open Settings → Sending servers → click your active server. The toolbar shows the live SPF / DKIM / DMARC chip status:

- Green chips on all three = receiving servers can confirm you're authorized to send from this domain.
- Any chip red = receiving servers immediately downgrade reputation. Click Verify domain in the toolbar to walk through the DNS-fix wizard.
Click Verify domain to re-check on demand. AcelleMail's dig-check runs against the receiving-server-side perspective (not your local cache), so propagation issues are detected accurately.
Common UI signals + fixes
| Symptom | Likely cause | UI fix |
|---|---|---|
| All 4 auth chips Green except DMARC | DMARC record published but pass rate <99% | Check rua aggregate reports; identify failing source IPs |
| SPF chip Red after adding a new vendor | SPF lookup count exceeded 10 (DNS limit) | Combine includes or use SPF flattening (advanced) |
| DKIM chip Red despite CNAME published | DNS propagation pending OR CNAME pointing wrong target | dig CNAME acellemail._domainkey.yourdomain.com to verify |
| MX chip Red on bounce subdomain | MX not published or pointing wrong target | Check sending-domain detail page for exact MX target |
| BIMI logo not appearing in Gmail | VMC not configured | See BIMI VMC cost walkthrough |
| Different chip states on different campaigns | Per-campaign From: domain doesn't match the verified sending domain | Use consistent From: domain per sending-server config |
Per-vendor SPF includes reference
| Vendor | SPF include |
|---|---|
| Amazon SES | include:amazonses.com |
| SendGrid | include:sendgrid.net |
| Mailgun | include:_spf.mailgun.org |
| Postmark | include:spf.mtasv.net |
| Sparkpost | include:sparkpostmail.com |
| Self-hosted Postfix | Your sending server IPs (ip4:1.2.3.4) |
Combine for multi-vendor:
v=spf1 include:amazonses.com include:_spf.mailgun.org include:sendgrid.net -all
DNS lookup limit: 10. Most senders fit comfortably.
Advanced: SPF flattening, DKIM key length recommendations, DMARC ARC for forwarders
SPF flattening:
If you have many includes (3+ vendors + corporate apps), you can hit the 10-lookup DNS limit. SPF flattening resolves all includes at publish time + republishes as a single record:
# Before:
v=spf1 include:amazonses.com include:_spf.mailgun.org include:sendgrid.net include:spf.mtasv.net -all
# 4 lookups; if any vendor's include has 2-3 sub-includes, you blow the cap
# After (flattened):
v=spf1 ip4:54.240.0.0/18 ip4:13.32.0.0/15 ip4:54.240.36.0/22 ... -all
Tools like ValiMail SPF + Easy SPF auto-flatten + re-publish daily (vendors change their IP ranges). Self-flatten manually = maintenance burden; tool is worth it for 4+ vendor stacks.
DKIM key length:
- 1024-bit: legacy; still works at all receivers
- 2048-bit: modern; recommended for new setups
- 4096-bit: maximum security; some DNS hosts don't allow >2048-bit TXT records
For DKIM-via-CNAME (AcelleMail default), the key length is managed at the AcelleMail side — typically 2048-bit.
DMARC ARC (Authenticated Received Chain):
For forwarding scenarios — when your message is forwarded by a recipient or middleman — the original SPF + DKIM can fail. ARC records the original auth state so the eventual receiver can trust the chain.
ARC-Authentication-Results: i=1; mx.google.com;
dkim=pass header.i=@yourdomain.com header.s=acellemail header.b=...;
spf=pass smtp.mailfrom=bounce@yourdomain.com;
dmarc=pass header.from=yourdomain.com
ARC-Seal: i=1; a=rsa-sha256; t=...; ...
ARC-Message-Signature: ...
AcelleMail handles ARC signing automatically when forwarding scenarios are detected.
Aggregate DMARC report parsing:
DMARC rua= reports arrive at your inbox as XML files (.zip or .gz). Parse via:
- dmarcian.com (free tier)
- onDMARC by Red Sift (paid; full visualization)
- DMARCLY (budget; basic reports)
- Custom parser (open-source XML libraries)
Reports tell you which IPs sent from your domain and what auth state was — including unauthorized senders trying to spoof your domain.
Multi-tenant DMARC for SaaS:
If your platform sends on behalf of many customers:
Customer A: _dmarc.customerA.com → Customer's own DMARC policy
Customer B: _dmarc.customerB.com → Customer's own DMARC policy
Each customer manages their own DMARC. Your platform-side SaaS DMARC policy is separate (for emails sent FROM your own platform domain).
Verification automation:
# Daily script: verify all 6 records on all sending domains
domains=$(curl -sH "Authorization: Bearer $TOKEN" \
"https://acellemail.com/api/v1/admin/sending-domains" | jq -r '.data[].name')
for domain in $domains; do
spf=$(dig TXT $domain +short | grep -c "v=spf1")
dkim=$(dig TXT acellemail._domainkey.$domain +short | grep -c "k=rsa")
dmarc=$(dig TXT _dmarc.$domain +short | grep -c "v=DMARC1")
bimi=$(dig TXT default._bimi.$domain +short | grep -c "v=BIMI1")
echo "$domain: SPF=$spf DKIM=$dkim DMARC=$dmarc BIMI=$bimi"
done
Alert if any record drops to 0 (DNS host accidentally removed). DNS-host bugs do happen.
Related articles
- How to set up SPF, DKIM, and DMARC records
- SPF record deep dive
- DMARC enforcement migration
- Return-path and envelope-sender explained
- Custom tracking domain for click URLs
- BIMI setup — show your logo in Gmail
- DNS propagation explained
8 bình luận