Source review dated 8 November 2026. Provider settings and acceptance exercises below are documentary guidance, not executed account, DNS or message tests.
Confirm which service sends the MailPoet message
MailPoet is a WordPress plugin with more than one sending route. Its Send With settings distinguish the MailPoet Sending Service from web-host sending and SMTP or third-party delivery. Those alternatives do not inherit one universal authentication configuration. Start in MailPoet > Settings > Send With and record the selected method, WordPress site, account owner, default sender and affected newsletter or automation. MailPoet sending-method settings.
For the MailPoet Sending Service, license-key activation links the site to the service, and a qualifying key can activate that sending method automatically. The setup guide distinguishes previews using authorized addresses from bulk sending, which requires sender-domain DKIM and DMARC. Check the method again after an account or key change rather than assuming the prior transport remained selected. Sending Service setup.
Save the current settings and DNS baseline before changing anything. Identify newsletters, welcome messages, post notifications and WooCommerce-related messages that the business actually sends through MailPoet. Other WordPress mail can follow a different route, so do not use a successful site-password email to approve an untested newsletter. Give every material workflow its own test row and owner.
Match the From address to the right account
The domain to authenticate is the domain in the email's actual From address. It may differ from the WordPress website domain. Choose a domain the organization controls and a legitimate monitored address appropriate for replies. Record both the default sender and any sender set inside existing messages; a template-level value can persist after a global setting is edited.
MailPoet's address-authorization guide says that verified sender domains authorize their addresses automatically. For individual-address authorization, it uses a confirmation email. It also directs troubleshooting toward the account associated with Key Activation, the default sender and existing emails, including welcome, post notification and WooCommerce messages. Authorizing MailPoet From addresses.
Treat authorization as an account control, not evidence that the received message passes DMARC. If a preview succeeds while a scheduled campaign remains blocked, compare the accounts and From addresses before editing DNS again. Avoid using a free mailbox domain as if your organization could publish its DKIM records. Where a sender rewrite is observed, record the actual received From rather than the value displayed in the editor.
Publish the Sender Domain records from the account
Use the site authentication prompt or the MailPoet account's Sender Domains page. Add the intended domain if needed, copy its exact records, publish them and manually run Verify DNS records after propagation. The current guide specifies two CNAMEs and two TXT records and permits an existing valid DMARC value to differ from its default. MailPoet domain-authentication procedure.
Prepare a DNS change sheet containing owner, type, value, TTL and purpose for each requested record. Preserve other providers' selectors and unrelated TXT values. Compare the authoritative answer with the full owner shown in the account, allowing for a DNS interface that appends the zone automatically. Keep the record contents account-specific: a recognizable selector name does not authorize reuse of another customer's target or verification token.
If the domain already has DMARC enforcement and reporting, review its syntax and scope with the mail-security owner. Do not replace it with a monitoring-only default simply to make an onboarding screen match. Retain the established reporting destinations unless an approved policy change is part of the task. A provider setup wizard is not the owner of the organization's broader anti-spoofing policy.
Understand why provider SPF can remain unaligned
MailPoet documents that the Sending Service manages SPF for its provider envelope domain, sendingservice.net, and that this SPF identity is expected to be unaligned with the customer's domain. The intended customer-domain DMARC path therefore depends on appropriate DKIM authentication and alignment, not adding a guessed MailPoet SPF mechanism to the customer's root. MailPoet Sending Service SPF explanation.
Precisely, SPF evaluates SMTP MAIL FROM or, in the relevant protocol circumstances, HELO. It does not evaluate the visible From merely because a simplified setup explanation calls that address the sender. DKIM uses the signature's d= domain and s= selector. DMARC can pass when an aligned DKIM signature passes even if a different, unaligned envelope identity passes SPF. Inspect the effective alignment mode and received domains rather than inferring alignment from a brand name. SPF, DKIM and DMARC.
For an Other sending method, the host or actual delivery provider owns the relevant SMTP and signing configuration. MailPoet directs those users to their host or third-party service for SPF/DKIM help. Establish that provider's current account-specific records and test its route separately; the Sending Service's envelope behavior is not a claim about every SMTP plugin or host. MailPoet non-delivery guidance.
Diagnose verification and sending as separate problems
The domain guide identifies duplicated zone names, missing or conflicting values, and Cloudflare proxy or flattening behavior as verification problems. It also describes a sending pause when an enforced DMARC policy lacks the needed MailPoet DKIM setup. Correct the relevant authentication records and reverify rather than treating weaker DMARC enforcement as the fix. MailPoet verification troubleshooting.
Use the smallest DNS change needed. If a CNAME is obscured by a DNS feature, ask the DNS owner to inspect that record's behavior and dependencies before changing zone-wide settings. Confirm that public answers contain the intended delegation rather than merely an address response. Keep the diagnostic outcome specific: missing record, wrong owner, wrong target, conflicting type, stale answer or unresolved provider verification.
When no message arrives, check account state and the selected sending method as well as authentication. MailPoet documents separate causes including suspension, recipient restrictions and host sending limits. Use a controlled, deliverable non-role test mailbox and check spam folders before concluding DNS is the only explanation. MailPoet missing-newsletter checklist.
Prove each real workflow with a received message
Create an original identity table with site, MailPoet account, sending method, message type, template or automation, timestamp, configured From and received From. Add Reply-To, Return-Path, trusted receiver SPF identity/result, every DKIM d=/s=/result, DMARC result and observed alignment. Link restricted original-message evidence and contemporaneous DNS answers. Record expected identities separately from actual results and leave untested routes explicitly pending.
Send harmless content through the real workflow: a newsletter test for the newsletter route and an appropriate controlled trigger for each active automation. A preview can be a useful preliminary check, but do not let it stand in for a scheduled message that uses a different sender. Test replies and unsubscribe behavior separately. Where WooCommerce messages are in scope, use approved test orders or an existing safe test workflow rather than creating customer-facing transactions solely for authentication testing.
Compare receiver results before and after the change. If DKIM passes but DMARC fails, inspect whether the passing signature aligns with the received From. If the signature fails, compare its selector and public key path and consider whether message modification occurred. Preserve the evidence needed to distinguish a DNS problem from a transport or content problem.
Recover and approve the complete route
Pause the affected newsletter or automation when its identities remain unresolved. Restore the last approved sender and transport configuration where appropriate, with DNS changes reviewed against the saved baseline. If changing to another delivery service is necessary, obtain approval and complete that service's own authentication process before resuming. Retest after any restoration rather than assuming rollback itself proves recovery.
No WordPress installation, MailPoet tenant, live customer DNS or received message was inspected here. First-party guidance supports the described product branches, but it does not fill the original evidence requirement. The exact-route received-message identity table, tenant applicability and human mail-security SME approval remain required before publication or production acceptance.