Identify the Harmony sending route
This guide addresses the Poppulo Harmony email route described in Poppulo's current knowledge base. It is not a universal procedure for every product carrying the Poppulo name. Establish the enterprise account, sub-account, intended From domain, and actual delivery route before collecting DNS values. A communications team's successful internal delivery may reflect a gateway exception rather than domain authentication.
Poppulo describes account-assigned server pools and provides pool-specific IP details through Support or the Customer Success Manager. It also documents authenticated SMTP as an Enterprise Settings option applying across sub-accounts. Determine whether the organization uses the Poppulo server route or another SMTP route; do not assume that one account's test represents a different enterprise configuration. Poppulo Harmony allowlisting and authentication
Assign an enterprise administrator to the application change, a DNS administrator to public records, and a mail-security owner to the receiver tests. Record what each will approve. Keep an internal IP allowlist outside this DNS work unless it is explicitly part of the change. Expanding a gateway exception is not a substitute for finding why a signature is missing or unaligned.
Add the domain and retain the configuration
Poppulo's DKIM procedure uses Enterprise Settings > Email Domains > DKIM > Add domain. Enter the intended domain, copy the generated record types, owners, and values, then publish them at its DNS provider. Save Enterprise Settings before leaving: the provider warns that unsaved generated configuration is lost. After propagation, select Verify, then Save again; verification does not save the page automatically. Poppulo DKIM configuration
This save requirement should appear in the change record. Capture the domain and generated public values after the application state is retained, then compare them with DNS. Do not maintain a worksheet from an abandoned unsaved attempt while expecting a later attempt to use identical records. If two administrators are working concurrently, agree which saved configuration is authoritative before either publishes or removes anything.
A Pending state calls for investigation, not immediate regeneration. Confirm that the owner was created in the correct zone and that the DNS interface did not append the domain twice. Compare the actual public answer with the retained application values, including record type and complete target. Poppulo lists these checks and propagation time among its verification troubleshooting steps. Poppulo DKIM verification troubleshooting
Do not infer SPF alignment from allowlisting language
The Harmony technical overview states that customer-domain DKIM is supported, but its short SPF description is not a precise account-specific envelope specification. It sends customers to support for DMARC details. Obtain the actual SMTP envelope identity and supported configuration for the selected route rather than inventing a universal Poppulo SPF include or custom Return-Path setting. Poppulo authentication overview
SPF authorizes a sending host for an SMTP identity. DKIM verifies a signature associated with its d= domain and s= selector. DMARC then compares a successful authenticated domain with the visible From domain. A record added to the corporate root is not necessarily evaluated when the service uses another envelope domain. One passing aligned DKIM signature can satisfy DMARC even if another signature or unaligned SPF path does not. SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989
If the real message lacks an aligned path, stop at that finding. Ask the authorized support contact which configuration applies to the enterprise, route, and From domain. Do not weaken the organization's DMARC policy or add an entire shared IP pool to SPF merely because an internal newsletter failed. Preserve the current records while the correct change is established.
Test beyond the corporate gateway
Use a harmless test through the same workflow and From domain intended for production. Where authorized, include a receiver outside the corporate gateway so an internal allowlist cannot obscure the result. Retain full technical headers privately and create a sanitized identity table for review. A successful preview, a link click, or a delivered internal copy does not demonstrate aligned authentication at another receiver.
Record the receiver's trusted Authentication-Results alongside From, Return-Path, every DKIM d= and s= value, and the time. Check the actual signature domain against the configured domain and applicable alignment mode. A verified application state is useful setup evidence, but a later different From address or sending route can change the result.
For multiple sub-accounts, identify which domains and workflows share configuration and which require separate tests. When authenticated SMTP is involved, determine which system signs the final message and whether subsequent processing changes signed content. Treat that as a separate route assessment rather than asserting that Poppulo's domain verification covers a downstream relay.
Poppulo enterprise acceptance worksheet
These are fields to complete, not results already collected.
- Enterprise and route: account owner, sub-account, campaign or communication workflow, Poppulo server pool or authenticated SMTP, and intended From domain.
- Saved configuration: generated DNS values, first Save time, authoritative DNS owner, published answers, verification result, and final Save time.
- Receiver coverage: internal gateway behavior, applicable allowlist scope, authorized external test receiver, and message timestamps.
- Identity comparison: visible From, envelope domain, every signing domain and selector, trusted authentication results, and aligned passing path if present.
- Open questions: route-specific SPF or bounce-domain support requiring confirmation, unsupported product assumptions, and missing tests.
- Release decision: evidence owner, recovery configuration, business approval, security review, and editorial review state.
Fictional diagnosis of an unsaved verification
This scenario is fictional. An internal communications administrator sees Verified during setup and closes the page. A colleague later sends a campaign, and the security team finds no expected aligned signature at an external receiver. Internal recipients received the message because their gateway allowed the assigned sending IP range.
The team checks the retained enterprise configuration rather than treating delivery as proof. It discovers that the final Save step was omitted. The proposed repair is to restore and retain the intended domain configuration, compare DNS with the saved record set, verify, save, and retest the original workflow externally. No outcome is assumed: the received signing domain and receiver result must establish whether that repair resolves the issue.
Review and publication gates
First-party documentation was reviewed, but no Poppulo enterprise, DNS zone, gateway policy, support response, or live message was accessed. The exact product scope, saved application values, support-confirmed route, received alignment evidence, and human SME sign-off remain open. The manuscript is unpublished and requires rendered presentation review. Do not describe the entire Poppulo estate as authenticated from a single domain status or internally delivered message.
Close the configuration checkpoint before the route checkpoint
Keep separate entries for generated values retained, public DNS matching, verification retained and received alignment. In the fictional case, a missing expected signature does not establish that every signature failed; the remaining results are unspecified. Retesting must identify all passing aligned mechanisms before diagnosing the final DMARC outcome.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.