The email glossary every developer needs bookmarked

Email has been around since the 1970s and it shows. The terminology is a mess of acronyms, overlapping concepts, and specs written by committees. If you've ever stared at a bounce message wondering what "550 5.7.1" means, or googled "SPF vs DKIM" for the third time this year, this page is for you.

This is a reference. Bookmark it. Come back when you need it.

Authentication

SPF (Sender Policy Framework)

A DNS TXT record that lists which IP addresses and servers are allowed to send email on behalf of your domain. When a receiving server gets a message claiming to be from yourdomain.com, it checks the SPF record to see if the sending server is authorized.

The record lives on your root domain and looks like this:

v=spf1 include:sendkit.dev include:_spf.google.com ~all

Each include: directive authorizes a service's mail servers. The ~all at the end means "soft-fail anything not listed" (treat it as suspicious but don't reject). Use -all for a hard fail once you're confident everything is configured.

SPF has a hard limit of 10 DNS lookups. Exceed it and the entire record becomes invalid. This catches teams off guard when they use multiple SaaS tools that each add their own include: directives.

Related: How to set up SPF, DKIM, and DMARC

DKIM (DomainKeys Identified Mail)

A cryptographic signing mechanism. Your sending server signs each outgoing email with a private key. The receiving server looks up the corresponding public key in your DNS (published as a TXT record at selector._domainkey.yourdomain.com) and verifies the signature.

If the signature checks out, two things are confirmed: the message came from your infrastructure, and it wasn't modified in transit.

DKIM keys should be 2048-bit minimum. Some older setups still use 1024-bit keys, but receivers are starting to flag them as weak.

When you add a domain in Sendkit, DKIM keys are generated automatically and hosted via CNAME records. This lets Sendkit rotate keys on a schedule without you touching DNS.

DMARC (Domain-based Message Authentication, Reporting & Conformance)

The policy layer that ties SPF and DKIM together. A DMARC record tells receiving servers what to do when authentication fails, and where to send reports about authentication results.

v=DMARC1; p=none; rua=mailto:[email protected]

The p= parameter sets the policy:

• p=none -- monitor only, no action on failures. Start here.
• p=quarantine -- send failing messages to spam.
• p=reject -- bounce failing messages outright. This is the goal.

The rua= parameter tells receivers where to send aggregate reports (XML files showing what passed and failed). These reports are the only way to know if your authentication is working before you tighten the policy.

DMARC also checks alignment: the domain in the From: header must match the domain that passed SPF or DKIM. This is the part most people miss. A message can pass SPF but still fail DMARC if the domains don't align.

BIMI (Brand Indicators for Message Identification)

A DNS record that lets you display your brand logo next to your emails in supporting inboxes. Gmail, Apple Mail, and Yahoo support it. BIMI requires a valid DMARC policy of p=quarantine or p=reject and a Verified Mark Certificate (VMC) from a certificate authority.

It doesn't improve deliverability directly, but it does increase trust and recognition in the inbox.

ARC (Authenticated Received Chain)

A protocol that preserves authentication results when messages are forwarded. Mailing lists and forwarding services break SPF and sometimes DKIM. ARC adds headers at each hop so the final receiving server can trace the authentication chain back to the original sender.

If you run a forwarding service, adding ARC headers prevents your forwarded messages from failing DMARC at the destination.

DNS records

MX record (Mail Exchange)

Tells the world which servers accept email for your domain. When someone sends a message to [email protected], their mail server queries DNS for MX records to find where to deliver it.

MX records have a priority value. Lower numbers mean higher priority. If the primary server is down, the sender tries the next one.

yourdomain.com.  MX  10  mx1.sendkit.dev.
yourdomain.com.  MX  20  mx2.sendkit.dev.

No MX records means nobody can receive email at your domain. This is also what email validation checks -- if a domain has no MX records, any address at that domain is undeliverable.

TXT record

A generic DNS record type that holds text data. SPF, DKIM, and DMARC records are all stored as TXT records. The receiving server knows which is which by the prefix (v=spf1, v=DKIM1, v=DMARC1).

You can only have one SPF TXT record per domain. Two SPF records on the same domain make both invalid.

PTR record (Pointer)

The reverse of an A record. Instead of mapping a domain to an IP address, a PTR record maps an IP address back to a domain. Mail servers use reverse DNS lookups to verify that a sending IP has a valid PTR record matching the sending domain.

Missing or mismatched PTR records are a red flag for spam filters. If you're sending from a dedicated IP, make sure the PTR record is configured.

A record

