Emercury SPF, DKIM and DMARC setup, step by step

For Emercury Email Marketing, create and verify a Brand Profile, publish the documented DKIM TXT and SPF authorization, configure all four branded-domain CNAMEs, and complete the remaining profile checks. The current public SPF mechanism is include:spf1-srvs.em01.net; the published DKIM selector is em. A support-issued root TXT Verification Key is a separate requirement. Finally, inspect a delivered campaign to confirm the actual SPF identity, DKIM signing domain and DMARC alignment. Brand Profile setup, official SPF and DKIM records.

Which Emercury product does this guide cover?

This procedure is for Emercury Email Marketing Brand Profiles, formerly called Sender Profiles. It covers the domain and sender identity used for campaigns.

Emercury's separate SMTP service has its own API and requires a registered, confirmed Sender Signature. Do not assume that its keys, records or activation steps are the same as the marketing Brand Profile workflow. This article does not configure that service, SMTP credentials or application API sending. Separate Emercury SMTP documentation.

Have access to the correct marketing account, the From and Reply-To mailboxes, and authoritative DNS for the domain being authenticated. Save existing DNS first. Brand Profile allowances and delivery arrangements vary by plan, so do not assume unlimited profiles or a dedicated sending IP. Emercury plan information.

The records and checks you need

Do not stop after the three tracking/image names found in older instructions. Current branded-URL records, required profile steps.

1. Create the Brand Profile and verify its mailboxes

1. Open Settings → Brand Profiles → Add.
2. Enter the internal profile name and the From email address.
3. Complete ownership verification for the From address.
4. Choose the Reply-To address. If it differs from From, complete its separate verification too.
5. Identify the exact domain whose DNS the profile will authenticate.

Use an address your organization controls and can verify. A verified From mailbox proves mailbox access; it does not replace DNS authentication. Similarly, the Reply-To field directs replies but does not by itself supply SPF or DKIM alignment. Brand Profile creation.

If you are authenticating a subdomain, establish the correct full DNS owners before editing. The @ symbol means the root of the zone currently open in a DNS panel, not always the domain Emercury is verifying. A panel for example.com and a separately hosted panel for news.example.com use different relative owner names.

2. Publish the current Emercury DKIM TXT

It is a vendor-published public key, not described in that article as an account-generated unique key.

Before making a change, compare your current Brand Profile instructions with the live official article. If the account or support supplies a different selector or key, resolve which configuration applies to your account. Do not combine two competing keys or overwrite an active selector without confirming its signing dependency.

The documented record is:

v=DKIM1; g=*; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC75RQss0FsR1dIiQ8fJwD8RJlktEdllRbjHKZcMv8GBnCSqoyNzjuoA6Xn3sJkIw6ZR9eB4hiz1yEdJSVsQKnOCzfLfPFqFbC5z6fBNJ6h/JNHNkcRTaiSwQXxvtP4jpBRbzOoK8rxSDwvPITLhh63xgXomiGYmaMsWkIvVfBnhQIDAQAB

Source: Emercury's current published DKIM value. Confirm it again at implementation time rather than treating an archived copy as a permanent key-rotation authority.

Paste the complete value without extra text, smart quotes or inserted line breaks. Follow the DNS host's syntax: a web form may accept the value without enclosing quotes, while a zone file represents TXT strings differently. Multiple quoted character strings within one TXT record can be valid because DKIM concatenates them without inserting spaces; two separate competing TXT key records at one selector are not equivalent. DKIM key-record processing.

For em._domainkey.news.example.com, the relative owner is em._domainkey.news in an example.com zone, em._domainkey in a separately delegated news.example.com zone, or em in a separately delegated _domainkey.news.example.com zone. Preserve NS delegation, DNSSEC and existing selectors. Do not publish in a non-authoritative parent or remove delegation to force verification.

What about key strength and rotation?

Decoding the public key published above shows a 1024-bit RSA key. The DKIM cryptographic guidance requires at least 1024 bits and recommends at least 2048 bits. Ask Emercury whether a stronger or account-specific key and a supported rotation process are available for your account. DKIM key-size guidance.

Do not generate a replacement key yourself and put only its public half in DNS. Emercury would still be signing with a different private key, so verification would fail. The presence of a published public key is normal DKIM behavior and is not evidence of a private-key compromise. Any rotation must coordinate signing changes, DNS publication and retirement of old keys with the provider.

3. Add Emercury to the correct single SPF policy

For a domain with no existing SPF policy, Emercury publishes this TXT value:

