Adobe Campaign Classic Deliverability: Bounce Handling, Quarantine, and Sender Reputation

Adobe Campaign Classic deliverability problems rarely announce themselves. A campaign goes out, the delivered count looks a little lower than usual, and a few weeks later open rates at one mailbox provider have dropped and nobody knows why. Most of the time, the answer was in Campaign’s bounce and quarantine data the whole time.

Campaign Classic v7 does a lot of the protective work for you, but only if the configuration is sound and someone reads what it reports. Here I explain how the mechanism works, then walk through an investigation after a send that went badly.

How Adobe Campaign Classic knows a message failed

There are two ways a failure reaches Campaign.

Synchronous errors happen during the SMTP conversation. The receiving server refuses the message straight away, for example because the mailbox does not exist. The MTA records the response immediately against the message in the delivery logs.

Asynchronous errors arrive later as bounce emails. The receiving server accepted the message, then sent back a non-delivery report. These land in the platform’s bounce mailbox, and the inMail process reads them and matches them against rules to work out what went wrong.

Either way, Campaign assigns two things to the failed message: a type and a reason.

Hard, soft and ignored errors in Campaign Classic deliverability

The type decides what happens next. The delivery failures and quarantine page explains the qualification process.

• Hard errors are permanent. The address does not exist, or the domain is invalid. The address goes into quarantine straight away, because retrying will never work.
• Soft errors are temporary. The mailbox is full, the server is unreachable, or the receiving server refused the message for a reason that may pass. Campaign retries the message and counts the error.
• Ignored errors are temporary and harmless, such as an out-of-office reply. Campaign retries them, but they never lead to quarantine.

The reason is a finer label, such as User unknown, Invalid domain, Mailbox full, Account disabled, Refused or Unreachable. It is what you will group by when you investigate.

Retries and Adobe Campaign Classic deliverability

For soft and ignored errors, Campaign retries the message. On instances using the standard Campaign MTA, the settings are on the Delivery tab of the delivery properties. By default there are five retries spread over the first day, at least one hour apart, then one per day until the delivery’s validity period ends. You set the validity period on the Validity tab, in Delivery duration, and I keep sensible defaults for it in my delivery templates. The delivery sending steps page documents these defaults.

A shorter delivery duration is reasonable for time-sensitive messages. There is no point retrying a “sale ends tonight” email for five days.

If Adobe hosts your instance, check with them which of these settings apply to your setup, because some hosted configurations manage retries at the MTA level instead.

Quarantine in Adobe Campaign Classic deliverability

Quarantine is Campaign’s list of addresses it will no longer send to on a given channel. Campaign keeps it in its own table, separate from the recipient, and you can see it under Administration > Campaign Management > Non deliverables Management > Non deliverables and addresses.

An address in that table has a status:

• With errors means soft errors have been counted but the threshold has not been reached. Campaign still sends to it.
• Quarantine means Campaign excludes it from deliveries on that channel.
• On blacklist means it was blacklisted at the address level, for example after a spam complaint came back through a feedback loop.

Hard errors move an address to Quarantine immediately. Soft errors increase a counter. On instances using the standard MTA, you find the defaults in the deployment wizard under Email channel > Advanced parameters: five errors, with at least 86,400 seconds (one day) between two errors for the second to count. When the counter reaches five, Campaign quarantines the address. If the last counted error is more than 10 days old, the counter starts again.

Because the table is per address and per channel, a quarantined email address does not stop SMS to the same person.

I leave the soft error thresholds at their defaults on almost every instance. Lowering them quarantines addresses that would have recovered, and raising them keeps you sending to addresses that are hurting your reputation. When the quarantine numbers look wrong, the cause is usually the data being sent to, not the threshold.

Quarantine is not the blacklist

People confuse these two all the time, and the difference matters for compliance.

Quarantine is about technical deliverability. The address is not working, so Campaign stops trying.

The blacklist is about consent. On the recipient profile, the fields No longer contact by email (@blackListEmail) and No longer contact (by any channel) (@blackList) record that a person does not want to hear from you. Unsubscribe links in emails set these flags. Campaign excludes blacklisted recipients during delivery analysis, the same way it excludes quarantined addresses.

So an address can be perfectly deliverable and blacklisted, or wanted and quarantined. Never clear a blacklist flag to fix a deliverability problem, and never treat a quarantine as an opt-out.

How addresses leave quarantine

Quarantine is not forever. The Database cleanup technical workflow releases some addresses automatically. According to Adobe’s documentation, it clears addresses in With errors status after a successful delivery, addresses in With errors status whose last soft bounce is more than 10 days old, and Mailbox full errors after 30 days. The database cleanup workflow page has the details.

Make sure that workflow is running every day. If it is stopped, quarantine data goes stale, and either you keep excluding addresses that would now work, or the counters stop resetting.

You can also release an address by hand from the quarantine list. Do this only when you have a real reason, for example a customer who has fixed their mailbox and asked to be mailed again.

Qualification rules and Campaign Classic deliverability

Campaign’s bounce rules are under Administration > Campaign Management > Non deliverables Management:

