SPF record for SendGrid (Twilio)

The exact SPF record

Copy the example that matches your setup. Each one is a single TXT record; the host is shown as your DNS provider usually expects it (@ means the domain itself).

Automated security off: TXT on the return-path subdomain SendGrid gives you

Type: TXT · Host: em1234 · 2 of 10 DNS lookups Copy

v=spf1 include:sendgrid.net ~all

Use the exact subdomain SendGrid shows; em1234 is an example. SendGrid also asks for an MX record there: mx.sendgrid.net.

Your main domain on Microsoft 365 stays as it is

Type: TXT · Host: @ · 1 of 10 DNS lookups Copy

v=spf1 include:spf.protection.outlook.com -all

Your main domain on Google Workspace stays as it is

Type: TXT · Host: @ · 1 of 10 DNS lookups Copy

v=spf1 include:_spf.google.com ~all

How SPF applies to SendGrid mail

SendGrid sends with a bounce (MAIL FROM) address on a subdomain set up for it, and receivers check SPF on that subdomain. Your main domain's SPF record doesn't need to change for SendGrid.

• SendGrid's SPF article shows v=spf1 include:sendgrid.net -all as a typical record. With domain authentication, that record belongs on the return-path subdomain, which is the domain SPF actually checks for SendGrid mail.
• With automated security on, SendGrid updates the SPF and DKIM records for you, for example when you add a dedicated IP address. With it off, you must update them yourself.

How to add it

1. In SendGrid, start domain authentication for the domain you send from (for example example.com).
2. Under Advanced Settings, keep Use automated security on unless your DNS host can't store underscores in CNAME records.
3. Optionally set a custom return path if you need a specific subdomain label instead of SendGrid's random one.
4. Publish exactly the records SendGrid shows: with automated security, one CNAME for the return path (SPF), two DKIM CNAMEs and a DMARC TXT record.
5. Verify in SendGrid, then check the return-path subdomain with the SPF Checker below.

DKIM and DMARC alignment

With automated security on, DKIM uses two CNAMEs (s1._domainkey and s2._domainkey) that point to SendGrid; with it off, a DKIM TXT record (m1._domainkey). Because the return path is a subdomain of your From domain, SPF aligns under DMARC's default relaxed alignment, and DKIM aligns too.

DMARC passes when SPF or DKIM passes and the domain it checked matches your From domain. Our guide to SPF, DKIM and DMARC explains how the three fit together.

Common mistakes

• Two SPF records. A domain may publish only one record that starts with v=spf1. With two, receivers return a permanent error and SPF fails for all your mail (RFC 7208 section 3.2). Merge every sender into one record.
• More than 10 DNS lookups. Each include, a, mx, exists and redirect costs a lookup, nested ones included; over 10 is a PermError (section 4.6.4). SendGrid's include costs 2 on its own. See how to fix too many SPF lookups.
• Choosing ~all or -all without a plan. SendGrid's documentation uses ~all. -all asks receivers to reject unlisted servers; ~all asks them to accept but mark the mail. Once DMARC is enforced, receivers act on DMARC instead. Read SPF soft fail vs hard fail before you choose.
• Adding include:sendgrid.net to your root record when you've already authenticated the domain. SPF for SendGrid mail is checked on the return-path subdomain, so the root include spends 2 lookups for nothing.
• A custom return-path CNAME that matches an existing CNAME overwrites it. Check your DNS first.