Seed Addresses and Proof Sending in Adobe Campaign Classic: Testing Before You Send

Teams often treat proofs and Adobe Campaign seed addresses as the same thing. They are not. A proof is a test send before the real one. A seed address is a test recipient inside the real send. Using both, for the right reasons, is what turns “I think it looks fine” into “we checked”.

Here I write about how each works in Campaign Classic v7, how I set them up, what to watch with custom recipient tables, and the routine I would use for a hypothetical weekly newsletter.

Proofs and Adobe Campaign seed addresses: the difference

A proof is a separate send to a proof target before the main delivery. It goes through analysis and personalisation, and the recipients see the email as a customer would. Proofs are numbered, and each round of changes should produce a new one. Their job is to answer “is this email right?”.

A seed address is a test address added to the target of the delivery itself. When the real send goes out, the seeds receive their copy at the same time as customers. Their job is to answer “what actually went out, and when?”. Seeds are your evidence that the production send matched the approved proof, and they catch problems that only appear at send time, such as content changed after the last proof.

Seed addresses can also serve as the proof target. That is usually how I set things up: one seed list per brand, used for proofs and included in real sends.

The distinction also changes who looks at what. Reviewers look at proofs, because that is where content decisions are made. Operations people look at seeds, because that is where they confirm the send behaved. When both groups use the same list, each sees the other’s evidence, which shortens the conversation when something goes wrong.

Setting up Adobe Campaign seed addresses

Seed addresses are stored in their own table, nms:seedMember, with their own folder in the explorer. Each seed address holds an email address and the profile fields you want to test with, such as first name, so personalisation renders as it would for a customer.

My rules for a good seed list:

• Represent the audience. Include profiles with and without a first name, with different languages or segments if the content varies, and with the fields that drive conditional blocks.
• Cover the main mailbox providers. Accounts on the providers your customers use most, so you see real rendering and spam folder placement.
• Include the people who approve. Brand manager, legal reviewer where required.
• Keep it small. The standard Proof size check control rule generates an error if the proof target exceeds 100 recipients, as listed in the control rules documentation. A proof list near that size is a distribution list, not a test.

Campaign seed addresses with a custom recipient table

If you target a custom table rather than nms:recipient, seeds need extra configuration. The seed addresses configuration page explains that nms:seedMember must be extended with an element named after the custom schema, containing fields that match the custom table’s fields:

<srcSchema extendedSchema="nms:seedMember" label="Seed addresses"
           labelSingular="Seed address" name="seedMember" namespace="cus">
  <element name="common">
    <element name="custom_cus_person">
      <attribute name="lastname"  template="cus:person:person/@lastname"/>
      <attribute name="firstname" template="cus:person:person/@firstname"/>
      <attribute name="email" sqlname="myEmailField" xml="false"
                 template="cus:person:person/address/@addrEnv"/>
    </element>
  </element>
  <element name="seedMember">
    <element aggregate="cus:seedMember:common"/>
  </element>
</srcSchema>

Two details matter. The email field must be named email with an SQL name other than sEmail, which the recipient schema already uses. And the database structure must be updated after the extension. I add this to the checklist for any project that introduces a custom recipient table, because it is often discovered only when the first proof fails. My post on custom schemas covers extension in general.

Making new seed fields visible

Extending the seed schema is only half the job. After the schema change and the database structure update, the new fields exist in the table but not on the seed address screen. Adobe’s seed selection use case finishes by updating the seed addresses Input form, so operators can see and edit the new field.

I treat the schema, the structure update and the form as one change, and I package them together so they move between environments as a unit. A field that exists in production but not on the form leads to seeds with stale values, because nobody can see them to fix them. After deploying, I disconnect and reconnect the console, open one seed and check that the field is there and editable.

Filling personalisation for seeds: substitution

Seed addresses rarely have every field a delivery uses. If the email shows the recipient’s favourite category and the seed has none, the preview shows a blank.

Campaign handles this with random field substitution. The field substitution use case explains that empty seed fields used in the delivery are filled at delivery time with values taken from recipients in the target. The seed schema needs the field, but you don’t have to type a value into each seed.

Two notes from experience. Substitution happens at delivery time, so the preview still shows blanks. And because values are random, a seed may get a combination no real recipient has. For content that varies a lot by segment, I prefer seeds with explicit values for each segment, so I know which version each seed shows.

