Skip to main content
Each problem starts with its most frequent cause. The link at the end of each answer goes to the page that settles it.

​
A campaign will not leave

The Delivery tab lists what blocks it, each line with the link that settles it. The whole list, with what each line asks, is in Ready or not. Through the API, the same lines come back in problems, with a 422. A campaign that stopped in the middle, with a reason in red, paused itself: too many bounces or complaints. Read Paused on its own before you start it again.

​
E-mails land in spam

Filters judge who you are, what you send, and to whom. In that order:
  1. Who you are. SPF, DKIM and DMARC published and found for the domain of the sender. Deliverability shows each record’s state. A sender on a domain without them is the first cause, by far. See Sending domains.
  2. Your links. Click tracking sends every link through Lekalao’s address. A tracking host on your own domain keeps them under your name.
  3. What you send. The check before sending names what filters punish: a subject in capitals, shortened links, a link that shows one address and goes to another. See What a spam filter would hold against it.
  4. To whom. Bounces and complaints weigh more than anything else. The rates of the last thirty days are on Deliverability: mailboxes react above 2 % bounces and 0.1 % complaints. Old addresses and people who stopped reading are dealt with in List hygiene.
  5. A new sender. A domain nobody knows that sends its whole list on day one looks like a spammer. See Warming up a new sender.
Give transactional e-mails a mailer of their own: a campaign that goes wrong then never drags your invoices into spam. See A provider per kind of sending.

​
An import failed

The list’s Imports tab shows each import, Failed or Completed with its rows in error.
  • Refused at once: the file has no header row (“This file has no header row.”), no column holds the address (“One column must hold the e-mail address.”), or it is not a CSV, TXT or XLSX file of 20 MB at most.
  • Failed part-way: most often the plan’s subscriber allowance ran out. The rows already handled stay imported. Make room or move up a plan, then import the rest. See Billing.
  • Completed, with rows in error: each row says why. An invalid address; an address on the suppression list; someone who unsubscribed earlier (“Skipped: … unsubscribed earlier.”), who comes back only when Subscribe again people who unsubscribed is ticked and they asked for it; a throwaway mailbox, or a domain with no mail server. See List hygiene.
  • Imported, and nothing was sent to them: that is the default. No welcome e-mail and no automation start for imported people, unless Welcome them as new subscribers was ticked.
Everything an import does is in Import and export.

​
A webhook does not arrive

Start with Settings → Outgoing webhooks, and the endpoint’s Calls we made: every call is there, with your server’s answer.
  • No call at all. The endpoint does not listen to that event; or it is limited to one list, and the event belongs to no list (transactional e-mails, their bounces and complaints); or it is Switched off, by hand or after 3 days of failures, in which case its owners received an e-mail. Switch Call this endpoint back on.
  • Calls that failed. Your server must answer a 2xx within 15 seconds, without a redirect: redirects are not followed. Lekalao tries each call again for about 21 hours (Trying again); once your server answers, the next attempt goes through. A call Failed after its seventh attempt is sent again only with Send again.
  • An address Lekalao refuses. It must be public: localhost and private networks are refused. To test on your machine, go through a tunnel.
  • Calls that arrive and that your code rejects. The signature is computed on the time of the call, a dot and the raw body, with this endpoint’s own secret; a server whose clock is more than five minutes off refuses every call. See Check the signature.
  • The same event twice. A retry or a Send again carries the same Lekalao-Event-Id: ignore an id you already handled.
  • No mail.bounced or mail.complaint. They come from your provider first. If the provider does not report to Lekalao, there is nothing to pass on: Settings → Provider feedback lists what it received. See Provider feedback.
See Outgoing webhooks and, for the code, Webhooks.

​
A transactional e-mail stays pending

For a few seconds, pending is normal: the e-mail leaves from a queue, after the answer. For minutes:
  • The provider fails, and Lekalao tries again, after 5 seconds, 30 seconds, 2 minutes, 10 minutes and 30 minutes. After the sixth failure, and six hours after the call at the latest, the e-mail becomes failed, with the provider’s last error in failure_reason.
  • The mailer’s rate limit holds e-mails back when many leave at once. It is set on the mailer.
  • On an installation of your own, the workers may be stopped. Settings → Maintenance shows the queues and the failed jobs. On Lekalao’s service, tell the support.
  • The queue lost it. After a restore, or a Redis that restarted without its data, an e-mail may have no job left to send it. Seven hours after the call, it becomes failed with failure_code: lost. Send it again.
Once it is failed: read failure_code and failure_reason, test the mailer with Send a test e-mail, then send the e-mail again, with Send again in the log or POST /v1/transactional-mails/{id}/resend. See Then, on the queue.

​
An address receives nothing any more

Most often it is on the suppression list: it bounced for good (Hard bounce), its owner reported an e-mail as spam (Spam complaint), or somebody blocked it (Added manually). Look it up in Contacts → Suppression list.
  • Nothing is sent to it any more: no campaign, no automation, no confirmation, and no transactional e-mail either. A transactional e-mail leaves it out of its recipients; with nobody left in to, the call answers 422 recipients_suppressed and failure_reason names it.
  • Through the API, subscribing it again answers 422 address_suppressed (“This address is blocked.”), and a batch marks its line failed.
  • A hard bounce or a complaint also unsubscribed the person from every list.
Take it off only when the person asks you to, with the bin on its row: an address that bounced will bounce again, and someone who complained will complain again. See Suppression list and Provider feedback.

​
Still stuck

  • Every error code of the API, and when to try again: Errors.
  • What changed lately: Changelog.