Gmail deferred or blocked your message because the domain in its From: address doesn’t match the domain SPF checked or the domain DKIM signed with. Usually a sending service passes SPF and DKIM for its own domain, which doesn’t count for yours. Paste the message headers below to see which identifier is off, then set the service up to sign DKIM with your domain.
Last verified 9 October 2026.
Google’s SMTP error reference lists two codes for this, with the same cause:
421 4.7.32 Your email has been rate limited because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain.
5.7.32 Your email was blocked because the From: header (RFC5322) in this message isn't aligned with either the authenticated SPF or DKIM organizational domain.
4.7.32 is temporary: Gmail rate limited the message and your server retries it. 5.7.32 is permanent: the message was blocked. The first digit of the enhanced code says which (RFC 3463: a permanent failure “is not likely to be resolved by resending the message in the current form”). Google’s table prints the reply code 421 next to both; bounces that reach you may carry a different three-digit reply code in front, such as 550. Go by 5.7.32 and the text.
Both mean the same thing: of the domains Gmail authenticated for the message, the Return-Path domain SPF checked and the d= domain of each DKIM signature, none shares an organizational domain with the From: domain. In DMARC terms, there is no aligned pass.
Bounce texts quoted from Google Workspace Help, Gmail SMTP errors and codes (page last updated 2026-10-07, checked 9 October 2026; trailing “Learn more about DMARC alignment” and sender guidelines links left out); RFC 3463 §2.
Google’s DMARC setup guide: “DMARC passes or fails a message based on how closely the domain in the From: header matches the sending domain specified by either SPF or DKIM.” Three domains are involved:
MAIL FROM, smtp.mailfrom): the domain SPF checks. Sending services often set it to their own bounce domain.d= (header.d, or header.i in Gmail’s header): the domain that signed. Services sign with their own domain until you set up yours.From: you@example.com, d=example.com | Aligned. Identical. |
|---|---|
From: you@example.com, Return-Path bounce.example.com | Aligned under relaxed alignment (the default): same organizational domain. Not aligned if your DMARC record sets aspf=s. |
From: news@mail.example.com, d=example.com | Aligned under relaxed alignment. Not aligned with adkim=s. |
From: you@example.com, d=mailer.example.net, Return-Path bounces.mailer.example.net | Not aligned. SPF and DKIM can both pass, for example.net. This is the usual 5.7.32. |
Your DMARC record sets the mode with aspf= and adkim=, r (relaxed) or s (strict); Google’s guide lists relaxed as the default and says “Relaxed alignment typically provides sufficient spoofing protection.” The full rules, including how the organizational domain is found, are in DMARC alignment failed.
Source: Google Workspace Help, Set up DMARC (page last updated 2026-10-07, checked 9 October 2026).
Paste the headers of a bounced or test message, or type the domains. The check reads your From: domain’s DMARC record from public DNS in your browser, then compares the Return-Path and each DKIM d= domain under its aspf and adkim modes.
Alignment only counts for a check that passed. Whether SPF and DKIM passed for a message is in its Authentication-Results header; this page shows that header’s results when you paste it, as written in the message.
What this can and can’t tell you: pasted headers stay in your browser; only DNS names are looked up, through Cloudflare’s public resolver (Google’s when Cloudflare’s fails). Organizational domains come from the DNS tree walk of RFC 9989, as on the DMARC alignment page, skipping public suffixes such as co.uk or com.pe (from the ICANN section of the Public Suffix List) and hosting platforms such as github.io. It doesn’t verify DKIM signatures or SPF itself: the results shown come from the pasted Authentication-Results header. A link to a result holds only the domains checked, never the pasted headers. A lookup that fails is reported as failed, never as “not aligned”.
Alignment is in the requirements for bulk senders in Google’s Email sender guidelines. Under “Requirements for sending 5,000 or more messages per day”:
For direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain. This is required to pass DMARC alignment.
The guidelines FAQ defines a bulk sender as one “that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period”, and spells the rule out: “For messages sent directly to personal Gmail accounts, the organizational domain in the sender From: header must be aligned with either the SPF organizational domain or the DKIM organizational domain.” Only one needs to align, it adds, and “DMARC alignment isn’t required for forwarded or mailing list messages”. Google also recommends “all senders fully align DMARC to both SPF and DKIM” and expects that to become a requirement.
The FAQ lists the enforcement for “From: header and authentication don’t align” as “Temporary or Permanent Failure codes, or spam foldering”, and says that starting November 2025, “Messages that fail to meet the email sender requirements will experience disruptions, including temporary and permanent rejections.” The other requirements, side by side with Yahoo’s and Microsoft’s, are in bulk sender requirements.
Sources: Google, Email sender guidelines and Email sender guidelines FAQ (checked 9 October 2026).
One aligned pass is enough. Fix 1 is the one to do first; fix 2 adds SPF alignment where the service supports it.
In the service that sent the message (your newsletter tool, CRM, help desk or transactional email provider), open its domain authentication settings. It may be called custom DKIM, sender authentication, branded sending domain or domain verification. Add your From: domain and publish the DNS records it gives you, usually two or three CNAMEs or a TXT record at <selector>._domainkey.yourdomain.com. From then on it signs with d=yourdomain.com, which aligns. This is the more robust fix: a DKIM signature doesn’t depend on the Return-Path and survives a plain forward.
If the key isn’t found after you publish it, check it with the DKIM key check. For Google Workspace itself, see DKIM “Not authenticating”; for Microsoft 365, DKIM CnameMissing.
If the service offers a custom Return-Path or custom MAIL FROM domain, set it to a subdomain of yours, such as bounce.yourdomain.com, and publish the records it asks for (usually a CNAME, or an MX and an SPF TXT record on that subdomain). SPF then passes for a domain with your organizational domain, which aligns under relaxed alignment. Not every service offers this, which is why fix 1 comes first. Step-by-step settings for SendGrid, Mailchimp, Amazon SES, Microsoft 365 and Google Workspace are on the DMARC alignment page.
With aspf=s or adkim=s in your DMARC record, a subdomain doesn’t align for DMARC: bounce.yourdomain.com and d=mail.yourdomain.com fail for you@yourdomain.com. Unless you need strict mode, remove the tag; Google’s DMARC guide calls relaxed alignment typically sufficient. The checker above flags this.
Alignment counts only for a check that passed. If the checker shows d=yourdomain.com aligned but Authentication-Results shows dkim=fail or neutral, the key isn’t published at that selector or doesn’t match. If the Return-Path aligns but SPF doesn’t pass, add the service’s include: to that domain’s SPF record and stay within 10 lookups (SPF PermError).
dkim=pass with header.i=@yourdomain.com (or header.d=yourdomain.com) and dmarc=pass. Or click Copy to clipboard and paste the headers into the checker above.Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=s1 header.b=AbCd1234;
spf=pass (google.com: domain of bounces@bounce.example.com designates 192.0.2.25 as permitted sender) smtp.mailfrom=bounces@bounce.example.com;
dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=example.comSource: Gmail Help, Trace an email with its full header (checked 9 October 2026). The header above is an illustration with documentation addresses.
They passed for the sending provider’s domain, not yours. Gmail checks that the From: domain shares an organizational domain with the domain SPF checked (the Return-Path) or the domain DKIM signed with (d=). A provider that uses its own bounce domain and signs with its own domain passes both checks for itself, and neither counts for your From: address.
No. Google’s sender guidelines FAQ says only one of them needs to be aligned to meet the requirement, though Google recommends aligning both. Aligned DKIM is the better one to start with: it doesn’t depend on the Return-Path and survives plain forwarding.
Same cause, different outcome. 4.7.32 means Gmail rate limited the message (a temporary failure, so your server retries); 5.7.32 means it blocked the message (a permanent failure). Fix the alignment either way: deferred mail that keeps failing alignment won’t get through on retry.
Yes, under relaxed alignment, the default: bounce.example.com and mail.example.com share the organizational domain example.com, so they align with a From: address at example.com. If your DMARC record sets aspf=s or adkim=s (strict), only an exact match counts for DMARC.
If you manage sending domains for clients or brands, Email Security Signals checks a whole list and returns one row per domain with the DMARC policy, SPF, DKIM selectors found and an A–F grade, ready to export as CSV. $0.02 per graded domain ($20 per 1,000); invalid inputs, domains that don’t exist, DNS lookup failures and duplicates are free.
Check a list on the Apify Store →Related: Gmail 550 5.7.26 (sender unauthenticated), DMARC alignment failed, Outlook 550 5.7.515, Yahoo 554 5.7.9, bulk sender requirements and the free DMARC, SPF and DKIM checker.