How to set up SPF, DKIM, and DMARC
Authenticate your sending domain with SPF, DKIM, and DMARC. What each record does, how to publish it, and how to verify it actually resolves.
Outbound email requires all three authentication records: SPF authorizes which servers may send for your domain, DKIM cryptographically signs your messages, and DMARC tells receiving servers what to do when a message fails either check. Publish all three on your sending domain, then verify each one independently — adding a record is not the same as it working.
Who this applies to: 11x workspace Admins setting up outbound email for Alice. You need DNS access for the sending domain. Confirm who owns DNS before you start — it's often IT rather than the GTM team.
What each record does
| Record | Answers | Failure symptom |
|---|---|---|
| SPF | "Is this server allowed to send for this domain?" | Mail rejected or spam-foldered |
| DKIM | "Was this message altered in transit, and is it really from this domain?" | Mail spam-foldered, no logo display |
| DMARC | "What should I do if SPF or DKIM fails?" | Inconsistent handling, no visibility |
All three are required. Two out of three still leaves you exposed.
Step 1 — Choose your sending domain
Use a dedicated sending subdomain (for example outbound.yourcompany.com) or a separate domain for cold outbound. This isolates outbound reputation from your transactional, internal, and executive mail. If outbound reputation gets damaged, your primary domain is unaffected.
Decide this before publishing anything — moving later means warming a new domain from scratch.
Step 2 — Publish SPF
Get the SPF include from 11x
11x provides the mechanism to include for its sending infrastructure.
Add or edit one TXT record
SPF is a TXT record at the root of your sending domain, starting with v=spf1.
Merge, do not duplicate
A domain may have only one SPF record. If one already exists, add the new include to it rather than creating a second TXT record.
Two SPF records on one domain is a hard failure — the domain is treated as having invalid SPF entirely. This is one of the most common misconfigurations.
Watch the lookup limit
SPF allows a maximum of 10 DNS lookups. Each include: counts. Long-accumulated SPF records frequently exceed this and fail silently.
Verify
Test with the SPF record checker. Confirm it resolves and reports within the lookup limit.
Step 3 — Publish DKIM
Get the DKIM key and selector from 11x
You'll receive a public key and a selector name.
Add the record at the selector hostname
DKIM records live at a selector-specific hostname, in the form <selector>._domainkey.yourdomain.com.
Paste the key exactly
Do not add line breaks or spaces. Truncated or reformatted keys are a frequent cause of DKIM failing while appearing configured.
Verify
Test with the DKIM checker. It must report a valid signature, not merely a record present.
Step 4 — Publish DMARC
DMARC is a TXT record at _dmarc.yourdomain.com. It has three policy modes:
| Policy | Behaviour | When to use |
|---|---|---|
p=none | Monitor only, take no action | Start here — collect reports without risk |
p=quarantine | Send failures to spam | After reports look clean |
p=reject | Reject failures outright | Steady state, and required for BIMI |
Start with p=none
Publish in monitoring mode and include a reporting address so you receive aggregate reports.
Read the reports for a week or two
You're looking for legitimate mail streams that fail authentication — a marketing tool or invoicing system you'd forgotten about.
Fix any legitimate failures
Authenticate those senders before tightening the policy, or you'll block your own mail.
Move to quarantine, then reject
Tighten in stages. Don't jump straight from none to reject.
Verify
Test with the DMARC checker.
Do not publish p=reject before reviewing DMARC reports. If any legitimate system sends on your behalf without authentication, enforcement will silently block it — often invoices or password resets, which you'll discover from customers rather than monitoring.
Step 5 — Verify everything together
Run the domain health checker for a combined view, then confirm:
- SPF resolves, single record, within 10 lookups
- DKIM reports a valid signature
- DMARC record present with a policy and reporting address
- Domain and IP not on a blocklist — check here
- MX records correct — check here
DNS changes propagate on a delay. If a checker reports failure immediately after you publish, wait and re-test before assuming the record is wrong.
Optional — BIMI
Once DMARC is at enforcement, BIMI displays your verified brand logo next to your messages in supporting inboxes. Check eligibility with the BIMI checker. This is a trust and recognition improvement, not a deliverability fix.
Troubleshooting
Next steps
Warm up a new domain
Authentication done — now build reputation.
Why emails go to spam
The other seven causes.
Set up Alice
Continue outbound configuration.
Help Center
All articles and tools.
Still need help
Email support@11x.ai with your sending domain and the output of the domain health checker.