Domain email: why messages land in spam

Why email lands in spam

Gmail, Outlook and Yahoo handle huge volumes of mail, and some of it is sent by scammers using other people's names. So every incoming message gets checked: did the domain owner really send it? The answer comes from three DNS records: SPF, DKIM and DMARC. If they are missing or broken, the service cannot confirm the sender and plays it safe, sending the message to spam or not delivering it at all.

This affects all mail from the domain: website enquiries, payment emails, newsletters and everyday correspondence. Most people find out by accident, when a customer says they never got anything.

SPF, DKIM and DMARC in plain words

• SPF is the list of servers allowed to send email for the domain. The receiving service looks at which server the message came from and compares it with the list.
• DKIM is a digital signature. Your mail service signs every message with a private key, and the public key sits in DNS. The signature proves the message is genuine and was not changed on the way.
• DMARC is a rule on top of the other two: what to do with a message that fails (deliver it, send it to spam or reject it) and where to send reports. Only DMARC ties the check to the From address the recipient actually sees.

Each record on its own covers only part of the problem. Real protection comes when all three work and DMARC is set to quarantine or reject.

How to read the result

The summary at the top is the short answer. “Configured” means SPF works and DMARC is set to quarantine or reject, so forging a message in your name is hard. “Partly” means there is protection with gaps, for example DMARC only monitors or there are two SPF records. “Not protected” means mail services cannot tell your messages from forged ones.

Below are cards for each record with explanations, and at the end a “What to fix” block with ready-made records. Copy them and paste them into your DNS panel. Values in angle brackets, such as <selector>, must be replaced with your own; your mail service provides them. It is also worth changing the DMARC report address to a mailbox you actually read, or one connected to a report-parsing service.

Common mistakes

• Two SPF records. Someone connects a new newsletter service and gives it a separate record. The standard allows only one, so SPF fails for every message.
• More than 10 DNS lookups. Every include, a and mx needs a lookup, and includes can contain their own includes. Past the tenth lookup the check is treated as an error.
• +all or ?all at the end. The first lets anyone send, the second forbids nothing.
• DKIM only on the main mailbox. Mail from the CRM, online store or newsletter service goes out unsigned or signed with someone else's domain.
• DMARC stuck at p=none. The record exists and reports arrive, but forged mail is still delivered.
• Forgetting domains that never send mail. Scammers like them even more, because nobody notices the forgery. Two records are enough for such a domain: SPF "v=spf1 -all" and DMARC "p=reject".

How to turn on protection without losing mail

1. List everyone who sends email in your name: your mailbox provider, the website, CRM, newsletter service, payment or receipt services.
2. Build one SPF record with all their includes and end it with ~all.
3. Turn on DKIM in each of these services.
4. Add DMARC with p=none and a report address. After 2–4 weeks, review the reports: if they show only your servers, move to p=quarantine, then to p=reject.
5. Check the domain on this page after every step. DNS changes take anywhere from a few minutes to a day to spread.

Where to add the records

Records are changed wherever the domain's DNS is hosted: at the registrar, the hosting provider or in Cloudflare. Our DNS records tool shows who runs DNS for your domain. In the panel, create a TXT record. The name field usually takes only the left part, such as _dmarc, and the panel adds the domain itself. If the panel asks for the full name, enter it in full.