Maps a domain name to an IPv4 address. While not email-specific, your domain's A record matters because some mail servers fall back to it when no MX records exist. An AAAA record is the same thing for IPv6.

CNAME record

An alias that points one domain to another. Sendkit uses CNAME records for DKIM so you don't have to paste raw public keys into TXT records. The CNAME points your sendkit._domainkey.yourdomain.com to Sendkit's DNS, where the actual key is hosted and rotated automatically.

Deliverability

Sender reputation

A trust score that mailbox providers (Gmail, Outlook, Yahoo) assign to your sending domain and IP address. It's based on bounce rates, spam complaints, engagement metrics, and whether you hit spam traps.

High reputation means your emails reach the inbox. Low reputation means spam folder or outright rejection. Once damaged, reputation takes weeks to rebuild.

Bounce rate

The percentage of sent emails that failed to deliver. There are two types:

• Hard bounce -- permanent failure. The address doesn't exist, the domain is invalid, or the server permanently rejected the message. Hard bounces hurt your sender reputation the most.
• Soft bounce -- temporary failure. The recipient's mailbox is full, the server is down, or the message is too large. Soft bounces usually resolve on retry.

Keep your bounce rate under 2%. Anything above 5% and you're in trouble with most providers.

Spam trap

An email address specifically designed to catch senders with bad list hygiene. There are two types:

• Pristine traps -- addresses that were never used by a real person. They exist only to catch scrapers and purchasers of email lists.
• Recycled traps -- old addresses that were abandoned, then repurposed by the provider as traps. Hitting these means you're not cleaning your list.

Sending to spam traps tanks your reputation fast. The only defense is proper email validation and regular list cleaning.

IP warming

The process of gradually increasing email volume from a new IP address or domain. ISPs are suspicious of new senders blasting high volume from day one. Warming builds trust by showing consistent, low-complaint sending behavior over weeks.

A typical warm-up schedule starts with a few hundred emails per day and doubles every few days until you reach your target volume. Skip this and you'll likely get throttled or blocked.

Suppression list

A list of email addresses you should never send to. This includes addresses that hard-bounced, filed spam complaints, or unsubscribed. Sendkit manages suppression lists automatically -- bounces and complaints are suppressed without you writing any code.

Ignoring suppression is one of the fastest ways to destroy deliverability.

Feedback loop (FBL)

