Sender Policy

Introduction

This policy outlines our company’s position on email anti-abuse mechanisms and acceptable email practices. It aligns with industry Sender Best Practices as advocated by major email providers and organizations such as M3AAWG.

Our goal is to ensure high deliverability, security, and compliance for both inbound and outbound email by adhering to proven standards. This document covers requirements for authentication (SPF, DKIM, DMARC), sending protocols, header integrity, rate limiting, and compliance with applicable laws.

It applies to all email sent to or from our infrastructure.

Authentication and Domain Identity

Use Industry-Standard Authentication

All inbound email must be authenticated using the industry-standard methods of Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) at a minimum. For any domain sending more than 5,000 messages per day to our systems (high-volume senders), we require SPF and DKIM to be correctly configured and for the tests to pass.

Outbound emails from our platform must be:

1. Authenticated using an end user’s credentials; and
2. DKIM-signed by us to the best of our ability.

Implement DMARC

We strongly recommend and, for high-volume senders, require Domain-based Message Authentication, Reporting, and Conformance (DMARC) records on sender domains. DMARC should be configured with at least a monitoring policy (p=none) and ideally an enforcement policy, to instruct how to handle emails failing authentication.

We will always honour DMARC policies set on remote domains. We will treat domains without DMARC as more suspicious than those with an appropriate DMARC policy.

Our outbound domains will have DMARC policies, and we advocate that all customers correctly configure a DMARC policy for domains that we host.

Notably, the sender’s Header From: address domain must align (match) with the authenticated domain (SPF and/or DKIM) to pass DMARC alignment. We do not permit spoofing of domains that don’t belong to the sender. If a user attempts to send a message using a From-domain without proper alignment or authorization, our system will reject the message. This protects against forged sender identities and ensures DMARC alignment. This protects against forged sender identities and ensures DMARC alignment.

No Forged Headers or Identities

All email headers, particularly the From and Reply-To, must accurately reflect the sending domain and user. The From address should be valid, owned by the sender or customer, and able to receive replies.

We do not allow any outbound emails with forged or misleading header information. Using deceptive headers or pretending to be another domain (impersonation) is strictly forbidden. Internally, our mail system enforces that the authenticated user or domain matches the email’s headers – if not, the sender may be modified to an appropriate address (e.g., an on-behalf-of address) or the message may be blocked.

Address Verification for Outbound Senders

Infrastructure and Technical Requirements

DNS and IP Configuration

All sending mail servers (both ours and external senders connecting to us) must have correct DNS configurations. This includes a valid A record and a PTR (reverse DNS) record for the sending IP address that maps back to the sending domain.

Our outbound mail IP addresses have PTR records matching our domain, and we expect the same of inbound senders – messages from domains/IPs lacking valid forward and reverse DNS may be refused or flagged.

We also require that HELO/EHLO identifiers are not obviously fraudulent (e.g., they should match the domain of the sending server).

TLS Encryption

We use TLS (Transport Layer Security) for transmitting email wherever possible. Our servers support STARTTLS for inbound and outbound SMTP.

We require outbound clients to use TLS on submission, and we prefer inbound connections to be encrypted. Emails sent without encryption may be accepted (to preserve compatibility), but senders are strongly encouraged to use TLS for privacy and security. We also implement policies such as MTA-STS and DANE, where applicable, to enforce transport encryption with our partners.

Strict Protocol Adherence (SMTP and RFC Standards)

All emails must adhere to standard Internet message formats and protocols. Senders should comply with SMTP protocol (RFC 5321) and Internet Message Format (RFC 5322) requirements.

For example, messages must have a valid Message-ID header, properly formatted addresses, a single From address, and no malformed MIME parts. Inbound, if a sending server violates fundamental SMTP rules or sends corrupt headers, our server may reject the message. Outbound, we ensure that our system generates compliant headers and line formatting (e.g., no bare line feeds, correct MIME encoding, etc.).

Anti-Abuse Network Controls

We subscribe to reputable IP blocklists and threat intelligence feeds. Connections from known spam sources or insecure open relays will be blocked at the network level. We also block emails with obviously malicious payloads (viruses, phishing content) via our email security filters. Any inbound SMTP session exhibiting abusive behavior (such as command pipelining violations, excessive recipient failures, or other signs of spambot activity) may be terminated.

Our outbound servers are secured against being an open relay. Authentication is required ,and outbound traffic is monitored to prevent spam outbreaks.

Inbound Email Acceptance Policy

As a mailbox provider, we receive large volumes of inbound email for our end users. We apply strict criteria to identify legitimate messages and reject or filter out abusive emails:

