Flywheel SPF, DKIM and DMARC setup, step by step

For Flywheel’s built-in website mail, configure sender authentication in the site’s Email Deliverability card and publish the exact CNAME records it generates. Do not assume that adding include:sendgrid.net to your root-domain SPF authenticates this route. If a WordPress plugin sends through your own SMTP or API provider instead, authenticate that provider separately. Finish with DNS checks and received-message evidence for the route the site actually uses.

This guide covers the managed Flywheel WordPress sending route and the boundary with a separately configured email provider. Flywheel does not supply personal or business inbox hosting. No Flywheel account, customer DNS or sending tests were accessed or changed. Flywheel email-service scope

Choose the authentication workflow for your route

Start from a representative website email, not from the company that registered the domain. Inventory password resets, contact-form notifications, store receipts and newsletters independently. One plugin may override WordPress mail while another uses an API directly.

Trace the actual SMTP or API service used by each WordPress application. Changing the website host does not automatically change your mailbox provider, and a successful staff-mailbox test says nothing about the store’s receipt emails.

Collect the visible From address, actual SMTP MAIL FROM domain, current DKIM d= and s=, authoritative DNS host, existing policies and a zone backup. Confirm access to the correct Flywheel site and a test mailbox. Keep credentials and private keys out of the DNS worksheet.

Configure the built in Flywheel sender

The managed workflow uses SendGrid through Flywheel. In the site’s Advanced tab:

1. Find Email Deliverability and choose Set up email.
2. Select the domain and choose Set Domain and Begin Setup. It must already be added to that site.
3. Copy every generated CNAME and publish it at the authoritative DNS host.
4. Return to Check Validation, complete Ok, I’m Done, and inspect the result.

An absent card requires Flywheel support. Orange indicates incomplete setup; red indicates failed record validation. After cloning a site or moving it to a new subscription, configure authentication again because the records are site-specific. Flywheel managed authentication

Keep the generated record list for the correct site and domain. Do not borrow another site’s CNAME targets or assume a copied WordPress database transfers the sending account’s authorization. If an old and new site need to coexist, coordinate the transition before replacing any shared owner names.

Flywheel’s public workflow gives the validation result as its completion step; it does not document a separate universal signing toggle or a customer-accessible SendGrid subuser console. Do not search for an invented control. If the card validates but the intended branded signature is missing, investigate the route and ask Flywheel to check its managed sender.

Understand where SPF is evaluated

SPF checks the connecting sending IP against the SMTP MAIL FROM domain, or HELO in applicable cases including a null reverse-path. That domain is often visible in Return-Path after delivery, but it need not match the From address readers see. A TXT policy at example.com is not inherited by bounce.example.com. SPF identity model

SendGrid’s automated-security model uses generated CNAMEs to delegate authentication, including the return-path subdomain and DKIM selector names. Its current domain-authentication documentation identifies the generated envelope-domain CNAME separately from the DKIM records. Use this to understand the record roles, not to invent Flywheel-specific targets or assume all direct SendGrid controls appear in Flywheel. SendGrid domain authentication

For a managed Flywheel setup, follow the generated records first. Then inspect smtp.mailfrom on a real received message and query that exact owner. If the envelope uses an unrelated provider domain, adding an include at your apex does not change the envelope identity or make SPF align. Resolve the managed-domain setup with Flywheel; do not make increasingly broad SPF authorizations to change a header the sender controls.

If a separate sender explicitly requires a TXT SPF change at an owner you control, merge its authorization into the existing v=spf1 policy. Keep one SPF policy at that owner, preserve other legitimate senders and retain the intended final qualifier. Do not add a second SPF record, insert a second version tag or use +all as a shortcut.

SPF ignores redirect= whenever any all mechanism is present, irrespective of ordering; mechanisms after all are unreachable. Preserve the approved qualifier and do not add an all that disables an existing redirected policy. Qualifiers specify SPF outcomes, not guaranteed delivery or rejection. RFC 7208 section 5.1.

Evaluate the full policy’s DNS-query-causing terms, including nested includes, redirects, a, mx, exists and ptr. The limit is 10 during evaluation, not 10 services listed in your editor. ip4 and ip6 do not consume that term budget. SPF lookup limits

