Email deliverability, answered straight.

Delivery means the receiving server accepted the message; placement is where it then lands: inbox, promotions, or spam. A message can be "delivered" and still go to spam. Placement is decided by sender reputation, authentication, engagement, and content, not by acceptance alone.

Since February 2024, bulk senders to Gmail and Yahoo must authenticate with SPF and DKIM, publish a DMARC policy (at least p=none) with alignment, send from a domain with valid forward and reverse DNS over TLS, keep spam complaints low, and offer one-click unsubscribe (RFC 8058). Gmail defines "bulk" as roughly 5,000 or more messages a day to Gmail accounts and asks senders to stay below a 0.30% spam rate, ideally under 0.10%. Yahoo publishes no volume threshold but applies the same kind of rules, and Microsoft has announced similar requirements for high-volume Outlook.com senders.

A DMARC record is now expected of bulk senders; p=none is enough to meet the baseline, but it offers no protection against spoofing. p=reject is the strongest policy and is appropriate only when every sending source for the domain is authenticated and aligned, with no unmanaged intermediaries breaking alignment. The current standard (RFC 9989) also makes clear that receivers should not reject on p=reject alone, and discourages p=reject for domains whose users post to mailing lists.

Yes. The original DMARC spec, RFC 7489, is now obsolete. DMARC is defined by three Standards-Track RFCs: 9989 (core), 9990 (aggregate reporting), and 9991 (failure reporting). The version tag is still v=DMARC1 and existing records keep working, but the pct, rf, and ri tags are removed, np, psd, and t are added, and the Public Suffix List is replaced by a DNS "Tree Walk" capped at 8 lookups.

The most common cause is the 10 DNS-lookup limit in RFC 7208: every include, a, mx, ptr, and exists mechanism counts, and exceeding ten produces a permerror that fails SPF. SPF also breaks on forwarding, because the forwarding server is not in your record. This is why DKIM (which survives forwarding) and DMARC alignment matter as much as SPF.

Either, not both. A message passes DMARC when SPF passes and is aligned, OR DKIM passes and is aligned. This is the single most misunderstood point in email authentication. Because DKIM survives forwarding and SPF often does not, a valid aligned DKIM signature is the more durable path.

Gmail asks senders to stay below 0.30% and ideally under 0.10%, measured in Postmaster Tools. Yahoo targets under 0.3%, measured against inbox-delivered mail. Most other providers do not publish a number, but the same discipline applies: complaints near a few tenths of a percent damage placement for everything you send, so suppress complainers immediately via feedback loops.

One-click unsubscribe (RFC 8058) lets a recipient unsubscribe directly from their mail client without visiting a page. It requires the List-Unsubscribe and List-Unsubscribe-Post headers, an HTTPS endpoint that accepts a context-free POST, and a DKIM signature covering those headers. It is mandatory for bulk senders under the Gmail and Yahoo requirements, and the unsubscribe must be honored quickly (Yahoo specifies within two days).

Reputation is not only about the IP. URI blocklists (SURBL, URIBL) and Spamhaus DBL list domains found in the message body, so a clean sending IP can still be filtered because of a listed link, redirect, or tracking domain. Domain reputation increasingly dominates IP reputation, which is why changing IPs rarely fixes a content or domain problem.

Only if you send steady, meaningful volume. A dedicated IP reflects only your behavior, but it needs warming and consistent volume to build and hold reputation. Low or spiky senders are usually better on a well-run shared pool. Either way, domain reputation and list quality matter more than the IP choice.

Warming is gradually increasing volume on a new IP so receivers can build trust. Fixed day-by-day schedules fail because receivers throttle based on demand and engagement, not a calendar: ramps should be gated by how the mail is actually received (acceptance, deferrals, complaints), not by a predetermined volume table.

SMTP reply codes have three digits: 2xx is success, 4xx is a transient failure that should be retried, and 5xx is a permanent failure that should not. Many servers add an enhanced status code (RFC 3463) in the form X.Y.Z for more detail. Hard bounces (permanent, like a non-existent address) must be suppressed immediately; soft bounces (temporary) are retried sensibly.

