How to Set Up SPF, DKIM and DMARC for SendGrid (2026)

SendGrid is a cloud-based email delivery platform used for transactional and marketing email. Without proper SPF, DKIM, and DMARC configuration, mail sent through SendGrid on your domain is vulnerable to spoofing and increasingly likely to be rejected by major inbox providers. By the end of this guide you will have all three authentication layers published in DNS and verified as passing.

Before you begin

• DNS write access to your domain (via your registrar or DNS provider, e.g. Cloudflare, Route 53, GoDaddy).
• Admin access to your SendGrid account with permission to configure Sender Authentication.
• A verified sender identity or domain in SendGrid — you must complete SendGrid's own domain authentication flow to retrieve the CNAME or TXT records SendGrid requires before DKIM will work.
• The ability to send a test email from your domain and view full message headers.
• An understanding that DNS changes can take up to 48 hours to propagate, though most providers resolve within minutes to a few hours.

Step 1: Identify what's sending from SendGrid

SendGrid routes outbound mail through a shared or dedicated IP pool depending on your plan. When you authenticate a domain inside SendGrid, it generates a set of CNAME records that point to SendGrid-controlled DNS entries for both SPF and DKIM. This means SendGrid's recommended approach is CNAME-based domain authentication rather than a manually maintained SPF include: in your root TXT record. Before touching your DNS, log in to SendGrid and navigate to the Sender Authentication section (Settings → Sender Authentication) to start the domain authentication wizard. That wizard will output the exact CNAME records you need to publish — the values are unique to your account and cannot be inferred in advance. Note them down; you will publish them in Steps 2 and 3 below.

Step 2: Add the SPF record

When you use SendGrid's CNAME-based domain authentication, SendGrid manages the SPF record on its own subdomain — the CNAMEs you publish delegate authority to SendGrid's infrastructure. You do not need to manually add an include: mechanism to your root SPF record for SendGrid traffic, because the CNAME chain handles it. However, if you are using a legacy manual setup or your account requires a direct include:, SendGrid's documentation lists the correct include string; verify it in your SendGrid account before publishing.

If you already have an SPF record and need to add a SendGrid include manually, the pattern looks like this:

Before (existing SPF record):

your-domain.com.  TXT  "v=spf1 include:_spf.google.com ~all"

After (with SendGrid include added — replace the placeholder with the value from your SendGrid account):

your-domain.com.  TXT  "v=spf1 include:_spf.google.com include:<sendgrid-spf-include> ~all"

SPF 10-lookup limit warning: SPF resolves each include: mechanism recursively, and the RFC hard-limits the total to 10 DNS lookups. SendGrid's own SPF infrastructure can itself chain multiple includes. If your domain already has several include: entries (Google Workspace, Microsoft 365, Salesforce, Zendesk, etc.) you may exceed the limit before adding SendGrid. Use a tool such as MXToolbox's SPF record checker or DMARC Busta's SPF analysis to count your current lookups before making changes. Exceeding the limit causes spf=permerror, which fails authentication.

Step 3: Enable DKIM in SendGrid

SendGrid uses CNAME records to implement DKIM, not raw TXT records. This means you publish CNAMEs in your DNS that point to SendGrid-hosted TXT records containing your DKIM public keys. SendGrid rotates and manages the keys on its side; you never need to update the CNAME values after the initial setup.

The general workflow:

1. Log in to SendGrid and go to Settings → Sender Authentication.
2. Click Authenticate Your Domain (or edit an existing domain if you have already started).
3. Select your DNS host from the dropdown if prompted (this helps SendGrid format the records correctly), then enter your sending domain.
4. SendGrid will generate three CNAME records: two for DKIM and one for a custom return path (which also improves SPF alignment). Copy all three exactly as shown.
5. Publish all three CNAME records in your DNS provider. The record names will follow a pattern similar to the one below, but the exact subdomains and values are account-specific:

; DKIM CNAME records — exact values come from your SendGrid account
em<number>.your-domain.com.         CNAME  <sendgrid-dkim-value-1>
s1._domainkey.your-domain.com.      CNAME  <sendgrid-dkim-value-2>
s2._domainkey.your-domain.com.      CNAME  <sendgrid-dkim-value-3>