Publish the generated DNS records safely

Use the authoritative DNS service, which may be separate from both Flywheel and the registrar. Do not change nameservers or mailbox MX records just to authenticate the built-in website sender.

Translate each generated owner into the format the DNS editor expects. This table illustrates roles only; none of its placeholder names or targets is a Flywheel-issued value.

For generated-selector._domainkey.news.example.com at a separately delegated news.example.com zone, use relative generated-selector._domainkey. If _domainkey.news.example.com itself is delegated, use generated-selector at that authority. Preserve its NS delegation, other selectors and DNSSEC. Do not publish at an inactive parent zone.

Copy the actual type and complete target from the account. Do not replace a generated CNAME with a guessed TXT public key. A CNAME owner must not be occupied by unrelated ordinary records. If an existing sender already uses the selector or envelope hostname, stop and ask for a supported alternative or coordinated migration. Do not delete it just to make validation turn green.

For CNAME targets, apply the DNS host’s fully qualified-name convention, including a terminal dot where required. Avoid doubling the zone suffix in either the owner or target. SendGrid authentication troubleshooting

For a required literal authentication CNAME in Cloudflare, use DNS only, turn the applicable per-record Flatten option off when available, and ensure CNAME flattening for all CNAME records does not conceal that alias. Coordinate any shared-zone setting change with affected owners rather than disabling it globally without review. DNS-only alone is insufficient. Cloudflare flattens apex CNAMEs by default and same-zone targets regardless of the setting. If mandatory behavior or shared dependencies prevent the required literal CNAME answer, stop and coordinate a supported configuration; do not invent a switch or delete NS delegations. Cloudflare CNAME verification, flattening controls.

Keep the sender’s generated values when following a DNS host’s interface instructions; verify that host’s relative-name and external-target conventions.

Verify DKIM signing and domain alignment

A DKIM signature identifies its signing domain in d= and selector in s=. Receivers retrieve the public key at selector._domainkey.signing-domain. A correct record at a guessed selector is irrelevant if the message uses another selector. A CNAME delegation must lead to a usable public key. DKIM key discovery

Keep both requirements in your acceptance checklist:

• The intended custom-domain signature is present and verifies successfully.
• Its signing domain aligns with the visible From domain under the domain’s DMARC policy.

An additional platform-domain signature may pass without satisfying either requirement for your brand. Do not declare custom DKIM successful because a mail client shows one generic green DKIM result. Identify the signature associated with that result.

For a fictional From: news@example.com, a passing intended signature with d=mail.example.com aligns in relaxed mode (assuming the same Organizational Domain), but not strict mode. A passing d=example.com matches exactly under both modes. These illustrate comparison, not measured provider defaults. Do not accept a rewritten provider-owned From as successful authentication of the intended brand. DMARC alignment.

See raw DKIM results versus aligned DKIM results when a signature passes without authenticating the intended visible identity.

Publishing records does not create a mailbox or authorize arbitrary From domains. Use a From address on a domain you control and have configured. For a contact form, put the visitor’s address in Reply-To rather than impersonating the visitor’s domain in From. This gives replies a useful destination without making the website claim to be the visitor’s email service.

Handle your own SMTP or API provider separately

A plugin configured with your own email-provider account is a separate authentication project. Confirm its actual mailer, account, credentials, From override and return-path behavior. Authenticate the domain inside that account, publish its issued records, then test through the plugin’s real application path. Do not assume Flywheel’s managed sender status covers it.

For a direct SendGrid account, use its Settings → Sender Authentication workflow. Twilio documents automated-security and manual-record modes, custom return-path and selector options, and EU-pinned domains for regional accounts. Those are direct-account controls, not established capabilities of Flywheel’s managed card. Take region-specific values only from the relevant account. Current SendGrid account workflow

Flywheel documents that outbound port 25 is unavailable; external providers need a supported alternate port or an API. Its built-in mail has plan-dependent limits and limited diagnostic visibility, so larger or business-critical streams may need a dedicated sending provider. A DNS change cannot fix a blocked port, exhausted limit or unauthenticated SMTP connection. Flywheel transport and limits

Do not paste SMTP passwords or API keys into DNS, public tickets or examples. Account configuration and DNS publication are separate responsibilities even when one person performs both.