Often yes. Receivers score the sender, not the message type, so a bad marketing campaign can drag down password resets and receipts that share the same domain or IP reputation. The usual fix is to separate streams onto distinct subdomains (and sometimes IPs) so critical mail is insulated from campaign volatility, an approach M3AAWG and Apple both recommend.

A feedback loop is a mechanism where a mailbox provider forwards spam complaints back to the sender, usually as an ARF report (RFC 5965), so the complaining recipients can be suppressed. You enroll per provider: Microsoft through JMRP, Yahoo (and AOL) by registering your DKIM signing domain in Sender Hub, while Gmail offers a campaign-level feedback loop and Apple offers none. Acting on complaints immediately is one of the highest-signal ways to protect reputation.

They are provider dashboards that show your reputation as that provider sees it. Google Postmaster Tools shows domain and IP reputation, spam rate, and authentication results; Microsoft offers SNDS (data) and JMRP (complaint feedback) for Outlook.com; Yahoo offers Sender Hub with a complaint feedback loop. Apple publishes guidance but no equivalent dashboard or feedback loop.

MTA-STS (RFC 8461) lets a domain require that inbound mail be delivered over authenticated TLS, closing the gap that ordinary SMTP TLS is opportunistic and strippable. TLS-RPT (RFC 8460) is the companion reporting standard: receivers send back JSON reports of TLS delivery failures so you can detect interception or misconfiguration.

Modern filters combine many signals: connection and reputation checks, authentication results, statistical (Bayesian) content analysis, collaborative checksum networks (DCC, Pyzor, Razor), rule engines (SpamAssassin, Rspamd), and engagement. There is no single universal score threshold; each deployment tunes its own. The way a legitimate sender stays clear is consistency, authentication, and list hygiene, not trying to outguess a score.

It depends on where your recipients are. The US CAN-SPAM Act is opt-out; Canada CASL, the EU/UK (GDPR and ePrivacy/PECR), and Australia (Spam Act) are consent-based (opt-in); Turkey has the ETK and IYS system. All require honest identification and a working unsubscribe. This is general information, not legal advice; consult counsel for your jurisdiction.

No. Egressif does not read message content and does not store message bodies for delivery. Where it hosts mailboxes, their contents are stored only to operate the mailbox and are never read. Your data is not used to train AI.

Yes. Egressif can be your whole stack or an operating layer on top of an existing provider (SendGrid, Amazon SES, Postmark, Mailgun, the Google Workspace relay, or your own infrastructure), adding monitoring, ordered failover, suppression, and per-message delivery evidence without a migration.

Spam foldering is almost always a reputation, authentication, or engagement problem rather than a single "bad word." The usual causes are failing or unaligned SPF/DKIM/DMARC, a sending domain or IP with weak reputation, high complaint or bounce rates, listed links in the body, or mailing people who never opted in. Because a message can be accepted (a 250) and still be filtered to spam, the fix is to clean up authentication, list hygiene, and complaint handling, not to tweak wording.

Authenticate every message with aligned SPF and DKIM, publish DMARC, and keep forward and reverse DNS valid and TLS in place. Then protect reputation operationally: send only to people who opted in, suppress hard bounces and complaints immediately, honor unsubscribes promptly (one-click for bulk mail), and keep volume consistent. Watch the provider signals (Gmail Postmaster spam rate, feedback loops) so problems surface early; no one can guarantee the inbox, but these inputs are what receivers actually measure.

550 is a permanent SMTP rejection (5xx), and the enhanced code 5.7.1 is RFC 3463's "Delivery not authorized, message refused" in the security/policy class (X.7.x). In plain terms the receiver applied a per-host or per-recipient policy and refused the mail, commonly for reputation, authentication, or being blocked, rather than a bad address. Because it is permanent, do not blindly retry the identical message; investigate the specific reason in the response text, since providers attach their own meaning to the same code.

