Skip to content

Glossary of terms

Short explanations of terms you’ll see in Mailexam documentation, in engineering conversations, and when configuring mail. Written for junior developers and managers — without diving into RFCs or cryptography.

SMTP

SMTP (Simple Mail Transfer Protocol) is the standard protocol for sending email on the internet. Your application uses SMTP to hand a message to a mail server; from there, servers relay it to the recipient — or, in a test environment, capture it in a sandbox.

Simple analogy

Think of a post office counter:

Real mail In IT
You bring an envelope to the desk The app builds the message (subject, body, attachments)
Staff accepts the item The app connects to an SMTP server
Mail is sorted and forwarded The SMTP server passes the message to the next hop

Without SMTP (or an equivalent), the app can only prepare a message — not send it.

What people usually configure

SMTP setup needs a host, port, login, and password. Common ports:

Port Meaning (simplified)
587 Recommended: sending with encryption (STARTTLS)
465 Sending over an encrypted connection from the start (SMTPS)
25 Classic port; often blocked by hosting and corporate networks
2525 Alternative when port 25 is blocked

With Mailexam, you point the app at a test SMTP host ({login}.mailexam.io). Messages land in your project dashboard, not in real inboxes. Step-by-step setup: integration examples.

For managers

“Configure SMTP” in a ticket usually means: provide developers with host, port, login, and password so the app can send mail. For Mailexam, those credentials are issued when a project is created.

Sandbox

In email, a sandbox is an isolated test environment where messages go instead of real recipients. This is not a browser sandbox or a Docker sandbox — it specifically means safe email debugging.

Why a sandbox exists

Without a sandbox With a sandbox (Mailexam, etc.)
A test email might reach a customer or random address Only your team sees it in a test inbox
Risk of leaking tokens, passwords, or personal data You can run production-like flows without spamming people
Hard to automate checks in CI/CD API and a single place for all test messages

Sandbox ≠ production

  • In production, SMTP points to SendGrid, Amazon SES, corporate Exchange, etc. — mail is delivered to recipients.
  • In a sandbox, you often keep the same sending code and only swap SMTP credentials (host, login, password) for test values.

Mailexam is a cloud sandbox for teams: development, QA, CI/CD pipelines. Messages are not delivered to real internet mailboxes — they are stored in your project and available in the browser and via the API.

SPF

SPF (Sender Policy Framework) is a DNS mechanism that lists which servers are allowed to send mail for your domain (for example, company.com). The receiving mail server checks the sender’s IP address against the domain’s SPF TXT record.

Simple analogy

Like a list of approved courier companies at a building entrance: mail carrying your brand is trusted more when it comes from a server on the approved list, not from a random host on the internet.

How it works (high level)

  1. A TXT record such as v=spf1 include:... -all is added to the domain’s DNS — allowed hosts and a policy for everyone else.
  2. When a message arrives, the receiving server checks whether the sending IP matches that record.
  3. On failure, the message is often marked suspicious, sent to spam, or rejected.

SPF works alongside DKIM and DMARC: SPF answers “who may send from this IP,” DKIM signs the message, DMARC defines what to do when checks fail.

Do you need SPF for Mailexam?

Usually no. Mailexam catches test mail in the sandbox; SPF checks at real recipients do not affect delivery to your dashboard. SPF (like DKIM and DMARC) matters when you run production sending from your own domain. Check your record with the SPF tool on the website.

For managers

If a migration ticket asks “do we need to change SPF or DNS” for a sandbox — for Mailexam and similar services the answer is no: only SMTP credentials change; sender-domain DNS records are not required. SPF comes later with production SMTP.

DKIM

DKIM (DomainKeys Identified Mail) is a way to cryptographically sign outbound mail for a domain (for example, company.com). The receiving server verifies the signature and decides whether to trust the message.

Simple analogy

Like a seal on an official document: the sender proves the message is tied to the claimed domain, not forged by an attacker.

How it works (high level)

  1. A TXT record with a public key is added to the domain’s DNS.
  2. The sending mail server signs each message.
  3. The receiving server verifies the signature. Failures often mean spam folder or rejection.

DKIM is often used together with SPF and DMARC to improve deliverability and protect your brand from phishing “from your domain.”

Do you need DKIM for Mailexam?

Usually no. Mailexam is for test mail: messages are caught in the sandbox and do not reach real recipients on the internet. DKIM, SPF, and DMARC matter when you run production sending from your own domain (marketing, transactional mail, customer notifications). Verify the record or generate a key with the DKIM tool.

For managers

If a developer says “we don’t set up DKIM in the sandbox,” that’s expected: for checking templates, links, and send logic in Mailexam, domain signing is not required. DKIM comes later with production SMTP and DNS work.

DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) is a DNS policy that tells receivers what to do when SPF and/or DKIM checks fail, and where to send reports about those messages.

Simple analogy

SPF and DKIM are the badge check and seal at the door. DMARC is security’s instruction: “if the badge is fake — don’t let them in” or “put the item in a separate bin and notify the admin.”

How it works (high level)

  1. A _dmarc TXT record is added to the domain’s DNS with a policy (for example, p=none, p=quarantine, p=reject).
  2. The receiver compares SPF/DKIM results with the domain shown in From (with alignment rules).
  3. On failure, the policy applies: mail may still deliver, go to quarantine/spam, or be rejected. Aggregate reports may be sent to an address you specify (who is sending as your domain).

A typical rollout: start with p=none (monitoring only), then tighten to quarantine or reject once SPF and DKIM are stable.

Do you need DMARC for Mailexam?

Usually no. In the sandbox, messages do not go through production delivery with DMARC enforcement at real recipients. DMARC matters for production sending, when the domain is already protected by SPF and DKIM and you want a clear policy plus visibility into spoofing attempts. Check your policy with the DMARC tool.

For managers

DMARC does not replace SPF/DKIM — it sits on top of them. Turning on DMARC without working SPF/DKIM helps little. It is not a blocker for Mailexam in development; in production, the same person who manages corporate mail or your ESP (SendGrid, SES, etc.) usually owns it.

How the terms fit together

flowchart LR
    App[Your application] -->|SMTP| Sandbox[Test server<br/>Mailexam]
    Sandbox --> Inbox[Dashboard / API]
    Prod[Production SMTP] -->|SPF + DKIM + DMARC| Internet[Real recipients]
Term Typical role
SMTP How the app sends mail
Sandbox Where mail goes during development
SPF Who is allowed to send mail for your domain (by IP)
DKIM How you sign mail for your domain
DMARC What to do when SPF/DKIM fail, and where reports go