Do not send e-mail to me!

Query and delist

Rules for free delist


  • Only IP with rDNS pointing to the same IP will be accepted, with FCrDNS validation;
  • The rDNS must be in the domain of the MTA administrator, so third-party domains such as the generic rDNS of the data-center or ISP will not be accepted;
  • The postmaster account must be configured for the domain registered on the rDNS and the account must be active and responding;
  • If you are using an IPv6 with SLAAC flag, you must keep port 25 opened to proof the existence of an active SMTP service and
  • Reputation of IP should be below 25% of negative points per total send volume.


Rules for paid delist


  • Only static IPs with configured reverse, even if FCrDNS is invalid;
  • A PayPal account is required for the email address of this account to be assigned to the IP, as responsible for the abuse;
  • The PayPal user must agree to have their email address shown publicly on this platform as responsible for the abuses of that IP and
  • Reputation of IP should be below 25% of negative points per total send volume.



Important: If possible, include in your whitelist to prevent your MX to reject messages from our system, such as greylisting or content filtering. We will not support in cases where MX is deliberately rejecting messages from our system, especially if the recipient is the postmaster because RFC 5321 does not allow the use of any type of rejection filter for the postmaster.


Important: Any email address used in the delist process will be considered responsible for the abuses of that specific IP and will receive reports of abuse of this IP in the ARF format at this same email address. All submitted reports should be treated otherwise the same IP will be listed again.


Important: In the case of payment, the user will be paying for the inclusion of his PayPal email in our database as responsible for the abuses of that IP and not exactly by the delist itself. Once included as responsible, that email address can be used several times to delist the same IP in case of new listings, without the need for new payments. The new responsible should read all the ARF reports sent and take the necessary steps, otherwise the record of this email address will be deleted, and then he will have to make a new payment for a new inclusion.


Tip: Consider using the SPFBL special rejection prefix to contain unwanted flow directly from your outgoing MTA: 5.7.1 SPFBL <message>. A script that is able to monitor this prefix and freeze email accounts can be a strong ally to prevent your IP from being listed. All negative points of our DNSBL are generated with rejections, at the SMTP layer, with this prefix. Minimizing the incidence of this prefix helps to have IPs always clean, with good reputation and a faster delist.