421 is the SMTP reply for "service not available, closing the transmission channel" and is transient (a 4xx), even though it drops the connection. The 4.7.x part is RFC 3463's security/policy class, so a 421 4.7.x typically signals temporary throttling or a reputation-based deferral. The exact compound code is provider-specific and not defined as a single point in any base RFC, so treat it as "back off and retry later" while investigating reputation and authentication, not as a permanent block.

RFC 5321 defines the first digit of an SMTP reply as the verdict: 4xx is a transient (temporary) failure and 5xx is a permanent one. A 4xx means the command could succeed if repeated unchanged, so a sender should queue and retry on a backoff (the RFC suggests retrying for several days). A 5xx means something must change first (the address, the content, your reputation), so the same request should not be retried; resending into a 5xx is exactly the behavior receivers penalize.

A hard bounce is a permanent failure: a delivery report with Action: failed and a 5.x.x status (for example 5.1.1 "user unknown"), and the address should be suppressed and never retried. A soft bounce is a transient condition, such as Action: delayed or a 4.x.x status (a full mailbox, throttling, a temporary DNS problem), which should be retried on a backoff. RFC 3464 cautions that even a permanent-looking failure can be temporary, so suppress on persistent failure over time rather than a single report.

No mailbox provider publishes a universal "acceptable" bounce-rate percentage, so we will not invent one. What is documented is the behavior: large volumes of hard bounces subtract from sender reputation, M3AAWG considers it best practice to remove an address after it bounces consecutively at least twice over two weeks or more, and hard bounces should be suppressed immediately. The practical target is to keep bounces low by mailing only verified, opted-in addresses and processing bounces promptly, rather than aiming at a specific number.

The p tag tells receivers what to do with mail that fails DMARC. p=none is monitor-only (deliver as normal but send reports), p=quarantine asks receivers to treat failing mail as suspicious (typically the spam folder), and p=reject asks them to refuse it. Note that under RFC 9989 receivers should not reject on p=reject alone, so p=reject is appropriate only for domains controlled end to end; p=none is the baseline most bulk-sender rules require.

Start at p=none with a rua reporting address and read the aggregate reports until every legitimate sending source passes with aligned SPF or DKIM. Remove the dead tags (pct, ri, rf), add np=reject to close the non-existent-subdomain hole, then escalate to quarantine and finally reject once reports are clean. Keep in mind p=reject suits only domains you control fully (the standard discourages it for domains whose users post to mailing lists), and that the new t=y testing tag only downgrades at receivers that already implement the 2026 DMARC, not the majority that still apply p=reject directly.

The qualifier on the all mechanism sets what SPF asserts about every host you did not list. -all is a hard "fail" (no one else is authorized), while ~all is a "softfail" meaning probably not authorized but the domain is not certain. Receivers usually still accept softfail mail and lean on DMARC for the actual decision; avoid +all entirely, since it authorizes the whole internet to send as your domain.

RFC 7208 caps SPF at 10 DNS-querying terms (include, a, mx, ptr, exists, and redirect all count; ip4 and ip6 do not), and crossing it returns a permerror that fails the SPF half of DMARC silently. Audit the full recursive expansion, not just your top-level record, because each include pulls in its own lookups. Reduce includes, replace lookups with ip4/ip6 ranges where you can, remove unused vendors, and watch for void lookups (NXDOMAIN/empty answers), which are limited to two. Because SPF breaks on forwarding anyway, leaning on aligned DKIM is the durable fix.

A plain forward usually keeps DKIM valid, because DKIM signs the message content rather than checking the connecting IP. DKIM breaks when an intermediary changes signed content, which is exactly what many mailing lists do when they rewrite the Subject or append a footer to the body inside the signed region. SPF also fails on forwarding because the forwarder's IP is not in your record, which is why ARC exists to carry the original result forward, though receivers are not obligated to honor it.

Alignment is the DMARC requirement that an authentication result match the visible From: domain. For DKIM, the signing domain (the d= value) must align with the From: domain: relaxed alignment (the default) accepts the same Organizational Domain, while strict alignment requires an exact match. A bare DKIM "pass" is not enough for DMARC; the passing identifier also has to be aligned, which is why an ESP can show DKIM pass while your DMARC still fails.

