Elastic Email SPF and DKIM setup

What you are setting up

Elastic Email is an SMTP relay and marketing-email platform, and it authenticates a sending domain with two TXT records: one SPF record that includes _spf.elasticemail.com, and one DKIM record at the api selector. Both are plain TXT records, not CNAME delegations, so you publish the actual public key in your zone. Elastic Email calls SPF mandatory and DKIM strongly encouraged; for DMARC you want both. Two more records are optional but matter: a tracking CNAME that brands rewritten links with your domain, and a custom bounce domain CNAME that moves the Return-Path onto your domain. The second one is the record that makes SPF align with your From address rather than merely pass.

Publish SPF and DKIM

In Elastic Email, go to Settings > Domains > Manage Domains, click Start Verification, and enter your domain. The verification screen lists each record with a Verify record button beside it. The shape is:

Type:  TXT     (SPF)
Host:  @
Value: v=spf1 a mx include:_spf.elasticemail.com ~all

Type:  TXT     (DKIM)
Host:  api._domainkey
Value: k=rsa;t=s;p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB... (copy from Manage Domains)

Type:  CNAME   (Tracking, optional)
Host:  tracking
Value: api.elasticemail.com

Type:  CNAME   (Custom bounce domain, optional but recommended)
Host:  bounces
Value: bounces.elasticemail.net

If your domain already has an SPF record, do not add a second one. Elastic Email's own guidance is to add include:_spf.elasticemail.com to the existing record, because a zone with two SPF records fails SPF everywhere. The DKIM host is api._domainkey and the value is the key exactly as shown in your account, starting k=rsa;t=s;p=; copy it from the verification screen rather than from this page. For a subdomain such as mail.yourdomain.com, the hosts become mail and api._domainkey.mail. The custom bounce domain is set separately: on Manage Domains, open the three-dot menu for the domain, choose View details, and enter the bounce subdomain you created. Elastic Email requires it to be a subdomain, and if the zone is on Cloudflare the record must be DNS-only (click the cloud icon to turn the proxy off). Once each record verifies you get a green check mark; Elastic Email says to allow up to 48 hours for DNS to propagate, though most zones show green within minutes.

Add DMARC

Standard _dmarc TXT record, nothing Elastic Email-specific. Start in monitor-only mode and ramp up:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Elastic Email's verification screen shows a DMARC row too and suggests going straight to p=quarantine or p=reject. Resist that on day one. A p=none record with a rua address is fully accepted by Gmail and Yahoo and gives you the reports you need to see what else sends as your domain. Build it with our DMARC builder and progress past p=none once your reports are clean.

The Elastic Email gotcha

Without a custom bounce domain, SPF does not align. By default Elastic Email puts the Return-Path on bounces.elasticemail.net. SPF passes for that domain, but DMARC compares the Return-Path domain with your From domain, and elasticemail.net is not yours. Your DMARC pass then leans entirely on the api DKIM signature, which is fine until a forwarder or a mailing list breaks the signature. Point bounces.yourdomain.com at bounces.elasticemail.net, enable it under View details, and bounces travel on a subdomain of yours, so SPF aligns under DMARC's default relaxed mode. Elastic Email notes that Google may report SPF as neutral on a custom bounce domain; check the Authentication-Results header on a test send after you turn it on.

The suggested SPF spends three lookups before you start. Elastic Email's copy-paste record is v=spf1 a mx include:_spf.elasticemail.com ~all. The a and mx mechanisms each cost a DNS lookup against the limit of ten, and most domains do not send mail from their web server or their MX hosts. If your record is already busy with Google or Microsoft plus a CRM, drop a and mx and keep only the include. Two smaller traps: Elastic Email will quietly send from your default verified sender domain if a campaign uses a From domain you have not verified, so an unverified brand domain shows up in DMARC reports as a different domain entirely; and the DKIM key carries the t=s flag, which tells receivers the signing domain must match exactly, so a subdomain that sends through Elastic Email needs its own api._domainkey record rather than borrowing the parent's.

Confirm it worked

• Check Manage Domains. SPF and DKIM should both show a green check mark, and Tracking too if you added it. A red mark on SPF usually means a second SPF record or a typo such as _spf.elasticmail.com (missing the second e).
• Send a test and read the headers. Send through Elastic Email, open the message, and confirm the DKIM signature shows d=yourdomain.com with s=api, the Return-Path is on bounces.yourdomain.com if you set the custom bounce domain, and the result is dmarc=pass. Our header analyzer reads it back plainly.
• Watch the reports. Elastic Email should appear as an aligned, passing source on DKIM, and on SPF too once the bounce domain is in, in your DMARC aggregate reports, labeled as a known sender in trustyourinbox.