The Technical Glossary

BIMI functions on top of SPF, DKIM, and strict DMARC enforcement. When an email passes all security checks, supporting email clients (like Gmail, Apple Mail, and Yahoo Mail) fetch your official SVG logo and display it in place of a generic initial avatar.

For full BIMI verification in Gmail, organizations must also secure a Verified Mark Certificate (VMC) from an authorized certificate authority (such as DigiCert or Entrust), proving legal trademark ownership of the logo.

The specification uses DNS TXT records to publish the URI of the logo SVG Tiny PS file and the cryptographic certificate, allowing mail servers to validate authenticity in real time.

Enacted in 2003 and enforced by the FTC (16 CFR Part 316), CAN-SPAM sets legal ground rules for commercial outreach. Core requirements include: no deceptive header or routing info, no misleading subject lines, inclusion of a valid physical postal address, clear identification of the message as commercial, and honoring opt-outs within 10 business days.

The Federal Trade Commission (FTC) enforces penalties of up to $50,120 per non-compliant email send.

Unlike opt-in frameworks, CAN-SPAM allows unsolicited commercial email to be sent without prior consent, provided that strict disclosure and opt-out rules are observed.

Unlike the opt-out model of the US CAN-SPAM Act, CASL operates primarily on an opt-in basis. For B2B outbound, senders can leverage "Implied Consent" only if the contact's business email was conspicuously published without a statement declining unsolicited messages and the email directly relates to the recipient's business role.

The Canadian Radio-television and Telecommunications Commission (CRTC) strictly investigates non-compliant commercial email operations.

CASL mandates that every message contain clear identification of the sender, postal contact details, and an operational unsubscribe mechanism functioning for at least 60 days.

Professional cold email infrastructure consists of purchasing secondary lookalike domains, setting up Google Workspace or Microsoft 365 tenants, configuring SPF, DKIM, DMARC, and MX records, connecting custom tracking domains, and routing sends through distributed inbox rotation networks.

By segregating cold outreach traffic from your primary corporate email domain (e.g. using `trycompany.com` or `getcompany.io`), you insulate your core domain from spam reputation damage.

Infrastructure monitoring includes tracking Google Postmaster Tools reputation metrics, checking DNSBL blocklists daily, and balancing warm-up traffic across all active inboxes.

By default, email sending platforms use shared tracking domains to record opens and clicks. If another user of that shared domain sends spam, spam filters flag that tracking URL across all users.