• Delivery log qualification lists the error messages Campaign has seen, with the type and reason assigned to each. New messages that match no rule appear with the status To qualify.
• Mail rule sets hold the inbound email rules used to classify bounce mails, and the domain and MX management rules.

The Refresh for deliverability technical workflow updates the rules from Adobe. That update can overwrite rules you create yourself, so if you change qualification, document why and check after each refresh.

I only touch qualification when I can see a specific message being misclassified, for example a provider’s temporary throttling response being treated as a hard error. Changing rules on a hunch causes more problems than it solves.

The worked example: a reactivation send that bounced

Here is the scenario. It is hypothetical, but it happens on most programmes eventually.

A retailer has a large group of recipients who have not been mailed for over two years. Marketing decides to send them a “we miss you” offer. The delivery goes out, and the next morning the delivery dashboard shows a much higher error rate than the usual weekly newsletter. A week later, the deliverability team reports that inbox placement at one large provider has dropped for all campaigns, not just this one.

Here is how I would investigate.

Step 1: read the delivery’s own numbers

Open the delivery and look at the summary on the Delivery tab, then the Delivery logs tab. Filter the logs to failed messages and add the failure type and failure reason columns. You want to know the split between hard and soft, and which reasons dominate.

Then run the Failures and bounces report on the delivery. It breaks down failures by cause and by domain, which tells you whether the problem is spread across all providers or concentrated on one.

Step 2: group the failures in a query

For numbers you can paste into a report or compare between deliveries, query the recipient delivery logs directly. Here is the queryDef I use, grouped by type and reason. Swap in your delivery’s internal name.

var res = xtk.queryDef.create(
  <queryDef schema="nms:broadLogRcp" operation="select">
    <select>
      <node expr="@failureType"/>
      <node expr="@failureReason"/>
      <node expr="count(@id)" alias="@total"/>
    </select>
    <where>
      <condition expr="[delivery/@internalName] = 'DM2041'"/>
    </where>
    <groupBy>
      <node expr="@failureType"/>
      <node expr="@failureReason"/>
    </groupBy>
  </queryDef>
).ExecuteQuery();

for each (var row in res.broadLogRcp)
  logInfo("type " + row.@failureType + ", reason " + row.@failureReason + ": " + row.@total);

Messages without a failure show up as their own group, which gives you the denominator.

In this scenario, the result is what you would expect from old data: the bulk of failures are hard, with User unknown at the top. Addresses that worked two years ago have been closed since.

Step 3: understand the damage to Adobe Campaign Classic deliverability

High hard bounce rates tell mailbox providers that a sender does not maintain their list. That affects the sending IPs and domain for every campaign, not just the one that caused it. That is why the regular newsletter suffered too.

Campaign has already done its part: every hard bounce is now in quarantine, so the next send will not repeat the damage. The rest is up to you.

Step 4: fix the process, not just the data

• Stop mailing old data in one block. Reactivation should go in small batches, starting with the most recently active, so a bad segment shows up early and small.
• Check recency before targeting. Add a condition on the last successful delivery or last open, so dormant addresses are deliberately chosen rather than included by accident. A filtering rule in a typology can enforce this on every send, which protects Adobe Campaign Classic deliverability far better than a one-off fix.
• Look at spam complaints. If complaints came back through a feedback loop, those addresses are on the blacklist. Check that number too.
• Confirm authentication. SPF, DKIM and DMARC alignment do not stop bounces, but weak authentication makes reputation recovery slower.

If I could only make one of those changes, it would be the first. Every other fix limits the damage after a bad send. Batching stops a bad segment before it reaches the whole list.

The deliverability overview covers the reputation side in more depth.

Common Campaign Classic deliverability mistakes with quarantine

• Filtering quarantine in the query. The delivery analysis already excludes quarantined addresses and logs them as exclusions. Filtering them out earlier hides that information.
• Mass releasing quarantine because a segment looks too small. Campaign quarantined those addresses for a reason.
• Using quarantine as unsubscribe. It is not consent data, and Campaign clears it automatically.
• Leaving To qualify messages unreviewed. Unqualified bounces do not improve the rules.
• Stopping the Database cleanup workflow during maintenance and forgetting to restart it.

FAQ

Why was an address quarantined after only one failure?

Because it was a hard error, such as User unknown or Invalid domain. Hard errors quarantine immediately. Only soft errors go through the counter and threshold.

Does quarantine apply across all deliveries?

Yes. Campaign stores quarantine per address and per channel, not per delivery, so every future email delivery excludes that address until it is released.

Can I see why a specific person did not receive an email?

Open the recipient profile and look at the delivery logs on the Deliveries tab, then check the address in the non-deliverables list. The delivery log shows the failure or exclusion reason for that message.

Should I remove quarantined recipients from the database?

Not automatically. The profile may still be useful for other channels or for reporting. If your data retention policy says inactive profiles should go, handle that as a separate, documented purge.

Seed addresses and proofs are the other half of a safe send, because they catch content and rendering issues before a real audience sees them. My seed addresses and proofs guide covers how I set them up.

Last updated on 26 October 2026