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.
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.
mail.example.com keeps ESP reputation away from your root domain and is easier to isolate later.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.
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.
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.
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.
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.
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.
No. Verification requires publishing records in that domain's DNS zone. Claiming a domain you cannot edit will fail at the verification step.
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.