SPF, DKIM & DMARC for Elastic Email.
Verifying a domain in Elastic Email comes down to four DNS records plus a click in the dashboard: an SPF TXT record that adds Elastic Email's shared include, a DKIM TXT record on the api selector, a tracking CNAME that brands your click/open links, and a DMARC policy record. What's unusual here is the DKIM key — Elastic Email hands every customer the same shared public key rather than generating a per-domain one, and its SPF include is a dynamic macro lookup rather than a static IP list. Get the records in and hit Verify, and Elastic Email sends fully authenticated as your domain — and lifts the 500-emails-a-day cap it puts on unverified domains.
Why authenticate Elastic Email?
Authenticating your Elastic Email domain is what lifts you out of the 500-messages-a-day penalty box and off the shared pool. Until a domain is verified, Elastic Email caps it at 500 emails per day and sends your mail only weakly attributed to you. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on Outlook/Hotmail/Live traffic in 2025 — and because Elastic Email is used heavily for high-volume marketing and transactional sending, that bar applies to exactly the mail you push through it. Publishing SPF and DKIM (plus the tracking CNAME and a DMARC policy) aligns your mail to your own domain, removes generic Elastic Email branding from tracked links, unlocks the daily cap, and makes the sending reputation you build accrue to your domain instead of the infrastructure every account on the platform shares.
The SPF reality for Elastic Email
Elastic Email is a genuine "include" provider: you add one shared mechanism, include:_spf.elasticemail.com, to the single SPF TXT record on your domain. Elastic Email's own recommended line is v=spf1 a mx include:_spf.elasticemail.com ~all, but the only part that authorizes Elastic Email's servers is the include — the a and mx are generic boilerplate that authorize your own web/mail host and are optional. What makes this include unusual is what it resolves to: instead of a static list of ip4: ranges, _spf.elasticemail.com publishes v=spf1 exists:%{i}._spf.elasticemail.info ~all — a macro-based exists: check that looks up the exact sending IP (%{i}) at verification time. Two practical consequences follow. First, the include costs TWO of your 10 SPF DNS lookups, not one: one for the include itself and one for the nested exists mechanism (keep the a and mx too and Elastic Email's recommended line is already at four lookups before you add any other sender). Second, because authorization is computed dynamically per IP, Elastic Email can add or retire sending IPs without you ever editing DNS again. Keep exactly one SPF record on the domain — if you already send through Google Workspace, Microsoft 365, a CRM, etc., merge include:_spf.elasticemail.com into that single v=spf1 line rather than publishing a second SPF record (two SPF records is a PermError). Elastic Email ships the line with ~all (softfail) because most senders also mail from other services; tighten to -all only once every legitimate source is listed.
Step by step
- 1
Open Manage Domains
Log in at app.elasticemail.com and go to Settings → Domains → Manage Domains. Click Start Verification, type the domain you send from, and click Continue. Elastic Email then generates the exact DNS records for that domain.
- 2
Read the generated records
On the verification screen Elastic Email lists the records to publish: an SPF TXT line, a DKIM TXT record on host api._domainkey, a tracking CNAME (host tracking → api.elasticemail.com), and a suggested DMARC record. Keep this tab open — you'll click Verify here once DNS is live.
- 3
Add or merge the SPF record
At your DNS host, add a TXT record on the root domain (host @ or blank) with v=spf1 a mx include:_spf.elasticemail.com ~all. If an SPF record already exists, do NOT create a second one — merge include:_spf.elasticemail.com into the existing v=spf1 line. You can drop the a and mx if you don't send from your domain's own web/mail server.
- 4
Publish the DKIM TXT record
Add a TXT record with host api._domainkey and the value shown in your dashboard (it starts with k=rsa; t=s; p=MIGf…). This is Elastic Email's shared DKIM key — copy the value verbatim from Manage Domains and don't rename the host.
- 5
Add the tracking CNAME
Add a CNAME record with host tracking pointing to api.elasticemail.com. This brands your open/click-tracked links with your own subdomain and is part of full domain verification. On Cloudflare, set it to DNS only (grey cloud) so it resolves.
- 6
Publish the DMARC record
Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none (monitor-only) so nothing is affected while you confirm alignment, then tighten later.
- 7
Click Verify record
Back on the verification screen, click Verify record. Green checkmarks appear next to each record as Elastic Email confirms it in DNS. Propagation can take up to 24–48 hours, so re-check if a record isn't seen immediately.
- 8
Set as default sender
Once verified, optionally set the domain as your default sender so new campaigns and API sends use it automatically. Verification also removes the 500-emails-per-day cap that applies to unverified domains.
- 9
Send a test and check the headers
Send a message from an address on the verified domain, open it in Gmail, and choose ⋮ → Show original. Confirm DKIM: PASS signed-by yourdomain.com (selector api), SPF: PASS, and DMARC: PASS.
Records to add
Elastic Email generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 a mx include:_spf.elasticemail.com ~allRoot SPF — keep just one SPF record and merge the include into it. Only include:_spf.elasticemail.com authorizes Elastic Email; the a and mx are optional. The include costs 2 DNS lookups (include + a nested exists macro). |
| TXT | api._domainkey | k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCbmGbQMzYeMvxw…Elastic Email's SHARED DKIM key (selector api) — every account publishes the same value. Copy the full value verbatim from Manage Domains; it aligns to your domain even though the key is shared. |
| CNAME | tracking | api.elasticemail.comBranded open/click tracking. Part of full verification. On Cloudflare set to DNS only (grey cloud). |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comOne DMARC record per domain. Start at p=none, then tighten to quarantine/reject. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Elastic Email's setup costs against that budget.
Elastic Email adds 2 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM on Elastic Email is a single, shared public key with the selector api — not a per-domain key you generate. Every customer publishes the very same TXT record: host api._domainkey.yourdomain.com, value k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ… (a 1024-bit key). You can confirm this yourself: api._domainkey.elasticemail.com resolves to the identical value. Elastic Email holds the one matching private key and signs your outbound mail with d=yourdomain.com, so even though the key is shared, the signature still ALIGNS to your domain — which is exactly what DKIM needs to contribute a DMARC pass. Because it's shared, a few things follow: you can't rotate the key yourself, it's a 1024-bit key rather than the 2048-bit modern default, and you should copy the exact value from your own Manage Domains screen rather than pasting one from a third-party article — if Elastic Email ever rotates the shared key, the dashboard is the source of truth. Publish it exactly as shown: don't rename the api._domainkey host, don't switch it to a CNAME, and don't add or strip characters (the t=s flag in the value is Elastic Email's, not a typo). In practice DKIM is the load-bearing mechanism for DMARC here — it aligns to your domain on every message regardless of forwarding, whereas SPF only helps when your domain is the envelope sender.
DMARC
DMARC is a separate TXT record you publish yourself — Elastic Email doesn't create it, though its verification flow prompts you for one. Add a record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery but asks receivers to email you aggregate reports so you can confirm Elastic Email's mail is passing DKIM (and, where your domain is the envelope sender, SPF) aligned to your domain before you enforce anything. Elastic Email's own verification screen nudges you straight to p=quarantine or p=reject, and it's right that a policy of none earns you little protection — but move there deliberately: watch the rua reports for a week or two, confirm every legitimate sender (Elastic Email plus any other tools on the domain) is aligned, then tighten to quarantine and finally reject. Keep exactly one _dmarc record for the whole domain no matter how many senders you use; never publish a second DMARC record just for Elastic Email.
Check it actually worked
Don't trust the green checkmarks in Manage Domains alone — confirm on a real message. Send a test from an address on the verified domain, open it in Gmail, and choose ⋮ → Show original: you want DKIM: PASS signed-by yourdomain.com with selector api, SPF: PASS, and DMARC: PASS. If SPF shows an Elastic Email envelope domain instead of yours, don't panic — DKIM is what's carrying the DMARC pass, and that's fine. You can also spot-check the raw records with dig TXT api._domainkey.yourdomain.com, dig TXT yourdomain.com (for the SPF line), dig TXT _dmarc.yourdomain.com, and dig CNAME tracking.yourdomain.com. Then run the domain through Qualisend's domain health check to confirm every record resolves and your SPF stays under the 10-lookup limit (remember Elastic Email's include is two of them), and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer to verify Elastic Email shows up as an aligned, passing source.
Common gotchas
- DNS setup
Elastic Email's DKIM key is shared, not per-domain — every account publishes the same api._domainkey value. That's expected and still aligns to your domain, but it means you can't rotate the key yourself, it's a 1024-bit key, and you should copy the exact value from Manage Domains rather than a third-party article in case Elastic Email rotates it.
- Breaks auth
The include costs TWO SPF lookups, not one: include:_spf.elasticemail.com plus the nested exists:%{i}._spf.elasticemail.info macro inside it. Keep Elastic Email's suggested a and mx and the recommended line is already ~4 lookups before you add any other sender — mind the 10-lookup limit.
- Breaks auth
Keep exactly one SPF record on the domain. If you already send through Google, Microsoft 365, a CRM, etc., merge include:_spf.elasticemail.com into the existing v=spf1 line — two separate SPF records is a PermError that breaks SPF entirely.
- DNS setup
The a and mx in Elastic Email's recommended SPF are generic boilerplate for your own web/mail host, not Elastic Email. If you don't actually send mail from your domain's A record or MX servers, drop them and use v=spf1 include:_spf.elasticemail.com ~all to reclaim two lookups.
- DNS setup
On Cloudflare, set the tracking CNAME to DNS only (grey cloud). An orange-cloud proxied CNAME won't resolve to api.elasticemail.com, so tracking and full verification fail.
- DNS setup
Unverified domains are capped at 500 emails per day. If your sends are silently throttled, the domain almost certainly hasn't finished verifying — completing SPF + DKIM + the tracking CNAME and clicking Verify is what lifts the cap.
- DNS setup
Publish the DKIM record at exactly host api._domainkey, as a TXT record, with the value verbatim. Renaming the host, using a CNAME, or mangling the long p= string all cause DKIM to silently fail while the dashboard may still look partly green.
- Coverage
Sending from a subdomain (e.g. mail.yourdomain.com)? Put every record on the subdomain — SPF on the subdomain, api._domainkey.mail, tracking.mail, and _dmarc.mail. The root domain's records do not cover a sending subdomain.
Build your SPF record
Elastic Email is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listElastic Email SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.