+48 501 250 220

Emails landing in spam? Find the cause and plan the fixes

Invoices, quotes or one-time passwords land in spam or come back? Since November 2025 Gmail has enforced its sender rules more strictly, including rejections (As of 2026-10). We check SPF, DKIM, DMARC and reputation and give you a written action list.

Have your deliverability checked See the email deliverability service
  • Postfix and Dovecot servers and transactional mail for practically all clients
  • Reply within one working day
An envelope on the left with a line passing through three vertical gates, the first two black and the third orange; beyond the orange gate the line continues faintly to an upper box, and a dashed branch leads to a lower box

Is the email in the spam folder or does it come back?

The email is in the spam folder

The recipient accepts the email but classes it as suspicious. Common causes are missing authentication (SPF, DKIM, DMARC), a poor reputation of the domain or IP address, and a system that sends in your name without anyone checking it.

The email comes back

The bounce message carries an error code such as 4.7.x or 5.7.x. The recipient's server has rejected the email. Typical reasons are failed authentication, a missing reverse DNS record, an unencrypted connection or an IP address on a blocklist.

Microsoft is one example. Domains that send 5,000 or more messages to Outlook.com, Hotmail, Live.com or MSN must pass SPF and DKIM. They also need a DMARC record with at least p=none that passes. Otherwise Microsoft rejects the email with error 550 5.7.515 (Microsoft (opens in a new window), as of 2026-10).

Typical triggers

  • A move to a new server, for example from Windows/IIS to Linux. The IP address, reverse DNS record and HELO name change, but the SPF record still names the old address.
  • A new CRM, a newsletter service or a helpdesk sends with your domain.
  • A major client asks about SPF, DKIM and DMARC.
  • Nobody in the company knows the mail server any more.
An envelope on the left and a line to an inbox tray on the right; shortly before the tray the line breaks off at a point marked with an orange ring and continues dashed

First diagnosis in 15 minutes: six checkpoints

Checkpoint What it secures How to check it Typical fault
SPF Which servers may send for your domain. Query the TXT record: dig +short TXT your-domain.com. It starts with v=spf1. A sender is missing, there are two SPF records, or more than ten DNS lookups.
DKIM Adds your domain's signature to every email, so the recipient can verify where it came from and that it was not altered. Send a test email to a Gmail mailbox and choose "Show original". SPF and DMARC results appear there too. The system does not sign, or signs with a domain other than the sender domain.
DMARC What happens to email that fails SPF and DKIM, and reports about it. Query the TXT record at _dmarc.your-domain.com. It starts with v=DMARC1. No record, or p=none for years without anyone reading the reports.
Reverse DNS (PTR) Maps the mail server's IP address to a name that resolves back to the address. Run dig -x with the IP address, then resolve the returned name again. The hosting provider's default name, or a name that differs from the server's HELO name.
TLS Encrypts the transfer between mail servers. openssl s_client -starttls smtp -connect mail.your-domain.com:25 shows the certificate and the encryption. Certificate expired or issued for a different name, or no STARTTLS.
Unsubscribe header One-click unsubscribe, required for newsletters and bulk promotional mail. Check the headers of a newsletter email for List-Unsubscribe and List-Unsubscribe-Post. The header is missing, or unsubscribe requests are not processed.

Which systems still send in your name?

If the six checkpoints are fine, it is worth looking at the other systems that send with your domain: the CRM, a newsletter service, the helpdesk, the accounting system or a web form. Each of them should be listed in the SPF record and have a DKIM key for your domain; otherwise its emails may fail the recipient's checks.

We look for these senders in DNS, in your mail server's logs and in existing DMARC reports. The reports show every server that sends with your domain. If there are no reports, we first collect them with p=none. That takes longer than the check itself.

Four boxes on the left, each joined by a line to a vertical bar inside a tall frame; the lowest line is dashed and orange; from the bar an arrow leads to a single box on the right

How the deliverability check runs

  1. Access and measurement

    We receive access to DNS and the mail server, or log extracts, plus examples of affected emails. We measure the six checkpoints and send test emails to mailboxes at the large providers.

  2. Identify the senders

    From DNS, logs and existing DMARC reports we establish which systems send in your name, and check their emails for SPF and DKIM.

  3. Assess the causes

    We check the reputation of your IP addresses and your domain, for example against blocklists, and rank the findings by impact and effort.

  4. Action list and walkthrough

    You receive the written findings and the DMARC plan. We go through both with you and your IT team.

