SendGrid SPF, DKIM and DMARC setup, step by step

To configure SPF and DKIM for Twilio SendGrid, authenticate your sending domain in Settings → Sender Authentication, then publish the DNS records generated for your account. With Automated Security enabled, SendGrid uses CNAME delegation to manage SPF and DKIM. Do not substitute a generic SPF record or another account's DKIM targets. SendGrid domain authentication

This guide covers email actually sent through SendGrid's API or SMTP service, including applications using a SendGrid subuser. It does not configure Microsoft 365, Google Workspace, or a separate email provider simply because they share your From domain.

If the same organization also sends staff mail through Microsoft 365, configure that separate route with our Microsoft 365 SPF and DKIM guide.

Before you change DNS

Write down the application, SendGrid account or subuser, visible From address, DNS provider, and person responsible for approving DNS changes. Include the sending region when applicable. Keep a copy of the existing zone records and the application's current sending configuration.

EU-pinned domains and link branding require Email API Pro or higher, or Marketing Campaigns Advanced or higher. Regional email users must select Make domain EU-pinned. Retain the exact regional records issued by the eligible account rather than adapting a global example. Regional setup requirements

Choose a representative message from the actual application route, using an authorized test identity, controlled valid recipient and non-sensitive content. For a receipt or order workflow, use a non-charging test event rather than a real customer purchase; do not disrupt customer accounts or passwords. A manually composed test through a different account cannot establish whether the application workflow is correct.

Single Sender Verification is not the same task as domain authentication. Use the domain-authentication workflow for the DNS-backed configuration described here. If you manage several brands or environments, maintain a separate worksheet for each identity rather than assuming one verified domain covers every sender.

For subusers, verify which account owns the authentication and whether it is assigned to the sending subuser. SendGrid supports authenticating within the subuser or assigning a parent-verified domain. Its UI route is Settings → Subuser Management → select the subuser → Change Sending beside Domain Authentication. SendGrid subuser assignment

Which SendGrid DNS records do you need?

Use the generated record list as the implementation specification. Record counts can vary with security mode and additional features. In particular, separate authentication records from link branding and any suggested DMARC policy.

If the generated types, owners or purposes disagree with the selected security mode or documentation, stop and reconcile the output with SendGrid Support before publishing. The setup page contains inconsistent labeling of DKIM aliases as link branding; its record table and dedicated DKIM instructions distinguish those functions. Do not repurpose a DKIM record to resolve that wording discrepancy.

Do not confuse Automated Setup with Automated Security. Automated Setup is the documented GoDaddy DNS-publication option; it requires Automated Security and does not support Link Branding. Manual DNS publication can still use Automated Security and its managed CNAMEs. Review the proposed changes and DNS access separately before authorizing any automatic setup. SendGrid setup options

SendGrid's DKIM documentation describes two default selectors, s1 and s2, used for rotation, with one active for signing at a time. Keep both generated records even if your latest message uses only one. With Automated Security disabled, SendGrid instead supplies authentication TXT and MX records that you must maintain. These are account instructions, not permission to replace your root-domain mailbox MX records. SendGrid DKIM records

Configure domain authentication step by step

1. Open Settings → Sender Authentication → Domain Authentication → Get Started in the correct account.
2. Select the DNS host and enter the intended sending domain. If the From address uses a subdomain, confirm that exact identity is covered rather than assuming parent-domain verification applies automatically.
3. Review Advanced Settings. Normally leave Use automated security enabled. Select a custom Return-Path or custom DKIM selector only when your naming plan requires it, such as a collision with an existing selector.
4. Open the generated DNS record list and save a dated copy. Publish the exact owner, type, and target shown, following your DNS host's name-format rules.
5. Return to SendGrid and select Verify after the records resolve publicly. Investigate an incorrect answer rather than repeatedly regenerating records. SendGrid setup instructions

Before saving any record, compare its fully qualified hostname with the existing zone. A DNS panel may append the zone automatically. Entering the full name into a relative-name field can produce a duplicated suffix. Treat an existing record at the same name as a collision to resolve, not something to overwrite casually.

The general setup instructions say to enter only the root domain in their domain field, while the custom Return-Path article separately describes subdomain sending. Do not assume that any subdomain can be entered in every wizard. Confirm the supported account flow and how it covers your intended From identity before choosing custom settings. General setup · Subdomain Return-Path configuration

For an illustrative issued owner SELECTOR._domainkey.news.example.com, a suffix-appending editor for example.com uses SELECTOR._domainkey.news; one for a separately delegated news.example.com zone uses SELECTOR._domainkey. If _domainkey.news.example.com itself is delegated, use relative SELECTOR in that zone. A full-name field takes the complete issued owner. Replace the placeholder with the actual account selector, preserve existing NS delegations and active selectors, and publish with the actual authority rather than adding an inactive parent-zone copy. DNS zone boundaries.

