Poppulo SPF, DKIM and DMARC setup, step by step

For Poppulo Harmony email, configure customer-domain DKIM in Enterprise Settings, publish the generated DNS records, and save both the initial configuration and the verified result. Check SPF against the actual envelope sender used by your route. An internal allowlist or a message arriving in an employee's inbox is not proof of aligned authentication. Poppulo DKIM setup, Harmony sending routes.

This guide covers the Poppulo Harmony email workflow documented in its knowledge base. It does not assign the same records to digital signage, every Poppulo product, or an independently operated outbound SMTP relay. No customer account, DNS configuration, gateway or delivered message was tested.

Start with the enterprise and delivery route

Before changing DNS, record the enterprise, relevant sub-accounts, communication workflow, intended From address and current route. Poppulo describes assigned sending-server pools, with pool details supplied by Support or the Customer Success Manager. It also documents authenticated SMTP as an Enterprise Settings option that applies across sub-accounts. Ask which route your organization actually uses. Poppulo's technical overview.

The route determines what needs testing. A server-pool newsletter, a message relayed through your corporate mail service and a different sub-account's communication should not be accepted on the strength of one unrelated preview.

If the selected corporate relay is Microsoft 365, EmailAuth’s Microsoft 365 authentication guide covers that separate sender configuration. Confirm which system signs the final Poppulo route rather than assuming the relay’s settings cover all sub-accounts.

Prepare three owners: someone permitted to manage the domain in Poppulo, the authoritative DNS administrator, and the mail-security administrator who can interpret receiver results. Retain the current DNS values and application state before changes. Do not alter the corporate MX records, inbound gateway rules or employee mailbox setup as a side effect of adding DKIM.

Verify trusted sending domains before selecting addresses

Poppulo separately requires domain-ownership verification. An Enterprise Administrator can open Enterprise Settings > Settings > Account Settings > Trusted Sender Domains; without that license, work with Poppulo Support. Add each domain, copy its generated TXT name and value, publish that exact record, save DNS, then return to complete verification. Only verified domains are available in both From and Reply-To. Generic mailbox domains such as Gmail are unsupported. Poppulo allows up to 48 hours for DNS propagation. Trusted Sending Domains.

This ownership TXT is not an SPF authorization or a DKIM public key. Keep it alongside other legitimate TXT records without overwriting them. If From and Reply-To use different domains, include both in the ownership checks. Successful ownership validation does not remove the separate DKIM configuration and message-test requirements below.

Configure DKIM and retain both saves

You need DNS access and permission to manage domain settings. Follow this sequence in Enterprise Settings > Email Domains > DKIM:

1. Choose Add domain and enter the intended sending domain.
2. Copy every generated record's type, full owner and complete value or target.
3. Publish the matching records with your DNS administrator.
4. Select Save on Enterprise Settings before leaving. Unsaved generated configuration can be lost.
5. After DNS is available, return, compare the displayed values with DNS and select Verify.
6. When verification succeeds, select Save again. Verify does not automatically retain the page changes.

The documented state changes from Pending to Verified. Official DKIM configuration and verification.

Use the account-generated record set rather than another customer's selector or an old screenshot. The public procedure does not prescribe one universal selector, key or record count. Preserve the issued record type: a CNAME target and a TXT public key are not interchangeable. Never publish a private signing key.

If an administrator abandoned an unsaved attempt, compare the currently retained configuration before using the earlier worksheet. Do not assume two attempts generated identical values. Avoid repeated regeneration while an unchanged correct record is merely cached.

Put each record at the exact DNS owner

The following table demonstrates DNS naming only. selector-from-account is a placeholder for the selector actually issued by Poppulo, not a value to publish.

Use the authoritative zone. If news.example.com is delegated elsewhere, adding the child record in an inactive copy of the parent zone will not fix public DNS. In a panel that appends the zone name, entering the entire owner can create an erroneous name such as selector-from-account._domainkey.example.com.example.com.

For an existing separately delegated _domainkey.news.example.com namespace, full owner selector-from-account._domainkey.news.example.com maps to relative selector-from-account there. Use the actual issued selector and type, preserving the NS delegation and other selectors. Relative DNS names.

For a generated CNAME, check that no other ordinary data already occupies the same owner; a CNAME cannot coexist with a TXT public key or another service's record at that name. Resolve conflicts rather than deleting unrelated records. Preserve the exact target and use DNS-only resolution where a DNS host offers web proxying. For TXT, preserve the entire public value without inserting spaces into the key. Multiple DNS presentation strings within one TXT record can be valid and are not separate records. DNS alias restrictions, DKIM key lookup.

Keep generated authentication CNAMEs as visible, unflattened aliases. On Cloudflare, check both the record-level Flatten control and the zone-wide setting that flattens all CNAMEs; DNS-only by itself is insufficient when either still hides the alias. Have the DNS owner assess other services before changing a shared setting, and do not remove an intentional delegation merely to pass verification. Recheck that public DNS returns the exact issued CNAME. 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.

Understand what Poppulo SPF does and does not prove

SPF evaluates the sending IP against the SMTP MAIL FROM identity, normally recorded as the delivered Return-Path. It does not authenticate the visible From address merely because that address looks corporate. With a null reverse-path, SPF uses the HELO identity. SPF identities.

Poppulo's short allowlisting overview uses “Sender: from” wording and directs customers to Support for DMARC details. It is not an account-specific specification of the envelope domain, branded bounce options or a universal SPF include. Do not invent an include:poppulo.com rule, assume a corporate-root SPF edit is required, or turn a list of inbound allowlist IPs into an outbound authorization without route-specific instructions. Poppulo authentication overview.

