DMARC, SPF and DKIM for Twilio SendGrid

Updated 2026-11-07

Twilio SendGrid is an email sending service for transactional and marketing mail. To send as your own domain with SPF and DKIM that align, you set up domain authentication in the SendGrid console and publish the records it shows at your DNS host. DMARC is a record you publish yourself. This guide follows SendGrid's documentation on twilio.com. For the background on each standard, see SPF explained, DKIM explained and DMARC explained.

What Twilio SendGrid sends from

Mail you send as [email protected] leaves through SendGrid's servers. The visible From address is your domain. SendGrid applies an authenticated domain when the From domain matches it. If no valid authenticated domain matches and no default is set, the docs say "your mail domain defaults to sendgrid.net". That mail cannot align with your domain.

Domain authentication creates a subdomain of your domain that handles bounces. The docs describe it as "four random alphanumeric characters", and their examples look like em1234.example.com. That subdomain is the envelope sender (Return-Path): with automated security off, the docs say its MX record "creates a return-path email header". You can choose your own label with "Use custom return path".

Authentication is per domain. The docs say "Subdomains don't inherit authentication permissions from their parent domain". If you send from news.example.com, authenticate that name too.

SPF

SPF is checked on the Return-Path domain, not on the From domain. SendGrid's DMARC page says the receiver "retrieves the SPF record from the DNS records for the domain in the return-path". So the SPF record that matters for SendGrid mail sits on the em subdomain.

With automated security on (the default), you publish one CNAME for that subdomain. As of November 2026 it looks like this, based on the documented examples:

em1234.example.com CNAME uXXXXXXX.wlXXX.sendgrid.net.

The uXXXXXXX and wlXXX parts are placeholders, combined from the examples on two docs pages; the console shows your own values. SendGrid then keeps the SPF data behind the CNAME current. The docs give an example: "If you purchase a dedicated IP address, Twilio SendGrid adds that IP address to your SPF record".

With automated security off, you publish an MX and a TXT record on the subdomain and keep them current yourself:

em1234.example.com MX mx.sendgrid.net.
em1234.example.com TXT "v=spf1 include:sendgrid.net ~all"

The docs give the MX target as mx.sendgrid.net. but print no priority, so use the one the console shows. When you add an IP address to your account, the docs say to update this SPF record.

The TXT record above uses 1 DNS lookup itself. SendGrid does not document how many lookups include:sendgrid.net costs. When we counted it with real DNS on 7 November 2026, its record held IP ranges and one more include, ab.sendgrid.net, which held no further lookups. So it cost 2 lookups in total. SendGrid can change that record, so count your own tree with the SPF lookup counter. RFC 7208 sets the limit at 10; SendGrid's SPF page quotes it.

The docs do not say whether your root domain's SPF record needs include:sendgrid.net when you use domain authentication. Their SPF page shows v=spf1 include:sendgrid.net -all as "a typical SPF record", without saying where to put it. Since the Return-Path is the em subdomain, we read the root record as not involved for SendGrid mail.

DKIM

SendGrid signs your mail. In the docs' words, "Twilio turns on DKIM for all email messages". It canonicalizes headers and body as relaxed/simple.

With automated security on, you publish two CNAMEs. As of November 2026 they look like this, based on the documented examples:

s1._domainkey.example.com CNAME s1.domainkey.uXXXXXXX.wlXXX.sendgrid.net.
s2._domainkey.example.com CNAME s2.domainkey.uXXXXXXX.wlXXX.sendgrid.net.

The docs explain: "Twilio uses multiple selectors (s1 and s2, by default) interchangeably and rotates them when necessary. Twilio only activates one selector for generating DKIM signatures at any given time." Publish both; in our reading, rotation can otherwise break DKIM.

One note on the setup page: its bullet list calls the two extra CNAMEs link branding records, but its own record table and the DKIM page list them as the s1 and s2 DKIM records. We follow the tables.

With automated security off, DKIM is a TXT record that holds the key. The documented example is m1._domainkey.example.com with a value that starts k=rsa; t=s; p=. You copy the exact value from the console. If the key changes, you must update it yourself.

If another service already uses the selector s, the docs offer "Use a custom DKIM selector": you type three letters or numbers, such as org or 001. The docs do not show the record names that result. They also do not state the key length SendGrid uses.

DMARC alignment

DMARC passes when SPF or DKIM passes and the authenticated domain aligns with the From domain.

  • SPF alignment compares the Return-Path domain with the From domain. SendGrid's Return-Path is a subdomain such as em1234.example.com. Under relaxed alignment that matches example.com, because both share the organisational domain. Under strict alignment (aspf=s) it does not. SendGrid's DMARC page shows the same in its table: @example.com with return-path @mail.example.com is "PASS" under r and "FAIL" under s.
  • DKIM alignment compares the d= domain with the From domain. The selectors sit under _domainkey.example.com, so a signature that verifies through them carries d=example.com. The docs do not print a sample SendGrid DKIM-Signature header, so this is our reading of the records. It aligns under both relaxed and strict.