For Automated Security CNAMEs only, do not add conflicting TXT, A, AAAA, MX or a second CNAME at an issued alias owner. The following controls do not apply to the manual TXT/MX route. Where the issued authentication or return-path records require literal CNAME answers, use DNS-only aliases returning the exact targets, without an HTTP proxy or flattening hiding them. Turn the relevant per-record Flatten control off when available and ensure applicable zone settings preserve those aliases. Cloudflare documents that flatten-all cannot be overridden per record, apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are conditional DNS-host behaviors, not assumed controls in every panel. If mandatory apex/same-zone behavior or a shared setting prevents the required answer, stop and coordinate a supported configuration with the DNS owner and sender. Do not blindly change the whole zone or remove an existing delegation. CNAME verification, flattening controls and limits.

If SendGrid suggests a p=none DMARC record, first check the policy already governing the From domain, including an inherited parent-domain policy. Do not replace an existing policy, publish a duplicate, or add a weaker subdomain policy just to complete this setup. Treat any intended DMARC-policy change as a separate reviewed change.

Only if no direct or applicable inherited DMARC policy exists, and the domain owner approves this first policy and a monitoring/review plan after reviewing legitimate senders, a first TXT policy for fictional From domain example.com may be v=DMARC1; p=none at full owner _dmarc.example.com. The minimal value requests no reports; provision an approved reporting destination and review process before adding rua. Preserve established enforcement and authorized reports.

For a first policy at full owner _dmarc.example.com, a relative-name field in zone example.com takes _dmarc. For a deliberately approved child policy at _dmarc.news.example.com, use _dmarc.news in the parent zone or _dmarc in a separately delegated news.example.com zone. A full-name field takes the complete owner. These examples do not authorize overriding an inherited policy.

Compare the Organizational Domain of the aggregate-report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as the policy domain is excepted; a different hostname alone does not make it external. Obtain the reporting operator's exact authorization instructions when required. This protocol check is separate from the domain owner's approval to share report data; agree access, retention and privacy. RFC 9990 section 4.

For example, RETURN_PATH_HOST, DKIM_HOST_1, and DKIM_TARGET_1 in your worksheet are placeholders. Replace them with values copied from your account. They are not literal DNS names, and this article intentionally supplies no account-like target that could be mistaken for a working configuration.

Does SendGrid need an SPF include at the root domain?

For the Automated Security route, use the delegated Return-Path record supplied by SendGrid. Do not add a second root SPF policy merely because you use SendGrid. SPF evaluates the envelope-sender domain, which can differ from the visible From domain. SPF specification

An SPF check against the root alone therefore does not prove the SendGrid route is configured. Inspect the message's actual envelope identity and its DNS resolution. If you use the manual-security route, apply the generated SPF instruction at its specified hostname and preserve any other authorized senders at that same name.

For manual SPF, publish exactly one v=spf1 TXT policy at the issued envelope owner, preserving all legitimate senders and approved qualifiers. The limit is ten evaluated DNS-dependent terms across the full nested policy, not ten visible includes. SPF evaluation limit.

If the existing SPF policy uses redirect=, reconcile its authorizations and terminal behavior with the DNS owner before changing it. Any all mechanism makes redirect ignored regardless of their order. Do not append all automatically: preserve the redirected senders and approved policy semantics through a reviewed design. SPF all and redirect processing.

A custom Return-Path changes the bounce-domain label used by the service. It does not automatically make every possible From address aligned. SendGrid documents a custom Return-Path option for matching a chosen sending subdomain and warns that rewriting it directly to the root domain is often not possible. SendGrid custom Return-Path

SendGrid says this custom Return-Path choice cannot be applied by editing an existing domain authentication. Treat recreation as a controlled transition: agree the account/subuser assignment, replacement records, test and rollback plan with the sending and DNS owners, and use Support when the supported migration is unclear. Keep the working authentication and delegation until dependencies and queued mail are accounted for; do not delete them merely to expose a creation option.

For DMARC, relaxed alignment permits a shared Organizational Domain; strict alignment requires identical domains. A passing, aligned SPF or DKIM result can satisfy DMARC. Evaluate the actual names and policy rather than treating “custom” as a guarantee of strict alignment. DMARC specification, RFC 9989

Validate DNS, then validate a delivered message

Use two separate checks. The first proves publication; the second checks the application route.

Public DNS checks: Query each generated hostname at the authoritative nameserver and through a public recursive resolver. For Automated Security, replace the capitalized placeholders before running these read-only CNAME queries:

