WP Engine SPF, DKIM and DMARC setup, step by step

For WP Engine's default WordPress mail route, the documented SPF authorization is include:relay.mailchannels.net, added to the appropriate existing SPF policy. WP Engine directs customers to their email provider for DKIM values and recommends an external sending service for greater control. If you need branded DKIM and dependable DMARC alignment, authenticate a domain with the chosen sender, connect WordPress to it, and verify real delivered messages. WP Engine email-authentication guidance

This guide covers WordPress-generated email on WP Engine, including password resets, contact forms and order notifications. It distinguishes the default relay from a separately configured SMTP or API provider. A website hosted at WP Engine does not make WP Engine the sender of every email using your domain.

Map the event to its actual sending service

Inventory each mail-producing plugin and event. Record the production or staging environment, From address, transport, sending account and any fallback behavior. Identify both the domain visitors see and the identity used to handle bounces.

Keep this inventory with the DNS change. A successful plugin test proves neither that every event uses the plugin nor that a receipt's From address matches the test address.

WP Engine does not provide email-hosting MX or DKIM values, does not host DNS, and does not publish a universal default-route customer DKIM selector. Do not assume a direct MailChannels account tutorial applies to a hosted relay you cannot administer. WP Engine sending guide, WP Engine SPF and DKIM guidance

Configure SPF for the route you actually use

SPF authenticates the envelope MAIL FROM domain against the connecting sender's IP. The visible From address is a separate identity. Read the trusted receiver's smtp.mailfrom result to establish which domain was checked. Root-domain SPF does not automatically apply to a different envelope subdomain. SPF identity and policy discovery

For the default WP Engine MailChannels route, WP Engine documents this standalone example:

v=spf1 include:relay.mailchannels.net ~all

Use it only after checking the actual sending identity and all other authorized senders. Where a policy already exists at the required owner, merge the include into that policy rather than adding a second v=spf1 record. Preserve its intended qualifier and existing authorizations. An external SMTP/API route needs its own provider's instructions, not this default-relay include merely because WordPress runs on WP Engine. WP Engine SPF instructions

A correct include is authorization, not proof of alignment. If the message uses a provider-owned envelope domain, changing example.com SPF will not make that identity match example.com. If it uses bounce.example.com, relaxed SPF alignment with From example.com is possible, but strict aspf=s requires an exact domain match. DMARC SPF alignment

Before saving an SPF change:

• Export the previous policy and identify every sender it authorizes.
• Preserve unrelated TXT records and the existing terminal all qualifier. Review redirect and nested policies rather than appending text blindly.
• Keep one SPF policy per owner. Multiple quoted strings within one TXT record are different from multiple SPF TXT records.
• Check the full evaluation against the limit of ten DNS-querying mechanisms and modifiers, including nested includes.
• Avoid static IP lists copied from today's provider DNS, which can become stale.

These checks prevent a website-mail repair from causing SPF permanent errors for corporate mail. SPF record rules, SPF 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.

Obtain DKIM from the external sender

A DNS key alone does not make WordPress or the default relay sign with it. The reviewed WP Engine documentation does not establish a customer-controlled branded-DKIM activation workflow for the default relay. Treat custom signing on that route as unverified, not as a feature enabled by an online key generator. Do not upload a private key to a web-accessible directory. WP Engine DKIM boundary

For an external provider, first confirm the intended account, region, plan and domain. You need permission to authenticate that domain, access to authoritative DNS and a supported WordPress integration. Obtain the complete generated record set and determine whether successful DNS verification also activates signing or whether a separate enable action is required.

As one concrete external option, SendGrid's domain-authentication workflow starts at Settings → Sender Authentication → Domain Authentication → Get Started. Enter the intended From domain, choose the appropriate advanced settings and publish the account-generated records. With automated security enabled, use the supplied return-path and DKIM CNAMEs. Return to Verify, then use the matching From domain for actual sending. Do not copy example account numbers or replace an existing DMARC record with the wizard's p=none example. SendGrid domain authentication

For more detail on that option, see the SendGrid authentication guide. Other services may issue TXT public keys, different selectors or multiple rotation records. Do not convert a TXT requirement into a guessed CNAME or assume a familiar selector such as default applies.