v=spf1 include:spf1-srvs.em01.net ~all

Its instructions use @ for the owner. Confirm that the selected zone and owner represent the exact domain being authenticated. Do not blindly add the policy to your organization's apex if the profile is authenticating a different subdomain. Emercury SPF instructions.

If SPF already exists at that owner, edit that one policy to add include:spf1-srvs.em01.net before its final all mechanism. Preserve the existing legitimate senders and intended ending. Do not paste a second v=spf1 TXT beside it, and do not change an existing -all to ~all merely because the starter example uses softfail.

For illustration only, a policy authorizing the documentation-only address 192.0.2.10 would change as follows. Do not deploy this example IP as your sender:

Before: v=spf1 ip4:192.0.2.10 -all
After: v=spf1 ip4:192.0.2.10 include:spf1-srvs.em01.net -all

For a policy using redirect= or other complex routing, have the DNS/mail administrator reconcile the complete evaluation instead of appending text mechanically. SPF permits at most ten DNS-querying terms during evaluation, including nested include and redirect processing. a, mx, ptr and exists also count; the number of visible top-level includes is not the total lookup budget. SPF processing limits.

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.

A root SPF check does not prove SPF alignment

SPF is evaluated for the SMTP envelope sender, normally exposed as smtp.mailfrom by the receiver. It does not authenticate the visible From address directly, and SPF policies do not inherit automatically from the apex domain. SPF identity rules.

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.

Complete the documented profile SPF check, but also inspect a real campaign's envelope domain. The branded bounce field is described as used for delivery; the reviewed documentation does not promise an exact MAIL FROM value or an aligned SPF pass. Do not infer either from the field name or from publishing the root include.

If the receiver evaluates a provider-owned domain, its SPF policy must be investigated with Emercury. If it evaluates your bounce hostname, follow the real DNS chain and the actual receiver result. Do not add an SPF TXT alongside a CNAME at the same owner to force alignment.

4. Configure all four branded domains

Use unused names or resolve existing dependencies before assigning the documented hosts. Do not overwrite a working website, tracking integration or other service.

Publish the four CNAMEs from the record table above at the authoritative DNS provider. Keep authentication/delivery aliases DNS-only and preserve required CNAME responses; an HTTP proxy or flattening feature can hide the expected alias. Do not add https:// to a target. A CNAME owner cannot also hold independent ordinary TXT, MX, A or AAAA records. DNS CNAME rules.

For Cloudflare, set required aliases to DNS only. Where available, leave each record’s Flatten option off and check that CNAME flattening for all CNAME records is off; the zone-wide setting overrides per-record choices. Coordinate shared-setting changes with the DNS owner first, then query actual CNAME answers. 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 proxy behavior, Cloudflare flattening controls.

Preserve legitimate NS delegation for child zones, including _domainkey, and their DNSSEC records. Publish each selector in the zone actually authoritative for it, coordinating with that zone’s operator. Do not remove delegation merely to add a record in the parent. If a delegation conflicts with the requested CNAME owner, obtain a supported alternative. DNS-host delegation guidance.

Then return to Settings → Brand Profile, open Step 4 – Branded URLs, and enter the full names associated with your domain:

Choose Save Settings and use the system verification checks. Successful verification shows a green check mark. If the standard names conflict, get a supported hostname choice rather than silently substituting one without updating the profile. Branded-URL configuration and activation.

The SPF/DKIM article allows roughly 24–48 hours for some DNS updates, while the branded-URL article allows 24–72 hours. These are troubleshooting windows, not a requirement to wait out a wrong record. Compare authoritative answers and cached resolver answers before deciding that propagation is the only remaining issue.

5. Complete the profile's remaining activation requirements

Use Emercury's built-in checker to confirm SPF and DKIM. Complete organization and footer information, including the required address and alignment settings. Obtain the separate Verification Key through Emercury Support Chat and publish the root TXT record they supply for the specified domain. Preserve other unrelated TXT records at that owner.

Do not substitute the DKIM key, an arbitrary ownership token or an API credential for the Verification Key. The setup documentation treats it as a separate support-issued record. Required Brand Profile checks.

An incomplete profile's From Address will not appear as a campaign option. Also, new-account onboarding requires the contact list to be imported and approved before campaigns can send. A green DNS check does not replace either profile completion or account/list approval. Emercury onboarding gates.

6. Check DMARC without weakening existing protection

