Plain definitions of the words that turn up in email infrastructure: DKIM, SPF, DMARC, bounces, complaints, suppressions, idempotency, webhooks and more.
An API key is the credential a program uses to call an email API. It identifies the account, carries a set of permissions, and travels in an authorization header rather than in the URL. A key is a secret: keep it in your server's environment, never in client code or a repository, and revoke it the moment you suspect it has leaked.
In Rasket: Keys start with rk_, are shown once and stored only as a hash, and each one is either full access or sending only, optionally locked to a single domain. Authentication
Automation
An automation is a workflow that runs for one contact at a time. Something happens in your product, that contact enters at the trigger, and the graph carries them through sends, waits and branches until it ends. It replaces a pile of scheduled scripts with one picture a colleague can read, and every run can be inspected after the fact.
In Rasket: An automation starts on an event you send, then sends published templates, waits, branches on the contact, and updates properties, segments and topics. Automations
Bounce (hard vs soft)
A bounce is a rejection by the receiving mail server. A hard bounce is permanent: the mailbox does not exist, or the domain refuses your mail, and trying again will fail the same way. A soft bounce is temporary: a full mailbox, a server under load, a message deferred until later. Hard bounces should stop all future sends to that address. Soft ones should not.
In Rasket: A permanent bounce adds the address to your suppression list on its own; a temporary one is reported and nothing is suppressed. Events
Broadcast
A broadcast is one message sent to many people at once: a newsletter, a product announcement, a release note. What separates it from transactional mail is who asked for it. A broadcast goes to a list rather than to one person who has just done something, so it needs consent, a working unsubscribe and a postal address in the footer.
In Rasket: A broadcast is addressed to a segment and produces one ordinary email per recipient, so suppression, tracking and events behave exactly as they do for a single send. Broadcasts
Complaint (feedback loop)
A complaint is what happens when a reader presses the spam button. Large mailbox providers report those presses back to the sender over a feedback loop, so you learn which address complained even though the reader never wrote to you. Complaints are the strongest deliverability signal there is, and a rising rate costs you the inbox for everyone else on the list.
In Rasket: A complaint suppresses the address immediately and arrives on your webhook endpoints as an email.complained event. Events
Contact
A contact is a person in your audience: an address, a name, and whatever else you know about them. Contacts are the unit marketing email is addressed to, and the place consent is recorded, so a contact is also where you answer the only question that matters before a send. May we write to this person, and about what.
In Rasket: Contacts carry properties you declare with types, an unsubscribed flag, and a subscription for each of your topics. Broadcasts
Custom return path (MAIL FROM)
The return path, also called MAIL FROM or the envelope sender, is the address bounces come back to. It is set during the delivery conversation between servers and is usually invisible to readers, who see the From header instead. Putting the return path on a subdomain you control is what lets SPF align with the domain your mail claims to be from.
In Rasket: Every sending domain gets a return path on a subdomain of itself, at the send label by default, and you can choose another label. Domains
Dedicated IP
A dedicated IP is a sending address used by one sender and nobody else. Its reputation is entirely yours: nothing another sender does can damage it, and nothing they do can help it either. It suits high and steady volume. Below a few thousand messages a day it usually hurts, because there is not enough traffic for receiving servers to form an opinion.
In Rasket: A dedicated IP is an add-on for high-volume senders on the larger plans, and we warm it up and watch it for you. Pricing
Delivery event
A delivery event says a receiving mail server accepted the message. That is the end of the part you control. It is not proof anyone read the mail, and not proof it landed in the inbox rather than the spam folder. Delivery, bounces, complaints, opens and clicks together are the timeline of a message after it leaves your code.
In Rasket: Every email keeps a timeline of its events, and the same events reach your webhook endpoints as they happen. Events
DKIM
DKIM signs outgoing mail with a private key and publishes the matching public key in DNS, under a label called a selector. A receiving server fetches the key, checks the signature, and learns that the message was not altered on the way and really came from a sender your domain authorized. It survives forwarding, which is why it matters more than SPF alone.
In Rasket: Each domain gets its own 2048-bit key, published as one TXT record under the selector rasket._domainkey. Domains
DMARC
DMARC tells receiving servers what to do with mail that claims to be from your domain but fails DKIM and SPF. You publish one TXT record naming a policy, none, quarantine or reject, and an address for the reports. It also demands alignment: the domain that passed authentication has to match the one a reader sees in the From header.
In Rasket: The dashboard shows the record to publish, walks you from none up to reject, and warns you when a strict policy would block mail you have not finished authenticating. Domains
Domain verification
Domain verification is proving you control the domain you want to send from. You add the domain, publish the DNS records you are handed, and wait for them to resolve everywhere. Until they do, mail from that domain is unauthenticated and receiving servers treat it as such. Verification is per domain, and it is the first thing to do with a new one.
In Rasket: Checks run on their own until every record resolves, and keep running afterwards, so you hear about it if a record is later changed or removed. Domains
Idempotency key
An idempotency key is a string you attach to a request so the server can tell a retry from a new request. A network timeout never says whether the work happened, so a client that retries without one can send the same email twice. With one, the second call gets the first call's answer back instead of sending anything.
In Rasket: Send an Idempotency-Key header on a send and the same key with the same payload replays the original response for 24 hours. Idempotency
Inbound email / receiving
Receiving is the other half of an email API. Mail addressed to your domain arrives, is parsed into headers, text, HTML and attachments, and is handed to your code. It turns an address into an endpoint, which is how support inboxes, reply handling and forward-this-to-the-app features get built without anybody running a mail server.
In Rasket: Point one MX record at us, subscribe to the email.received event, and each message arrives as a webhook carrying the envelope and the attachment list. Receiving
IP warming
Warming is the practice of raising volume on a new sending address slowly rather than all at once. Receiving servers judge an address they have never seen by how it behaves, and a sudden burst from an unknown one looks like a spam run. A warm-up sends a little on the first day and more each day after, watching bounces and complaints as it climbs.
In Rasket: A dedicated IP is warmed for you, and the plan settings show how far through the ramp it has got. Pricing
Link tracking
Link tracking counts clicks by rewriting the links in an email so they pass through a redirect first. The reader clicks, the redirect records the click, and the browser carries on to the real destination. Serving that redirect from a hostname on your own domain keeps the link recognizable to a reader and keeps the reputation of the domain in your hands.
In Rasket: Click tracking is per domain and off by default, rewrites only the HTML part, and redirects only to the address stored when the message was assembled. Tracking
List-Unsubscribe is a header that puts an unsubscribe control in the mail client itself, beside the sender's name. RFC 8058 adds the one-click form: the client posts to the address in the header and the reader is out, with no page to load and no account to find. Large mailbox providers require it on bulk mail, and it is far better for you than a spam complaint.
In Rasket: Broadcasts carry both headers and a hosted preference page, and a footer with an unsubscribe link is added to any part that does not already have one. Broadcasts
MX record
An MX record is the DNS record naming the servers that accept mail for a domain, each with a priority number, where lower numbers are tried first. Without one a domain can send mail but cannot receive it. Changing the record at the root of a domain moves every address at once, which makes it a decision rather than a setting.
In Rasket: Receiving takes one MX record, published at the inbound label by default, or at the root of the domain when every address there should reach us. Receiving
Open tracking
Open tracking counts opens by putting a tiny invisible image in the message and watching for it to load. It is the weakest number in email. Many clients block images, and others fetch them through a proxy before anyone has read a word, so an open can be recorded that never happened and a real read can go unseen. Treat it as a trend.
In Rasket: Open tracking is per domain and off by default, capped per message, and the user agent is recorded exactly as it arrives so you can judge the proxies yourself. Tracking
Rate limit
A rate limit is the ceiling on how fast an API will accept requests. It protects the service from one noisy caller and protects you from a runaway loop. A good one tells you where you stand on every response and how long to wait when it refuses, so a client can slow down before it is turned away rather than after.
In Rasket: The limit is per team and shared by every key on it, every response carries the headers, and a refusal says how many seconds to wait. Rate limits
Segment
A segment is a named group of contacts described by a rule rather than listed by hand: everyone who signed up this month, everyone on a particular plan, everyone who has not opened anything in a year. Because it is a rule, the membership is worked out when you ask for it, so a segment cannot quietly go stale.
In Rasket: Segments are filters over contact properties and topic subscriptions, and the membership is resolved when a broadcast is sent. Broadcasts
Sending domain
A sending domain is the domain in the From address of the mail you send, and it carries the reputation. Receiving servers judge mail by the domain it claims, so every message builds that reputation or spends it. Many senders keep marketing and transactional mail on separate subdomains, so a bad campaign cannot take the password resets down with it.
In Rasket: Add a domain, publish the record set you are handed, and send from any address at it once verification passes. Domains
Shared IP pool
A shared pool is a set of sending addresses used by many senders at once. Its reputation is collective, and keeping it in good standing is the operator's job. For most volumes that is the right default: the pool is already warm, while a small sender on an address of its own would never send enough for receiving servers to form a view.
In Rasket: Every plan sends from managed shared pools, and a dedicated IP is an add-on for senders large enough to need one. Pricing
SPF
SPF is a TXT record listing which servers may send mail for a domain. A receiving server looks up the record for the return path domain and checks whether the machine that connected is on the list. It breaks when a message is forwarded, because the forwarding server is not on your list, and that is why SPF on its own is not enough.
In Rasket: The SPF record for your return path is part of the record set we generate, and verification keeps watching it. Domains
Suppression list
A suppression list is the set of addresses you must not send to: hard bounces, spam complaints, and anyone who has unsubscribed. Checking it before every send is what stops a dead address being retried until it costs you your reputation. The list is also evidence, because it is the record that an unsubscribe was honored.
In Rasket: Suppressions are per team, written automatically on permanent bounces and complaints, checked before every send, and editable over the API. Suppressions reference
Template
A template is the content of an email kept apart from the code that sends it: a subject, a body, and named holes for the values that change. Copy can then be edited without a deploy, and every message of a kind looks the same. Versions matter, because sooner or later you will need to know which wording actually went out.
In Rasket: Templates are versioned, only a published version is ever sent, variables are declared with types, and each email records the exact version it used. Templates
Topic
A topic is a category a reader can subscribe to on its own: product news, billing notices, a weekly digest. Topics turn unsubscribe from a single switch into a choice, which keeps people on your list who only wanted to leave one conversation. They are also what a preference page is built from, without asking a reader to explain themselves.
In Rasket: A contact holds a subscription for each topic, and your public topics are listed on the hosted preference page. Broadcasts
Transactional email vs marketing email
Transactional mail goes to one person because of something they just did: a receipt, a password reset, a shipping notice. Marketing mail goes to a list because you decided to write. The difference matters legally and practically. Marketing mail needs consent, an unsubscribe and a postal address, and it should never share a reputation with a password reset.
In Rasket: Both run through the same sending pipeline, and an unsubscribe stops broadcasts to that address while transactional mail still goes out. Broadcasts
Webhook
A webhook is an HTTP request the service makes to you when something happens, instead of you asking over and over whether anything has. You register a URL, choose the event types you care about, and answer quickly with a success status. Retries are the part that matters: an endpoint that is briefly down should not lose the events it missed.
In Rasket: Endpoints subscribe to the event types they want, every delivery records its attempts, and a failure is retried with a growing delay for about a day. Webhooks
Webhook signature
A webhook signature proves a request really came from the service and not from somebody who found your URL. The sender computes a keyed hash over the exact bytes it is about to send, using a secret only the two of you hold, and puts it in a header. You compute the same hash and compare. Check the timestamp too, or a captured request can be replayed at you.
In Rasket: Every delivery carries svix-id, svix-timestamp and svix-signature headers, and a published helper verifies them for you. Webhooks
Ready to put the words to work?
Sign up, verify a domain and send your first email in minutes.