Front Emails Going to Spam or Showing "via mandrillapp.com": Fixes (SPF & DKIM)

Symptom to likely cause, at a glance

Start here, then jump to the matching section below.

Cause 1 (most common): an SMTP channel is sending through Front's default server without SPF/DKIM

This is the "via mandrillapp.com" case, and it's the single most common Front deliverability complaint. When a channel sends through Front Default, the mail physically leaves Mandrill (Mailchimp Transactional) — Front's own outbound infrastructure. If you haven't told the world's mailbox providers that Mandrill is allowed to send as your domain, they annotate the message "via mandrillapp.com" and treat it as more suspicious, which pushes it toward spam.

Per Front's guide to removing "via mandrillapp.com" from outgoing emails, the fix is to authorize Mandrill to send on your behalf by publishing specific SPF/DKIM DNS records. Front is explicit that this applies to SMTP channels: "If you use SMTP channels in Front, we strongly recommend that you authorize Mandrill to send emails on your behalf by setting up specific Mandrill SPF/DKIM entries."

The fix (admin-only):

1. Click the gear icon, go to Company settings → Security, and open the Deliverability tab. This is admin-only, so if you don't see it, ask a company admin.
2. Select the domain with the warning icon. Front shows the exact SPF and DKIM record values it needs.
3. Copy those values into your DNS provider as the specified record types (typically a TXT record for SPF and CNAME/TXT records for DKIM).
4. Back in Front, click Check DNS settings. This triggers a verification check; once it passes, "the warning icon will be removed from the channel name in the list and the DNS records will say Verified."

One honest caveat: Front's records alone remove the warning, but Mandrill also validates the domain on its side. Per the same doc, Mandrill sends a validation link to an address on your domain — you contact Front's support team ([email protected]) to trigger it and forward the link back so they can complete validation on Mandrill's account. It's a one-time step, not a recurring chore.

Cause 2: SPF or DKIM is missing or failing for your send domain

Even without the "via" note, mail can quietly land in junk when SPF or DKIM don't line up. These are the two industry-standard checks every inbox provider runs, and since 2024 Gmail and Yahoo require authentication for bulk senders — a domain that fails is treated as unauthenticated.

Per Front's deliverability settings and SPF/DKIM guide, company admins configure these records for every domain in one place: the Deliverability tab under Security. The interface flags domains with missing records via warning icons, and you "Select a domain to view its DNS records," then add them at your DNS host and click Check DNS settings to verify.

What to check, in order:

• SPF exists and isn't over-limit. SPF is a single TXT record. If you already send through Google, Microsoft, or another service, you can't stack multiple SPF records — you merge the include: mechanisms into one. More than ten DNS lookups in a chain causes a permerror and silent failures.
• DKIM is published and matches. DKIM is the signature that survives forwarding, and it's what Gmail/Yahoo lean on hardest. Copy Front's DKIM host and value exactly; a trailing dot or a wrong host is the usual culprit for "won't verify."
• You clicked Check DNS settings after propagation. DNS changes can take up to a few hours to propagate. Verifying too early reports a false failure — wait, then re-check.

If you're still standing up Front's channels for the first time, the mechanics of how those channels connect and send are covered in Front channels explained, and if your inbox is a Gmail mailbox, how to connect Gmail to Front walks the OAuth path that sidesteps a lot of this.

Cause 3: the channel's sending server is set to Front Default when it should be your own provider

Here's the lever most teams don't know exists. Each channel in Front chooses how its outbound mail is physically sent, and that choice — not just your DNS — decides how deliverable your mail is. The picker lives at Settings → Channels → [your channel] → Settings → Send Outbound Messages → Modify, and it offers four options: Front Default, Office365 OAuth2, Google OAuth2, and Other SMTP.

The reasoning is straightforward. If your organization already runs Google Workspace or Microsoft 365, choosing Google OAuth2 or Office365 OAuth2 sends outbound through your own authenticated mail servers — the same servers that already have working SPF and DKIM and a warm sending reputation. That's the cleanest path off "via mandrillapp.com" entirely, because the mail never touches Mandrill. Other SMTP does the same through any provider whose credentials you supply. Front Default is the convenient fallback, but it's the one that requires the SPF/DKIM authorization from Cause 1 to stay out of junk.