After publishing, return to SendGrid and click Verify. SendGrid will perform its own DNS lookup and confirm whether the records are resolving correctly. Do not proceed to DMARC until SendGrid marks domain authentication as Verified.

Note on DKIM alignment: For DMARC to pass via DKIM, the domain in the DKIM d= tag must align (match or be a subdomain of) the From: header domain. SendGrid's domain authentication signs with your own domain, so alignment passes automatically once the CNAMEs resolve. If you are using a subdomain for sending (e.g. mail.your-domain.com), make sure your DMARC record covers the organizational domain (your-domain.com) and that the DKIM signature uses the same organizational domain.

Step 4: Publish your DMARC record

Publish the DMARC record as a TXT record at _dmarc.your-domain.com. Start with p=none — this is monitoring mode. It generates reports without affecting delivery, giving you at least 14 days of visibility into all sources sending as your domain before you move to enforcement.

_dmarc.your-domain.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; ruf=mailto:ruf@dmarcbusta.pro; fo=1; adkim=r; aspf=r; pct=100; ri=86400"

Tag-by-tag breakdown:

Once you have reviewed 14 or more days of aggregate reports and confirmed all legitimate sending sources are authenticating, progress to p=quarantine, then to p=reject.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

Send a test email from your SendGrid domain to a Gmail or Yahoo address you control. In Gmail, open the message and click the three-dot menu → Show original. At the top of the raw message you will see an authentication summary. You are looking for all three to show pass:

spf=pass   smtp.mailfrom=your-domain.com
dkim=pass  header.d=your-domain.com
dmarc=pass header.from=your-domain.com

• spf=pass — the sending IP is authorized by the SPF record of the MAIL FROM (envelope sender) domain, which for SendGrid is typically a subdomain they control via your CNAME setup.
• dkim=pass — the DKIM signature in the message header is cryptographically valid and the d= tag aligns with your From: domain.
• dmarc=pass — at least one of SPF or DKIM passed and the passing identifier aligns with the From: header domain. DMARC does not require both to pass, only one with alignment.

If any of the three shows fail or permerror, do not advance the DMARC policy beyond p=none until the issue is resolved.

Common errors with SendGrid

• CNAME not verified in SendGrid after publishing: DNS propagation can lag. Wait at least 30 minutes and retry the verification inside SendGrid. If it continues to fail, double-check that your DNS provider did not append your domain to the record name (creating s1._domainkey.your-domain.com.your-domain.com), which is a common mistake on cPanel hosts.
• DKIM alignment failure when using a subdomain sender: If your From: header uses @mail.your-domain.com but your DMARC policy is published at _dmarc.your-domain.com, alignment still passes under relaxed mode. However, if you have published a subdomain-level DMARC record at _dmarc.mail.your-domain.com with a stricter policy, that record takes precedence for subdomain mail.
• SPF permerror from too many lookups: If you chose the manual include: path instead of the CNAME delegation path, adding SendGrid's include on top of other email service providers can push you over the 10-lookup limit. Audit your full SPF chain before publishing changes.
• Duplicate SPF TXT records: Some DNS providers allow you to add a second TXT record at the root zone. Having two v=spf1 records is an RFC violation that causes spf=permerror. Merge all mechanisms into one record.
• Sending from a domain not yet authenticated in SendGrid: If you add a second sending domain to your SendGrid account later and do not repeat the Sender Authentication process for it, mail from that domain will fail DKIM. Each domain you send from in SendGrid requires its own separate authentication setup.

How DMARC Busta helps

The steps above are a one-time configuration, but email authentication is an ongoing operation. New sending sources appear, SPF records drift past the 10-lookup limit, DKIM selectors expire, and DMARC reports pile up as unprocessed XML. DMARC Busta is designed to manage these operational concerns at scale — across 10,000+ domains if needed — without manual intervention.

Autopilot mode monitors your aggregate DMARC reports and progressively tightens your policy from p=none to p=quarantine to p=reject once legitimate sources are confirmed authenticating — no manual policy edits required. SPF Auto-Repair uses automated delegation to keep your SPF record under the 10-lookup limit as your sending stack changes, replacing brittle manual include chains with a managed flat record. Managed DMARC reporting parses incoming aggregate and forensic reports and surfaces actionable findings, so you spend time fixing problems rather than decoding XML.

Start your free trial and put your email authentication on autopilot.