Inspect the DMARC policy for the visible From domain. For example.com, query _dmarc.example.com; for news.example.com, begin with _dmarc.news.example.com. If no valid direct record exists, current DMARC policy discovery may find an applicable organizational-domain or public-suffix policy through its DNS tree walk. A missing direct subdomain record does not necessarily mean there is no policy. DMARC policy discovery.

Preserve existing p, applicable subdomain policy, alignment modes and reporting destinations. Do not reset enforcement to monitoring solely to add Emercury. An explicit subdomain p=none can weaken protection previously inherited from its parent.

For a genuinely new setup with no direct or applicable inherited policy, publish a monitoring TXT only after the policy owner approves the monitoring plan while you inventory all legitimate senders. For example, at _dmarc.example.com, with a monitored mailbox your organization controls:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For _dmarc.example.com, use _dmarc in the example.com zone. For _dmarc.news.example.com, use _dmarc.news in that parent zone or _dmarc in the separately delegated news.example.com zone. Replace the example domain and mailbox; the value after mailto: must be the mailbox address only, not a second URI prefix. Publish only one DMARC policy at an owner. Monitoring does not request rejection of failing mail, and a successful Emercury test does not establish readiness to enforce policy for every other service using that domain.

Use only approved report recipients and review their access and retention arrangements. Aggregate reports expose sending IP addresses, domains, message counts and authentication outcomes. The external-authorization test in RFC 9990 compares the organizational domain of the domain from which the policy was retrieved with the organizational domain of the reporting URI’s host. Different hostnames under the same organizational domain do not alone trigger that test; when those organizational domains differ, the destination must authorize the relationship in DNS and the report-generating receiver must check that authorization before sending reports. This protocol check is distinct from the owner’s data-sharing/privacy approval. For a policy retrieved for example.com with rua=mailto:reports@reports.example.net, the report receiver normally authorizes it with a TXT containing v=DMARC1 at example.com._report._dmarc.reports.example.net. Use the actual domain from which the policy was retrieved; this authorization is published in the receiver's DNS. External reporting authorization.

DMARC requires an aligned pass from SPF or DKIM. For DKIM, compare the passing d= domain with the visible From domain. For SPF, compare the passing MAIL FROM domain. Relaxed alignment uses their organizational domain under DMARC discovery; strict adkim=s or aspf=s requires exact equality. A passing unrelated provider signature or envelope identity is insufficient by itself. DMARC alignment.

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.

7. Verify public DNS and a delivered campaign

Inspect DNS at the names actually configured

These examples assume the profile authenticates example.com. Change the owners for your chosen domain and any account-specific values.

dig +short NS example.com
dig +short TXT em._domainkey.example.com
dig +short TXT example.com
dig +short CNAME img.example.com
dig +short CNAME url.example.com
dig +short CNAME track.example.com
dig +short CNAME bounce.example.com
dig +short TXT _dmarc.example.com

Confirm one SPF policy at the intended owner, the full correct DKIM key, and all four expected CNAME targets. Check the separate support-issued Verification Key at the exact requested owner. Compare authoritative and recursive results to diagnose caches; use the delegated zone's nameservers where applicable.

Inspect the receiver's results, not just the profile checker

After all activation gates are satisfied and testing is authorized, send a representative campaign to a mailbox you control. Open its original-message view. Use receiver-controlled authentication diagnostics, or have the receiving mail administrator establish that its trust boundary strips or clearly distinguishes externally supplied Authentication-Results before relying on the result. A familiar authserv-id or header position alone does not establish provenance. Authentication-Results trust boundary.

Record these acceptance checks:

1. The intended Brand Profile and From domain were used.
2. The actual smtp.mailfrom domain and SPF result are identified.
3. The expected customer-domain DKIM signature is present and passes. Inspect its d= and s=, not just the existence of a DKIM-Signature header.
4. That signing domain aligns with the From domain under the applicable adkim mode.
5. The receiver reports dmarc=pass for the intended header.from, with the aligned mechanism identified.

An SPF-only DMARC pass does not complete the intended DKIM setup, and rewriting From to an unrelated fallback domain is not successful branded authentication.

If the delivered selector is not em, query selector._domainkey.signing-domain using the message's actual values and reconcile them with Emercury. Do not claim a root SPF check validates the bounce-domain result. Investigate SPF failures independently even if DKIM supplies the DMARC pass. Repeat for other Brand Profiles and materially different campaign paths.

Troubleshooting Emercury authentication

When escalating, include the profile, domain, failing DNS owner, observed value and redacted receiver results. Do not disclose passwords, API tokens, private keys or unnecessary recipient data.