Email from your own domain

Your bot can email your customers from an address on your domain, such as noreply@example.com. The message itself is sent by our server. Because of that, you need to add three DNS records to your domain once, before the first send. Below: why that is necessary, exactly what to add, and what happens afterwards.

First, the plan

Email is a paid bot-builder capability. It is in the Pro, Business and Enterprise plans; the free Start plan does not have it, and no Customer Engagement plan grants it. See Plans.

Check the plan before going into DNS. On a plan without email the whole section is closed: the sending domain cannot be added and every request answers 402. You can still publish the SPF, DKIM and DMARC records, they will simply serve nobody: the platform does not start sending mail because they exist.

Why mail will not arrive without DNS records

Look at it from the receiving side: Gmail, Outlook, or your customer's own mail server. A message arrives that claims to come from your domain, but it arrives from a server that does not belong to your domain. That is exactly what a forgery looks like: this is how phishing works.

The only way the receiver can tell the two apart is to ask your domain itself: "is this sender really acting on your behalf?" You publish the answer in your domain's DNS, because DNS is the one place only you control, and therefore the one place the receiver trusts.

Until that answer is there, a conscientious mail server has to treat the message as suspicious. At best it lands in Spam; at worst it is rejected and the recipient never learns it existed.

So the three records below are not paperwork and not a checkbox in an interface. They are your authorisation.

The three records and what each one does

DKIM: a signature proving the message is genuine

DKIM is a cryptographic signature added to every outgoing message. The platform generates a key pair for your domain: the private half stays with us and signs your mail, the public half you publish in DNS. The receiver takes the public key from your DNS and checks the signature. If it matches, the message was sent by whoever holds the private key and its contents were not altered in transit.

Without DKIM: there is nothing to check the signature against. The message looks unsigned and untrusted, and no other setting makes up for it. DKIM is the most important of the three.

SPF: which servers may send on your behalf

SPF answers a different question: which servers are allowed to send mail for this domain at all. It is a list of sources: your hosting provider's mail servers, the sending services you already use, and, so the bot can send, our sending servers.

Without SPF: the message arrives from a server your domain does not acknowledge. To a filter that is a classic sign of forgery, and it adds to every other suspicion.

DMARC: what a receiver should do when the checks fail

DKIM and SPF answer "is this message genuine". DMARC answers the next question: what to do if it is not. It is your instruction to the receiver: do nothing and just report, put it in spam, or reject it. DMARC is also the address receivers send aggregate reports to, including reports of other people forging your domain.

Start with the mildest policy, "report only". Tighten it later, once you are sure every legitimate sender of yours (accounting, CRM, newsletters, this bot) passes the checks. A strict policy switched on too early starts eating your own mail.

Without DMARC: every receiver decides for itself, and you never find out what is happening to mail sent in your name.

Which records to add

First add the domain in the dashboard: the Email section → "Sending domains" → the "Add domain" button. The dialog has three fields: the domain itself (shop.example.com, say), the local part of the address (what goes before @, usually noreply) and the sender name the recipient sees instead of an address. Your DNS records appear on screen once you save.

Both halves of the address are validated on save, and the rules are stricter than mail in general:

• The domain is lowercased and must be a fully qualified name of at least two labels (example.com, mail.example.com), no longer than 253 characters. Each label may contain Latin letters, digits and hyphens, and must begin and end with a letter or digit: -mail.example.com and mail-.example.com are refused. Write internationalised domains in punycode (xn--…).
• The local part is lowercased, is at most 64 characters, may contain Latin letters, digits and ., _, +, -, and must begin and end with a letter or digit. So noreply, no-reply and news.2026 are fine, while noreply-, .noreply and no..reply- are not (the last character is neither a letter nor a digit).
• Line breaks and other control characters are refused in both fields. They could otherwise inject extra headers into a message: one that is signed with your domain's key, that is, in your name.

An address that fails these rules is refused with 400 when the domain is saved, before anything is ever sent. Inbound addresses follow slightly different rules, described in Email campaigns.

