Practice 03 · Web, software & digital solutionsEmail deliverability and transactional sending: your emails must arrive. Not in spam, not never.
A quote, a booking confirmation, a licence key, a reply to a form: behind every email sent by your website or your software, there is a customer waiting. Gmail, Outlook and Yahoo now only accept properly authenticated senders. We set up a reliable, secure sending infrastructure so that your messages reach the inbox, under your name, and nobody else can send on your behalf.
A deliverability test of your domain, written feedback, free
Who it is for, and whenWhen to call Kopus about the deliverability of your emails
The problem rarely shows up as an alert: you guess it from a customer who calls back, an order with no confirmation, a form that seems to have stopped working.
- Your contact forms land in spam, or stop arriving altogether: enquiries are lost without anyone knowing.
- You run several websites or applications and no longer know what sends what, from which server, with which address.
- Your software or your SaaS sends important emails: licence keys, invoices, password resets, order confirmations.
- You are changing hosting or email provider and want a switch with no downtime, and no fall back into spam the next day.
The scopeWhat an email deliverability engagement with Kopus includes
- Deliverability audit Why your emails land in spam, or do not arrive. We check what actually leaves your servers, the headers received, and the reputation of your domains and IP addresses.
- Authentication of your domains SPF, DKIM and DMARC, the three standards required by the major mailbox providers, configured and verified on every sending domain.
- Securing your domain names A DMARC policy taken progressively to reject, continuous monitoring of the reports, and lock-down of the domains that never send email.
- Dedicated sending domain and address A subdomain reserved for automated sending, to protect the reputation of your main domain and your personal mailboxes.
- Centralised sending relay A single sending point for several websites or applications, with its own access for each one, revocable at any time.
- Connection of your forms, websites and software We plug what exists into the new infrastructure, without redoing what works.
- Abuse protection Sending limits, locked sender, access restricted to your servers, tokens stored outside the web root.
- Tracking and reports Every send traced (accepted, deferred, rejected), and attempts to spoof your domain flagged.
What you get
- Emails that reach the inbox, under your name.
- Authenticated domains that nobody can spoof.
- One sending point for all your websites and software, traced and revocable.
The path of an emailBetween your software and the inbox, three checks decide the fate of the message
Each application sends through the relay with its own access, the message leaves the dedicated sending domain with the three authentications, and the recipient’s mailbox provider verifies before filing. A message claiming to come from you without going that way fails the same checks: the DMARC policy rejects it and flags it in the report. It is the same infrastructure as the one described in our API integration: one access point per application, a log, revocable access.
- Website and formsContact requests, quotesOwn access, revocable
- Software or SaaSLicence keys, invoices, passwordsOwn access, revocable
- Online shopOrder confirmationsOwn access, revocable
Sending relay
One sending point for all your applications
- Locked sender
- Sending limits per application
- Access restricted to your servers
- Every send logged
Dedicated sending domain
mail.your-domain.com
- SPFAuthorised servers
- DKIMSignature verified
- DMARCPolicy: reject
Spoofing attempt
Unknown server, same display name
Your companyaccounts@your-domain.com
RejectedFlagged in the DMARC report
Inbox
Recipient’s mailbox provider
Your AlloDesk licence key
Your companynotifications@mail.your-domain.com
Authenticated
Sending log
- 09:41:07Licence key · order 4821Accepted
- 09:41:12Booking confirmationAccepted
- 09:42:30Invoice 2027-0318 · retry in 2 minDeferred
- 09:43:55Unknown source · 212.xx.xx.xxRejected
- Authenticated send
- Spoofing blocked
The methodHow a reliable sending infrastructure is put in place
Real inventory
We list everything that sends email in your name (websites, forms, software, third-party tools) and check what actually leaves your servers, not only what is configured.
Authentication plan
For each domain, the SPF record, the DKIM keys and the DMARC policy are defined, with a dedicated sending subdomain when the main domain’s reputation must be protected.
Relay set-up
The centralised sending point is installed, with per-application access, sending limits and a searchable log.
Site-by-site migration
Each website or application is connected in turn, with a real test at every step and a rollback always possible. Your forms stay the same: only the way they send changes.
Monitoring and hardening
DMARC reports are read, the policy moves to reject once everything is clean, and new senders are added properly instead of being hacked in.
Our positionWhy we treat email sending as infrastructure, not as a setting
We start by checking what actually leaves your servers, not only what is configured. Then we migrate your websites one by one, with a real test at every step and a rollback always possible. We apply this method to our own products: AlloDesk, our telephony software, sends its licence keys by email at the moment of purchase. A message that does not arrive is a customer who cannot use what they have just paid for. The infrastructure we deploy for our clients is the one that carries those emails.
Your questionsFrequently asked questions about this service
Why do my emails land in spam when they are sent from my website?
Most often because the website’s server sends “on behalf of” your domain without being authorised to. With no SPF record listing it, no DKIM signature and no DMARC policy, Gmail, Outlook or Yahoo cannot verify that the message really comes from you, and file it as spam or refuse it. A shared-hosting IP address with a damaged reputation makes it worse. The audit identifies the exact cause before anything is changed.
What are SPF, DKIM and DMARC?
SPF is a DNS record that lists the servers allowed to send for your domain. DKIM adds a cryptographic signature to every message, verified by the recipient with a key published in your DNS. DMARC ties the two to the address the reader sees, says what to do on failure (monitor, quarantine, reject) and sends you reports. Together, the three prove that the sender is really you.
Do the major mailbox providers really enforce these standards?
Yes. Since February 2024, Google and Yahoo require SPF, DKIM and DMARC from bulk senders, with a complaint rate under 0.3% as measured in Google Postmaster Tools, and Microsoft has applied comparable requirements for Outlook since May 2025. Below the volume thresholds, authentication remains the main criterion for inbox placement. These rules get stricter every year, never the other way round.
Do we need a dedicated sending domain?
We recommend one as soon as software sends automated emails: a reserved subdomain (for example mail.your-domain.com) carries its own reputation. If a form is hijacked or an unusual volume goes out one day, your main domain and your staff’s mailboxes are not affected. The reader still sees your company name as the sender.
Will our forms and software have to be rebuilt?
No. The sending relay exposes a simple interface that we connect to what exists: a PHP form, a WordPress site, a custom application or a SaaS. Each application gets its own access, revocable without touching the others. The content of the messages and the address your customers see do not change; only the way they are delivered does.
How do we know if someone is sending emails pretending to be us?
The aggregate DMARC reports, sent daily by the mailbox providers, list every source that used your domain, authorised or not. We centralise them in a readable dashboard: volume per source, SPF and DKIM result, country of origin. A spoofing attempt shows up within hours, and the reject policy stops it from arriving.
How long does the set-up take?
An audit with written recommendations takes a few days. Authenticating a domain and connecting a first website takes one to two weeks, the time to propagate the DNS records and check the first real sends. Moving DMARC to reject then waits for a few weeks of clean reports, so that a legitimate send is never blocked.
Go furtherPages related to this service
Our workProjects built on this expertise
All our work
Let’s bring your projects to lifeYour next project starts here.
Let’s get your emails where your customers expect them: in the inbox.
A deliverability test of your domain, written feedback, free