SPF, DKIM and DMARC: the three records every sending domain needs

SPF, DKIM and DMARC are the three DNS records that let a receiving mail server check that a message claiming to come from your domain actually did. They solve different halves of the same problem, and they are meant to be used together — which is why the trio is quoted as a unit and why partial setups are so common and so ineffective.

They are also no longer optional. Major mailbox providers have progressively tightened requirements for anyone sending at volume, and a domain without all three should expect mail to be filtered, quarantined or refused. The work is a set of DNS entries and an afternoon.

What each one does

• SPF (Sender Policy Framework): a DNS record listing which servers are allowed to send mail for your domain. The receiver checks whether the sending server is on that list.
• DKIM (DomainKeys Identified Mail): a cryptographic signature added to each message, verified against a public key in your DNS. It proves the message was not altered and really came from an authorised sender.
• DMARC (Domain-based Message Authentication, Reporting and Conformance): a policy record saying what to do when SPF or DKIM fails — do nothing, quarantine, or reject — and where to send reports.
• Alignment: DMARC requires that the domain in the visible From address matches the domain that passed SPF or DKIM. This is the part most partial setups get wrong.
• The DMARC reports themselves, which tell you who is sending as your domain — including services you forgot about and anyone spoofing you.
• Optionally BIMI, which can display your logo in supporting clients, but only once DMARC is enforcing.

Start DMARC at p=none and read the reports before enforcing. Going straight to p=reject reliably breaks something you forgot about — the invoicing system, the CRM, the newsletter tool, a supplier who sends on your behalf. A few weeks at none shows you every sender using your domain; then tighten to quarantine, then to reject.

Setting them up

1. List every system that sends mail as your domain: your mail provider, the app that sends invoices, the CRM, the marketing tool, the helpdesk, the website contact form.
2. Publish one SPF record for the domain, including each of those senders. One record only — multiple SPF records are invalid and cause silent failures.
3. Keep SPF within the ten-lookup limit. Exceeding it makes the record fail, and it is easy to exceed with several third-party includes.
4. Enable DKIM signing in each sending system and publish the public keys they give you, each on its own selector.
5. Publish a DMARC record at p=none with an address to receive aggregate reports.
6. Read the reports for a few weeks. They arrive as XML; a free parser makes them readable.
7. Fix anything failing alignment, then move to p=quarantine, then to p=reject once the reports are clean.
8. Re-check whenever you add a sending service — a new tool is the usual reason a working setup starts failing.

Why partial setups fail

The common pattern is SPF published years ago, DKIM enabled on the main mail provider only, and no DMARC at all. Mail from the mail provider passes; mail from the invoicing app or the marketing tool fails silently, and nobody notices until a customer says an invoice never arrived. Because DMARC is what surfaces this, a domain without it has no visibility into its own sending — you cannot fix a failure you cannot see, which is the strongest argument for publishing DMARC even at p=none on day one.

Ettex Mail hosts mail on your own domain, so these records apply to a domain you control and the reputation you build is yours rather than a shared provider's. Per-address signatures keep branding consistent across mailboxes, reusable replies and scheduled send handle the repetitive messages, and sixteen transactional layouts cover automated mail. The list of which systems send as your domain — the inventory that SPF depends on — is worth keeping as a table in Ettex Records, and the DNS change itself is made at whoever hosts your domain, alongside the records that point Ettex Sites at it.

Said plainly: Ettex does not manage your DNS and does not publish these records for you. There is no DMARC report parser, no authentication checker, no alerting when a record breaks, and no automated setup wizard. You add the records at your DNS host and verify them with free external tools. What Ettex gives you is mail on your own domain, which is what makes the records worth publishing at all.

Common mistakes

• Two SPF records on the same domain, which invalidates both.
• SPF exceeding the ten-lookup limit, causing failures that look random.
• DKIM enabled on the primary provider only, leaving every other sender unsigned.
• DMARC published at p=reject immediately, breaking legitimate mail nobody remembered.
• Aggregate reports sent to an address nobody reads, so the whole reporting benefit is lost.
• Alignment ignored — SPF passing for a provider's domain rather than yours, which DMARC still fails.
• A new sending tool added without updating SPF, which is the usual cause of a sudden delivery problem.
• Records copied from a blog post without substituting your own domains and selectors.

SPF, DKIM and DMARC are an afternoon of DNS work that decides whether your mail arrives. Inventory your senders, publish one SPF record, sign with DKIM everywhere, and start DMARC at none until the reports are clean.