Obtain the following for the selected route:

• The expected MAIL FROM domain and who operates its DNS.
• Whether a customer-domain SPF change is needed and the exact approved owner and authorization.
• Whether a branded return path is supported for this enterprise and how it is activated.
• For authenticated SMTP, which final outbound service signs and supplies the envelope identity.

If the service uses its own envelope domain, SPF can pass without aligning with your From domain. A passing, aligned customer-domain DKIM signature can still provide DMARC authentication. If SPF actually fails, that is a separate fault to diagnose, not something to dismiss as “normal because DKIM works.”

If a supported change to customer SPF is required, merge it into the one SPF record at the exact owner. Preserve existing legitimate senders and the final qualifier; do not add a second v=spf1 record or use +all. SPF does not inherit from the parent: example.com and bounce.example.com are different lookup names. Check the complete recursive evaluation against SPF's ten DNS-querying-term limit, including nested includes and redirects, rather than counting only visible includes. SPF record selection and processing limits.

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.

Preserve DMARC policy and establish reporting

DMARC compares the visible From domain with an authenticated identity. A message passes when SPF passes and aligns, or when at least one DKIM signature passes and aligns. DKIM alignment uses the signature's d= domain. Relaxed alignment permits the applicable organizational-domain relationship; strict adkim=s or aspf=s requires an exact match. DMARC alignment.

Inspect the existing policy at the From domain and any applicable parent policy. A missing _dmarc.news.example.com record does not mean news.example.com is unprotected. Preserve established enforcement, reporting recipients and alignment settings. Do not add a relaxed monitoring policy under an enforced parent just to accommodate a broken newsletter route.

Only for a domain with no applicable established policy, and after its owner approves monitored deployment, this is an illustrative starting record:

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

Replace the example names and establish a monitored report destination first. For this owner, the relative name is _dmarc.news in the example.com zone, or _dmarc in the delegated news.example.com zone. Keep one DMARC record at that owner. A reporting service outside the applicable organizational domain needs external-report authorization. Aggregate reports help identify legitimate routes and authentication failures; absence of a report does not prove absence of mail. Aggregate reporting.

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. For an owner-approved first policy at apex From domain example.com, full TXT owner _dmarc.example.com maps to relative _dmarc in the example.com zone. Preserve the direct/inherited-policy safeguards above.

Review employee mail, applications, forwarding and mailing lists before enforcement changes. The current DMARC specification requires valid DKIM when publishing p=reject; do not use one aligned-SPF test as the entire reject-policy decision. Failure reports can expose message information, so ruf needs a deliberate privacy review rather than automatic inclusion. DMARC policy considerations, failure reporting.

Verify public DNS before testing delivery

These are read-only examples for an administrator to adapt, not results already collected. Replace the selector, domain and resolver placeholders. Use the issued record type and check every generated record.

dig +short CNAME selector-from-account._domainkey.news.example.com
dig +short TXT selector-from-account._domainkey.news.example.com
dig +short TXT actual-envelope-domain.example.com
dig +short TXT _dmarc.news.example.com
dig +short TXT _dmarc.example.com
dig @authoritative-nameserver.example TXT selector-from-account._domainkey.news.example.com
dig @recursive-resolver.example TXT selector-from-account._domainkey.news.example.com

Expected observations:

• A generated CNAME returns the exact target, with a usable downstream DKIM key. A TXT configuration returns the complete issued public record.
• Authoritative answers match the saved Poppulo configuration. Recursive answers converge as cached TTLs expire. A blank answer is not a pass; investigate the owner, type, delegation and DNS response status.
• The SPF policy is looked up at the actual envelope identity, not automatically the corporate apex.
• DMARC discovery establishes the applicable policy rather than treating a missing child record as permission to weaken protection.

Complete Poppulo verification and retain its saved result. Public DNS alone cannot show whether a message has been signed with the intended key.

Require a branded, aligned DKIM pass on the real route

Arrange an authorized, harmless message through the actual employee-communications workflow after the configuration is retained. Include a controlled external receiver where permitted, so internal gateway exceptions cannot hide the authentication outcome. Do not send confidential employee content merely to test identity.

Use the recipient system's trusted Authentication-Results, not an arbitrary sender-supplied header. Record UTC time, route, visible From, actual smtp.mailfrom, each DKIM d= and s=, and the SPF, DKIM and DMARC results. Trusted authentication results.

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.

Accept the setup only when:

1. The received From domain is the intended one.
2. The intended customer-domain DKIM signature both passes and aligns under the applicable policy. A provider-domain signature or an unrelated signature is not sufficient evidence that your branded DKIM setup works.
3. SPF passes for the actual expected envelope identity, or a failure has been investigated and corrected before launch. Record SPF alignment separately: a passing provider envelope may legitimately be unaligned.
4. DMARC passes through an identified aligned mechanism. A DMARC pass supplied only by SPF must not conceal a missing or broken intended DKIM signature.
5. Each materially different relay, sub-account and From-domain route has its own acceptance evidence.

For example, From updates@news.example.com and a passing DKIM signature with d=news.example.com can align exactly. SPF for an unrelated provider envelope may pass but remain unaligned. Conversely, dkim=pass for only a provider-owned domain does not prove Poppulo is signing as news.example.com.

Authentication does not guarantee inbox placement. Inspect bounces, filtering, recipient permissions and message quality separately.

Troubleshoot Poppulo without broad DNS changes

Keep the approved prior configuration and a rollback plan. If the new route fails, pause that route or use the established approved sender while investigating. Share sanitized headers and public record values with the authorized support contact, not credentials or private keys.