• Authentication and Domain Reputation: We verify the SPF, DKIM, and DMARC status of incoming emails. While we will not outright reject all mail lacking these (to avoid false positives), messages that fail SPF/DKIM and come from domains with a published DMARC policy will be handled according to that policy (quarantined or rejected). We also consult domain and IP reputation. Senders with very poor reputations may have their emails rejected or heavily throttled.
• DNS and Identification Checks: Inbound SMTP connections must have a resolvable reverse DNS and a matching HELO name. Emails from IPs without rDNS, or where rDNS suggests a dynamic/pool address, may be rejected. We verify that the sender’s domain exists and has an MX or A record. Messages claiming to be from our own domains (or other high-value domains) but not coming through the proper channels are dropped.
• Anti-Spam Content Filtering: We use content-based spam filters and machine learning to scan inbound emails. Messages that score high on spam metrics or resemble phishing attempts may be quarantined or rejected.
• Rate Control and Throttling (Inbound): We implement connection and message rate limiting. Excessive bursts may be deferred (4xx “try again later”). Sustained or excessive rates exceeding acceptable thresholds can result in temporary blocks.
• Rejection of Abusive Mail: If an inbound message violates our policies (e.g., malware detected, phishing detected, fails authentication on a domain with strict policy, etc.), our mail system will reject it with an appropriate SMTP error.

Regulatory Compliance (GDPR, Australian Spam Act, etc.)

We are committed to complying with all relevant anti-spam and privacy laws in the regions we operate. All email practices must conform to the strictest applicable regulations, including:

• GDPR (EU General Data Protection Regulation): We treat email addresses and any personal data of recipients in accordance with GDPR. Senders must have a lawful basis (such as consent). Users have rights to unsubscribe and request deletion. We assist customers in fulfilling GDPR data subject requests.
• Australia’s Spam Act 2003: For messages sent to or from our environments, regardless of region, we require compliance with the Australian Spam Act (consent-based sending, sender identification, and unsubscribe).
• Other Jurisdictions: We respect anti-spam and privacy laws of other countries (e.g. CASL in Canada, PECR in the UK). Core principles are consent, identification, and unsubscribe. As an Australian company, the Australian Spam Act applies to all our servers regardless of location.

Our platform provides features (like automatic inclusion of unsubscribe links and tools to manage suppression lists) to help with compliance. However, it is the sender’s responsibility to ensure that their email content and recipient list handling comply with legal requirements. We will act against senders who violate spam laws or this policy – up to and including suspension of sending privileges.

Monitoring and Enforcement

Adhering to these best practices is encouraged and monitored. We use several mechanisms to ensure compliance and help senders improve:

• Feedback Loops and Complaint Handling: We leverage FBLs from ISPs, log complaints against sender accounts, and engage with senders to remediate issues. Repeat offenders may be temporarily blocked while remediation is in proccess.
• Anti-Abuse Systems: Automated systems detect abnormal sending patterns and can rate-limit, quarantine, or suspend sending in real time. In likely account compromises, we block activity and reset credentials.
• Engagement and List Quality: We encourage good list hygiene and sending to engaged users. Poor engagement can contribute to spam classification.
• Collaboration with Industry Standards: We follow guidance from M3AAWG and consider recommendations from organizations such as the Certified Senders Alliance (CSA). We continually update this policy as best practices evolve.

Enforcement: Violations may result in technical blocking, warnings from our postmaster/abuse team, or suspension of service in severe cases. We prefer constructive remediation, but will not tolerate intentional abuse.

Conclusion

By following this Sender Policy, our company and its clients can ensure we maintain a secure, trusted email ecosystem. Measures such as enforcing SPF/DKIM/DMARC, proper headers, rate limiting, and honoring unsubscribes reduce abuse and improve deliverability.

We are committed to aligning with industry best practices and legal requirements: only wanted emails should traverse our network. Through collective vigilance and adherence to these standards, we protect end-users and ensure that legitimate communications reach the inbox reliably.

Contact Us

For practical sender guidance, including delivery troubleshooting, sending limits, and a full reference of the SMTP response codes our platform issues, see our Postmaster page.

For questions about this policy, or to reach the teams that enforce it:

• Postmaster (delivery and operations): [email protected] for bounce questions, delisting and blocklist requests, DNS and authentication problems, and delivery issues to or from domains we host.
• Abuse desk: [email protected] for reports of spam, phishing, or other abuse originating from our network or customers.

When reporting a delivery issue, please include the details listed under Contact Support on the Postmaster page (full SMTP transcript, sending IP, Message-ID, and related information) so we can investigate without delay.