For Elastic Email Email Marketing and Email API, verify a domain you own, add include:_spf.elasticemail.com to its existing SPF policy, and publish the DKIM name and public key currently displayed in your account. Verify the records in Elastic Email, then inspect a delivered message. The default bounce domain does not SPF-align with your custom From domain, so aligned DKIM is the normal DMARC path. Even when an aligned custom bounce route supplies SPF alignment, require the intended branded DKIM signature to pass as part of completing this setup. Domain verification and SPF alignment explanation.
Confirm product, account and domain ownership
This procedure concerns sender-domain authentication, not receiving mail in Elastic Email's Inbox product. Start with the correct Email Marketing or Email API account and the exact domain or subdomain you intend to put in From. Having access to an address at gmail.com does not give you control of that provider's DNS.
A domain can belong to only one Email Marketing or Email API account at a time. If another account owns the verification, resolve that ownership first. Elastic Email documents a support-assisted release when access is unavailable, using ownership proof supplied by support. Free-plan domains cannot be removed by the customer through the normal removal workflow. Do not delete a working account's domain casually to clear an error. Account ownership restrictions.
Prepare a change record containing the sending account, domain, application owner, authoritative DNS host, current SPF and DMARC, and any existing selector names. Identify which team controls ongoing campaign and API sending. A domain move can affect applications that continue using the old account even if the new DNS looks correct.
Record existing values before editing and agree on a test window. Do not rotate a key repeatedly while another administrator is still publishing an earlier value. An explicit handoff between the account owner and DNS administrator prevents that avoidable mismatch.
Open the domain verification workflow
Go to Settings → Domains → Manage Domains, select Start Verification, choose domain verification and enter your domain. Copy the DNS instructions supplied there. After publishing, return to Verify record; domain details provide the status of individual records. A default-sender star is a separate setting, not evidence that a received message passed DMARC. Current verification workflow.
Publish at the company serving the authoritative DNS zone. Your registrar and website host may be different companies. For an example.com zone, a Name field may expect @, a blank value, a relative name or a fully qualified owner. Inspect the final saved name rather than assuming every provider uses the same convention.
For news.example.com, distinguish the sending subdomain from a subaccount. One is a DNS name; the other is an account-management boundary. Build a record sheet for the actual names shown by the account instead of copying the parent domain's records into the subdomain.
Configure one SPF TXT policy
Elastic Email's documented inclusion is include:_spf.elasticemail.com. Its standalone example is:
v=spf1 a mx include:_spf.elasticemail.com ~all
For an existing policy, add the include before the final all, preserving other required authorizations and the current qualifier. Do not create another SPF record or replace the policy with a single-provider example. The a and mx mechanisms authorize additional hosts; review whether those authorizations belong in your domain's policy rather than adding them mechanically. Elastic Email SPF troubleshooting.
SPF is published as TXT, not the obsolete SPF-specific record type. It authenticates the SMTP MAIL FROM identity. The maximum is ten evaluated lookup-causing mechanisms and modifiers, including nested includes and redirects. Breaking a long policy into TXT strings, or placing includes behind another include, does not eliminate that evaluation cost. Other TXT verification tokens may coexist; only multiple SPF policies at the same owner are invalid. SPF specification.
Any all mechanism causes SPF to ignore redirect, regardless of its position. Preserve the authorized qualifier and redirected authorization design; do not insert all casually when merging. A qualifier determines an SPF result, not a guaranteed delivery or rejection decision. SPF all/redirect rule.
SPF can also evaluate HELO; for a null reverse-path (MAIL FROM:<>), the HELO identity supplies the SPF identity used in the applicable DMARC SPF evaluation. Record the actual receiver-evaluated identity rather than assuming every message has the normal envelope sender. SPF identities.
Use the actual envelope domain from a delivered message when evaluating SPF success. Adding an include at your visible From domain does not change the envelope identity selected by Elastic Email.
Publish the current account-generated DKIM key
Expand DKIM in the domain details and use the account's Copy controls for Name and Value. Create the specified TXT record at the authoritative DNS host. api._domainkey appears in examples, but the account's exact owner and complete current public key control your configuration. Never paste a fixed public key from an older tutorial or another customer's account. Current DKIM instructions.
For a typical api selector on example.com, the full lookup owner is api._domainkey.example.com. For news.example.com, it becomes api._domainkey.news.example.com. These illustrate naming, not a substitute for your account values. If the editor appends the zone, enter only the relative part; verify that the domain has not been appended twice.
For the illustrative full owner api._domainkey.news.example.com, use api._domainkey.news within an example.com zone, api._domainkey within a separately delegated news.example.com zone, or api within a separately delegated _domainkey.news.example.com zone. Preserve existing NS delegation, DNSSEC and other selectors; publish through the actual authoritative zone rather than removing delegation.
Keep the full key intact. A long TXT answer can contain several quoted character strings within one record; concatenate those component strings without inserting spaces. This is one logical TXT record, not independent key fragments in separate records. DKIM TXT storage. If a CNAME or another provider already occupies the required selector, stop and resolve ownership with the account administrators. Do not erase unrelated signing records or invent a replacement selector.
Publishing a public key does not itself prove that the platform used its matching private key on a message. Receivers identify the lookup using the message's DKIM s= and d= fields. Those fields, followed by a successful signature verification, are the useful evidence. DKIM specification.
Decide default sender and custom bounce behavior separately
Setting a default sender domain affects branding when unverified domains are used and can make the main account's verified domain available to subaccounts. Subaccounts can use that inherited domain but cannot modify it. Review this as an account-wide identity choice, not a checkbox required merely to publish DKIM. Use intentionally verified From domains in production rather than relying on fallback branding. Default sender domain.
The default bounce domain is bounces.elasticemail.net. To configure a custom one, open your domain's details, locate bounce-domain settings, select Custom, and choose a dedicated subdomain. Elastic Email documents a CNAME such as bounces.example.com pointing to bounces.elasticemail.net. Publish the account-requested record, keep it DNS-only on Cloudflare, and return to Verify Record. Custom bounce procedure.
For the required bounce alias, keep any record-level Flatten option off where available and ensure the applicable zone-wide CNAME flattening for all CNAME records setting does not flatten the required literal alias; it overrides per-record choices. Coordinate changes with the DNS owner; these controls do not apply to native TXT DKIM. If mandatory apex flattening or a same-zone-target exception prevents the required literal CNAME answer, stop and obtain a provider-supported, owner-approved hostname or DNS design. Do not declare a synthesized A/AAAA answer equivalent to the required alias or blindly change a shared zone setting. Cloudflare verification and flattening controls.
Do not add an SPF TXT record at that same CNAME owner as a quick fix. A standard CNAME cannot coexist with ordinary TXT data at the same name. If the delegated bounce route returns an unexpected SPF result, inspect the CNAME chain and ask Elastic Email to resolve the discrepancy rather than publishing conflicting records.
A bounce subdomain under example.com can align with From example.com under relaxed SPF alignment, but not strict exact-domain alignment. Sharing one bounce domain across unrelated customer domains cannot make it align with all of them. Confirm the actual received identity before selecting the option to share it across account domains.
For optional tracking, the native documented CNAME uses tracking (or automatically detected email) pointing to api.elasticemail.com; a different prefix needs support validation. Return to domain verification and keep the required alias DNS-only. Apply the same per-record Flatten-off and applicable zone-wide no-flattening controls described for the bounce alias above, with owner coordination before changing shared settings. If mandatory apex flattening or a same-zone-target exception prevents the required literal CNAME answer, stop and obtain a provider-supported, owner-approved hostname or DNS design. Do not declare a synthesized A/AAAA answer equivalent to the required alias or blindly change a shared zone setting.
Tracking is different again: it brands rewritten links and does not supply SPF alignment or DKIM. A tracking failure should not prompt a DKIM key change. Ordinary outbound authentication also does not require moving your existing inbound MX records. Tracking-domain explanation.
Preserve or introduce DMARC safely
Query TXT at _dmarc.example.com. For From news.example.com, inspect _dmarc.news.example.com and applicable ancestor policy before adding a local record. Preserve existing enforcement, report destinations and alignment settings. No local record does not mean there is no inherited protection.
DMARC passes with either an aligned SPF pass or an aligned DKIM pass. Relaxed alignment permits the same organizational domain; strict alignment requires the identical domain. A provider-domain SPF pass alone does not authenticate your visible From. RFC 9989 replaces RFC 7489 and removes pct; do not build a rollout around the former percentage tag. Current DMARC specification.
Only if no direct or applicable inherited policy is established and the policy owner approves the monitoring plan, publish one TXT at _dmarc.example.com with the minimal value v=DMARC1; p=none. Use _dmarc where the editor appends the zone. That value requests no reports. Append ; rua=mailto:REPORT-ADDRESS with a real, approved destination for monitoring, replacing the placeholder with a mailbox address only, not another mailto: prefix. For _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in the separately delegated news.example.com zone. Compare the Organizational Domain of the domain where the policy was found with that of the reporting URI host. When they differ, the report-generating receiver must check the destination’s DNS authorization. Destinations within the same Organizational Domain are excepted even if the hostnames differ. RFC 9990 section 4. That check is separate from the owner’s approval to share report data with the chosen recipient, including access and retention review. Edit existing policy rather than duplicating or weakening it. Review every legitimate sender before enforcing quarantine or rejection.
For a hypothetical passing signature with d=news.example.com and visible From sender@example.com, DKIM aligns in relaxed mode but not strict mode. A passing d=example.com signature with that same From aligns in both modes. These examples illustrate comparison rules, not measured provider signing identities. DKIM alignment.
Verify public DNS and delivered-message alignment
Substitute your domain and account selector in these reader-side checks:
dig +short NS example.com
dig +short TXT example.com
dig +short TXT api._domainkey.example.com
dig +short TXT _dmarc.example.com
dig +short CNAME bounces.example.com
The last query applies only if that custom bounce owner was configured. Expect the intended SPF policy, the exact current DKIM key, the established DMARC policy and the correct bounce target. Follow a bounce CNAME to inspect its TXT answer without adding conflicting local TXT. If resolvers disagree, compare authoritative answers and TTLs. An empty answer or a stale key is not successful verification.
Recheck the individual records in Elastic Email, then send through the real campaign or API workflow to a controlled external inbox. Inspect the receiving service's trusted Authentication-Results, including spf, smtp.mailfrom, dkim, header.d, dmarc and header.from; match the DKIM selector to the signature. Have the receiving administrator confirm the trusted authentication boundary and that externally supplied result fields are stripped or clearly isolated. If that cannot be established, use receiver-controlled authentication logs or message traces instead. A familiar authserv-id or header position alone is not provenance. Authentication-Results standard.
With default bounce handling, expect SPF identity outside your domain and require valid aligned DKIM for DMARC. With custom bounce handling, verify both the actual envelope domain and its alignment mode. For every route, including custom bounce, require the intended branded signature’s dkim=pass, its d= alignment with the intended visible From under the effective mode, and trusted dmarc=pass. An SPF-only DMARC pass does not complete DKIM setup, and a rewritten unrelated fallback From is not success. A dashboard check or star cannot substitute for this message-level evidence.
Diagnose SPF separately: fail or softfail calls for checking the actual evaluated identity and connecting IP; permerror calls for checking syntax, duplicate policies and nested lookup limits; temperror calls for resolving transient DNS/evaluation failures. An unaligned provider-domain spf=pass is not an SPF failure. Do not dismiss actual SPF defects because DKIM supplies DMARC success. SPF result meanings.
Test each production campaign/API route and relevant subaccount after ownership, default-sender or key changes. For example, a legacy application still submitting through the old account cannot be repaired by repeatedly replacing the new account’s DNS key. Pause that affected route during an unresolved identity mismatch and use the saved, owner-approved recovery plan to restore the last working configuration where feasible. Keep representative indirect-mail tests before considering stronger domain-wide enforcement.
Troubleshooting and frequently asked questions
What does “Valid DKIM not found” mean?
Compare the public value with the current account value, including the complete owner name. Check for an old key, truncated value or doubled suffix. Coordinate any replacement with the sending-account owner and verify again after caches update.
Why does SPF pass while DMARC fails?
The default bounce domain may pass SPF without aligning. Look for a valid DKIM signature using your verified domain, or review the separately configured custom bounce route. More root-domain includes cannot repair an unrelated envelope identity.
Should I regenerate DKIM when the domain belongs to another account?
Resolve account ownership first. Regenerating or replacing DNS does not release a domain from another account and may disrupt a working sender. Use support for ownership disputes or the documented Free-plan restriction.
Do I need to change my mailbox MX records?
Not for ordinary outbound sender authentication. Receiving through Inbox and inbound-notification features are separate projects. Leave working mailbox routing intact unless you intentionally undertake one of those changes.
Is verified authentication a delivery guarantee?
No. Preserve redacted headers, account status and DNS answers for each production route, then investigate recipient policy or reputation separately if messages still fail. For help distinguishing a successful signature from the aligned result DMARC uses, read EmailAuth’s raw DKIM results versus aligned DKIM policy results.
No account settings, DNS records or mail flows were changed or tested for this article. Production completion requires the public-DNS and delivered-message checks above.