SendGrid will deliver your mail whether or not you authenticate it. But under a DMARC policy of quarantine or reject, unauthenticated SendGrid traffic is exactly what gets filtered. The fix is not "add an SPF include" — it is completing domain authentication so that SendGrid signs with your domain and sends the envelope from a subdomain you control.
Why alignment matters more than passing
DMARC does not ask whether SPF or DKIM passed. It asks whether the domain that passed aligns with the domain in the visible From header. SendGrid can pass SPF against sendgrid.net and still fail DMARC, because that is not your domain. DKIM is what usually saves the message, and only if the signing domain is yours.
Step 1 — Complete domain authentication
- In SendGrid, open Settings → Sender Authentication and choose domain authentication, not single sender verification.
- Pick the domain you actually send from. A dedicated subdomain such as
mail.example.com keeps ESP reputation away from your root domain and is easier to isolate later.
- SendGrid generates CNAME records: two for DKIM selectors and, if you enable it, one for link branding. Copy them exactly — the selector names are generated per account and cannot be guessed.
- Publish the CNAMEs at your DNS provider. On Cloudflare, set the proxy status to DNS only (grey cloud). A proxied CNAME will not verify, because the record must resolve to SendGrid, not to Cloudflare.
- Return to SendGrid and click verify. Wait for the check to pass before changing any DMARC policy.
Step 2 — Decide what SPF should say
Once domain authentication is active, SendGrid sends the envelope from your bounce subdomain, so SPF is evaluated there and your root SPF record does not need a SendGrid include. Teams that still rely on a shared sending domain, or that never finished authentication, do need include:sendgrid.net in the root record.
Keep the record within the 10-DNS-lookup limit. Every include: and every a or mx mechanism costs a lookup, and a record that exceeds the limit returns a permanent error rather than a pass. Verify the final result with the SPF Checker.
Step 3 — Publish DMARC and watch one cycle
Start at p=none with a reporting address, then read the aggregate reports before enforcing. Under SendGrid-specific traffic you should see DKIM pass with d= set to your domain. If DKIM passes but shows a different signing domain, authentication was completed for the wrong domain.
Troubleshooting the usual failures
DKIM verifies in SendGrid but DMARC still fails
Check the selector domain. A signature on em1234.example.com aligns with example.com only when adkim=r (relaxed), which is the default. If you set adkim=s, the domains must match exactly.
Only some recipients filter the mail
Authentication is per-message, not per-recipient. A provider that filters anyway is reacting to reputation or content, not to a broken record. Compare placement across providers before rewriting DNS.
Bounces look like they come from a different domain
That is the bounce subdomain doing its job. Custom MAIL FROM separates bounce handling from your root domain and is the intended design, not a misconfiguration.
FAQ
Do I need both SPF and DKIM for SendGrid?
DMARC passes if either mechanism aligns. In practice DKIM is the reliable one for ESP traffic, so complete domain authentication first and treat SPF as reinforcement.
Can I authenticate a domain I do not own?
No. Verification requires publishing records in that domain's DNS zone. Claiming a domain you cannot edit will fail at the verification step.
How long before DMARC enforcement is safe?
Long enough to cover a full business cycle, including monthly invoices and any campaign that only runs occasionally. Enforce only when every failing source in your reports is one you recognise.