Only publish public-key material or the provider's delegation targets. Keep existing selectors for other services. If a new CNAME owner already holds a TXT, A or other ordinary record, obtain a supported alternate owner rather than deleting the existing service. DKIM DNS lookup, CNAME coexistence rule

Connect WordPress without losing the authenticated route

WP Engine documents this integration order: validate the external sender's domain, activate a compatible plugin, then enter the provider-supplied host, port, encryption and authentication details. API-based services may offer their own integration. Port 25 is blocked; use a provider-supported alternative, such as 587, 465 or 2525, with its required encryption, or a supported API. WP Engine SMTP configuration and ports

WP Engine’s published port guidance makes a specific exception for Microsoft Office 365 SMTP: use port 587, not the general alternatives above. Keep the selected provider’s required encryption and account settings. WP Engine email ports.

Set the plugin's From address to an authorized address on the authenticated domain. Inspect event-specific overrides. In a contact form, use the visitor address as Reply-To rather than impersonating it in From. Verify that a credential or connection failure does not silently revert the message to a different route.

Keep credentials in the plugin's supported secure configuration, not in public diagnostic posts. Do not assume a display-name change affects the envelope identity. For branded bounce domains, use the sending provider's supported setup and the custom MAIL FROM alignment guide, then verify the actual message.

Changing persistent integration credentials or expanding application access requires separate approval from the responsible security owner. If repair fails, pause the affected workflow or restore its previously approved transport without silently falling back to unauthenticated customer mail. Preserve keys needed by queued messages; retire unused credentials and DNS delegations through the authorized change process and retest each affected event.

Publish records in the correct DNS zone

Use the DNS service named by the domain's authoritative nameservers, which may differ from its registrar. WP Engine does not host these records. Do not replace inbound mailbox MX records merely to authenticate an external outbound sender. WP Engine DNS responsibility

The following fictional names illustrate owner mapping. site1 is an example selector, not a WP Engine selector. Replace it with the provider-generated value.

For a delegated child, publish in its child zone, not in an inactive parent-zone copy. Inspect the resulting FQDN to catch duplicated suffixes. Preserve the exact CNAME target and use DNS resolution rather than an HTTP redirect. If your DNS provider offers web proxying, authentication records must remain available as the required DNS records.

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. At an existing delegated _domainkey.notify.example.com authority, illustrative full owner site1._domainkey.notify.example.com maps to relative site1. Substitute the actual issued selector, preserve NS delegation and other selectors. Relative names.

If the external provider issues a bounce CNAME, do not add an SPF TXT record at that same owner. If it issues a bounce TXT plus MX set instead, apply that specific mode without replacing the organization's mailbox MX records. DNS record type is part of the provider's configuration, not a stylistic choice.

For that separately selected TXT/MX bounce mode only, the routing owner must approve the exact full owner and complete numeric-priority/target MX set before publication or activation. A provider packet alone does not approve new routing. Compare the complete approved set at its authoritative nameservers and a recursive resolver; stop on missing, extra or mismatched records, and preserve normal mailbox MX and delegated authority.

Preserve DMARC and make reports actionable

DMARC requires an aligned SPF pass or an aligned DKIM pass. Relaxed alignment compares organizational domains; strict alignment requires an exact match. A DKIM signature with d=example.com can align with From example.com in either mode, while d=notify.example.com aligns with it only in relaxed mode. Check the applied adkim and aspf settings. DMARC alignment rules

Retain an existing enforcement policy and report destinations. Inspect the From domain's policy and applicable parent policy, including sp, before treating a child domain as unprotected. Do not reset the domain to monitoring just because one website event fails.

RFC 9989 section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Review legitimate forwarded and mailing-list routes separately; a single aligned SPF test does not authorize a policy change. Enforcement readiness.

If there is no established policy and a monitored rollout is appropriate, this is an illustrative starting structure, not a record to copy unchanged:

Before this first TXT policy is published, confirm there is no direct or applicable inherited policy and obtain the domain owner’s explicit approval of the monitoring and review plan. Use only a provisioned approved report destination; preserve existing policy.

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

Use an arranged reporting destination. External destinations may need authorization at the report recipient's domain. Review reports across website and non-website senders before considering enforcement changes. p=none does not produce DMARC pass and does not guarantee a receiver will deliver a message. DMARC reporting and external destinations

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.

