Domains and mail

Fromenance is a communication provenance platform that answers customer forwards in your name, so it only accepts forwards that provably came through your mail platform. This page explains the trust model behind the verify@ inbox and how to read a rejection.

By the end you will have published the TXT record, understood what the redirect rule must do, and know what each rejection reason means.

Two records, one rule

Your DNS footprint for the forward path is a single TXT record. The optional branded reply identity adds three more on a subdomain. Fromenance never asks you to CNAME anything to fromenance.com.

The trust TXT record

When you add a domain (POST /v1/domains or Domains in the admin app) the response includes txt_record:

_fromenance.northfieldbank.example.  TXT  "v=fromenance1; t=northfield; k=<32 hex character token>"

• v=fromenance1 is the record version.
• t= is your tenant slug, which is also the local part of your tenant inbox northfield@verify.fromenance.com.
• k= is a token minted for this domain. It is not a secret; it proves that whoever controls the DNS zone intended to bind the domain to this tenant.

Fromenance polls the record every minute for 24 hours after you add the domain, then daily. POST /v1/domains/{id}/check runs the check immediately. A domain moves from pending to verified when the record resolves and the token matches; a verified domain whose record disappears moves to suspended and inbound for it is paused until the record is back.

Domain roles

Each domain carries roles. New domains get trust and sender; reply is added when you create a branded reply identity.

Role	Meaning
trust	Forwards that authenticate for this domain are accepted into your tenant inbox
sender	Registered communications may carry a From address on this domain; journal copies from other domains are rejected
reply	Verdict replies are sent from verify@verify.<domain> (or the subdomain you chose)

A tenant can own several domains (northfieldbank.example, northfieldalerts.example). Each needs its own TXT record. Any of them can host the verify@ rule and any with sender can be a registered From.

The redirect rule

Customers write to verify@yourdomain.com. Your mail platform must redirect that mail to your tenant inbox, <slug>@verify.fromenance.com. The address is verify_address on GET /v1/tenant and is shown in the setup wizard.

Redirect and forward are different operations on every platform, and only redirect works:

	Redirect	Forward
Envelope and visible sender	The customer stays the sender, so Fromenance can reply to them	Rewritten to verify@, so the reply would come back to you
Original headers	Preserved, including the customer’s forwarded message structure	Often rewrapped, and the innermost message can be flattened
Authentication seen by Fromenance	Your platform’s DKIM signature or ARC seal for your domain	Usually the same, but the reply path is already broken

Because the customer’s own domain is what the message was originally signed by, your platform must add its own authentication on the way out. Google Workspace signs redirected mail with DKIM for your domain; Microsoft 365 adds an ARC seal by your tenant’s domain and, depending on configuration, a DKIM signature. Proofpoint, Mimecast, and Cisco sit in front of one of those two and hand the redirect to it. Each platform guide covers what to check.

Click by click guides: Google Workspace, Microsoft 365, Proofpoint, Mimecast, Cisco Secure Email.

The trust check

Every message arriving at <slug>@verify.fromenance.com goes through the same check before anything is parsed for content.

1. The slug resolves to an active tenant.
2. The message carries a DKIM signature that verifies for a domain the tenant owns, or an ARC chain whose last seal is by such a domain. Fromenance runs DKIM (RFC 6376) and ARC (RFC 8617) verification itself on the raw MIME it receives; it does not trust upstream Authentication-Results headers.
3. That domain is verified (its TXT token matched on the last check) and carries the trust role.

Subdomains count: a signature for mail.northfieldbank.example vouches for a tenant that owns northfieldbank.example.

Only the forward path needs this check. The verify page is authenticated by its site key and origin.

Rejection reasons

A message that fails the trust check is stored for 24 hours as rejected inbound, never processed, and never answered. The reason is visible to Fromenance support during onboarding, and the forwarding test in the setup wizard reports it as failed: <reason>.

Reason	Meaning	Fix
unknown_inbox	The local part before @verify.fromenance.com is not a tenant slug	Check the redirect target address against verify_address
tenant_inactive	The tenant is suspended	Contact support
no_domains	The tenant has no domains at all	Add a domain and publish the TXT record
auth_failed	No DKIM signature verified and no ARC seal passed. The detail lists each signature and why it failed	The rule forwarded instead of redirecting, or your platform does not sign outbound mail for the domain. Fix the rule; confirm DKIM signing is on
domain_not_owned	A signature passed, but for a domain not in your tenant	Add that domain (for example a separate sending subdomain your platform signs with)
domain_not_verified	The signing domain is in your tenant but its TXT record has not resolved yet	Wait for the poll or run a check
domain_suspended	The TXT record was removed after verification	Republish the record
domain_no_trust_role	The domain exists and is verified but lacks the trust role	Add the role with PATCH /v1/domains/{id}

Troubleshooting: my forwards are rejected

1. Run the forwarding test from the setup wizard or POST /v1/domains/{id}/forwarding-test and read result.
2. auth_failed with a detail like dkim northfieldbank.example/google: fail (body hash mismatch) means something modified the message after signing: a disclaimer stamped by a gateway after the redirect, or a rule that rewrites the body. Move the redirect after the gateway or exclude verify@ from stamping.
3. auth_failed with no signatures means the redirect path does not sign at all. On Microsoft 365 confirm ARC sealing is on for the tenant; on Google Workspace confirm DKIM authentication is set up for the domain.
4. domain_not_owned with a domain like northfieldbank-example.mail.onmicrosoft.com means the platform signed with its tenant domain rather than yours. Configure DKIM for your custom domain.
5. Send a plain message from a personal mailbox to verify@yourdomain.com and check that a reply arrives within a minute. Until you have registered anything, the reply is Not verified, which confirms the path end to end.