A mechanism where ISPs notify senders when recipients mark their email as spam. When a user clicks "Report spam" in Gmail or Outlook, the ISP sends a report back to the sender (if they're registered for the FBL).

You should process these reports and immediately suppress the complaining address. Continuing to send to people who complained is a guaranteed way to damage your reputation.

SMTP and protocol

SMTP (Simple Mail Transfer Protocol)

The protocol used to send email between servers. It's been around since 1982 (RFC 821, updated by RFC 5321). SMTP uses a series of text commands (HELO, MAIL FROM, RCPT TO, DATA) to transfer messages.

Modern SMTP uses TLS encryption. Port 587 with STARTTLS is the standard for submission. Port 465 uses implicit TLS. Port 25 is for server-to-server relay and is often blocked by ISPs for consumer connections.

Sendkit's SMTP relay accepts connections on ports 587 and 465 and works as a drop-in replacement for any SMTP provider.

Envelope sender (Return-Path)

The email address used during the SMTP handshake (the MAIL FROM command). This is different from the From: header that the recipient sees. Bounce notifications go to the envelope sender address, which is why it's also called the return-path or bounce address.

The distinction matters for DMARC alignment. SPF checks the envelope sender domain, not the From: header domain.

SMTP handshake

The back-and-forth conversation between two mail servers when delivering a message:

1. EHLO/HELO -- the sending server identifies itself.
2. MAIL FROM -- specifies the envelope sender.
3. RCPT TO -- specifies the recipient.
4. DATA -- the actual message content (headers + body).
5. QUIT -- closes the connection.

Email validation services perform a partial handshake (up to RCPT TO) to check if a mailbox exists without actually sending a message.

TLS (Transport Layer Security)

Encryption for data in transit. When two mail servers communicate over TLS, the message content is encrypted between them. This doesn't mean the message is encrypted end-to-end (the servers themselves can still read it), but it prevents eavesdropping on the wire.

STARTTLS upgrades an existing plain-text connection to encrypted. Implicit TLS (port 465) starts encrypted from the beginning.

MIME (Multipurpose Internet Mail Extensions)

The standard that lets email carry more than plain text. MIME defines how to encode attachments, HTML content, inline images, and character sets. When you send an email with both HTML and plain text versions, MIME handles the multipart structure.

Message anatomy

From header

The email address displayed to the recipient. This is what people see in their inbox. It's set by the sender and can technically be anything, which is exactly why SPF, DKIM, and DMARC exist -- to verify it's legitimate.

Reply-To header

An optional header that tells email clients where to send replies. If not set, replies go to the From: address. Useful when you send from [email protected] but want replies to go to [email protected].

Message-ID

A unique identifier assigned to every email. It looks like <[email protected]>. Message-IDs are used for threading conversations and for tracking delivery status across systems.

Email headers

Metadata attached to every email message. Headers include routing information (Received), authentication results (Authentication-Results), content type (Content-Type), and more. When debugging deliverability issues, the raw headers are the first place to look.

Most email clients let you view raw headers. Look for Authentication-Results to check SPF, DKIM, and DMARC status.

Sending concepts

Transactional email

Messages triggered by a user action: password resets, order confirmations, login codes, invoice receipts. These are expected by the recipient and typically have high open rates. They need to arrive fast and reliably.

Sendkit's email API is built for transactional email -- send via REST API or SMTP with delivery tracked through webhooks.

Marketing email (bulk email)

Messages sent to a list of subscribers: newsletters, promotions, product announcements. Unlike transactional email, recipients didn't explicitly request each individual message. Marketing email requires proper consent (opt-in) and must include an unsubscribe link.

Webhook

An HTTP callback that notifies your application when something happens. In the email context, webhooks tell you when a message is delivered, opened, clicked, bounced, or marked as spam. Instead of polling an API for status, the email provider pushes events to your endpoint in real time.

Email validation

The process of checking whether an email address is deliverable before sending to it. A proper validation stack includes syntax checks, DNS/MX lookups, disposable email detection, and SMTP mailbox verification.

Sendkit's email validation API runs all these checks in a single request. Validating at the point of collection prevents bad addresses from entering your database in the first place.

Related: How to validate email addresses before sending

Dedicated IP vs shared IP

A shared IP is used by multiple senders on the same email provider. Your reputation is partially influenced by the behavior of other senders on that IP. Good for low-volume senders.

A dedicated IP is assigned exclusively to you. Your reputation is entirely your own. Better for high-volume senders (100K+ emails/month) who maintain clean lists. Requires IP warming before use.

Compliance

CAN-SPAM

US law governing commercial email. Requirements: include your physical address, provide a clear unsubscribe mechanism, honor opt-out requests within 10 business days, don't use deceptive subject lines. Applies to marketing email, not transactional.

GDPR (General Data Protection Regulation)

EU regulation that governs how personal data (including email addresses) is collected, stored, and processed. Requires explicit consent for marketing email, the right to be forgotten, and data portability. Violations carry fines up to 4% of global revenue.

LGPD (Lei Geral de Protecao de Dados)

Brazil's data protection law, similar to GDPR. Requires a legal basis for processing personal data, consent for marketing communications, and gives individuals the right to access and delete their data.

Opt-in / double opt-in

Single opt-in means a user provides their email address and is immediately added to your list. Double opt-in (confirmed opt-in) sends a confirmation email first -- the user must click a link to verify their address before they're added.

Double opt-in produces cleaner lists and protects against typos and fake signups. It's required by law in some jurisdictions (Germany, for example) and strongly recommended everywhere else.

Common status codes

When an email fails to deliver, the bounce message includes an SMTP status code. Here are the ones you'll see most:

• 250 -- success. The message was accepted.
• 421 -- service not available. Try again later (temporary).
• 450 -- mailbox unavailable. Usually temporary (mailbox full, server busy).
• 451 -- local error in processing. Try again later.
• 452 -- insufficient storage. The server ran out of space.
• 550 -- mailbox not found. The address doesn't exist (hard bounce).
• 551 -- user not local. The server doesn't handle mail for this address.
• 552 -- message too large. Reduce attachment size or content.
• 553 -- mailbox name not allowed. Usually a syntax issue.
• 554 -- transaction failed. Catch-all rejection, often spam-related.

The three-digit code is sometimes followed by an enhanced status code like 5.7.1 (delivery not authorized) which gives more specific context.

Wrapping up

Email terminology is scattered across decades of RFCs, provider documentation, and tribal knowledge. This glossary covers the terms you'll actually encounter when setting up email infrastructure, debugging deliverability, or building applications that send mail.

If something is missing, it probably deserves its own article. Check the Sendkit blog for deep dives on specific topics, or the documentation for implementation details.