What the test report contains

Your IT team applies the fixes from the list, or we carry them out as a separate project on request.

  • Findings with baseline values

    The six checkpoints, measured before the fixes.

  • List of the senders found

    The systems that send with your domain, each with the result of the check.

  • Actions by priority

    With the place of the change (DNS, application or mail server) and the effort.

  • DMARC plan

    The steps from p=none to p=reject, with an address for the reports.

What Gmail and Yahoo require from senders

As of: 2026-10
Date Event Source
2024-02-01 Gmail requires every sender to use SPF or DKIM, valid forward and reverse DNS records (PTR), TLS and a spam rate below 0.3%. From about 5,000 messages a day to Gmail addresses, SPF and DKIM are required together, plus DMARC with alignment. support.google.com (opens in a new window)
2024-02-01 From February 2024 Yahoo requires every sender to use SPF or DKIM, valid forward and reverse DNS records and spam complaints below 0.3%. Bulk senders need both, plus DMARC, and must process unsubscribe requests within two days. senders.yahooinc.com (opens in a new window)
2024-06-01 Gmail requires bulk senders of marketing and promotional mail to offer one-click unsubscribe. Senders that already had an unsubscribe link were given until this date. support.google.com (opens in a new window)
2025-11-01 From November 2025 Gmail enforces the requirements more strictly. Non-compliant email is increasingly rejected, temporarily or permanently, shown by error codes in the 4.7.x and 5.7.x series. support.google.com (opens in a new window)

DMARC plan: p=none to p=reject without blocking your own mail

  1. Observe with p=none

    We publish DMARC with p=none and an address for the reports. Email arrives as before, and the reports show every sender and where SPF or DKIM fail.

  2. Fix the senders

    We set up SPF and DKIM for every legitimate system until the reports no longer flag any of your own email as faulty. Depending on the number of senders, this takes weeks.

  3. Move to p=quarantine

    Email that fails DMARC lands in the recipient's spam folder. We keep reading the reports and correct whatever stands out.

  4. Move to p=reject

    If the reports stay clean, recipients reject email that carries your domain as sender but fails DMARC. We keep watching, because new systems keep arriving. BIMI, the display of your logo at the recipient, is an optional extra and not a requirement for delivery.

When the application sends the email itself

Many applications send email themselves: ColdFusion and Lucee with cfmail, PHP with mail() or a library. Typical faults:

  • The application sends directly from the web server instead of logging in to a mail server over SMTP (submission). The SPF record does not know that server.
  • The sender address belongs to a different domain from the one SPF and DKIM are set up for.
  • Bounces land in a mailbox nobody reads, and invalid addresses stay on the mailing list.

If sending runs through your own Postfix server, we also check its configuration, queue and logs. The action list states where the fault arises: in the application, on the mail server or in DNS. You will find more on our work with ColdFusion & Lucee and with PHP on the technology pages.

An application window and a line with an envelope to a mail server and on to an inbox; the connector at the mail server is orange

Our engineers' experience with mail servers and application mail

Mail operations
Postfix and Dovecot servers and systems for transactional mail, for practically all clients
Application mail
Sending from ColdFusion, Lucee and PHP, including bounces and unsubscribes
Authentication and reputation
SPF, DKIM and DMARC with reports, reverse DNS, TLS and sender reputation
Full stack and DevOps
Since 2012, from the application to the server

How we work on your email deliverability

  • Access credentials, configuration and documentation stay with you.
  • We also tell you when something is not worth doing.

The recipient's server decides on delivery

The test therefore covers what we can influence: technically correct sending, the mail providers' requirements and the measurement of the result.

And if someone on our side is unavailable?

We write the documentation on request. The repository is normally with you. We arrange cover on request. Our working methods are described under How we work.

On the left a sheet with lines of text and a signature line with an orange tick; an arrow points to a server drawn with dashed lines on the right

The first step: deliverability check with action list and DMARC plan

Email deliverability check

