Why do my emails go to spam? Complete guide to SPF, DKIM, DMARC and server reputation

Why your emails land in spam: SPF, DKIM, DMARC, reverse DNS, IP reputation, Mail-Tester / MXToolbox checks and a professional deliverability checklist.

You send an important email to a client, but the message goes straight to Spam? Or worse — Gmail and Outlook reject it before delivery? This is a common problem for companies that use professional addresses on their own domain.

You can have a correctly configured email server, a valid domain and an address such as contact@company.com, but that does not guarantee your messages will reach the inbox.

Providers such as Google, Microsoft and Yahoo use complex verification systems to decide whether an email is legitimate, suspicious or dangerous.

In some cases the issue is a missing DNS record. In others it is IP reputation, incorrect server configuration or sending behaviour.

The good news is that most authentication and configuration problems can be identified and fixed.

In this INITWIN guide we explain how email filtering works, what SPF, DKIM and DMARC mean, how to check server reputation and what you can do to improve company email deliverability.

1. Why do legitimate emails go to spam?

Every day, mail servers receive huge volumes of unsolicited messages, phishing attempts and emails that try to impersonate companies.

To protect users, providers analyse every message before showing it in the inbox. This analysis is not limited to email content.

Several elements are checked:

• Identity and reputation of the sending domain.
• Reputation of the server IP address.
• Authentication via SPF, DKIM and DMARC.
• Existence and correctness of DNS records.
• Message content and potentially suspicious links.
• Volume and frequency of sending.
• Spam complaints and recipient interactions.

For example, if your company sends email from a new VPS without reverse DNS and without DKIM, the recipient’s provider may treat the messages as insufficiently trustworthy.

Even if you are not sending spam, automated systems do not know your intent. They analyse technical and behavioural signals.

That is why email deliverability should be treated as an important part of IT infrastructure.

2. What do SPF, DKIM and DMARC mean?

These three technologies are email authentication standards. They help verify the sender’s identity and prevent domain forgery — known as email spoofing.

Although they work together, each solves a different problem.

These technologies do not guarantee inbox placement, but they are the foundation of a modern, credible email setup.

What is SPF?

SPF means Sender Policy Framework.

With SPF, a domain owner publishes in DNS which servers are authorised to send email using that domain for the SMTP envelope sender identity.

Suppose the company uses company.com and emails are sent through a server with IP 203.0.113.10.

You can publish this DNS record:

Type: TXT
Name: @
Value: v=spf1 ip4:203.0.113.10 -all

The IP address is reserved for examples and must be replaced with the real server address.

The record states that the specified IP is authorised to send email for the evaluated domain. The -all element indicates that other sources are not authorised. There is also ~all, which expresses a softer SPF policy.

Note: SPF does not directly check the address visible to the user in the “From” field. DMARC correlates that with the authenticated domain.

Common SPF configuration mistakes

A frequent problem is multiple SPF records for the same domain. If you use your own server and also an invoicing platform, you must not create two separate SPF records. Authorised sources belong in a single policy.

Another issue appears when an external platform starts sending email but the administrator forgets to add it to SPF.

SPF also has a limit of ten mechanisms or modifiers that trigger DNS lookups during evaluation. Exceeding it can produce a permerror.

So an SPF configuration must be correct — and as simple as possible.

3. What is DKIM and why does it matter?

DKIM means DomainKeys Identified Mail.

It is a technology by which the sending server adds a cryptographic signature to outgoing messages. The signature is created with a private key kept on the server. The recipient can verify it using the public key published in DNS.

If verification succeeds, there is evidence that the message was signed by the system controlling the key for that domain and that the signed parts were not modified afterwards.

How does DKIM work?

Suppose you send from office@company.com. The server applies a signature using the private DKIM key.

In DNS there is a record similar to this:

Type: TXT
Name: dkim._domainkey
Value: v=DKIM1; k=rsa; p=PUBLIC_KEY

PUBLIC_KEY is only a placeholder. The real value is generated by the email system. The name dkim is the selector and may differ depending on server configuration.

When Gmail receives the message, it can look up the public key and verify the signature. A valid result contributes positively to authenticity assessment.

How do you enable DKIM in Mailcow?

If you installed your own email server with Mailcow, the platform includes DKIM key management.

1. Open the Mailcow admin interface.
2. Select the domain for which you configure signing.
3. Generate or identify the DKIM key.
4. Copy the displayed name and TXT value.
5. Publish the record in the DNS panel.
6. Test the signature by sending a message.

