Emma SPF, DKIM and DMARC setup, step by step

On this page: Scope and preparation · Publish DKIM records and activate the correct account · Review SPF without mistaking it for alignment · Keep DMARC protection intact · Verify DNS first, then a delivered campaign · Troubleshoot the account, not just the zone · Frequently asked questions

Authenticate Emma with its three DKIM CNAME records, account verification and the final domain save in Emma. Tiered accounts can apply parent authentication to same-domain subaccounts; separately configured accounts need their own verification TXT values. Review SPF separately: adding Emma to your domain’s SPF policy does not make Emma’s provider-owned Return-Path align with your visible From domain. Your aligned DKIM signature is therefore essential.

This guide covers Emma marketing-email accounts, including standalone and tiered accounts. It does not configure another Marigold product, your staff mailbox service or a website’s SMTP plugin. No customer account, DNS zone or delivered message was tested for this article.

Scope and preparation

Use a domain you control, identify its authoritative DNS host, and obtain access to the relevant Emma account settings. List the default From address, authenticated domain and accountable administrator for every sending account. An agency login is not evidence that every client account has been configured.

Emma currently allows one authenticated domain per account or subaccount. Standalone Lite and Plus accounts lack subaccounts; tiered accounts can use different domains in different subaccounts. The standard independent-account setup uses three shared CNAMEs for each domain and account-specific verification. Same-domain tiered accounts have a parent-inheritance option described below. Emma DKIM setup

Before editing DNS, export existing records and note their TTLs. Preserve unrelated TXT verification tokens, mailbox SPF authorizations and other services’ DKIM selectors. A domain registrar and authoritative DNS host are not necessarily the same company. Changing records in an inactive DNS zone will not help Emma validate anything.

Publish DKIM records and activate the correct account

The current official workflow is Account → Deliverability. Confirm that the default sender in Sender info uses the intended domain. Obtain that account’s validation hash, publish the records below, then enter the domain in the DKIM domain field and save. Publishing DNS alone is not activation. For separately configured accounts or different-domain subaccounts, complete the relevant account-specific verification. Current setup and final validation

For same-domain tiered accounts, complete DKIM in the parent and select “Apply changes to all existing subaccounts” during final validation. That applies the parent setup without separate TXT records for each covered subaccount; future subaccounts inherit the parent configuration. Configure different-domain exceptions separately. Review the affected subaccounts before applying a parent-wide change. Emma parent-inheritance FAQ

YOUR_ACCOUNT_HASH is a placeholder, not a usable token. Obtain its replacement from the account being authenticated. The CNAME targets are provider-published values; the hash is account-specific. Never generate a replacement DKIM key yourself for this hosted service.

For a sending domain of example.com, the first full owner is e2ma-k1._domainkey.example.com. If your DNS editor appends example.com automatically, enter only the relative owner. Review the saved full name to catch duplicated suffixes. CNAME owners cannot also contain conflicting TXT or other records. Investigate an existing owner before replacing it; do not remove another service’s key to make a form accept your entry.

Keep authentication CNAMEs DNS-only rather than behind an HTTP proxy, and disable CNAME flattening for these owners so the published aliases remain visible. Emma manages the signing keys and rotation through those aliases. Its FAQ permits removing the verification TXT after completed setup, but requires retaining the CNAMEs. Leaving the verification token documented until all accounts have completed their work avoids an unnecessary multi-account troubleshooting variable. Emma authentication FAQ

Review SPF without mistaking it for alignment

Emma’s SPF setup page recommends include:_spf.e2ma.net. For an existing SPF policy, incorporate that mechanism into the single policy at the appropriate owner, before its terminal all mechanism, preserving other authorized senders and the existing policy qualifier. Do not publish a second v=spf1 record. The account’s SPF status check is available after DKIM setup in Account → Deliverability. Emma SPF instructions

For a domain used only for the documented Emma authorization, a reviewed starting example is:

Owner: example.com
Type: TXT
Value: v=spf1 include:_spf.e2ma.net ~all

This is not a replacement for your existing combined policy. Count DNS-lookup-causing terms across nested includes and redirects, not just visible includes. SPF permits at most ten such terms during an evaluation; exceeding the limit produces an error rather than extra authorization. SPF evaluates the SMTP envelope sender, not the address your reader sees. SPF specification

