550 Rejected by Header-based Anti-Spoofing Policy (SendGrid)

Quick verdict: Despite showing up in your SendGrid Activity Feed, this 550 is not generated by SendGrid. It is a permanent rejection returned by the recipient's mail gateway — almost always Mimecast, whose error reads 550 Rejected by header based Anti-Spoofing policy: <address>. SendGrid simply relays that bounce back to you. The same message text is reported verbatim by senders using AWS SES, Marketo, and Google Apps Script, because the rejection comes from the receiver, not the sender.

What causes "550 rejected by header based anti-spoofing policy"?

Mimecast's Anti-Spoofing policy inspects the header (visible) From address. When it sees an address belonging to a domain Mimecast protects (an internal/customer domain) but the message arrived over an external, unauthorized route — in this case SendGrid's shared or dedicated IPs — it treats the message as a potential spoof and rejects the SMTP transaction with a permanent 550 (RFC 5321 §4.2.1 permanent negative completion).

The classic trigger is "same-domain" mail sent through a third party: the From and the recipient (To) are both on a domain Mimecast protects, but the mail is injected by an ESP like SendGrid instead of the domain's own servers. Legitimate internal mail is expected to originate from internal sources, so Mimecast flags the external path.

Mimecast evaluates several signals, and a gap in any of them can keep the policy from trusting the route:

• The header From domain (the protected identity)
• The source IP address (SendGrid's sending IP)
• The SPF result for the Return-Path / envelope domain
• The DKIM signing domain and whether it aligns with the From domain
• Any existing Anti-Spoofing exception policies

Note this is a header-based check. SPF and DKIM operate on the envelope sender and signing domain, so a message can pass SPF/DKIM yet still be rejected if Mimecast doesn't have an exception trusting that external source for your protected domain. Authentication is necessary but, on its own, not always sufficient.

How do I fix the Mimecast anti-spoofing rejection when sending via SendGrid?

This is a two-sided fix. Do the sender-side authentication first, then have the receiving Mimecast admin add a scoped exception.

On the SendGrid (sender) side:

1. Authenticate your domain in SendGrid. Complete Sender Authentication (Domain Authentication / Automated Security) for your domain.
2. Verify SPF and DKIM are both published. Enabling Sender Authentication / Automated Security in SendGrid delegates an em-subdomain (e.g. em123.yourdomain.com) to SendGrid via a CNAME record. SendGrid then auto-publishes the SPF (TXT) record and the DKIM (CNAME) records under that delegated subdomain, covering the Return-Path/envelope domain and the DKIM signing domain. Confirm both resolve correctly in DNS.
3. Publish a DMARC record (v=DMARC1; p=...) so the receiver can see that DKIM/SPF align with your From domain. DMARC alignment is what lets a receiver distinguish your authorized SendGrid traffic from a real spoof.
4. Send a test to a non-Mimecast mailbox (e.g. a Gmail account) and inspect the headers — confirm dkim=pass, spf=pass, and dmarc=pass before involving the recipient's admin.

On the recipient's Mimecast (receiver) side — this is the part that actually clears the 550, and it must be done by the receiving organization's Mimecast administrator:

1. Confirm DNS first. Don't bypass anti-spoofing until SPF/DKIM/DMARC genuinely pass — otherwise you'd be whitelisting a real spoofing hole.
2. Create an Anti-Spoofing policy exception ("take no action") scoped to the legitimate sender — by source IP (SendGrid's outbound ranges, ideally a dedicated IP) or, for shared/dynamic provider IPs, an SPF-based bypass that trusts mail passing SPF for your domain. SPF-based bypass is preferred for large providers because their IPs change.
3. Scope it tightly to the specific sending domain/addresses and, where possible, specific recipients — rather than weakening anti-spoofing globally.
4. Check policy order so the new "permit / take no action" exception is evaluated before the broad reject policy.

If you don't control the receiving domain, you'll need to ask that organization's IT/email team to add the exception — there is nothing further you can change inside SendGrid once your authentication passes.

What this error is not

It is not caused by missing IP whitelisting on SendGrid's outbound side, and it is unrelated to Google "Less Secure Apps." Treating it as a generic SPF/DKIM problem on your own server misses the point: the block lives in the recipient's Mimecast tenant. The single most reliable resolution is the Mimecast Anti-Spoofing exception, backed by passing DMARC alignment.

Note: some sender community threads (e.g. discussions of this same bounce on AWS SES) label it a "transient" bounce. That's a mislabel — a 550/5yz response is a permanent SMTP failure per RFC 5321 §4.2.1, and retrying without fixing authentication or getting a Mimecast exception won't resolve it.