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
ARC is a way for a mail server that modifies a message in transit to record what authentication result it saw before the change. A mailing list that rewrites a subject line breaks the original DKIM signature; ARC lets the list state, under its own signature, that the message did pass when it arrived. A receiving server can then choose to trust that record.
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
BIMI is a way to have your logo shown beside your messages in a supporting mail client. You publish a record in DNS pointing at a logo file in a particular SVG profile, and the client displays it only for mail that already passes DMARC at an enforcing policy. Several providers also require a certificate attesting that the mark is yours.
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
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
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
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
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
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
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 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 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
Alignment is the part of DMARC that asks whether the domain that passed authentication is the same one the reader sees. A DKIM signature or an SPF check can pass for a domain that has nothing to do with the From header, and on its own that proves nothing. Alignment closes that gap by requiring the two to match, strictly or at the organisational level.
In Rasket: A verified domain signs with a key on that domain and uses a return path on a subdomain of it, so both DMARC paths align without extra configuration. Domains
Propagation is the delay between publishing a DNS record and the rest of the internet seeing it. Nothing is actually pushed anywhere: resolvers cache the previous answer for as long as its time to live allows, and only ask again when that expires. The old value therefore lingers for up to one TTL, which is why a correct record can look broken for hours.
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
Double opt-in is asking somebody to confirm a subscription by clicking a link in an email before you add them to a list. The first step is the form they filled in; the second proves the address exists and belongs to the person who typed it. It costs you some signups and buys you a list that bounces less and complains less.
An email API is an HTTP interface for sending and receiving mail from your own code. You post a message as JSON, authenticate with a key, and get an identifier back. Everything a mail server would make you manage — connections, retries, authentication records, bounce parsing — is handled behind the call, and the results come back as events rather than as mail you have to read.
In Rasket: Rasket is an email API for developers: one REST call sends transactional email or a broadcast, and the same account receives mail at your own domain. Email API
Deliverability is whether your mail reaches the inbox rather than the spam folder or nowhere at all. It is not one setting. It is the combined result of authentication, the reputation of your domain and sending address, how people react to your mail, and how clean your list is. Every part of it is earned over time and can be lost in a single campaign.
Greylisting is a filtering technique where a receiving server temporarily refuses a message from an unfamiliar sender and waits to see whether it is tried again. A real mail server retries; much bulk software does not. The message is accepted on the second attempt, so the only cost to a legitimate sender is a delay of minutes, and the sender is usually remembered afterwards.
HMAC is a way to prove a message came from someone holding a shared secret, and that nobody changed it on the way. A hash function is combined with the secret in a defined order to produce a short tag sent alongside the message. The receiver computes the same tag and compares. It is the mechanism behind almost every webhook signature you will meet.
In Rasket: Webhook deliveries are signed with a per-endpoint secret, and a published helper package verifies the signature and the timestamp for you. Webhooks
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
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
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 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
The Message-ID is a globally unique identifier a sending system puts on every message, written as a local part and a domain inside angle brackets. Replies quote it in their In-Reply-To and References headers, which is how mail clients build a thread. It is also the handle support teams use to trace one specific message through logs on both sides.
MIME is the set of rules that lets an email carry more than plain ASCII text: HTML, attachments, images, and characters outside the original alphabet. It defines the headers that declare a part's type and encoding, and the multipart structure that nests parts inside one another. Every modern message is a MIME document, whether or not anybody writing it ever thinks so.
An MTA is a program that moves email between servers. It accepts a message, decides where it should go next by looking up the recipient domain's MX record, opens a connection to that host and hands the message over. Queueing, retries and bounce notices are its responsibility. When people talk about running their own mail server, this is usually the part they mean.
MTA-STS lets a domain declare that mail sent to it must arrive over TLS, to a named set of hosts. The policy is published as a file on an HTTPS host and announced by a TXT record in DNS. A sending server that supports it fetches and caches the policy, then refuses to deliver over an unencrypted or mismatched connection rather than falling back.
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 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
A PTR record maps an IP address back to a hostname, which is the reverse of an ordinary lookup. Receiving mail servers check it on the connecting address, and many refuse or penalise mail from an address with no reverse name, or one whose forward lookup does not return to the same address. It is configured by whoever owns the address block.
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
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
Sender reputation is a receiving organisation's running opinion of your mail, kept against your sending domain and the address you send from. It is built from how often your messages bounce, how often readers complain, how they engage, and whether your mail authenticates. Nobody publishes the formula, every provider keeps its own, and it changes with every campaign you send.
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
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
SMTP is the protocol mail servers use to hand messages to one another. It is a conversation of short commands and numeric replies: who the message is from, who it is for, then the message itself. Almost everything else in email — authentication, encryption, bounce handling — is either an extension to it or a reaction to what it does not do.
In Rasket: Rasket sends over an HTTPS API rather than asking you to open an SMTP connection, and the reply the receiving server gave still reaches you as a delivery or bounce event. Email API
The complaint rate is the share of your delivered messages that readers marked as spam, measured per mailbox provider rather than across your whole audience. It is the number providers watch most closely, because it is the most direct statement their own users can make about your mail. A rising rate costs you the inbox long before anyone tells you.
In Rasket: The metrics endpoint reports a complaint rate alongside deliveries and bounces, so the number can be watched from your own dashboards. Metrics reference
A spam trap is an address that exists only to catch senders who mail people who never asked. Some are addresses created purely as bait; others are abandoned mailboxes that a provider has repurposed after years of inactivity. Mail to one is strong evidence that a list was bought, scraped or never cleaned, and the penalty is applied to the sender.
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
STARTTLS is the SMTP command that upgrades a plain connection to an encrypted one. The receiving server advertises support, the sender asks to upgrade, and the rest of the session runs over TLS. Because the offer travels in the clear and the fallback is to continue unencrypted, an attacker in the path can strip it, which is the problem MTA-STS was designed to solve.
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
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
TLS-RPT is a way for a domain to ask other mail servers to report how their encrypted connections to it went. You publish a TXT record naming an address to send reports to, and senders that support it post a daily summary of successful and failed sessions. It is the feedback channel that makes MTA-STS and DANE deployable without guessing.
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 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
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
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