• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Red Sift Blog

Red Sift Blog
  • redsift.com
  • Featured
  • Who are we?
  • Get in touch
You are here: Home / Email / Deliverability / What is an email bounce and how does it affect deliverability?

What is an email bounce and how does it affect deliverability?

by Joshua Harris
September 22, 2020August 30, 2022Filed under:
  • Deliverability

Here is a situation we have all experienced, the outreach emails have gone out and “Wow! A reply already?!” but upon checking, the response is an automated message informing you that your email was not delivered, or in common English, it has bounced. But, what is a bounce? Why do they occur? And how do they relate to email authentication?

What is an email bounce?

A bounce occurs when the receiving server is unable to deliver the email. There are many reasons which can be easily classified into hard and soft. 

  • Hard – This indicates that the email has not and will not reach any inbox. There are numerous reasons for a hard bounce, including “Invalid sending address”, the sender being blacklisted, DNS errors, and many more.
  • Soft – The email cannot be delivered currently but may be delivered later. Soft bounces are caused by remediable errors such as the mailbox being full or the server being temporarily unavailable.

What happens when an email bounces?

When a bounce occurs, there is an automatic response generated which is then sent to the address listed in the return-path of your email.

The return-path is an address tucked away in the headers of the email, beyond the eyes of the typical user. This address can be the same or a different one from the “From:” address, which is the one immediately visible to the end user.

The return-path address is typically the address of the sender – this is why when an email bounces, you receive a notification to your personal inbox.

In a soft bounce case, the servers will keep trying to send the email. For hard bounces, the email is rejected and the servers will not try to send it again.

Below is an example of a hard bounce email failure. The error codes will depend on which mail transfer agent sent the bounce back but the full list of errors and reasons can be found in RFC5248.

hard bounce fail email

How does this affect authentication?

To the end user, this all seems relatively straightforward – an email gets sent and if there’s a problem you will be notified. For admins though, management of email bounces ties into authentication and deliverability. It’s important to ensure that bounce rates remain low (ideally under 2% according to independent research by Campaign Monitor). It is also important that your email authentication is robust and enforced by DMARC so that the domain is protected against spoofing.

Authentication of an email’s IP address is done using the SPF protocol, this checks that the sender IP is listed in a record at the domain referred to in the return-path.

Deliverability is also a key factor to consider here. Mail servers may classify a sender as spam if that sender sends too many emails that get bounced, as it shows poor management of the sending list. As a result, many sending services will modify the return-path to point to the sending service’s address, helping them to capture the bounces which subsequently are presented to the user to help them better manage the sending list. 

A side effect is that the SPF check is performed on the domain of the sending service, which breaks the SPF alignment component of the DMARC protocol (e.g sending service = “example.com” and return-path = “company.com”) and makes DMARC authentication based on SPF not possible. 

DMARC not only checks for alignment in the SPF protocol between the return-path and the “From:” address, but also checks for alignment in the DKIM protocol between the domain in the “d=” parameter and the domain in the “From:” address.

If the return-path points to the sending service’s domain rather than the “From:” address, then the DMARC check will rely entirely on the DKIM protocol to pass authentication.

Deliverability and authentication, separately, have protocols and mechanisms in place to handle these processes but the handling can clash when DMARC gets involved due to alignment.

The solution to this is to ensure that any sending services you use support DKIM and also that supports authentication of your custom domain, this concept is called whitelabelling. Without this, you won’t be able to provide authentication for those emails and also you won’t be able to reach protection mode in your DMARC policy for the domain on behalf of which this service sends emails.

To explore the setup of your email authentication, send a test email to our free ‘Investigate’ tool below.

Share this:

  • Click to share on Twitter (Opens in new window)
  • Click to share on LinkedIn (Opens in new window)

Related

Tagged:
  • DKIM
  • DMARC
  • Email Authentication
  • Email Deliverability
  • SPF

Post navigation

Previous Post DMARC is for life, not just a project
Next Post Boosting your online security using DANE

Primary Sidebar

Subscribe to our blog and be the first to get updates!

Categories

  • AI
  • BEC
  • BIMI
  • Brand Protection
  • Coronavirus
  • Cybersecurity
  • Deliverability
  • DMARC
  • DORA
  • Email
  • Finance
  • Labs
  • News
  • OnINBOX
  • Partner Program
  • Red Sift Tools
  • Work at Red Sift
  • March 2023
  • February 2023
  • January 2023
  • December 2022
  • November 2022
  • October 2022
  • September 2022
  • August 2022
  • July 2022
  • June 2022
  • May 2022
  • April 2022
  • March 2022
  • February 2022
  • January 2022
  • December 2021
  • November 2021
  • October 2021
  • September 2021
  • August 2021
  • July 2021
  • June 2021
  • May 2021
  • April 2021
  • March 2021
  • February 2021
  • January 2021
  • December 2020
  • November 2020
  • October 2020
  • September 2020
  • July 2020
  • June 2020
  • May 2020
  • April 2020
  • March 2020
  • February 2020
  • January 2020
  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • October 2018
  • September 2018
  • August 2018
  • July 2018
  • June 2018
  • May 2018
  • April 2018
  • March 2018
  • February 2018
  • January 2018
  • December 2017
  • November 2017
  • October 2017
  • September 2017
  • July 2017
  • June 2017
  • May 2017
  • April 2017
  • March 2017
  • October 2016

Copyright © 2023 · Red Sift