An honest note on scope: this per-channel sending-server picker is what you see on a standard connected channel like the one above. The custom send-domain deliverability workflow — where a company verifies its own branded sending domain under Security → Deliverability — only populates once at least one domain is added. On a trial that connects a plain Gmail channel with no custom send domain, that tab reads "No domains," which is exactly why the sending-server panel above (not a domain list) is the real deliverability control to reach for first.

Cause 4: your DNS provider can't create the record Front needs

Sometimes every step is right and verification still fails — because the DNS host physically can't create the record type Front asks for. Front names the culprits directly. Per the deliverability settings guide, "DreamHost, HostGator, SiteGround, and Wix do not support creating the required MX record" for this configuration.

The fix: if you're on one of those four providers, don't keep fighting the record — switch that channel to custom SMTP instead, so mail sends via your own mail servers using DNS records those hosts do support. Front recommends exactly this: configuring custom SMTP for the affected channels rather than forcing an unsupported record. If moving DNS providers is on the table long-term, hosts like Cloudflare, Namecheap, AWS Route 53, and Google Domains all handle the required records cleanly, and Front publishes provider-specific setup guides for several of them.

Cause 5: content and reputation still matter

Authentication gets you eligible for the inbox; it doesn't guarantee it. Once SPF and DKIM pass, a few reputation basics finish the job:

• Publish a DMARC record (v=DMARC1; p=none; to start) so providers see an aligned policy — it's the natural next step after SPF/DKIM.
• Avoid spam-trigger patterns: all-caps subjects, link-only bodies, or a brand-new domain sending high volume from a cold reputation.
• Warm up gradually if you've just switched sending servers; a sudden spike from a fresh IP looks like spam regardless of authentication.

For most shared-inbox teams these are marginal compared with Causes 1–3, but they're worth a pass once the DNS work is done. If you want the wider picture of how sending, channels, and inboxes fit together, Front shared inbox explained covers the model.

Where an AI layer quietly reduces these tickets

Deliverability is a plumbing problem, and the fixes above are the right ones. But there's a second-order angle worth naming: a large share of the outbound your team authenticates is routine — order status, password resets, "where's my refund." Every one of those is a message that has to be composed, sent, and land in an inbox.

That's the seam an AI agent layer sits in. Macha runs on top of the Front you already use through the live Macha–Front connector — it doesn't replace Front, your channels, or your DNS. What it changes is volume: the broader category of AI agents for customer service exists to resolve repetitive questions directly, so fewer human-drafted replies ever need to go out. Fewer outbound emails is simply less surface area for a spam-folder incident. When the agent does need live data — a real order, a real account status — it pulls it through a custom tool that turns your REST API into something the agent can call, and Macha's credits are consumed per AI action, never per resolution. It won't fix an SPF record for you. It will mean you're authenticating a smaller pile of mail.

FAQ

Why does my Front email say "via mandrillapp.com"? Because that channel sends through Front's default server, which is Mandrill (Mailchimp Transactional), and you haven't published the SPF/DKIM records that authorize Mandrill to send as your domain. Add those records under Company settings → Security → Deliverability, then click Check DNS settings. Once verified, the note and warning icon disappear.

Where are Front's deliverability settings? Click the gear icon, go to Company settings → Security, and open the Deliverability tab. It's admin-only. You select each sending domain, copy the SPF/DKIM values into your DNS provider, and click Check DNS settings to verify.

My DNS won't verify — what's wrong? Most often the record host or value is slightly off, or you checked before DNS propagated (wait a few hours). If it still fails, confirm your DNS provider can create the required record — DreamHost, HostGator, SiteGround, and Wix cannot, and Front recommends using custom SMTP for channels on those hosts.

Can I avoid Mandrill entirely? Yes. In Settings → Channels → [channel] → Settings → Send Outbound Messages → Modify, set the sending server to Google OAuth2, Office365 OAuth2, or Other SMTP. Mail then sends through your own authenticated servers and never touches Mandrill, which removes the "via mandrillapp.com" note at the source.

Do I need a custom domain to fix this? Not to remove "via mandrillapp.com" on a standard SMTP channel — publishing Mandrill's SPF/DKIM is enough. The full custom send-domain verification workflow only applies once you add your own branded sending domain under Security → Deliverability; on a plain Gmail channel that tab stays empty.

Want to cut the volume of outbound your team has to authenticate in the first place? Start a free trial of Macha and connect it to your Front in minutes.