For companies whose invoices, quotes or one-time passwords land in spam or bounce back as undeliverable.

  • DNS records of your domain: SPF, DKIM, DMARC and reverse DNS (PTR)
  • Reputation of your domain and your sending IP addresses
  • Headers of real emails from your application and your other systems
  • Test emails to mailboxes at the large providers
  • List of fixes in order of priority

We agree the scope and price in the intro call and confirm them in writing before we start. The fixes themselves and the ongoing operation of mail servers are not included. If you wish, we agree both afterwards.

What the result contains

A written action list with the causes and the fixes in order of priority, plus a plan for DMARC. Both are yours.

Request a deliverability check

Two cases from our work

  • Four envelopes pass the gates SPF, DKIM and DMARC, each ticked in orange, on the way into the inbox

    Email deliverability for four company domains

    A mail server for four company domains signed nothing, published no DMARC policy and was rejected by Microsoft. Our engineers audited it, piloted the change on one domain and rolled it out in batches. The result: all three checks pass at Gmail, the Microsoft block was lifted, and the users noticed nothing.

  • A score scale with a dashed threshold: the phishing envelope moves in an orange arc across the threshold

    A spam filter that ran but did not protect

    Services up, configuration valid, no errors in the system status. Yet phishing landed in the inboxes while partners' newsletters went to spam. Our engineers measured which detection mechanisms actually fired, repaired the causes, and three months later found and fixed a regression that only showed up hour by hour.

Common questions about spam, SPF, DKIM and DMARC

Will DMARC with p=reject block our own invoices?

Not if all senders have been identified and set up beforehand. We start with p=none and read the DMARC reports: they show which systems send in your name. For each legitimate system we set up SPF and DKIM. We move to p=quarantine and then to p=reject only once the reports no longer show any of your own mail as failing.

If a new system is added later, it must be authorised in SPF and have a DKIM key before it sends its first message. Otherwise recipients reject its mail.

Is it enough if our newsletter service signs the emails?

Not automatically. Many services initially sign with their own domain. For DMARC, however, the signature or the SPF record must match your sender domain (alignment). To do that, you register your domain as the sender domain with the service and add the DNS records it specifies.

Whether this has been done is shown by the headers of a test email (Authentication-Results) and by the DMARC reports. The same applies to your CRM, helpdesk and other systems that send on your behalf.

Why does email land in spam after a server move?

In a move, the IP address, the reverse DNS record and the name the server announces itself with (HELO) usually change. The SPF record then still names the old address, and the DKIM key is often missing on the new system. On top of that, a new IP address has no reputation yet with the large providers.

This also affects applications that send mail themselves, for example with cfmail after a switch from Windows/IIS to Linux. For a planned move, these points therefore belong on the checklist before the servers are switched over.

How quickly do the corrections take effect?

That depends first on when the fixes reach the systems: changes in DNS, on the mail server or in the application are made by your IT team, your hosting provider or by us once we have access. DNS changes take effect once the lifetime of the previous record (TTL) has expired. The reputation of a domain or IP address recovers at a pace that depends on the provider and the cause, which is why it is worth measuring again after the fixes.

Can you guarantee that our emails reach the inbox?

A delivery guarantee is not technically possible, because the receiving server decides. We make sure delivery is technically correct, compliant with the mailbox providers' policies and monitored. SPF, DKIM and DMARC are set up correctly. The reputation of your senders is watched, and every system that sends on your behalf is on record. After that we measure the result.

What if we are missing access credentials?

This can usually be solved. We start with what you still have to hand. That is the contract and customer account with the hosting provider, access to the domain and, where available, the repository and backups. Server access can often be reset through the hosting provider if you act as the contracting party. We only gain access to a system with your explicit consent.

When can you start?

You will receive a first reply within one working day. When we begin work depends on our current workload and on the scope. We give you a binding answer in the intro call. If it is urgent, the 48-hour emergency assessment starts as soon as we have access to the system.

Which of your emails land in spam?

Tell us which emails are affected, at which recipients and since when. We reply within one working day and suggest the right first step.

Fields marked optional can stay empty.

Reply by email

For a call back we only need your phone number: emergencies around the clock, otherwise within one working day.

Which system, which technology, what do you want to achieve? Please do not send passwords or confidential documents.

Reply within one working day · without obligation

We use your details only to answer your enquiry. Prownex IT Services Sp. z o. o. is the controller. Retention and your rights are described in the privacy policy.