Why your business email goes to spam, and what actually fixes it

A receiving mail server has to answer one question before it decides where your message goes: did the domain in the From address authorise this server to send on its behalf? For a brand-new domain the honest answer is "nobody has said", and a server with no answer treats the mail as suspicious. That is not a penalty for being new. It is the only safe default, because the alternative is accepting anything that claims to be you.

Three DNS records between them give the answer. They are usually introduced as a checklist, which is why people add all three at once, get one subtly wrong, and end up worse off than before. They are better understood as three separate questions.

SPF: which servers may send as you

SPF is a TXT record listing the servers allowed to send mail using your domain. It looks like this, and the detail that matters is at the end:

~all means "anything not listed above is suspicious". -all means "anything not listed is forged, reject it". The temptation is to go straight to -all because it sounds stricter and therefore better. Do not, not on day one — if you have forgotten a sender, and almost everyone has, -all tells the world to throw that mail away. Your invoicing tool, your contact form, your newsletter and your CRM all send as you, and each needs to be in the record or deliberately left out.

The second trap is subtler. SPF permits a limited number of DNS lookups, and every include: spends one. Chain four or five providers together and you quietly exceed it, at which point the whole record stops being evaluated — not the last entry, the whole thing. A record that is too generous fails exactly like a record that is missing.

There may only be one SPF record per domain. Two records, each individually correct, is a permanent error — the receiving server cannot choose between them, so it discards both.

DKIM: proof the message was not altered

SPF vouches for the server. DKIM vouches for the message. Your mail host signs each outgoing message with a private key, publishes the matching public key in your DNS, and the receiver verifies the signature. If anything in the signed part of the message changed in transit, the signature breaks.

This is the record people most often skip, because nothing visibly fails without it — and it is the one that matters most for forwarded mail. When someone forwards your message, the forwarding server becomes the sender, so SPF no longer matches. DKIM still does, because it travels with the message rather than describing the route. A domain with SPF and no DKIM looks legitimate until the first time a customer forwards your quote to their accountant.

DMARC: what to do when the first two disagree

DMARC is the instruction that ties the other two together. It says what a receiver should do when a message claiming to be from you passes neither check, and — the part almost nobody uses — asks receivers to send you reports about what they saw.

p=none means "do nothing differently, but tell me what you saw". It is the correct place to start and the wrong place to stop. Start there because you do not yet know every system that sends as you, and you will be surprised by at least one. Leave within a few weeks, because p=none on its own provides no protection — anyone can still send mail as your domain and have it delivered.

The upgrade path is p=none for one to two weeks while you read the reports, then p=quarantine to send failures to junk, then p=reject once a fortnight of reports shows nothing legitimate failing. Skipping to p=reject is how a business loses a week of order confirmations without noticing.

The order that works

1. Publish SPF with ~all, listing every system you know of that sends as you.
2. Enable DKIM at your mail host and publish the key it gives you.
3. Publish DMARC at p=none with a rua address you will actually read.
4. Send test mail to a Gmail and an Outlook address, and check the headers show spf=pass and dkim=pass.
5. After a week or two of reports with nothing unexpected, move to p=quarantine.
6. After a fortnight at quarantine with no legitimate mail affected, move to p=reject and tighten SPF to -all.

There is also one non-technical requirement that no record can substitute for: send mail people want. Authentication proves you are who you say. It does not make you welcome. A domain that is perfectly configured and sends unsolicited bulk mail will still end up filtered, because recipients pressing "report spam" outweighs every record above.

How to check what you have now

Before changing anything, look at what is actually published. From a terminal:

The DKIM selector is given to you by your mail host; there is no way to guess it. If the first command returns two lines both beginning v=spf1, you have found your problem already.

The other check costs nothing: send a message to a Gmail address you control, open it, and choose "Show original". The authentication results are at the top, in plain language. A dkim=none there is worth more than any online scanner's score.