REST Compliant Response From Email Validation API

The GET Method on the REST API endpoint /api/validations/addresses/:addressToValidate has been updated to return a JSON object. Previously, this endpoint was returning an array. The POST Method response remains unchanged.

An example GET request and response has been added to the Mailsac REST API documentation.

Email validation via the Mailsac Website is still available to all registered customers. An email address can be checked for valid format and if it is associated with any known disposable email services.

Email Forwarding Changes

Email can be forwarded using websockets, webhooks, slack, and catchall. The way email is forwarded has been changed for consistency. Reserved addresses, which are part of a catchall domain, will now be the inbox email is saved to. Catchall forwarding will still take place on websockets, webhooks, and slack webhooks.

Examples:

Improved SMTP Responses and Throttling Changes

SMTP Responses

The robustness of our SMTP server has been improved by providing better response codes.

  • Response code 553 when email is missing a recipient
  • Response code 421 when inbound email is being throttled and the server is unable to accept the message until a later time
  • Response code 554 with meaningful error message describing the cause (blacklisting or internal server error)

Throttling Improvements

Incoming SMTP connections will be queued based on system load. The connection will stay open while waiting for system resources. If the SMTP connection cannot be completed in a reasonable period of time the server will issue a response code of 421. This situation may be encountered while sending a large amount of email from a specific server or to Mailsac hosted email address.

We offer custom domains to get around throttling, in all but the heaviest DDOS scenarios. Also, Enterprise customers can visit mailsac.com/enterprise to view higher performance or dedicated deployments.

API Response Fixes

The status code for reserving an address on the API was returning a 302 in some situations, while the documentation said it was a 200. This has been resolved. This endpoint for reserving an address will also return the address object.

When deleting a private address, the API used to return { "ok": true } with a 200 status code. Now the API will return a 200 a copy of the address object which was deleted.

Official API documentation