Why confirmation emails land in spam and how to fix it

The form works, your team receives the enquiry, and the customer swears they got nothing. When website emails land in spam, the cause is almost never the wording of the message. It is usually how the mail was sent and whether the receiving server can confirm you were allowed to send it. This article walks through the common causes in the order you should check them, explains SPF, DKIM and DMARC in plain terms, and lists the tests that tell you whether the fix worked.

The good news: most of this is configuration, done once, and it improves every email your site sends, from acknowledgements to order receipts and password resets.

Cause one: sending directly from your web server

Many sites use the server's own mail function, which hands the message to a mail program running on the same machine as the website. It is the default in a lot of hosting setups and the single biggest reason messages fail to arrive.

Shared hosting addresses often have a poor or unknown sending reputation, because hundreds of other sites use the same machine. Many cloud providers block outbound port 25 entirely. The server frequently has no reverse DNS record matching the sending domain, which receiving systems treat with suspicion.

The fix is to send through a proper mail service using authenticated SMTP or an API: your own business mailbox provider, or a dedicated transactional mail service. Your form or application then logs in with credentials rather than posting mail anonymously from the web server. On WordPress this typically means an SMTP plugin; in a framework it is a change to the mail configuration.

Cause two: a From address that is not yours

A classic mistake is setting the From address of the notification to whatever the visitor typed. The mail then claims to come from a Gmail or Yahoo address but was sent by your server, which looks exactly like forgery, because technically it is.

The rule is simple: the From address must be on a domain you control and are authorised to send for. Put the visitor's address in Reply-To instead, so hitting reply still reaches them. This one change often fixes deliverability on its own, and it also closes a route spammers use to relay messages through your form.

Cause three: missing or wrong authentication records

Three DNS records tell receiving servers that mail claiming to be from your domain is genuine. Without them, even a perfectly written message starts at a disadvantage.

SPF

An SPF record lists which servers may send mail for your domain. It is a single TXT record, and you must have only one for the domain. If you use Google Workspace and a transactional service, both need to be included in that one record. Keep the total number of DNS lookups it triggers under ten, or it fails.

DKIM

DKIM adds a cryptographic signature to each message, letting the receiver verify the content was not altered and came from an authorised system. Your mail provider generates a key and gives you a TXT record to publish at a selector name. Check that the signing domain matches your From domain.

DMARC

DMARC ties the two together: it tells receivers what to do when SPF and DKIM fail, and where to send reports. Start with a monitoring policy of p=none and a reporting address, read the reports for a few weeks to find every system sending as your domain, then tighten to quarantine and eventually reject. Tightening too early can block your own invoicing software or CRM.

Publish these before you worry about anything else in this article. A domain with no SPF and no DKIM will keep having problems no matter how you rewrite the text.

Cause four: the content and structure of the message

Once authentication is in place, content matters at the margins.

• One big image and almost no text is a classic spam pattern. Keep a real text body.
• Link shorteners and mismatched links, where the visible text says one domain and the href points elsewhere, are heavily penalised.
• Attachments on automated mail, especially archives and documents, raise scores. Link to files instead.
• Shouty subject lines, excess capitals, multiple exclamation marks and words like "free" and "guaranteed" still contribute, though far less than authentication does.
• Missing a plain text alternative in a multipart message makes it look machine-generated in a bad way.
• Tracking pixels and heavy third-party scripts in the HTML add nothing helpful to a simple acknowledgement.

Also check the technical envelope: a valid Message-ID, a Date header in the right format, and a Return-Path that matches your domain. A misconfigured mail library sometimes omits these.

Cause five: reputation and volume patterns

A brand new domain has no sending history, so early messages get extra scrutiny. If you have just moved to a new domain or a new mail service, expect a settling period and avoid sending a large batch on day one.

Repeated sends to invalid addresses hurt, which is another reason to validate addresses and to stop retrying a hard bounce. So do complaints, so never mix marketing into service mail. If your IP or domain appears on a public blocklist, most lists provide a delisting request form; find the cause first, because a delisting without a fix does not last.

How to test what is actually happening

1. Send a test to a mail-testing service that gives you a score and shows which checks passed. These sites give you an address to send to and a report covering SPF, DKIM, DMARC, blocklists and content.
2. Read the full headers of a received message. In Gmail, "Show original" displays the authentication results lines with pass or fail for each check.
3. Check the DNS records with an online SPF, DKIM and DMARC lookup tool, then confirm they resolve from outside your network.
4. Test to several providers: Gmail, Outlook and at least one business mailbox on a corporate filter, since they behave differently.
5. Read your DMARC reports after a couple of weeks to catch a forgotten sender, such as an old server still emailing as your domain.
6. Check your application's mail log to confirm the message was queued and accepted, not silently dropped.

Work through it in this order

Fix the sending route first, then the From address, then publish SPF, DKIM and DMARC, then tidy the content. Re-test after each step so you know which change helped. Keep a note of the mail service, the DNS records and the credentials location with your other site documentation, because this is exactly the knowledge that disappears when a developer moves on. If your site currently sends through the web server and you want it moved onto a properly authenticated setup, our team can handle it alongside your hosting configuration.

Frequently asked questions

Why do emails reach Gmail but not Outlook?

Providers weigh signals differently and keep separate reputation data. Outlook and corporate filters tend to be stricter about new domains and missing DMARC alignment, so check that DKIM signs with your own domain rather than the mail service's.

Is a no-reply address bad for deliverability?

It is not penalised directly, but a mailbox nobody monitors means bounces and replies go unseen, and customers who reply get no answer. A monitored address is better for both people and filters.

Do I need a dedicated IP address for sending?

Not for the volumes a typical small business sends. A shared pool at a reputable transactional provider generally has better reputation than a dedicated IP with no sending history.

How long after fixing DNS records does delivery improve?

DNS changes usually propagate within a few hours, but reputation recovers more slowly. Give it a week or two of normal, low-complaint sending before judging the result.