Configuring a CTD (e.g., `track.yourdomain.com` pointing to the provider's tracking server) ensures your tracking URLs carry your own isolated reputation.

Modern security gateways check whether tracking domain CNAME records match the sending domain in the From: header to ensure reputation alignment.

When an email client renders an HTML message with click tracking enabled, the anchor `href` points directly to the custom subdomain (e.g. `https://track.yourdomain.com/c/12345`). The proxy server logs the recipient IP, user-agent, and timestamp before issuing an HTTP 302 redirect to the destination URL. If the CNAME record points to an unauthenticated third-party endpoint without SSL encryption, modern browsers and mail clients flag the redirect chain as suspicious.

With a Dedicated IP, your deliverability, sender score, and blacklisting risk depend 100% on your own sending practices. No other sender on the network can damage your reputation.

Dedicated IPs require a careful initial warm-up period and consistent sending volume (typically 50,000+ emails/month) to maintain high ISP trust scores.

If sending volume is low or erratic, ISPs cannot establish a stable reputation profile, which can lead to aggressive throttling or spam folder routing.

DKIM uses public-key cryptography. When an email is sent, the mail server creates a digital signature in the email header using a private key.

The receiving server fetches the corresponding public key from the sender's DNS TXT records to verify the signature. If the signature matches, it confirms integrity and sender authenticity.

The DKIM header contains the selector tag (`s=`), the signing domain (`d=`), the canonicalization algorithm (`c=`), and the cryptographic signature data (`b=` and `bh=`).

DMARC specifies three enforcement policies: `p=none` (monitor and generate reports), `p=quarantine` (deliver authentication failures to spam), and `p=reject` (block unauthorized emails entirely).

It also provides XML reporting (`rua` and `ruf` tags) detailing who is sending email on behalf of your domain globally.

For DMARC to pass, an email must pass either SPF or DKIM, and the authenticated domain must align with the visible domain shown in the recipient's From: header.

In cold outbound, Google Workspace and Microsoft 365 are considered premium ESPs because their inboxes route through high-reputation consumer and enterprise IP pools, achieving higher inbox placement than bulk marketing ESPs.

Marketing ESPs (like Mailchimp, SendGrid, or Klaviyo) are optimized for opt-in bulk newsletters and strictly prohibit unsolicited cold outreach in their Terms of Service.

Choosing the right ESP architecture ensures your outbound emails authenticate via native corporate infrastructure rather than third-party bulk relays.

When an FBL notification is received, high-quality sending platforms automatically suppress the complaining email address from future sends to prevent further reputation damage.

ISPs provide FBL data in the Abuse Reporting Format (ARF), containing the original email headers, sender IP, and timestamp of the complaint.

Note that Gmail does not offer traditional ARF feedback loops for individual senders; instead, Gmail provides aggregate complaint statistics via Google Postmaster Tools.

For B2B cold outreach in the EU, GDPR permits sending under the legal basis of "Legitimate Interest" (Article 6(1)(f)), provided the sender conducts a legitimate interest assessment (LIA), ensures direct relevance to the recipient's professional role, and includes a seamless opt-out mechanism.

Senders must respect the fundamental rights and freedoms of data subjects, ensuring that personal data is processed transparently and stored securely.

Under GDPR, data subjects have the "Right to Object" and the "Right to be Forgotten" (Article 17), requiring senders to permanently purge contact data upon request.

Unlike legacy POP3 (which downloads and removes messages from the server), IMAP maintains continuous two-way state synchronization between the mail server and all connected clients.

In cold outreach, automation platforms use IMAP connections (or OAuth API tokens) to listen to connected mailboxes in real time, inspecting incoming `In-Reply-To` and `References` RFC headers to detect prospect replies, soft bounces, and unsubscribe requests instantly.

Proper IMAP configuration ensures that when an SDR replies to a prospect from their mobile phone or desktop client, the sending tool immediately registers the interaction and updates CRM deal stages.

In scalable cold email setups, multiple mailboxes are created across secondary domains and connected to an automated sequencer for inbox rotation.

Each mailbox has dedicated daily volume caps (30–40 emails/day), custom signature settings, and automated warm-up protocols to preserve sending health.

Distributing outreach across dozens of distinct mailboxes prevents account suspension and maintains optimal primary inbox delivery rates.

Enterprise mailbox management requires configuring authentic MX records, SPF include tags, custom DKIM keys, and DMARC enforcement across every secondary domain. Connecting mailboxes to sequencers via modern OAuth 2.0 API integrations ensures seamless token refresh and prevents password-reset synchronization failures that disrupt live sending cadences.

When an email is sent to `user@yourdomain.com`, the sending server queries DNS for the MX records of `yourdomain.com` to determine where to route the SMTP connection.

MX records include a priority number (e.g., 10, 20) directing servers to try primary and fallback mail servers in order.

In cold outreach, secondary sending domains must have valid MX records pointing to their Google Workspace or Microsoft 365 tenant so they can receive incoming prospect replies and bounce notifications.

Attackers utilize lookalike domains (typosquatting), spoofed From: headers, and fake corporate logos to trick users. In response, modern email security gateways (like Proofpoint, Mimecast, and Microsoft Defender) deploy aggressive heuristic filters that analyze newly registered domains, unauthenticated headers, and suspicious body keywords.

Because modern anti-phishing algorithms inspect all incoming mail, legitimate cold emailers must implement rigorous cryptographic authentication (SPF, DKIM, and DMARC) and avoid any language or URL redirects that mimic phishing patterns.

DMARC enforcement at `p=reject` provides the ultimate defense against domain impersonation by instructing receiving mail servers to automatically drop unauthorized messages claiming to originate from the protected domain.

Outreach platforms monitor connected mailboxes via IMAP or Google/Microsoft Graph APIs, matching incoming message headers (`In-Reply-To`, `References`, and `Message-ID`) against original outbound campaigns.

Modern reply tracking engines deploy NLP sentiment analysis to categorize incoming replies into Positive (interested in demo), Objection, Out of Office (OOO), or Unsubscribe requests.

Positive replies automatically trigger CRM deal creation and send instant Slack notifications to the assigned Account Executive for rapid response.

When sending through Google Workspace or Microsoft 365, your messages travel over massive shared IP pools shared with millions of legitimate enterprise users.

This shared volume establishes high trust with receiving mail filters because the IP reputation is anchored by billions of authentic day-to-day business communications.

However, on shared bulk SMTP providers (like low-cost marketing relays), a bad actor sending spam on the same shared IP can temporarily degrade deliverability for all other users on that IP.

SMTP establishes a connection between the sending client and receiving mail transfer agent (MTA) over specific network ports: Port 587 (authenticated client submission with STARTTLS encryption), Port 465 (SMTPS SSL/TLS encryption), and Port 25 (server-to-server relay).

The protocol executes a command-response conversation: `EHLO` (client greeting), `MAIL FROM` (envelope sender), `RCPT TO` (recipient address), `DATA` (message payload), and `QUIT`.

Modern security gateways inspect the SMTP handshake in real time, checking reverse DNS (PTR) records, TLS cipher strength, and envelope authentication before accepting the message payload.

When a receiving mail server receives a message, it inspects the sender's envelope Return-Path domain, queries DNS for that domain's SPF record, and checks whether the transmitting IP address is listed in the authorized mechanisms (e.g. `ip4:`, `include:`, `a`, `mx`).

The SPF specification (RFC 7208) enforces a strict **10 DNS lookup limit**—if your SPF record requires more than 10 nested DNS queries, receiving servers throw a `PermError` and fail authentication.

A domain must have **exactly one SPF TXT record**; publishing multiple SPF records on a single domain invalidates all of them, causing immediate deliverability failure.