BIMI (Brand Indicators for Message Identification) displays your brand logo next to authenticated mail in supporting clients. It authenticates nothing itself; it rides entirely on DMARC and only shows when your policy is at enforcement (p=quarantine or p=reject, not p=none), using an SVG Tiny PS logo published at default._bimi. You do not need it for deliverability, but it is a reasonable visible payoff once your DMARC is already at enforcement, and most major providers also require a mark certificate before they will render the logo.

A VMC (Verified Mark Certificate) is a certificate that validates your ownership of a logo, based on a registered trademark, so mailbox providers will display it via BIMI. A related option, the CMC (Common Mark Certificate), covers logos that are not trademarked. The BIMI spec calls a certificate "strongly recommended" rather than strictly mandatory, but in practice many major providers require a VMC or CMC before they will show your logo, so the certificate, not the DNS record, is usually what determines whether the logo appears.

Greylisting (described in RFC 6647) returns a temporary 4xx failure to an unfamiliar sender, then accepts the message when it retries, exploiting the fact that most spam software never retries while legitimate MTAs must. The cost is a one-time delay on the first message from a new sender, which the recipient notices as a lag. It only causes lasting problems if your setup looks like a new sender each attempt, for example shifting outbound IPs, per-message return-paths, or reformulated headers between retries, so consistent sending and correct retry behavior make greylisting wave your mail through.

There is no fixed, published number of days, and we will not invent one, because receivers throttle based on demand and engagement rather than a calendar. Warming is done when you can send your normal volume with stable acceptance, low deferrals, and low complaints, which depends on your volume, list quality, and how each provider responds. Gate the ramp by how the mail is actually received (acceptance, 4xx deferrals, complaint and bounce signals) rather than following a predetermined day-by-day volume table.

A spam trap is an address used to catch senders with poor list hygiene: pristine traps are addresses that never opted in to anything, and recycled traps are real addresses retired after long inactivity and converted into traps (M3AAWG suggests a minimum of around 12 months of inactivity). Hitting one is a symptom, not the disease; it signals weak address acquisition or missing bounce processing. Avoid them with confirmed (double) opt-in, never buying or appending lists, suppressing hard bounces, and removing chronically unengaged addresses.

Both make inbound SMTP TLS authenticated and resistant to downgrade attacks, but they anchor trust differently. MTA-STS (RFC 8461) uses the Web PKI and an HTTPS-served policy and needs only a valid certificate, while DANE (RFC 7672) publishes TLSA records in DNS and requires a DNSSEC-signed zone (without DNSSEC, DANE provides no security at all). They are receiving-side protections rather than placement boosters; if your zone is DNSSEC-signed, DANE is the stronger option, and publishing both reaches the most senders since many honor only one.

Google Postmaster Tools rates your domain and IP reputation on a four-tier scale: Bad and Low mean a history of spam and likely filtering, Medium means mostly legitimate with occasional spam, and High means very low spam rates and compliance with Gmail's guidelines. Read the spam-rate dashboard with care, because if Gmail is already routing mail to spam the displayed rate can look deceptively low. Reputation and spam rate are inputs to placement, not a placement report, and data lags (around 24 hours, up to 7 days for compliance changes) and only covers personal @gmail.com mail.

Tracking itself is not inherently penalized, but it adds links and a tracking domain to your mail, and a tracking or redirect domain with poor reputation that appears on a URI blocklist (SURBL, URIBL, Spamhaus DBL) can get the whole message filtered even from a clean IP. Use a reputable, properly authenticated tracking domain, keep link counts reasonable, and for high-risk or mandated mail M3AAWG advises stripping tracking to the minimum. The bigger risk is usually the tracking domain's reputation, not the act of measuring opens or clicks.