Keep DMARC policy and reporting under domain owner control

DMARC requires a passing SPF result aligned with the visible From domain or a passing aligned DKIM signature. Relaxed alignment permits the same organizational domain; strict alignment requires an exact match. A branded bounce subdomain can align with an apex From under relaxed SPF alignment while failing strict SPF alignment. That can be an intentional limitation when exact aligned DKIM passes; it is different from SPF itself returning an error. Current DMARC specification

Inspect the existing policy for the From domain and any applicable parent policy. Do not replace p=quarantine or p=reject with a provider’s sample p=none, and do not add a competing DMARC record. If the existing policy is strict, satisfy it or obtain an intentional domain-owner policy decision, rather than weakening it to hide a mismatch.

Only with domain-owner approval, no direct or applicable inherited policy and an appropriate monitoring plan, an illustrative monitoring record is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

Publish the new value as TXT at _dmarc.example.com: in the example.com zone, the relative Name is _dmarc. For a policy specifically covering a From domain of news.example.com, the full owner is _dmarc.news.example.com. Enter _dmarc.news in the parent example.com zone, or _dmarc if news.example.com is a separately delegated authoritative zone. Follow the DNS host’s full-name convention if it does not use relative names. Do not add a child policy merely to replace an applicable inherited policy. DMARC policy publication

Replace the address with an authorized, working destination. Aggregate reports provide source and authentication evidence; they are not a complete delivery log. When the Organizational Domain of the report destination host differs from that of the domain where the DMARC policy was found, the report-generating receiver must check DNS authorization for the destination. Destinations within the same Organizational Domain are excepted; a different hostname alone does not trigger that requirement. DNS authorization does not replace the domain owner’s approval of the recipient and report-data sharing. RFC 9990 section 4.

Review reports for both website and mailbox traffic before advancing policy. Keep the existing reporting setup intact during a website move. Current DMARC standards supersede RFC 7489 and remove its pct tag, so a new rollout should not depend on percentage enforcement. Separate overlooked applications from unauthorized sources when reviewing reports.

Run a DNS and delivered message acceptance test

These commands are templates, not completed tests. Substitute the actual zone, active authoritative nameserver, generated envelope hostname and selector. Repeat the authoritative checks against each active nameserver.

dig +short NS example.com
dig @ns1.dns-host.example generated-bounce.example.com CNAME +noall +answer
dig @ns1.dns-host.example generated-selector._domainkey.example.com CNAME +noall +answer
dig @ns1.dns-host.example _dmarc.example.com TXT +noall +answer
dig +short TXT generated-bounce.example.com
dig +short TXT generated-selector._domainkey.example.com
dig +short TXT _dmarc.example.com

For each CNAME, compare the answer with the account-issued target and query that target’s TXT record as well. The envelope path should resolve to the sender’s SPF authorization; the selector path should resolve to a usable public key. Do not add TXT beside a CNAME because a checker queried the wrong name. An empty DKIM p= revokes a key; a lookup that returns no answer does not prove all DKIM is absent.

Next, generate harmless-content controlled messages through the real production paths: a password reset, contact-form notification and order email where applicable. Use only test recipients you control. A plugin’s own test button may not cover a form plugin’s separate API path.

Inspect the final recipient system’s trusted Authentication-Results and retain the following observations. Do not trust an arbitrary similarly named header supplied upstream. Use results produced inside the actual receiving service’s known mail-processing boundary, and ask its administrator how externally supplied Authentication-Results fields are removed or excluded from trusted evaluation. A familiar authserv-id or header position alone does not prove origin. Ignore attacker-supplied results. RFC 8601 section 7.1.

Investigate SPF fail, softfail, none, temperror or permerror even when aligned DKIM allows DMARC to pass. An unrelated-domain SPF pass is an alignment issue, not an SPF failure. Record that distinction explicitly. Connect the actual envelope identity with its authoritative DNS owner before changing authorization.

Troubleshoot before changing more DNS

If a publication change breaks another sender, restore only the affected known-good records and coordinate the sender configuration too. Do not revert the entire zone blindly. Keep old selectors while queued messages or another active site still require them, and retire them only as part of a deliberate transition. Preserve test evidence before and after the fix.