Scope and provider-specific configuration
Symplify documents sender-domain authentication using SPF, DKIM and DMARC. Its newer bulk-sender article clarifies the transition from the older k5 DKIM selector to dkim2048. Use that current behavior when assessing a domain rather than treating any historical key as proof of the intended signing route.
Inventory the domain used in Sender Address and its existing authentication records. The sender-domain guide publishes the SPF baseline v=spf1 include:carmamail.com ~all. Merge the required include with other authorized services in a single policy. Do not replace an established policy or adopt the baseline's ending without reviewing the complete sending inventory and lookup budget.
For DKIM, the newer guide says Symplify signs with a 2048-bit key using selector dkim2048. Publish the current provider public key as TXT at dkim2048._domainkey.<your-domain>. Copy the uninterrupted key from the current source rather than transcribing a long key from a screenshot or this article. If a DNS editor needs multiple character strings because of its 255-character string limit, they must form one logical TXT record. Do not turn the chunks into independent competing key records or add spaces inside the public-key material.
The provider explains that when only k5._domainkey exists it continues using the older key until dkim2048 is added. With neither key published, Symplify signs using its own domain, and that signature does not align with the customer's From domain. This is why a generic DKIM pass is not sufficient acceptance evidence. Read the actual d= and s= values on the received campaign.
Publish or review the applicable DMARC policy. The provider offers p=none as a starting point and a reporting-address example, but the mailbox must be real and authorized. Do not downgrade an existing policy to mirror an example. Symplify offers setup verification through domainsetup@symplify.com; asking that team is a separate communication requiring authorization. Authentication also does not replace recipient permission, list hygiene or a visible unsubscribe link. The newer guide says one-click unsubscribe headers are added by the service, while a visible link remains the template owner's responsibility.
The decision that matters
Confirm the dkim2048 signature aligns with the customer’s From domain rather than accepting a provider-domain DKIM pass.
Verify the published records and the real sending path
Record the change owner, sending product, domain, approved maintenance window and prior DNS answers before editing. Obtain the current record values from the named account or documented provider workflow. Separate values supplied by the provider from choices your organization controls, such as DMARC policy and reporting recipients. Existing mailbox MX, unrelated verification TXT records and active DKIM selectors are not cleanup candidates merely because a new service is being added.
Query the authoritative name servers for each exact owner and record type after publication. Record the query time, responding server and complete answer. Compare TXT strings as one logical value where the DNS response splits them into character strings. Check CNAME targets as well as the starting alias. Then compare a recursive-resolver answer to identify caching differences. A successful provider validation is useful evidence of configuration, but it does not establish what an actual recipient received.
Send only an authorized test to a controlled recipient using the intended product route. Retain the raw message and the trusted receiving system's Authentication-Results. Record the visible From domain, SMTP MAIL FROM or observed Return-Path domain, every DKIM d= and s= value, SPF and DKIM outcomes, and the receiver's DMARC result. A passing SPF or DKIM check supports DMARC only when its authenticated domain aligns with the visible From domain under the applicable policy. Reply-To and a branded display name are not alignment identities. RFC 7208, RFC 6376 and RFC 9989 provide the protocol basis for these distinctions.
Acceptance worksheet, recovery and evidence limits
This is an original acceptance worksheet, not a report of live testing. Mark each gate pending until evidence exists: account scope confirmed; previous DNS captured; exact new owner/type/value published; provider verification complete; intended route exercised; received identities recorded; aligned authentication confirmed; other senders unaffected. Assign a person and evidence file to every gate. A red gate blocks rollout even when the provider dashboard is green.
If a test fails, first distinguish missing publication, stale cached data, inactive provider configuration, wrong outbound route and nonaligned authentication. Correct the smallest demonstrated defect and test again. Do not weaken DMARC or delete other senders' records simply to make one test pass. If a change harms existing mail, use the approved recovery plan and the captured pre-change configuration, coordinating any provider-side sender change as well as DNS. Retain old keys while queued messages or an approved overlap still require them.
No customer tenant, authoritative before/after change or real received message was available for this manuscript. The retained sources support the documentary workflow; they do not satisfy the commissioned live-evidence gate. Independent checker review and human SME approval remain pending. Do not describe this guide as field-validated or publish it as having passed those gates.
Treat the fallback signature as incomplete evidence
Written case SY-01 assumes a campaign has From news@example.org, neither customer-domain selector is published, and the hypothetical receiver shows a passing signature from an unrelated provider domain. The exact provider domain, selector and SPF result are deliberately unknown, so no complete DMARC verdict is asserted. The DNS owner should reconcile the intended dkim2048 record with the campaign owner, then obtain a controlled received message. Do not label a generic DKIM pass as customer-domain alignment or change enforcement to hide the missing identity. No campaign, verification email or DNS action occurred.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.