SPF and DKIM by provider

SPF record for SendGrid

Last updated 2026-08-26

SendGrid sends transactional and marketing mail through its API and SMTP relay. Here is what to publish so it can do that as your domain, and what has to line up before DMARC will pass.

The SPF record

Add one mechanism to the SPF record on your sending domain:

In a complete record, alongside Google Workspace, that looks like:

Add this only if you are sending without SendGrid's domain authentication. With domain authentication set up the way SendGrid recommends, the envelope sender moves to a subdomain of yours (something like em1234.example.com) that CNAMEs into SendGrid's infrastructure, and the SPF record that gets evaluated is theirs, not your root record. Your ten-lookup budget stays untouched.

That is the better setup, and it is why a lot of correctly configured SendGrid domains have no sendgrid.net in their SPF record at all.

Then count your lookups. SPF allows ten DNS-querying mechanisms across the entire nested chain, and the eleventh turns the record into a permerror that authorises nothing. The record still reads correctly to a human while every check fails. Run the domain through the SPF checker after every change, because the number moves when your providers change their own records, not just when you change yours.

DKIM

Domain authentication generates three CNAMEs. The account-specific parts (the user number and the wl host) come from your account, so copy them from the SendGrid screen:

Leaving automated security on is the right default: SendGrid rotates the keys behind the CNAMEs and you never touch DNS again. Turning it off swaps the CNAMEs for TXT records and hands you the rotation problem.

Return path and SPF alignment

The em1234 CNAME is your return-path host. Because it is a subdomain of example.com, SPF aligns under relaxed matching, which is the default. Skip it and SPF authenticates sendgrid.net, which aligns with nothing of yours.

DMARC alignment with SendGrid

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the domain in your visible From address. A provider can pass both checks for its own domain and leave you failing. These are the SendGrid specifics:

• Subusers get their own authenticated domains. Authenticating at the parent account does not always cover a subuser sending under a different domain.
• Link branding is a separate CNAME and a separate setting. It does not affect DMARC, but unbranded links pointing at sendgrid.net hurt the clickthrough you were trying to protect.
• If you also keep include:sendgrid.net in your root record out of caution, it costs a lookup you may need later. Take it out once domain authentication is verified.

The general case is covered in alignment, explained, and the header you read to prove it is on the dmarc=fail page.

Verify it

Substitute your domain, and run these after the TTL on anything you replaced has expired:

Then send one message through SendGrid to a Gmail address you control, open Show original, and look for dkim=pass with your domain in header.i. That single check is worth more than any number of DNS lookups, because it tests the thing receivers actually do.

Our SPF checker gives you the lookup count, the DKIM checker confirms a selector resolves and the key is long enough, and the DMARC checker reads your policy back to you. All three are free and none of them ask for an account.

Values here were checked against SendGrid's own documentation, at SendGrid domain authentication docs. Providers change DNS requirements without much announcement, so if their screen disagrees with this page, believe their screen and tell us.

A record can read correctly and still fail alignment once real mail moves through it. Receivers write that verdict into the reports they send. We read them for you, and paid plans email you the same day one names a new sender that failed, instead of holding it for Monday. See whether this sender passes. Your first domain is free.