Changelog

Every email SendByte sends you, from domain checks to receipts to usage alerts, has a new design. Each one reads like a record of what happened:

• The state comes first. A tag such as Verified, Payment failed or 80% used sits above the headline, with the time it happened in UTC.
• The facts sit in one place. Domains, record names, amounts, dates and references are laid out in a short table you can scan or copy.
• One clear next step. Each email has a single button for the thing to do, and the footer says why you received it.
• Light and dark. Emails follow your mail app’s dark mode where it supports one, and read cleanly on a phone.

We also added a warning before a project is paused for its bounce or spam complaint rate. If the bounce rate reaches 5%, or complaints reach 0.3%, over the last 24 hours, the project owner gets an email with the numbers, the addresses that failed, and what to fix. Sending only pauses above 8% bounces or 0.5% complaints, so there is time to clean the list first. The warning is sent at most once a day while the rate stays high.

When you add a domain, we check your DNS records until they appear. Until now, a check that ran before you saved a record could leave us seeing “not found” for up to an hour after the record was published, depending on your DNS provider. Check again gave the same stale answer, and your domain sat at Pending even though your setup was correct.

We now read your records straight from your domain’s own DNS servers:

• A record you just saved shows as found on the next check, usually within seconds.
• Verification follows a few minutes later, once our sending provider confirms your DKIM key.
• Nothing changes on your side. The records you publish are the same, and domains that are already verified are unaffected.

Until now, when SendByte could not hand an email to the mail network, the email log called it Bounced. A bounce means the receiving server turned the address down. These emails never got that far, so the label pointed you at the address when the problem was on our side.

Those emails now show as Failed:

• The email log says what happened. A failed email explains that it never left SendByte and that the recipient was not blocked. You can filter the log by Failed.
• Your bounce rate is not affected. Failed emails no longer count as bounces in your analytics or in the checks that protect your sending reputation.
• The API matches. status can now be failed, and the list and export endpoints accept status=failed. Webhooks already sent email.failed for these emails, and still do.

We also corrected the few emails from 8 October that were wrongly marked as bounced during that day’s outage.

Welcome credit in your wallet now pays for sending emails only. Plan payments and renewals come from money you add to your wallet or from your card. Your billing page shows how much of your balance is welcome credit.

sendbyte.africa now has a dark theme on every page, the same near-black our product screens and code samples already sit on. The site follows your device by default, and the theme switch in the header and footer lets you pick System, Light or Dark.

• The product shows its work. On the homepage and the product pages, the panels play out as you scroll to them: an email moves from queued to delivered, DNS records turn verified, a campaign fills its hourly batches, and a webhook gets its 200.
• A price that stays put. The pricing panel shows a dollar-priced plan changing with the exchange rate while your Naira price does not move.
• Calm if you prefer it. If your device is set to reduce motion, every panel shows its finished state straight away.

The status page at status.sendbyte.africa has the same themes and the same switch, and remembers the choice you made on the main site.

If your DKIM record goes missing, we pause sending from that domain until it reads back, so mail never goes out unsigned. When you re-add the record, the dashboard says sending resumes within the hour. Until today that was not always true: if our email provider had checked the domain while the record was still missing, it could hold the domain for hours, and in the worst case up to three days, before checking again.

Now, as soon as we see the record back in your DNS, we ask the provider to check again straight away. That check usually finishes in a minute or two, and sending resumes on the next hourly pass, with nothing for you to do. Domains that are sending normally are never touched by this.

If you import people who already agreed to hear from you into a list set to “Confirm by email”, they arrive as Unconfirmed. You can now move them to Subscribed yourself.

• Mark subscribed. Unconfirmed rows in a list now have a “Mark subscribed” action. It asks you to confirm first, because no confirmation email is sent. Use it only for people who already said yes, for example on your own website.
• Re-import after switching. If you change a list to “Join straight away” and import the same contacts again, anyone still Unconfirmed is now moved to Subscribed. Before, the import reported them as updated but left them Unconfirmed.

People who unsubscribed, bounced or marked your mail as spam are never re-activated by either path.

