MarTech · · 8 min read

YOUR EMAILS ARE GOING TO SPAM

Replies dry up and everyone blames the subject line. In the audits I run, the copy is rarely the first problem. The sending domain is.

The short version
  • Mailbox providers expect SPF (who may send as you), DKIM (a signature on the message) and DMARC (what to do if those checks fail) on the domain you send from. A CRM or email platform will send without that being finished.
  • If marketing mail and staff mail share one domain, a bad campaign can take invoices and client mail into spam with it.
  • Assistants now summarise and file the inbox. Unauthenticated mail is easy to ignore. You do not get a fair test of the copy if the copy never arrives.
  • Check the sending domain with a public DNS lookup (the internet address book for that domain) before you rewrite the nurture sequence. The email authentication guide is the working document.

The complaint usually arrives as a content problem. Open rates fell. Replies stopped. Someone has already rewritten the first line twice.

I ask to see the sending domain first (the domain in the From address of the campaign, which is often not the website domain). Not the template. The DNS (the internet address book for a domain).

Mailbox providers decided this for you. If SPF (a public list of servers allowed to send mail as that domain), DKIM (a signature on the message that proves it was not altered in transit) and DMARC (the policy that tells Gmail and others what to do if SPF or DKIM fail) are missing or pointing at the wrong place, a lot of that mail never reaches the inbox. Tools such as HubSpot and Salesforce make it easy to start sending on a domain nobody finished authenticating. The platform looks fine. The mail does not.

This is worse when the same domain is used for staff email. A bulk send with a broken record does not only hurt the campaign. It can take invoices, tenders and client mail with it.

What these words mean

  • DNS: the internet address book for a domain. The records that say where a website lives and which servers may send its mail.
  • Sending domain: the domain in the From address of the campaign, which is often not the same as the website domain.
  • SPF (Sender Policy Framework): a public list of servers allowed to send mail as that domain.
  • DKIM (DomainKeys Identified Mail): a signature on the message that proves it was not altered in transit.
  • DMARC (Domain-based Message Authentication, Reporting and Conformance): the policy that tells Gmail and others what to do if SPF or DKIM fail. p=none only reports. Quarantine or reject actually blocks.
  • MX (mail exchange): the record that says which servers receive mail for the domain.
  • Header: the hidden routing data on a received email. It shows whether authentication passed on that send, not just what is published in DNS.
  • Bulk sender: Gmail's term for anyone sending more than 5,000 messages a day to personal Gmail accounts.

What changed in the inbox

People used to scan a list of subject lines. Plenty now let an assistant summarise the morning. Unauthenticated mail is easy for that software to treat as noise. You do not get a fair test of the copy if the copy never arrives.

Publishing a record is not the same as enforcing it

Gmail's sender guidelines (opens in a new tab) require bulk senders (Gmail's term for anyone sending more than 5,000 messages a day to personal Gmail accounts) to set up SPF, DKIM and a DMARC record. The minimum DMARC policy is p=none, which reports and does not block. Yahoo and Microsoft now run similar rules for their consumer mail.

Valimail's 2026 State of DMARC Report (opens in a new tab) found 78 per cent of domains now publish a DMARC record, and only 42 per cent have moved that record to quarantine or reject. The rest have checked a box. Spoofed mail in their name still arrives.

78%domains with a DMARC record (Valimail 2026)
42%at quarantine or reject (Valimail 2026)
0.3%Gmail spam-rate ceiling for bulk senders (Gmail sender guidelines)

The order of work

  1. Confirm which domain the CRM or email platform is sending from.
  2. Check SPF, DKIM and DMARC on that domain, not the root domain you assumed.
  3. Separate marketing mail from staff mail if they currently share one reputation.
  4. Then look at the list and the copy.

Tools that show you the records

You do not need a consultant to see the first problem. These are public lookups. Run them on the sending domain, not the website domain you assumed.

If a header shows fail, or the DNS lookup is empty, stop rewriting the sequence. The email authentication guide is the working document I use next. If the records are wrong, a MarTech systems conversation is usually the job, not another workshop on subject lines.

If the mail never arrives, the subject line is not the problem.

COMMON QUESTIONS

Which tool should I open first?

MX Toolbox or Google Check MX, both public lookups of mail records, on the sending domain, the one in the From address. Then paste one real message into Messageheader. The DNS lookup (the internet address book) tells you what is published. The message header (the hidden routing data) tells you what happened on that send.

We already have a DMARC record. Are we done?

Only if the policy is quarantine or reject and the reports look clean. A DMARC record (the policy that tells Gmail what to do if a check fails) set to p=none only reports. It satisfies the Gmail bulk-sender floor. It does not stop spoofed mail in your name.

How do I know if this is DNS or copy?

If a share of mail never arrives, or lands in spam across several inboxes, start with DNS, the internet address book for the domain. If it arrives and nobody replies, then look at the list and the copy.

Can you fix this without moving email platform?

Yes. Most of this is DNS (the internet address book) and the sending domain (the From address) inside the tool you already pay for. Moving platform is a different job and I will say so if that is actually the problem.

Does this apply to a small list?

Yes. Provider rules do not scale down because you send a few hundred emails a month. A small list on a shared domain is still enough to cause trouble.

Recognise any of this?