Email deliverability and allow-listing

Sending identity

The detail that usually causes confusion

SPF is evaluated against the return-path, which for our mail is send.sigfetch.com, not against the visible From domain. If you check SPF on sigfetch.com you will find a record covering our own staff mail and conclude that our signature requests are unauthenticated. They are not.

What carries DMARC alignment here is DKIM. We sign with d=sigfetch.com, which matches the From domain, so an aligned DKIM pass is the signal to check. DMARC is published for the domain.

Where to add the allow entry

Menu names drift between versions, so treat these as the route rather than the exact wording.

• Microsoft 365 / Exchange Online

  Defender portal → Policies & rules → Threat policies → Tenant Allow/Block Lists → Domains & addresses → Allow

  Allowing the domain in the Tenant Allow/Block List is preferred over a mail-flow rule, which can bypass checks you want to keep.

• Google Workspace

  Admin console → Apps → Google Workspace → Gmail → Spam, phishing and malware → Allowlist / Inbound gateway

• Sophos Central

  Email → Policies → your Email Security policy → Allow/Block lists → add the domains as allowed senders

  If a message was already held, it will be in Email → Quarantine, usually flagged as impersonation. Releasing it does not stop the next one; the allow entry does.

• Mimecast

  Administration → Gateway → Policies → Permitted Senders → add a policy for the domains

• Proofpoint

  Email Protection → Spam Detection → Safe Senders list, or the equivalent org-level rule

• Anything else

  Look for permitted senders, safe senders, or an allow list in your inbound anti-spam policy, and add both domains there.

What our messages look like

So you can identify them without waiting for a sample. Subject lines take these forms:

• Signature requested: <document name>
• Reminder — signature requested: <document name>
• Signed & completed: <document name>
• Signed copy: <document name>
• Declined: <document name>
• Voided: <document name>
• Expired: <document name>

• Every link in a signature request resolves to https://sigfetch.com/sign/ followed by a random token. We do not use link redirectors or tracking domains, so anything pointing elsewhere is not from us.
• A signature request carries no attachment. Only the completion email attaches a PDF, and only once every party has signed.
• Signers do not need an account, a password, or a payment method. Nothing we send will ask for any of them.

Why a legitimate message might be held

Worth stating plainly, because it is the most common reason our mail is quarantined rather than delivered. When one of your own people sends a document to a colleague, the message arrives from an external domain that your filter may not have seen before. We used to put the sender's own name in the From line, which meant an unfamiliar external domain appeared to be carrying the name of one of your staff. Impersonation protection is built to catch exactly that shape, and it was right to be suspicious.

We have since stopped doing that for internal sends: when sender and recipient share a domain, the message now goes out plainly as SigFetch, and the sender is named in the body instead. Adding the allow entry above covers the remaining cases, which are mostly about our domain simply being new to you.

Sending this to your IT team

If you are the one waiting on a signature rather than the person who administers the mail filter, copy the following into a ticket.