Identify the Front sending route
Front can present similar inboxes while using different outbound transports. Start by recording the channel type, address, domain and account owner. Distinguish Gmail or Office 365 synchronization, SMTP forwarding with Front-provided authentication, and custom SMTP. Do not authorize a second delivery service simply because a mailbox appears in Front.
Front's deliverability documentation says native Gmail and Office 365 sync use the providers' APIs and do not need Front's additional SPF/DKIM records. SMTP-forwarded channels, including Google Groups configured that way, require a separate assessment. Custom SMTP uses the chosen server; follow that server's authentication requirements. This route distinction is the most important prerequisite for the change.
The practical boundary is transport, not branding. A message composed in Front and sent by a connected mailbox must be checked against that mailbox provider's domain setup. An SMTP-forwarded channel using Front's sending infrastructure must be checked against Front's supplied DNS records. Keep two acceptance records if the organization uses both.
Collect account-specific DNS requirements
For shared SMTP channels, a company admin opens company settings, Security, then Deliverability. The tab depends on having a shared SMTP channel. Select the domain and obtain its displayed records. For an individual SMTP channel, use the teammate's Channels settings and the channel's Improve delivery rates - SPF / DKIM section. Publish the supplied records and run Check DNS settings; the documented success state is Verified.
Those steps describe documentary setup, not a tenant we accessed. Ask the authorized administrator to export the record names, types, values and any priority field from the actual account. Keep the complete intended owner name alongside the DNS editor's input label. This prevents a relative-name field from appending the domain twice.
Do not carry over selectors from another Front customer or replace the root SPF policy with a generic service example. The account's displayed values are the configuration authority. If the UI conflicts with an older document, stop and resolve the exact channel and service before writing DNS.
Keep inbound routing separate
Front documents a dedicated front-mail MX owner for its authentication setup, distinct from the root-domain MX records used to receive ordinary mail. Do not replace the existing root MX records to make an authentication warning disappear. In an MX editor, priority is a separate numeric field from the destination hostname.
Before publishing, examine every requested owner name for existing use. A provider instruction to add records is not permission to destroy a different service's records. Record any collision and obtain a supported alternative rather than silently overwriting it. Verify that the authoritative zone is the one you are editing, particularly if the registrar and DNS host differ.
The channel setup page offers a choice between custom SMTP and SPF/DKIM records. If your DNS service cannot support the required configuration, investigate the documented custom-SMTP route with the mail administrator. Do not improvise by placing records at a nearby unused label: signatures and envelope routing require the exact intended names.
Accept DNS and mail independently
Product validation and authoritative DNS answer different questions. Query the expected owner and type on each authoritative server. Compare the answer with the approved account values. If authoritative answers disagree, repair the zone state first. If they agree but Front still sees an old answer, allow for the previous cache lifetime and repeat its check without repeatedly rewriting working records.
Then send a controlled message through the actual Front channel to a mailbox whose raw received message is available. Record the visible From domain, envelope identity, all DKIM d= and s= values, and the trusted receiver's authentication results. An SPF pass concerns the envelope identity. A DKIM pass concerns a signing domain. DMARC needs at least one passing path aligned with the visible From domain. Receiving a reply or seeing a message in Sent does not establish that result.
Synthetic example, not an observed Front default: a support message has From help@example.com, envelope bounce@front-mail.example.com and a valid DKIM signature with d=example.com. The DKIM domain exactly aligns. The envelope is a subdomain rather than an exact domain match, so its SPF alignment depends on the applicable mode. If the signature fails and strict SPF alignment is required, an SPF pass for that subdomain does not rescue the example.
Diagnose the specific failing layer
A missing Deliverability tab is an access or channel-scope question, not proof that DKIM is unsupported. A DNS warning after a change may indicate the wrong zone, suffix duplication, a record-type error or cached data. A passing DNS check with an unsigned message points toward the selected outbound transport or activation state. A passing aligned message that lands in spam requires separate investigation of reputation, content and recipient policy; authentication does not guarantee inbox placement.
Keep the old DNS record sets and the last working channel configuration before making a change. Test ordinary inbound mail separately from outbound signing, and test expected replies. If recovery is needed, restore only the affected configuration under an approved change; avoid replacing unrelated root records or disabling domain-wide DMARC enforcement as a shortcut.
Record completion honestly
The acceptance packet should name the Front channel, business owner, DNS owner, supplied records, authoritative answers, Front validation outcome and received-message identity evidence. Label each route tested. This guide has documentary evidence and a synthetic example only: no tenant settings, live DNS observations or delivered-message results were collected. Production acceptance remains with the authorized administrator after these checks.
Keep two channels in separate evidence rows
Written case FR-01 assumes help@example.com is a native Microsoft 365 sync channel, while group@example.com is an SMTP-forwarded group using Front sending. The first has a stipulated trusted DKIM pass with d=example.com, s=demo1; the second has no received-message evidence. The first aligned path does not validate the second route or authorize new DNS changes for the first. Ask the channel owner to confirm the group transport and obtain its generated values, preserving root MX and all mailbox-provider records. If the group later uses custom SMTP, reassess that server instead. No channel, DNS lookup or message was accessed in this example.
Preserve the enforcement boundary
RFC 9989 Section 7.4 requires valid DKIM, not SPF alone, for domains publishing p=reject, and warns about indirect-mail and mailing-list interoperability. A single successful direct-message test is not proof that every legitimate route is ready for stronger policy. Keep existing approved protection while diagnosing the actual gap; any policy change needs its own decision.