Your customer calls asking why they never got last month's invoice. You check Odoo — the email shows as sent. It landed in their spam folder, or worse, it never arrived at all. If you're running Odoo, a CRM, or any transactional mail from your own domain and you haven't touched SPF, DKIM or DMARC in the last year, this is happening to you right now, and you probably don't know it yet.

Why this matters now

For years, SPF and DKIM were "nice to have." Gmail and Yahoo mostly just flagged suspicious mail as spam and moved on. That's over. Enforcement has shifted from passive filtering to active rejection — non-compliant messages are now refused at the SMTP level before they ever reach an inbox, spam folder or otherwise. Your mail server gets a bounce, and the invoice simply never gets delivered.

Gmail's own sender guidelines are explicit: senders must format messages according to RFC 5322 and keep spam complaint rates reported in Google Postmaster Tools below 0.30%. Yahoo has followed the same direction, requiring valid SPF, DKIM, PTR records and TLS from every sender, with bulk senders held to DMARC alignment, the same 0.30% spam-rate ceiling, and one-click unsubscribe. If your Odoo instance sends quotations, invoices, payment reminders or statements directly to Gmail or Yahoo addresses — and almost every business does — these rules apply to you whether you send ten emails a day or ten thousand.

The three building blocks — what each one actually checks

SPF (Sender Policy Framework) is a DNS TXT record that lists which mail servers are allowed to send email claiming to be from your domain. When a receiving server gets a message, it checks whether the sending IP is on that approved list. No match, no pass.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to each outgoing message, generated from a private key on your mail server and verified against a public key published in your DNS. Yahoo's Sender Hub requires a minimum 1024-bit key length for this signature, and it exists specifically so the receiving server can confirm the message content wasn't altered in transit.

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the two together. It tells receiving servers what to do if a message fails SPF or DKIM, and — critically — it checks alignment: does the domain in the visible "From:" header actually match the domain that passed SPF or DKIM? Google is blunt about this: for direct email, the domain in the sender's From: header must be aligned with either the SPF domain or the DKIM domain, or Gmail's quarantine enforcement policy kicks in.

Bulk sender or normal sender — which rules bind you?

Google draws a line between "normal" senders and "bulk senders" (roughly, anyone sending a large volume of mail to personal Gmail accounts, which in practice includes most Odoo instances pushing invoices to customer inboxes at scale). Bulk senders are required to set up SPF, DKIM, and DMARC — not optional, not recommended. Google's own guidance states it directly: bulk senders are required to set up SPF, DKIM, and DMARC. If your Odoo, CRM or marketing tool sends promotional campaigns as well as invoices from the same domain, assume you're a bulk sender and configure accordingly. It costs you nothing to over-comply here, and it saves you the bounce.

Step-by-step: publishing SPF and DKIM correctly

Start with SPF. In your DNS zone, add a single TXT record at the root of your sending domain. If you send through Google Workspace, it typically looks like:

v=spf1 include:_spf.google.com ~all

If Odoo sends through its own SMTP relay, a third-party relay (SendGrid, Mailgun, etc.), or your own mail server, include all of those sources in one record — this is where most admins go wrong (more on that below). Once published, DNS propagation can take up to 48 hours, so don't panic if a test fails an hour after you save the record — wait it out before troubleshooting further.

Next, DKIM. Generate a key pair on your mail server or through your provider's admin console (Google Workspace Admin > Apps > Gmail > Authenticate email), then publish the public key as a TXT record at a selector subdomain, something like google._domainkey.yourdomain.com. If Odoo relays through a separate SMTP service, that service needs its own DKIM selector published too — Odoo itself doesn't sign messages; whatever sends on its behalf does. Turn DKIM signing on at the source, not just in DNS.

Setting up DMARC without breaking your mail flow

Publish a DMARC TXT record at _dmarc.yourdomain.com. Start conservative:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; fo=1

