Start free
Menu

Why does Gmail reject my email due to the domain's DMARC policy (550 5.7.26)?

Gmail refused the message because it failed DMARC, and the domain in its From address has a DMARC policy that asks for failing mail to be refused. Gmail followed the domain owner's own request. If the domain is yours, a service or server that sends as you is not set up for it. If it is not yours, you sent through a server that may not send for that domain.

The bounce

Google's list of Gmail SMTP errors gives this text under 550 5.7.26:

Unauthenticated email from domain-name is not accepted due to domain's DMARC policy. Contact the administrator of domain-name domain if this was legitimate email. To learn about the DMARC initiative, go to Control unauthenticated email from your domain.

In your bounce, domain-name is the domain in the From address. Under 451 4.7.26 the same list has a temporary form that adds "but temporary DNS failures prevent authentication". There Gmail could not finish the checks because a DNS lookup failed. The sending server tries again later. If the bounce keeps coming, ask your DNS host whether your domain's name servers answer.

What Gmail checked

First, DMARC. A message passes when SPF or DKIM passes for the domain in its From address. Google's Set up DMARC page says: "To pass DMARC, a message must pass at least one of these checks: SPF authentication and SPF alignment, DKIM authentication and DKIM alignment." A check that passed for a sending service's own domain is not aligned and does not count.

Then the domain's policy. Google's page on this bounce explains: "Domain owners can publish a policy telling Gmail and other participating email providers how to handle messages that are sent from your domain but aren't authenticated." This domain's policy asked Gmail to refuse the message, and Gmail did. Gmail's own sender rules do not come into it. 550 5.7.26 is the bounce for those.

Who has to fix it

Google's page gives the person who got the bounce two cases. For mail sent from Gmail itself: "If you sent the email using Gmail, learn how to fix bounced or rejected emails." For mail sent from any other mail program: "If you sent the email using a different email application, try looking for a setting in your email application that controls the server used to send messages (the “outgoing” server). Change this setting so that you're using the server that matches the email address you want to send from." It adds: "If that doesn't work or you need more help, contact the email provider for your email address."

  • The domain is not yours. You sent from an address at someone else's domain, such as a personal address at another mail provider or an address at another company, through your own company's or internet provider's server. That server cannot pass DMARC for the other domain. Send through the server that belongs to the address, or send from your own domain.
  • The domain is yours. Your DMARC record asks for reject, and a service or server that sends as you fails DMARC. Set it up for your domain: custom DKIM, or its include in your SPF record together with a bounce address of yours. A website form that puts the visitor's address in From fails for the visitor's domain, so send it from your own domain with the visitor in Reply-To.
  • You never sent the message. Someone else sent mail in your domain's name, and the bounce came back to you. Your policy did its job, and there is nothing to fix.

The records

This is the kind of record behind the bounce, for example.com:

_dmarc.example.com  TXT  v=DMARC1; p=reject; rua=mailto:k3x9p2m7q4w8@rep.mailmoni.com

Keep it, and fix the sending service. The fix is usually the DKIM key the service gives you:

s1._domainkey.example.com  CNAME  s1.dkim.newsletter.example

Set up DKIM for a sending service has the steps. If you cannot fix the service quickly, you can step the policy back. p=quarantine sends its failing mail to spam folders instead of refusing it, and p=none delivers it. Both do the same for mail forged in your name. Before you move a step closer to p=reject again, readiness checks that every source sending a real share of your mail passes DMARC.

What it looks like in your DMARC reports

In the aggregate reports for your domain, the refused mail shows up as a row like this:

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>40</count>
  <policy_evaluated>
    <disposition>reject</disposition>
    <dkim>fail</dkim>
    <spf>fail</spf>
  </policy_evaluated>
</row>
<identifiers>
  <header_from>example.com</header_from>
</identifiers>
<auth_results>
  <dkim>
    <domain>newsletter.example</domain>
    <selector>s1</selector>
    <result>pass</result>
  </dkim>
  <spf>
    <domain>bounces.newsletter.example</domain>
    <result>pass</result>
  </spf>
</auth_results>

RFC 9990 defines the reject disposition as "Failed DMARC, marked as reject". The two checks under policy_evaluated fail for your domain, while auth_results shows them passing for the service's own domains. A source that sends no authentication at all shows fail under auth_results too.

In Mailmoni, the Sources page shows each source's SPF and DKIM result for your domain, and when we recognise the service, its explanation names the setting to turn on.

Sources

Checked on 27 October 2026.

Published 27 October 2026 · Checked 27 October 2026

See it for your own domain

Start free How it works