Postmaster Information

We are committed to delivering a reliable and secure email service. To protect our users, we continuously evaluate incoming and outgoing email for spam, phishing, malware, and abusive sending behavior.

This page explains how to improve deliverability to our users and how to troubleshoot common delivery issues. Please review this guidance before contacting support.

This page contains

---

Quick Checklist

Before you contact support, confirm the following:

• Your sending IP has a valid reverse DNS (PTR) record.
• Your HELO/EHLO is a fully qualified domain name (FQDN) and matches your sending infrastructure.
• Your envelope sender domain (MAIL FROM) publishes SPF and your sending IP is authorized.
• Your messages are DKIM-signed and the DKIM signature validates.
• Your From domain publishes a DMARC policy (recommended) and authentication aligns where possible.
• You are not sending to invalid recipients and you are honoring bounces and complaints promptly.
• If you receive a 4xx error, you are retrying with backoff (not aggressively reconnecting).

Email Delivery Guidelines

To improve acceptance and reduce spam classification:

• Follow SMTP and message format standards.
  Ensure messages include mandatory headers and are compliant with
  RFC 5321 (SMTP) and RFC 5322 (Internet Message Format).
• Maintain a stable sending identity.
  Use a static sending IP and consistent domains for campaigns and transactional mail.
• Keep DNS correct and complete.
  • Reverse DNS (PTR) must exist for the sending IP and point to a hostname you control.
  • The hostname used for HELO/EHLO should be an FQDN (example: mail.example.com).
  • Your sending domains should have valid A and/or MX records.
• Use TLS.
  TLS is strongly recommended for connections to our platform.
• Keep recipients and list hygiene clean.
  • Remove invalid recipients immediately (5.1.1 / invalid recipient responses).
  • Process bounces and complaints quickly and suppress unengaged recipients.
• Avoid sudden bursts.
  Ramp volume gradually, limit fanout, and spread delivery over time.

Authentication

Authentication improves delivery and helps protect our users. At least one of the mechanisms below should pass for legitimate mail, and we strongly recommend implementing all three.

SPF (Required)

Publish an SPF record in DNS for your envelope sender domain (MAIL FROM). The sending IP must be authorized by that SPF record.

Example SPF record:

example.com TXT "v=spf1 ip4:192.0.2.10 include:_spf.example.net -all"

• If SPF fails, verify the correct domain is used for MAIL FROM and that your sending IP is included.
• If you recently updated DNS, allow time for caches to expire based on your TTL.

DKIM (Strongly Recommended)

DKIM signing helps prove message integrity and improves deliverability. Ensure messages are DKIM-signed and that the signature validates.

• Publish the DKIM public key in DNS for your selector.
• Avoid modifying message content after signing (forwarding or gateways can break DKIM).

DMARC (Recommended)

DMARC ties SPF/DKIM results to the visible From domain and provides policy guidance. Publish a DMARC record for your From domain and align authentication where possible.

Sending Limits

Sending limits vary based on reputation and traffic patterns. If you are receiving temporary deferrals (4xx), reduce sending rate immediately and retry later with backoff.

• Concurrent connections: keep concurrency low and stable per IP.
• Recipients per message: avoid high fanout; reduce recipients if rate limited.
• Messages per connection: avoid long-running, high-volume sessions.

Notes for Large Senders

If you send high volumes (for example, campaigns or automated notifications), follow these additional guidelines:

• Follow M3AAWG best practices.
• Use confirmed opt-in where applicable and provide one-click unsubscribe for bulk mail.
• Keep complaint rates low and suppress recipients who are not engaging.
• Ensure SPF, DKIM, and DMARC pass and are aligned with your visible From domain.
• Make your sender identity clear (branding and legal identity should match your sending domains).
• If you receive 4xx responses, back off immediately and slow down; do not increase retries.

Error Series Overview

2xx — Accepted

Message accepted or informational discard. No resend required.

3xx — Quarantine / Suspect

Message quarantined for review. Check sender reputation and content quality.

4xx — Temporary Deferral