Do not copy keys from public tutorials. Each setup must use its own cryptographic keys, and the private key must never be made public.

4. What is DMARC and how does it protect the company domain?

DMARC means Domain-based Message Authentication, Reporting and Conformance.

It complements SPF and DKIM and introduces two important elements: domain alignment and the policy for handling messages that fail authentication.

For example, a message may have a valid SPF result for a provider’s technical domain, but show your company domain in the “From” field. DMARC checks whether the identity authenticated by SPF or DKIM aligns with the visible sender domain.

To pass DMARC, it is enough for SPF or DKIM to pass and meet alignment rules. Both mechanisms do not have to pass, although configuring both correctly is recommended.

How do you configure DMARC?

In DNS you create a TXT record:

Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none

This is a monitoring policy. With p=none, you indicate that messages failing DMARC should not be specially rejected or quarantined because of your DMARC policy. The recipient provider may still apply its own spam filters.

We recommend starting with monitoring. After identifying all services that send on behalf of the domain, you can adopt a stricter policy.

How do you receive DMARC reports?

You can add an address for aggregate reports:

v=DMARC1; p=none; rua=mailto:dmarc@company.com

Make sure this mailbox exists and can receive reports. Aggregate reports usually use XML and can be analysed with specialised tools. They can show which sources send using your domain and where authentication issues appear.

If you identify unknown servers, they may be forgotten services, misconfigurations or impersonation attempts.

Do not enable p=reject immediately before checking all legitimate sending sources. You risk affecting invoices and automated notifications from company systems.

5. Reverse DNS and IP reputation

SPF, DKIM and DMARC are not enough if the server has identity problems at network level. An important element is reverse DNS, also known as a PTR record.

Normally, DNS turns a domain name into an IP address. For example: mail.company.com → 203.0.113.10. Reverse DNS does the opposite: 203.0.113.10 → mail.company.com.

Major email providers frequently check whether sending servers have a valid DNS identity.

How do you check PTR?

On Linux you can use:

dig -x 203.0.113.10 +short

Replace the address with your server’s public IP. The result should indicate the name corresponding to the SMTP server.

Also check the forward association:

dig mail.company.com A +short

The two checks should be consistent. If you use IPv6, also verify the matching AAAA/PTR setup. The PTR record is usually managed by the provider that owns the IP address.

What is IP reputation?

Reputation is an assessment of the sending behaviour associated with an IP address. If an IP was used for spam, phishing or large volumes of unwanted messages, it may have a problematic reputation.

This is a challenge for companies renting VPS servers. An IP received from a provider may have an unknown prior history.

Before migrating company email, check IP reputation and test sending to Gmail, Outlook and other relevant recipients.

Some platforms allow delisting requests if you fixed the cause of a block. Removing an IP from a public list does not, however, guarantee acceptance by every provider.

6. Why do Gmail or Outlook reject emails?

In recent years, major platforms have introduced stricter requirements for senders.

Google requires SPF or DKIM authentication for ordinary senders to Gmail. For those sending more than 5,000 messages per day to personal Gmail accounts, SPF, DKIM and DMARC are required, along with other technical and operational requirements.

Google also requires TLS connections, correct DNS configuration and compliance with message formatting standards.

Microsoft applies additional requirements for domains sending high volumes to its consumer services such as Outlook.com, Hotmail and Live. These include SPF and DKIM authentication as well as publishing a DMARC policy.

A message that does not meet requirements may receive a rejection response. An example is:

550 5.7.515 Access denied

This error is associated with authentication requirements Microsoft applies to high-volume senders.

If you receive an SMTP error, keep the full response. The code and provider explanation give important clues for identifying the problem.

Do not assume every rejected message is caused by DNS. The cause can also be a reputation policy, a content issue or traffic limiting.

7. How do you test whether company emails go to spam?

Before changing configurations at random, start with a diagnosis. Free and commercial tools can help identify technical problems.

Mail-Tester

Go to mail-tester.com. The platform generates a temporary email address. Send a test message from the professional address to that address and review the result.

The report may include information about SPF, DKIM, DMARC, blocklists and message structure. The score is useful for diagnosis, but it is not a guarantee that messages will reach the Gmail or Outlook inbox.

MXToolbox

Go to mxtoolbox.com. This service lets you check several elements of email infrastructure: MX, SPF, DNS, IP reputation and availability of certain SMTP services. It is especially useful when you suspect a configuration error.

Google Postmaster Tools

