Plain definitions of the words that turn up in email infrastructure: DKIM, SPF, DMARC, bounces, complaints, suppressions, idempotency, webhooks and more.
Authentication
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.
Read more about API keyAuthentication
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.
Read more about ARCMarketing email
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.
Read more about AutomationBrand and authentication
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.
Read more about BIMIDelivery
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.
Read more about BounceMarketing email
A campaign, also called 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 campaign 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.
Read more about CampaignDeliverability
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.
Read more about ComplaintAudience
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.
Read more about ContactDomain authentication
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.
Read more about Custom return pathInfrastructure
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.
Read more about Dedicated IPDelivery
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.
Read more about Delivery eventDomain authentication
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.
Read more about DKIMDomain authentication
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.
Read more about DMARCDomain authentication
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.
Read more about DMARC alignmentDNS
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.
Read more about DNS propagationDomain authentication
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.
Read more about Domain verificationConsent
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.
Read more about Double opt-inInterfaces
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.
Read more about Email APIDeliverability
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.
Read more about Email deliverabilityDelivery
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.
Read more about GreylistingSecurity
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.
Read more about HMACAPI behaviour
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.
Read more about Idempotency keyInterfaces
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.
Read more about Inbound emailInfrastructure
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.
Read more about IP warmingTracking
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.
Read more about Link trackingConsent
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.
Read more about List-UnsubscribeMessage format
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.
Read more about Message-IDMessage format
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.
Read more about MIMEInfrastructure
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.
Read more about MTATransport security
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.
Read more about MTA-STSDNS
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.
Read more about MX recordTracking
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.
Read more about Open trackingDNS
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.
Read more about PTR recordAPI behaviour
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.
Read more about Rate limitAudience
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.
Read more about SegmentDeliverability
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.
Read more about Sender reputationDomain authentication
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.
Read more about Sending domainInfrastructure
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.
Read more about Shared IP poolProtocols
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.
Read more about SMTPDeliverability
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.
Read more about Spam complaint rateDeliverability
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.
Read more about Spam trapDomain authentication
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.
Read more about SPFTransport security
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.
Read more about STARTTLSDeliverability
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.
Read more about Suppression listSending
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.
Read more about TemplateTransport security
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.
Read more about TLS-RPTConsent
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.
Read more about TopicSending
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.
Read more about Transactional vs marketingInterfaces
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.
Read more about WebhookSecurity
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.
Read more about Webhook signatureSign up, verify a domain and send your first email in minutes.