Temporary throttling or processing issue. Slow down and retry later with exponential backoff.

5xx — Permanent Rejection

Message permanently rejected. Fix the underlying issue before resending.

Rate Limiting & Connection Controls

These responses indicate your sending IP has exceeded a connection or delivery rate threshold. Reduce volume and retry with backoff.

4.7.3 Policy-IPCRC — Recipient count rate limited

Meaning: Your IP has sent to too many recipients within the rate window.

Action: Reduce recipients per interval. Retry later with backoff.

4.7.1 Policy-IPCIRC — Invalid recipient rate limited

Meaning: Too many messages to non-existent recipients from your IP.

Action: Clean your recipient list. Remove invalid addresses and slow down retries.

4.7.3 Policy-IPCS — Send rate exceeded

Meaning: Overall send rate from your IP exceeded limits.

Action: Throttle throughput and ramp back up gradually.

4.7.3 Policy-IPCCC — Concurrent connections refused

Meaning: Too many simultaneous SMTP connections from your IP.

Action: Reduce concurrency and add spacing between connections.

4.7.1 Policy-IPCSPAM — Spam threshold exceeded

Meaning: Your IP’s spam/abuse score has exceeded the threshold.

Action: Pause sending. Remediate list quality and message content, then resume slowly.

4.7.3 Policy-IPCPSMC — Per-session mail count limit

Meaning: Too many messages sent within a single SMTP session.

Action: Lower per-session volume. Disconnect and reconnect with pacing.

4.7.1 Policy-IPCPMRC — Too many recipients per message

Meaning: A single message addressed too many recipients.

Action: Reduce recipients per message (split into multiple messages).

Policy Throttles (Policy-DC*)

These responses indicate sender-level (envelope address) rate limiting has been triggered.

4.7.0 Policy-DC00 — Sender rate limited

Meaning: The sending address has exceeded its delivery rate.

Action: Reduce send rate. Retry later with backoff.

4.5.3 Policy-DC01 — Temporarily refused (sender policy)

Meaning: Temporarily refused due to a sender-level content or classification policy.

Action: Pause, reduce volume, and retry later.

4.7.1 Policy-DC02 — Unauthenticated branded daily limit

Meaning: Unauthenticated branded mail has exceeded its daily send limit.

Action: Authenticate with SMTP credentials and reduce volume. Retry after the limit window.

4.7.1 Policy-DC03 — Unauthenticated daily limit

Meaning: Unauthenticated mail from this sender has exceeded its daily limit.

Action: Set up authenticated SMTP. Retry after the limit window.

4.7.5 Policy-DC04 — Pattern/campaign rate limited

Meaning: Sending patterns (e.g., repetitive subject lines) triggered rate limiting.

Action: Reduce frequency and repetition. Spread traffic out over time.

4.7.5 Policy-DC05 — Class policy rate limited

Meaning: A sender classification policy has triggered rate limiting.

Action: Throttle and retry with pacing.

Policy Decisions (Policy-DT*)

These responses reflect content scanning, authentication verification, and policy enforcement decisions made during the DATA stage.

Note for automated processing: match codes as whole tokens, not prefixes. In particular, Policy-DT51 is a prefix of Policy-DT510; match up to a word boundary (for example Policy-DT51 followed by a space) to distinguish them.

Temporary Deferrals (4xx)

4.2.1 Policy-DT40 — Processing failure

Meaning: A temporary processing failure occurred during content evaluation.

Action: Retry later with exponential backoff.

4.7.1 Policy-DT41 — Soft deferral

Meaning: Message deferred due to greylist-style or reputation-based soft policy.

Action: Retry later. Do not flood retries.

4.7.1 Policy-DT42 — Deferred due to SPF

Meaning: Temporary SPF validation issue (DNS timeout or similar).

Action: Retry later. Verify SPF record and DNS health. Allow TTL to expire after changes.

4.7.1 Policy-DT43 — Deferred due to DMARC

Meaning: Temporary DMARC record lookup or policy issue.