Google offers postmaster.google.com for eligible domains. Through it you can get information about domain reputation, authentication and reported spam rates, depending on volume and data availability.

Not all domains or periods have enough data for indicators to appear.

Manual testing

Send a few legitimate test messages to accounts you control, hosted by different providers. Check whether messages are delivered, rejected or moved to spam.

In Gmail you can use “Show original” to inspect headers and authentication results. Look for:

Authentication-Results

A favourable result might include:

spf=pass
dkim=pass
dmarc=pass

These results confirm the respective checks for that message, not deliverability of all future emails.

8. How do you check DNS using Linux?

If you administer your own email server, the dig tool is very useful.

dig company.com MX +short
dig company.com TXT +short
dig _dmarc.company.com TXT +short
dig dkim._domainkey.company.com TXT +short
dig -x 203.0.113.10 +short

If the configured DKIM selector differs from dkim, change the queried name.

If results are not what you expect, check records in the DNS panel. Remember that DNS updates may take time to become visible, depending on TTL and cache.

A correct diagnosis includes DNS queries as well as analysis of the real message and server logs.

9. Common mistakes that hurt deliverability

Even with SPF, DKIM and DMARC configured, messages can still go to spam for other reasons.

Sending high volume from a new server

A server without history may attract extra checks. If you immediately send thousands of messages, providers may limit traffic or classify some messages as suspicious.

For ordinary business communication, keep volume normal and predictable. For marketing campaigns, use infrastructure and procedures suited to bulk sending.

Outdated recipient lists

Sending to non-existent addresses generates delivery errors known as bounces. A high error rate can indicate poor list-management practices.

Remove invalid addresses and respect recipient preferences. Do not use purchased lists or lists collected without an appropriate legal basis.

Messages with suspicious links

An email may be assessed negatively if it includes links to domains known for abuse, unusual redirects or misleading content. Clear links and a legitimate domain help transparency.

There is no universal list of words that automatically cause spam classification.

Compromised accounts

If a mailbox password is stolen, an attacker can send unwanted messages using company infrastructure. This can quickly damage domain and IP reputation.

Use strong passwords, multifactor authentication where available, and monitoring of unusual sending.

Incorrect external application configuration

Invoicing, CRM, web forms and ERP systems may send email on behalf of the company. If they use different providers, each authentication path must be checked separately.

A domain may have correct SPF and DKIM for Mailcow, but incomplete setup for an external system.

10. Mailcow: how do you monitor sent messages?

If you use Mailcow to host email, you have tools for diagnosing traffic. The platform integrates Postfix for message transport and Rspamd for spam filtering.

To examine Postfix logs from the Mailcow installation directory:

sudo docker compose logs --tail=200 postfix-mailcow

To filter certain results:

sudo docker compose logs postfix-mailcow | grep -i "status="

Depending on configuration, you may see statuses such as:

• sent — the message was accepted by the next server.
• deferred — delivery was postponed and may be retried.
• bounced — delivery failed permanently.

Importantly, sent does not necessarily mean the message reached the inbox. It means the next server accepted the SMTP delivery. The recipient may still apply its own filters.

Do not arbitrarily change Rspamd rules or Postfix configuration hoping for better results. Before changes, check documentation, create a backup and identify the exact cause of errors.

If you have not installed Mailcow yet, see the INITWIN guide: How to build your own company email server with Mailcow.

11. Checklist for a professional email server

Before using a server for company correspondence, verify the following:

• The domain has correct A and MX records.
• The IP address has valid reverse DNS.
• SPF includes all legitimate sending sources.
• DKIM is active and signatures are verified.
• DMARC is configured and monitored.
• Domains used by SPF and DKIM are properly aligned.
• The server uses TLS and valid certificates.
• Messages comply with formatting standards.
• The IP and domain have no known reputation problems.
• There is monitoring for SMTP queues and delivery errors.
• Administrative accounts are protected.
• Backup and restore procedures exist.
• Commercial sending respects consent and unsubscribe where required.

12. When do you need help with email problems?

If one or two recipients report messages in spam, it may be a local or reputation issue. If many clients miss offers, invoices or confirmations, the situation must be investigated systematically.

Start with the server log, authentication results and error messages. Check whether the problem appears only with Gmail, only with Outlook or with multiple providers.

Do not change SPF, DKIM, DMARC, the server IP and message content all at once. Make controlled changes and test results so you can identify what fixed the problem.

For a company that depends on email for client communication, delays and lost messages can have real commercial consequences. A monitored, documented setup reduces the risk of unexpected interruptions.