NOC | Postmaster

Email Authentication Requirements

Authentication is not a formality here: it is what lets us distinguish your legitimate traffic from someone forging your domain. Mail that fails all of the checks below is far more likely to be rejected or filtered, regardless of content.

• SPF — publish a record authorizing every legitimate sending source. Stay within the RFC 7208 limit of 10 DNS lookups: a record that exceeds it evaluates to a permanent error and is treated as unauthenticated. Never end the record with “+all”; use “~all” or “-all”.
• DKIM — sign all outbound mail. Use 2048-bit keys; 1024-bit is the accepted floor, not a target. Rotate selectors periodically and remove the retired public keys from DNS.
• DMARC — publish a policy with a working aggregate report address and actually read the reports it produces. A policy of “none” is fine while you are measuring, but it is a starting point, not a destination. Make sure at least one of SPF or DKIM aligns with the domain in the From header: SPF passing on a bounce domain that does not align gives you nothing under DMARC.
• Reverse DNS (PTR) — every sending IP must have one. Generic, dynamic-looking or absent reverse DNS on a mail source is a strong negative signal.
• Forward-confirmed reverse DNS — the name returned by the PTR must resolve back to the same IP address. A PTR pointing to a name with no matching A or AAAA record is worse than no PTR at all.
• HELO/EHLO — must be a fully qualified domain that resolves, and should match the PTR of the connecting IP. Bare IP literals, “localhost” and invented names are treated as abuse indicators.
• List-Unsubscribe — bulk senders should provide both the List-Unsubscribe header and RFC 8058 one-click unsubscribe, and honour requests within two days. Major providers now require this, and so do we for any high-volume stream.

Deliverability Best Practices

• Send only to recipients who opted in, and keep the proof: date, source and IP of the subscription;
• Suppress hard bounces immediately and retire addresses that soft-bounce repeatedly;
• Keep complaint rates below 0.1%. Above roughly 0.3%, expect throttling from every large provider;
• Separate transactional traffic from marketing traffic — different IPs, and ideally different subdomains, so one cannot poison the other;
• Use authenticated submission (port 587 with STARTTLS, or 465 with implicit TLS) for anything originating from an application or a workstation;
• Warm new IP addresses and new domains gradually; a volume spike from a cold IP looks exactly like a compromise;
• Avoid URL shorteners and long redirect chains — they hide the destination and are heavily abused, so they are scored accordingly;
• Keep the subject line honest and consistent with the body;
• Do not use a free-mail domain in the From header of bulk mail;
• Comply with the applicable privacy legislation (LGPD in Brazil, GDPR in the EU, and equivalents);
• Monitor your own reputation continuously instead of discovering problems from rejection messages.

Reputation and Blocklist Checks

Before contacting us, check whether the problem is broader than our network. If you are listed at Spamhaus, you are almost certainly listed with us as well, and fixing the source resolves both.

• Spamhaus Blocklist Removal Center — SBL, XBL, PBL and DBL;
• MXToolbox Blacklist Check — broad multi-list overview;
• MultiRBL — the widest list coverage, including forward and reverse DNS consistency checks;
• Barracuda Reputation Block List;
• Cisco Talos Reputation Center — IP and domain reputation, plus observed volume;
• Validity Sender Score;
• SURBL — note that SURBL and URIBL list domains found in message content, not sending IPs. If you are listed there, look at the URLs in your mail, not at your MTA.

Major Provider Postmaster Resources

• Google Postmaster Tools — domain-based reputation, authentication and spam rate for Gmail;
• Microsoft SNDS — Smart Network Data Services, IP-based data for Outlook.com, Hotmail and Live. The service moved to this address during 2026; update any automation still pointing at the old sendersupport.olc.protection.outlook.com URLs;
• Microsoft JMRP — Junk Email Reporting Program, Microsoft’s complaint feedback loop, now enrolled from inside the SNDS portal;
• Yahoo Sender Hub — complaint feedback loop and sender services for Yahoo and AOL, which share the same filtering infrastructure. The former standalone AOL postmaster no longer exists;
• Yahoo Postmaster — documentation and delisting requests for Yahoo and AOL;
• Apple iCloud Mail Postmaster — sending policies for iCloud Mail.

Google Postmaster Tools is keyed by domain and Microsoft SNDS is keyed by IP address. If you send from IP space you do not control, only the domain-side tools are available to you.

SMTP Security and Inbound Filtering

Connections to our MX servers are evaluated against, among other criteria:

• TLS availability and negotiated version;
• Reverse DNS, forward-confirmed reverse DNS and HELO/EHLO consistency;
• SPF, DKIM and DMARC evaluation, including alignment;
• Public DNSBL and URIBL listings;
• Our own historical reputation data for the source IP, network and domain;
• Rate limits per IP address, per sender and per recipient;
• Anti-spam content analysis and anti-malware scanning of bodies and attachments.

We do not publish thresholds or scoring weights, for the obvious reason. Filtering rules and additional validation mechanisms may be added or changed at any time, without prior notice, when required to protect the platform.

Abuse Handling Policy

We operate a zero-tolerance policy towards spam, malware, phishing, botnet traffic, open relays, unauthorized bulk email, email spoofing and fraudulent activity of any kind.

Traffic matching these categories may be blocked automatically, without prior notice and without a manual review preceding the block. Review happens on request, after the fact, through the delisting procedure. This is a deliberate trade-off: protecting our users comes before minimizing false positives, and we would rather correct a wrong block than let an active campaign run while a ticket is triaged.