Action: Retry later. Verify DMARC record availability in DNS.

Permanent Rejections (5xx)

5.7.1 Policy-DT51 — Phishing detected

Meaning: Message identified as phishing or containing deceptive content.

Action: Remove impersonation patterns, suspicious URLs, and deceptive content.

5.7.1 Policy-DT52 — Policy violation (hard reject)

Meaning: Message permanently rejected based on combined policy signals.

Action: Review content, links, sender reputation, and recipient quality.

5.7.1 Policy-DT53 — Malware detected

Meaning: Malware, virus, or infected payload detected in the message.

Action: Remove infected payloads/URLs and scan all templates before resending.

5.7.1 Policy-DT54 — RFC 5322 non-compliant

Meaning: Message is missing required headers or does not comply with RFC 5322 format.

Action: Fix message construction. Ensure required headers (From, Date, Message-ID, Subject) are present.

Note: A subset of our mail exchangers previously issued Policy-DT54 with the text “Message permanently rejected – Policy violation”. If your rejection matches that text, refer to Policy-DT52 instead.

5.7.1 Policy-DT55 — Content policy violation

Meaning: Message rejected due to content policy (known bad patterns or subject lines).

Action: Revise content, links, and sending practices before resending.

Note: A subset of our mail exchangers previously issued Policy-DT55 with the text “malware found”. If your rejection matches that text, refer to Policy-DT53 instead.

5.7.1 Policy-DT56 — DMARC policy rejection

Meaning: The sender’s DMARC policy specifies rejection and authentication did not align.

Action: Align SPF/DKIM with the visible From domain. Verify DMARC policy settings.

Note: If you received this code while sending outbound through our platform (authenticated submission or relay), it indicates a content policy rejection of the submitted message rather than a DMARC failure; follow the guidance under Policy-DT510.

5.7.1 Policy-DT57 — SPF policy rejection

Meaning: SPF evaluation returned a hard fail for the sending IP.

Action: Authorize the sending IP in your SPF record. Ensure MAIL FROM uses the correct domain.

5.7.1 Policy-DT58 — DKIM validation failed

Meaning: The DKIM signature on the message did not validate.

Action: Fix DKIM signing configuration and DNS selector records. Prevent message rewriting after signing.

5.7.1 Policy-DT59 — Unverified sender with adverse content

Meaning: Message from an unauthenticated sender combined with adverse content signals.

Action: Implement SPF, DKIM, and DMARC. Improve list quality and content.

5.7.1 Policy-DT510 — Spam rejection

Meaning: Message rejected as spam based on content scoring.

Action: Remediate content, links, and list quality before resending.

Informational Outcomes

3.7.1 Policy-DT31 — Quarantined

Meaning: Message quarantined for review (not delivered to inbox).

Action: Review sender reputation and content. Adjust sending practices.

2.7.1 Policy-DT21 — Discarded

Meaning: The message was classified as known-bad traffic and was not delivered.

Action: Review sending behavior and message content. If you believe this is an error, contact support with your SMTP transcript.

Fallback Responses

These generic responses appear when a message is handled by a default policy action rather than a specific rule. They are most commonly seen when sending outbound through our submission service.

2.0.0 Policy-DT200 — Accepted (default)

Meaning: Message accepted without a more specific policy annotation.

Action: None required.

4.7.1 Policy-DT400 — Temporary deferral (default)

Meaning: Message temporarily deferred by a default policy action.

Action: Retry later with exponential backoff.

5.7.1 Policy-DT500 — Rejected (default policy)

Meaning: Message permanently rejected by a default policy action.

Action: Review the guidance on this page. If the cause is unclear, contact support with your full SMTP transcript.

5.7.1 Policy-DT500D — Sender blocked

Meaning: The sending address has been blocked due to abusive traffic patterns. If you are a customer, your account may be compromised.

Action: Secure the sending account (change the password and review connected devices), then contact support to request a review.

Sender Policy (Policy-MFRM*)

These responses are issued during the MAIL FROM stage based on sender address and domain reputation checks.

