This story goes back a few years. At the time, I had a particularly demanding client in front of me... not to say... picky. Suspicion weighs heavily on the results of an email campaign, which forces me to generate report after report.
As the advertiser in question has the possibility to check all the interactions himself, he brings up a problem which, according to him, proves that our reports are wrong: There is a bounce which generated a click!
Doubtfulness sets in
Yes, there, indeed, the pressure was already great, but the doubt settles. I check in the database, and the address in question has indeed generated an error (and a permanent one, not a soft one). I push the investigations a little further and indeed bounces regularly click on the campaigns (it remains an extremely small volume anyway).
Not so strange
These active bounces have one characteristic in common. They are always the addresses that were sent first during a campaign.
Need help?
Reading content isn't everything. The best way is to talk to us.
What does this mean? Simply that some destinations (ISPs, Webmails, ...) pass the very first messages of a given campaign through their spam filters... whether they are active addresses or not. And as you may know, nowadays, spam filters don't just analyze the content of your emails. These filters click and check the different redirects that take place behind your links and open the final landing page.
This link analysis allows for example to check if some URLs are not referenced in dedicated blacklists (URIBL, SURBL, ...), to check the number of redirects (too many redirects makes you look like a spammer) and to analyze the consistency of your sender identity (a topic that Badsender will have to come back to in the next few weeks).
Putting the undead back in their coffin
As a result, another side effect (even if its volume will be very limited), check that your asset management/assets don't put your bounce back on the scene, for example by increasing the marketing pressure towards it. A permanent error must generate a permanent deactivation of the address... in any case!
7 réponses
Hello Jonathan,
A small mistake has crept in: "The doubt is installed" in the 1st subtitle ;),
Have a nice day!
You also have the case of all those emails buried alive, because their server is misconfigured and sends back bad codes that make the platform, professional, classify them as NPAI Hard and bury them... while the customer exchanges every day with them by email. gloups!
Lucie > Thanks, it's corrected!
What frequently happens to us is that a recipient redirects to several addresses and one of these addresses is no longer valid. As a result, the initial recipient becomes a hard bounce (non-existent address) ... and generates opens and clicks... Not easy to explain to customers 🙂
Have a nice day
Alain > That's why I love emailing 😉 We can never rest on our laurels!
Alain > strange, if the initial address is not in bounce, why the bounce goes up to you? It's the first address (the one that redispatches) that it should go back to, right?
On the other hand, the tricky part is when there are aliases like at Wanadoo/Orange. The customer unsubscribes his orange email but the wanadoo one still works and is rerouted to his orange email. He may have unsubscribed 15 times on his orange address, he still remains an effective subscription on his wanadoo address 🙂 So he continues to receive emails, grumbles and ends up declaring you as spam when technically it is unjustified 😉
In this case, it is with the tracking ids that we can trace back to the initial address and finally unsubscribe it 🙂
Charles> It's in my bounces treatment, I intercept smtp dialogs between servers and so I have this kind of message:
Mar 7 10:10:05 cerapoda postfix/cleanup[10298]: 8C33F2542A2: message-id=
Mar 7 10:10:05 cerapoda postfix/qmgr[14891]: 8C33F2542A2: from=, size=93554, nrcpt=1 (active queue)
Mar 7 10:10:07 cerapoda postfix/smtp[10307]: 8C33F2542A2: to=, relay=smtp-in.orange.fr[80.12.242.9]:25, conn_use=27, delay=1.7, delays=0.16/0.35/0.01/1.2, dsn=5.1.1, status=bounced (host smtp-in.orange.fr[80.12.242.9] said: 550 5.1.1 Address of at least one invalid recipient. Invalid recipient. OFR_416 [416] (in reply to RCPT TO command))
Mar 7 10:10:07 cerapoda postfix/bounce[10508]: 8C33F2542A2: sender non-delivery notification: 504922542A5
Mar 7 10:10:07 cerapoda postfix/qmgr[14891]: 8C33F2542A2: removed
Since I'm doing my processing on "Invalid recipient", it goes to hard bounce... I'll have to process the "Address of at least one invalid recipient" instead and switch it to soft...
Concerning unsubscriptions, I don't have this kind of problem because I rely on the address of the original recipient. But indeed, if the recipient doesn't use the unsubscribe link and asks me to unsubscribe him (during a redirection), if I don't have the original message, I'm a bit annoyed 🙂