Automated Email Goes to Spam: SPF, DKIM and DMARC as an Operations Process

When automated invoices land in the spam folder, the first move is not rewording the message. It is opening one delivered message and reading its Authentication-Results header. That header reports three verdicts - spf, dkim and dmarc - and whichever one failed is what you fix, in that order.

Step one: read the Authentication-Results header

Every mail client can show a message's full source. Inside it is a line shaped like Authentication-Results: mx.google.com; spf=pass ...; dkim=pass ...; dmarc=fail .... That line is the diagnosis.

• spf=pass and dkim=pass but dmarc=fail means an alignment problem, not a records problem.
• spf=fail means the server that actually sent is not authorised in the domain's SPF record.
• dkim=none means the message was never signed at all. This is the single most common finding on automated systems configured once and then forgotten.
• spf=permerror means the record itself is broken, most often by exceeding the lookup limit.

Without that header you are rewording copy and hoping. With it you know which of the three records you are dealing with.

What each of the three records actually does

The values look like this in practice: v=spf1 include:_spf.example.net ~all for SPF, v=DKIM1; k=rsa; p=<base64 key> for DKIM, and v=DMARC1; p=none; rua=mailto:dmarc@example.com for DMARC. Three notes that save a round trip: publish exactly one SPF record per domain, SPF evaluation is capped at 10 DNS-querying terms and returns permerror above that, and your DKIM selector is chosen by whichever provider sends for you.

What is alignment, and why does a passing SPF still fail DMARC?

Alignment is the requirement that the domain which authenticated is the same domain the recipient sees in the From field. This is where most businesses come unstuck, and it explains the confusing state where everything looks green and DMARC still fails.

• SPF authenticates the envelope domain, 5321.MailFrom. The recipient sees 5322.From. If your sending provider sets an envelope in its own domain, SPF passes but is not aligned.
• DKIM is aligned when the domain that signed the message matches the domain in the From header.
• DMARC passes if at least one of the two is aligned. So DKIM alignment alone is sufficient even when SPF belongs to the provider.
• Alignment mode is controlled by the aspf and adkim tags. The value r is relaxed and is the default; s demands an exact match of the full domain.

The practical translation: if you send through a third party, ask them to sign with DKIM using your domain. That single change produces alignment without touching SPF at all.

The order to work in

1. Inventory everything that sends as you: the website server, the invoicing system, the marketing platform, the CRM, the automation tool. A record that misses one source will break that source.
2. Publish a single SPF record covering all of them, ending in ~all at this stage.
3. Turn on DKIM at every provider and publish the selector record each one gives you.
4. Publish DMARC at p=none with rua, then wait. none blocks nothing; it only makes the reports flow.
5. Read the reports for one to two weeks and identify sources sending as you that you did not know about.
6. Fix what the reports exposed, and only then move to p=quarantine.
7. Move to p=reject at the end of the process, not the beginning. reject over incomplete infrastructure blocks your own invoices.

Which thresholds are you being measured against?

The large mailbox providers have published explicit requirements for high-volume senders. They apply to anyone sending more than 5,000 messages a day to that provider.

Two points worth noting: Google also requires a valid PTR record for the sending IP address and a TLS connection, plus List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click headers on marketing messages with unsubscribe requests honoured within two days. Microsoft states that a domain which has ever crossed the threshold stays subject to the requirements even if its daily volume later drops.

How do you confirm each step actually worked?

• Send a test message to a Gmail address and read Authentication-Results again. It is the only check that reflects reality.
• Confirm there is exactly one TXT record starting with v=spf1. Two SPF records break evaluation.
• Count the include mechanisms in the chain. Exceeding ten DNS lookups returns permerror, which is equivalent to a failure.
• Send one message from each system separately - website, invoicing, marketing. They are usually signed differently from each other.
• Verify that rua reports are actually arriving in the mailbox you nominated. An unmonitored mailbox is the same as no reports.
• After moving to quarantine, watch your critical operational messages for a week before tightening further.

What still lands in spam when authentication is perfect

Authentication is necessary and not sufficient. It proves you are who you claim to be, not that the message was wanted. Once everything passes, what remains is behaviour:

• Addresses that do not exist. A high bounce rate damages sender reputation faster than anything else on this list.
• Sending at volume from a new domain with no ramp-up.
• Mixing marketing campaigns with operational mail on the same domain. Separating them onto subdomains keeps invoices delivering when a campaign goes badly.
• No obvious way to unsubscribe, which turns quiet opt-outs into spam complaints.

Related: an invoice email that never arrived checklist, email automation for a small business, what DNS is.

Sources

• Gmail - Email sender guidelines
• Microsoft Support - Fix NDR error 550 5.7.515 in Outlook.com
• RFC 7489 - DMARC