The DMARC aggregate report guide helps separate old default-relay traffic from the new provider after a migration.

Acceptance tests: DNS first, real messages second

Substitute actual owners and selectors in this read-only checklist. These commands were not executed against a customer domain for this article.

dig +short NS example.com
dig +short NS notify.example.com
dig +short TXT example.com
dig +short TXT bounce.example.com
dig +short CNAME bounce.example.com
dig +short CNAME site1._domainkey.example.com
dig +short TXT site1._domainkey.example.com
dig +short TXT _dmarc.example.com

The SPF query must cover the envelope domain actually used. Confirm only one SPF policy where a TXT policy is required. For delegated SPF or DKIM, confirm the exact CNAME target and its resolving data. For DKIM TXT, verify the complete public key. Compare authoritative responses with an independent recursive resolver; missing data, NXDOMAIN and SERVFAIL require different diagnoses. A green provider badge is not a delivered-message result.

Use approved synthetic accounts and harmless controlled events on the actual intended route to exercise password resets, contact forms, receipt templates and scheduled notifications. Do not reset a real customer’s credentials, perform a real payment/refund, or trigger customer communications merely to obtain headers. If no safe representative workflow exists, leave that test pending and arrange one with the application owner. Start with a direct external test mailbox; inspect its original message and receiver evidence. 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. Diagnose the actual smtp.mailfrom result independently: fail or softfail calls for checking the connecting sender against the approved authorization; temperror is a transient evaluation failure, often DNS; permerror requires checking malformed or duplicate policies and the evaluated lookup budget. An aligned DKIM pass does not repair these SPF faults. Do not change an unrelated apex policy to fix a provider-controlled envelope domain. SPF result definitions.

For an external branded-DKIM implementation, accept the change only when:

1. The event reached the intended provider account and used the intended visible From address.
2. The intended branded signature returns dkim=pass, and header.d aligns under the actual adkim setting. Do not substitute a second provider-owned passing signature.
3. The actual SPF result is inspected. Resolve unexpected fail, softfail, permerror, temperror or none using the real envelope domain, route and sender IP. A nonaligned SPF pass is different from an SPF error, but a DKIM-based DMARC pass does not excuse an actual SPF defect.
4. DMARC passes through an identified aligned mechanism. An SPF-only DMARC pass does not prove the DKIM deployment is complete.
5. Delivery/rejection evidence and provider events agree with the tested route. Inbox placement remains a separate outcome.

For the default route, document what the headers actually show without claiming a customer signing feature the reviewed documentation does not establish. If the default route cannot meet your branded authentication requirement, move that event to the authenticated external sender.

For the separately selected external route, match the intended active provider signature’s d= and s= to its configured domain and selector. Require that signature to pass and align under effective adkim with the unchanged intended visible From, plus the trusted receiver’s dmarc=pass; a different aligned signer or rewritten From is not branded completion. DMARC alignment.

Troubleshooting WP Engine mail

The SMTP connection times out

Check the selected provider endpoint, encryption and supported port. A port-25 configuration conflicts with WP Engine's published restriction. Do not turn off encryption or switch to an arbitrary port just to make a connection succeed.

Password resets work but a campaign or batch fails

Confirm the transport. WP Engine describes an undisclosed hourly limit for its default service and no built-in sending logs or monitoring. Use the external sender's event history and quotas for mail routed there; do not invent a fixed WP Engine messages-per-hour allowance. WP Engine limits and logging

SPF passes but DMARC fails

Compare the envelope domain with From and inspect branded DKIM. If the passing identities belong to another organization, the failure is alignment, not a missing allowlist entry at your apex.

Domain verification passes but DKIM does not

Check whether the real event uses the authenticated account, the expected From domain and the current selector. Compare provider-generated records with public DNS, then check whether another gateway altered signed content after signing.

Mail broke after pointing the website to WP Engine

Inspect MX targets and mail-host aliases. A mail hostname that aliases the website apex can be redirected unintentionally when that apex changes. Correct the mail routing with the email provider's actual values rather than copying a website IP. WP Engine post-migration mail troubleshooting

Documentation review and verification limits

No account configuration, DNS change or live message test was performed for this article. Verify generated values, current product access, public DNS and delivered headers in the intended environment before declaring the implementation complete.