Campaign emails sent with click tracking on could carry an unsubscribe link that opened a “This link is not valid” page, so readers could not opt out. That is fixed. Every campaign sent from now on has a working unsubscribe link, whether it uses the {{unsubscribe_url}} merge tag or the footer we add for you.

Campaigns sent before today keep the old link. If a reader of one of those asks to be removed, you can remove them from the list in Subscribers.

Test emails still show a placeholder unsubscribe link on purpose, so it will not unsubscribe anyone.

Changing the From name in Brand settings used to have no effect on campaigns, so subscribers kept seeing the old name. That is fixed.

New campaigns start with your brand’s sender. The From line is filled in from the From name and From address in Brand settings. You can still change it for a single campaign.

Drafts can adopt the new sender in one click. If a draft’s From line differs from your brand’s, a “Use brand sender” link appears under the field. Campaigns that are already scheduled or sent keep the sender they were saved with.

The footer we add names your brand. When a campaign has no unsubscribe link of its own, the footer we append now says who the subscriber signed up with and includes your postal address. Welcome emails and autoresponders get the same footer. If you build your own footer, nothing changes.

The API, open and click tracking, and the SMTP relay now run on two servers in separate data centres. If one stops responding, traffic moves to the other on its own, usually within a minute, and our own updates no longer interrupt requests in flight.

If you connect to api.sendbyte.africa and smtp.sendbyte.africa by name, as our docs describe, there is nothing to do.

One case needs a change. If your firewall only allows outbound connections to fixed IP addresses, the addresses behind smtp.sendbyte.africa are now 13.244.253.10 and 15.240.4.124 (ports 587, 465 and 2525), and the previous addresses no longer accept connections. Allow smtp.sendbyte.africa by name if your firewall supports it; otherwise allow both of these addresses. The same two addresses are now the source of our webhook requests, so if you only accept webhooks from known addresses, add them there too.

Billing now has a Payment method section, so you can see and control the card we use when your plan renews.

Add a card in a minute. Choose Add a card and pay ₦100 on Paystack’s secure page to confirm it. The ₦100 is not a fee: it goes straight into your wallet and counts toward your next renewal. Card details are only ever entered on Paystack, never in the dashboard.

Know exactly how you will be charged. The section shows the card on file and your next renewal date and amount. We always use your wallet balance first, then your card. If you have no card, it says plainly what happens if your wallet does not cover the renewal.

Replace or remove it any time. Adding a new card replaces the old one. Removing a card tells you what that means for your next renewal before you confirm. The account owner gets an email whenever a card is added or removed.

Problems are clear. If an automatic payment fails, Billing shows the reason from your bank, how many retries are left and when the next one runs. If your card expires before your next renewal, Billing warns you, and we email you a week before it expires.

You can also tick “Save this card for renewals” when you top up your wallet by card. Owners and admins can change the payment method; other team members can see it.

You can now change a webhook endpoint’s URL and delete endpoints you no longer need, from the Webhooks page or the API.

Change the URL, keep the secret. Moving your endpoint to a new domain or path no longer means creating a new endpoint with a new signing secret. Choose Edit URL, enter the new address and save. The signing secret stays the same, so your signature checks keep working. Events that were still waiting or retrying are sent to the new URL, so nothing you missed while the old address was broken is lost. If we had turned the endpoint off after repeated failures, you can turn it back on in the same step.

Delete for good. Delete removes an endpoint and its delivery history, and events stop immediately. If you only want to pause an endpoint and keep its history, use Disable.

Safer by default. Two endpoints in a project can no longer be edited to share one URL, which would deliver every event twice. The delivery log shows which address each attempt went to when an endpoint’s URL has changed. The account owner gets an email whenever an endpoint’s URL is changed or an endpoint is deleted.

In the API, use PATCH /v1/webhooks/{id} to change the URL and DELETE /v1/webhooks/{id}?permanent=true to delete. A DELETE without permanent=true still disables the endpoint, exactly as before, so existing integrations are unaffected. There is also an explicit POST /v1/webhooks/{id}/disable.

The dashboard has been rebuilt around one question: is anything wrong with my sending, and what do I do about it?

The Overview tells you what needs attention. It now opens with a short list of anything that is stopping or slowing your mail: sending that has been paused, a domain that has stopped working, a plan allowance that is nearly or fully used, a low wallet, a webhook that was switched off after repeated failures, or a bounce or complaint rate that is too high. Each item says what happened and links straight to the fix. When nothing is wrong, it says so.