The p=none policy tells receivers to take no punitive action yet — it just asks them to send you aggregate reports so you can see what's passing and what isn't. Run this for at least two to three weeks. Watch the reports. Once you see SPF and DKIM consistently passing and aligned with your From: domain, move the policy to p=quarantine (suspect mail goes to spam) and eventually p=reject (suspect mail gets refused outright). Jumping straight to reject without watching reports first is the single fastest way to lose legitimate invoice traffic — don't do it.

Alignment mode matters here too. By default, DMARC checks alignment at the organizational domain level, and Google's FAQ confirms that for direct mail to personal Gmail accounts, the organizational domain in the From: header must align with either the SPF organizational domain or the DKIM organizational domain. If Odoo sends as invoices@yourcompany.com but the underlying SMTP relay authenticates as a completely unrelated domain, alignment fails even if SPF and DKIM individually pass. This is exactly the gap that trips up hosted Odoo setups using a generic mail relay without domain-specific configuration.

One-click unsubscribe and why your invoices are exempt

Google's sender guidelines require one-click unsubscribe for bulk senders — but only for marketing and promotional messages. Transactional messages are explicitly excluded from that requirement. Google gives password resets, reservation confirmations and form submission confirmations as examples of transactional mail, and invoices, payment receipts and statements sit squarely in that same category. That said, don't get lazy: if you're sending marketing newsletters from the same Odoo instance or the same sending domain as your invoices, that unsubscribe requirement absolutely applies to those messages, and mixing marketing and transactional traffic under one domain reputation is asking for trouble anyway. Consider a subdomain split — mail.yourcompany.com for marketing, yourcompany.com or a dedicated transactional subdomain for invoices — so a spike in newsletter complaints doesn't tank your invoice deliverability.

Monitoring: don't configure and forget

Set up Google Postmaster Tools for your sending domain — it's free and it's where Google actually reports your spam rate, the number that decides whether you stay under that 0.30% threshold or get throttled. Check it weekly, not once a year. Alongside it, actually read your DMARC aggregate reports (the rua address you configured above). They'll tell you which sending sources are failing alignment before Gmail or Yahoo start rejecting mail outright. Several free DMARC report parsers exist that turn the raw XML into a readable table — use one, because reading raw aggregate XML by hand gets old fast.

Common misconfigurations that keep tripping up admins

A few mistakes show up constantly in the field:

• Multiple SPF records for one domain. DNS only allows one SPF TXT record per domain — if you have two, both fail. Merge every sending source into a single record with multiple include: statements.
• Missing DKIM on sub-services. Odoo, your marketing tool, and your transactional relay might all send as the same domain, but each needs its own DKIM selector configured and signing correctly. One configured service doesn't cover the others.
• No alignment between From: header and authenticated domain. SPF and DKIM can both pass technically while DMARC still fails, because the visible sender domain doesn't match either authenticated domain. This is the quiet killer — test it specifically.
• Forgetting DNS propagation delay. Changes can take up to 48 hours to take effect. Test, wait, then test again before assuming a fix didn't work.
• Jumping to p=reject too early. Always pass through none and quarantine first, with reporting on, before enforcing rejection.

Here's your next move: pull up your domain's DNS zone today, check whether you have exactly one SPF record, confirm DKIM is actually signing outbound Odoo mail (check message headers, not just DNS), and if you don't have a DMARC record at all yet, publish one at p=none this week. That single step gives you visibility into a problem you can't currently see — and right now, that invoice sitting in your customer's spam folder is costing you money you haven't noticed yet.

References

• Email sender guidelines - Gmail Help
• Email sender guidelines FAQ - Gmail Help
• Email sender guidelines FAQ - Google Workspace Admin Help
• Set up SPF - Google Workspace Help
• Yahoo Sender Hub - Best Practices
• Gmail & Yahoo Sender Requirements 2026: The Complete Guide for Ecommerce Brands
• DMARC Google Workspace, Yahoo, & Microsoft Requirements | Mimecast

Image: hisperati — BY (via Openverse)