Why Business Emails Go to Spam—and How to Fix It

A legitimate message can land in spam because receiving systems evaluate far more than the visible From address. They consider authentication, domain alignment, sending infrastructure, complaint rates, recipient behaviour, message format, links, volume and reputation.

This guide explains why business emails go to spam and how to investigate the problem methodically. It covers ordinary staff mail, website forms, invoices, transactional messages and marketing campaigns without pretending that one DNS record guarantees inbox placement.

Start with evidence, not guesses

Collect:

• the affected sender and recipient domains;
• full message headers from delivered examples;
• the exact rejection or deferral response;
• authentication results for SPF, DKIM and DMARC;
• sending date, volume and IP or provider;
• whether all recipients or one provider are affected;
• recent DNS, provider, website or campaign changes;
• complaint, unsubscribe and bounce data.

Do not send passwords or private message content to a public diagnostic service. Redact personal data while preserving the technical headers needed by your administrator.

Delivery outcomes are different

Rejected

The receiving server refuses the message and normally returns an SMTP error. The code and text are essential evidence.

Deferred

The receiving server asks the sender to try later. Repeated deferrals can eventually become a failure.

Delivered to spam

The receiving service accepts the message but classifies it as junk. Sender authentication, reputation, content and recipient behaviour can contribute.

Missing after acceptance

Mailbox rules, quarantine, forwarding, security gateways or user deletion may be responsible. Trace the message through provider logs.

1. Inventory every service that sends as your domain

Businesses often authenticate the main mailbox platform but forget:

• website contact forms;
• accounting and invoice software;
• CRM and ticketing systems;
• booking tools;
• newsletters;
• online-shop notifications;
• monitoring and application alerts;
• former providers still configured to send.

Create an owner, purpose and authentication record for each sender. Remove obsolete systems rather than leaving them permanently authorised.

2. Check SPF

SPF publishes which systems are authorised to send for an envelope domain. Google's guidance says the SPF record should include every legitimate sender and should be updated when a new third-party service is introduced.

Common SPF problems include:

• the current provider is missing;
• multiple competing SPF records exist at one hostname;
• the policy exceeds the DNS-lookup limit;
• an old sender remains authorised;
• the website uses an unlisted server;
• SPF passes for a domain that does not align with the visible From address.

Do not copy a generic SPF value from another company. Build one valid policy from the instructions for every service you actually use.

3. Verify DKIM signing

DKIM adds a cryptographic signature to outgoing messages. A public key in DNS lets receiving systems verify the signature and signing domain.

Check that:

• the provider has generated the correct selector and key;
• the DNS record is published at the correct hostname;
• signing is enabled after DNS verification;
• the signature survives any gateway or content modification;
• the signing domain aligns with the visible From domain for DMARC;
• old selectors are removed only after a safe key rotation.

Publishing a DKIM record does not prove that messages are being signed. Inspect a real outgoing message header.

4. Check DMARC and alignment

DMARC evaluates whether authenticated SPF or DKIM domains align with the domain shown to the recipient in the From address. It also publishes a policy and reporting destination.

A message can pass SPF for a provider domain and still fail DMARC alignment with your business domain. Configure the provider to use aligned return-path or DKIM signing where supported.

Roll DMARC out carefully:

1. Inventory legitimate senders.
2. Verify SPF and DKIM.
3. Publish a monitoring policy and collect reports.
4. Fix unaligned legitimate streams.
5. Increase enforcement in controlled stages.

Do not move immediately to a strict reject policy without understanding the reports. You can block your own invoices, forms or applications.

5. Verify forward and reverse DNS

For a dedicated sending server, the sending IP should have a valid PTR record, and that hostname should resolve back to the sending IP. Google's sender guidelines require valid forward and reverse DNS for mail sent to personal Gmail accounts.

The owner of the IP address usually controls reverse DNS. If you use a hosted email or transactional provider, it manages this infrastructure. If you operate your own server, coordinate PTR configuration with the network provider.

6. Use TLS and valid message format

Modern receiving services expect TLS during mail transport and correctly formatted messages. Invalid headers, malformed Message-ID values, broken MIME parts or inconsistent dates can contribute to rejection or filtering.

Use a maintained mail library or provider rather than manually constructing messages. Test plain-text and HTML alternatives, character encoding, attachments and reply addresses.

7. Protect sender reputation

Reputation can exist at IP, domain and provider levels. Sudden volume, complaints, invalid recipients, compromised accounts and poor list acquisition can damage it.

Good practice includes:

• sending only to people with an appropriate relationship or permission;
• using confirmed or well-documented list acquisition;
• removing hard bounces and persistent invalid recipients;
• honouring unsubscribes promptly;
• avoiding purchased or scraped lists;
• monitoring complaint and spam rates;
• increasing volume gradually on new infrastructure;
• separating high-volume marketing from critical transactional mail where appropriate.

Google Postmaster Tools can provide eligible senders with authentication, reputation, delivery-error and spam-report diagnostics. Use the provider tools relevant to your recipients.