5.7.1 Policy-MFRM52 — Sender address blocked

Meaning: The sender email address is on the global blocklist.

Action: If you believe this is an error, contact support with your sender address and SMTP transcript.

5.7.1 Policy-MFRM53 — Sender domain blocked

Meaning: The sender’s domain is on the global blocklist.

Action: Contact support. Review domain reputation and sending practices.

5.7.1 Policy-MFRM54 — Sender TLD blocked

Meaning: The sender’s top-level domain is globally blocklisted.

Action: Contact support if you believe this is a false positive.

5.7.1 Policy-MFRM55 — Abusix DBL block

Meaning: The sender’s domain is listed on the Abusix domain blocklist.

Action: Check your domain status at Abusix Lookup and request delisting if resolved.

5.7.1 Policy-MFRM56 — ABL IP block

Meaning: The sending IP is currently listed on our internal blocklist (ABL).

Action: Contact support with your sending IP and SMTP transcript.

5.7.1 Policy-MFRM57 — Blocked due to abuse

Meaning: The sender domain matches a known abuse pattern.

Action: Remediate abuse and contact support to request review.

5.1.8 Policy-MFRM58 — Invalid sender domain

Meaning: The sender address uses an invalid or non-existent domain.

Action: Correct the MAIL FROM address to use a valid, resolvable domain.

Connection & HELO

These responses are issued at the connection or HELO/EHLO stage, before any mail transaction begins.

conn-401 — IP throttled

Meaning: Your IP is being temporarily throttled based on reputation or recent behavior.

Action: Slow down connection attempts. Retry later with backoff.

conn-502 — IP blocked

Meaning: Your IP is blocked due to a real-time blocklist (RBL) listing or internal policy.

Action:
Check your IP status on the referenced blocklist.
For Abusix listings: Abusix Lookup.
For Cloudmark listings: Cloudmark CSI.
If listed on our internal ABL, contact support.

helo-502 — HELO/EHLO blocked

Meaning: The HELO/EHLO hostname you presented is blocked due to abuse.

Action: Use a valid FQDN for your HELO/EHLO that matches your sending infrastructure and has proper DNS.

Recipient & Infrastructure Responses

These are standard SMTP responses related to recipient validity and backend processing.

550 5.2.1 — Mailbox suspended

Meaning: The recipient’s mailbox is suspended or disabled.

Action: Suppress this recipient and stop retries.

550 5.1.1 — Recipient does not exist

Meaning: The recipient address does not exist on our platform.

Action: Remove the address immediately. Do not retry.

550 5.1.2 — Domain does not exist

Meaning: The recipient’s domain is not hosted on our platform.

Action: Validate the domain and DNS before resending.

rt-403 — Mailbox quota exceeded

Meaning: The recipient’s mailbox is full (temporary).

Action: Retry later with normal backoff.

rt-500 — Relay denied / recipient limit

Meaning: Relay denied, too many recipients, or too many invalid recipient attempts.

Action: Authenticate your connection. Reduce fanout and invalid recipient attempts.

data-401 / data-400 / cnx-401 / helo-401 / mf-400 — Backend processing failure

Meaning: A temporary backend or policy processing failure occurred.

Action: Retry later with backoff. Avoid aggressive reconnect loops.

sess-500 — Session expired

Meaning: Your SMTP session timed out or expired.

Action: Reconnect and resend remaining queue with pacing.

Contact Support

If issues persist after following this guidance, contact our Postmaster/Abuse team and include the details below. Missing information may delay investigation.

• [email protected] – mail delivery and operations issues: bounce questions, delisting/blocklist requests, DNS/authentication problems, delivery issues to or from Atmail-hosted domains.
• [email protected] – reports of spam, phishing, or other abuse originating from Atmail’s network or customers.

Please include the following details with your request:

• Full SMTP transcript (including the exact response text)
• Sending IP address
• Message-ID header
• HELO/EHLO hostname
• Envelope sender (MAIL FROM) and recipient (RCPT TO)
• Date/time of the attempt (with timezone)