What causes DMARC bounces and SendGrid authentication issues?
Published 10 Jul 2025
Updated 2 Aug 2026
11 min read
Summarize with
Updated on 2 Aug 2026: We added SendGrid strict-alignment fixes and updated staged DMARC policy guidance for RFC 9989.
DMARC bounces happen when a receiving server checks the visible From domain, gets a DMARC fail result, and factors the domain's published policy into its handling decision. With SendGrid, a common cause is authentication with a SendGrid-controlled domain instead of your domain, so SPF or DKIM can pass technically while DMARC still fails for the sender identity the recipient sees.
The short answer is this: a sudden burst of DMARC bounces with p=reject usually means one of four things. Your SendGrid domain authentication was not applied, a DKIM signature used the wrong domain, SPF passed on a bounce domain that is not aligned with the From domain, or a provider-side incident caused previously working mail to be signed or routed differently.
- Reject policy: A domain at p=reject raises the chance that an authentication break becomes a visible SMTP rejection.
- Wrong DKIM domain: The DKIM signature can show a SendGrid domain where your own sending domain should appear.
- SPF path mismatch: SPF can pass for the return-path domain while DMARC fails against the visible From domain.
- DNS drift: Changed CNAMEs, missing selectors, stale sender authentication, or DNS outages can break a domain that worked for years.
- Temporary incident: A time-boxed spike across many domains points toward sender infrastructure or a receiver-side rule change.
This is exactly why DMARC monitoring matters. The bounce tells you the symptom, but aggregate reports and headers tell you which domain, source, selector, receiver, and policy were involved.
Why a DMARC bounce happens
DMARC does not simply ask, "Did SPF pass?" or "Did DKIM pass?" It requires at least one passing authentication result whose domain aligns with the visible From domain. Under the default relaxed mode, the organizational domains must match. Under strict alignment, the domains must match exactly. If neither authenticated domain aligns under the published mode, DMARC fails.
That detail is the reason SendGrid problems can feel confusing. The headers can show dkim=pass and spf=pass, but DMARC can still fail if those passes belong to an unaligned SendGrid domain or do not satisfy strict alignment.
Header pattern that fails DMARCtext
Authentication-Results: receiver.example; dkim=pass header.d=sendgrid.net; spf=pass smtp.mailfrom=bounces.sendgrid.net; dmarc=fail header.from=example.com
Split the bounce type first
Two different problems get called "DMARC bounces." They need different fixes.
- Message bounce: The recipient rejected your campaign, transactional email, or notification because DMARC failed.
- Report bounce: A mailbox that receives DMARC aggregate reports rejected the XML report delivery.
- Fix path: Message bounces require header and DNS checks, while report bounces require mailbox or report-URI checks.
Policy impact during an authentication break
The same technical failure has a different likely result depending on the published DMARC policy and the receiver's broader delivery decision.
Monitor
p=none
Failures are reported, but the domain owner expresses no DMARC handling preference.
Quarantine
p=quarantine
The domain owner asks receivers to treat failing mail as suspicious.
Reject
p=reject
The domain owner asks receivers to reject failing mail, subject to the receiver's other checks.
Why SendGrid can be involved
SendGrid sends on behalf of many domains. For your mail to pass DMARC, SendGrid must produce an aligned SPF or DKIM result for the domain in the visible From address. Domain authentication usually creates CNAME records for DKIM signing and a delegated bounce subdomain, plus the sender identity used inside SendGrid.
If a message falls back to a SendGrid domain in both the DKIM signature and return path, receivers can reject it when your domain publishes p=reject. SendGrid's own support material on DMARC bounces points to the same core issue: a passing authenticated domain must be aligned with the domain the recipient evaluates.
SendGrid sender authentication screen with DKIM, SPF, and CNAME status.
|
|
|
|---|---|---|
Wrong DKIM domain | d=sendgrid.net | Reverify domain authentication |
Strict SPF misalignment | From example.com, Return-Path em123.example.com | Review aspf or use a matching custom return path |
Sender not verified | Fallback sender or blocked API request | Use the intended authenticated domain |
Subuser mismatch | Only one subuser fails | Check the subuser's domain setup |
Provider incident | A narrow cross-domain time spike | Preserve evidence and open a ticket |
Common SendGrid-related DMARC failure causes.
The strongest clue is scope. One domain failing after a DNS change points toward your configuration. Many unrelated, mature domains failing during the same window points toward a shared sending path, account-level setting, or temporary provider issue.
How strict alignment changes the fix
Check the aspf and adkim tags before treating a SendGrid return-path subdomain as a failure. Both default to relaxed alignment when omitted. Relaxed alignment accepts example.com and em123.example.com because they share an organizational domain. Strict alignment requires exact equality.
|
|
|
|---|---|---|
aspf=r | From example.com, Return-Path em123.example.com | Aligned when SPF passes |
aspf=s | From example.com, Return-Path em123.example.com | Not aligned |
adkim=r | From example.com, d=mail.example.com | Aligned when DKIM passes |
adkim=s | From example.com, d=mail.example.com | Not aligned |
How DMARC alignment modes compare SendGrid authentication domains.
If strict SPF alignment is required, create a SendGrid Custom Return Path that exactly matches the subdomain in the From address. An existing domain authentication cannot simply be edited into that configuration, so plan a new authentication and DNS change. If mail must use the root domain with aspf=s, review whether strict SPF alignment is necessary before asking SendGrid about Preserve Sender.
Preserve Sender is a last resort
Preserve Sender keeps the return path equal to the From address, but SendGrid warns that it can stop bounce and spam-report data from reaching its suppression system. Use it only with a separate process for feedback and suppression management.
How to diagnose the failure
Do not treat the bounce code as the source of truth. The bounce says what the receiver did. The headers and DNS explain why. If you have the original received message, inspect the Authentication-Results header before changing DNS.
- Confirm policy and alignment: Check p, aspf, and adkim on the From domain.
- Read headers: Find the authentication results, DKIM signing domain, return-path domain, and visible From domain.
- Compare domains: Apply organizational-domain matching for relaxed alignment or exact matching for strict alignment.
- Check SendGrid: Verify the sending domain, account, subuser, sender identity, and domain authentication selected for the message.
- Check DNS: Confirm DKIM CNAMEs, the return-path CNAME, its delegated SPF answer, and the DMARC TXT record resolve from public DNS.
- Check scope: Group failures by time, receiver, sending domain, template, and SendGrid account or subuser.
Quick DNS checksbash
dig TXT _dmarc.example.com dig CNAME s1._domainkey.example.com dig CNAME s2._domainkey.example.com dig CNAME em123.example.com
Replace the example selector and return-path label with the values SendGrid generated for your authentication. If you do not have the original headers, start with a broad domain health checker run. It will not prove what happened during a past SendGrid incident, but it catches DNS mistakes that cause the same bounce pattern.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
A clean DNS result does not clear SendGrid automatically. It only tells you the current domain state. For a time-bound incident, compare current DNS with the message headers from the failure window and the sending logs from the same period. For a deeper checklist, use this DMARC troubleshooting process after you collect the failed message source.
What to fix first
Fix the cause that matches the scope. A single domain failure needs DNS and sender-authentication repair. A cross-domain spike needs evidence collection first, because random DNS changes can make a short incident last longer.
When it is your setup
- CNAMEs: Repair missing or changed DKIM and return-path CNAMEs for the exact SendGrid authenticated domain.
- Sender identity: Make the From domain match the SendGrid domain authentication assigned to the sender under the published alignment mode.
- Subuser: Check whether the message was sent through a subuser without the right domain setup.
- Alignment mode: Use a matching custom return path when strict SPF alignment is required.
When it is not your setup
- Scope: Look for the same failure across many domains during the same time window.
- Headers: Save full headers proving which DKIM domain and return path were used.
- Ticket: Give SendGrid timestamps, message IDs, domains, receivers, and header samples.
- Rollback: Do not undo long-working DNS unless the headers prove DNS is the cause.
Use testing mode carefully
RFC 9989 removed the percentage-based pct tag and introduced t=y for testing. It asks receivers to apply one policy step lower to failures, so p=reject; t=y is treated as quarantine and p=quarantine; t=y is treated as none. Receiver support can lag, so do not use testing mode as a substitute for fixing alignment.
Short-term testing mode exampletext
v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.com
This is where Hosted DMARC helps. Instead of editing raw DNS during an incident, you can stage policy changes through a managed workflow, then move back to enforcement once SendGrid and every other source is passing again.
How Suped helps with this workflow
Suped is our DMARC reporting and email authentication platform, so the workflow is built around the exact questions that matter during a bounce spike: which source failed, which domain was evaluated, which receiver rejected it, and what step fixes it.
Issue steps to fix dialog showing the issue overview, tailored fix steps, and verification action
Suped connects record state with sender sources and failure patterns, then turns that evidence into repair steps. That matters when SendGrid is only one of several legitimate senders on a domain.
- Issue detection: Suped flags failing sources and gives practical steps to fix SPF, DKIM, and DMARC issues.
- Real-time alerts: Alerts help you catch a sudden SendGrid authentication shift before support volume grows.
- Hosted controls: Hosted DMARC, Hosted SPF, SPF flattening, and Hosted MTA-STS reduce urgent DNS edits.
- Unified checks: DMARC, SPF, DKIM, blocklist (blacklist), and deliverability signals are visible together.
- MSP scale: Agencies and managed service providers can manage many client domains in one dashboard.
Decision path for sudden bounces
When a domain that has worked for years suddenly starts bouncing, do not assume the old setup is wrong. Start with timing and scope, then prove the failing authentication path.
Flowchart for diagnosing sudden DMARC bounces in SendGrid.
The most useful evidence packet has the failed message headers, the SendGrid message ID, the From domain, the return-path domain, the DKIM signing domain, the recipient domain, and the exact time of the bounce. With that packet, you can separate a configuration error from a provider-side routing or signing problem.
Evidence to include in a SendGrid ticket
- Message IDs: Provide failed and successful examples from the same domain and time period.
- Headers: Include full headers showing DKIM, SPF, DMARC, return path, and From domain.
- Scope: List affected domains, recipients, subusers, templates, and the start and end times.
- DNS proof: Attach current DNS results so support can separate DNS state from sending behavior.
Views from the trenches
Best practices
Separate report-delivery bounces from message bounces before changing DNS or policy.
Save full headers during the failure window; later checks only show the current state.
Group failures by sender, receiver, domain, subuser, and time before opening tickets.
Common pitfalls
Treating SPF pass as DMARC pass hides cases where the return-path domain differs.
Changing long-working DNS during a shared outage can create a second failure mode.
Missing subuser differences causes teams to fix the wrong SendGrid configuration.
Expert tips
Compare failed and successful samples from the same domain to isolate routing changes.
Check relaxed versus strict alignment before treating a bounce subdomain as wrong.
Use aggregate reports to verify recovery, not only lower bounce volume in logs alone.
Marketer from Email Geeks says DMARC bounces are often specific to a sending domain, and receiver-specific causes are less common but still worth checking.
2024-07-23 - Email Geeks
Marketer from Email Geeks says the first diagnostic split is whether DMARC reports bounced or whether normal mail failed authentication.
2024-07-23 - Email Geeks
What to do next
A DMARC bounce from SendGrid is usually clear once you read the headers. The key question is whether SPF or DKIM passed and aligned with your visible From domain under the published relaxed or strict mode.
If the failing header shows an unaligned SendGrid signing domain or return path while the From domain is yours, fix SendGrid domain authentication or gather evidence for SendGrid support. If the failure affects many mature domains in one narrow window, preserve proof before changing DNS. If the domain is at p=reject, treat policy changes as temporary incident controls, not the final fix.
Suped turns those checks into a repeatable workflow: monitor failures, identify the affected source, receive alerts, use hosted records when policy needs staging, and verify recovery across every legitimate sender.
