DMARC Analyzer

TL;DR

• Email deliverability is not message delivery. Message delivery is the SMTP-level outcome (did the receiving MTA accept the message with a 250 OK?); deliverability is the end-to-end outcome (did the message land in the recipient primary inbox where it will be read, or in the spam folder where it will not?).
• Five root causes drive spam-folder placement: authentication failure (SPF / DKIM / DMARC), low sender reputation (IP, domain, tenant), low engagement (opens, clicks, replies, complaints, deletes), content signals (URL patterns, attachment types, HTML/text ratio), and list-hygiene problems (spam-trap hits, role-address mailings, long-inactive recipients).
• Sender reputation is a four-layer composite: IP reputation + domain reputation + tenant reputation + engagement reputation. Engagement is universally weighted heavily — senders with poor open / click rates see deliverability degrade even when authentication passes and complaint rate is low.
• DMARC enforcement is now a baseline prerequisite for the inbox, not a competitive differentiator. Gmail and Yahoo Bulk Sender Requirements (February 2024) require p=quarantine or stricter for senders mailing more than 5,000 recipients per day at each provider.
• The postmaster-tools triad is the canonical observability layer: Google Postmaster Tools (postmaster.google.com), Microsoft SNDS + JMRP (sendersupport.olc.protection.outlook.com), Yahoo Sender Hub (senders.yahooinc.com). Each exposes per-provider reputation, complaint rate, authentication pass rate, and bounce breakdown. Enroll every sending domain in all three before scaling beyond ~1,000 recipients per day.
• Hard bounces (5xx) must be removed immediately; soft bounces (4xx) should be retried per RFC 5321 §4.5.4 and only escalated to permanent removal after sustained failure. Continuing to mail hard-bounced addresses is a strong negative reputation signal at every receiver.
• Spam traps are the highest-leverage negative signal. A single pristine spam-trap hit can degrade deliverability for weeks; sustained hits trigger Spamhaus blacklist listings that block the sender from a large fraction of the internet. Spam traps are the inevitable consequence of acquiring addresses without explicit opt-in (purchased lists, scraped addresses, third-party append services).
• One-click List-Unsubscribe (RFC 8058 List-Unsubscribe-Post: List-Unsubscribe=One-Click) is mandatory for senders mailing more than 5,000 Gmail or Yahoo recipients per day, per the Gmail and Yahoo Bulk Sender Requirements. The unsubscribe must complete in a single recipient action and remove the recipient from the list within two business days.

1. What email deliverability actually means

Email deliverability is the chain of receiver-side acceptance, placement, and engagement outcomes that determines whether a sent message reaches the recipient primary inbox. It is the business-outcome view of email sending, distinct from — and downstream of — the protocol-level view that SMTP, SPF, DKIM, DMARC, and ARC describe.

Senders new to deliverability commonly conflate three distinct outcomes:

• Message delivery — the SMTP-level outcome of whether the receiving MTA accepted the message in the SMTP transaction (a 250 OK response to the final dot-period after DATA). A message that is delivered at the SMTP layer is the receiver's responsibility from that point on; the sender has completed its side of the transaction.
• Inbox placement — the receiver-side outcome of which folder the accepted message is placed in. The same accepted message can land in the primary inbox (where it will probably be read), the spam / junk folder (where it will probably never be read), the Promotions / Updates / Forums / Social tabs (where it will be read with low frequency), or a tenant-administrator-defined quarantine folder (where the recipient will probably never see it). Placement is a per-receiver, per-recipient decision the sender does not control directly.
• Recipient engagement — the recipient actions that follow placement: open, click, reply, forward, mark-as-important, mark-as-not-spam, mark-as-spam, delete-without-open. Engagement is what the sender ultimately cares about (because engagement is the business-outcome of email marketing / transactional notifications / customer communications), AND it is the highest-leverage input into future placement decisions, because engagement reputation feeds back into how the receiver places the sender's NEXT message.

The industry shorthand "deliverability" loosely covers the second and third outcomes — inbox placement and the engagement feedback loop. Senders saying "my deliverability is bad" almost always mean either "my mail is landing in spam" or "my mail is being blocked entirely after a period of acceptance."

The key insight: deliverability is a RECEIVER-side decision the sender does not directly control. Senders can only influence deliverability by optimizing the signals receivers measure — and measuring receiver-side outcomes through the postmaster-tools triad and the DMARC aggregate-report stream so the optimization is informed by real data rather than guesswork.

2. The delivery funnel — from MX lookup to inbox

A sent message traverses a four-stage funnel before it lands in front of the recipient. Each stage filters a fraction of mail out of the funnel; the inbox-placement rate is the cumulative product of the per-stage acceptance rates.