dig CNAME RETURN_PATH_HOST +short
dig CNAME DKIM_HOST_1 +short
dig CNAME DKIM_HOST_2 +short

For manual security, query the generated Return-Path SPF TXT and MX records and the generated DKIM TXT owner instead:

dig TXT MANUAL_RETURN_PATH_HOST +short
dig MX MANUAL_RETURN_PATH_HOST +short
dig TXT MANUAL_DKIM_HOST +short

These manual-mode placeholders must come from the account-generated record list, not your root mailbox domain by assumption. Compare answers with your saved account record list. Follow each DKIM CNAME to its final TXT key, and inspect the Return-Path destination's SPF data. Save the time, resolver, requested name, and answer. Do not paste API keys or SMTP passwords into a DNS checker.

Before publishing manual-mode MX, have the DNS owner separately approve its exact full owner and complete numeric-priority/target set, including its bounce-routing consequences. Compare every issued entry with that approved plan at authoritative and recursive DNS; stop on missing, extra or unapproved destinations. An account packet alone does not authorize a routing change. Preserve the root mailbox MX and unrelated inbound services.

Message checks: Trigger the representative application email to an external mailbox you control. Open its original source and record:

• The visible From domain.
• Return-Path and the receiving system's smtp.mailfrom result.
• Each DKIM signature's d= signing domain and s= selector.
• The receiving system's SPF, DKIM, and DMARC results in Authentication-Results.

DKIM key lookup uses the selector and signing domain together. Check the selector actually seen on the delivered message, not one guessed from an old screenshot. DKIM specification

Repeat for a subuser, another From domain, or another application only when it represents a different route. Keep the results separate. Do not describe a route as tested until a real message has been inspected.

Establish which results were generated inside the receiving service's known processing boundary and how it removes, ignores or distinguishes externally supplied Authentication-Results. Use receiver-controlled diagnostics or have the receiving-mail administrator confirm its documented handling. A familiar authserv-id string or header position alone is not proof. Ignore attacker-supplied or otherwise untrusted fields; obtain authenticated receiving-system evidence when provenance is uncertain. Receiver-result trust.

For this branded DKIM setup, require the intended SendGrid signature to report dkim=pass and align with the unchanged approved branded From under the effective adkim policy, together with trusted receiver dmarc=pass for that From. Record the expected and observed d= and s=. A rewritten provider From, unrelated passing signature or SPF-only DMARC pass does not complete the intended DKIM deployment. DMARC itself permits either aligned passing method; this is the commissioned signer’s acceptance gate.

Diagnose SPF at the actual envelope owner independently even when aligned DKIM supplies DMARC. For fail or softfail, compare the observed connecting source and MAIL FROM identity with the approved authorization and sending route. For permerror, check duplicate SPF policies, malformed syntax and the full nested DNS-dependent term budget. For temperror, investigate temporary DNS resolution or availability failures and retest after recovery. A provider-owned SPF pass without alignment is different from these failures; escalate errors for provider-owned identities to that sender rather than editing unrelated apex DNS. SPF result definitions.

Troubleshooting SendGrid authentication

SendGrid verifies DNS, but the application still fails: Check account/subuser assignment, the exact From domain, and the credentials' account ownership. Compare the received signature with your intended configuration before changing DNS again.

Check matching and default authenticated domains in the actual sending account or subuser. SendGrid documents a matching From-domain authentication before the valid default; its subuser logic also includes the domain assigned by the parent. A different brand’s default can therefore explain an unexpected signer even when the intended domain is verified elsewhere. Confirm current assignments and application From settings, then retest that route rather than editing otherwise correct DNS. Matching and default-domain behavior

Only one DKIM record verifies: Query both complete names. Look for a wrong target, missing selector, duplicated zone suffix, or collision. Preserve the working record while investigating the other.

SPF passes but DMARC fails: Compare smtp.mailfrom with the visible From domain under the domain's alignment mode. Then inspect DKIM independently. A successful provider-domain SPF result can still be unaligned.

DKIM passes but the message goes to spam: Save the authentication evidence and investigate delivery separately. Authentication does not establish recipient consent, message relevance, or inbox placement. Do not weaken an existing DMARC policy to address a content or reputation issue.

The error persists after DNS edits: Record the old and new answers and check the authoritative zone first. Escalate with the authentication ID, non-secret account identity, record names, timestamp, and redacted message headers. Avoid sending credentials or full customer-message contents.

Acceptance checklist

The DNS owner should hand over the generated record list, public-query evidence, and a real message's authentication results. The application owner should confirm the tested account, subuser, From address, and workflow. Keep a rollback copy and schedule revalidation after account moves, DNS migrations, or sender-identity changes.

This guide is based on public documentation. No customer account, DNS zone, or delivered message was tested for this article.*