MailPoet SPF, DKIM and DMARC setup, step by step

MailPoet Sending Service handles SPF on its own envelope domain. Authenticate your branded From domain with MailPoet's issued DKIM records and a valid DMARC policy; adding a MailPoet include to your website's root SPF does not create alignment. If the plugin sends through an external SMTP provider, configure that provider instead. MailPoet authentication guidance

Identify the route before editing DNS

MailPoet is both a WordPress email tool and a sending service. Those roles are not interchangeable. Write down the selected sending method, newsletter From address, website URL, account owner and DNS host. The domain after the From address's @ sign is the authentication scope; a website at shop.example.com does not mean that mail from news@example.com needs records beneath shop.example.com.

Check MailPoet > Settings > Send With… in WordPress. For MailPoet Sending Service, the plan must include sending and its license key must be activated under Settings > Key Activation. MailPoet says key validation automatically selects its sending service, so recheck this setting after a license change. Localhost or firewall restrictions can prevent activation; investigate with the administrator rather than disabling security controls or silently switching routes. Account approval and individually authorized preview addresses are separate from bulk-send domain authentication. Sending Service setup

For external SMTP or API delivery, retrieve authentication instructions from that service's account. For hosting-server delivery, ask the hosting administrator which system signs outgoing messages. Do not combine unrelated selectors from a MailPoet article, a hosting panel and an SMTP provider simply because all three appear on the same website. A WordPress contact form may also use a different transport from newsletters; test it separately. Sending-method branches

Check Settings > Basics > Default sender and the From stored in existing welcome emails, post notifications and WooCommerce messages. Confirm that the license key belongs to the account whose domain is authorized. Domain verification authorizes addresses under that domain; individual-address confirmation is a separate account control, not DMARC proof. From-address authorization

Obtain the domain's records and activate authentication

Open Sender Domains in your MailPoet account or choose Authenticate domain in the WordPress authentication notice. Add the actual From domain, then copy the displayed records into a worksheet. The current workflow uses two DKIM CNAMEs and two TXT records, including domain verification and DMARC. Typical owners are mailpoet1._domainkey, mailpoet2._domainkey, _mailpoet and _dmarc. Copy the account's targets and verification value, not another customer's screenshot. After publication, manually run Verify DNS records; waiting alone does not necessarily recheck the WordPress notice. Current DNS workflow

Use a worksheet with full owner, type, account-issued value, existing value, TTL and purpose. Obtain an authorized account operator and DNS administrator; the public guidance does not establish one universal role name. This exposes a conflict before an administrator replaces a working record. Retain a screenshot or text export of the issued public records, the account/domain they belong to and the date. Do not record passwords, license keys or SMTP secrets in that worksheet.

Publish CNAME targets as hostnames, not URLs. They must not contain https://, path components or copied quotation marks. Publish the verification TXT value exactly, preserving its character order. DMARC is the exception to blindly copying a generated default: an existing valid policy must be retained and reviewed as described below.

The CNAMEs delegate public-key discovery to the service. They are not keys you generate yourself. A third-party DKIM generator cannot configure MailPoet's private signing key. Also, do not replace both CNAMEs with one guessed TXT record at default._domainkey; obtain the active selector from the account or a real signature. DKIM selector and key model

Keep DNS changes narrow and reversible

Export the current zone and note its authoritative nameservers. The domain registrar and DNS operator may differ. Changes in an inactive registrar zone will never satisfy MailPoet's check, regardless of how long you wait.

Use the account's complete owners and map them to the zone actually authoritative for each name. These are illustrative owner mappings, not issued records:

Apply the same mapping to the second issued selector. For _mailpoet.news.example.com, use _mailpoet.news in the parent zone or _mailpoet in the delegated child zone, not in a delegated _domainkey zone. Preserve NS delegations and coordinate with their operators. Never remove a delegation just to expose an editor. Inspect each saved full owner for a duplicated suffix. DKIM DNS discovery