All three are TXT records in your domain's DNS. You add them wherever you manage the domain: your registrar's control panel or your DNS provider.

The values below use example.com as an example: substitute your own. The exact values for your domain are shown on the domain card in the dashboard; copy them from there, especially DKIM: its value contains your own public key, which is different for every domain and cannot be taken from documentation.

On screen each record is split into two separate fields: "Host" and "Value": each with its own "Copy" button. Copy them one at a time into the matching fields at your DNS provider: the two parts do not paste as a single block.

Two things people trip over most often:

• Many control panels append the domain to the record name for you. If the name field already shows ".example.com", enter only mybot._domainkey and not the full name, otherwise you end up with mybot._domainkey.example.com.example.com.
• The DKIM value is long and must contain no line breaks or spaces inside the key. Copy it with the button rather than by dragging a selection.

If the domain already has an SPF record

A domain may have only one SPF record. If you already send mail through your hosting, a CRM or another newsletter service, you already have one. Do not add a second: add another include to the existing record, before the trailing ~all:

v=spf1 include:spf.yourprovider.com include:esp.getmybot.dev ~all

Two SPF records on a domain is the same failure as none: the check does not pass, because the receiver has no way to know which of the two to believe.

Note that being "covered" through someone else's record is not enough. Even if your current provider includes us in their own SPF, our include has to sit in your record directly: see the verification section below for why.

Why SPF uses an include and not an IP address

The most common mistake is pasting an IP address spotted in a message header or someone's forum post. Do not do that.

include:esp.getmybot.dev is a pointer to our own, maintained list of sending servers. Today that name resolves to a single relay. Tomorrow there may be more of them, they may move, they may be replaced. When that happens we update the list on our side and your record keeps working with nothing for you to change. That is the entire point: the address changes in one place instead of in every customer's DNS.

A hand-written IP address simply stops being true at that moment. Mail starts failing SPF with no warning at all: no error in the dashboard, no notification. You find out from customers who "never received anything".

Write exactly include:esp.getmybot.dev and add nothing to it.

Domain verification

Domain verification is the platform looking into your domain's DNS itself and confirming that all three records are in place. If all three pass, the domain becomes verified and sending is allowed. While any of them fails, the domain stays pending.

What is checked is more than "a record exists":

Why DMARC is checked more loosely: it tells receivers what to do with the DKIM and SPF results, but it does not grant us the right to send as you. That right comes from the first two records alone, and both of those are fully content-checked.

Someone else's include does not count

include:esp.getmybot.dev has to be in your own SPF record. If your SPF includes a third-party provider whose record in turn includes us, verification will not accept that: the platform does not resolve chains of other people's includes. The reason is simple: it keeps the answer to "did this specific domain authorise us" unambiguous.

In practice: even if you are confident you are "covered through your provider", add our include directly to your own record. The screen says the same thing in its SPF explainer: if the domain already has an SPF record, add the include:... value to it rather than replacing the record wholesale, because the domain may send mail through others too. That note is always on screen, not something that appears only after a failed check.

DNS does not update instantly. After you save the records at your registrar they have to propagate across name servers: usually minutes, sometimes hours, occasionally up to a day. It depends on your provider and the records' TTL. This is normal and not something we control.

You do not have to wait passively, though. The platform re-checks pending domains once an hour on its own, but the domain card also has a "Verify now" button: the very same check, run immediately, with the result on screen straight away. Use it right after saving the records: if there is a typo, you find out in a second rather than in an hour. You can run it as often as you like.

The domain's status is shown on the card: "Pending verification", "Verified" or "Not verified". While it is unverified, the card also carries the warning "Sending from this domain is disabled until it is verified."

The result is not just "failed". Each of the three records has its own status on screen: "Passing", "Not passing" or "Not checked yet": and its own line explaining what is wrong.

For SPF the screen distinguishes two situations, and this is the distinction that matters most in the whole process:

