Add inbox-works.com mail template

[masanori-iwata]

Description

Adds the mail template for Inbox Works (https://inbox-works.com), a shared-inbox product for small teams in Japan.

• providerId: inbox-works.com / serviceId: mail
• Purpose: email sending authentication for our customers' own domains — SPF (via SPFM merge) + return-path MX + DKIM TXT. Records point to the sending infrastructure (Amazon SES / Resend) that delivers our customers' mail.
• syncPubKeyDomain: inbox-works.com (signing public key published at _dcpubkeyv1.inbox-works.com, RS256 — verified with dc-debug-pubkey)
• syncRedirectDomain: app.inbox-works.com
• DMARC is intentionally NOT included: an existing _dmarc policy must never be overwritten by a template apply.
• No click-tracking records: the product does not use link tracking.
• dc-template-linter --merge-or-fail passes (exit 0), logo reachability check included.

Type of change

• New template
• Bug fix (non-breaking change which fixes an issue in the template)
• New feature (non-breaking change which adds functionality to the template)
• Breaking change (fix or feature that would cause existing template behavior to be not backward compatible)

How Has This Been Tested?

Please mark the following checks done

• Template functionality checked using Online Editor
• Template file name follows the pattern <providerId>.<serviceId>.json
• resource URL provided with logoUrl is actually served by a webserver (https://app.inbox-works.com/brand/inbox-works-logo.svg → HTTP 200, image/svg+xml)

Checklist of common problems

• syncPubKeyDomain is set — this is mandatory; omitting it requires explicit justification in the PR description or the PR will be rejected
• warnPhishing is not set alongside syncPubKeyDomain — the two must not appear together
• syncRedirectDomain is set whenever the template uses redirect_uri in the synchronous flow
• no TXT record contains SPF content ("v=spf1 ...") — use the SPFM record type instead
• txtConflictMatchingMode is set on every TXT record that must be unique per label or content prefix (e.g. DMARC)
• no variable is used as a bare full record value (e.g. @ TXT "%foo%") unless necessary — prefer @ TXT "service-foo=%foo%"; if bare, justify in the PR description
• no bare variable is used as the full host label — the non-variable parts are fixed to limit misuse (e.g. %dkimkey%._domainkey, not %dkimhost%); if bare, justify in the PR description
• no variable is used in the host field to create a subdomain — use the host parameter or multiInstance instead
• %host% does not appear explicitly in any host attribute
• essential is set to OnApply on records the end user may need to modify or remove without breaking the template (e.g. DMARC)

Notes:

• The MX + SPFM records use the fixed label send (the Amazon SES custom MAIL FROM / return-path subdomain of the sending domain), not a variable — rules 7 and 8 hold. Our service verifies that the live sending records really use that label before it offers the one-click apply at all; if they ever differ, we fall back to manual setup rather than write a record the template cannot express.
• Only two variables remain, both embedded in fixed text: %region% inside feedback-smtp.%region%.amazonses.com, and %domainKey% inside p=%domainKey% on the DKIM TXT.
• No record needs essential: OnApply: the template writes no policy record the end user is expected to edit (that is why DMARC is deliberately left out).

Online Editor test results

Editor test link(s):

• apex, both groups (example.com, no host): Test inbox-works.com/mail example.com/@
• subdomain, both groups (example.com, host=mail): Test inbox-works.com/mail example.com/mail

[github-actions]

✅ JSON Filename Check Passed

[github-actions]

✅ JSON Schema Validation Passed

[github-actions]

Linter OK

inbox-works.com.mail.json

Level	Code	Note

[github-actions]

PR Description Check Passed

All required sections are filled in correctly.

Details

  OK  Type of change: 1/4 checkboxes ticked
  OK  How Has This Been Tested?: all 3 checkboxes ticked
  OK  Checklist of common problems: 10/10 checkboxes ticked
  OK  Online Editor test results: 2 link(s) found
  OK  Template coverage: all 1 template(s) covered
Labels to remove: Checklist of common problems not complete, Forged editor links, PR description incomplete, Test links missing

PR description check PASSED

[github-actions]

Linter passed all checks — approving for auto-merge.

[masanori-iwata]

Status update — this PR is ready from my side, and the automation is green on 4d8ad93:

• all checks pass
• automerge-check now passes dc-template-linter --merge-or-fail. It had been failing on DCTL1040 (bare variables in host or pointsTo record field) for host: "%spfDomain%" — invisible in the PR UI because the plain lint job reports OK and the merge-or-fail output is redirected to /dev/null. The return-path MX/SPFM records now use the fixed send label instead of a variable, so guidelines 7 and 8 hold and the checklist above is fully satisfied.
• the automerge-possible label was added and the bot approved the PR

The last step of Automerge Approve did not complete, though — enqueuePullRequest failed with:

Pull request You're not authorized to push to this branch.

(run: https://github.com/Domain-Connect/Templates/actions/runs/29728948211)

So the PR was never added to the merge queue. That looks like a workflow-token / branch-protection setting rather than anything I can fix from the PR side. Could a maintainer merge it manually, or adjust the permissions?

For context: Cloudflare have verified our public key and logo, and told us they will only start onboarding once this PR is merged.

Thanks for the review!