Fewer places to look. Everything now sits in nine sections: Overview, Email log, Domains, Deliverability, Templates, Developers, Marketing, Billing and Team. API keys, SMTP, webhooks and test recipients live together under Developers. Reputation and suppressions live together under Deliverability.

Domain health is on the Domains page. Each domain shows whether it is working and when it was last checked, without opening it.

Marketing has its own space. Brands, lists, subscribers and campaigns open in a separate area with a brand switcher, so campaign work and API work no longer share one menu.

Clearer numbers. The Usage page shows each day’s sends with a scale you can read, and you can point at or tap a day to see its delivered and bounced counts. Dates read the same way on every page.

Your subscribers’ pages are more neutral. The subscribe, confirm and unsubscribe pages your subscribers see no longer use SendByte’s colours, so they sit more quietly alongside your own brand.

Sign in, sign up and password reset have been redesigned to match, and dark mode works throughout the dashboard.

Nothing changes in the API, SMTP or webhooks.

Three parts of the platform used to depend on a single in-flight step going right the first time. They no longer do.

Bounces and complaints are saved the moment they arrive. When a mailbox provider reports a bounce or a spam complaint, we now record it before we acknowledge it, then process it. If processing is interrupted, it is picked up again automatically within about 20 minutes. The address is still suppressed, your email log still shows the outcome, and your email.bounced and email.complained webhooks still fire.

Scheduled emails and scheduled campaigns catch up if they miss their time. A scheduled send that does not start on time is now noticed and started within about 40 minutes of its scheduled time, instead of waiting indefinitely. A scheduled campaign is picked up within about 15 minutes. Nobody is mailed twice: each message is still sent at most once.

Webhook deliveries that go missing are retried. If a webhook event was recorded for your endpoint but never attempted, we now retry it for up to three days after the event, with the same payload and the usual signature header.

Nothing changes in how you call the API or configure webhooks.

The website has a new design, and every page now says less and shows more.

The homepage runs a real send, from the API call to the delivery webhook, so you can see what happens to an email before you sign up. Pricing lists every plan limit line by line, exactly as the product enforces it. The comparison pages were re-checked against each provider’s official pricing page, and they say plainly where another provider is the better pick.

The cost calculator now lets you set the exchange rate and card fee you actually pay, and it includes more providers. The deliverability audit and the migration planner show what they will check before you run them. The status page is easier to read at a glance.

We also removed claims we could not back up, so what the site says matches what the product does today.

Our abuse filter blocks a sender pretending to be a brand it does not own, which is the shape almost all brand phishing takes. It was reading your sender name and your subject line as if they were the same thing, so a brand named anywhere in either was treated as you claiming to be that brand, and that was enough to suspend the whole project.

That is too blunt, and it caught a real customer. They sent a message whose subject mentioned Apple, from an address with no display name at all. A From address with no display name cannot claim to be anyone, so there was nothing being impersonated, and their account was still closed.

The two are now separate. A brand name in your sender identity is still treated as impersonation and still suspends the project. A brand name that only appears in a subject line no longer touches your account.

One limit stays, and it is deliberate. A subject naming a global brand such as Apple, PayPal or Microsoft is still rejected at the point of sending, and you get an error back instead. A big brand in a subject line is genuinely how phishing reads to the person receiving it, and we would rather refuse one message than let that through. If you have a real reason to send one, for example announcing a payment method you now support, contact support and we will clear it for your account.

Worth knowing either way: our filter never flags a message whose sender name relates to the domain it is sent from, so sending as Your Brand <noreply@yourbrand.com> rather than a bare noreply@yourbrand.com protects you from this whole class of check, and gives your recipients a real sender name to look at.

Raise a ticket from your dashboard, or from the contact form on our website, and you now get an email back straight away, with our support inbox copied so the thread stays in one place. It carries your ticket number, so you have something to quote, and replying to it keeps you on the same ticket.

