Skip to content

Mimecast

Fromenance is a communication provenance platform that answers forwards sent to verify@yourdomain.com. With Mimecast in front of your mail, the redirect usually stays on the mailbox platform and Mimecast only has to let the customer’s forward in and the redirected copy out untouched.

By the end you will have verify@ reachable through Mimecast, the redirect configured, disclaimer stamping excluded for the redirected copy, and the forwarding test marked Working.

Mimecast does not offer a per recipient redirect to an external address in its standard policy set; address alteration policies rewrite addresses on inbound or outbound mail rather than redirecting delivery. Keep the redirect on the mailbox platform (Google Workspace or Microsoft 365) and configure Mimecast so the two legs pass cleanly:

  1. Inbound leg: a customer at any external address writes to verify@yourdomain.com with a forwarded message, often as an .eml attachment.
  2. Outbound leg: the platform redirects that message to northfield@verify.fromenance.com. The customer is still the sender. Mimecast sees external sender, external recipient, on your outbound route.
  1. Administration Console, Gateway, Policies, Attachment Management (or Attachment Protection). Add a definition that permits message/rfc822 and .eml attachments, and a policy scoped to recipient verify@yourdomain.com that applies it. Sandboxing the attachment is fine; blocking or stripping it removes the message the customer is asking about.
  2. Gateway, Policies, Spam Scanning: confirm verify@ inherits the default action of deliver with tagging rather than hold. Held mail never reaches Fromenance.
  3. Gateway, Policies, Impersonation Protection: forwards of phishing samples trigger impersonation hits by design. Add a bypass policy with recipient verify@yourdomain.com so samples are delivered rather than held. Fromenance handles abuse on its side; the fraud list is only ever written by your analysts.
  1. Gateway, Policies, Stationery (disclaimers and signatures): create a policy at the top of the list with Emails to = *@verify.fromenance.com, stationery None, and Policy override enabled so it wins. A stamped disclaimer breaks the DKIM body hash and Fromenance rejects the copy with auth_failed.
  2. Gateway, Policies, Document Services or Content Examination: exclude recipient *@verify.fromenance.com from any policy that rewrites or strips content.
  3. Gateway, Policies, DNS Authentication - Outbound (DKIM signing): if Mimecast is your outbound relay, confirm signing is enabled for yourdomain.com with a published selector. The redirected copy is signed by whichever system is the last hop; if that is Mimecast, its signature for your domain is what Fromenance checks. If Mimecast relays but does not sign, the Microsoft ARC seal or the Google DKIM signature from the platform must survive untouched, which the policies above ensure.
  4. URL Protect rewrites links in the customer’s forward on the inbound leg. That is expected and Fromenance’s normalization handles rewritten links from Mimecast, Proofpoint, Microsoft, and Google.

Follow Google Workspace or Microsoft 365. If Mimecast is also your outbound connector, the platform’s redirect is delivered through Mimecast; nothing else changes.

  1. Setup wizard, step 4, Send test, or POST /v1/domains/{id}/forwarding-test.
  2. Status should read Working via dkim yourdomain.com or Working via arc yourdomain.com within a minute.
  3. failed: auth_failed with a body hash mismatch: a stationery or content policy modified the copy. Re-check the policy order and the override flag.
  4. failed: domain_not_owned naming a mimecast.com domain: the copy was signed by Mimecast’s own domain. Enable DKIM signing for your domain in DNS Authentication - Outbound.
  5. Nothing arrives: check Message Center, Held for the test message. A hold policy on the inbound or outbound leg is the usual cause.

Then forward any message from a personal mailbox to verify@yourdomain.com and confirm a Not verified reply arrives.