Emfluence SPF, DKIM and DMARC setup, step by step

For the emfluence Marketing Platform, publish the two documented DKIM CNAME records and then contact emfluence to activate signing. A green DNS check alone does not complete setup. Check the actual envelope sender before changing SPF, and coordinate migration across the account if it still uses the old DKIM method. emfluence DKIM setup

This guide covers email sent by the emfluence Marketing Platform, not every service offered by its marketing agency or your organization's employee mailbox system. This is a documentary walkthrough, not a report of account configuration, customer DNS testing or observed delivery.

For separate employee mail, use the Microsoft 365 authentication guide where applicable; its signing controls do not replace emfluence activation.

Confirm the sending domain and account state

Bring together the account administrator, DNS administrator and campaign owner. Identify every visible From domain in the account, including occasional event or regional campaigns. Save the current DNS zone and applicable DMARC policy before editing records.

Check whether the account uses the current dual-CNAME method or older TXT-based signing. emfluence says an account cannot mix the two methods: adding a domain to an old-method account requires moving the existing domains to the new method as well. Its current checker does not recognize old records as passing. Migration restriction

Make a migration inventory before touching DNS: domain, present selector, active campaigns, DNS owner and who will approve the signing switch. A red badge on an older configuration is not, by itself, proof that all historical mail has invalid signatures. Conversely, the existence of an older key is not evidence that the current account is using it.

The public documentation does not justify different targets by pricing plan or region. If your support-issued configuration differs, resolve the discrepancy with emfluence rather than generating a regional hostname yourself.

Publish the current two-selector DKIM records

The official current mapping is:

Both are published values, not invented tenant examples. emfluence manages the underlying keys. Confirm the mapping for your account before changing an established setup. Current DNS configuration

For a sending domain of example.com, the first full owner would be emfluence-k1._domainkey.example.com. Use the relative label only if the DNS editor appends that zone. For a separate sending subdomain, use the zone and full owner corresponding to that actual domain; do not accidentally sign a different identity.

For an issued signing domain such as news.example.com, the illustrative full owner is emfluence-k1._domainkey.news.example.com. In an editor relative to the parent example.com zone use emfluence-k1._domainkey.news; in a separately delegated news.example.com zone use emfluence-k1._domainkey; in a delegated _domainkey.news.example.com zone use only emfluence-k1. Repeat the mapping for emfluence-k2 and preserve both confirmed CNAME targets. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

A CNAME owner cannot also carry conflicting TXT, A or MX data. If a record already occupies either owner, find out which service uses it. Do not delete the record to silence a control-panel warning. Preserve other providers' DKIM selectors and all unrelated records.

Use DNS-only behavior for authentication aliases, not a web proxy or HTTP redirect. Record the exact before-and-after state, including TTL. You should never receive or publish a private signing key as part of this DNS task.

Activation is a separate emfluence step

After DNS resolves, inspect Options → Account Settings → Sending Domains and contact emfluence to confirm signing is activated. The official instructions explicitly require this provider-side step. They also direct customers to support for the separate Yahoo Feedback Loop verification value. Activation and feedback-loop prerequisites

Keep these states separate in your checklist:

1. Public DNS has the intended aliases and usable destination keys.
2. The account recognizes the sending domain.
3. emfluence confirms its signing configuration is active.
4. A received message carries a valid, aligned signature.

If migrating, agree on when the account-wide switch will occur and when old records can be retired. Do not remove the old public keys ahead of the signing transition or while delayed messages may still need them. Do not recreate the legacy method for a new domain just to match a historical screenshot.

What SPF record should emfluence use?

The official SenderID page states that SPF is already configured in the Platform account. It separately shows an older spf2.0/pra SenderID record. That string is not a v=spf1 SPF record and should not be relabeled as one. The page does not establish a universal new root SPF include for every current customer route. emfluence SenderID documentation

Ask support which MAIL FROM domain the account uses and whether a customer-managed SPF change is required for your configuration. Then compare that answer with a delivered message. A provider-owned envelope domain can pass SPF without aligning with your organization's visible From domain. A passing aligned DKIM signature can supply the DMARC pass instead.

SPF belongs at the exact envelope-domain owner that is evaluated. Publishing an include at a visually similar root domain does not automatically authorize a different subdomain. When an SPF change is explicitly required, maintain one SPF policy at that owner, preserve legitimate senders and the existing final policy, and put new mechanisms before all. Check nested processing against the ten evaluated DNS-lookup-causing-term limit, not just the number of includes on the first line. SPF specification

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Do not flatten provider records into guessed static IP lists, create duplicate SPF records, or weaken a hard-fail policy merely because an old example uses a soft fail.

Keep verification CNAMEs unflattened as well as DNS-only. Flattening can hide the CNAME answer the service expects even when proxying is off. Cloudflare CNAME verification guidance