Choosing seeds by criteria

For a large brand with many stakeholders, adding seeds one by one to each delivery is tedious and error-prone. The Edit the dynamic condition link in the seed selection lets you choose seeds by a criterion instead.

Adobe’s seed selection use case extends the seed schema with a department field, then selects seeds where the department is “Purchasing”. The same approach works for “brand”, “market” or “language”. Once each seed carries the right value, the delivery template selects them by condition and new deliveries get the right seeds automatically.

Campaign seed addresses in transactional messages

Message Center templates use seeds differently. In a transactional message template, the Seed addresses tab holds test event data in XML, so previews and proofs have realistic content without a real event. The transactional template testing page describes it. The XML must have the same structure as the real event, or personalisation will not resolve.

Worked example: a testing routine for a weekly newsletter

The hypothetical brief: a home goods retailer sends a weekly newsletter in two languages, with a product block that changes by preferred category. Last quarter, a send went out with a broken image because the final content change was made after the last proof. They want a routine that prevents it.

My setup:

Seed list. Eight seeds with a “brand” field set to the retailer:

• Two in each language, one with a first name and one without.
• Seeds with explicit category values for the three main categories.
• Inbox test accounts on the two mailbox providers most of their customers use.
• The brand manager.

Template. The newsletter template selects seeds with the dynamic condition brand = retailer and uses the same seeds as the proof target.

Routine for each send:

1. Preview in the console against a seed in each language.
2. Send proof 1 to the seed list. The brand manager approves or requests changes.
3. Every change, including “just one word”, produces a new proof. The approval names the proof number.
4. Analyse the real send and check that seeds are in the target count.
5. After sending, someone checks one seed in each language in the inbox within the first hour and compares it to the approved proof.

The fifth step is what catches the broken-image case. If the production email differs from the approved proof, the seeds show it, and the team can stop the delivery while most of it is still queued.

What proofs and seeds cannot tell you

Proofs and seed addresses are good at catching content and personalisation errors. They are weaker at telling you how the main send will perform, and it helps to be honest with stakeholders about that.

A proof is a small send. Mailbox providers judge reputation on volume and engagement over time, so a proof landing in the inbox does not mean the main send will. Seeds in the real send are a better signal, but still a handful of addresses, and their placement depends on how those accounts have been used.

Seeds also do not prove the target is right. A seed list that receives a perfect email tells you nothing about whether the query selected the right customers. That check belongs to the analysis count and the target definition, which I describe in my email delivery walkthrough.

Finally, proofs reflect the data at the time of the proof. If recipient data changes between the proof and the send, personalisation for real customers can differ from what reviewers saw. For sends that depend on fresh data, I re-analyse close to the send time and check a seed in the inbox afterwards.

Who owns the seed list

Seed lists drift. People leave, test accounts expire and new markets appear. I make one person responsible for each brand’s seeds and review them every quarter: remove leavers, check that test accounts still receive mail, and confirm each segment that the content varies by still has a seed. Without an owner, proofs end up going to people who no longer work on the brand, and the one person who should have seen the email did not.

Testing mistakes I see most often

• Proofs only to the person building the email. They are the least likely to notice their own mistake.
• Seeds with every field filled. You never see the fallback content.
• No seeds in the real send. Then nobody can confirm what went out.
• Changes after the last proof. Every change needs a proof.
• Custom recipient table, unextended seed schema.

Frequently asked questions

Do Adobe Campaign seed addresses affect the delivery’s statistics?

Seeds are a handful of addresses in the target, so their effect on rates is small. I still keep the list small so reports are not distorted, and I avoid clicking every link in seed copies.

Can Campaign seed addresses be used in workflow deliveries?

Yes. Seeds set on the delivery template apply to deliveries created by workflow Delivery activities from that template.

Should proofs go to external agencies?

If they approve content, yes. Add them as seeds with the right brand value so they get proofs through the same list as everyone else.

Why does my seed show a blank field in preview?

Substitution happens at delivery time, so the preview still shows the empty seed field. Send a proof, or give the seed an explicit value.

Proofs tell you the email is right and seeds tell you the send was right, so I set up both on every brand from the start. My post on delivery templates shows how to make the seed selection automatic.

Last updated on 26 October 2026