For Tripletex’s documented native invoice-email route, configure the customer reply address in Tripletex, not an SPF include or DKIM key in your own DNS. Tripletex identifies the sender as noreply@via.tripletex.no, even when replies go to your chosen mailbox. This is a vendor-domain sending route, not evidence that your business domain has been authenticated as the visible sender. Official reply-address instructions.
This guide covers that native route only, not third-party integrations, independently configured mail servers or an undocumented custom-domain feature. No account configuration or live-message test was performed for this guide.
What you can configure
- Reply destination: Your monitored mailbox for customers’ replies
- Visible sender: The documented Tripletex-owned address, not the reply mailbox
- SPF identity: The SMTP envelope sender used by the actual message; inspect trusted receiver results rather than guessing it from the visible address
- DKIM identity: The
d=signing domain in an actual signature; this guide does not invent a selector or key - DMARC identity: The domain in the visible From address, not the Reply-To address
SPF, DKIM and DMARC perform different checks. A mailbox used only for replies does not become the original message’s SPF or DMARC identity. Conversely, changing your business domain’s SPF cannot repair authentication of a different vendor-owned envelope domain. These are protocol consequences, not a claim that we tested Tripletex’s present signatures. See SPF identities and DMARC alignment.
Set the reply address in Tripletex
Before changing anything, agree who owns the receiving mailbox, confirm it accepts mail and record the previous selection. Use an account authorized to change invoice settings; the cited page does not specify a universal role or subscription entitlement.
- Open Faktura > Innstillinger (Invoice > Settings).
- Find Fakturautsending, the invoice-dispatch section.
- Under the invoice/reminder reply controls, select the option that directs all replies to a specified address and enter the agreed mailbox.
- Review the separate reply controls for offers and order confirmations if those messages should use the same destination. Recheck the persisted settings before sending.
These are separate message-type choices, not one DNS switch. Tripletex’s screenshot also contains delivery preferences and blind-copy options: do not change those merely to set a reply address. The source’s scope includes invoices, offers, order confirmations and payment reminders. Provider workflow and screenshot.
Do not add speculative SPF or DKIM records
There is no customer DNS record to copy from these reply-address instructions. Do not substitute a guessed Tripletex include, copy a public DKIM key from another tenant, or authorize a shared hosting network because it appears in a message header.
Keep existing SPF and DMARC policies for your own legitimate senders unchanged. In particular, do not create a second SPF policy or weaken DMARC to make invoice mail appear to work. Your mailbox provider may need its own authentication setup for messages you send from that mailbox, but that is a separate sending path, not the original Tripletex invoice.
If a specific integration or newly offered account feature sends with your own visible From domain, stop and obtain current official documentation for that exact route: record issuance, sending activation, envelope identity and DKIM signing identity. A different route needs its own evidence; these instructions do not establish whether such a feature is available elsewhere.
Verify the result without creating a financial transaction
Use an already authorized, appropriate message workflow with a controlled recipient and non-sensitive content where available. Do not create a fake invoice, payment reminder, charge or customer communication solely to test email. If there is no safe test facility, coordinate inspection of the next legitimate authorized message instead.
At the receiving mailbox:
- Open the original message’s complete headers, not a forwarded copy.
- Compare the actual From address with the documented vendor-domain route. An unexpected customer-domain From means the scope must be reassessed, not assumed successful.
- Confirm the Reply-To destination and use Reply to inspect the intended recipient before sending a controlled response. Confirm that response reaches the agreed mailbox.
- Inspect authentication results generated by the receiving system you trust. Header position or a matching server-name string alone does not establish trust; sender-injected results are not evidence. Authentication-Results trust boundary.
- Record SPF outcome and its evaluated envelope domain, DKIM outcome and signing domain, and DMARC outcome for the actual visible From domain. Do not assume an observed vendor-domain DMARC pass authenticates your business domain.
A DKIM pass must align with the visible From domain to contribute to DMARC; a signature from some other domain is not sufficient by itself. Raw DKIM results versus aligned policy results explains this distinction. This contextual article was checked against its retained body, not newly tested on the live site.
For a claimed DKIM-authenticated route, require the intended signature to pass and align as well as a trusted dmarc=pass; a DMARC pass through SPF alone does not prove that DKIM works. Investigate SPF failure, temporary DNS error and permanent policy error separately even if another aligned mechanism passes. Authentication success is not an inbox-placement guarantee.
Troubleshooting and safe recovery
- Customer replies go to the wrong team: Inspect Reply-To on the original message and the settings for that specific message type; restore the recorded prior choice if the change was mistaken
- Invoice never arrives: Confirm recipient spelling, then ask the authorized recipient to check spam/quarantine; avoid repeated resends that duplicate financial communications
- Message still shows Tripletex as sender: That is consistent with this documented route; changing Reply-To is not custom-domain From authentication
- SPF/DKIM/DMARC failure appears: Preserve a redacted original-header sample and ask Tripletex support to investigate its sending route; do not change DNS you do not control
- Your own-domain From appears: Identify the integration or account feature responsible and obtain its current primary setup instructions before making DNS changes
Tripletex specifically identifies incorrect recipient addresses and spam filtering as possible delivery causes. Its support note does not establish that authentication passed or failed in your case. Official delivery troubleshooting.
For escalation, provide message type, timestamp and timezone, expected reply mailbox, observed sender and relevant receiver-authentication results. Redact invoice contents, personal details and unnecessary identifiers, and share only through an approved support channel. Never send mailbox passwords or private keys. Preserve existing DNS, MX routing and security settings while the route is investigated.