What does my bounce message mean?

A bounce that names SPF, DKIM, DMARC or an "authentication level" means the receiving server checked whether the mail really came from the domain it claims, and the mail did not pass. Find the code from your bounce below. Each one says what the server checked, who has to fix it, and which record to change. The fix is on the sending side.

Find your code

The texts are quoted from Microsoft's list of Exchange Online bounce codes, Microsoft's page on 5.7.515 and Google's list of Gmail SMTP errors. A real bounce adds your domain, the sending address and the server's own details.

550 5.7.515 (Outlook.com)

Outlook.com, Hotmail, Live.com and MSN refuse mail from a high-volume domain unless SPF and DKIM both pass and DMARC passes for the From domain. Microsoft's help page draws the line at 5,000 or more messages and names no time period. Its announcement says "over 5,000 emails per day". A DMARC record with p=none is enough. The owner of the domain fixes it with whoever sends the mail. A message can pass DMARC through DKIM alone and still bounce here, because SPF has to pass too. Read the 550 5.7.515 page.

550 5.7.509 (Microsoft)

The domain in the From address has a DMARC policy of p=reject, the message failed DMARC, and Microsoft refused it as the domain asked. If the domain is yours, a service that sends as you is not set up for it. If it is not yours, the mail went out through a server that cannot pass DMARC for that domain. Read the 550 5.7.509 page.

550 5.7.26 (Gmail)

Gmail asks every sender, whatever the volume, to pass SPF or DKIM. This message passed neither, or it came from a server missing from an SPF record that ends in -all. Add the server or service to your SPF record and turn on DKIM where the mail is sent from. Read the 550 5.7.26 page.

Not accepted due to the domain's DMARC policy (Gmail)

Gmail followed the DMARC policy of the domain in the From address and refused mail that failed it. Google's own advice to the sender is to use the outgoing server that belongs to the address you send from. Read the page on this bounce.

421 4.7.32 and 5.7.32 (Gmail)

SPF or DKIM passed, but for the sending service's domain, not for the domain in the From address. Gmail asks large senders for that alignment. Turn on custom DKIM in the service. Read the 421 4.7.32 page.

4.7.27 and 5.7.27 (Gmail)

Gmail asks large senders to pass SPF, and this message did not. The sending server is missing from the SPF record of the envelope domain, or that record is broken. Read the 550 5.7.27 page.

4.7.30 and 5.7.30 (Gmail)

Gmail asks large senders to sign with DKIM, and this message had no signature that passed. Turn on DKIM where the mail is sent from and publish the key it gives you. Read the 550 5.7.30 page.

4.7.40 and 5.7.40 (Gmail)

Google's texts:

421 4.7.40 Your email has been rate limited because the sending domain doesn't have a DMARC record, or the DMARC record doesn't specify a DMARC policy. Gmail requires all bulk email senders to add a DMARC record to their sending domain.
550 5.7.40 Your message was blocked because the sending domain doesn't have a DMARC record or the DMARC record doesn't specify a DMARC policy. Gmail requires all bulk email senders to add a DMARC record to their sending domain.

Gmail looked for a DMARC record at _dmarc under the domain in the From address and found none, or found one without a p tag. Gmail's sender guidelines ask this of senders who send more than 5,000 messages per day to Gmail accounts, and add: "Your DMARC enforcement policy can be set to none." The owner of the domain fixes it by publishing one record:

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

You get no DMARC reports at all until this record exists, because the rua address in it is where mailbox providers send them. Publish your DMARC record has the steps.

4.7.28 and 5.7.28 (Gmail)

This one is not about authentication. Gmail saw an unusual rate of unwanted mail from the sending address, its network, its DKIM or SPF domain or its links, or too many messages with one Message-ID. Whoever runs the sending server looks into it, and Google's Postmaster Tools shows your spam rate. Read the 550 5.7.28 page.

4.7.29 and 5.7.29 (Gmail)

This one is not about authentication either. The server that sent the message did not encrypt its connection to Gmail with TLS. The bounce speaks of bulk senders, but Google's sender guidelines ask TLS of every sender. Whoever runs that server turns it on. Read the 550 5.7.29 page.

Who has to fix it

Look at the domain the bounce names. For 5.7.515, 5.7.509 and the DMARC policy text, it is the domain in the From address. For the SPF texts, it is the envelope sender's domain, the bounce domain.

• The domain is yours. You fix it, together with whatever sent the mail: your email provider, a sending service such as a newsletter or invoicing platform, or a server of your own. The change is in that service's settings and in your DNS records.
• The domain is not yours. You sent with someone else's address in the From field through a server that may not send for it. A website form that puts the visitor's address in From does this, and so does a mail program that sends someone else's address through your company's server. If that domain's DMARC policy asks for reject, the mail bounces. Send from your own domain, or through the server that belongs to that address.
• You never sent the message. Someone else sent mail with your domain as the return address, and the bounce came back to you. Your records did their job, and there is nothing to fix.

The person you wrote to usually cannot fix these, because the checks are about the sending domain. The exception is 5.7.509 at a company on Microsoft 365: its administrator can let one sender's failing mail through, and Microsoft's DMARC guide says "Be careful when overriding p=reject for legitimate senders." That helps at that one company only.

A code that starts with 4 is temporary. RFC 3463 says of it: "If this code accompanies a delivery failure report, sending in the future may be successful." The cause stays until someone fixes it. A code that starts with 5 is permanent: "Some change to the message or the destination must be made for successful delivery."

What it looks like in a DMARC report

Every aggregate report has a row for each sending address and each set of results its mail got. Two parts of a row tell you what the bounce was about:

<row>
  <source_ip>192.0.2.10</source_ip>
  <count>40</count>
  <policy_evaluated>
    <disposition>none</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>

• policy_evaluated holds the DMARC result for your domain. Its dkim and spf are "The result of the DKIM DMARC Identifier Alignment test" and the same for SPF, and disposition is "The result of applying the DMARC policy" (RFC 9990, section 3.1.1.9).
• auth_results holds the plain SPF and DKIM results, with the domain each one checked.

In this row, SPF and DKIM pass, but for the service's domains, so DMARC fails. Microsoft's DMARC guide calls pass with alignment fail the "classic alignment problem". The disposition follows your own DMARC policy, so with p=none it can say none for mail that Gmail or Outlook.com refused under their own sender rules. Read the checks, not the disposition.

Mailmoni reads these reports for you: the Sources page shows each source's SPF and DKIM result for your domain, and its explanation says what to change.