A CNAME owner cannot also hold an ordinary TXT, MX, A or another CNAME value. If a required selector already belongs to another service, stop and resolve ownership instead of deleting it. Separate DKIM selectors can coexist for separate senders. Do not change the website address records or corporate inbound MX to authenticate newsletters. An existing _mailpoet value may reflect another account; determine which account is still in use before replacement.

MailPoet flags proxying and flattening as possible verification failures. Required CNAME answers must remain DNS-only and unflattened, with the account's literal target publicly visible. In Cloudflare, disable the affected record's Flatten option where available and ensure the applicable zone-wide setting does not suppress the issued literal aliases. A flatten-all setting overrides the per-record choice; coordinate a supported zone configuration that preserves these CNAME answers. Coordinate shared settings rather than changing the whole zone blindly. Mandatory apex or same-zone flattening may not offer an off switch; if it prevents the required answer, stop and agree a supported configuration with the DNS host and MailPoet. Do not move the selector to a different owner or remove shared delegations. Cloudflare flattening controls and domain-verification implications

Understand SPF pass versus SPF alignment

SPF checks the SMTP MAIL FROM identity, or HELO in applicable cases such as a null reverse path; delivered Return-Path generally exposes the envelope sender. It does not authenticate the human-readable From address by itself. MailPoet's managed service uses its own sending-service envelope identity, so a passing SPF result for that domain can coexist with unaligned SPF for your brand. A root-domain edit does not change the envelope identity. Custom aligned DKIM is the important DMARC path for this route.

If an external SMTP service instructs you to add SPF, apply its instructions to the relevant owner. Preserve other legitimate senders and maintain exactly one v=spf1 policy there. Merge mechanisms rather than entire policy strings, retain the intended final all qualifier, and check recursive evaluation against the ten DNS-lookup-causing-term limit. Counting only visible top-level includes is insufficient. Any all mechanism makes redirect ignored, regardless of qualifier. Preserve a redirect-only policy’s intended control flow rather than appending all or merging another complete policy. Qualifiers do not guarantee a receiver’s final delivery decision. SPF evaluation and redirect precedence SPF specification

Add DMARC without undoing existing protection

First inspect the policy for the exact From domain and any applicable inherited parent policy. A subdomain with no local record is not necessarily unprotected. Do not replace p=reject or p=quarantine, remove reporting destinations, or introduce a child p=none exception merely to clear a setup warning.

Only if no direct or applicable inherited policy exists at all, including p=none, and the domain owner approves a monitoring plan, a first-policy example is:

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

For From addresses at news.example.com, the local policy owner is _dmarc.news.example.com. Use _dmarc.news in the parent example.com zone, or _dmarc when editing a separately delegated news.example.com zone. Confirm the full saved owner. For an aggregate-report destination in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain is excepted; a different hostname alone does not make it external. Use the report service’s issued authorization, not a guessed record. RFC 9990 section 4 Protocol authorization does not replace the domain owner’s approval to share report data with that recipient. Review privacy, access and retention before enabling it.

Replace the example domain and the mailbox address after the existing mailto: prefix with your approved, provisioned destination; do not duplicate mailto:. Keep semicolons between tags and publish one DMARC policy at that owner. An external reporting service supplies its own destination and may require reporting authorization. p=none requests monitoring, not blocking; review all authorized senders before moving to enforcement. Current DMARC specification, RFC 9989

DMARC passes when either SPF passes with alignment or a DKIM signature passes with alignment. Relaxed alignment permits the same organizational domain; strict alignment requires an exact domain match. For example, with visible From news@example.com, a passing signature with d=news.example.com aligns under relaxed DKIM alignment (assuming the same Organizational Domain), but not strict alignment. A passing intended signature with d=example.com aligns under either mode. These are hypothetical identities, not a claim about your issued signature. An authentication pass for an unrelated provider domain is not enough. Alignment rules RFC 9989 supersedes RFC 7489 and removes pct; do not copy that legacy tag into a new rollout plan.

Verify public records, then verify a delivered newsletter

Replace the example domain and use the actual issued owners:

dig +short NS example.com
dig +short CNAME mailpoet1._domainkey.example.com
dig +short CNAME mailpoet2._domainkey.example.com
dig +short TXT _mailpoet.example.com
dig +short TXT _dmarc.example.com

