SPF, DKIM & DMARC for Front.
Front (front.com) is a shared-inbox and customer-communication platform, not an email host — so "sending as your domain" through Front has one specific meaning. When you connect a custom SMTP channel, Front relays your outbound mail through SendGrid, its underlying email infrastructure (older accounts relayed through Mandrill, which is why you may have seen a legacy "via mandrillapp.com" tag). Until you authenticate that path, recipients see a "via sendgrid.net" note on your From address and your mail is far likelier to land in spam. Front's Deliverability settings hand you three DNS records — an MX, an SPF (as a TXT), and a DKIM (as a TXT) — that you add to a dedicated front-mail sending subdomain. Because those records live on the subdomain rather than your root domain, they authorize SendGrid to send as you, drop the "via" tag, and align your mail to your domain for DMARC, all without touching your existing SPF or changing where your inbound email is delivered.
Why authenticate Front?
Authenticating your Front sending domain decides whether your replies reach the inbox at all. Since February 2024, Gmail and Yahoo have required every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, and Microsoft began enforcing the same on high-volume senders in 2025 — and support and success teams that live in Front routinely clear those volumes. Until you add the records, Front sends your mail on SendGrid's shared infrastructure: recipients see the "via sendgrid.net" tag, your From address doesn't align to your domain, DMARC can't pass on SPF, and your sending reputation is pooled with every other unauthenticated tenant on that platform. Authenticating fixes all of it at once — SendGrid signs with a DKIM key published under your front-mail subdomain (so the signature aligns to your domain), the envelope Return-Path lives on that same subdomain (so SPF aligns in relaxed mode), the "via" tag disappears, DMARC passes, and the reputation you build accrues to your own domain instead of the shared pool.
The SPF reality for Front
Front is a subdomain-delegation setup, not an "include" provider — there is NO include:sendgrid.net for you to paste onto your root domain. Instead, the entire authenticated path lives on a dedicated sending subdomain that Front labels front-mail. That subdomain gets three records straight from Front's Deliverability panel: an MX record pointing to SendGrid's mail host (mx.sendgrid.net) so SendGrid can process bounces, an SPF TXT record (v=spf1 include:sendgrid.net ~all) scoped to the subdomain, and a DKIM TXT public key on a selector under that same subdomain. Your organizational domain's own SPF record is left exactly as it is — Front's include lives on front-mail.yourdomain.com, so it costs zero of your root SPF's 10 DNS-lookup budget. DMARC still passes, but note the Front-specific detail: because BOTH the envelope Return-Path AND the DKIM key live on the front-mail subdomain, both SPF and DKIM align to your organizational domain in relaxed mode (the subdomain shares your registrable domain) — and neither aligns in strict mode. Relaxed is the DMARC default, so Front passes out of the box; just don't force strict alignment (aspf=s or adkim=s) for this domain. Finally, this only applies to Front SMTP channels; if your Front channel is a connected Gmail or Microsoft 365 inbox, Front sends through that provider's own servers and you authenticate at Google/Microsoft instead — none of the front-mail records apply.
Two ways to set it up
Front SMTP channel — add the SendGrid records (this guide)
- Applies when your channel is a custom SMTP channel — Front relays your outbound mail through SendGrid and you must authenticate it.
- Add MX + SPF (TXT) + DKIM (TXT) to a dedicated front-mail sending subdomain, copied from Front's Deliverability panel.
- All three records live on the subdomain, so your root domain's SPF is untouched — zero of your 10 SPF lookups consumed.
- Until Front shows the records Verified, mail sends 'via sendgrid.net' on the shared pool and risks the spam folder.
Connected Gmail / Microsoft 365 channel — authenticate there instead
- Applies when you added your inbox to Front via the Google or Microsoft 365 integration — Front sends through that provider, not SendGrid.
- Authentication is inherited from your Google Workspace or Microsoft 365 SPF, DKIM, and DMARC — set those up at that provider.
- There is no front-mail subdomain, no MX to mx.sendgrid.net, and none of the SendGrid SPF/DKIM records apply.
- The 'via sendgrid.net' tag never appears because SendGrid is not in the sending path.
Step by step
- 1
Confirm the channel is an SMTP channel
These records only apply to Front SMTP channels (mail relayed through SendGrid). If your channel is a connected Gmail or Microsoft 365 inbox, Front sends through that provider — stop here and authenticate at Google/Microsoft instead. Check the channel type under Settings → Channels.
- 2
Open Deliverability settings
For company-wide channels, click the Settings gear → Company settings → Security in the sidebar → the Deliverability tab. This page only appears to company admins once at least one shared SMTP channel exists. For an individual teammate's channel, open Settings → the teammate's SMTP channel → Settings tab → the 'Improve delivery rates - SPF / DKIM' section.
- 3
Select the sending domain
Under Domains, pick the domain you send from. Any domain missing SPF/DKIM shows a yellow warning icon. Front then displays the Name and Value for three records to add: an MX, an SPF (TXT), and a DKIM (TXT). Keep this panel open to copy from — the exact selector, host, and key values are unique to your account.
- 4
Add the MX record on the front-mail subdomain
Create an MX record: Host/Name = the subdomain label Front shows (e.g. front-mail), Value/Target = SendGrid's mail host (e.g. mx.sendgrid.net), Priority = as shown (Front commonly uses 10). This is a NEW MX on the subdomain for SendGrid's bounce handling — it does NOT change your main MX (host @) or where your inbound mail is delivered.
- 5
Add the SPF (TXT) record
Create a TXT record: Host/Name = front-mail, Value = exactly what Front shows (e.g. v=spf1 include:sendgrid.net ~all). This SPF is scoped to the sending subdomain only — do NOT add include:sendgrid.net to your root domain's SPF record.
- 6
Add the DKIM (TXT) record
Create a TXT record with the selector host Front shows (e.g. s1._domainkey.front-mail) and paste the long public key value from Front exactly, with no added spaces or line breaks. Front uses SendGrid's classic whitelabel, so this is a single static TXT key, not the auto-rotating CNAMEs of modern SendGrid domain authentication.
- 7
Enter hosts as labels only and don't touch existing records
Type just the label (front-mail, s1._domainkey.front-mail) — most registrars auto-append your domain, and entering the full front-mail.yourdomain.com produces a doubled name that won't resolve. Add these three NEW records only; do not edit or delete any existing DNS records, which can break delivery.
- 8
Publish your DMARC policy (if you don't have one)
On your root domain add a TXT record at _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Keep exactly one _dmarc record for the whole domain. Leave alignment at its relaxed default — Front's front-mail subdomain carries both SPF and DKIM in relaxed mode, so don't set aspf=s or adkim=s, either of which would break Front's authentication.
- 9
Click 'Check DNS settings' in Front
Return to Front's Deliverability panel and click Check DNS settings — this triggers a verification through SendGrid. When the records resolve, each flips to Verified and the yellow warning icon disappears from the channel. DNS propagation is usually minutes but can take up to 24–48 hours.
- 10
Send a real test and confirm alignment
Send yourself a message from the Front channel, open it in Gmail, and use ⋮ → Show original. Confirm SPF: PASS, DKIM: PASS signed-by front-mail.yourdomain.com, DMARC: PASS, and that the 'via sendgrid.net' tag is gone from the From line.
Records to add
Front generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| MX | front-mail | mx.sendgrid.netSending subdomain's Return-Path — SendGrid's bounce host, priority as shown by Front (commonly 10). The exact subdomain and host come from Front's Deliverability panel. This is NOT your main MX and does not affect inbound mail. |
| TXT | front-mail | v=spf1 include:sendgrid.net ~allSPF for the sending subdomain only — never added to your root domain, so it costs 0 of your root SPF's 10 lookups. Copy the exact value from Front. |
| TXT | s1._domainkey.front-mail | k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC…DKIM public key (single static TXT). Front/SendGrid supplies the exact selector and key — host and value are unique to your account; this is illustrative. Because the key lives under front-mail, the signature's d= is the subdomain and aligns to your domain in relaxed mode. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYour DMARC policy — one per root domain. Front authenticates entirely through the front-mail subdomain, so keep alignment relaxed (the default); strict (aspf=s or adkim=s) breaks Front. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Front's setup costs against that budget.
Front's recommended setup adds 0 lookups — all 10 stay free for the senders that do need an include.
DKIM
DKIM for Front is a single static TXT public-key record that Front generates through SendGrid and shows you in the Deliverability panel. You publish it on the sending subdomain's selector (something like s1._domainkey.front-mail.yourdomain.com); SendGrid holds the matching private key and signs every message Front relays. Because the key lives under front-mail, the DKIM signature carries d=front-mail.yourdomain.com, which aligns to your organizational domain in relaxed mode — the DMARC default — the same way the SPF Return-Path does. It does not align in strict mode, so don't set adkim=s for this domain. Two things make Front's DKIM different from modern SendGrid domain authentication. First, it is a static TXT key, not an auto-rotating CNAME — Front uses SendGrid's classic whitelabel, so you paste the key once and it doesn't rotate on its own (nothing is delegated to re-resolve, but nothing rotates keys for you either). Second, because it's a full public key in a TXT value, it can exceed the 255-character single-string limit; most DNS panels store it as one chunked record automatically, but if a checker later reports the key invalid, a mangled or truncated value is the usual cause — re-paste it exactly as Front shows. The SendGrid-assigned selector won't collide with your Google (google) or Microsoft (selector1/selector2) DKIM selectors, so Front's DKIM coexists with your mailbox provider's. DKIM is still the more forwarding-resilient of your two signals — it survives message forwarding where SPF breaks — but for DMARC alignment it rides the same relaxed mode as SPF, so keep your policy's alignment relaxed.
DMARC
DMARC is a separate policy record you publish on your root domain — Front doesn't create it for you, though its deliverability docs walk you through the interaction. Add a TXT record at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only, so it won't affect delivery while you confirm Front mail authenticates. The Front-specific catch is alignment: because SendGrid uses the front-mail subdomain for BOTH the envelope Return-Path AND the DKIM d= domain, Front mail aligns to your organizational domain in RELAXED mode on both SPF and DKIM — and in STRICT mode on neither. Relaxed is the DMARC default, so a standard policy passes Front out of the box; you don't need to add anything. Trouble only appears if your existing DMARC forces strict alignment: aspf=s breaks Front's SPF alignment and adkim=s breaks its DKIM alignment, and strict on both fails Front entirely. Keep alignment relaxed (you can make it explicit with aspf=r; adkim=r). Keep exactly one _dmarc record for the whole domain no matter how many senders (Front, your mailbox host, marketing tools) you run — never add a second DMARC record for Front. Once aggregate reports confirm Front/SendGrid is authenticating cleanly, tighten from p=none to p=quarantine and eventually p=reject.
Check it actually worked
Don't trust Front's Verified badge alone — confirm it on a real message. After Check DNS settings shows the records Verified, send yourself an email from the Front channel, open it in Gmail, and choose ⋮ → Show original. You want SPF: PASS (mailed-by front-mail.yourdomain.com), DKIM: PASS with signed-by: front-mail.yourdomain.com, and DMARC: PASS — and the 'via sendgrid.net' tag should be gone from the From line. You can spot-check the raw records with dig MX front-mail.yourdomain.com (expect mx.sendgrid.net), dig TXT front-mail.yourdomain.com (expect the v=spf1 include:sendgrid.net line), dig TXT s1._domainkey.front-mail.yourdomain.com (expect the DKIM key), and dig TXT _dmarc.yourdomain.com. Then run your domain through Qualisend's domain health check to confirm every record resolves and your root SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Front should appear as an aligned, passing source (SendGrid infrastructure signing as your domain).
Common gotchas
- Coverage
The MX record Front asks for is NOT your main MX. It sits on the front-mail subdomain and only lets SendGrid process bounces for Front's outbound mail — it does not reroute your inbox or change where inbound email is delivered. Your existing MX at host @ is untouched.
- Coverage
Enter hosts as the label only — front-mail, s1._domainkey.front-mail — not the full front-mail.yourdomain.com. Most registrars auto-append your domain, and the doubled name (front-mail.yourdomain.com.yourdomain.com) won't resolve, so Check DNS settings fails.
- Coverage
Add three NEW records only. Front explicitly warns not to edit or delete existing DNS records during this process — modifying your current SPF, MX, or DKIM can break delivery.
- DNS setup
Don't add include:sendgrid.net to your ROOT SPF. Front scopes SPF to the front-mail subdomain, so a root include is redundant, needlessly consumes one of your 10 SPF lookups, and isn't what SendGrid checks for Front.
- Coverage
Strict DMARC alignment breaks Front. Both the envelope Return-Path and the DKIM key live on the front-mail subdomain, so SPF and DKIM each align to your domain only in relaxed mode. Setting aspf=s breaks Front's SPF alignment and adkim=s breaks its DKIM alignment — strict on both fails Front entirely. Relaxed is the default, so leave alignment alone.
- Coverage
Connected Gmail / Microsoft 365 channels don't use these records at all. If Front sends through your Google or Microsoft mailbox rather than an SMTP channel, there's no front-mail subdomain and no via tag — authenticate at that provider instead.
- DNS setup
MX and TXT records can't be proxied, so on Cloudflare there's no orange-cloud/grey-cloud step here (unlike CNAME-based SendGrid domain auth). Just make sure you created them as MX and TXT, not as some other type.
- Coverage
Each SMTP sending domain and channel is authenticated separately. Setting up one domain doesn't cover the others — the Deliverability panel flags any domain still missing records with a yellow warning icon.
Build your SPF record
Front doesn't need an SPF include: on your root domain — use the generator to assemble one clean record for your other senders, and keep it to a single line.
Sending sources
Search for each platform you send email through and tick it.
Search for your email platform above, or .
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
No senders yet, so every message would hit the ~all policy. Add the platforms you send through in step 1.
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listFront SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.