How we source these references

Deliverability “best practice” is not one stable body of knowledge. It is at least five separate layers, and merging them produces fuzzy, often wrong advice. This library keeps them apart.

The five layers we keep separate

• Protocol standards — the RFCs that define how email is sent, formatted, authenticated, and reported on.
• Mailbox-provider requirements — what Gmail, Yahoo, Microsoft, Apple and others actually enforce, which changes without much notice.
• Anti-abuse and reputation norms — how blocklist and reputation operators decide what to trust.
• Legal and regulatory obligations — what the law in a given country requires of senders.
• Vendor and operational advice — useful implementation notes from ESPs and operators, which are opinions, not standards.

When you read a page here, it tells you which layer a statement belongs to. A mailbox-provider threshold is not a law. A vendor recommendation is not an RFC.

How each fact gets here

1. We pull the claim from a primary source — the RFC, the provider’s own documentation, or the regulator, not a third-party blog summarizing them.
2. We record the exact value, the canonical URL, and the date.
3. We verify it against that primary source before it becomes copy.
4. We restate it in plain language, then add what it means operationally and how Egressif handles it.
5. We stamp the page with a Last checked date and cite the source at the bottom.

What we will not do

• We do not republish or paraphrase whole documents. We extract the obligation and link you to the original.
• We do not present mailbox-provider rules or vendor opinions as if they were law.
• We do not give legal advice. Compliance pages describe operational signals we help enforce; your counsel owns the legal call.
• We do not mass-produce thin pages to game search rankings. Every page here has to earn its place.

If a page looks stale, the Last checked date will tell you. Provider rules in particular move quickly, and we re-verify the ones that change most.