Relaxed is the default. Keep it unless you have a reason not to. DKIM is the stronger leg: it usually survives forwarding, while SPF often does not.

Step by step to p=reject

  1. Authenticate the domain. In the console, open Settings, then Sender Authentication, and start Domain Authentication. Enter the domain from your From addresses. As of November 2026 leave "Use automated security" checked unless your DNS host does not accept underscores in CNAME records.
  2. Publish the records. Add the em CNAME and the s1 and s2 DKIM CNAMEs exactly as the console shows them. With automated security off, the documented records are instead an MX record for em1234.example.com to mx.sendgrid.net., a TXT record there with v=spf1 include:sendgrid.net ~all, and the DKIM TXT record at m1._domainkey.example.com. Then click Verify. The docs say DNS changes can take up to 48 hours.
  3. Start DMARC at p=none with reports. Publish a TXT record at _dmarc.example.com with v=DMARC1; p=none; rua=mailto:[email protected]. This does not protect the domain yet. It turns on aggregate reports.
  4. Read the reports and fix other senders. For two to four weeks, look at which servers send as your domain. Give each legitimate service aligned SPF or DKIM, and make sure every SendGrid From domain is authenticated.
  5. Move to quarantine. Change the policy to p=quarantine once the reports show only aligned mail from your own services. Failing mail usually goes to spam, so a sender you missed can still be found.
  6. Reject. Change the policy to p=reject when the reports stay clean. Receivers then refuse mail that fails DMARC.

The record for step 3:

_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]"

The final record:

_dmarc.example.com TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

The Install DNS Records page in the docs shows v=DMARC1; p=none; without rua. Add rua, or you get no reports to base the next steps on. If you already have a DMARC record, change it rather than adding a second one.

Common mistakes

  • The domain typed twice. GoDaddy, Route 53 and Namecheap append your domain, so em123.example.com becomes em123.example.com.example.com. The docs say to enter only the host part, em123.
  • Sending from a domain that is not authenticated. SendGrid falls back to sendgrid.net, and that mail fails alignment for your domain. Subdomains need their own authentication.
  • Only one DKIM CNAME. SendGrid rotates between s1 and s2. In our reading, if one is missing, mail can fail DKIM after a rotation (DKIM not found).
  • Overwriting an existing record. The docs warn that a custom return-path CNAME that matches an existing CNAME overwrites it. Check your zone first.
  • A split DKIM key. With automated security off, some DNS hosts split the TXT value. The docs say to combine the key "back together into one set of quotes".
  • A free-mail From address. Sending as a gmail.com or yahoo.com address through SendGrid fails SPF and DKIM for that domain, and the receiver applies its DMARC policy. Authenticate a domain you control.
  • Relying on a test flag. Some receivers support a test flag: t=y in RFC 9989 (DMARCbis), which obsoletes RFC 7489, or pct in RFC 7489. Neither is a safety net. RFC 7489 says unknown tags must be ignored, so a receiver that implements only RFC 7489 can treat p=reject; t=y as a full reject, and RFC 9989 removed pct. SendGrid's DMARC page still describes pct; do not build on it. Move from p=none to p=quarantine to p=reject and let the reports decide each step.

How to check it

Run the email security check on your domain for SPF, DKIM and DMARC in one pass. Run the SPF lookup counter on your em subdomain to count every lookup behind it. In the DKIM selector finder, look for s1 and s2, the default selectors as of November 2026. Build or check your policy with the DMARC record generator. SendGrid's troubleshooting page also lists the dig commands to verify each record by hand.

Sources

Frequently asked questions

Do I need include:sendgrid.net in the SPF record on my root domain?

Not for mail sent through an authenticated domain, in our reading of the docs. As of November 2026 SendGrid puts SPF on a return-path subdomain such as em1234.example.com, and receivers check SPF on the return-path domain. With automated security that subdomain is a CNAME to SendGrid; without it you publish v=spf1 include:sendgrid.net ~all on the subdomain. The docs do not say whether the root record needs the include.

Which DKIM selectors does SendGrid use?

As of November 2026 the docs say SendGrid uses s1 and s2 by default and rotates them, with only one active at a time. With automated security both are CNAMEs from s1._domainkey.example.com and s2._domainkey.example.com to names under sendgrid.net. With automated security off, the example uses m1._domainkey.example.com as a TXT record.

What is automated security?

A setting in domain authentication that is on by default. SendGrid then gives you CNAME records and keeps the SPF and DKIM data behind them up to date, for example when you add a dedicated IP. With it off you publish MX and TXT records yourself and must update them after changes.

Does SendGrid publish a DMARC record for my domain?

No. The Install DNS Records page shows a DMARC TXT record for _dmarc.example.com with v=DMARC1; p=none;, but you publish it at your DNS host. SendGrid's verification does not require DMARC to pass. Add a rua address so you get reports, then move to quarantine and reject.