Undelivered or bounced emails

Many PagerDuty Workflow Automation email actions, like Email: Send an Email or Email: Wait for reply have an email bounce feature which monitors and responds to an undeliverable email.

When an email is sent, it can be delivered, get caught in spam, or be rejected by a email server and be undeliverable. If an email is undeliverable, the email has bounced. PagerDuty Workflow Automation email actions have built-in features to help manage dealing with undelivered email.

At this time, email sent to spam is not possible to track. To reduce the chance email is considered spam, the best options are techniques like whitelisting or proofreading.

note

• Note: This article focuses on email bounces, for other reasons why emails may be undeliverable, see Ensure your emails are delivered.

Examples of use

This email bounce capability makes for easy automation of undeliverable mail. You can leverage the email bounce feature and the email bounce output fields in some of the following ways:

• After a large email campaign is sent, use actions to collect each Bounced email address in a data table for review.
• Automate resending emails with conditions based on the different errors from the Bounce message.
• Assign a PagerDuty Workflow Automation group a manual task to personally reach out to each recipient where an email bounced.

How the email bounce feature works

PagerDuty Workflow Automation email actions will return specific email bounce fields when an email bounces. The fields are added when the bounce occurs. Bounce output fields can be added to the action even after the task has completed, but not after the instance has completed.

The output fields can be used with conditions and dependencies to set up the logic to automate a bounced email.

If an email bounces, the email action will output these extra fields:

• Email bounced: A TRUE or FALSE response for whether an email bounced.
• Bounced email address: The email addresses where the email bounced.
• Bounce message: This will capture the message returned by the addresses where the email bounced.
• Bounce type: The bounce type for the bounced email, such as soft or hard.

Why an email may bounce or be undeliverable

An email will bounce if:

1. The recipient’s email server rejects the email
2. The email is sent to the wrong address
3. The Workflow stops the email because it believes it was sent on accident

Each bounced email typically has a bounce message and bounce type. The bounce message is a reason that explains why the email was not delivered. There are two bounce types, hard and soft:

• Permanent issues, like if an email address does not exist, the domain does not exist, or the recipient’s email server has stopped email delivery, are hard bounces

• Temporary issues, like a full mailbox, too many attachments or too large of an email, or too many emails sent to a single email address or email provider in a short time, are soft bounces

The bounce type output field is another field that’s good to base conditions on.

How to use email bounce output fields in tasks

If a process is only sending a few emails, set up basic conditions and dependencies based on the bounce message, bounced email address, or bounce type. For example, send an email, then set the next task to:

• start if there are no bounced emails
• or if there is a bounce, to relay the bounced email addresses to the instance owner for them to update the addresses and try to send again.
• then repeat this loop until all emails are delivered.

To handle large volumes of bounced emails, use actions like Tables: Add a Row to store each bounced email address, bounce message, and other fields in a data table. Then use actions like Tables: Start Workflow for Each Row to trigger a new Workflow to resolve each bounced email address from each row of the data table.

With conditions and dependencies, there are many ways to resolve bounced email addresses. The best place to start is by collecting all bounced email addresses into one place, then setting up other actions or Workflows to deal with each one.

Best practices to prevent undelivered email

Set a minimum 1 hour delay after an email task

If you’re not sure if an email will bounce, the next task after an email task should be set to start with a 1 hour delay since many email servers take up to an hour to report if a message was undeliverable. Set the delay to 1 hour so any dependencies and conditions can resolve before the instance ends.

If the email is sent internally and an undeliverable email is unlikely, this 1 hour delay is not needed.

Validate email addresses before an email is sent

The Contacts: Validate an Email Address action checks if an email is formatted correctly, free of spelling mistakes, and verified by a mail server. This action outputs an is valid field that will verify if a hard bounce may occur.

Use the validate an email action before sending an email to reduce the chance the email will bounce.

Ask the recipient’s company to whitelist PagerDuty Workflow Automation domains

If the recipient is a trusted customer, vendor, or partner, ask them to whitelist the PagerDuty Workflow Automation @catalytic.comand @pushbot.com domain to reduce email bounces. This will not work for unfamiliar email addresses, but if you send many emails to the same domains, this is a simple fix to ask for.