Both CNAME answers must match the account's targets. The verification TXT must match the issued value, and DMARC must be the single intended policy. Compare authoritative and recursive answers when they disagree. Negative caches can retain a previous missing-record response; repeated editing can make diagnosis harder. Once DNS is correct, run MailPoet's check again and record the result.

Next send a newly generated newsletter through the same production route and From domain to a mailbox you control. Inspect the raw message, not a screenshot of a green account badge. Establish the receiving service’s actual processing boundary through its documentation or administrator: results must originate inside that boundary, and externally supplied Authentication-Results must be removed or isolated from trusted results, or corroborated by an authenticated receiver trace. A familiar authserv-id or header position alone proves nothing. Ignore sender-inserted fields; leave acceptance pending if provenance cannot be established. Record spf with smtp.mailfrom, dkim with header.d, and dmarc with header.from; record s= from the corresponding DKIM signature. Header trust boundaries

For the managed service, success means the intended branded DKIM signature passes and aligns, and the trusted receiver reports dmarc=pass for the intended From domain. Provider-domain SPF can pass without aligning. Investigate SPF fail (authorization mismatch), temperror (temporary evaluation/DNS problem) and permerror (invalid policy or evaluation limits) separately, even if DKIM makes DMARC pass. Do not “fix” managed-envelope errors by adding an unrelated apex include. A rewritten provider From is not successful authentication of the intended brand. Preserve a redacted message and timestamp, configured and received From, Reply-To, selected account/transport and all evaluated signature identities. Keep expected values separate from observed results. Repeat for materially different newsletter, automation and transactional routes; a preview does not demonstrate every application path.

Troubleshooting and frequently asked questions

Why does MailPoet still say authentication is pending?

Separate missing public DNS from stale provider status. Check the full owner names, types, exact targets and authoritative zone, then manually verify again. If the account shows a different expected token, establish whether you are in the right MailPoet account before changing DNS.

What if no test newsletter arrives?

Use a controlled, valid, non-role recipient. Check spam folders, account suspension and sending limits as well as DNS; MailPoet documents recipient restrictions separately. Do not confuse an unsent message with a failed receiver authentication result. Missing-newsletter troubleshooting

Why did sending stop after enabling DMARC enforcement?

Check the actual branded DKIM signature and selected From domain. Repair the signing path rather than lowering the domain's security policy. A passing signature for a provider domain cannot substitute for your aligned signature. If mail never leaves the service, resolve its account/domain validation error first; there is no delivered header to inspect yet.

Can I authenticate a Gmail or Yahoo From address?

You cannot publish those providers' domain authentication records. Use a branded domain you control and authorize the intended sender. Changing only Reply-To does not change the From domain that DMARC evaluates.

Do I need another SPF record for MailPoet?

Not for the managed Sending Service route described here. External SMTP has different requirements. Preserve the SPF policy used by corporate mail and other services rather than deleting it because MailPoet manages its own envelope SPF.

Does a passing test guarantee inbox placement?

No. Authentication establishes identity evidence, not recipient consent, reputation or message quality. If the receiver reports aligned passes but places the newsletter in spam, investigate complaints, audience permission and sending patterns separately instead of repeatedly regenerating DKIM.

Related configuration and review scope

Read EmailAuth's distinction between raw DKIM results and aligned DKIM policy results when a green signature result conflicts with DMARC. Employee mail and newsletters may use different transports even when the visible domain matches.

Keep unresolved routes paused. Restore only an approved account/sender configuration, review DNS against the baseline, and retest after restoration. Obtain owner approval before switching services. For WooCommerce tests use an approved safe workflow, not a customer-facing purchase; test replies and unsubscribe behavior separately from authentication.

MailPoet’s authentication-page structured metadata records an update of 31 October 2026; that publisher timestamp is separate from this documentary check. No customer account was configured, DNS changed or delivery test performed for this guide. Complete account, authoritative DNS, signing and trusted received-message checks for every material production route. Authentication does not guarantee inbox placement.