A carefully written quote, a friendly reply to an enquiry, the appointment confirmation for the next day - and then nothing comes back. No decline, no follow-up question, just silence. In many cases the reason is not the recipient but an invisible intermediate step: the message landed in the spam folder or was rejected outright by the receiving server. For a business that handles orders over email, that is both costly and frustrating, precisely because it is so hard to notice. This article explains in plain language why business emails end up in spam and how to secure delivery for the long run. It deals with deliverability alone: the authenticity of the sender, the reputation of your own domain, and the signals a filter uses to tell a legitimate message apart from a suspicious one. How a domain and mailbox are set up in the first place is a topic of its own - here the only thing that counts is that your mail arrives.
Why the spam folder exists at all
Spam filters are not a nuisance; they are a necessity. The share of unwanted and harmful messages in total email traffic has been high for years, and the threat picture keeps sharpening. 97 percent (Bitkom) of companies were hit or presumably hit by cyberattacks in 2025; phishing - forged messages that trick people into handing over passwords or making payments - is among the most common routes of attack. Artificial intelligence makes the problem worse: 66 percent (Bitkom) of companies have the impression that attackers are increasingly using AI, and phishing emails in particular now read more cleanly and credibly than before (Bitkom). For receiving servers this means one thing: they have to be stricter about who is sending them something. And that strictness also catches honest senders who fail to identify themselves properly.
When you send an email, it does not travel straight into the recipient's mailbox but first to their mail server. That server decides in a fraction of a second what happens to the message: straight to the inbox, off to the spam folder, or rejected on the spot. The decision rests on a whole range of signals, yet three questions sit at the centre: does the message really come from the sender it claims? Has the sending domain sent cleanly in the past? And does the content point to a wanted message? Answer all three convincingly and you land in the inbox. Leave doubt about any one of them and you risk the spam folder. The important point: the sender influences all three questions - deliverability is not luck but the result of a clean setup.
Where this article draws the line
The three checks behind every delivery
Let us stay with the three questions, because they are the thread running through everything that follows. The first question is about authenticity: an attacker can put any sender they like into an email, just as you can write any address on an envelope. So that the receiving server can tell whether your mailbox is really behind the message, there are three technical proofs that you store once for your domain. The second question is about reputation: servers remember whether wanted or unwanted mail came from a domain in the past. The third question is about content and recipient behaviour: do people open your messages, or do they move them unread into spam? All three can be actively shaped. Let us begin with the most important and, at the same time, most often neglected one - the authenticity of the sender. Anyone who understands these three checks also sees why the XICflow service overview treats domain email as part of the build from the very start.
Is the sender genuine?
The receiving server checks whether the message really comes from your domain or whether someone is misusing your name. Three entries handle this: SPF, DKIM and DMARC.
Does the domain have a reputation?
Servers keep a record of whether wanted mail came from a domain in the past. Complaints, dead addresses and spam reports damage that reputation.
Is the message wanted?
If recipients open and reply to your mail, that speaks for you. If they delete it unread or mark it as spam, the delivery rate drops for all future messages.
SPF, DKIM and DMARC in plain terms
The three abbreviations SPF, DKIM and DMARC sound like the IT department, yet the principle behind them is everyday. All three are small entries stored with your domain that help the receiving server tell genuine mail from forged mail. You set them up once, after which they work invisibly in the background. If they are missing, some servers treat your messages as suspicious just to be safe - even when all you are sending is an invoice. Here are the three proofs without the jargon.
SPF is the guest list. With your domain you record which servers are allowed to send email in your name - for instance your provider's mail server. If a message arrives from a server that is not on that list, the recipient knows something is off. SPF therefore answers the question of whether a given server is allowed to send for this domain. The most common mistake is an incomplete list: if you later use a second sending service, say for invoices or appointment reminders, you have to add it too, or those very important mails will end up in spam.
DKIM is the seal. Every outgoing message receives an invisible digital signature that can only be created with your domain's matching key. The receiving server checks this seal and learns two things: that the message really comes from your domain and that it was not altered in transit. As with a wax seal on a letter, an intact DKIM shows that no one has tampered with the content. A broken or missing seal is a clear warning sign.
DMARC is the house rule. It sets out what a receiving server should do when SPF or DKIM do not match: deliver the message anyway, move it to spam, or reject it entirely. Without DMARC every server decides at its own discretion; with DMARC you give a clear instruction and at the same time protect your name from fraudsters who would misuse it for phishing. You can also have reports sent to you showing who is sending in your name - a simple way to spot misuse early. DMARC builds on SPF and DKIM and only works when both are set up cleanly.
Scroll table sideways
| Proof | Everyday image | What it answers | Without it |
|---|---|---|---|
| SPF | Guest list of allowed servers | Is this server allowed to send for the domain? | Foreign servers can misuse your name |
| DKIM | Seal on the envelope | Is the message genuine and unaltered? | Tampering goes unnoticed |
| DMARC | House rule for doubtful cases | What to do when a check fails? | Every server decides on its own, uncontrolled |
An image for everyday life
The sender address @your-own-domain
The most visible trust factor is the address itself. A message from a borrowed free webmail address feels less binding to recipients and filters alike than one from contact@your-business.com. The reason is not only appearance: with your own domain you can store SPF, DKIM and DMARC in the first place and thereby prove your authenticity. With a borrowed free webmail address you share the reputation with countless other users and have no influence over the sender proofs. For a business that takes enquiries seriously, an address @your-own-domain is therefore not a nice-to-have but a basic requirement - not least so that replies to your messages reliably reach you. What a professional first contact through the website looks like is shown in the article on making the most of contact enquiries.
- Use one fixed main address, such as contact@ or info@your-domain.com, and do not keep changing it - receiving servers judge familiar senders more favourably.
- Keep the reply address the same as the sender address, so that responses do not run into a void and do not trigger filters.
- For automatic messages such as appointment confirmations use a descriptive address (for example bookings@your-domain.com), but still accept replies - pure no-reply addresses feel impersonal and are checked more strictly.
- Keep personal free webmail accounts out of business correspondence; they cannot be tied to your sender proofs.
- Set the display name cleanly, using the company name rather than cryptic abbreviations, so recipients see at a glance who is writing.
An address people recognise
What else pulls messages into spam
Even with clean proofs, an email can land in spam if its content or context looks suspicious. Filters assess not only the technology but also patterns typical of unwanted mail. These include sensational subject lines in capital letters, a body that consists almost entirely of a single image, many or shortened links, attached files in unusual formats, and a heavy imbalance between image and text. Recipient behaviour plays in as well: if many of your messages go to dead addresses or are deleted unread, the server reads that as a sign that your mail is less wanted. For everyday practice this means: write the way one person writes to another - clear, personal, without marketing gibberish.
- Phrase subject lines factually instead of shouting in capital letters or with chains of exclamation marks.
- Compose the message as readable text, not as a single large image - a filter cannot interpret pure image mail.
- Use links sparingly and only to your own, known domain; avoid short URLs and third-party redirects.
- Keep attachments small and use common formats such as PDF; executable files are blocked almost everywhere.
- Maintain recipient addresses and remove undeliverable ones, so your delivery rate is not dragged down by dead mailboxes.
- Add a visible, working signature with genuine contact details - this improves recognition as a legitimate sender.
Newsletters and bulk mail are a league of their own
As soon as you stop writing individual messages and instead address many recipients at once - a newsletter or a promotional mailing, say - stricter rules apply. Receiving servers recognise bulk sending and then check especially carefully whether the recipients have agreed to it at all. The most important lever is a cleanly collected recipient list: only addresses of people who have actively consented, ideally through a confirmed sign-up procedure. How that works in a way that is both legally sound and delivery-friendly is described in the article on newsletter sign-up with double opt-in. A second important point is the visible unsubscribe link: people who can unsubscribe easily click the spam button less often - and it is precisely those spam clicks that harm your delivery rate the most.
Bought addresses are a delivery risk
When it goes wrong: finding the cause
When messages evidently fail to arrive, a structured look pays off more than frantic one-off attempts. The first step is the question of whether it affects all recipients or only certain providers - if your mail lands in spam only at one large free webmail service, that points to a reputation or proof problem. The second step is a look at the three proofs: are SPF, DKIM and DMARC fully stored and valid for your domain? Many delivery problems resolve themselves with that alone. The third step is a test send to several of your own mailboxes at different providers to see where the message lands. Document what you check and change - that way you can tell which measure actually worked, instead of turning several dials at once.
- Check whether the problem affects all recipients or only one particular provider - that narrows the cause considerably.
- Verify that SPF, DKIM and DMARC for the domain are complete and valid; correct missing or duplicate entries.
- Send test messages to several of your own mailboxes at different providers and note where they land.
- Soberly review the subject and content of a message that was not delivered and defuse sensational language, pure image content or many third-party links.
- Clean up the recipient list and remove undeliverable addresses before the next larger send starts.
- Test again after every change and record the result, so that effect and cause stay cleanly separated.
Deliverability is not a property of the individual mail but of the reputation a sender builds over months. Identify yourself cleanly and write what people want, and you get delivered.
Delivery is setup, not chance
The good news: almost everything that decides between inbox and spam can be set up cleanly once and then runs in the background. That is exactly why domain email is part of the foundation at XICflow and not a side project. Anyone who builds their website with XICflow gets their own domain and a professional mailbox as part of the whole - with the matching sender proofs, so that enquiries from customers reach you and your replies arrive. The address @your-own-domain then does not sit isolated next to the website but belongs to the same consistent presence. What the build costs and which services are included is shown in the pricing overview; how the path from idea to finished site unfolds is described in the overview of how XICflow works.
Deliverability is bound up with other foundational questions. A credible first contact often begins not in the email but in the briefing inputs for the AI website builder, where you set addresses, contacts and contact routes. Anyone who schedules appointments online automatically sends confirmations - why those have to arrive reliably becomes clear in the article on online appointment booking for businesses. And whether a message is opened at all is sometimes decided at the preview stage, as the article on the preview image and favicon when sharing shows for shared links. Further articles on structure, law and technology are collected in the XICflow blog.
How to secure your delivery
- Set up one fixed sender address @your-own-domain and use it for all business correspondence.
- Store SPF, DKIM and DMARC for the domain in full and have their validity checked.
- Register all sending routes: invoice and appointment mails have to go through allowed servers too.
- Write messages in a human, factual way - a clear subject, readable text, sparing links, a working signature.
- Keep the recipient list clean: only consented addresses, and remove undeliverable ones regularly.
- For newsletters use a confirmed sign-up procedure and a visible unsubscribe link.
- When problems arise, test in a structured way: narrow down affected providers, check the proofs, evaluate a test send, document changes.