8. Make marketing consent and unsubscribe clear

Marketing messages should identify the sender, reflect a lawful contact basis and provide a working unsubscribe route where required. High-volume senders may need one-click unsubscribe under receiving-provider rules.

Do not hide unsubscribe controls to protect list size. People who cannot leave may complain instead, which is worse for reputation and trust. Obtain legal advice on Irish and EU direct-marketing obligations for the actual campaign.

9. Review message content without chasing myths

No single word automatically sends every email to spam. Filters consider the combined sender, recipient, authentication, reputation and message context.

Still, messages should:

• use an accurate From name and subject;
• avoid deceptive urgency and misleading links;
• include a meaningful plain-text alternative;
• link to domains controlled by trusted services;
• avoid unnecessary URL shorteners;
• use accessible HTML rather than one large image;
• identify the organisation and purpose;
• include the required unsubscribe and business information.

Check whether a compromised website or linked domain is blocklisted. Even a well-authenticated message can look risky if it sends recipients to a hacked destination.

10. Fix website contact-form sending

A common mistake is making a form message claim to come directly from the visitor's email address. That domain has not authorised your web server and may fail authentication.

A safer pattern is:

• send from an authenticated address on your own domain;
• place the visitor's validated address in Reply-To;
• use authenticated SMTP or a transactional service;
• rate-limit and protect the form from abuse;
• escape user content in notification HTML;
• avoid exposing submitted personal data in logs;
• monitor delivery failures.

11. Separate transactional and promotional risk

Password resets, invoices and order confirmations have different urgency from newsletters. A high complaint rate on marketing should not prevent critical operational mail from reaching customers.

Use separate streams, subdomains or providers where justified, while authenticating and monitoring each. Separation is not permission to send unwanted mail; it is an operational control for legitimate message categories.

12. Check for account compromise

If deliverability declines unexpectedly, review:

• unusual sign-ins and sent messages;
• new forwarding and inbox rules;
• unknown OAuth applications;
• new administrator accounts;
• large or unusual sending activity;
• password resets and MFA changes;
• DNS changes to SPF, DKIM or DMARC.

Ireland's NCSC business email compromise guidance recommends MFA, least privilege, monitoring, SPF/DKIM/DMARC, blocking unauthorised forwarding and tested incident response.

A practical diagnostic sequence

1. Identify the exact sending service and affected recipients.
2. Read the SMTP error or full accepted-message headers.
3. Confirm SPF result and domain.
4. Confirm DKIM result, selector and signing domain.
5. Confirm DMARC alignment and policy.
6. Check reverse DNS and TLS for dedicated infrastructure.
7. Review bounces, complaints, volume and list acquisition.
8. Test links, format and website-form configuration.
9. Check for account or DNS compromise.
10. Correct one cause, retest and monitor rather than making random DNS changes.

What not to do

• Do not publish several SPF records to “cover everything”.
• Do not buy a new domain to escape poor sending practices.
• Do not ask recipients to whitelist a compromised sender.
• Do not use purchased mailing lists.
• Do not immediately enforce DMARC without monitoring.
• Do not repeatedly resend the same rejected campaign.
• Do not put mail passwords or DNS keys into support tickets.
• Do not assume an accepted message must appear in the inbox.

Business email deliverability checklist

• Every sender is inventoried and authorised.
• One valid SPF policy covers current senders.
• DKIM signing is active and tested.
• DMARC alignment passes for legitimate streams.
• Reverse DNS is correct where you operate the sending IP.
• TLS and message formatting meet provider requirements.
• Bounces, complaints and unsubscribes are processed.
• Marketing recipients have an appropriate permission basis.
• Website forms use an authenticated From domain.
• Transactional mail is monitored separately.
• Accounts use MFA and forwarding rules are reviewed.
• Postmaster and provider diagnostics are monitored.

Frequently asked questions

Does SPF stop emails going to spam?

SPF is one authentication layer. Deliverability also depends on DKIM, DMARC alignment, reputation, message quality, recipient behaviour and provider policy.

Why does email work for some recipients but not Gmail?

Providers use different requirements and reputation data. Check Gmail's sender guidelines, Postmaster Tools and the exact message headers or error response.

Should I change my email provider?

Only after identifying the cause. A provider change will not fix poor lists, unauthenticated third-party senders or compromised accounts.

How long does a DNS fix take?

Resolvers cache records according to TTL. Authentication can begin working after caches refresh, while reputation recovery may take longer and depends on future sending behaviour.

Can anyone guarantee inbox placement?

No. Receiving providers and users make filtering decisions. A responsible service can improve authentication and practices but cannot guarantee every message reaches an inbox.

Improve the system behind your email

Review the live Hoster business email plans and our professional email setup guide. For a deliverability issue, use the contact form with the affected domain, sending provider and redacted error code. Never include a mailbox password, recovery code or private key.

Official sources

• Gmail email sender guidelines
• Google Workspace SPF guidance
• Gmail Postmaster Tools and sender requirements
• Ireland NCSC business email compromise guidance
• Microsoft email authentication guidance