For a Front channel that sends through Front's default SMTP infrastructure, publish the DNS records shown for that domain in Front, then run Check DNS settings. For Gmail or Microsoft 365 API-synced channels, configure authentication with the mailbox provider instead. A custom SMTP connection also uses the external sender's authentication. The address displayed in the inbox does not tell you which route is active. Front deliverability settings
This guide covers outbound email sent through Front. It separates outbound authentication from inbound forwarding. It does not configure a standalone SendGrid account or assume that a historical Mandrill tutorial describes your current channel.
On this page
- Choose the correct route before editing DNS
- Prerequisites and eligibility
- Obtain and activate Front's DNS configuration
- SPF: validate the envelope identity, not just the root domain
- DMARC: preserve policy and prove alignment
- Acceptance: DNS, Front verification and real delivery
- Troubleshooting by symptom
- Frequently asked questions
- Review and implementation boundary
Choose the correct route before editing DNS
| Channel configuration | Where outbound authentication belongs | First check |
|---|---|---|
| Gmail or Office 365 sync | Google Workspace or Microsoft 365 | Confirm API sync, not merely the mailbox's brand |
| SMTP forwarding with Front's default sender | Records supplied by Front for its sending infrastructure | Open that domain's deliverability settings |
| Google Group using SMTP forwarding | Front-supplied records unless another outbound transport is configured | Inspect the channel's outbound setting |
| Custom SMTP | The external SMTP provider | Confirm the selected SMTP server and its domain authentication |
Front's default SMTP sending uses SendGrid. Switching a Gmail or Microsoft 365 mailbox to forwarding can therefore change its outbound authentication requirements, even if the visible From address stays identical. An already authenticated Google Workspace domain does not automatically authenticate Front's separate sender. Transitioning to SMTP forwarding
For the separate Microsoft 365 API-synced route, consult the Microsoft 365 authentication guide; those tenant controls do not authenticate Front’s default SMTP infrastructure.
Prerequisites and eligibility
Have a company administrator identify the affected channel, exact From domain, DNS administrator and outbound route. Export the DNS zone or save the existing values and TTLs before making changes. Record the current SPF policy, DKIM selectors, DMARC policy, root MX records and any existing front-mail owner.
The shared-domain deliverability screen requires company-admin access and at least one shared SMTP channel. Individual-only configurations use a different path below. Missing controls can be an account-role or channel-type issue rather than a broken DNS record. Front setup requirements
Front documents custom SMTP as available on all plans, with email required as the company channel type on the latest Starter plan. Confirm your actual plan and channel before planning a transport change. The same documentation does not make every possible mailbox authentication method available: ask the external provider which authentication method it currently accepts. Do not disable MFA or enable legacy authentication to follow an old screenshot. Custom SMTP and pricing
Obtain and activate Front's DNS configuration
For a shared SMTP channel, open the gear icon, company settings, Security > Deliverability. Select the sending domain. For an individual channel, use company preferences, Teammates > selected teammate > Channels, select the SMTP channel, then expand Settings > Improve delivery rates - SPF / DKIM.
Copy every record's owner, type and destination from the selected domain, not another tenant's screenshot. After publishing, return to Check DNS settings. Front reports successful records as Verified and removes the warning. Cache expiry can delay that result. Current navigation and verification
Use a change worksheet rather than relying on a single screenshot:
| Field | Record before proceeding |
|---|---|
| Business identity | Channel, inbox, sending address and domain |
| DNS identity | Complete owner name, type, exact value and any MX preference |
| Existing use | Whether the owner already has records and who owns them |
| Verification | Public answer, Front result, time and resolver used |
| Message acceptance | Actual From, MAIL FROM, DKIM domain and receiver DMARC result |
Keep bounce routing separate from inbound mail
Front's documented three-record configuration includes an MX record at front-mail, separate from the root-domain MX used for ordinary incoming mail. Add the account-requested records at their specified owners. Do not replace root MX entries or point all incoming company mail at Front's sending infrastructure. If the generated owner differs, use the account's actual owner. Front MX distinction
Before publishing or activating sending-related MX, the mail-routing owner must separately approve the complete full-owner, numeric-priority and target set. An account-issued packet is not approval of its routing consequences. Reconcile all requested tuples with that authorized plan, preserve corporate inbound routing, and compare the complete approved set at authoritative and public recursive DNS. Stop on any unapproved or conflicting owner, priority or destination rather than accepting one matching hostname.
DNS providers differ in how they split the MX preference from its destination. A displayed leading number belongs in the priority/preference field when the editor provides one. It is not part of the destination hostname. Likewise, determine whether the DNS editor automatically appends your domain. Entering a full hostname into a relative-name field can create front-mail.example.com.example.com.
If Front requests a CNAME, keep it as a CNAME and make it DNS-only where proxying is available. A CNAME cannot coexist with ordinary A, AAAA, MX or TXT data at that exact owner. Stop on conflicts instead of deleting another service's authentication. Public DKIM records are safe to publish; SMTP credentials and private signing keys are not DNS records.
For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.
Front specifically flags limitations with the required MX setup at DreamHost, HostGator, SiteGround and Wix, and suggests custom SMTP as an alternative. Verify the current capability with the DNS host before changing architecture. Do not silently omit the MX record and call the setup complete. Provider limitations
On Cloudflare, also leave flattening off for authentication aliases, including any zone-wide flatten-all-CNAME setting. DNS-only alone is insufficient if flattening hides the requested CNAME answer. Cloudflare verification guidance
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.
SPF: validate the envelope identity, not just the root domain
SPF authenticates the SMTP MAIL FROM domain, normally represented by the delivered Return-Path. The visible From domain can be different. Query the actual envelope domain from the test message and follow any relevant alias or delegated configuration. A passing SPF check on example.com does not prove a message using front-mail.example.com passed.
Do not add a blanket include:sendgrid.net to the apex simply because Front uses SendGrid. Use Front's account-supplied design. If a separately managed SMTP provider requires a TXT change, merge only its documented authorization into the existing SPF policy at the correct owner. Keep one v=spf1 policy per owner, preserve unrelated senders and the existing terminal policy, and evaluate nested mechanisms against SPF's limit of ten DNS-querying terms. This is not a ten-vendor allowance. SPF specification
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.
DMARC: preserve policy and prove alignment
DMARC passes when at least one valid authenticated identifier aligns with the visible From domain: aligned SPF or aligned DKIM is sufficient. Relaxed alignment compares organizational domains; strict alignment requires an exact domain match. A subdomain envelope can therefore pass SPF without satisfying aspf=s for an apex From address. Current DMARC standard
Front's DMARC guidance warns that its SMTP return path does not meet strict SPF alignment. Do not respond by automatically changing an established aspf=s, adkim=s, quarantine or reject policy. First inspect whether the delivered message has a passing aligned DKIM signature. If neither method aligns under the organization's existing policy, pause the rollout and resolve the sender configuration or obtain approval for a policy decision. Front's alignment caveat
For a domain without an established policy, plan a monitored DMARC deployment separately, after accounting for parent-domain inheritance and other senders. Do not overwrite an existing reporting destination. RFC 9989 supersedes RFC 7489 and removes pct; percentage-based enforcement recipes are not current guidance. Aggregate reporting is specified separately in RFC 9990. Review data-sharing implications before adding failure reporting under RFC 9991.
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. First inspect the direct policy at _dmarc.YOUR-FROM-DOMAIN and any applicable inherited policy. Only absent both, with owner-approved monitoring, an illustrative first TXT value is v=DMARC1; p=none; it requests no reports unless an approved rua destination is added. For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names.
Acceptance: DNS, Front verification and real delivery
Replace these examples with the owners actually displayed in Front:
dig +short MX front-mail.example.com
dig +short TXT front-mail.example.com
dig +short CNAME ACTUAL-SELECTOR._domainkey.example.com
dig +short TXT ACTUAL-SELECTOR._domainkey.example.com
dig +short TXT _dmarc.example.com
The MX answer must match the requested preference and host. TXT/CNAME answers must match their requested types and values, with a resolvable DKIM public key where applicable. An empty answer is not verification. Query authoritative nameservers and a recursive resolver if results differ.
After Front shows Verified, send a new support reply and a new conversation from each affected channel to a mailbox you control. This is a recommended test, not one performed for this guide. Inspect the receiving system's trusted Authentication-Results and the raw From, Return-Path and DKIM-Signature headers. Authentication-Results specification
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.
For Front-managed custom-domain sending, require the intended channel and From, a passing branded DKIM signature aligned with that From, and receiver dmarc=pass under the existing policy. Also confirm the expected SPF authentication result for the actual envelope domain. A DMARC pass through SPF alone does not establish that the requested DKIM setup is complete. Record DKIM d= and s=. Test a forwarding route separately because forwarding can change SPF results. Confirm inbound forwarding still works, but do not confuse it with outbound authentication. A green badge, SMTP connection success or missing “via” label alone is insufficient. Authentication cannot guarantee inbox placement.
Investigate an actual spf=fail, permerror or temperror even if aligned DKIM makes DMARC pass. Check the observed envelope owner, authorized sender, evaluated lookup limit and DNS availability. A DMARC pass does not turn a broken SPF path into a healthy configuration.
Diagnose authorization fail or softfail against the actual observed envelope policy and connecting IP; temperror indicates a transient evaluation failure, often DNS; permerror points to an invalid policy, duplicate SPF policies or exceeded lookup limits. Keep these distinct even when aligned DKIM supplies DMARC. SPF result definitions.
Troubleshooting by symptom
- Deliverability tab absent: check company-admin permissions and whether any shared SMTP channel exists. Use the teammate channel path for individual channels.
- Records exist but remain unverified: compare the complete owner, type and destination; look for duplicated suffixes, proxying, conflicting owners and cached answers.
- Outgoing mail still uses the old sender: inspect Send Outbound Messages in the actual channel. DNS cannot change the selected transport.
- SPF passes, DMARC fails: compare MAIL FROM and DKIM
d=with visible From, including strict alignment settings. Do not weaken policy as a diagnostic shortcut. - Custom SMTP connection fails: diagnose external credentials, accepted authentication method, TLS and server permissions before changing DNS.
- Incoming mail fails: examine forwarding and root MX independently. Authentication records are not a replacement for inbound routing.
Review and implementation boundary
No customer account was accessed, DNS changed, message sent or website published. EmailAuth's useful next step is an evidence-led authentication review covering the channel, public records and receiver results, not a promise of rankings or inbox placement.