Company Emails Landing in Spam? Check DNS First
5 min read
A quote goes out and nothing comes back, and when you chase it, it was sitting in their junk folder. Customers say the order notification never arrived. Members say the same about password resets. In most of these cases the message does not read like an advert. The recipient's system simply cannot confirm that you sent it. Mail providers are unforgiving towards senders who cannot prove who they are, and proving it comes down to three settings on your domain.
1. Why legitimate email gets blocked
Email was designed loosely, and the from field can be filled in with anything at all. Fraudsters use exactly that to send mail in somebody else's name, so receiving systems built a set of checks around one question: was this message really sent by a server your domain authorises?
With nothing configured, your message arrives as one that claims to come from a domain and cannot be verified. Some systems drop it into junk, others reject it outright. None of this has anything to do with how the message is written. Changing the subject line, removing the attachment or cutting the number of links will not rescue it.
Certain moments cause trouble. Moving host, changing mail provider or adding a newsletter tool usually introduces a sending source that nobody put on the authorised list. Automated email from a website is the most exposed of all, because it normally goes out through the hosting or a third-party sending service rather than the server you collect your own mail from.
One pattern misleads people badly: some recipients get the message and others do not. That is normal, since providers judge differently. It does not mean your setup works some of the time. It means the more lenient providers are still letting it through. Receiving your own test message is not evidence that anything is fine.
2. What each of the three proves
All three live in your domain's DNS settings, and none of them requires a change to the website itself. The names look technical, but what each one proves is straightforward, and they prove three different things.
| Record | What it proves | What happens without it |
|---|---|---|
| SPF | Who may send using my domain. You list the authorised sending servers and the recipient checks the source against that list | Anyone can send mail in your domain's name and the recipient has no way to judge |
| DKIM | The message was not altered in transit. A signature goes out with it and the recipient verifies that against your published key | When mail is forwarded or tampered with, there is no way to prove it is the message you sent |
| DMARC | What to do when a check fails: accept, junk or reject. It also sends you reports on who is sending in your domain's name | Every provider guesses for itself when a check fails, and you never see anyone impersonating you |
The three work as a set. Setting up SPF alone is the most common half-measure and improves things only a little, because SPF checks the sending server and breaks easily once a message is forwarded. DKIM is what proves the content was not touched, and only with DMARC on top do you get to decide what happens on failure.
3. How to check your own setup
You do not need a customer complaint to find out. The fastest check is to send a message to your own Gmail account, open it, and choose "Show original". The panel at the top lists the three results, and all three need to pass. Anything showing a failure, or no result at all, means the setup is incomplete.
For a fuller diagnosis, there are free email authentication testing services. You send a message to the address they give you and they report the state of all three records and what has been filled in wrongly. What these are good at is catching details you would never spot yourself, such as an authorisation list too long to be processed, or a signature configured only halfway.
A domain already in use gives you two more clues. If DMARC reporting is switched on, the weekly aggregate data shows whether one source keeps failing, which is usually the service nobody listed. And the error text inside bounce messages is worth reading, since it often states the reason for rejection outright.
4. Automated email from the website needs extra care
Form notifications, order confirmations and password resets are the most likely to be blocked and the most damaging when they are. A customer who does not receive an order confirmation phones you. Somebody who does not receive a password reset cannot log in. Worse, most people never tell you. They decide the company seems unreliable and go elsewhere.
So this category needs a few extra steps, all of them settled before launch rather than after the first complaint.
Four things to settle before automated email goes live
- Do not send directly from the web host. Shared hosting addresses carry the reputation of everyone else on them, which is usually poor. A dedicated sending service passes authentication far more often.
- Send from your own domain. A free mailbox address in the from field is treated as suspicious immediately.
- Make the reply address a real one. A reply-to nobody reads is another mark against you.
- Walk the whole thing through before launch. Register, order and reset a password once each, receiving at accounts on different providers, and confirm every message reaches the inbox.
5. It will not work instantly
After a change to the domain settings, the new values need time to spread to servers around the world. A few hours is typical and occasionally it takes until the next day. Test it yourself on the day and confirm the check results turn to pass. Do not write the whole thing off because the first test message still landed in junk.
Reputation takes longer. A domain's sending reputation is accumulated, so one that has been treated as spam for a long time takes a while to recover even once the records are complete. Do not send a large batch during that period, since a sudden spike is itself a spam signal. Send small volumes, confirm they reach the inbox, and scale up gradually.
Undelivered email costs more than it looks: the customer thinks you never replied, the order looks like it never went through, and the member who cannot log in says nothing to you. These three records are a one-off job, and once they are done you can leave them alone unless you change sending service.
Common questions
- We use Google Workspace. Do we still need to set this up ourselves?
- Yes. The provider gives you the values, but adding them to your domain's DNS is your job, and plenty of people skip it. If anything else sends using the same domain, such as your website's notification email or a newsletter tool, those sources have to be included too.
- Is SPF on its own enough?
- It helps, but no. SPF checks the sending server and breaks easily when a message is forwarded. DKIM is what proves the content was not altered, and DMARC is what tells recipients how to handle a failure while sending you reports on who is using your domain's name. The three together are the complete answer.
- Could these settings block legitimate mail?
- They can, which is why the order matters. Start DMARC in monitor-only mode, read the reports until every legitimate source passes, then tighten gradually. Skipping the observation period and going straight to reject is an easy way to block everything from a service you forgot to list.