550 5.7.26 DMARC Policy Rejection: How to Fix It

If Gmail bounces your mail with 550 5.7.26 unauthenticated email is not accepted due to the domain's DMARC policy, the receiving server did not quietly file it into spam. It refused the message outright. The 550 is a permanent rejection, so the sending server will not retry it.

It happens because mail using your domain in the From address failed DMARC, and your domain tells receivers to reject anything that fails. The fix is almost never just add an SPF record. It is alignment.

What 550 5.7.26 actually means#

Google's own SMTP error reference lists this code. The wording it publishes is: Unauthenticated email from domain-name is not accepted due to domain's DMARC policy. Google's advice is to contact the domain's administrator if the mail was legitimate, a clue that the problem lives in your setup.

Break the code apart. The 550 is a permanent (5xx) failure. The enhanced status 5.7.26 is a security and policy failure. Together they mean two things are true at once: the domain in your From header publishes a DMARC record, and this specific message failed the DMARC check.

DMARC only fails a message when it passes neither aligned SPF nor aligned DKIM, so this bounce is never about a missing DNS record alone. It is about the authenticated domain not matching your From line.

SPF pass is not SPF alignment#

The most common misread is this: your SPF record passes, so you assume authentication is fine. SPF authenticates the domain in the envelope sender, the Return-Path, also called MAIL FROM. It does not check the From header a person actually sees.

DMARC ignores a plain SPF pass. It requires alignment. RFC 9989, the current DMARC standard, defines two ways to align: SPF alignment, where the SPF-authenticated domain matches your From domain, and DKIM alignment, where the domain in the DKIM signature's d= tag matches your From domain.

Relaxed alignment, the default, matches on the organizational domain, so mail.yourco.com aligns with yourco.com. Strict alignment demands an exact match. DMARC passes if either mechanism aligns, which means 550 5.7.26 tells you both failed: your SPF-authenticated domain and your DKIM d= domain were both different from your From domain.

Common causes of 550 5.7.26#

Almost every case is one of four situations, each with its own way to confirm it from the headers and its own fix. Find your row, then jump to the matching fix below.

The two paths DMARC compares#

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

When a service like 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, not you, 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. Add your domain there.

3. 3

   Publish the DNS records they give you

   This is usually a set of 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 you added a custom-domain address under Settings, Accounts and import, Send mail as, Gmail may relay it through its own servers. The message then gets signed by gmail.com and its SPF resolves to gmail.com, so neither identifier aligns with your domain and DMARC fails.

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

   In the Send mail as settings, use your domain provider's SMTP server, such as Google Workspace with the domain added or your host's SMTP, rather than the default relay.

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. The steps for that are in Fix 3.

4. 4

   Retest

   A fresh Show original should now 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. DKIM signing is off until you set it up, and a missing include means SPF cannot authenticate your provider's servers.

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, Gmail, Authenticate email, generate the key, publish the TXT record, then turn on signing. Microsoft 365: enable DKIM in the Defender portal and publish the two CNAMEs.

3. 3

   Confirm your DMARC record

   You need a TXT record at _dmarc.yourco.com such as v=DMARC1; p=reject; rua=mailto:[email protected]. Keep p=none until you have confirmed alignment, then tighten it.

4. 4

   Test

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

How to tell which cause you have#

The fastest diagnosis is a single delivered message. 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.

A vendor's domain in both the DKIM d= and the Return-Path points to cause 1; gmail.com in both points to cause 2; a missing or failed DKIM with no provider include points to cause 3.

Preventing it#

The bounce is a policy catching an unaligned sender. Prevention is making sure every legitimate sender is aligned before your policy gets strict, and keeping watch afterwards.

• 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: start at p=none to monitor, read the aggregate reports, then move to p=quarantine, then p=reject once every legitimate source aligns.
• Keep reading aggregate reports after you reach reject. A tool added months later can start failing silently and trigger fresh bounces.

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

None of this is something a mail client can do for you. A 550 5.7.26 bounce is a sending-side authentication problem, fixed in your DNS and your sending services, not in the app you read mail in. We build AI Emaily, and it is a mail client, not a DMARC monitor, an ESP, or a deliverability tester, so it will not publish your records or repair alignment. The fixes above are your answer.

Where the same authentication signals matter to us is the receiving side. AI Emaily treats every inbound message as untrusted and weighs whether a sender is really who it claims to be before it trusts a link or a request. That is the mirror image of the check that just bounced your mail, and it is the job our spam and phishing protection does.