1. Stage 1 — MX resolution and TCP connect. The sending MTA looks up the recipient domain's MX records (RFC 5321 §5.1), selects the lowest-preference MX target, and opens a TCP connection on port 25 (or port 587 for authenticated submission, or port 465 for implicit-TLS submission). Failures at this stage — DNS resolution failure, TCP timeout, connection refused — are infrastructure-level and usually correct themselves on retry. The DMARC Analyzer Domain Security Checker confirms recipient- side MX records are well-formed; see help_mx_records.php for the MX record reference and help_dns_propagation.php for the TTL discipline that bounds how quickly MX changes become visible to senders.
2. Stage 2 — SMTP envelope acceptance. The sending MTA runs the SMTP transaction (HELO/EHLO → MAIL FROM → RCPT TO → DATA → final dot). The receiving MTA accepts (250 OK), defers with a 4xx code (transient failure, retry), or rejects with a 5xx code (permanent failure, no retry). Acceptance at this stage is the SMTP-level "delivered" outcome — but acceptance does NOT guarantee inbox placement. Receivers commonly accept mail at SMTP (to avoid the sender's sending-MTA infrastructure thrashing on retry) then route the accepted message to the spam folder or a quarantine. See section 8 for the SMTP bounce taxonomy.
3. Stage 3 — content classification and placement. The receiver runs the accepted message through its content classifier — a machine-learning model trained on hundreds of millions of historical messages, recipient actions, and per-sender reputation signals. The classifier produces a placement decision: primary inbox, Promotions / Updates / Forums / Social tab (Gmail's category split), Focused vs Other (Outlook's two-folder split), Bulk vs Inbox (Yahoo's binary split), or spam folder. This is the highest-leverage stage for deliverability — and the stage where sender reputation, authentication outcomes, engagement history, and content signals all factor into the receiver's decision. See section 9 for the per-receiver placement model.
4. Stage 4 — recipient action. Once the message is placed, the recipient may open it, click links, reply, forward, mark as important, mark as not-spam (recovering from a spam-folder placement), mark as spam (driving future placement toward spam), or delete without opening (a strong negative engagement signal at most receivers). Recipient actions feed back into the receiver's engagement-reputation model for the sender — making this stage's outcomes the single highest-leverage input into the NEXT message's placement decision. See section 5 for the engagement-signal taxonomy.

Stages 1 and 2 are sender-controlled (infrastructure + authentication + bounce handling). Stages 3 and 4 are receiver-controlled — but the receiver's decisions are shaped by the sender's history at stages 1, 2, and 4 across thousands of prior messages. Deliverability optimization is the discipline of influencing stages 3 and 4 by managing the inputs the receiver measures at every stage.

3. The authentication layer — SPF, DKIM, DMARC, ARC, BIMI

Email authentication is the first deliverability filter every modern receiver applies. The four-layer authentication stack — SPF, DKIM, DMARC, and ARC, with BIMI as the brand-trust capstone — establishes the receiver's confidence that the message actually comes from the claimed sender. Without that confidence, no content-classifier verdict and no reputation history can save the message from the spam folder.

• SPF (Sender Policy Framework, RFC 7208) — the IP-authorisation layer. The sender publishes a DNS TXT record at the envelope-from domain listing the IPs authorised to send mail. The receiver checks the connecting SMTP client IP against the published list and returns pass / fail / softfail / neutral / none / temperror / permerror. SPF alone is insufficient because it breaks across forwarding (the forwarder's IP is not in the original sender's SPF list). See help_spf_explained.php for the SPF deep dive and help_spf_lookup_limit.php for the 10-DNS-lookup limit that commonly trips senders during onboarding.
• DKIM (DomainKeys Identified Mail, RFC 6376) — the cryptographic-signing layer. The sender signs each outgoing message with a per-domain private key; the public key is published in DNS at a sender-chosen selector (selector._domainkey.example.com). The receiver fetches the public key, verifies the cryptographic signature against the message body and selected headers, and returns pass / fail / none / temperror / permerror. DKIM survives forwarding (the signature travels with the message) but fails when a forwarder modifies the message body or signed headers. See help_dkim_explained.php and help_dkim_key_rotation.php.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance, RFC 7489) — the alignment + policy layer. DMARC requires SPF or DKIM (or both) to ALIGN with the From: header domain (the domain the recipient sees), and tells the receiver what to do when alignment fails: monitor only (p=none), spam-folder (p=quarantine), or reject (p=reject). DMARC enforcement is the inflection point for deliverability: at p=none the receiver gets a signal but no instruction; at p=quarantine alignment failures go to spam; at p=reject alignment failures bounce. See help_dmarc_records_explained.php and help_dmarc_policy_rollout.php.
• ARC (Authenticated Received Chain, RFC 8617) — the forwarding-survival layer. ARC lets intermediate MTAs (mailing lists, forwarders, security gateways) preserve the original sender's SPF and DKIM authentication results across modifications that would otherwise break DMARC. Without ARC, mail forwarded through a mailing list typically fails DMARC at the final receiver and lands in spam regardless of the original sender's good reputation. See help_arc_explained.php.
• BIMI (Brand Indicators for Message Identification) — the brand-trust capstone. BIMI lets senders display their verified brand logo next to their messages in supporting clients (Gmail, Apple Mail, Yahoo, AOL, Outlook). BIMI requires DMARC at p=quarantine or stricter, and for Gmail / Apple Mail also requires a Verified Mark Certificate (VMC) from DigiCert or Entrust. The logo display is a recipient-side trust signal that lifts open rates and engagement, which feeds back into engagement-reputation. See help_bimi_explained.php.

Authentication failures shift placement aggressively — most modern receivers treat a DMARC fail with the sender at p=none as a strong spam signal even though the policy does not request enforcement, because p=none publishers have a higher historical spoofing rate than enforcing publishers. Authentication is necessary but not sufficient for inbox placement; it is the floor every other deliverability optimization builds on.

4. Sender reputation — IP, domain, tenant, engagement

Sender reputation is how mailbox providers summarize a sender's history into a single placement- decision input. Every major mailbox provider — Gmail, Microsoft 365 / Outlook.com, Yahoo, Apple iCloud, Comcast, AOL, AT&T — maintains its own per-sender reputation score, computed from its own observed signals over a rolling 30-day window. Reputation is a per-receiver concept: a sender can have excellent reputation at Gmail and poor reputation at Outlook simultaneously, and the two receivers will make different placement decisions for the same message.

Reputation is a weighted composite of four sub-reputations:

• IP reputation — the historical complaint rate, bounce rate, and spam-trap hit rate of the sending IP address. For dedicated-IP senders, IP reputation is the sender's own history. For shared-IP senders (SendGrid, Mailgun, Postmark, Amazon SES out-of-the-box, Mailchimp), the IP reputation is shared with every other sender on the same IP — meaning a single noisy neighbor can degrade your deliverability. Reverse DNS / PTR records (see help_reverse_dns_ptr.php) are the receiver's primary signal for whether the sending IP is operated by a legitimate mail provider.
• Domain reputation — the same signals computed for the sending domain (specifically the DKIM signing domain and the From: header domain), computed independently of which IPs the domain sends from. Domain reputation is portable: moving from a shared-IP ESP to a dedicated IP does not lose the domain's accumulated reputation, because Gmail and Microsoft track reputation primarily by domain. This is why DKIM signing is mandatory for serious senders — DKIM is the cryptographic anchor that lets receivers attribute reputation to the domain independently of the sending IP.
• Tenant reputation — for shared-IP mailbox-provider tenants (M365 tenants, Workspace tenants, SendGrid sub-accounts, Mailgun sub-accounts), the per-tenant reputation that lives alongside the per-IP and per-domain reputations. This is how M365 surfaces tenant-level outbound throttling when one tenant on a shared M365 outbound IP pool generates complaints disproportionate to the pool's baseline. See help_dmarc_for_microsoft_365.php and help_dmarc_for_google_workspace.php for the tenant-side controls.
• Engagement reputation — the historical open rate, click rate, reply rate, mark-as-spam rate, and delete-without-open rate of the sender across the receiving organization's recipient base. Engagement reputation is universally weighted heavily — senders with poor engagement signals see deliverability degrade even when authentication passes and complaint rate is low. Engagement reputation is also the most volatile signal: a deliverability problem caused by engagement decay can take 4–8 weeks to repair, even after the underlying list-hygiene issue is fixed.

The exact weights are proprietary and differ between Gmail, Microsoft 365, Yahoo, and Apple iCloud, but every major receiver weighs engagement reputation heavily — by some industry estimates, more than 50 percent of the total reputation score at Gmail. This is the single most important insight in modern deliverability: engagement is reputation. Senders mailing recipients who do not engage will degrade reputation regardless of how clean the technical setup is.

5. Engagement signals — the recipient feedback loop

Engagement signals are the per-recipient actions that mailbox providers measure to compute engagement reputation. Different receivers measure slightly different signals, but the high-leverage list is consistent:

• Open — the recipient opened the message (typically measured by a tracking-pixel fetch, though Apple Mail Privacy Protection and similar features now pre-fetch all tracking pixels on receipt, making open-rate a less reliable signal for Apple Mail recipients than it was historically). Positive engagement signal.
• Click — the recipient clicked a link in the message. Strongly positive engagement signal; harder to falsify than open (no automated pre-fetching, except for anti-phishing scanners that follow links in a sandbox — a small fraction of total clicks).
• Reply — the recipient replied to the message. Strongest positive engagement signal: a reply proves the recipient values the conversation enough to write back, and is the single most-weighted positive signal at Gmail.
• Forward — the recipient forwarded the message to another recipient. Strongly positive engagement signal.
• Mark as important / star / flag — the recipient marked the message for future attention. Positive engagement signal.
• Mark as not-spam — the recipient retrieved the message from the spam folder. Very strongly positive engagement signal: it tells the receiver its placement decision was wrong, and the sender's mail SHOULD have gone to the inbox.
• Mark as spam — the recipient flagged the message as unwanted. Very strongly negative engagement signal: an explicit recipient-driven anti-vote that tells the receiver to send this sender's mail to spam going forward, AND that feeds into the sender's reputation across all recipients at this receiver. Senders aim for a complaint rate (mark-as-spam rate) below 0.1 percent of delivered mail; above 0.3 percent is the canonical Gmail Postmaster Tools threshold for "bad" reputation.
• Delete without open — the recipient deleted the message without opening it. Negative engagement signal at most receivers (the implicit "I did not want this enough to look at it" anti-vote). Sustained delete-without-open behaviour across a recipient list is a strong deliverability-decay predictor.
• Unsubscribe via List-Unsubscribe — the recipient used the receiver-integrated unsubscribe button. NEUTRAL signal at most receivers (because unsubscribing is the legitimate path for recipients who no longer want the mail). Senders MUST honor List-Unsubscribe within two business days per RFC 8058 + Gmail / Yahoo Bulk Sender Requirements. Failure to honor unsubscribes usually escalates to mark-as-spam, which IS a strongly negative signal.

The engagement-signal feedback loop is the single most powerful lever in deliverability optimization. Senders who segment their list by recent engagement (mail only recipients who opened or clicked in the last 30 / 60 / 90 days), re-engage cold recipients with a single permission-confirmation message before removing them, and remove non-engagers from the active sending list see deliverability lift within 2–4 weeks at most receivers. Senders who continue mailing inactive recipients see deliverability decay even when authentication, list-hygiene, and content are all clean.

6. List hygiene — bounces, spam traps, role addresses

List hygiene is the operational discipline of keeping the sending list free of addresses that damage reputation: hard-bounced addresses, spam traps, role addresses, abandoned addresses, and addresses acquired without explicit opt-in.

• Hard-bounce removal. Addresses that returned a 5xx SMTP error MUST be removed from the sending list immediately and never re-mailed. Continuing to mail hard-bounced addresses is a strong negative reputation signal at every receiver — and a likely path to spam-trap accumulation, because mailbox providers commonly convert long-abandoned addresses into recycled spam traps. Automated bounce processing (parse the bounce, extract the address, mark permanently undeliverable in the database) is mandatory for any sender mailing more than a few thousand recipients per month.
• Soft-bounce escalation. Addresses that returned a 4xx SMTP error should be retried per RFC 5321 §4.5.4 (typically every 30 minutes for the first 4 hours, then every 4 hours for up to 5 days). Addresses that soft-bounce consistently across multiple sends (a common heuristic: 5+ consecutive soft-bounces over 30 days) should be escalated to permanent removal — the underlying cause is usually a full mailbox that has been abandoned, an over-aggressive receiver-side rate limit, or a long-term DNS / MTA problem at the recipient that will not resolve.
• Spam-trap avoidance. The only effective spam-trap avoidance strategy is double-opt-in (the recipient clicks a confirmation link in a separate message to confirm they actually own the address before being added to the list). Senders who use single-opt-in (the recipient types their address into a form and is immediately added) reliably accumulate spam traps from competitors seeding the list, typos, and bad actors. Purchased lists, scraped addresses, and third-party append services are guaranteed to contain spam traps in statistically meaningful concentrations.
• Role-address filtering. Role addresses (info@, admin@, support@, sales@, postmaster@, abuse@, webmaster@, noreply@) are addresses shared by multiple people or by an automated system that does not engage with marketing mail. Many receivers weight role addresses heavily into complaint rate calculations because the person receiving the mail did not personally opt in. Filter role addresses out of marketing sends at signup time.
• Inactivity-based removal. Recipients who have not opened, clicked, or replied in 6–12 months should be moved to a re-engagement segment (a single permission-confirmation message), and removed entirely after another 30–60 days if no engagement results. Long- abandoned addresses commonly convert to recycled spam traps without warning; mailing them after the conversion is the canonical path to a Spamhaus listing.
• Address validation at signup. Real-time email-address validation services (NeverBounce, ZeroBounce, Kickbox, BriteVerify) check at signup whether an address syntactically valid, the MX records resolve, the mailbox actually exists (via SMTP probe), and the address matches known spam-trap patterns. Validation catches typo spam traps (gmial.com for gmail.com) and many recycled and pristine traps before they contaminate the list.

7. Postmaster tools — Google, Microsoft, Yahoo

The postmaster-tools triad is the canonical observability layer for senders. Each major mailbox provider operates a free dashboard that surfaces receiver-side reputation, complaint rate, authentication pass rate, and bounce breakdown to enrolled senders. Enroll every sending domain in all three before scaling beyond ~1,000 recipients per day.

• Google Postmaster Tools (postmaster.google.com). Enrollment is via DNS TXT record proving domain ownership. Surfaces: domain reputation (high / medium / low / bad — a four-level scale; anything below high warrants investigation), IP reputation (same scale per sending IP), authentication rate (the percentage of mail that passed SPF, DKIM, and DMARC at Gmail receivers), encryption rate (the percentage of mail that arrived over TLS — must be high for bulk senders per Gmail Bulk Sender Requirements), feedback-loop complaint rate (the percentage of recipients who marked the mail as spam, sampled and aggregated for privacy), delivery errors (per-error-code breakdown of SMTP-level rejections), spam rate (the percentage of accepted mail that Gmail classified as spam after acceptance), and one-click unsubscribe compliance (whether the sender supports RFC 8058 List-Unsubscribe-Post: One-Click). Postmaster Tools is the highest-fidelity view of how Gmail sees a sender; the data is updated daily.
• Microsoft SNDS (Smart Network Data Services) + JMRP (Junk Mail Reporting Program) (sendersupport.olc.protection.outlook.com). SNDS is IP-keyed (request access for each of your sending IPs) and surfaces per-IP reputation, complaint rate, spam-trap hit count, and Microsoft's overall trust verdict (red / yellow / green). JMRP is the complaint feedback loop — Microsoft forwards a copy of every Outlook.com / Hotmail user's mark-as-spam back to the enrolled sender's designated FBL address, with the recipient ARF-encoded so the sender can remove the complainer from the list. Both SNDS and JMRP are free; enrollment is per-IP and per-domain respectively.
• Yahoo Sender Hub (senders.yahooinc.com). Yahoo's unified sender portal replaced the legacy AOL FBL and Yahoo Postmaster pages after Yahoo acquired AOL. Surfaces sender reputation, complaint feedback loop enrollment (Yahoo CFL), authentication compliance per the February 2024 Yahoo Sender Best Practices, and ticket-based deliverability investigation for senders seeing systemic spam-foldering. Enroll every sending domain that mails Yahoo, AOL, or Verizon recipients.
• Validity Sender Score (senderscore.org). Not a mailbox-provider tool — Validity is a commercial deliverability vendor that aggregates per-IP reputation data from many sources (Spamhaus, several mailbox providers, public DNSBLs) into a single 0-100 sender score. Useful as a cross-receiver health check, less authoritative than the provider-direct postmaster tools.

The DMARC Analyzer aggregate-report stream complements (does not replace) the postmaster tools. Aggregate reports surface authentication outcomes (pass / fail per source IP per recipient receiver); postmaster tools surface reputation, complaint rate, and placement outcomes (inbox vs spam) that authentication alone does not predict. Use both: aggregate reports to confirm authentication is healthy end-to-end, postmaster tools to confirm placement is actually landing in the inbox.

8. SMTP bounce taxonomy — hard vs soft, codes, handling

The SMTP response code returned by the receiver on a failed delivery is the primary diagnostic for bounce handling. Codes follow the three-digit format from RFC 5321 §4.2 and the enhanced-status-code format from RFC 3463 §2.

• 2xx (Success). 250 OK is the canonical success — the receiver accepted the message at SMTP. Other 2xx codes (251, 252) are rare and indicate partial acceptance for special-case recipients.
• 4xx (Transient failure). The receiver could not deliver the message right now but expects success on retry. Common 4xx codes: 421 (service unavailable — try later), 450 (mailbox temporarily unavailable), 451 (local error in processing), 452 (insufficient system storage). The sending MTA SHOULD retry per RFC 5321 §4.5.4 for up to 5 days before generating a delivery-status notification to the original sender.
• 5xx (Permanent failure). The receiver cannot deliver the message and will not accept retries. Common 5xx codes: 550 (mailbox unavailable — most common, often paired with 5.1.1 enhanced code for "no such user"), 551 (user not local), 552 (storage allocation exceeded), 553 (mailbox name not allowed — usually a syntactic problem with the recipient address), 554 (transaction failed — often paired with content-rejection or reputation-blocking enhanced codes).
• RFC 3463 enhanced status codes — three numbers separated by dots (X.Y.Z): X is class (2 = success, 4 = persistent transient, 5 = permanent failure); Y is subject (1 = addressing, 2 = mailbox, 3 = mail system, 4 = network and routing, 5 = mail delivery protocol, 6 = message content, 7 = security or policy); Z is the specific detail. Common enhanced codes: 5.1.1 (no such user), 5.1.2 (no such domain), 5.2.2 (mailbox full), 5.7.1 (delivery not authorised — usually DMARC, SPF, DKIM, or reputation-based rejection), 5.7.26 (Gmail's bulk-sender-requirements rejection code, introduced February 2024 for senders failing the new Gmail bulk-sender floor), 5.7.509 (Microsoft 365's DMARC-policy-driven rejection), 5.7.605 (Microsoft 365's reputation-driven rejection).
• Block bounces vs delivery bounces. A block bounce is a rejection driven by sender reputation or content (typical 5xx code: 550 5.7.x). A delivery bounce is a rejection driven by recipient state (typical 5xx code: 550 5.1.1). Block bounces require fixing the sender side (clean the list, improve reputation, fix authentication); delivery bounces require removing the recipient from the list. Bounce processors MUST distinguish the two and route them to different remediation paths.
• Bounce rate target. Best-practice hard-bounce rate is below 2 percent of delivered mail for an established sender; above 5 percent is a strong reputation-degradation signal at most receivers. Soft-bounce rates of 5-10 percent are common and usually not a problem, but sustained soft-bounces against the same recipient should escalate to permanent removal.

Modern transactional ESPs (SendGrid, Mailgun, Postmark, Amazon SES) process bounces automatically and expose webhook callbacks for the sending application to consume. Senders using these ESPs MUST wire the bounce webhook to the application's recipient database — a surprising fraction of deliverability problems trace to senders who left the bounce webhook unwired and continued mailing hard-bounced addresses for months.

9. Inbox vs spam vs Promotions — per-receiver placement models

Inbox placement is per-receiver and per-recipient. The same accepted message at the same recipient on the same day can land in different folders depending on which client the recipient uses, the recipient's per-sender folder rules, and the receiver's classifier verdict at that moment.

• Gmail — Primary, Promotions, Updates, Forums, Social tabs (the default five-tab Inbox layout), or Spam. The category-tab decision is content-classifier driven: Promotions catches marketing / commercial mail; Updates catches transactional / notification mail; Social catches social- media notifications; Forums catches mailing- list traffic. Primary inbox is reserved for person-to-person mail and high-engagement bulk mail. Category-tab placement is often the correct outcome — a Promotions- tab placement is NOT a deliverability failure for a marketing message; spam-folder placement is. Recipients can drag messages between tabs to teach the classifier their preferences.
• Outlook / Outlook.com / Microsoft 365 — Focused vs Other (the two-folder split introduced 2016) or Junk (the spam folder). Focused holds mail from frequent correspondents; Other holds less-engaging-but-not-spam mail (often marketing). Outlook's Focused vs Other decision is computed per-recipient based on the recipient's historical engagement with each sender, plus a global per-sender prior. Microsoft 365 administrators can force Focused-vs-Other off tenant-wide, consolidating everything into a single Inbox + Junk binary.
• Yahoo / AOL / Verizon — Inbox or Bulk (the spam folder). Yahoo does not run a category-tab split; the decision is binary. Yahoo's bulk-folder threshold is famously sensitive to complaint rate — a 0.3 percent complaint rate that Gmail would tolerate as "medium" reputation regularly drives Yahoo to Bulk placement.
• Apple iCloud / Apple Mail client — Inbox or Junk. iCloud does not split by category; placement is binary. The Apple Mail client honors whatever folder the server placed the message in; Apple's classifier-side rules weigh DMARC authentication results heavily and lean Junk when DMARC fails. Apple Mail Privacy Protection (introduced iOS 15) pre-fetches all tracking pixels on receipt — meaning open-rate as a deliverability signal for Apple Mail recipients is unreliable, and senders should rely on click-rate, reply-rate, and unsubscribe-rate for the engagement feedback loop with Apple recipients.

Recipients can override placement decisions: moving a message from spam back to inbox tells the receiver its classifier was wrong (strongly positive reputation signal for the sender); moving a message from inbox to spam tells the receiver the opposite (strongly negative). The receiver's classifier rapidly incorporates these per-recipient overrides into per-sender per- recipient placement defaults, and more slowly into the global per-sender reputation that drives placement defaults for all recipients at the receiver.

10. Common misconceptions

• "Good content equals good deliverability." No. Content matters but is the lowest-weighted input at every modern receiver. A well-written transactional message from a sender with poor reputation will land in spam; a poorly-written marketing message from a sender with excellent reputation and high engagement will land in the inbox. Content optimization (no SPAMMY-CAPITALIZED SUBJECT LINES, balanced HTML-to-text ratio, no suspicious URL patterns) is the floor, not the ceiling.
• "DMARC alone fixes deliverability." No. DMARC enforcement raises the authentication floor (which IS a deliverability prerequisite), but reputation, engagement, and list hygiene remain dispositive. A sender at p=reject with poor engagement signals and a dirty list will still land in spam. See help_dmarc_policy_rollout.php for the DMARC rollout journey, then this page for the broader deliverability picture.
• "More volume equals more engagement." No. Mailing inactive recipients to "stay in front of the customer" degrades engagement reputation and pushes the entire list toward spam. The right rule is the opposite: mail less frequently to less-engaged recipients, and ramp frequency UP only for the most-engaged segment.
• "Switching ESPs fixes deliverability." Mostly no. Modern reputation systems are primarily DOMAIN-keyed, not IP-keyed — moving from SendGrid to Mailgun (changing sending IP) does not change the sender's DOMAIN reputation, which is what most receivers weight most. Switching ESPs helps only when the old ESP's shared IP pool was genuinely the problem (verifiable in SNDS and Postmaster Tools per-IP reputation history), AND the sender's domain reputation is healthy. The right move for damaged domain reputation is to fix the underlying engagement and list problems, then wait 4-8 weeks for reputation to recover.
• "DKIM key rotation fixes spam-folder placement." No. Rotating a DKIM key does not reset reputation — the receiver tracks reputation by the SIGNING DOMAIN (d= tag), not by the key material itself. Rotating the key changes the public-key DNS record but leaves the signing domain unchanged, so reputation attribution continues unbroken. Rotating the signing DOMAIN (changing d= to a fresh subdomain) DOES reset reputation — but it starts the new domain with zero history, which is no better than the damaged history and often worse (because receivers treat zero-history domains as suspicious).
• "Spam folder is the only bad outcome." No. Silent quarantine and content-classifier-driven category- tab routing (Gmail's Promotions when the sender expected Primary) are both deliverability problems for messages that depend on the recipient seeing them promptly. The DMARC aggregate- report stream and Postmaster Tools spam-rate metric surface spam-folder placement; category-tab routing is harder to detect — it requires a seedlist (a private list of recipients across major receivers whose inboxes the sender can monitor) or a third-party seedlist service (GlockApps, 250ok, Litmus).

11. Deliverability best-practices checklist

1. Publish SPF, DKIM, and DMARC for every sending domain. No exceptions. Even domains that send only one transactional message per month need authentication.
2. Get DMARC to p=quarantine or stricter. Required by Gmail and Yahoo Bulk Sender Requirements for senders mailing more than 5,000 recipients per day; useful for every sender regardless of volume.
3. Enroll in Google Postmaster Tools + Microsoft SNDS + Yahoo Sender Hub. Before scaling beyond ~1,000 recipients per day. The reputation dashboards are free and the data is the highest-fidelity view of how each receiver sees the sender.
4. Process bounces automatically. Hard bounces removed within 24 hours; soft bounces retried per RFC 5321 §4.5.4 and escalated to permanent removal after 5+ consecutive failures over 30 days.
5. Honor List-Unsubscribe within two business days. Per RFC 8058 + Gmail / Yahoo Bulk Sender Requirements. Support one-click unsubscribe (List-Unsubscribe-Post: List-Unsubscribe=One-Click) for bulk senders.
6. Process complaint feedback loops automatically. Wire Microsoft JMRP and Yahoo CFL into the sending application. Remove the complaining recipient within 24-48 hours.
7. Use double opt-in. The single most effective spam-trap avoidance practice. Senders who use single opt-in reliably accumulate traps within 6-12 months.
8. Validate addresses at signup. Real-time email validation (NeverBounce, ZeroBounce, Kickbox, BriteVerify) catches typo traps and many recycled traps before they contaminate the list.
9. Segment by engagement. Mail only recipients who opened, clicked, or replied in the last 30-90 days. Re-engage cold recipients with a single permission- confirmation message; remove non-engagers from the active sending list.
10. Keep complaint rate below 0.1 percent. Gmail Postmaster Tools threshold for "low" complaint rate; above 0.3 percent is "high" and triggers spam-foldering at every major receiver.
11. Keep hard-bounce rate below 2 percent. Above 5 percent is a strong reputation-degradation signal.
12. Send over TLS. Every modern ESP and self-hosted MTA defaults to STARTTLS; Gmail Postmaster Tools encryption rate must be 100 percent for bulk senders per Gmail Bulk Sender Requirements. Pair MTA-STS (RFC 8461) and TLS-RPT (RFC 8460) — see help_mta_sts_explained.php and help_tls_rpt_explained.php.
13. Publish reverse DNS / PTR records. Every sending IP needs an FCrDNS-valid PTR record. See help_reverse_dns_ptr.php.
14. Monitor DMARC aggregate reports. The authoritative source for authentication outcomes at every receiver. See help_dmarc_aggregate_reports.php.
15. Use a dedicated sending IP for high-volume sending. Above ~100,000 recipients per month, dedicated-IP sending gives the sender direct control over IP reputation. Below that volume, the shared-IP pool of a reputable ESP is usually preferable to a dedicated IP that cannot accumulate enough mail to establish reputation.

12. FAQ — common questions about email deliverability

What is email deliverability?

Email deliverability is the chain of receiver-side acceptance, placement, and engagement outcomes that determines whether a sent message reaches the recipient inbox. It is NOT the same as message delivery (the SMTP-level outcome of whether the receiving MTA accepted the message): a message that is delivered at the SMTP layer can still land in the spam folder. Deliverability is the END-TO-END outcome measured by inbox placement rate.

Why is my email going to spam?

Five root causes: (1) authentication failure (SPF / DKIM / DMARC fail at the receiver), (2) low sender reputation (IP, domain, or tenant has a history of complaint / bounce / spam-trap hits), (3) low engagement (recipient cohort has poor open / click / reply / mark-as-spam rates), (4) content signals (URL patterns, attachment types, HTML/text ratio match the spam classifier), (5) list-hygiene problems (spam-trap hits, role addresses, long-inactive recipients). The receiver weighs all five together.

How do mailbox providers compute sender reputation?

Sender reputation is a weighted composite of four sub-reputations: IP reputation, domain reputation, tenant reputation (for shared-IP mailbox-provider tenants), and engagement reputation (historical open / click / reply / mark-as-spam rates). The exact weights are proprietary and differ between Gmail, Microsoft 365, Yahoo, and Apple iCloud, but engagement reputation is universally weighted heavily — senders with poor engagement signals see deliverability degrade even when authentication passes and complaint rate is low.

What is the difference between a hard bounce and a soft bounce?

A hard bounce is a permanent delivery failure (SMTP 5xx code); the message cannot be delivered and should not be retried. A soft bounce is a transient delivery failure (SMTP 4xx code); the message cannot be delivered right now but should be retried per RFC 5321 §4.5.4. Hard bounces MUST be removed from the sending list immediately; soft bounces should be retried for up to 5 days and only escalated to permanent removal after sustained failure (5+ consecutive failures over 30 days is a common heuristic).

What is a spam trap?

A spam trap is an email address operated by an anti-spam organization or mailbox provider specifically to detect senders who acquire addresses without consent. Three categories: pristine (never used by a real person), recycled (abandoned by a real person and converted to a trap), typo (matches common typos of real addresses). Spam-trap hits are the single highest-leverage negative reputation signal: a single pristine hit can degrade deliverability for weeks; sustained hits trigger Spamhaus blacklist listings.

What is the complaint feedback loop?

A complaint feedback loop (FBL) is a per- mailbox-provider mechanism that forwards a copy of every message a recipient marks as spam back to the enrolled sender, so the sender can identify the complainer and remove them from the list. Microsoft (JMRP), Yahoo (CFL), Comcast, Cox, and others operate FBLs. Gmail does NOT operate a per-recipient FBL — it aggregates complaint data into Postmaster Tools. Senders MUST process FBL complaints within 24-48 hours to avoid escalating reputation damage.

What is Google Postmaster Tools?

Google Postmaster Tools is a free Google dashboard at postmaster.google.com that surfaces sender-reputation signals (domain reputation, IP reputation, authentication rate, encryption rate, feedback-loop complaint rate, delivery errors, spam rate, one-click unsubscribe compliance) to senders whose mail flows to Gmail recipients. Enrollment is via DNS TXT record proving domain ownership. The data is updated daily and is the canonical observability tool for any sender mailing more than a few hundred Gmail recipients per day.

Does DMARC enforcement improve deliverability?

Yes, indirectly. DMARC enforcement raises the authentication floor (forcing fix-up of SPF / DKIM gaps), enables BIMI display (which lifts open rates via brand-logo trust), and qualifies the sender for the Gmail / Yahoo Bulk Sender Requirements (mandatory at p=quarantine or stricter for senders above 5,000 recipients per day per receiver). Without DMARC enforcement, bulk senders see mail throttled or spam-foldered regardless of other practices. DMARC alone does not deliver mail to the inbox — reputation and engagement remain dispositive — but it is now a baseline prerequisite, not a differentiator.

13. Related guides

• DMARC explained — the central DMARC primer covering rollout strategy, aggregate-report XML schema, and mailing-list / forwarding interactions. The authentication-side companion to this business-outcome reference.
• Email authentication explained — the cluster-intro pillar covering the full SPF + DKIM + DMARC + ARC + BIMI + MTA-STS + TLS-RPT + CAA ecosystem. Authentication is the first deliverability filter every receiver applies.
• SPF explained — Sender Policy Framework (RFC 7208). The IP-authorisation layer that feeds receiver- side acceptance decisions.
• include vs ip4 vs a vs mx — the DELIVERABILITY-AUDIT-VS-SPF- MECHANISM-AUTHORING-CHOICE-AS-INBOX- PLACEMENT-INPUT-VARIABLE companion to this deliverability business-outcome framework. Where THIS page documents the 14-section OUTCOME-LAYER deliverability framework (authentication- verdict → reputation → engagement → SMTP-bounce-taxonomy → Postmaster-Tools telemetry → inbox-placement-rate), the include-vs-ip4-vs-a-vs-mx spoke documents the FOCUSED FOUR-IP-PROVIDING-MECHANISM- AUTHORING-CHOICE that ITSELF constitutes a load-bearing per-mechanism input variable into the receiver-side reputation-model deliverability verdict: each of the four IP-providing mechanism choices feeds a structurally-distinct deliverability-input dimension — include: recursive sub-record consultation creates a per-included-sub- tree reputation-aggregation surface (an ESP's bad-tenant cross-contamination risk inherited through the include: chain into the publisher's own deliverability), ip4: literal IP-CIDR publication creates a per-CIDR reputation- attribution surface (per-block IP-history reputation lookups at Gmail / Outlook / Yahoo / Apple / Comcast), a: A/AAAA-RR consultation creates a per- A-RR-IP-set reputation-attribution surface (which mutates with every A-RR-update), mx: MX-RR- then-A/AAAA chain consultation creates a per-MX-RR-IP-set reputation-attribution surface (which conflates inbound-MX-IP reputation with outbound-relay-IP reputation). Without the include-vs-ip4- vs-a-vs-mx spoke a deliverability operator reading THIS outcome-layer framework knows that SPF pass-rate gates the inbox-placement verdict, but not WHICH of the four mechanism choices in their own SPF record creates the per-mechanism reputation-attribution surface their domain's deliverability depends on — this link closes that mechanism-choice-to-reputation-input attribution gap at the SPF-authoring- decision layer upstream of every major receiver's reputation-model verdict.
• SPF mechanisms explained — the DELIVERABILITY-OUTCOME-DEPENDS-ON- PER-MECHANISM-SPF-PASS-RATE companion to this deliverability business-outcome reference. Where THIS page documents the 14-section OUTCOME-LAYER deliverability framework (authentication-verdict → reputation → engagement → SMTP-bounce- taxonomy → Postmaster-Tools telemetry → inbox-placement-rate), the SPF-mechanisms- explained spoke is the UPSTREAM PER- MECHANISM BYTE-GRAMMAR REFERENCE documenting the eight RFC 7208 §5 primitives whose AGGREGATE per-mechanism pass-rate is the LOAD-BEARING input gating every major receiver's reputation model. The PER-MECHANISM-PASS-RATE-DRIVES- DELIVERABILITY cross-reference establishes FIVE structurally-distinct per-receiver- reputation-model dependencies on per- mechanism SPF discipline: (i) Gmail / Workspace receiver-side per-mechanism weighting — Gmail's reputation model weighs ip4: / ip6: literal-IP mechanisms as the MOST RELIABLE per RFC 7208 §5.6 (deterministic, zero DNS lookup); the SPF-mechanisms spoke documents how senders maximising literal-IP coverage produce the highest sustained Gmail inbox-placement rates; senders relying heavily on nested include: cascades experience transient SPF- permerror bursts that Gmail's reputation engine penalises with multi-day inbox- placement degradation; (ii) Outlook / EOP receiver-side per-mechanism weighting — Outlook's Smart Network Data Services reputation model consumes per-IP spf=pass verdicts at the connecting IP boundary; the SPF-mechanisms spoke documents the per-mechanism evaluation order which determines which mechanism actually AUTHORISES a given connecting IP — when an IP is authorised via a deeply-nested include: cascade, the Outlook reputation engine sees the same spf=pass verdict but attributes the reputation to the outermost include's owner rather than the publishing domain; (iii) Yahoo receiver-side per-mechanism weighting — Yahoo's Mail Domain Reputation model penalises domains whose SPF record carries the deprecated ptr: mechanism per RFC 7208 §5.5; the SPF- mechanisms spoke documents the deprecation status and the per-mechanism DNS-lookup-budget cost (~5 of 10) that Yahoo's reputation engine treats as a negative signal even when the ptr: mechanism happens to authorise the connecting IP; (iv) Apple / iCloud Mail receiver-side per-mechanism weighting — Apple's reputation model heavily penalises permissive +all qualifier presence per the SPF-mechanisms spoke's per-mechanism catalogue; senders publishing +all experience near-total bulk-folder routing on Apple/iCloud receivers regardless of DMARC posture; (v) Comcast / Cox / consumer-ISP receiver-side per-mechanism weighting — consumer-ISP reputation models treat ~all SoftFail as a yellow- flag signal and -all HardFail as a green-flag signal per the SPF-mechanisms spoke's qualifier documentation; consumer-ISP inbox- placement rate divergence between ~all and -all publishers is the canonical deliverability- measurement variable the per-mechanism terminating-qualifier choice produces. Pair this page (the deliverability outcome framework) with the SPF- mechanisms spoke (the per-mechanism byte- grammar reference) when authoring a per- receiver inbox-placement remediation plan — the spoke documents the per-mechanism operational discipline whose aggregate pass-rate drives the receiver-side reputation models this page's deliverability outcomes depend on.
• SPF for Microsoft 365 — the M365-TENANT-DELIVERABILITY-BASELINE prerequisite companion to this email- deliverability business-outcome reference. Where THIS page documents the 14-section OUTCOME-LAYER deliverability framework applicable to any sender (authentication- verdict → reputation → engagement → SMTP-bounce-taxonomy → Postmaster-Tools telemetry → inbox-placement-rate), the SPF-for-M365 spoke is the M365-tenant- SPECIFIC prerequisite-authoring reference for the largest single SPF-authoring population in the deliverability operator field (~400M+ M365 commercial seats globally). The M365 baseline SPF token include:spf.protection.outlook.com is the load-bearing PREREQUISITE that determines whether the M365-tenant's outbound mail produces spf=pass at every major receiving mailbox provider (Gmail, Yahoo, Apple iCloud Mail, Microsoft Consumer / Outlook.com, ProtonMail, Fastmail) — and SPF=pass + DKIM=pass + DMARC=pass is the entry-gate authentication VERDICT every section-1-authentication deliverability check on THIS page presupposes before the deliverability framework's downstream sections (reputation, engagement, bounce-rate) can even begin to apply. A misconfigured or absent M365 SPF token produces SPF=fail across the entire M365 outbound envelope, which in turn collapses DMARC=fail, which in turn breaks every downstream deliverability layer this page documents (Gmail / Yahoo Bulk Sender Requirements 99% authentication floor = immediately violated; Postmaster Tools domain reputation = immediately degraded; bounce rate at receivers enforcing p=reject = elevated). Read the SPF-for-M365 spoke when the deliverability operator running THIS framework is on an M365 tenant — the spoke is the authoritative per-platform SPF-authoring reference that establishes the AUTHENTICATION-PASS deliverability floor every downstream framework section on THIS page presupposes.
• SPF for Google Workspace — the WORKSPACE-TENANT-DELIVERABILITY- BASELINE-PREREQUISITE-WITH-_SPF.GOOGLE.COM- INCLUDE-AUTHORING-DISCIPLINE companion to this email-deliverability business-outcome reference. Where THIS page documents the 14-section OUTCOME-LAYER deliverability framework applicable to any sender (authentication-verdict → reputation → engagement → SMTP-bounce-taxonomy → Postmaster-Tools telemetry → inbox- placement-rate), the SPF-for-Workspace spoke is the Workspace-tenant-SPECIFIC prerequisite-authoring reference for the largest single combined consumer-and- enterprise sending population in the deliverability operator field (~3B+ Gmail consumer accounts + ~9M Workspace business tenants globally). The Workspace baseline SPF token include:_spf.google.com is the load-bearing PREREQUISITE that determines whether the Workspace-tenant's outbound mail produces spf=pass at every major receiving mailbox provider (Gmail, Yahoo, Apple iCloud Mail, Microsoft Consumer / Outlook.com, ProtonMail, Fastmail) — and SPF=pass + DKIM=pass + DMARC=pass is the entry-gate authentication VERDICT every section-1-authentication deliverability check on THIS page presupposes before the deliverability framework's downstream sections (reputation, engagement, bounce-rate) can even begin to apply. A misconfigured or absent Workspace SPF token produces SPF=fail across the entire Workspace outbound envelope, which in turn collapses DMARC=fail, which in turn breaks every downstream deliverability layer this page documents (Gmail / Yahoo Bulk Sender Requirements compliance for ≥5K-msg/day senders, Postmaster Tools domain-reputation scoring, complaint-rate-driven Gmail spam- folder routing, the engagement-signal-based Gmail tab-routing decision between Primary / Promotions / Updates / Forums). The four-axis DELIVERABILITY-VS-WORKSPACE-SPF comparison exposes the structurally- distinct WORKSPACE-DELIVERABILITY- PREREQUISITE roles: (i) Workspace is the only sending platform whose outbound mail is ALSO the dominant consumer-receive-side mailbox — Gmail receives ~1.5B+ active consumer- inbox messages/day and Workspace tenants send mail to Gmail recipients at the highest cross-tenant frequency of any platform; the SPF-for-Workspace spoke documents the SPF-authoring discipline that determines Gmail-to-Gmail and Workspace-to-Gmail SPF=pass rates the deliverability framework on THIS page treats as the load-bearing authentication-verdict-floor; (ii) Workspace Postmaster Tools is the canonical reputation-feedback instrumentation layer this deliverability page documents — Workspace operators publishing v=DMARC1 records register the postmaster.google.com domain for sender-side telemetry; the SPF-for- Workspace spoke documents the SPF-aligned-pass-rate calculation that the Postmaster Tools "Spam rate" / "Domain reputation" / "IP reputation" metrics covered on THIS page consume as their primary scoring input; (iii) Workspace SMTP-relay-from- outside-Workspace coverage gap is the single most common SPF=fail root cause for Workspace tenants — Workspace tenants frequently configure the SMTP-relay service for outbound from on-prem / partner / vendor infrastructure that is NOT covered by the _spf.google.com include; the SPF-for-Workspace spoke documents the canonical ip4: / a: token-supplementation pattern that closes this gap and restores the SPF=pass population the deliverability framework on THIS page treats as load-bearing; (iv) Workspace-tenant operators cohabiting with transactional ESPs (SendGrid / Mailgun / Amazon SES / Postmark / SparkPost) require per-ESP include-token-layering on the Workspace SPF record — the SPF-for-Workspace spoke documents the per-ESP include-token discipline that prevents the 10-DNS-lookup-limit cascade overflow this deliverability framework's authentication-pass-rate floor depends on. Read the SPF-for- Workspace spoke alongside this deliverability framework when the operator is on Google Workspace — the spoke is the AUTHENTICATION-PREREQUISITE reference and this page is the DELIVERABILITY-OUTCOME consumer; the two pages are operationally co-load- bearing for any Workspace-tenant deliverability operator.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DELIVERABILITY- BASELINE-PREREQUISITE-WITH-google._domainkey- CNAME-DELEGATION companion to this email- deliverability business-outcome reference. Where THIS page documents the 14-section OUTCOME-LAYER deliverability framework applicable to any sender (authentication- verdict → reputation → engagement → SMTP-bounce-taxonomy → Postmaster-Tools telemetry → inbox-placement-ceiling), the DKIM-for-Google-Workspace spoke documents the PUBLISHER-INPUT-LAYER deliverability- prerequisite for the ~3B+ Gmail / Workspace seats this deliverability page treats as the canonical inbox-placement reputation- model substrate. Four per-Workspace-tenant per-custom-domain DKIM-publication-vs- deliverability coupling dimensions documented: (i) per-Workspace- tenant Admin Console "Authenticate email" wizard google._domainkey.<tenant- domain> RSA-2048 publication IS the load-bearing DKIM=pass prerequisite for the deliverability-ceiling-ramp THIS page documents — the Workspace- managed 2048-bit RSA keypair generated by the Authenticate-email wizard and published as the p=<base64-pubkey> tag at the per-tenant google._domainkey TXT-RR IS the LOAD-BEARING per-Workspace- tenant per-custom-domain DKIM-verification substrate that produces the receiver-side dkim=pass verdict every per- Workspace-tenant per-custom-domain DMARC- aligned-pass evaluation downstream depends on for the per-receiver per-day Gmail / Yahoo / Outlook / Apple inbox-placement reputation-model verdict-stability THIS page documents the deliverability-ceiling- ramp of; (ii) per-Workspace-tenant gappssmtp.com default-signing- identity vs custom-domain d=-tag alignment publication-discipline as per-tenant per-custom-domain DMARC-aligned- pass-rate floor gate — the spoke documents the canonical Workspace-tenant defect class where the default Workspace per-message DKIM signature uses d=<tenant-domain>.gappssmtp.com which produces dkim=pass but DOES NOT ALIGN with the From: organisational domain under DMARC — every Workspace- tenant deliverability operator must verify the post-publication d=<custom- domain> signing-identity is on the Workspace-tenant's own custom domain (NOT on gappssmtp.com) to keep the per-tenant per-custom-domain DKIM- aligned-pass-rate floor underpinning the per-receiver per-day inbox-placement reputation-model verdict-stability THIS page documents the deliverability-ceiling- ramp of; (iii) per-Workspace-tenant single-selector vs dual-selector publication-discipline as per-tenant per- custom-domain rotation-cadence preservation prerequisite — the spoke documents the per-Workspace-tenant Authenticate-email wizard "Rotate DKIM keys" affordance which publishes a SECOND google._domainkey TXT-RR alongside the first while keeping the OLD selector active for signing, the per- receiver per-MX-host cache-aging window (Gmail, Microsoft 365, Yahoo, Mail.ru) the operator monitors in aggregate reports BEFORE retiring the old selector — the per-Workspace-tenant per-custom-domain rotation-cadence preservation discipline directly underpins the per-receiver per- day inbox-placement reputation-model verdict-stability THIS page documents the deliverability-ceiling-ramp of; (iv) per-Workspace-tenant SPF + DKIM-Workspace-publication-discipline composite as per-tenant per-custom-domain DMARC-aligned-pass-rate floor structural prerequisite — the SPF-for- Workspace spoke documents the application- layer SPF-aligned-pass leg via include:_spf.google.com; the DKIM-for-Workspace spoke documents the application-layer DKIM-aligned-pass leg via google._domainkey CNAME delegation — both per-tenant per- custom-domain application-layer publication-discipline references compose the per-Workspace-tenant per-custom-domain DMARC-aligned-pass-rate floor underpinning the per-receiver per-day inbox-placement reputation-model verdict-stability THIS page documents the deliverability-ceiling- ramp of. Read the DKIM-for-Workspace spoke alongside this deliverability page when AUTHORING the per-Workspace-tenant per- custom-domain DKIM publication-discipline, when AUDITING the per-tenant per-custom- domain DKIM-aligned-pass-rate floor underpinning the deliverability-ceiling- ramp, or when INVESTIGATING per-tenant per-custom-domain deliverability regressions correlating with the post- publication DKIM d=-tag signing-identity alignment-mode publication-decision.
• DKIM explained — DomainKeys Identified Mail (RFC 6376). The cryptographic-signing layer that anchors domain reputation independently of the sending IP.
• DKIM DNS TXT-record byte syntax (RFC 6376 §3.6.1 tag-list grammar) — the DELIVERABILITY-AT-MAJOR-MAILBOX-PROVIDERS-IS-DOWNSTREAM-CONSUMER-OF-PER-SELECTOR-DKIM-TXT-RECORD-BYTE-SYNTAX-CORRECTNESS companion documenting the per-tag byte-level grammar (v=DKIM1 / k=rsa / p=<base64> / s=email / h=sha256 / t=y|s) that the Gmail / Yahoo / Microsoft Outlook / Apple iCloud / Fastmail reputation-model verdicts at the inbox-placement decision consume as the load-bearing cryptographic-validation prerequisite, across FOUR mailbox-provider DKIM-byte-syntax consumer dimensions: (1) Gmail/Yahoo Feb-2024 Bulk-Sender DKIM=pass requirement as downstream consumer of per-selector v=DKIM1 prefix + p=<base64> byte-content correctness — the Feb-2024 bulk-sender requirement for ≥5000 msg/day senders mandates DKIM=pass at the receiver; ANY per-selector TXT-record missing the v=DKIM1 8-byte literal prefix OR carrying a malformed p=-tag (truncated base64, bisected 255-byte chunk split, missing padding) produces dkim=permerror at the receiver and disqualifies the message from the bulk-sender DKIM-pass floor; (2) Microsoft Outlook reputation-model dependence on per-tag k=-cryptosystem byte-token (rsa / ed25519) correctness — the Microsoft Outlook deliverability reputation-model treats ed25519-signed messages with implicit k=rsa default-applied at the verifier as a dkim=permerror verdict-class (cryptosystem-mismatch); the per-selector k=ed25519 byte-token publication discipline is the load-bearing signal that prevents the Outlook reputation-model from misclassifying valid ed25519 signatures; (3) Apple iCloud / Fastmail per-selector s=email service-type byte-tag enforcement as deliverability gate — Apple iCloud and Fastmail's stricter DKIM-verifier implementations honor the per-selector s=-tag service-type restriction (defaulting to s=* if absent, but treating s=email as a deliverability-positive policy signal); the per-selector s=-tag byte-token publication discipline is the load-bearing signal that signals operator-controlled per-service-type DKIM scope, contributing to the per-domain reputation-model score; (4) per-mailbox-provider 255-byte TXT-chunk-split discipline at 2048-bit RSA p=-tag publication — Gmail's DKIM verifier (Gmail postmaster.gmail.com), Yahoo's MX (yahoo-aap.com / yahoodns.net), and Microsoft Outlook's MX (outlook.com / protection.outlook.com) ALL re-concatenate split TXT-strings per RFC 1035 §3.3.14, but the per-DNS-provider chunk-split byte boundary (Route 53, Cloudflare, Azure DNS, GoDaddy, NS1) MUST not bisect base64 padding (== / =) at the trailing string boundary; per-selector chunk-split byte-correctness is the load-bearing publication discipline that prevents per-mailbox-provider verifier permerror under 2048-bit RSA key publication. Byte-syntax correctness across these four mailbox-provider DKIM-byte-syntax consumer dimensions is the load-bearing prerequisite for the cross-provider deliverability posture documented on THIS pillar.
• DKIM best practices — the operator-facing key-cryptography & signing-hygiene reference Gmail / Yahoo Bulk Sender Requirements presuppose — the operator-facing best-practices reference for the DKIM deployment-and-maintenance discipline the Gmail / Yahoo Bulk Sender Requirements (Feb 2024) explicitly presuppose. Where THIS page is the OUTCOME-LAYER reference (the 14-section deliverability framework, the Gmail / Yahoo Bulk Sender Requirements feature list, the Postmaster Tools telemetry stack), the DKIM best-practices spoke is the STANDING-DISCIPLINE reference that determines whether your DKIM-pass rate meets the Gmail / Yahoo bulk-sender 99%-floor every day across the years: RSA-2048 minimum (the Feb 2024 Gmail / Yahoo deprecation of RSA-1024 retired every below-2048-bit operator from bulk-sender eligibility), the ED25519 / RSA dual-algorithm publication for forward-compatibility, the 6-month selector-rotation cadence with overlap-window dual-signing (a botched rotation is the single most common bulk-sender-eligibility regression — temporarily drops DKIM-pass below the Postmaster Tools 99% threshold, which Google then visibly flags), the explicit l=-tag avoidance (body-hash-ceiling attacks are a Postmaster-Tools-visible DKIM-fail signal), the relaxed/relaxed canonicalization for forwarder-survivability (broken canonicalization breaks DKIM across forwarder hops which is the most-cited deliverability regression for mailing-list-routed traffic), the per-provider key-inventory discipline (every SaaS sender + ESP + MTA in your sender inventory needs documented DKIM keys — Postmaster Tools shows degraded reputation per-IP at the sender's IP-block level, and unsigned mail from a forgotten transactional provider degrades the organisational-domain reputation across the entire fleet), and the DKIM-private-key-breach response protocol that determines whether a key-compromise incident becomes a 24-hour rotation-and-revoke or a days-long brand-reputation catastrophe.
• DKIM selectors explained — the SELECTOR-PUBLICATION-DISCIPLINE- AS-DELIVERABILITY-REPUTATION-INPUT companion to this 14-section deliverability framework. Where THIS page is the OUTCOME-LAYER reference (authentication, reputation, content, engagement, throttling, complaint rates, list hygiene, list-unsubscribe- post compliance, Gmail/Yahoo Feb 2024 Bulk Sender Requirements), the DKIM-selectors-explained spoke is the PUBLISHER-SIDE-PUBLICATION-DISCIPLINE reference whose correctness materially drives FOUR major-receiver reputation- model inputs: (i) the per-mail-stream selector inventory and its observability at major mailbox-provider reputation engines — Gmail's Postmaster Tools surfaces DKIM=pass rates per-domain (not per-stream), so a single under-published per-stream selector regression drags the cross-stream domain-level Gmail DKIM=pass rate downward — directly observable in the Postmaster Tools Authentication report as the per-day DKIM=pass-percentage line; (ii) the Gmail/Yahoo Feb 2024 Bulk Sender Requirements DKIM-signing prerequisite — both Gmail (5K+ daily/24h bulk-sender threshold) and Yahoo require DKIM-signing on every outbound message, which requires the operator to publish a working selector at every per-mail-stream owner-name and maintain it across rotations — a regression in even ONE per-stream selector during the rotation overlap window produces Bulk-Sender-Requirements non-compliance for that stream at Gmail / Yahoo, triggering Spam- Folder routing or full Spam- rejection until the selector is repaired; (iii) the per-stream selector publication as Apple iCloud Mail / Outlook.com deliverability input — Apple Mail and Outlook.com both weight DKIM=pass posture heavily in their inbox-placement decisions, so the per-stream selector inventory directly affects the inbox vs spam routing at those receivers — not only at Gmail / Yahoo where Bulk Sender Requirements make the DKIM=pass posture a compliance gate, and (iv) the per-stream selector rotation cadence as a long-term deliverability-stability driver — operators rotating selectors quarterly with correct dual-selector overlap maintain stable Gmail / Yahoo / Outlook / Apple DKIM=pass rates across years; operators who skip rotations or execute rotations with premature old-selector revocation produce multi-day-to- multi-week DKIM=fail spikes at major receivers that depress the per-domain inbox-placement reputation. Pair this 14-section deliverability framework with the DKIM-selectors-explained spoke for the publisher-side selector- publication-discipline reference every major-mailbox-provider reputation-model directly consumes when computing the per-domain inbox-vs-spam routing decision.
• DKIM troubleshooting — the symptom-driven diagnostic reference for the deliverability-degradation root cause — the symptom-driven DKIM debugging spoke operators reach for when this cluster-spanning deliverability reference identifies DKIM-fail as a top-3 root cause of inbox-placement degradation. Where this page is the OUTCOME-LAYER reference (the 14-section deliverability framework covering authentication, reputation, engagement metrics, SMTP bounce taxonomy, feedback loops, list hygiene, the Gmail / Yahoo Bulk Sender Requirements, the Postmaster Tools telemetry stack), the DKIM troubleshooting spoke is the ROOT-CAUSE-LAYER diagnostic reference for the most common authentication-driven deliverability regression: DKIM=fail events visible in Google Postmaster Tools / Microsoft SNDS / Yahoo Sender Hub. Concretely: when this page's section 4 (reputation) shows degraded domain-reputation at Gmail, the operator's first diagnostic step is identifying the DKIM-failure SYMPTOM from the troubleshooting spoke's catalogue — selector NXDOMAIN at fresh deploy (immediate domain-reputation crash), public-key truncation past 255 bytes (intermittent verifier-side failure), TXT-vs-CNAME selector record-type mismatch (provider-rotation-induced regression), signature algorithm rejection at modern Microsoft / Google receivers (RSA-1024 deprecation), key-rotation overlap-window misconfiguration (intermittent failures during rotation), forwarder-injected footer breaking body-hash (mailing-list-routed traffic falling out of DKIM), or BIMI display loss after DKIM regression (visible-brand signal degradation visible to end users before deliverability metrics catch up). Pair this page (the deliverability outcome reference) with the DKIM troubleshooting spoke (the symptom-driven DKIM root-cause companion) when a deliverability incident traces back to DKIM authentication failure — the spoke is the canonical symptom→cause→fix diagnostic ladder for moving the DKIM leg from failing back to passing in a single remediation cycle.
• DMARC troubleshooting — the DMARC-COMPOSITE-VERDICT-FAILURE- AS-DELIVERABILITY-DEGRADATION-ROOT-CAUSE companion to this email-deliverability business-outcome reference. Where THIS page documents the deliverability framework whose per-receiver inbox-placement reputation model consumes per-message authentication outcomes as the canonical deliverability-routing input, the DMARC-troubleshooting spoke documents the composite-verdict diagnostic catalogue whose four DMARC-failure-class rows in RUA aggregate-report streams DIRECTLY DRIVE the per-receiver inbox-placement reputation downgrade at four DMARC-diagnostic-class-to- deliverability-outcome coupling dimensions: (i) spf=pass + dkim=pass + DMARC-fail (both-legs- misaligned) — the canonical "authenticated but unaligned" diagnostic class where both authentication legs verify cryptographically but neither aligns with the per-message From: header organisational-domain, producing DMARC-fail and a per-receiver deliverability downgrade as the publisher's apex-domain reputation regresses; (ii) spf=fail + dkim=fail + DMARC-fail (both-legs- failed) — the canonical infrastructure-degradation diagnostic class where both legs fail outright, producing DMARC-fail and the strongest per-receiver deliverability downgrade (per-receiver reputation models price both-legs-failed clusters as spoofing-indistinguishable); (iii) spf=permerror + dkim=pass + DMARC-fail — the publisher-side SPF-record-defect diagnostic class where the SPF leg permerrors on the receiver-side evaluation, gating the SPF-aligned-pass leg from contributing and forcing the DMARC composite onto DKIM-only, with the per-receiver deliverability downgrade scaling with the per-publisher SPF-permerror-row percentage; (iv) spf=temperror + dkim=temperror diagnostic class — the DNS-infrastructure-outage diagnostic class where receiver-side DNS-fetch failure produces temperror on both legs, with per-receiver deliverability impact proportional to the temperror-row-percentage and the per-receiver retry policy. Read the DMARC-troubleshooting spoke alongside this deliverability reference when diagnosing per-receiver deliverability degradation that correlates with per-publisher DMARC-failure-row clusters, when sequencing the per-failure-class remediation work that restores the per-publisher per-receiver inbox-placement reputation baseline, or when composing per-receiver deliverability-incident response runbooks that bridge the per-message authentication-evaluation outcomes and the per-receiver inbox-placement reputation-model verdict.
• DKIM failures explained — the DKIM-FAILURE-MODE-CATALOGUE-AS- DELIVERABILITY-DIAGNOSTICS-INPUT canonical enumeration companion to this email- deliverability business-outcome reference, and the structural complement to the DKIM-troubleshooting spoke listed above. Where THIS page documents the 14-section OUTCOME-LAYER deliverability framework (authentication-verdict → reputation → engagement → SMTP-bounce-taxonomy → Postmaster-Tools telemetry → inbox-placement outcome), and where the DKIM-troubleshooting spoke is the SYMPTOM-DRIVEN-DEBUGGING root- cause-ladder reference, the DKIM-failures- explained spoke is the FAILURE-MODE-CATALOGUE reference enumerating the per-failure-mode TAXONOMY EXHAUSTIVELY — every distinct DKIM signature-verification failure class (body- hash mismatch via in-transit body modification, signature-tag invalidity at verifier-side parse-time, header-list signature scoping omitting a verifier- required header, c14n simple-vs-relaxed canonicalization mismatch at verifier-side, public-key DNS lookup failure / NXDOMAIN / TXT-string-bounds violation, RSA-key-too- small per RFC 8301 BCP 18 / RFC 8463 floor rejection, l= body-length-limit body-hash truncation drift, multi-DKIM-signature verifier-precedence ambiguity, expired-key x= timestamp drift, replay-protection signature-reuse rejection at modern Gmail / Yahoo receivers per the 2024 bulk-sender framework). The DKIM-troubleshooting spoke catalogues SYMPTOM PRESENTATIONS observers report (selector-NXDOMAIN at fresh deploy, intermittent verifier-side regressions, post-rotation failures); the DKIM-failures- explained spoke catalogues the underlying STRUCTURAL FAILURE MODES that PRODUCE those symptoms — the symptom-cause pairing is many-to-many because a single symptom (e.g., "all messages DKIM-fail at Gmail starting last Tuesday") admits multiple possible failure-mode root causes (key rotation broke selector publication / CDN cache holding old key / RSA-1024 deprecation rolled out at receiver / forwarder-injected body modification newly introduced / signature header-list scoping drift). Pair this page (the deliverability outcome reference) with BOTH the DKIM-troubleshooting spoke (the symptom-driven entry point) AND the DKIM-failures-explained spoke (the failure-mode-catalogue exhaustive enumeration) when a deliverability incident traces back to DKIM authentication failure — the symptom-driven spoke surfaces WHICH symptom is presenting; the failure-mode-catalogue spoke surfaces WHICH structural cause class is producing it; together they form the symptom→cause→remediation diagnostic ladder that converts a DKIM-fail incident from unknown root cause to known fix.
• DKIM canonicalization - the DELIVERABILITY-AT-MAJOR-MAILBOX- PROVIDERS-AS-DOWNSTREAM-CONSUMER-OF- c=ALGORITHM-PAIR-CHOICE companion to this email-deliverability outcome-layer reference. Where THIS page documents the 14-section deliverability framework (authentication- verdict + reputation + engagement + SMTP- bounce-taxonomy + Postmaster-Tools telemetry + inbox-placement outcome), the dedicated DKIM-canonicalization spoke documents the STRUCTURALLY-LOAD-BEARING publisher-side c=header/body-tag pair selection whose four deliverability trade- off dimensions determine the per-mailbox- provider per-day per-domain DKIM=pass survival rate baseline this page's deliverability framework rests on: (i) c=relaxed/relaxed maximises DKIM=pass survival through the dominant MLM/forwarder/mailing-list whitespace- normalisation traffic profile at the cost of allowing the relaxed-header case-folding and trailing-whitespace normalisation tolerance window per RFC 6376 §3.4.2 - operator-default for general transactional/marketing/personal mail traffic because it converts the forwarder-induced DKIM-fail-on-relayed-traffic deliverability-degradation root cause into DKIM-pass-after-relaxed- canonicalization-survives-whitespace- mutation deliverability-preservation outcome; the DKIM-canonicalization spoke documents the relaxed-pair survival contract and the per-major-mailbox- provider per-cohort deliverability-impact differential; (ii) c=simple/simple maximises cryptographic strictness at the cost of breaking on virtually every MLM/mailing-list/enterprise-forwarder traffic stream the deliverability framework's reputation model penalises - the publisher's choice of c=simple/simple is a deliverability-business-impact decision that prioritises signature integrity over per-mailbox-provider inbox-placement rate, and is appropriate ONLY when the mail-stream is confidently pristine-path- only and the cryptographic guarantee is operationally load-bearing; the DKIM-canonicalization spoke documents the simple-pair strictness contract and the per-mail-stream-profile rationale that identifies when the cryptographic guarantee outweighs the deliverability penalty; (iii) Gmail Bulk Sender Requirements (2024) and Yahoo Sender Best Practices both treat DKIM=pass on forwarded/MLM-relayed traffic as a REPUTATION INPUT and penalise senders with high DKIM-fail-due-to-body-hash- mismatch rates that the per- sender Postmaster-Tools telemetry surfaces - this page's deliverability framework rests on the publisher having chosen the c=-tag pair appropriate to the mail-stream's forwarder-exposure profile; the DKIM-canonicalization spoke documents the per-major-mailbox-provider Bulk Sender Requirements alignment with the relaxed-pair operator-default; and (iv) the deliverability impact of an incorrect c=-tag pair choice compounds with the mail-stream's MLM / forwarder traffic share - a publisher whose mail-stream is 80% direct transactional + 20% forwarded notification will experience a ~20%-of-total DKIM-fail deliverability-degradation impact from choosing c=simple/simple instead of c=relaxed/relaxed, which propagates through the reputation model to ALL subsequent mail traffic at the affected mailbox provider regardless of forwarding path; the DKIM- canonicalization spoke documents the operator-decision framework that converts the mail-stream's measured forwarder-traffic-share into an evidence-driven c=-tag pair recommendation the deliverability framework consumes downstream.
• DMARC record tags explained — every tag in the DMARC DNS record (v, p, sp, np, pct, rua, ruf, adkim, aspf, fo, rf, ri) with syntax, defaults, and interaction rules.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the PER-RECEIVER-DELIVERABILITY-HEURISTIC- IS-GATED-ON-PUBLISHER-TERMINAL-DMARC-POLICY- MODE-STATE companion to this email- deliverability reference. Where THIS page documents the per-receiver-organisation deliverability heuristics (sender-reputation, inbox-vs-spam-folder routing, bulk-sender deliverability discrimination), the DMARC- policy-modes spoke documents the UPSTREAM three-state DMARC-enforcement policy-mode ladder whose terminal-state choice at the publisher's apex DMARC TXT record is the LOAD-BEARING UPSTREAM PRECONDITION every per-receiver-organisation per-publisher deliverability outcome THIS page documents structurally depends on. The PER-DMARC- POLICY-MODE-VS-DELIVERABILITY-OUTCOME cross- reference establishes FOUR structurally- distinct per-policy-mode-to-deliverability- outcome coupling dimensions: (i) p=none as canonical NEUTRAL- DELIVERABILITY-HEURISTIC policy-mode state at every receiver-organisation — under p=none publication, the per-receiver deliverability heuristic treats the publisher as DMARC-NON-ENFORCING; the per-publisher sender-reputation score receives NO DMARC-enforcement-state reward (and at receivers implementing 2024+ bulk- sender requirements like Gmail + Yahoo, p=none on bulk-sender domains produces deliverability PENALTY heuristics for non-2024-bulk-sender-requirement- compliant senders); the DMARC-policy-modes spoke documents p=none as the OBSERVATION-ONLY policy-mode whose publication produces NEUTRAL-AT-BEST / PENALTY-AT-WORST deliverability heuristics across the receiver-organisation population; (ii) p=quarantine; pct=10 through pct=100 as PARTIAL- COVERAGE-RAMP deliverability heuristic with the per-percentage-coverage-vs-sender- reputation-reward linear relationship — under p=quarantine; pct=10, the per-receiver deliverability heuristic treats the publisher as DMARC-PARTIALLY- ENFORCING with a 10%-coverage sender- reputation reward; the per-publisher sender- reputation score scales linearly through the ramp until pct=100 produces 100%-coverage per-receiver-organisation DMARC-enforcing sender-reputation reward; the DMARC-policy-modes spoke documents the pct=-tag per-percentage-coverage semantics whose per-percentage-coverage rate is the canonical sender-reputation-reward scaling dimension during the policy-mode ramp; (iii) p=reject; pct=100 as CANONICAL TERMINAL-STATE MAXIMUM- DELIVERABILITY-REWARD policy-mode state with the strongest per-receiver-organisation sender-reputation signal — under p=reject; pct=100, the per- receiver deliverability heuristic treats the publisher as DMARC-FULLY-ENFORCING with the MAXIMUM sender-reputation reward at every receiver-organisation; the per-publisher legitimate-aligned mail receives canonical inbox-folder routing (vs spam-folder / bulk-folder) at the receiver-side deliverability heuristic decision boundary; the DMARC-policy-modes spoke documents p=reject; pct=100 as the canonical TERMINAL-STATE author-domain enforcement-posture whose publication maximises per-receiver-organisation deliverability outcomes; (iv) sp= subdomain-policy-mode tag-value as load-bearing per-subdomain- emitting-mail-stream deliverability coordination prerequisite — publishers using subdomains as per-vendor / per-stream mail-emission segmentation (transactional / marketing / per-vendor SaaS subdomain) MUST publish a per-subdomain DMARC posture (via the apex sp= tag default OR a per-subdomain explicit DMARC record) at p=quarantine or p=reject for the per-subdomain mail-emission stream to inherit the per- receiver-organisation sender-reputation reward from the apex policy-mode publication; a publisher with p=reject at the apex but sp=none for subdomains DENIES the per-receiver- organisation sender-reputation reward for per-subdomain mail-emission streams — a canonical deliverability defect class for publishers using subdomain segmentation; the DMARC-policy-modes spoke documents the sp= subdomain-policy-mode coordination tag-value semantics whose per- subdomain enforcement posture is the load- bearing per-subdomain deliverability coordination prerequisite. Read THIS email- deliverability reference WITH the DMARC- policy-modes spoke when the per-publisher DMARC-policy-mode-vs-deliverability-outcome audit step arrives: the deliverability page documents the PER-RECEIVER-ORGANISATION DELIVERABILITY HEURISTICS, the DMARC-policy- modes spoke documents the THREE-STATE AUTHOR-DOMAIN ENFORCEMENT-POLICY-MODE LADDER whose terminal-state choice at the publisher's apex DMARC TXT record is the upstream precondition every per-receiver-organisation per-publisher deliverability outcome structurally depends on.
• DMARC policy rollout — the rollout journey from p=none through p=quarantine to p=reject. DMARC enforcement is now a baseline deliverability prerequisite per Gmail / Yahoo Bulk Sender Requirements.
• DMARC deployment checklist — the operator quick-reference companion to the rollout deep dive: prerequisites, per- phase action items, per-phase exit criteria, decision matrix, FAQ.
• DMARC aggregate (RUA) reports — the daily XML stream that surfaces every authentication outcome per source IP per recipient receiver. The authentication-side companion to the postmaster-tools triad.
• DMARC reporting pipeline — the end-to-end observability infrastructure Feb 2024 Gmail / Yahoo bulk-sender compliance requires — the END-TO-END OBSERVABILITY-INFRASTRUCTURE operational reference for the daily RUA + RUF report stream the Feb 2024 Gmail / Yahoo bulk-sender requirements this deliverability page documents STRUCTURALLY DEPEND on. Where THIS deliverability page documents the business-outcome layer (DMARC enforcement requirement at 5000+ messages / day, the one-click List-Unsubscribe RFC 8058 mandate, the ≤0.3% complaint-rate ceiling, the 90-day rolling DMARC pass-rate floor BIMI eligibility transitively depends on), the reporting-pipeline spoke documents the 6-stage end-to-end operational architecture every operator MUST run to OBSERVE compliance with each of those business-outcome prerequisites: Stage 1 ingestion (the IMAP / Microsoft Graph inbound-mailbox transport layer the daily report stream arrives over from every receiving organisation — Gmail, Yahoo, Microsoft, AOL, the major ESP receivers), Stage 2 format detection and extraction (RUA XML / ZIP / GZ / TAR.GZ multi-format envelope), Stage 3 parsing (the per- record auth_results + policy_evaluated + policy_published XML traversal that materialises the per-source-IP-per-day DMARC pass-rate counters operators compare against the Gmail / Yahoo bulk-sender DMARC-enforcement prerequisite), Stage 4 storage and deduplication (the dmarc_reports / dmarc_records persistence layer the 90-day rolling-window BIMI- eligibility computation reads against), Stage 5 retention policies, and Stage 6 analysis and alerting (the per-source-IP / per-reporter / per-record drill-down views that surface the rolling-window pass-rate measurements the deliverability SLA depends on). Plus the dedicated IMAP- and Microsoft-Graph-setup sections that document the inbound-mailbox transport-layer configuration every operator MUST configure before any Feb 2024 compliance observability materialises. Read the reporting- pipeline spoke when a deliverability operator asks "what is the end-to-end operational architecture that observes the Feb 2024 DMARC bulk-sender compliance requirements this deliverability page documents", "which per-stage failure in my report pipeline explains why the rolling-window DMARC pass-rate counter in my dashboard does not match the Postmaster Tools DMARC counter", or "how do I configure the inbound-mailbox transport layer every aggregate report I receive arrives over before any deliverability SLA becomes observable" — the spoke is the authoritative end-to-end operator reference for the report-stream observability infrastructure the Feb 2024 deliverability compliance layer structurally depends on.
• Phishing protection — the threat-model companion to this deliverability page. Deliverability and phishing protection share one cause-and- effect chain: every sender-side control this page documents (SPF, DKIM, DMARC enforcement, ARC preservation, BIMI logo display, MTA-STS / TLS-RPT, sender-warmup discipline, list hygiene, FCrDNS) is ALSO an anti-phishing control because the same controls that earn inbox placement for legitimate mail are the controls that deny spoofed mail the same placement. Read the phishing-protection page when stake- holders ask "why does enforcement matter beyond reputation" — it catalogues the seven phishing attack patterns (look-alike-domain spoofing, exact-domain spoofing, display-name spoofing, hijacked legitimate-domain abuse, subdomain abuse on unprotected child labels, vendor- compromise spear-phishing, business-email- compromise wire-fraud) and maps each to the deliverability-control that prevents it (apex+sp=reject DMARC, MTA-STS+TLS-RPT, BIMI for visual verification, ARC for forwarder integrity, per-team brand- domain isolation).
• ARC (Authenticated Received Chain) explained — RFC 8617: the standard that preserves original DMARC verdicts across forwarding hops. Critical for senders whose mail traverses mailing lists or third-party forwarders.
• BIMI explained — Brand Indicators for Message Identification. Logo display at supporting receivers lifts open rates and engagement, which feeds back into engagement-reputation.
• BIMI Verified Mark Certificates (VMC and CMC) — the trademark-attestation companion that gates the BIMI engagement-reputation lift above — the BIMI-explained pillar above documents how brand-logo display at supporting receivers translates into the engagement- reputation lift this deliverability page models in the open-rate-to-engagement-to- reputation feedback loop, but the actual logo-rendering pipeline at Gmail / Apple Mail / Yahoo / Fastmail / Outlook will NOT honour a BIMI record without a valid Verified-Mark-Certificate (or, for the Gmail-only minority case, a Common-Mark- Certificate accepted only by Gmail). The VMC commercial-acquisition workflow is therefore the STRUCTURAL GATE between the BIMI-protocol-publication step on this deliverability page (which gets you the DNS record in place) and the engagement- reputation lift that actually moves the deliverability needle (which requires the logo to render in the inbox). Operators reading this deliverability page to understand the BIMI engagement-reputation lift in the open-rate-feedback loop need the BIMI-certificates spoke as the TRADEMARK-ATTESTATION COMPANION documenting: which of the two issuing CAs (DigiCert vs Entrust) accepts which trademark evidence pack (registered trademark for VMC vs unregistered mark for CMC), the 12-month VMC renewal cadence that operators must build into the deliverability-program calendar, the byte-level PEM-bundle file format the BIMI record's a= URL must serve (SVG-Tiny-PS-embedded-in-X.509 with the certificate-chain ordering), the mailbox- provider-specific rendering coverage matrix (VMC supported by Gmail + Apple Mail + Yahoo + Fastmail + Outlook; CMC currently only honoured by Gmail), and the canonical rendering-failure-pattern taxonomy (logo-not-rendering even with valid VMC, mailbox-provider-specific quirks where Outlook honours VMC but Apple Mail rejects, the rendering-suppression cases triggered by DMARC enforcement gaps that cascade back into the deliverability feedback loop). Read this spoke when the engagement-reputation lift modelled on this page is failing to materialise despite a BIMI record being published — the bottleneck is almost always the VMC issuance or renewal workflow the BIMI-certificates spoke documents.
• BIMI SVG Tiny PS file-format requirements — the BIMI engagement-reputation lift this deliverability page models in the open-rate-to-engagement-to-reputation feedback loop has TWO non-policy prerequisites operators must satisfy after the BIMI DNS record is published: the FIRST is the Verified-Mark-Certificate (covered in the entry immediately above); the SECOND is the SVG-Tiny-PS file-format compliance of the actual logo asset the BIMI record's l= URL serves. Even a tenant with a valid VMC will still fail to render the brand logo (and therefore fail to capture the engagement-reputation lift modelled on this page) if the SVG asset violates Tiny PS profile constraints: scripts, animations, external resources, embedded metadata, non-square aspect ratio, or missing baseProfile="tiny-ps" attribute each individually suppress the logo rendering at the mailbox-provider side. The SVG-requirements spoke is therefore the SECOND STRUCTURAL GATE between the BIMI-protocol-publication step on this page (which gets the DNS record in place) and the engagement-reputation lift that moves the deliverability needle (which requires the logo to actually render in the inbox). Operators reading this deliverability page to understand the BIMI engagement-reputation lift in the open-rate-feedback loop need the BIMI-SVG-requirements spoke as the TECHNICAL-FILE-FORMAT COMPANION (paired with the BIMI-certificates entry above for the COMMERCIAL-TRADEMARK-ATTESTATION arm) documenting: the SVG Tiny PS 1.2 profile constraints (which features are allowed — basic shapes, paths, gradients, transforms — and which are forbidden — scripts, animations, external resources, metadata, titles, embedded fonts), the square-aspect-ratio viewBox="0 0 SIZE SIZE" requirement, the baseProfile="tiny-ps" document-element attribute, the ~32 KB unminified / ~8 KB minified file- size operational target, the application/svg+xml / image/svg+xml MIME-type- serving requirements, the background-color requirements that ensure the logo renders distinctly against both light and dark inbox themes (a deliverability-program detail that directly affects the engagement-rate lift this page models), and the canonical validation tools (BIMI Group's SVG validator, Cloudflare's BIMI inspector, Mailhardener's BIMI lookup tool). Read this spoke when the engagement- reputation lift modelled on this page is failing to materialise despite a valid VMC being in place — the bottleneck is almost always the SVG file-format compliance the BIMI-SVG-requirements spoke documents (especially in marketing-team-owned-asset workflows where the design tool exports SVGs with embedded metadata or non-Tiny-PS-conformant features by default).
• MTA-STS explained — SMTP MTA Strict Transport Security (RFC 8461). The transport-security layer that Gmail Bulk Sender Requirements count toward the 100-percent-encryption-rate floor.
• MTA-STS vs DANE for SMTP — the DELIVERABILITY-TRANSPORT-LAYER- TECHNOLOGY-CHOICE companion to this email- deliverability business-outcome reference. Where THIS page documents the FOUR-STAGE DELIVERY FUNNEL applicable to any sender (sender → MX accept → bounce vs accept → spam-folder vs inbox-folder placement) including the TRANSPORT-LAYER stage gate (Gmail Bulk Sender Requirements count MTA-STS adoption toward the 100-percent- encryption-rate floor), and the adjacent MTA-STS-explained spoke documents MTA-STS as the transport-security layer in isolation, the MTA-STS-vs-DANE spoke is the TECHNOLOGY-CHOICE-DECISION-TREE companion documenting the head-to-head comparison whose answer determines WHICH transport-layer technology the sender deploys to maximise the per-receiver encryption-rate coverage that THIS page's Gmail Bulk Sender Requirements floor consumes as a load-bearing deliverability input. Four DELIVERABILITY- VS-TRANSPORT-TECHNOLOGY-CHOICE dimensions: (i) per-receiver encryption-rate coverage maximisation — different receivers support different transport- security technologies; Gmail / Outlook / Yahoo support BOTH MTA-STS AND DANE; Yandex and some Eastern European MTA fleets prefer DANE; some smaller receivers support only MTA-STS — the spoke documents the per-receiver support matrix that determines which technology (or both) maximises the sender's encryption-rate coverage toward the Gmail Bulk Sender Requirements floor THIS page documents; (ii) per-counterparty B2B-mail deliverability coverage — high- volume B2B senders need transport-layer coverage to their high-value counterparty domains' inbound MX infrastructure; the spoke documents the per-counterparty assessment methodology (which counterparties publish DANE-TLSA records, which publish MTA-STS policy files, which publish neither) that determines the sender's optimal outbound-MTA support matrix for defending per-counterparty deliverability against transport-layer TLS-policy enforcement at the receiver; (iii) operational-complexity-vs- coverage trade-off — DANE adds DNSSEC operational complexity (DNSSEC- signed zones, parent-zone DS-record coordination, TLSA-rotation discipline synchronised with certificate renewal) compared to MTA-STS (HTTPS-policy file + single TXT record + max_age cache bounding); the spoke documents the per- sender operational-complexity assessment determining whether the additional deliverability coverage DANE provides at DANE-only-publishing receivers is worth the operational complexity overhead vs deploying MTA-STS only and accepting the smaller-but-simpler coverage matrix; (iv) TLS-RPT-driven per-receiver-coverage observability — the spoke documents how the same TLS-RPT JSON aggregate-report channel (RFC 8460) carries per-receiver transport-layer-failure evidence for BOTH DANE-validation failures and MTA-STS-policy-validation failures, allowing the deliverability operator running THIS framework to triangulate per-receiver-cohort transport-layer- failure attribution against the receiver-side encryption-rate floor compliance the Gmail Bulk Sender Requirements track. Pair this email- deliverability framework (the business- outcome reference) with the MTA-STS-vs- DANE spoke (the transport-technology decision-tree) when scoping the per-sender transport-layer-coverage component of the deliverability program — the spoke is the canonical decision- reference whose answer optimises the per-receiver encryption-rate coverage toward the Gmail Bulk Sender Requirements floor THIS page documents as a load- bearing deliverability input.
• MTA-STS for Google Workspace — the DELIVERABILITY-WORKSPACE-MX- RECEIVE-TLS-POLICY-ENFORCEMENT-AS- DELIVERABILITY-GATE-WHEN-MODE-ENFORCE companion to this email-deliverability business-outcome reference. Where THIS page documents the FOUR-STAGE DELIVERY FUNNEL applicable to any sender (sender → MX accept → bounce vs accept → spam-folder vs inbox-folder placement) including the TRANSPORT-LAYER stage gate (Gmail Bulk Sender Requirements count MTA-STS adoption toward the 100-percent-encryption-rate floor), the Workspace-MTA-STS spoke is the Workspace- RECEIVER-SIDE-deliverability-gate companion documenting the Workspace- tenant MTA-STS publication mechanics whose enforced-mode policy file governs whether outbound mail from ANY sender SUCCESSFULLY DELIVERS to Workspace- hosted recipients (the gmail.com consumer-mail population, plus the ~3B+ Workspace-tenant custom-domain recipients). A Workspace-tenant publishing mode: enforce with the Workspace MX allow-list (aspmx.l.google.com + alt{1,2,3,4}.aspmx.l.google.com) creates a TLS-policy enforcement gate — any sending MTA that DOES NOT respect the policy (no STARTTLS, an invalid certificate, an MX hostname not in the mx: allow-list because the sender cached a stale policy past max_age:) gets its delivery refused at the Workspace MX boundary, appearing in the SENDER's bounce catalogue as a transport-layer SMTP rejection. Read the Workspace MTA-STS spoke alongside this page when the deliverability operator running THIS framework needs to scope Workspace- RECEIVER deliverability risk — Workspace receivers represent a substantial fraction of any high-volume sender's delivery population, and the Workspace MTA-STS publication discipline (TXT-record id=-keyed policy-file caching, Workspace's MX inventory churn during rolling MX upgrades, the mode: testing → mode: enforce rollout timeline) is the receiver-side rate-limiting variable governing sender-side deliverability outcomes to the Workspace half of the global receiver population.
• MTA-STS for Microsoft 365 — the DELIVERABILITY-M365-EXCHANGE- ONLINE-RECEIVE-TLS-POLICY- ENFORCEMENT-AS-DELIVERABILITY-GATE- WHEN-MODE-ENFORCE companion to this email-deliverability business-outcome reference. Where THIS page documents the FOUR-STAGE DELIVERY FUNNEL applicable to any sender (sender → MX accept → bounce vs accept → spam-folder vs inbox-folder placement) including the TRANSPORT-LAYER stage gate (Gmail Bulk Sender Requirements count MTA-STS adoption toward the 100-percent-encryption-rate floor), the M365-MTA-STS spoke is the M365-RECEIVER-SIDE-deliverability- gate companion documenting the M365- tenant MTA-STS publication mechanics whose enforced-mode policy file governs whether outbound mail from ANY sender SUCCESSFULLY DELIVERS to M365-hosted recipients (the outlook.com / hotmail.com consumer- mail population, plus the ~400M+ M365-tenant custom-domain recipients). Concretely, the spoke documents FOUR M365-receiver- deliverability-gate dimensions: (i) M365-tenant publishing mode: enforce with the M365 MX allow-list (typically mx: *.mail.protection.outlook.com wildcard covering the tenant-scoped and Microsoft-managed regional MX-fanout-targets) creates a TLS-policy enforcement gate — any sending MTA that DOES NOT respect the M365 policy (no STARTTLS, invalid certificate, MX hostname not in the mx: allow-list because the sender cached a stale policy past max_age:) gets its delivery REFUSED at the M365 MX boundary, appearing in the SENDER's bounce catalogue as a transport-layer SMTP rejection; (ii) M365-receiver-side deliverability-gate semantics are STRUCTURALLY DISTINCT from Gmail/ Workspace consumer-side deliverability-gate semantics — where Workspace receivers process inbound MTA-STS enforcement at the 5-host tier'd aspmx.l.google.com inventory boundary (the sibling Workspace MTA-STS spoke), M365 receivers process inbound MTA-STS enforcement at the single-host <tenant>.mail.protection.outlook.com target boundary that internally fans out to Microsoft-managed regional load-balancers — a STRUCTURALLY SIMPLER allow-list topology the sending MTA's policy- cache must respect; (iii) M365-receiver-side MTA-STS-policy- cache-rollover semantics drive sender-side deliverability instability during M365-tenant domain-migration events — when an M365 tenant migrates from one tenant-scoped FQDN to another (during M&A consolidation, tenant-rename, or cross-region Exchange Online migration), the M365 MTA-STS policy file's mx: directive update must propagate through the global sending-side MTA policy-cache population BEFORE the old tenant-scoped FQDN MX is decommissioned — failure to coordinate the policy-cache- rollover with the MX-decommission causes a deliverability-cliff for senders whose cached policy still points to the old MX; and (iv) M365-receiver-side deliverability-gate covers the ~400M+ commercial-seat global recipient population — M365 receivers represent a substantial fraction of any high-volume sender's delivery population (enterprise + Government Cloud + GCC High + DoD-tenant + outlook.com / hotmail.com consumer mail), and the M365 MTA-STS publication discipline (TXT-record id=-keyed policy-file caching, M365 tenant's MX inventory churn during rolling FQDN upgrades, the mode: testing → mode: enforce rollout timeline) is the receiver-side rate-limiting variable governing sender-side deliverability outcomes to the M365 half of the enterprise receiver population. Read the M365 MTA-STS spoke alongside this page when the deliverability operator running THIS framework needs to scope M365-RECEIVER deliverability risk — the sibling Workspace-MTA-STS spoke documents the Workspace-receiver half of the enterprise-receiver deliverability matrix; together the two spokes cover the global enterprise-receiver MTA-STS publication discipline this page's deliverability framework operationalises against.
• TLS-RPT explained — SMTP TLS Reporting (RFC 8460). The DMARC-aggregate-report equivalent for transport-encryption failures.
• MTA-STS policy file syntax — the TRANSPORT-LAYER-DELIVERABILITY-IMPACT byte-level companion to this email- deliverability business-outcome reference. Where THIS page documents the FOUR-STAGE DELIVERY FUNNEL (sender → MX accept → bounce vs accept → spam-folder vs inbox-folder placement) including the TRANSPORT-LAYER stage gate (Gmail Bulk Sender Requirements count MTA-STS adoption toward the 100-percent-encryption-rate floor + Microsoft 365 Inbound Connector requires opportunistic TLS) — i.e. the BUSINESS-OUTCOME CHAIN MTA-STS sits inside — the mta-sts-policy-syntax spoke documents the BYTE-LEVEL POLICY-FILE FORMAT whose AUTHORING-time errors directly cause INBOUND-DELIVERABILITY DAMAGE at enforcing receivers. The plain-text mta-sts.txt policy file published at https://mta-sts.<domain>/.well-known/mta-sts.txt with the version: STSv1 + mode: enforce|testing|none + repeated mx: directives + max_age: <seconds> tag-value grammar (RFC 8461 §3.2) — when the policy file is byte-incorrectly authored (missing version: tag, missing terminal CRLF, incorrect max_age: value, typo'd mx: pattern), the enforcing receiver fails MTA-STS policy validation and either DROPS the message on the floor (silent transport failure) or downgrades to cleartext+delayed-retry — both routes register in the deliverability funnel as INBOUND- DELIVERABILITY DAMAGE that does NOT surface in DMARC aggregate reports (since aggregate reports only cover outbound authentication outcomes, not inbound transport-security failures). Read the mta-sts-policy-syntax spoke when triaging a TLS-RPT-reported deliverability-damage scenario whose root cause is a byte-level error in the published mta-sts.txt policy file rather than an MX-misconfiguration or certificate-chain failure — the byte-level syntax reference is the load-bearing operator-reference for the AUTHORING-side of the transport- security deliverability cliff.
• Reverse DNS and PTR records explained — FCrDNS-valid PTR records are the receiver's primary signal that the sending IP is operated by a legitimate mail provider.
• MX records explained — the DNS foundation that determines which receiving MTA accepts mail for the recipient domain. Stage 1 of the delivery funnel.
• DNS propagation explained — TTL discipline for every authentication- record change. Bounds how quickly authentication fixes become visible to receivers.
• DMARC for SaaS senders — deployment guide for the multi-tenant SaaS sender pattern. Deliverability is the primary ROI argument for SaaS-sender DMARC adoption.
• DMARC for transactional email — deployment guide for transactional / notification senders (password resets, order confirmations, receipts) where inbox placement is mission-critical.
• DMARC for Microsoft 365 — deployment guide for M365 tenants. Tenant reputation is one of the four reputation sub-scores at M365 inbound.
• DMARC for Office 365 hybrid — hybrid Exchange tenants are the canonical case where the deliverability framework documented HERE BIFURCATES across multiple parallel outbound-relay paths under a single author-domain, each with its OWN inbox-placement outcome at every major receiver. Documents FOUR per-connector deliverability-KPI dimensions (EXO outbound send-connector path vs on-prem Exchange Server send- connector path vs centralized mail transport relay path vs direct send path — each carries a DISTINCT outbound IP set whose IP reputation at Gmail SNDS, Outlook SNDS, Yahoo Sender Hub, and Apple Mail Postmaster differs per-path and is observable per-path only via per-source-IP RUA-aggregate-report row attribution; per-connector DMARC-pass- rate at the SAME author-domain — on-prem Exchange-signed DKIM may pass while EXO- signed DKIM fails, or SPF-via-on-prem-IP may pass while SPF-via-EXO-include fails, producing per-connector pass-rate bifurcation the receiver reputation model scores PER inbound source IP, not per author-domain; per-connector TLS-RPT success/failure rate at the receiver- side STARTTLS handshake — on-prem-relay- path TLS handshake outcomes diverge from EXO-relay-path TLS handshake outcomes because the on-prem cert chain, cipher suites, and SNI behaviour differ from EXO's *.mail.protection.outlook.com baseline; per-connector List-Unsubscribe and complaint-rate signal — bulk-sender notification mailings routed via on-prem Exchange may lack the List-Unsubscribe- Post one-click header EXO automatically injects, dropping the Feb-2024 Gmail/ Yahoo bulk-sender compliance evidence for that per-connector subset of traffic). Per-connector deliverability KPIs require per-connector observability: the operator MUST disambiguate inbox-placement outcomes by sending-IP attribution to attribute deliverability shifts to the right path. Spoke documents the coexistence-mode mailflow, per-connector authentication path, and the per-path DMARC alignment audit prerequisite to Phase-3 p=reject ramp — the per-path deliverability observability gating prerequisite for the hybrid tenant case in this OUTCOME-LAYER framework.
• DMARC for Google Workspace — deployment guide for Workspace tenants. Postmaster Tools is the canonical observability for Workspace-sending domains.
• DMARC for cPanel & shared hosting (SMB Feb-2024 compliance procedure) — the SHARED-HOSTING-SPECIFIC compliance procedure for the Feb 2024 Gmail/Yahoo bulk-sender requirements this OUTCOME-LAYER deliverability page documents. Where this page is the operator-facing reference for the universal Gmail/Yahoo Bulk Sender Requirements (5000+ messages/day threshold, DMARC enforcement, one-click List-Unsubscribe per RFC 8058, ≤0.3% complaint rate via Postmaster Tools / SNDS / Yahoo Sender Hub), the cPanel deployment guide is the platform-specific compliance procedure for the SMB / shared-hosting cohort the enterprise-flavoured M365 and Workspace guides above do not cover: Bluehost, HostGator, SiteGround, A2 Hosting, GoDaddy cPanel, Namecheap Stellar Plus, Hostinger, InMotion, DreamHost cPanel, and every other Exim-based shared-hosting platform. The cPanel guide documents the distinct deliverability concerns this layer faces: (i) shared outbound IPs (the canonical commercial-honesty caveat — reputation is POOLED across tenants on shared cPanel hosting, so any single tenant's spam load drops deliverability for every other tenant even with perfect DMARC + DKIM publication; bulk marketing senders SHOULD NOT use shared cPanel for high-volume mail), (ii) the Email Deliverability page (cPanel's end-user UI) and its Install Suggested Record flow for the auto-generated SPF + DKIM-default- selector pair (cPanel does NOT auto-generate DMARC — operator MUST publish the _dmarc.<domain> TXT manually), (iii) WHM-administrator persona coverage (full Exim configuration, server- wide DKIM signing, outbound IP inventory) vs the limited end-user cPanel persona, (iv) provider-managed SPF include patterns and their 10-lookup-cap implications when the tenant layers on Mailchimp/SendGrid for bulk marketing, (v) the default._domainkey selector convention and its single-selector-rotation gotcha vs the dual-selector overlap-window discipline enterprise platforms use, and (vi) the Postmaster Tools / SNDS observability gap (shared-IP cPanel operators do not have dashboard visibility into the IP-reputation telemetry this page catalogues — they receive only domain-level DMARC aggregate reports). Read this page (the universal Gmail/Yahoo bulk-sender outcome-layer reference) with the cPanel guide (the SMB/shared-hosting-specific compliance procedure) for the operator cohort the M365 + Workspace deployment guides above do not cover.
• DMARC for Shared Hosting — shared-IP-reputation deliverability floor on Plesk / DirectAdmin / ISPConfig / generic-no-control-panel platforms — the SHARED-IP-REPUTATION-DELIVERABILITY-FLOOR companion to this email-deliverability business-outcome reference for the SMB operator population whose deliverability outcome is bounded by the collective reputation of the shared-IP pool the operator's outbound mail traverses. Where THIS page documents the universal Gmail/Yahoo Bulk Sender requirements, Postmaster Tools / SNDS / Yahoo Sender Hub observability, complaint-rate ceiling, and the encryption-rate floor for any operator regardless of sending infrastructure, the shared-hosting spoke documents the SHARED-IP-POOL-SPECIFIC DELIVERABILITY FLOOR the shared-hosting operator persona cannot rise above without migrating off the shared pool: co-tenant authentication- failure-rate sets the shared-IP-pool's reputation floor at each major receiver (one misconfigured co-tenant on the same /24 drives every tenant's complaint rate toward the 0.3% ceiling); shared-IP-pool operators do NOT have Postmaster Tools domain-level dashboard visibility into the IP-reputation telemetry this page catalogues (only the shared hoster operating the pool can register the shared IP at Postmaster Tools — individual tenants see only their own domain's RUA-aggregated DMARC verdicts); the shared-IP-pool's collective List- Unsubscribe compliance (per RFC 8058 one- click) is determined by the worst-compliant co-tenant — receivers correlate the compliance signal at the IP level not the domain level for shared-IP-pool senders; the encryption-rate floor (Gmail / Yahoo 99%+ TLS-secured-mail expectation) on shared-hosting is determined by the hoster's Postfix / Exim STARTTLS configuration not the tenant's own configuration (a hoster operating without opportunistic outbound TLS reduces every tenant's encryption-rate signal). Read the shared-hosting spoke when this page's framework leaves the shared-IP-pool tenant with no per-domain remediation lever — the spoke documents the structurally-different observability + ramp + remediation surface the shared-hosting operator persona faces that this universal framework does not anticipate.
• Email security glossary — DELIVERABILITY-THREAT-CLASSIFICATION vocabulary for sender-reputation degradation triggered by attacker campaigns — the DELIVERABILITY-THREAT-CLASSIFICATION companion to this email-deliverability business-outcome reference for the operator population reaching the sender-reputation-degradation diagnosis decision point. Where THIS page documents the universal Gmail/Yahoo Bulk Sender framework + Postmaster Tools / SNDS / Yahoo Sender Hub observability + the 0.3% complaint-rate ceiling, the email-security glossary documents the THREAT-CLASS TAXONOMY explaining WHY receivers respond to specific attacker-campaign patterns with sender-reputation degradation that this universal framework treats as end-state outcomes: receivers degrade the sender-domain reputation specifically when the domain is targeted by spoofing (exact-domain impersonation triggering reflexive spam-folder routing across the receiver's entire user base), lookalike- domain phishing (typo-squatting attacks against the brand triggering receiver-side reputation cross-contamination when receivers cannot distinguish the legitimate domain from the lookalike at scale), account-compromise BEC (compromised legitimate accounts sending attacker payload from authenticated infrastructure triggering temporary reputation collapse during the incident-response window), vendor invoice fraud (supply-chain attacks landing in the brand's accounts-payable correspondence triggering partner-side complaint surges that downstream into the operator's complaint- rate KPI), and APT-driven DKIM- replay attacks (cryptographic- layer bypass attacks producing authentication-passing receiver-side spam-classification that mechanically degrades reputation despite passing authentication). Read the email-security glossary when this deliverability framework's sender-reputation-degradation diagnosis requires distinguishing the attacker-campaign root cause from the operator-misconfiguration root cause — the glossary is the authoritative reference for the threat-class taxonomy that determines whether the next step is operator-side authentication-hardening, receiver-side appeal, threat-feed monitoring activation, or incident-response escalation.
• Business Email Compromise (BEC) defence — the financial-loss attack class whose exact-domain spoofing variant degrades a legitimate sender's reputation across every major receiver simultaneously. When an operator's domain is used in a BEC campaign, Gmail / Outlook / Yahoo reputation models react to the SPF/DKIM/DMARC fail traffic spike at the per-domain reputation surface documented in this deliverability framework — driving legitimate transactional flow into spam folders alongside the spoofed campaign. The BEC spoke is the THREAT-CLASS anchor whose enforcement-tier defence (DMARC p=reject) closes the spoofing window upstream of the reputation degradation THIS page's outcome-layer framework observes.
• CAA records explained — the PER-DOMAIN-CA-ISSUANCE-RESTRICTION- PUBLICATION-DISCIPLINE-AS-UPSTREAM-CONTROL- ON-BIMI-VMC-DISPLAY-ELIGIBILITY-AND-MTA-STS- DEPLOYMENT-AND-PER-MX-HOST-STARTTLS-CERT- RENEWAL companion to this deliverability framework. Where THIS page documents the per-publisher per-domain reputation / sender-eligibility / authentication-pass- rate / encryption-rate / complaint-rate deliverability outcomes the per-receiver per-domain reputation model evaluates, the CAA-records-explained spoke is the load- bearing UPSTREAM PKI-issuance-layer control-publication-discipline reference whose RFC 8659 CAA-RR primitive at <domain> CAA-RR scope gates three load-bearing deliverability outcomes whose drift the per-publisher deliverability framework structurally observes. The CAA-vs-deliverability- outcome cross-layer coupling establishes four specific upstream-CAA-control-to- downstream-deliverability-outcome dimensions: (i) CAA-vs-BIMI- VMC-issuance gating — per- publisher BIMI display eligibility at the receiver-side inbox-render layer requires a verified VMC (Verified Mark Certificate) issued by a CA listed in the publisher's CAA issue tag publication; an incompatible CAA- RR (CAA published listing only CA-X whilst the per-publisher VMC was procured at CA-Y) silently blocks VMC renewal at CA-Y refusal — per-receiver Gmail / Yahoo / Apple Mail BIMI-display indicator drops, undermining the per- domain brand-recognition deliverability outcome (the visual authenticated-brand indicator that signals legitimate- sender-provenance to the recipient at inbox-render time, structurally distinct from the SPF / DKIM / DMARC authentication- pass-rate reputation surface this page documents but contributing complementary engagement-rate uplift to the per- publisher deliverability outcome KPI catalogue); (ii) CAA-vs-MTA- STS-rollout gating — per- publisher MTA-STS deployment at the transport-security layer requires a public-PKI cert on the per-publisher mta-sts.<domain> HTTPS host (RFC 8461 §3.2 policy- fetch protocol); an incompatible CAA silently blocks per-publisher mta-sts.<domain> cert renewal — the per-publisher MTA-STS-enforced-TLS deliverability surface (per-connection transport- layer cert-channel-integrity at SMTP-STARTTLS handshake) degrades, increasing per-publisher inbound-MitM attack surface + per-publisher downgrade-attack surface visible in per-receiver TLS-RPT-JSON failure- report streams as load-bearing per-publisher transport-security regression signals; (iii) CAA- vs-per-MX-host-STARTTLS-cert renewal — per-domain CAA restrictions are inherited by all <host>.<domain> subdomains including per-MX-target hosts per RFC 8659 §3 tree-climbing algorithm; the per-MX-host SMTP- STARTTLS-cert renewal cadence is gated by the per-domain CAA — per- receiver TLS-RPT-JSON failure-report stream captures the resulting "result-type": "certificate-not-trusted" + "result-type": "validation-failure" failure- types per RFC 8460 §4.3 whose suppression is load-bearing for downstream per-receiver per-publisher TLS-pass-rate KPI the modern bulk- sender encryption-rate compliance contract (Gmail / Yahoo Bulk Sender Requirements February 2024 + Microsoft modern-authentication baseline) consumes; (iv) CAA- vs-deliverability-incident-response root-cause discipline — post-incident root-cause analysis of "why did BIMI display drop?" / "why did MTA-STS rollout fail?" / "why did per-MX-host STARTTLS handshake regress?" routinely surfaces per- publisher CAA-publication-discipline regression as the load-bearing upstream control-publication whose drift (CA added without coordinated CAA update, CAA-RR published listing only legacy CA after CA-migration, CAA 0 iodef incident-notification endpoint not actively monitored) caused the deliverability regression visible in the per- publisher per-domain reputation framework outcome surface THIS page documents.
• SPF qualifiers explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-QUALIFIER-CHOICE-AS-LOAD- BEARING-DETERMINANT-OF-PER-RECEIVER- REPUTATION-MODEL-TREATMENT companion to this deliverability framework. Where THIS page documents the per- publisher per-domain reputation / sender-eligibility / authentication- pass-rate / encryption-rate / complaint-rate deliverability outcomes the per-receiver per- publisher reputation model evaluates, the SPF-qualifiers-explained spoke is the STRUCTURALLY-UPSTREAM per- publisher per-domain SPF mechanism- qualifier-choice-publication- discipline reference whose RFC 7208 §4.6.2 qualifier-prefix primitive (+ Pass / - Fail / ~ SoftFail / ? Neutral) directly determines per-receiver reputation- model treatment of per-message spf= verdict-class. The SPF- qualifier-vs-deliverability-outcome coupling establishes four specific per-publisher qualifier-choice-to- deliverability-outcome dimensions: (i) per-publisher -all Fail choice produces spf=fail verdict-class that per-receiver reputation models treat as load-bearing per-publisher per-source-IP unauthorized-sender signal driving per-receiver per- publisher per-domain reputation degradation — per- publisher -all terminal-mechanism choice produces per-message spf=fail at receiver- side SPF evaluation; per-receiver Gmail / Microsoft 365 / Yahoo reputation models treat spf=fail as load-bearing per-publisher per- source-IP unauthorized-sender signal; per-publisher per-domain per-source-IP per-message spf=fail rate spike drives per-publisher per-domain reputation degradation; Gmail Postmaster Tools per-publisher per-domain authentication-pass-rate KPI observes per-publisher per- domain spf=fail-rate as load- bearing per-publisher per-domain deliverability-outcome attribution signal; (ii) per-publisher ~all SoftFail choice produces spf=softfail verdict- class that per-receiver reputation models treat as quarantine-eligible with structurally-distinct per- publisher per-domain reputation impact — per-publisher ~all terminal- mechanism choice produces per- message spf=softfail at receiver- side SPF evaluation; per-receiver reputation models treat spf= softfail as quarantine-eligible rather than reject-eligible; per- publisher per-source-IP per- unauthorized-sender mail produces per-receiver per-publisher per- domain spam-folder-placement rate spike rather than per-source-IP rejection; per-publisher per- domain inbox-placement KPI degrades at structurally-distinct per-receiver reputation-model treatment-class boundary; (iii) per-publisher ?all Neutral choice produces spf=neutral verdict- class that per-receiver reputation models treat as NO-AUTHENTICATION- SIGNAL with load-bearing per- publisher per-domain authentication- pass-rate degradation — per-publisher ?all terminal-mechanism choice produces per-message spf=neutral; per- receiver reputation models receive NO load-bearing per-publisher per- source-IP authentication signal; per-publisher per-domain authentication-pass-rate KPI in Gmail Postmaster Tools degrades below per-receiver per-publisher per-domain authentication-pass- rate floor expectation; per- publisher per-domain inbox- placement falls below per-receiver per-publisher per-domain deliverability outcome floor; (iv) per-publisher SPF qualifier choice as load-bearing per-publisher Bulk-Sender- Requirements-2024 compliance determinant for Gmail + Yahoo per-publisher per-domain DMARC- aligned-pass enforcement — per-publisher Gmail / Yahoo Bulk Sender Requirements (February 2024) require per-publisher per- domain DMARC-aligned-pass at per- publisher per-day >5000-recipient- message-volume threshold; per- publisher per-domain SPF qualifier discipline (-all as load-bearing per-publisher per- domain SPF-side authorisation- terminal-mechanism) is a load- bearing per-publisher per-domain SPF-side input to per-receiver per-publisher per-message DMARC- aligned-pass evaluation; per- publisher ?all / ~all qualifier choice silently caps per- publisher Bulk Sender Requirements compliance per-publisher per- domain DMARC-aligned-pass-rate ceiling. Read the SPF-qualifiers- explained spoke alongside this deliverability framework when investigating per-publisher per- domain reputation degradation root-cause attribution (per- publisher per-domain SPF qualifier choice is a load-bearing upstream deliverability-outcome determinant), when planning per- publisher per-domain SPF qualifier migration discipline (typically ~all → -all as a load-bearing per-publisher per-domain reputation-model signal-strengthening discipline), and when remediating per-publisher per-domain Gmail / Yahoo Bulk Sender Requirements compliance gap visible in per-receiver per- publisher per-domain deliverability outcome surface THIS page documents.
• TLS-RPT record syntax — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-OBSERVABILITY- PUBLICATION-PRIMITIVE companion to this email deliverability reference. Where THIS page documents the per-publisher per-domain deliverability-outcome decision discipline (per-receiver reputation-model treatment of per- publisher per-domain authentication- rate / complaint-rate / spam-rate / IP- warmup-stage / sender-reputation / Bulk-Sender-Requirements-2024 per- receiver Gmail + Yahoo compliance gate), the TLS-RPT-record-syntax spoke documents the per-publisher per-domain RFC 8460 §3 TLS-RPT DNS TXT-RR publication discipline whose per- publisher per-domain cross-receiver TLS-pass-rate distribution is the LOAD- BEARING per-publisher per-domain deliverability-outcome-determinant at the per-receiver transport-layer- compliance gate the per-publisher per- domain deliverability-outcome decision discipline THIS page documents evaluates at FOUR per-publisher per- domain transport-layer-deliverability- coupling dimensions: (i) per- publisher per-domain TLS-pass-rate captured per-receiver per-day per-MX- host per-failure-class in rua TLS-RPT JSON-report evidence stream as load- bearing per-publisher per-domain deliverability-outcome input under per- receiver reputation-model TLS-required gate — per-publisher per- receiver Gmail / Microsoft 365 / Yahoo per-day per-MX-host TLS-handshake- success-rate captured at row-level granularity in per-receiver-emitted TLS-RPT JSON-report evidence stream at the per-publisher per-domain rua mailbox the TLS-RPT-record-syntax spoke documents the per-publisher publication of operationally IS the per-publisher per-domain transport-layer-compliance evidence per-receiver reputation-model consumes — per-publisher per-MX-host TLS-failure-emergence per RFC 8460 §4.3 failure-class catalogue directly drives per-receiver per-publisher per-domain transport-layer-compliance signal- treatment in per-receiver Gmail / Microsoft 365 / Yahoo per-publisher per-domain deliverability-outcome determination the per-publisher per- domain deliverability-outcome decision discipline THIS page documents evaluates; (ii) per-publisher per-domain Bulk Sender Requirements February 2024 onwards TLS-handshake- success-rate floor enforcement boundary as load-bearing per-publisher per- domain Gmail + Yahoo compliance gate consuming per-publisher per-domain rua TLS-RPT JSON-report evidence stream — per-publisher per- domain Gmail + Yahoo Bulk Sender Requirements (BSR) February 2024 per-publisher cross-receiver TLS- handshake-success-rate floor enforcement boundary requires per- publisher per-domain TLS-pass-rate- floor evidence from per-publisher per- domain rua TLS-RPT JSON-report evidence stream the TLS-RPT-record-syntax spoke documents the per-publisher per-domain publication of as the LOAD-BEARING per- publisher per-domain transport-layer- compliance evidence the per-receiver Gmail + Yahoo BSR gate decision the per-publisher per-domain deliverability-outcome decision discipline THIS page documents evaluates structurally consumes; per- publisher per-MX-host TLS-pass-rate- floor violation captured as per-day per-MX-host per-failure-class evidence row in per-publisher per-domain rua TLS-RPT JSON-report stream the TLS- RPT-record-syntax spoke documents the per-publisher per-domain publication of directly drives per-receiver Gmail + Yahoo BSR per-publisher per-domain compliance-gate failure surfacing in per-publisher per-domain deliverability-outcome distribution THIS page documents; (iii) per- publisher per-MX-host cert-renewal- cadence drift as load-bearing per- publisher per-MX-host TLS-RPT-observed deliverability-outcome regression upstream root-cause class — per-publisher per-MX-host TLS-cert renewal-cadence drift (Let's Encrypt 90-day cycle slippage, public-CA 12- month cycle slippage, per-MX-host cert-rotation discipline drift) captured as per-MX-host per-day per-failure- class certificate-expired JSON evidence row in per-publisher per- domain rua TLS-RPT JSON-report stream the TLS-RPT-record-syntax spoke documents the per-publisher per-domain publication of is the LOAD-BEARING upstream per-publisher per-domain deliverability-outcome-regression root-cause class the per-publisher per- domain deliverability-outcome decision discipline THIS page documents attribution-analysis pipeline consumes; (iv) per-publisher per-domain cross-layer publication- discipline stack composition message- layer-DMARC + transport-layer-MTA-STS + transport-layer-TLS-RPT + transport- layer-DANE-OPTIONAL as load-bearing per-publisher per-domain deliverability-outcome cross-receiver complete-publication-coverage prerequisite — per-publisher per-domain deliverability-outcome cross-receiver complete-publication- coverage prerequisite composes per- publisher per-domain message-layer- DMARC publication discipline AND per- publisher per-domain transport-layer- MTA-STS publication discipline AND per- publisher per-domain transport-layer- TLS-RPT publication discipline the TLS- RPT-record-syntax spoke documents the per-publisher per-domain publication of AND per-publisher per-domain transport-layer-DANE optional publication discipline as the per- publisher per-domain cross-layer- publication-discipline-stack composed complete-publication-coverage prerequisite the per-publisher per- domain deliverability-outcome decision discipline THIS page documents per-receiver Gmail / Microsoft 365 / Yahoo / Apple Mail per-publisher per- domain reputation-model treatment consumes at the per-publisher per- domain cross-receiver complete- publication-coverage evaluation boundary. Read the TLS-RPT-record- syntax spoke alongside this email deliverability reference when planning per-publisher per-domain transport- layer-compliance publication discipline whose per-receiver per-publisher per- domain deliverability-outcome treatment is structurally gated by per-publisher per-domain rua TLS-RPT JSON-report evidence the TLS-RPT- record-syntax spoke documents the per- publisher per-domain publication of, and when investigating per-publisher per-receiver deliverability-outcome variance whose upstream root-cause is per-publisher per-MX-host transport- layer-compliance variance the per- publisher per-domain rua TLS-RPT JSON-report evidence stream the TLS- RPT-record-syntax spoke documents the per-publisher per-domain publication of structurally captures at per-receiver per-day per-MX-host per-failure-class row-level granularity.
• DMARC monitoring discipline — where THIS page documents the cluster-spanning per-publisher per- domain reputation framework architecting how receiver-side reputation models translate authentication-pass-rate + complaint-rate + spam-rate + bounce-rate inputs into per- receiver inbox-placement decisions (Gmail Postmaster + Microsoft SNDS + Yahoo Sender Hub + Apple Mail feedback loops), the DMARC- monitoring spoke documents the per-publisher per-domain standing operational discipline whose 8 core KPIs (per-domain DMARC-pass-rate / per-source-IP alignment-failure rate / per- receiver coverage / sender- inventory drift / volume-based compromise signals / disposition- distribution variance / RUA coverage / per-day baseline-vs- anomaly) PRODUCE the load-bearing application-layer authentication- rate observability evidence the per-receiver reputation models THIS page documents materially consume. FOUR structurally- distinct MONITORING-KPI-TO- DELIVERABILITY-OUTCOME coupling dimensions the DMARC-monitoring spoke operationally documents: (i) per-publisher per-domain DMARC-pass-rate KPI as load- bearing input into the Gmail / Yahoo Bulk Sender Requirements 2024 per-publisher cross-receiver authentication-pass-rate floor enforcement boundary — the per-publisher per-domain DMARC-pass-rate KPI floor the DMARC-monitoring spoke documents the standing observability of is the LOAD-BEARING application-layer authentication-rate input the Gmail / Yahoo 2024 Bulk Sender Requirements per-publisher cross-receiver authentication- pass-rate floor enforcement boundary THIS deliverability page documents consumes as the per- publisher per-domain compliance- determinant; (ii) per- source-IP alignment-failure rate alert threshold as load-bearing upstream-detection-primitive for per-source-IP reputation- degradation events that the per- receiver Gmail / Microsoft 365 / Yahoo / Apple Mail reputation models translate into per- publisher per-domain inbox- placement degradation — when a previously-aligned per- source-IP sender starts producing per-message DMARC-fail at one receiver, the DMARC-monitoring spoke's per-source-IP alert threshold surfaces the regression BEFORE the receiver-side reputation model THIS page documents translates it into per-publisher per-domain inbox-placement degradation; (iii) per- publisher sender-inventory drift KPI as load-bearing detection primitive for unauthorized senders whose per-message DMARC- fail volume degrades the per- publisher per-domain reputation score — when a new operationally-distinct sending infrastructure appears in the per-publisher per-domain rua aggregate-XML evidence stream (potential per-publisher per- domain compromise, ESP signup forgotten in inventory, shadow IT marketing tool, third-party partner sending without prior coordination), the DMARC- monitoring spoke's sender- inventory drift KPI surfaces the event for per-publisher evaluation BEFORE the per-message DMARC-fail volume contributes downstream per-publisher per- domain reputation degradation the per-receiver reputation models THIS page documents observe and translate into inbox-placement outcomes; (iv) per- publisher per-week / per-month / per-quarter operational review cadence as load-bearing standing publisher-operator discipline whose review-agenda materially includes the per-receiver inbox- placement variance + per-receiver complaint-rate + per-receiver spam-rate + per-receiver bounce- rate trend evidence streams THIS deliverability page documents the architecture of — the DMARC-monitoring spoke's per- cadence-tier review framework provides the standing per- publisher per-domain operational discipline that materially incorporates the per-receiver deliverability-signal evidence streams THIS page documents into a single coherent per-publisher per-domain operational review cadence the per-publisher operator can execute against. Read the DMARC-monitoring spoke ALONGSIDE this deliverability framework whenever the per- publisher scopes a per-publisher per-domain authentication- observability discipline — the DMARC-monitoring discipline IS the application-layer authentication-rate observability primitive whose aggregate-XML evidence stream is the load- bearing upstream input the per- receiver reputation models THIS page documents materially consume as the per-publisher per-domain deliverability-outcome determinant.
• SPF DNS record syntax — the PER-PUBLISHER-PER-DOMAIN-SPF- TXT-RR-BYTE-GRAMMAR-PUBLICATION- DISCIPLINE-AS-LOAD-BEARING-UPSTREAM- DETERMINANT-OF-PER-PUBLISHER-PER- MAILBOX-PROVIDER-DELIVERABILITY- BASELINE companion documenting the per-publisher per-domain SPF TXT-RR byte-grammar publication discipline whose per-record per-token byte- correctness IS the load-bearing upstream per-publisher per-domain SPF-aligned-pass-rate-floor determinant that the per-receiver- mailbox-provider per-day deliverability- baseline (the per-publisher per- receiver-mailbox-provider per-day inbox-placement-rate aggregate signal THIS page documents) structurally depends on at the Gmail / Microsoft 365 / Yahoo / Apple Mail per-publisher per-domain deliverability-outcome decision boundary. Where THIS page documents the 14-section per-publisher per-domain deliverability outcome- framework (authentication-verdict → reputation → engagement → SMTP-bounce- taxonomy → Postmaster-Tools telemetry → inbox-placement-rate), the SPF-DNS- syntax spoke is the LOAD-BEARING UPSTREAM SPF-publication-discipline companion whose four per-SPF-DNS- syntax-publication-discipline-to-per- publisher-per-mailbox-provider- deliverability-outcome-coupling dimensions structurally couple per- publisher per-domain SPF authoring discipline to per-publisher per- receiver-mailbox-provider per-day deliverability-baseline outcomes: (i) per-publisher-per-domain- SPF-TXT-RR-byte-grammar-defects-as- canonical-root-cause-of-per-publisher- per-mailbox-provider-SPF-aligned- pass-rate-floor-collapse — per-publisher per-domain SPF TXT-RR byte-grammar publication discipline defects (typo'd v=spf1 version-prefix-byte sequence, per- mechanism-token byte-corruption, multiple v=spf1 TXT-RR siblings at the same FQDN violating RFC 7208 §3.2 cardinality, per-record TXT-RR byte-length budget exhaustion) produce per-message spf=permerror verdicts on EVERY per-receiver-side per- message evaluation; per-publisher per-domain SPF-aligned-pass-rate floor collapses across Gmail / Microsoft 365 / Yahoo / Apple Mail per-day per-publisher per-receiver- side per-message authentication- result-column evidence; per-publisher per-mailbox-provider per-day deliverability baseline degrades to spam-folder placement or hard-bounce per the per-publisher per-domain DMARC enforcement-mode posture; (ii) per-publisher-per-domain- SPF-mechanism-choice-as-load-bearing- sender-catalogue-completeness- determinant-of-per-publisher-per- mailbox-provider-SPF-aligned-pass- rate-floor — per-publisher per-domain SPF mechanism-choice authoring discipline (the per-record per-mechanism authoring choice among include: / ip4: / ip6: / a / mx tokens enumerating the per-publisher per-domain authorised sending-IP set) determines per-publisher per-receiver- side per-message SPF-aligned-pass- rate floor; per-publisher per-domain SPF mechanism-choice authoring defects (missing per-ESP include: for an authorised marketing sender, missing per-region ip4: / ip6: ranges for an authorised hosted-sender IP block) collapse per-publisher per-receiver- mailbox-provider per-day SPF-aligned- pass-rate baseline directly degrading the per-publisher per-mailbox-provider deliverability floor; (iii) per-publisher-per-domain-SPF- end-of-record-qualifier-prefix-byte- choice-as-load-bearing-determinant-of- per-mailbox-provider-spam-folder-vs- reject-placement-policy — per-publisher per-domain SPF end-of- record qualifier-prefix-byte choice (the ~all SoftFail vs -all Fail vs ?all Neutral terminal qualifier) directly feeds per-receiver per-mailbox-provider per-message delivery-placement-policy decision- tree differently (-all with DMARC-fail triggers p=quarantine / p=reject enforcement; ~all with DMARC-fail defers to receiver-side spam-filter scoring); per-publisher per-domain SPF qualifier-prefix-byte authoring choices structurally determine per- receiver per-mailbox-provider per- message delivery-placement-policy outcomes; (iv) per-publisher- per-domain-SPF-record-byte-grammar- publication-discipline-as-load- bearing-input-to-Gmail-and-Yahoo- bulk-sender-requirements-2024- compliance-floor — per- publisher per-domain SPF record byte-grammar publication discipline (per-record per-mechanism token byte-sequence correctness, per- mechanism qualifier-prefix byte- placement, per-mechanism operand byte-correctness, per-record TXT-RR byte-length budget) directly determines per-publisher per-domain per-receiver-side SPF-evaluator- parser determinism; per-publisher per-domain Gmail + Yahoo 2024 bulk- sender-requirements compliance floor (≥99% authentication-pass-rate on SPF + DKIM legs) STRUCTURALLY DEPENDS on per-publisher per-domain SPF TXT-RR byte-grammar publication discipline correctness; per-record per-token byte-grammar defects collapse per-publisher per-receiver- side per-day authentication-pass- rate below the 99% floor — directly triggering Gmail / Yahoo per-publisher per-domain per-day delivery-placement downgrade or per-publisher per-domain sender-restriction enforcement. Read THIS page when DIAGNOSING per- publisher per-mailbox-provider per-day deliverability baseline degradation; read the SPF-DNS-syntax spoke when AUTHORING per-publisher per-domain SPF TXT-RR byte-grammar publication discipline as the LOAD-BEARING UPSTREAM SPF-publication-discipline whose per-record per-token byte- correctness IS the precondition the per-publisher per-mailbox-provider per-day deliverability-baseline THIS page documents the outcome-framework of structurally depends on.
• DMARC myths and misconceptions debunked — the 18-myth operator-mental-model correction catalogue cataloguing the recurring DMARC misconceptions that block per-publisher per-mailbox-provider deliverability outcomes. The deliverability-vs-authentication myth class this page directly addresses covers the "DMARC at p=reject hurts deliverability" rollout-blocker myth (the inverse is true at the per- mailbox-provider per-publisher-domain reputation level once aligned-pass-rate is stable), the "p=none is doing nothing for deliverability" misconception (the Phase-3 sender- inventory empirical evidence is the load-bearing precondition the per- publisher per-mailbox-provider per-day deliverability-baseline this page documents depends on), and the "we can fix deliverability without authentication" myth (Gmail bulk-sender-requirements and Yahoo bulk-sender-requirements both require per-publisher per-domain DMARC publication as the per-mailbox-provider per-bulk-sender entry-gate). Read THIS deliverability outcome-framework alongside the myths catalogue when operators raise the recurring "deliverability vs DMARC" rollout- blocker question.
• SPF forwarding issues — the per-message forwarder-induced envelope-MAIL-FROM-IP-rewrite as per-mailbox- provider per-day deliverability-degradation- input-variable companion to this deliverability outcome-framework. Where THIS page documents the per-publisher per-mailbox-provider per-day inbox-placement-rate KPI baseline and the Gmail / Yahoo Bulk Sender Requirements (February 2024) compliance discipline that determines the per-mailbox-provider per-day per-IP reputation curve, the SPF-forwarding- issues spoke documents the per-message FORWARDER-INDUCED upstream mechanic that produces the recurring per-mailbox-provider per-day spf=fail attribution rows that materially degrade per-IP reputation when the publisher has not yet shipped DKIM-aligned signing or ARC-trust- anchored intermediary cooperation. Four DELIVERABILITY-KPI-VS-FORWARDING-FAILURE- MECHANIC cross-correlation axes the SPF- forwarding-issues spoke documents: (i) the per-mailbox-provider per-day per-IP reputation curve degrades when a recipient-side auto-forwarder rewrites the envelope and the second-hop receiver evaluates spf=fail on legitimate mail — Gmail / Yahoo / Microsoft / Outlook.com each weight the forwarder-induced SPF-fail rows into the per-IP per-day reputation aggregation that determines inbox-placement vs spam-folder- placement vs reject disposition; (ii) the per-mailbox-provider per-day complaint-rate KPI surfaced in Google Postmaster Tools / Microsoft SNDS / Yahoo Sender Hub is structurally affected by the per-forwarder body-mutation pattern — body- mutating mailing-list intermediaries inject footers / List-Unsubscribe / Subject-prefix content that increases recipient-side complaint rates against the publisher's per-IP reputation, even when the original publisher's content was complaint-clean; (iii) the Gmail / Yahoo Bulk Sender Requirements (February 2024) one-click- unsubscribe compliance discipline interacts with the per-forwarder body-mutation pattern — when a mailing-list intermediary mutates the List-Unsubscribe header, the per-publisher per-mailbox-provider one-click-unsubscribe compliance verdict degrades, and per-publisher per-mailbox-provider per-day inbox-placement rates degrade in proportion; (iv) the per-publisher per-domain ARC-trust-anchored rescue path documented in help_arc_explained.php is the load-bearing operational lever that recovers per-mailbox-provider per-day inbox-placement rates against the forwarder-induced second- hop SPF break — publishers MUST ship DKIM- aligned signing AND coordinate with known- trustworthy ARC sealer populations to recover the per-IP per-day reputation curve against the per-forwarder degradation pattern. Read THIS page when SETTING the per-mailbox- provider per-day deliverability KPI baseline; read the SPF-forwarding-issues spoke when DIAGNOSING the per-forwarder-induced spf=fail attribution rows that DEGRADE the per-IP per-day reputation curve THIS deliverability outcome-framework depends on.
• Google Postmaster Tools — the canonical observability dashboard for Gmail-side reputation, complaint rate, authentication pass rate, encryption rate, and one-click unsubscribe compliance.
• Microsoft SNDS + JMRP — Microsoft Smart Network Data Services (per-IP reputation dashboard) + Junk Mail Reporting Program (the M365 / Outlook.com complaint feedback loop).
• Yahoo Sender Hub — Yahoo's unified sender portal covering reputation, complaint feedback loop enrollment, and Sender Best Practices compliance.
• Email spoofing explained — the per-mailbox-provider per-day spoofing-driven reputation-degradation attribution companion to this email- deliverability operator-reference. Where THIS page documents the per- publisher per-mailbox-provider per-day deliverability KPI framework (the per- IP reputation curve, the per-mailbox- provider complaint-rate KPI, the Gmail Postmaster Tools / Microsoft SNDS+JMRP / Yahoo Sender Hub per-provider dashboards, the Gmail+Yahoo Bulk-Sender- Requirements-2024 compliance floor), the email-spoofing spoke is the PER- ATTACK-CLASS-DRIVEN-REPUTATION- DEGRADATION-ATTRIBUTION REFERENCE documenting the per-publisher per- domain attack-surface catalogue whose per-attack-class downstream deliverability impact (per-attacker From-domain-spoofing campaign-driven per-publisher per-mailbox-provider complaint-rate spike, per-attacker lookalike-domain campaign-driven per- publisher per-mailbox-provider per-day reputation-curve degradation, per- attacker subdomain-spoofing campaign- driven per-publisher per-organizational- domain reputation collateral damage) the per-publisher per-mailbox-provider per-day operator MUST examine to root- cause per-day reputation-degradation evidence between (i) per-publisher per- mailbox-provider legitimate-traffic- pattern-shift complaint-rate degradation, (ii) per-publisher per-mailbox-provider per-day per-IP reputation-curve drift from per-IP-block reassignment, (iii) per-publisher per-mailbox-provider per-attacker spoofing-campaign-driven reputation-spike, and (iv) per- publisher per-mailbox-provider Bulk- Sender-Requirements-2024 cryptographic- publication-discipline-regression-driven 5xx rejection. Pair this page (the per-publisher per-mailbox-provider per- day deliverability KPI framework) with the email-spoofing spoke (the per- attack-class catalogue reference) when designing the per-publisher per- mailbox-provider per-day reputation- degradation-vs-spoofing-attribution root-cause investigation discipline.
• DMARC forensic reports — the per-publisher per-mailbox-provider per-day deliverability-degradation per- message attribution forensic-evidence companion to this email-deliverability operator-reference. Where THIS page documents the per-publisher per-mailbox- provider per-day deliverability KPI framework (the per-IP reputation curve, the per-mailbox-provider complaint-rate KPI, the Gmail Postmaster Tools / Microsoft SNDS+JMRP / Yahoo Sender Hub per-provider dashboards, the Gmail+Yahoo Bulk-Sender-Requirements-2024 compliance floor), the DMARC-forensic-reports spoke is the PER-MESSAGE-ROOT-CAUSE-EVIDENCE REFERENCE documenting the RFC 6591 AFRF MIME per-message failure-report envelope whose per-message authentication-failure attribution payload (the per-message envelope-MAIL-FROM-IP, the per-message From-domain, the per-message Authentication-Results: header dump with per-leg SPF/DKIM/DMARC pass-fail breakdown, the per-receiver verifier- side failure-reason-code attribution) the per-publisher per-domain operator MUST examine to root-cause per-mailbox- provider per-day deliverability- degradation evidence into per-message attribution categories: (i) per-message SPF-fail-emission-driven per-receiver spam-folder placement, (ii) per-message DKIM-fail-emission-driven per-receiver spam-folder placement, (iii) per-message DMARC-disposition-quarantine/reject receiver-side enforcement, and (iv) per- message Bulk-Sender-Requirements-2024 compliance-floor cryptographic- publication-discipline regression-driven 5xx receiver-side rejection. Pair this page (the per-publisher per-mailbox- provider per-day deliverability KPI framework) with the DMARC-forensic- reports spoke (the per-message RFC 6591 AFRF MIME failure-report payload reference) when designing the per- publisher per-domain per-mailbox- provider deliverability-degradation root-cause forensic-investigation discipline — the spoke documents the per-message AFRF MIME envelope payload structure that is the operationally- grounded per-message root-cause attribution stream every per-publisher per-mailbox-provider per-day deliverability KPI investigation STRUCTURALLY DEPENDS on.
• DKIM replay attacks — the per-publisher per-domain REPUTATION-EROSION-VIA-AUTHENTICATED-REPLAY companion to this deliverability KPI + per- mailbox-provider sender-reputation discipline reference. Where THIS page documents the per- publisher per-mailbox-provider per-day deliverability KPIs (per-publisher per-mailbox- provider inbox-vs-spam placement, per-publisher per-mailbox-provider bounce rate, per-publisher per-mailbox-provider complaint rate, per- publisher per-mailbox-provider engagement signals) and the per-publisher per-mailbox- provider Postmaster Tools + Sender Score + per-mailbox-provider domain-reputation feedback loops, the DKIM-replay-attacks spoke documents the specific per-message attack class that ERODES the per-publisher per-domain mailbox- provider-side sender reputation the deliverability discipline THIS page documents DEPENDS ON: a sophisticated attacker captures a legitimately DKIM-signed message from the per-publisher per-domain sender and re- broadcasts the byte-for-byte signed message (typically a phishing payload, a spam campaign, a malware lure) to an attacker- chosen recipient set; because the per-message DKIM signature still cryptographically verifies and the original From: still aligns with the original d=, the per- message DMARC verdict is pass — recipients see a per-publisher per-domain DMARC-authenticated message that LOOKS legitimate, generate per-publisher per- mailbox-provider SPAM-BUTTON / SPAM-FOLDER / BLOCKED-SENDER complaints attributed to the per-publisher per-domain d= signing domain, and the per- publisher per-mailbox-provider DOMAIN- REPUTATION SCORE DEGRADES toward the per- publisher per-mailbox-provider spam-folder- placement boundary. Three per-deliverability- KPI per-publisher per-domain reputation- erosion dimensions the DKIM-replay-attacks spoke documents the per-publisher per-domain deliverability operator MUST audit at the per- publisher per-domain reputation-monitoring tier: (i) per-publisher per-mailbox- provider complaint-rate KPI degradation via per-message authenticated-replay-attributed recipient SPAM-BUTTON clicks — the per-publisher per-mailbox-provider complaint- rate KPI THIS page documents (typically the per-mailbox-provider Gmail Postmaster Tools "User Reported Spam Rate" + Microsoft SNDS "Complaint Rate" + Yahoo SMTP-AUTH "Complaint-Rate" dimension) DEGRADES when per-message authenticated-replay attacks deliver phishing/spam payloads under the per-publisher per-domain d= signing identity; the DKIM-replay-attacks spoke documents the per-message attack mechanics the per-publisher per-mailbox- provider complaint-rate KPI degradation attributes to; (ii) per-publisher per-mailbox-provider domain-reputation KPI degradation via per-message authenticated- replay-attributed spam-folder placement feedback — the per-publisher per- mailbox-provider domain-reputation KPI THIS page documents (the per-mailbox-provider Gmail Postmaster Tools "Domain Reputation" Bad / Low / Medium / High classification + Microsoft SNDS Yellow / Green / Red classification + Cisco Talos SenderBase Poor / Neutral / Good classification) DEGRADES when per-publisher per-domain DKIM-PASS-WITH-ALIGNED-DMARC-PASS authenticated-replay messages reach recipients and trigger per-message spam- folder placement; the DKIM-replay-attacks spoke documents the per-message attack mechanics the per-publisher per-mailbox- provider domain-reputation KPI degradation attributes to; (iii) per-publisher per-mailbox-provider blocklist-listing KPI risk via per-message authenticated-replay- attributed RBL/DNSBL entries — the per-publisher per-mailbox-provider blocklist- listing KPI (per-publisher per-domain Spamhaus DBL / SURBL / URIBL + per-publisher per-IP Spamhaus SBL/CSS + per-publisher Composite Block List listings) RISKS LISTING when per-publisher per-domain DKIM-PASS-WITH-ALIGNED-DMARC-PASS authenticated-replay messages aggregate per-domain abuse signals at the per-RBL threshold-crossing boundary; the DKIM- replay-attacks spoke documents the per- message attack mechanics the per-publisher per-mailbox-provider blocklist-listing KPI risk attributes to. Read the DKIM-replay- attacks spoke ALONGSIDE this deliverability discipline reference whenever the per- publisher per-domain deliverability operator INVESTIGATES an unexplained per- publisher per-mailbox-provider per-day complaint-rate spike, domain-reputation degradation, or blocklist-listing event despite per-publisher per-domain DMARC- authenticated message flow — the per- publisher per-mailbox-provider deliverability KPI surface THIS page documents is the per- publisher per-mailbox-provider sender- reputation MONITORING primitive; the per- publisher per-domain DKIM-replay-attacks spoke is the per-publisher per-domain AUTHENTICATED-REPLAY-AS-REPUTATION-EROSION- VECTOR ROOT-CAUSE-HYPOTHESIS primitive that closes the per-publisher per-domain unexplained-reputation-degradation investigation gap at the per-publisher per- domain authenticated-replay-attack-class diagnostic tier.
• SPF PermError vs TempError — the LOAD-BEARING per-publisher per-domain SPF-PERMERROR-AS-PER- MAILBOX-PROVIDER-DELIVERABILITY-KPI- DEGRADATION-ROOT-CAUSE-HYPOTHESIS companion documenting the SPF-side spf=permerror / spf=temperror verdict family whose per-receiver-side treatment per RFC 7208 §8.5 produces sharply-divergent per-mailbox-provider deliverability KPI degradation patterns: Gmail treats per-message spf=permerror as a publisher-side configuration error producing per-publisher per-domain bulk-folder placement and per- sender-domain reputation-score degradation, Microsoft 365 treats per-message spf=permerror as spf=fail-equivalent for per-publisher per-domain DMARC evaluation purposes (so p=quarantine / p=reject publishers see per-message rejection); per-message spf=temperror produces per-mailbox-provider per-message retry-then-defer behaviour that degrades per-publisher per-message delivery-latency KPI under transient per-publisher per-domain authoritative- DNS-server unreachability. The per-publisher per-domain canonical root cause of spf=permerror is exceeding the RFC 7208 §4.6.4 ten- DNS-lookup limit (the per-publisher per-domain SPF record's chained include: records compound the per-resolution-cycle DNS lookup count beyond the receiver-side per-message hard ceiling) — a per- publisher per-domain SILENT DELIVERABILITY-KPI-DEGRADATION ROOT- CAUSE that this page's per-publisher per-mailbox-provider deliverability KPI framework can ONLY surface as a per-publisher per-mailbox-provider per-day delivery-rate / bulk-folder- placement-rate degradation pattern without the PermError vs TempError spoke's per-publisher per-domain SPF- side DNS-lookup-count audit discipline to identify the upstream root cause. Where THIS page documents the per- publisher per-mailbox-provider per-day DELIVERABILITY KPI FRAMEWORK (delivery rate, bulk-folder placement rate, per-mailbox-provider per-day reputation score, per-mailbox-provider per-day spam-complaint rate), the PermError vs TempError spoke documents the per- publisher per-domain SPF-side ROOT- CAUSE-HYPOTHESIS CATALOGUE for the unexplained per-mailbox-provider per- day deliverability KPI degradation patterns this page's KPI framework surfaces. Read THIS page when MONITORING the per-publisher per- mailbox-provider per-day deliverability KPI surface; read the PermError vs TempError spoke when DIAGNOSING the per-publisher per-domain SPF-side root cause of unexplained per-mailbox- provider per-day deliverability KPI degradation patterns surfaced by the KPI framework this page documents.
• DMARC multi-domain strategy — the PER-PUBLISHER-PORTFOLIO-PER-OWNED- SENDING-DOMAIN-DELIVERABILITY-BASELINE- SEGMENTATION companion to this per-publisher per-mailbox-provider per-day deliverability KPI framework. Where THIS page documents the per-publisher per-mailbox-provider per- day inbox-vs-spam-vs-promotions-vs-blocked placement-rate KPI surface as the LOAD- BEARING outcome the per-publisher deliverability operator monitors at the per-Gmail / per-Yahoo / per-M365 / per-Apple Mail / per-Fastmail receiver boundary, the multi-domain-strategy spoke documents the FOUR PER-PORTFOLIO-PER-DOMAIN-CLASS DELIVERABILITY-BASELINE-SEGMENTATION DIMENSIONS the per-publisher deliverability operator MUST close to preserve the per- domain inbox-placement-rate floor across the publisher's portfolio: (i) per- transactional-domain vs per-marketing-domain vs per-corporate-domain sender-reputation SEGMENTATION — the per-publisher portfolio MUST separate transactional mail (password resets, order confirmations, per-recipient one-to-one) from marketing mail (per-segment one-to-many campaigns) from corporate mail (per-employee one-to- one business correspondence) onto SEPARATE owned sending domains so a per-marketing- domain reputation incident does NOT contaminate the per-transactional-domain per-mailbox-provider per-day placement-rate floor; (ii) per-domain DKIM-key custody + per-domain DKIM-selector rotation cadence INDEPENDENCE — every per-publisher portfolio domain MUST publish its OWN selector._domainkey.<domain> public-key record (not a single shared per-publisher selector) so a per-domain DKIM-key-compromise incident or per-domain DKIM-key-rotation overlap-window error is isolated to that domain and does NOT cascade the per-publisher per-mailbox-provider per-day DKIM-aligned-pass-rate floor across the entire portfolio; (iii) per- domain DMARC p=reject rollout cadence STAGING — the per- publisher portfolio MUST stage the per- domain DMARC p=none → p=quarantine → p=reject rollout per-domain on an INDEPENDENT cadence so a per-domain prematurely-tightened DMARC enforcement misconfiguration that breaks per-recipient legitimate mail is contained to that domain and does NOT collapse the per-publisher portfolio-wide per-mailbox-provider per- day inbox-placement-rate floor in a single operator action; (iv) per-domain rua= aggregate-report INGESTION + per-domain per-mailbox-provider per-day DELIVERABILITY-KPI SEGMENTATION dashboard — the per-publisher portfolio operator MUST funnel every per-domain receiver-side DMARC rua= aggregate-report publication into a per-domain segmentation dashboard so the per-mailbox-provider per- day per-domain inbox-vs-spam placement-rate KPI this page documents can be SEGMENTED per-portfolio-domain — letting the per- publisher deliverability operator attribute a per-mailbox-provider per-day per-domain placement-rate degradation to the SPECIFIC portfolio domain whose authentication- publication discipline caused the per- recipient receiver-side downstream-spam- folder routing. Read the multi-domain- strategy spoke ALONGSIDE this per-publisher per-mailbox-provider per-day deliverability KPI framework when SEGMENTING the per- publisher portfolio's per-domain authentication-publication discipline — the per-portfolio-per-domain DKIM + DMARC baseline-segmentation catalogue is the canonical operator-facing companion to the per-mailbox-provider per-day inbox- placement-rate KPI surface this page documents.
• Email authentication glossary — the EMAIL-DELIVERABILITY-DISCIPLINE- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER- EMAIL-AUTHENTICATION-TERMINOLOGY-HUB companion to this deliverability-discipline reference. Where THIS page documents the per-publisher per-mailbox-provider deliverability-discipline workflow (the Feb 2024 bulk-sender authentication thresholds, the per-mailbox-provider inbox-placement-rate KPI dashboard, the per-sender reputation-trajectory coordination, the per-publisher SPF / DKIM / DMARC publication-discipline as upstream prerequisite for inbox placement, the per-mailbox-provider FBL registration coordination), the email- authentication-glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every deliverability-discipline discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term authentication-pillar vocabulary resolution — the authentication-pillar vocabulary (SPF, DKIM, DMARC, BIMI, MTA-STS, TLS-RPT, ARC, the per-pillar upstream-publication-discipline requirement, the per-pillar per-message verdict, the per-pillar Auth-Results keyword set) THIS page's per-publisher per-mailbox-provider deliverability reference structurally references at every per-pillar per-deliverability- threshold entry is canonically defined in the glossary spoke; the per- publisher per-domain authentication- pillar terminology vocabulary that drives every deliverability-discussion discussion lives in the glossary's per- pillar entry-set; (ii) per-term DMARC-alignment vocabulary resolution — the DMARC-alignment vocabulary (organizational domain, SPF-aligned-pass, DKIM-aligned-pass, DMARC-aligned-pass, adkim= / aspf= alignment-strictness mode, RFC5322-From domain, p=reject enforcement, p=quarantine partial enforcement) THIS page's per-publisher per-mailbox-provider deliverability reference references when describing the Feb 2024 bulk-sender authentication thresholds and the per-mailbox-provider inbox-placement-rate KPI gating is canonically defined in the glossary spoke; the per-message alignment-mode- evaluation vocabulary that determines whether a per-publisher per-message passes the per-mailbox-provider authentication-floor threshold lives in the glossary's per-term alignment- vocabulary entry-set; (iii) per- term bulk-sender-list-management vocabulary resolution — the bulk-sender- list-management vocabulary (RFC 8058 one-click List-Unsubscribe, List- Unsubscribe header, FBL feedback-loop registration, per-mailbox-provider FBL complaint-rate threshold, RFC 2369 List-Unsubscribe header semantics) THIS page's per-publisher per-mailbox- provider deliverability reference references when describing the per- publisher per-mailbox-provider list-hygiene discipline is canonically defined in the glossary spoke; the per-publisher per-mailbox- provider list-management-discipline vocabulary that drives every bulk-sender- threshold-coordination discussion lives in the glossary's per-term list- management-vocabulary entry-set; (iv) per-term deliverability-KPI vocabulary resolution — the deliverability-KPI vocabulary (inbox- placement rate, spam-folder placement rate, sender-reputation trajectory, IP warmup cadence, domain-reputation trajectory, FBL complaint-rate KPI, per- mailbox-provider authentication-pass- rate KPI) THIS page's per-publisher per- mailbox-provider deliverability reference references when describing per-KPI per- day operational visibility is canonically defined in the glossary spoke; the per-publisher per-mailbox- provider per-day KPI-dashboard decode vocabulary that drives every operator- side per-deliverability-trajectory decision discussion lives in the glossary's per-term deliverability-KPI- vocabulary entry-set. Read the email- authentication-glossary spoke alongside this email-deliverability-discipline reference when authoring per-publisher per-mailbox-provider deliverability runbooks and per-KPI-coordination documents that need the shared terminology hub.
• DKIM alignment with DMARC — the PER-PUBLISHER-PER-DOMAIN-DKIM- ALIGNED-PASS-RATE-FLOOR-AS-LOAD-BEARING- INBOX-PLACEMENT-INPUT-VARIABLE companion to this email-deliverability discipline reference. Where THIS page documents the per-publisher per-mailbox-provider per-day per-IP reputation curve / per-mailbox- provider complaint-rate KPI / Gmail+Yahoo Bulk-Sender-Requirements-2024 compliance discipline / inbox-placement vs spam-folder routing decision framework at the per- publisher per-domain deliverability- outcome layer, the DKIM-alignment-with- DMARC spoke is the PER-PUBLISHER-PER- DOMAIN-DKIM-ALIGNED-PASS-RATE-FLOOR-AS- LOAD-BEARING-INPUT companion documenting the per-message DKIM-Signature d=-tag vs RFC 5322 From- header organisational-domain alignment evaluation whose per-publisher per-domain application-layer DKIM-aligned-pass rate is the load-bearing per-publisher per- mailbox-provider inbox-placement gating signal. Four DKIM-alignment-vs- deliverability coupling dimensions matter at the per-publisher per-mailbox-provider per-IP reputation curve boundary: (i) per- publisher per-mailbox-provider per-IP reputation-curve threshold — Gmail Postmaster Tools Domain Reputation / Outlook SNDS sender-reputation / Yahoo+AOL Sender Hub consume per-publisher per-domain DKIM-aligned-pass rate as the primary per-publisher per-domain authentication-trust-floor input variable determining inbox placement; per-publisher per-domain DKIM-aligned-pass rate below the per-mailbox-provider reputation-curve threshold IS the load-bearing per- publisher per-domain deliverability- degradation root-cause hypothesis the DKIM-alignment-with-DMARC spoke documents diagnostic procedure for; (ii) Gmail+Yahoo Bulk-Sender-Requirements-2024 compliance — the per-publisher per-domain DKIM-signed- mail-flow universality requirement announced by Gmail+Yahoo February 2024 REQUIRES per-publisher per-domain DKIM alignment per RFC 7489 §3.1.1 for ALL 5000+-per-day bulk-sender traffic; per- publisher per-domain DKIM-alignment-with- DMARC compliance THIS spoke documents IS the load-bearing per-publisher per-domain compliance-with-Bulk-Sender-Requirements primitive every per-publisher per-domain per-mailbox-provider inbox-placement outcome at Gmail+Yahoo depends on; (iii) per-publisher per-domain per-stream DKIM-d= subdomain-segmentation reputation- portfolio decoupling — per-publisher per- domain operators segment per-stream signing (marketing.<publisher>, transactional.<publisher>, newsletter.<publisher>) to decouple per-stream per-mailbox-provider per-IP reputation curves; the per-publisher per- stream DKIM-d= subdomain alignment- evaluation discipline the DKIM-alignment- with-DMARC spoke documents IS the load- bearing per-publisher per-stream reputation- portfolio-decoupling primitive every per- publisher per-stream deliverability KPI THIS page documents depends on; (iv) per- publisher per-domain per-receiver-side DMARC-aligned-pass cascade — the per- publisher per-domain DMARC composite verdict pass requires AT LEAST ONE aligned-pass leg (DKIM-aligned- pass OR SPF-aligned-pass); when per- publisher per-domain SPF alignment breaks at forwarder hops (per-publisher per- domain envelope-MAIL-FROM-rewrite at forwarder), the per-publisher per-domain DKIM-aligned-pass leg the DKIM-alignment- with-DMARC spoke documents IS the LOAD- BEARING per-publisher per-domain authentication-leg-of-last-resort every per-publisher per-domain per-mailbox- provider inbox-placement decision depends on at the per-receiver per-message DMARC- aligned-pass cascade boundary. Read THIS page when AUTHORING the per-publisher per- mailbox-provider per-IP per-day deliverability-engineering discipline; read the DKIM-alignment-with-DMARC spoke when EVALUATING the per-publisher per- domain DKIM-d=-tag vs RFC 5322 From- header organisational-domain alignment whose per-publisher per-domain DKIM- aligned-pass rate IS the load-bearing per-publisher per-mailbox-provider inbox- placement input variable every per- publisher per-domain deliverability outcome THIS page documents depends on as the authentication-trust-floor primitive.
• TLS-RPT report format (RFC 8460 §4 JSON-aggregate schema) — the per-receiver per-publisher per-day RFC 8460 §4 TLS-RPT JSON-aggregate-report byte-grammar reference companion to this email-deliverability discipline page. Where THIS page documents the per- publisher per-mailbox-provider per-day per-IP reputation curve, the Gmail Postmaster Tools / Outlook SNDS / Yahoo Sender Hub feedback-loop observability feeds, the Gmail+Yahoo Bulk-Sender- Requirements-2024 compliance discipline (one-click List-Unsubscribe per RFC 8058, DMARC publication at p=quarantine minimum, sustained authentication-pass- rate ≥ 99%, complaint-rate < 0.3%), and the inbox-placement vs spam-folder routing decision framework at the per- publisher per-domain deliverability outcome layer, the TLS-RPT report-format spoke documents the structurally parallel per-publisher per-domain transport-layer JSON-aggregate-report byte-grammar whose result-type enum (starttls-not-supported, certificate-host-mismatch, certificate- expired, certificate-not-trusted, validation-failure, sts-policy-fetch- error) IS the per-publisher per-domain transport-layer STARTTLS-handshake- observability primitive every modern mailbox-provider's TLS-encryption-rate KPI depends on. Four per-mailbox-provider TLS-handshake-vs-inbox-placement coupling dimensions matter at the per-publisher per-domain composite deliverability discipline boundary: (i) Gmail Postmaster Tools TLS-encryption-rate KPI — Gmail Postmaster Tools publishes per-publisher per-domain per-day TLS-encryption-rate as a deliverability KPI alongside the per- publisher per-domain authentication-pass- rate KPI THIS page documents; per- publisher per-day TLS-encryption-rate falling below the per-mailbox-provider Gmail expectation floor surfaces as the per-publisher per-domain TLS-RPT JSON- aggregate-report result-type evidence stream the report-format spoke documents byte-grammar for; (ii) Outlook SNDS transport-layer-encryption signal — Outlook SNDS surfaces per-publisher per-day sender-IP TLS-handshake-success-rate alongside the per-IP complaint-rate and the per-IP volume metrics THIS page's deliverability discipline depends on at the per-publisher per-mailbox-provider per-IP reputation curve boundary; the per- publisher per-domain TLS-RPT JSON- aggregate-report feed the report-format spoke documents IS the load-bearing per- publisher per-domain feed-back-channel that closes the loop on the Outlook SNDS per-IP per-day TLS-handshake-failure signal at the per-publisher per-domain deliverability-engineering boundary; (iii) Gmail+Yahoo Bulk-Sender-Requirements-2024 TLS-encryption requirement — the Gmail and Yahoo Bulk-Sender-Requirements 2024 announcements require per-publisher per- domain TLS-encryption on egress for all 5000+-per-day bulk-sender traffic, with non-TLS egress trips the per-publisher per-domain inbox-placement-vs-spam-folder routing gate THIS page documents the diagnostic procedure for; the per- publisher per-domain TLS-RPT publication the report-format spoke documents IS the load-bearing per-publisher per-domain transport-layer observability primitive every per-publisher per-domain Gmail+Yahoo Bulk-Sender-Requirements-2024 compliance- verification workflow depends on; (iv) per-publisher per-domain composite deliverability-engineering KPI portfolio — the per-publisher per-domain composite authentication-pass-rate + complaint-rate + bounce-rate + TLS-encryption-rate + one-click List-Unsubscribe-compliance KPI portfolio THIS page documents IS the load- bearing per-publisher per-mailbox- provider per-day per-IP reputation curve input variable every per-publisher per- domain inbox-placement outcome depends on; the per-publisher per-domain TLS-RPT JSON-aggregate-report data feed the report-format spoke documents IS the load- bearing per-publisher per-domain transport-layer KPI-portfolio component every per-publisher per-domain composite deliverability-engineering discipline consumes as the per-publisher per-domain transport-layer observability primitive. Read THIS page when AUTHORING the per- publisher per-mailbox-provider per-IP per-day deliverability-engineering discipline; read the TLS-RPT report- format spoke when EVALUATING the per- publisher per-day per-receiver TLS- handshake-failure JSON-aggregate-report evidence stream every per-publisher per- domain composite deliverability-and- transport-layer observability discipline depends on at the per-publisher per- mailbox-provider per-IP reputation curve coordination floor.
• DKIM-Signature header explained
• Why SPF alone is insufficient
• DMARC attacker-bypass catalogue
• DANE for SMTP (RFC 7672) explained — the PER-PUBLISHER-PER-MAILBOX- PROVIDER-DELIVERABILITY-CEILING-AS-LOAD- BEARING-DOWNSTREAM-CONSUMER-OF-PER- PUBLISHER-PER-MX-HOST-DANE-TRANSPORT-LAYER- TLS-CERT-AUTHORIZATION-PUBLICATION- DISCIPLINE companion to this email- deliverability reference. Where THIS page documents the per-publisher per-mailbox- provider per-day inbox-placement-vs-spam- folder routing-decision-floor (sender- reputation signal-floor, per-IP / per- domain reputation scoring, Gmail and Yahoo Bulk Sender Requirements per the 2024 rollout, per-publisher per-mailbox-provider per-day complaint-rate budget, per-publisher per-domain DMARC-policy publication- readiness floor), the DANE-explained spoke is the STRUCTURALLY-UPSTREAM transport- layer cryptographic-authorization-leg publication-discipline companion whose per-publisher per-MX-host TLSA-RR publication-discipline directly preserves per-publisher per-mailbox-provider per-day deliverability-ceiling signal-integrity at FOUR per-publisher per-domain deliverability- vs-DANE-transport-layer coupling dimensions: (i) per-publisher per- MX-host DANE TLSA-RR publication-discipline as load-bearing per-publisher per-domain anti-downgrade transport-layer defense preserving per-publisher per-mailbox- provider per-day TLS-handshake-success- rate — per-attacker per- publisher per-MX-host STARTTLS-stripping MITM-downgrade attack-class produces per- publisher per-mailbox-provider per-day plaintext-fallback bounce-rate spike that contaminates per-publisher per-domain sender-reputation signal-floor; per- publisher per-MX-host DANE TLSA-RR publication per RFC 7672 §3 closes this attack-class at the receiver-side STARTTLS-cert-validation execution boundary BEFORE per-message authentication- evaluation begins; (ii) per- publisher per-MX-host DANE TLSA-RR publication as anti-cert-mis-issuance defense closing per-attacker per-target- domain HTTPS-cert-acquisition attack- window adjacent to BEC-and-phishing sender-reputation contamination — per-attacker per-publisher per- domain CA-mis-issuance-or-substitution attack-class (cousin-domain HTTPS-cert acquisition for BEC + lookalike-domain phishing) directly drives per-publisher per-mailbox-provider per-day reputation- signal-floor regression THIS deliverability page documents the per-publisher per- domain commercial-outcome reference of; per-publisher per-MX-host DANE DANE-EE=3 end-entity-pin publication-decision closes this attack- window at the per-CA-issuance time per RFC 7672 §8; (iii) per-publisher per-MX-host DANE TLSA-RR publication- discipline as TLS-RPT per-MTA-connection evidence-stream substrate — per-publisher per-MX-host DANE TLSA-RR publication-discipline drift produces per- receiver per-day per-MTA-connection evidence rows in the TLS-RPT JSON aggregate report per RFC 8460 that operators consume alongside the per-publisher per- mailbox-provider per-day deliverability- signal-floor observability stream THIS deliverability page documents the per- publisher per-domain commercial-outcome observability reference of; (iv) per-publisher per-MX-host DANE TLSA-RR publication-discipline cadence coordination with per-publisher per- domain SPF + DKIM + DMARC publication- discipline cadence — per- publisher per-domain composite per-MX- host DANE TLSA-RR + per-publisher per- domain SPF apex-TXT-RR + per-publisher per-selector DKIM TXT-RR + per-publisher per-domain DMARC _dmarc.<d> TXT-RR publication-discipline portfolio coordination IS the load-bearing per- publisher per-mailbox-provider per-day anti-spoofing-and-anti-downgrade publication-discipline floor whose joint per-publisher per-domain publication-portfolio coordination underpins the per-publisher per-mailbox- provider per-day inbox-placement-vs- spam-folder routing-decision-floor THIS deliverability page documents the per- publisher per-domain commercial-outcome reference of. Read the DANE-explained spoke WITH this email-deliverability reference when AUTHORING per-publisher per-domain composite cross-layer anti- spoofing-and-anti-downgrade publication- discipline portfolio whose joint per- publisher per-domain publication- portfolio coordination directly drives the per-publisher per-mailbox-provider per-day deliverability-ceiling signal- floor at the per-publisher per-domain composite cross-layer publication- discipline-and-deliverability-ceiling coordination boundary.
• DKIM cryptography basics — the DKIM key-strength and algorithm-choice (RFC 6376 plus RFC 8301 RSA-2048 minimum plus RFC 8463 Ed25519 alternative plus rsa-sha256 mandatory algorithm) cryptographic-primer covering the per-publisher per-domain DKIM publication-floor every receiver evaluates as a deliverability input. RSA-1024 per-publisher per-selector keys and rsa-sha1 signing-algorithm publications fall below the modern per-receiver cryptographic-floor and surface as per-day per-receiver per-source-IP dkim=permerror attribution per RFC 7489 §6.6.1 in the DMARC RUA aggregate-report stream THIS deliverability framework documents the per-publisher per-day per-receiver per-mailbox-provider inbox-placement-vs-spam-folder observability of. The Ed25519 (RFC 8463) per-publisher per-selector dual-algorithm publication (RSA-2048 selector plus Ed25519 selector both signed per outgoing message) is the per-publisher per-domain forward-looking receiver-side cryptographic-margin publication-discipline the per-publisher per-mailbox-provider per-day deliverability-ceiling preservation pattern this deliverability framework presupposes is operating cleanly underneath at the cryptographic publication-floor coordination boundary.
• DKIM for Microsoft 365 — the provider-specific cryptographic-signing companion to this deliverability framework for senders on Microsoft 365. A correctly enabled DKIM signature (selector1/selector2._domainkey CNAME-delegated keys, Admin Center signing switched on for the custom domain) is a load-bearing input to the inbox- placement reputation this page documents: an M365 message that ships unsigned or with a mis-aligned d=<tenant>.onmicrosoft.com identity loses the DKIM-aligned-pass leg, weakens its DMARC posture, and cedes the sender-reputation margin the deliverability ceiling depends on. Read the DKIM-for-M365 spoke to confirm the message-signature leg under the deliverability framework is published cleanly on a Microsoft 365 tenant.
• DMARC alignment explained — inbox placement increasingly depends on a DMARC pass, and a DMARC pass requires alignment: the SPF- or DKIM-authenticated identifier must match the visible RFC5322.From domain (relaxed or strict). This spoke documents that alignment rule — the gate between “SPF/DKIM technically passed” and “DMARC passed,” which is what mailbox providers reward with reputation and inbox placement under the deliverability framework this page covers.
• RFC 5321 — Simple Mail Transfer Protocol — the canonical SMTP specification covering envelope semantics, 4xx vs 5xx response codes, and retry behaviour.
• RFC 3463 — Enhanced Mail System Status Codes — the X.Y.Z enhanced-status-code scheme that modern bounce messages use for fine-grained diagnostic information.
• RFC 8058 — One-Click Unsubscribe — the List-Unsubscribe-Post: List-Unsubscribe= One-Click extension required by Gmail and Yahoo Bulk Sender Requirements (February 2024).
• Microsoft SNDS + JMRP monitoring — the Microsoft-specific reputation feed behind inbox placement: per-IP SNDS filter verdicts (GREEN/YELLOW/RED), complaint rates, blocked ranges, and the JMRP Junk-click feedback loop for Outlook.com/Hotmail recipients.

14. Verify your deliverability foundation now

DMARC Analyzer's Domain Security Checker performs live DNS lookups for SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and CAA records against any domain — the authentication floor every deliverability optimization builds on. The Email Header Analyzer parses received Authentication- Results headers (via includes/EmailHeaderParser.php) so you can confirm what receivers are actually observing for a specific message. The DMARC aggregate-report pipeline (uploaded via upload.php or auto-ingested via IMAP / Microsoft Graph) surfaces every authentication outcome per source IP per recipient receiver — the authentication-side companion to the postmaster-tools triad. Enroll every sending domain in Google Postmaster Tools + Microsoft SNDS + Yahoo Sender Hub before scaling beyond ~1,000 recipients per day.

Verify my authentication foundation Sign up — Free plan