1. Why business emails end up in spam
When an important quote does not reach a B2B customer or a hotel’s booking confirmation disappears into the spam folder, the content of the message is rarely to blame. The cause is almost always technical. Mailbox providers are under constant pressure to protect their users from phishing, fraud and unwanted advertising.
Historically, email is an unsecured medium. In theory, the original protocol allows any server to send emails with any sender name. Criminals exploit this by faking other people’s domains as the sender (spoofing). To counter this, modern mail servers check every incoming message to see whether the sending server is actually authorised to speak for the domain stated. If this proof is missing, the security filters kick in.
Since the stricter guidelines that large providers introduced at the beginning of 2024, a good reputation of the sender address is no longer enough. Without standardised authentication, delivery is refused or downgraded. For small and medium-sized enterprises this means: technical deliverability is a direct prerequisite for working sales and marketing processes.
2. The three pillars of email authentication
To prove that an email really comes from your company and has not been tampered with on the way, three DNS records work together: SPF, DKIM and DMARC. They complement one another and should always be used together.
SPF: who may send for your domain?
The Sender Policy Framework (SPF) is a list of authorised servers. With an SPF record, you tell the world which IP addresses and services may send emails on behalf of your domain.
If, in addition to the standard mail server of Microsoft 365 or Google Workspace, you use other systems – such as a CRM system for sales, a newsletter tool or booking software in a hotel – all of these service providers must be listed in the SPF record. If a destination server receives an email from a server that is not on this list, it rates the message as potentially forged.
A typical SPF record in your domain’s DNS is a single line of text built on the following principle:
v=spf1 include:_spf.google.com include:sendgrid.net -all
In this example, Google Workspace and the SendGrid service may send for the domain. The abbreviation -all (hard fail) signals to the receiving server that all other senders are unauthorised and should be rejected. An important technical aspect: an SPF record may trigger a maximum of ten DNS queries (DNS lookups). If there are too many services, validation fails.
DKIM: the digital signature of your messages
While SPF defines which servers may send, DomainKeys Identified Mail (DKIM) guarantees that the message has not been altered in transit. It prevents attackers from intercepting an email, changing its content (such as bank details in a PDF invoice) and forwarding it to its destination.
For this, DKIM uses an asymmetric cryptographic key pair:
- The private key is stored securely on the mail server that sends the email. It adds an invisible digital signature to the message in the email header.
- The public key is stored as a TXT or CNAME record in your domain’s DNS.
When the email arrives at the recipient, their server retrieves the public key from your DNS and compares it with the message’s signature. If the two match, it is certain that the email really comes from you and that the content was not modified along the way.
DMARC: policy and control authority
SPF and DKIM initially work independently of each other. Domain-based Message Authentication, Reporting, and Conformance (DMARC) links the two protocols and gives the receiving server clear instructions on how to behave if SPF or DKIM fail.
A key element of DMARC is what is known as alignment. DMARC checks whether the visible sender address (the “From” header that the user sees in their mail program) matches the technical sender domain protected by SPF and DKIM.
In addition, DMARC defines a policy:
p=none: the messages are merely monitored. If authentication fails, the email is still delivered. You receive error reports by email.p=quarantine: emails that fail are moved straight into the recipient’s spam or junk folder.p=reject: emails that pass neither SPF nor DKIM are rejected outright by the receiving server and not delivered at all.
A typical DMARC record looks like this:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; pct=100
Via the rua field, the receiving server sends aggregated XML reports to the address specified. This lets you see whether your own legitimate systems are misconfigured or whether third parties are trying to misuse your domain for spoofing.
3. Typical sources of error in SMEs and decentralised structures
In practice, deliverability rarely fails because the theory is not understood, but because of organisational circumstances in small and medium-sized enterprises.
A common mistake is multiple SPF records. Technically, exactly one SPF record may exist per domain. If marketing, sales and accounting book software tools independently and each provider asks for its own SPF record to be set, many administrators overwrite earlier records or accidentally create two SPF lines. Both cases make the SPF check invalid at the recipients’ end.
In franchise systems or with service providers that have decentralised sales partners, there is often a requirement to communicate via a single domain. However, if partner companies use their own mail programs or local mail servers that are not authorised in the central DNS management, their messages inevitably end up in spam. Close coordination between the head office and the local sites is needed here.
In the hotel industry, property management systems (PMS) send booking confirmations automatically, often via external SMTP relays. If the DKIM signature for this server is missing, systems such as Gmail or Outlook quickly classify the message as suspicious – with a direct impact on guest satisfaction and on telephone enquiries.
4. Step by step to a clean configuration
Technical implementation requires access to the DNS management of your domain registrar (for example Strato, Ionos, Hetzner, Cloudflare) and takes little time if prepared in a structured way.
1. Take stock of all sending systems
Draw up a complete list of all services that send emails on behalf of your domain. These include:
- The primary email service (Microsoft 365, Google Workspace, your own Exchange server)
- Newsletter and marketing automation tools
- CRM and sales systems
- Invoicing and accounting software
- Ticketing and helpdesk systems
- Website forms and transactional emails from the CMS or shop
2. Consolidate the SPF record
Combine all identified services in a single SPF line. Check whether you stay within the limit of ten DNS lookups. Store the record as a TXT record at domain level.
3. Activate DKIM for all main services
Generate the DKIM key in the admin interfaces of your primary systems (such as Google Workspace or Microsoft 365) and of your email marketing tools. Enter the generated keys as TXT or CNAME records in your DNS zone. Only activate the signature in each tool once the DNS records have propagated worldwide.
4. Introduce DMARC step by step
Introduce DMARC cautiously. Start with the policy value p=none. Set up a mailbox for the XML reports and ideally use an analysis tool to make the reports readable. Only when you can see that all authorised servers pass the SPF and DKIM checks should you tighten the policy to p=quarantine and finally to p=reject.
5. Frequently asked questions
Is an SPF record on its own enough to secure deliverability?
No. SPF covers only part of the security chain and does not protect the content of the email from tampering. For a reliable classification, large email providers require SPF, DKIM and DMARC to work together. If DKIM is missing, DMARC checks fail as soon as the email is routed via mailing lists or forwarding.
How do I test whether my SPF, DKIM and DMARC records are correct?
There are web-based testing tools such as mail-tester.com or MXToolbox. You send a test message to a given address and receive a detailed analysis of whether the DNS records were found, whether the syntax is correct and whether authentication was passed on the recipient’s side.
Why do newsletters sometimes end up in spam despite SPF and DKIM?
SPF, DKIM and DMARC secure technical delivery. Alongside this, however, spam filters also assess content criteria, the domain’s history and recipient reactions. High unsubscribe rates, many spam reports from users, a sudden multiplication of sending volume or faulty HTML code lead to downgrading in the mailbox despite correct DNS records.
Can the DMARC setting block business emails?
Yes, if the policy is immediately set to p=reject without first recording and authorising all internal sending systems. In this case, quotes or invoices sent via unauthenticated third-party programs are rejected by the receiving server. You should therefore always start with the p=none policy.
How long does it take for changed DNS records to take effect?
That depends on the TTL (time to live) set by your DNS provider. In most cases, changes take effect worldwide within a few minutes to a few hours. In exceptional cases, full propagation can take up to 48 hours.