Effectively yes for the Apple Mail audience. When Mail Privacy Protection is enabled, Apple pre-fetches remote content, including the tracking pixel, through its own infrastructure whether or not the recipient ever opened the message, which inflates open rates and masks the recipient's IP. Treat opens as unreliable for these recipients and base engagement decisions on clicks, replies, conversions, and sustained delivery instead.

Transactional (or relationship) mail is sent because of an action the recipient already took, such as a password reset, receipt, or order confirmation, while marketing mail promotes products or content. The distinction matters legally and operationally: under US CAN-SPAM the message's "primary purpose" determines its obligations, and providers like Yahoo require one-click unsubscribe only on marketing mail. Because receivers score the sender, it is good practice to separate the two streams so campaign volatility does not threaten critical transactional mail.

The Return-Path, also called the envelope sender or MAIL FROM (RFC5321.MailFrom), is the address given in the SMTP envelope and is where bounces are returned; it is separate from the From: header a person reads. SPF authenticates this envelope domain, not the visible From:, which is why an ESP can show "SPF pass" on its own return-path while your DMARC still fails for lack of alignment. Bounce notifications are sent with a null return-path (MAIL FROM:<>) so they cannot loop, so a bounce mailbox must accept mail from <>.

Publish one SPF TXT record (v=spf1 ...) that lists every legitimate sending source and stays under the 10-lookup limit, ending in -all or ~all rather than +all. Add a DKIM key as a TXT record at selector._domainkey.yourdomain and sign outgoing mail (including the From: and List-Unsubscribe headers) with a modern key. Then publish a DMARC record at _dmarc.yourdomain starting at p=none with a rua address, confirm SPF or DKIM passes and aligns with your From: domain in the reports, and escalate the policy from there. Keep forward and reverse DNS valid and TLS enabled.

It is a bad idea and, in many places, unlawful. Consent-based regimes (Canada CASL, EU/UK GDPR and ePrivacy, Australia's Spam Act) require permission the buyer does not have, and even under the opt-out US CAN-SPAM you remain liable for every non-compliant message (up to $53,088 per email). Industry bodies are blunt that permission is not transferable: M3AAWG calls sending to purchased or appended lists a direct violation of its core values, and providers such as Apple flatly prohibit it. Purchased lists also seed spam traps and complaints that damage your reputation, so confirmed opt-in is the only safe path.

A subdomain strategy splits your mail across dedicated subdomains, for example marketing on news.example.com and transactional on mail.example.com, so each stream builds its own reputation under the shared Organizational Domain. Because receivers score the sender, this insulates critical mail (receipts, password resets) from the volatility of marketing campaigns and lets you authenticate and monitor each stream independently. M3AAWG and Apple both recommend segmenting marketing and transactional streams; subdomains keep DMARC alignment with your primary domain while isolating reputation.

ARC (Authenticated Received Chain, RFC 8617) records what authentication looked like before a message was relayed, so a final receiver can see that it passed SPF and DKIM at the origin even after a mailing list or forwarder broke them. The important caveat is that ARC is advisory, not a pass: a receiver MAY use a valid chain to override a DMARC failure but is not required to, and as of 2026 it is still not widely deployed. The durable fix for forwarded and list mail is aligned DKIM that survives the relay, with ARC as a supplement rather than a substitute.

A PTR (reverse DNS) record maps your sending IP back to a hostname, and providers expect it to be valid, meaningful, and reflect your domain rather than look like a generic or dynamically assigned address. Bulk-sender rules at Gmail and Yahoo expect valid forward and reverse DNS, and a missing or generic PTR is documented to downgrade an IP's sending reputation (Gmail even lists "bad or missing PTR record" as a delivery-error reason). It is a basic hygiene requirement, not an optional extra, for any IP you send from.

A DMARC pass proves only that the domain in the visible From: was used with authorization, that is, that SPF or DKIM passed and the passing identifier aligned with the From: domain. It says nothing about whether the message is wanted or where it will land; RFC 9989 is explicit that reputation, content, and engagement still decide inbox placement. Authentication is necessary but not sufficient, so a passing DMARC record does not guarantee the inbox.