Emma documents e2ma.net as its Return-Path domain and explains that SPF remains unaligned even after adding its include. A green SPF badge therefore answers a different question from DMARC alignment. Do not repeatedly edit your apex SPF in an attempt to change the provider’s envelope identity. Emma authentication overview, alignment FAQ

If staff email also comes from Google Workspace, preserve that separate authorization and validate the staff route separately. The existing Google Workspace aliases and secondary-domain guide addresses identity choices Emma cannot configure.

Keep DMARC protection intact

DMARC passes when either SPF passes and aligns or DKIM passes and aligns with the visible From domain. Relaxed alignment permits the same organizational domain; strict alignment requires the exact domain. Enforcement policy and alignment mode are separate controls. Current DMARC standard, RFC 9989

Look for an existing DMARC record at the From domain and any applicable parent policy before creating a record. A missing record at _dmarc.news.example.com does not prove news.example.com has no protection: its parent’s policy may apply. Adding a child p=none record can weaken inherited enforcement.

Only when there is no established applicable policy, and a monitoring rollout has been approved, use this illustrative record for example.com:

Owner: _dmarc.example.com
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Replace the example domain and reporting mailbox with your controlled domain and an authorized, functioning report destination. Semicolons separate tags; mailto: belongs before the reporting address. Publish one DMARC record at that owner. An external report destination may require additional authorization from its operator. Monitoring does not block spoofed messages. Do not copy a reporting address belonging to a vendor without arranging that service.

Keep an established quarantine or reject policy intact while fixing Emma. Do not add the removed pct tag as a new rollout technique; RFC 9989 supersedes RFC 7489. Make an enforcement decision only after reviewing all legitimate senders, not just one campaign.

Emma’s documented tiered-account subdomain exception has product-specific policy restrictions. Do not weaken DMARC to fit that exception. Where exact-domain or enforcement requirements conflict with the account arrangement, obtain a supported configuration for the actual subaccount and From domain. General relaxed-alignment behavior does not override Emma’s stated product constraints. Emma domain limitations

Verify DNS first, then a delivered campaign

The following are read-only examples. Substitute your real domain before running them:

dig +short CNAME e2ma-k1._domainkey.example.com
dig +short CNAME e2ma-k2._domainkey.example.com
dig +short CNAME e2ma-k3._domainkey.example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com

Expect each CNAME to match the corresponding Emma target. Inspect TXT output for the correct verification token and one complete SPF policy. Resolve the DKIM target’s TXT record to inspect its public key if needed. Empty output is a symptom to investigate, not permission to delete existing records. Check authoritative answers, then recursive caches and TTLs.

After successful account activation, send an authorized campaign to a controlled mailbox using the real From address and originating subaccount. In the receiving system, inspect raw headers or Show original. Accept authentication evidence from the trusted receiver’s Authentication-Results, not an arbitrary header a sender could insert. Header trust boundary

Record the visible From domain, smtp.mailfrom, DKIM header.d, signature selector and DMARC result. A successful acceptance sample should show a passing, aligned DKIM signature and dmarc=pass for the intended From domain. SPF may pass for Emma’s domain without aligning. A second passing DKIM signature from an unrelated domain does not replace the aligned one you need.

Troubleshoot the account, not just the zone

One account works and another fails: determine whether the failing subaccount should inherit the parent’s same-domain setup or has its own different-domain configuration. Check the parent apply setting, saved DKIM domain and sender. For independent configurations, compare the account-specific hashes. Reusing CNAMEs does not make hashes interchangeable.

DNS resolves but validation fails: inspect the full owner names, hidden whitespace, wrong k1/k2/k3 pairing and proxy settings. Confirm the token belongs to the selected account. Waiting cannot fix a misspelled owner.

The dashboard passes but DMARC fails: compare the delivered From domain to DKIM d= and the published alignment mode. Check whether the campaign came from a different subaccount than the one you completed.

SPF status fails despite a managed SPF service: Emma warns its checker may not recognize flattened records. Ask the DNS administrator to evaluate the real policy before adding duplicate authorization. A checker mismatch and an actual receiver SPF failure are different incidents. Emma SPF checker limits

A receiver reports an actual SPF failure: do not dismiss spf=fail, permerror or temperror as normal nonalignment. Identify the tested envelope domain and sending IP, then investigate authorization or DNS errors with the relevant domain owner, even if aligned DKIM lets DMARC pass.

Authentication passes but internal mail bounces: collect the rejection text and gateway trace. Do not disable organization-wide anti-spoofing or broadly allowlist everything from a shared provider merely to clear one incident.