• The domain has no SPF record at all. Publish one, using the value from the table above.
• An SPF record exists but does not contain our include. Add the include to the existing record: do not create a second one and do not replace it wholesale. The same message also covers the chained case explicitly: if the include only reaches us through another provider's SPF record, that does not count: chains are not resolved.

The second case is the single most confusing moment in this flow: the record is already there, you have just re-read it yourself, and verification still refuses. The error message now says exactly what the always-visible hint next to the record says: add our include to what you already have.

If verification does not pass:

1. Read which of the three records is marked "Not passing" and what its explanation says, then act on it.
2. Make sure the records really are published: many panels need a separate "apply changes" click.
3. Check the record name for a doubled domain (see above).
4. Check that there is only one SPF record on the domain and that our include is inside that record itself.
5. Wait a bit and check again: the change may simply not have propagated yet.

Sending refuses to work until the domain is verified

While a domain is unverified, mail is not sent. Not "sent and filtered into spam": not sent at all: the attempt fails with an unverified-domain error, visible in the log.

That is deliberate, and it is not a bug. Mail from a domain that has not vouched for itself turns into spam complaints, and complaints damage the reputation of sending infrastructure shared by every customer of the platform. Not sending a message is cheaper than sending it and then spending six months climbing out of blocklists. Hence a refusal rather than a warning.

If you see this error, check the DNS records and press the check action before writing to support. In the overwhelming majority of cases it is a typo in a record name.

Unsubscribes, complaints and bounces

Three rules that surprise people who were not told in advance.

Every marketing message carries a one-click unsubscribe. The platform adds an unsubscribe link to the message footer and the technical headers mail clients use to draw an "Unsubscribe" button next to the sender's address. You cannot remove it: not by a setting, not by editing the message. The unsubscribe takes effect immediately, without opening the message and without a confirmation step. Gmail and the other large mail services require this of bulk senders: a message without it goes to spam for certain.

An unsubscribe is permanent and cannot be undone from the interface. An unsubscribed address receives no further mail from this bot. There is no "restore" button and no workaround via re-importing a list: an unsubscribe is never overridden on the person's behalf. They can come back only by opting in themselves through your subscription form.

There is a harsher case still: if someone pressed "This is spam" in their mail client, the address is closed for good. Even a fresh opt-in through your form will not reopen it: because we already know how the previous attempt ended, and mailing such an address is the fastest way to destroy a domain's reputation. Addresses closed manually on legal request behave the same way.

A hard bounce suppresses the address permanently. If the recipient's mail server replies that no such mailbox exists, the address is marked undeliverable and dropped from future sends. This is not a temporary state. Continuing to hammer a non-existent mailbox is the quickest route into spam filters wholesale, taking every other address with it.

Soft bounces (a full mailbox, a server that is temporarily down) do not suppress the address: sending to it continues.

Why the open rate is undercounted

Email statistics include an opens figure, and it is always lower than reality. That is not a counting bug: it is how opens are measured at all.

An open is recorded when the mail client loads a tiny tracking image from a server while displaying the message. Modern clients do not load remote images by default; and the ones that do (Apple Mail and similar privacy features) load them in advance for everyone, including people who never opened the message. In the first case the open is lost; in the second it is credited to someone who was not there. There is no way to count email opens more precisely: not for us and not for anyone else.

That is why the interface carries a caveat next to the figure: it is a lower bound, not an exact number. Use it to compare messages against each other, where the same distortion applies to all of them, but not as an answer to "how many people read this message".

If you need a dependable engagement metric, look at "Link clicks". A click on a link is a real action by a real person; nobody performs it in advance on their behalf. "Delivered", "Unsubscribes", "Complaints" and "Bounces" are counted exactly too: they are reported by mail servers rather than by an image inside a message. All of these live in the "Sending stats" block on the same Email screen.

What's next

• Channels: multichannel bots and channel capabilities.
• Broadcasts: sending to many people at once.
• Analytics: where to find the numbers.