550 5.7.26 DMARC Policy Rejection: How to Fix It

550 5.7.26 is Gmail's permanent rejection for mail that fails your domain's DMARC policy. Some servers word it as 550 message rejected due to sender's DMARC policy. DMARC passes only when SPF or DKIM authenticates the same domain as your From address, so find the service whose Return-Path and DKIM d= show its own domain, and authenticate your domain there.

Seeing 5.7.1, 5.7.509, 5.7.515 or a DMARC permerror instead? The code table below sends you to the right fix. Because a 5xx code is permanent, the sending server will not retry; fix the cause, then resend.

Exact error text: the three 550 5.7.26 bounces#

Google's SMTP error reference lists three different messages under 550 5.7.26, and they point to different fixes. Match the wording in your bounce to one of these (yourco.com stands in for your domain). In a raw bounce, long replies are split across lines that each start 550-5.7.26, which is why the hyphenated form shows up too.

• DMARC policy wording: the message failed DMARC and your record says quarantine or reject. Most of this page is about this case.
• Unauthenticated sender wording: neither SPF nor DKIM passed at all. Gmail requires every sender to use at least one, so start with Fix 3, then check the Gmail and Yahoo bulk sender requirements.
• SPF hard-fail wording: your SPF record ends in -all and the sending server is not listed in it. Add that service's include, or move it to a subdomain with its own SPF.

Other DMARC rejection codes: 5.7.1, 5.7.509, 5.7.515 and permerror#

Different receivers word a DMARC failure differently. This table maps the codes people search for to who sends them and what they mean. Gmail and Microsoft rows come from their own published references, checked in October 2026; providers revise these lists, so confirm against the source when a code does not match.

How to fix a DMARC fail, in order#

• Find the failing sender: open a copy of the message in Gmail with Show original and read which domain SPF and DKIM authenticated.
• Align it: authenticate your domain inside that service so its DKIM d= or Return-Path uses your domain (Fixes 1 to 3 below).
• Only then tighten policy: hold at p=none while you fix sources, and move to quarantine and reject once aggregate reports are clean.

What 550 5.7.26 actually means#

The 550 is a permanent (5xx) failure. In the enhanced-status registry, RFC 7372 defines X.7.26 as multiple authentication checks failed, and that is exactly what a DMARC failure is: neither SPF nor DKIM produced an aligned pass. So this bounce is never about one missing DNS record alone. It means the domain in your From header publishes DMARC, and this message did not authenticate as that domain.

Google's reference advises contacting the domain's administrator if the mail was legitimate, a clue that the fix lives in the sender's setup, not the recipient's.

SPF or DKIM pass is not DMARC alignment#

The most common misread: SPF passes, or DKIM passes, so you assume DMARC is fine. SPF authenticates the envelope sender (the Return-Path, or MAIL FROM), not the From header a person sees. DKIM authenticates whatever domain is in the signature's d= tag, which a sending service often sets to its own domain.

RFC 9989, the current DMARC standard, counts a pass only when the authenticated domain aligns with the From domain. Relaxed alignment, the default, matches on the organizational domain, so mail.yourco.com aligns with yourco.com. Strict alignment needs an exact match. DMARC passes if either SPF or DKIM aligns.

If SPF passes but DKIM does not align, look at the DKIM-Signature header. A d= domain such as esp.com or a vendor's shared domain means the service is signing for itself. Set up that service's custom DKIM for your domain (usually two or three CNAME records) so it signs with d=yourco.com. That single aligned signature is enough for DMARC, and unlike SPF it survives forwarding.

Which cause you have: read the headers#

Send a test to a Gmail account you control, open it, and choose Show original. Gmail prints the SPF, DKIM and DMARC results and the domain each one authenticated; the Authentication-Results line reading dmarc=fail against your From domain is the check that bounced you. Match the evidence to a row, then go to that fix.

The two paths DMARC compares#

Fix 1: Authenticate a third-party sender to your domain#

When an email platform, CRM, help desk or invoicing tool sends as your address, it signs with its own DKIM domain and uses its own Return-Path by default. Both authenticate the vendor, so DMARC fails on alignment even though SPF and DKIM technically pass.

1. 1

   Find the failing sender

   Open a bounced or delivered test message and note which vendor's domain appears in the DKIM d= tag and the Return-Path.

2. 2

   Open the vendor's domain authentication settings

   Look for a setting called authenticate domain, verified or sending domain, DKIM setup, or custom Return-Path, and add your domain.

3. 3

   Publish the DNS records they give you

   Usually CNAMEs for DKIM, and sometimes a custom Return-Path subdomain such as bounces.yourco.com. Add each record at your DNS host exactly as shown.

4. 4

   Let the vendor verify, then test

   Send one message to a Gmail address you control and choose Show original. You want dkim=pass with d=yourco.com, or SPF authenticating a subdomain of yourco.com, and dmarc=pass.

Fix 2: Repair a Gmail 'Send mail as' alias#

If a custom-domain address under Settings, Accounts and import, Send mail as goes out through Gmail itself, the message is signed by gmail.com and its SPF resolves to Google, so neither identifier aligns with your domain and DMARC fails. This mostly affects older alias setups.

1. 1

   Confirm the misalignment

   Send a test from the alias to another mailbox, open Show original, and check whether the DKIM d= and the SPF domain read gmail.com instead of yours.

2. 2

   Route through your domain's real SMTP

   Edit the Send mail as address to use your domain provider's SMTP server, such as Google Workspace with the domain added or your host's SMTP.

3. 3

   Turn on SPF and DKIM for the domain itself

   Publish your provider's SPF include and enable DKIM signing for yourco.com at that provider, as in Fix 3.

4. 4

   Retest

   A fresh Show original should show your own domain authenticated and dmarc=pass.

Fix 3: Turn on authentication for your own domain#

If you send directly from Google Workspace or Microsoft 365 and still get 5.7.26, the usual gap is that DKIM was never switched on, or SPF is missing the provider's include.

1. 1

   Publish or repair SPF

   Keep exactly one SPF TXT record at your root. Google uses include:_spf.google.com; Microsoft 365 uses include:spf.protection.outlook.com. End the record with ~all.

2. 2

   Generate and enable DKIM

   Google Workspace: Admin console, Apps, Google Workspace, Gmail, Authenticate email; generate the key, publish the TXT record, then start authentication. Microsoft 365: enable DKIM in the Defender portal and publish the two CNAMEs.

3. 3

   Confirm your DMARC record

   Publish one TXT record at _dmarc.yourco.com, such as v=DMARC1; p=none; rua=mailto:[email protected]. Move to quarantine and then reject once alignment is confirmed.

4. 4

   Test

   Send to a Gmail address, open Show original, and confirm an aligned spf=pass or dkim=pass, and dmarc=pass.

Preventing it#

• Inventory every service that sends as your domain, including your mail platform, CRM, help desk, invoicing and marketing tools, and authenticate each one.
• Roll DMARC out in stages: p=none to monitor, read the aggregate reports, then quarantine, then reject once every legitimate source aligns.
• Keep reading aggregate reports after you reach reject. A tool added months later can start failing and trigger fresh bounces.

Where a mail client fits, and where it does not#

A mail client cannot fix this for you. 550 5.7.26 is a sending-side problem, fixed in your DNS and your sending services. We build AI Emaily, a mail client, not a DMARC monitor, an ESP or a deliverability tester, so it will not publish records or repair alignment. On the receiving side, AI Emaily's spam and phishing protection weighs whether a sender is who it claims to be before trusting a link or a request, the mirror image of the check that bounced your mail.