The reply is not one stock paragraph for everybody. We read what you actually wrote, and answer in kind. A ticket about a blocked project tells you a review has started and asks for the sender address and subject line that were rejected, because those are what let us finish it quickly. A ticket about domain verification points you at the exact record to check, and warns you about the one thing that catches most people, which is that removing a domain and adding it back issues a fresh DKIM key and quietly invalidates the record you published before. A billing ticket explains up front why a card issued outside Nigeria is often declined on a Naira charge, and what to use instead.

We chose to read the wording rather than trust the category you pick. Looking back at the tickets we have received, nearly every customer whose sending had stopped filed it as “general” or “other”, so trusting the dropdown would have sent the most urgent people the blandest reply.

Two smaller things went out with it.

Asking the API for a domain by its name now works. GET /v1/domains/yourdomain.com used to expect the internal id and returned a server error on anything else, which read as though we had lost the domain. It now accepts the name or the id, and an identifier we do not recognise comes back as a plain not found.

And every ticket that was open in our queue has been read, investigated and answered.

A webhook signing secret is shown once, at the moment you create the endpoint, and we never show it again. That is deliberate and it is how API keys work here too. What was missing was the other half: if you lost the secret, or never captured it in the first place, there was no way to get a working one back. Recreating the endpoint gave you a new secret but abandoned the old endpoint, its id and its delivery history, and left a gap where nothing was registered.

You can now press Rotate secret on any endpoint on the Webhooks page, or call POST /v1/webhooks/{id}/rotate-secret. It issues a fresh secret and shows it once. The endpoint keeps its id, its URL and every delivery we have recorded against it. Only the secret changes. The old one stops verifying the moment you rotate, so have somewhere to paste the new one before you press it.

We have also written down the thing that sent one customer on a multi-day investigation. Every endpoint carries its own independent secret, and an endpoint’s URL cannot be changed after you register it. So moving your handler to a new URL means registering a second endpoint, and that second endpoint signs with a new and unrelated secret. If your handler is still verifying with the first endpoint’s secret, every signature mismatches while your algorithm and your raw body are perfectly correct. The webhooks guide now covers that case with a worked example, and tells you to list your endpoints first when a signature will not verify.

There is now an Export CSV button in the toolbar above your email log, and a matching GET /v1/emails/export if you would rather script it. It downloads your send history as a spreadsheet: when each message went out, its status, who it went to, the subject, which domain it was sent from, opens and clicks, and the message id so you can look any row back up through the API.

The important part is that the file matches what you are looking at. Whatever filters are on when you press the button travel with the download, so a search for one recipient with the status set to bounced gives you a file of exactly that, not your whole history under a misleading filename. The per-domain log exports just that domain.

Two things worth knowing before you open the file.

It covers the same window your plan lets you read. The email log has always shown a bounded stretch of history, from a week on Free up to ninety days on Scale, and the export honours the same boundary rather than pretending to be a complete archive. The file carries headers naming the exact window it covers, and the log page tells you what your plan keeps. Older sends are hidden, not deleted, and they come back in both places on a plan with a longer window.

Subjects that begin with an equals sign are prefixed with an apostrophe. Your recipients did not choose their subject lines, but a reply, a forwarded thread or an imported name can put text you did not write into a cell, and a spreadsheet will happily execute a cell starting with = the moment the file is opened. Making it text is the difference between a spreadsheet and a way in.

There is a gap between your DNS recovering and us being able to act on it. If your DKIM record disappears for a few hours we mark the domain Degraded, and once the record comes back we have to wait for Amazon to re-read it and re-confirm the key before sending can resume. That re-confirmation takes up to an hour, sometimes a little more. It is not something a button can hurry.

The banner on your Domains page did not say any of that. It said “A required record changed. Check again, then re-add anything missing below” and named no record, while every record in the table underneath it read Found. That is a contradiction with no way out of it, and the only thing it invites you to do is click Check verification over and over, which cannot help. One customer clicked it about twenty times in an hour before writing in, and their DNS had been correct the whole time.

The banner now reads the same DNS results you are looking at. If a required record genuinely fails the check, it names that record and asks you to re-add it, as before. If every record resolves, it says the records were found, that re-verification finishes on its own, usually within the hour, and that there is nothing to re-add and no reason to check again. Same wait, but you now know what you are waiting for and that you are not the one holding it up.