Keep the required literal CNAME answer: turn relevant per-record Flatten off where available and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, apex CNAMEs are flattened by default and same-zone targets are flattened regardless of that setting; flatten-all cannot be overridden per record. If mandatory behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration without breaking other services or removing NS delegation. These are DNS-host behaviors, not controls assumed in the sending provider. Cloudflare flattening controls and limits.

Verify both selectors in public DNS

Replace SENDING_DOMAIN with the actual domain. These are read-only commands:

dig +short CNAME emfluence-k1._domainkey.SENDING_DOMAIN
dig +short CNAME emfluence-k2._domainkey.SENDING_DOMAIN
dig +short TXT emfluence-k1._domainkey.SENDING_DOMAIN
dig +short TXT emfluence-k2._domainkey.SENDING_DOMAIN
dig +short TXT _dmarc.SENDING_DOMAIN

Each CNAME should match the corresponding documented target. Follow the target when necessary to inspect its public-key TXT data. Do not expect both selectors to appear on every message: publishing two available selectors and observing the selector used by a particular signature are different checks.

If the answer is absent, first verify the full owner and authoritative DNS delegation. If authoritative servers disagree, fix that inconsistency before waiting on recursive caches. If only a cache is stale, compare TTLs and recheck later. A fixed delay cannot correct a doubled domain suffix or an incorrect record type.

After an actual message is available, query the exact MAIL FROM domain recorded by the receiver for SPF. Do not assume SENDING_DOMAIN above is also the SPF identity.

Use receiver evidence for acceptance

Send an authorized controlled campaign using the real From address and account route. Inspect the original message at the destination rather than a forwarded copy. In the receiver-added Authentication-Results, record SPF, DKIM and DMARC results along with their domains.

For DKIM, require a passing signature with the intended header.d; obtain the selector from s= in DKIM-Signature. A header containing a signature is not equivalent to a verified signature. The receiving server must actually validate it. DKIM verification

For DMARC, require dmarc=pass for the actual header.from, supported by at least one passing aligned path. Under strict alignment, the authenticated domain must exactly equal From; under relaxed alignment, they can share an organizational domain. Do not count an unaligned provider-domain SPF pass as customer-domain authentication. DMARC alignment

For completion of this branded DKIM setup, require a receiver-observed aligned DKIM pass as well as a DMARC pass for the intended From domain. A DMARC pass obtained only through SPF does not prove DKIM activation. Investigate SPF fail, permerror or temperror even if DKIM supplies the DMARC pass: inspect the actual envelope owner and authorization, invalid policies or evaluated lookup limits, and temporary DNS failures respectively.

Read only authentication results trusted by the receiving system; a header inserted outside its trust boundary can be misleading. Authentication-results trust boundary

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

An illustrative failure: both CNAMEs are correct and the domain shows green, but the received signer is unrelated to the selected From domain. Confirm account activation and campaign identity before editing valid CNAMEs. This is a diagnostic scenario, not a test performed for this guide.

Repeat acceptance for each domain affected by a migration. Keep message identifiers and timestamps so support can trace the relevant send. A mailbox's spam decision can still differ from its authentication result.

Preserve DMARC while adding emfluence

Keep an established p=quarantine or p=reject policy. Do not replace it with p=none just to onboard emfluence. If a new policy is needed, have the domain owner inventory legitimate senders and agree on monitoring and enforcement before publication.

Inspect the direct _dmarc.YOUR-FROM-DOMAIN TXT policy and any applicable inherited policy first. Only absent both, with owner-approved monitoring, use a first-policy example v=DMARC1; p=none; it requests no reports unless an authorized rua destination is added. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.

The current DMARC specification is RFC 9989; it removed pct. Do not describe an obsolete percentage tag as a dependable staged-rollout mechanism. Review aggregate data to distinguish emfluence from unrelated sending streams. Send reports only to an approved destination, including any necessary external reporting authorization. Aggregate reporting, RFC 9990

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Failure reports can include personal data and message content. They are not necessary simply to verify these CNAMEs and should not be enabled without a privacy decision. Failure reporting, RFC 9991

Troubleshooting

• Green check, but no aligned DKIM on received mail: contact emfluence about activation and supply the message identifier, actual From and observed signer. A DNS badge does not sign mail.
• Old TXT record works elsewhere but not in the account checker: inspect the account's method and coordinate the documented account-wide migration. Avoid mixing old and new setups.
• Only the first selector resolves: check the second owner separately. Do not stop after validating k1.
• SPF passes but DMARC fails: compare the SPF domain with From, then inspect DKIM signing and alignment. Do not add root includes blindly.
• DKIM passes but strict alignment fails: inspect the exact signer and From names. Ask for a supported matching identity rather than weakening adkim as the first response.
• Yahoo-related sending remains blocked: check the platform's DKIM and feedback-loop requirements with support. Do not assume a generic SPF change addresses complaint-monitoring prerequisites.