If your legitimate email is being filtered, the cause is usually not the content. It is that receiving mail servers cannot verify you are allowed to send as your domain. Three DNS records fix that.
Why this exists
The email protocol lets anyone claim to be sending from any address. Nothing in the protocol itself prevents it. SPF, DKIM and DMARC are the layer added afterwards to let a receiving server check the claim. Domains that publish none of them are treated with suspicion, and increasingly are rejected outright by the large providers.
SPF — who is allowed to send
A TXT record listing the servers permitted to send mail for your domain. A receiving server compares the connecting server against the list.
Two things to know:
- You may only have one SPF record. Two records is a configuration error and typically causes both to be ignored. When you add a new sending service, extend the existing record; do not add a second one.
- There is a limit of ten DNS lookups. Every included service counts. Exceed it and the whole check fails, taking your legitimate mail with it. Organisations that have accumulated a marketing platform, a helpdesk, a CRM and an invoicing tool hit this limit surprisingly often.
Ending the record with a soft-fail marker is the cautious setting; a hard fail is stricter and only appropriate once you are certain the list is complete.
DKIM — proof the message was not altered
Your sending server signs each message with a private key. The matching public key is published as a TXT record on a selector subdomain. The receiver verifies the signature.
DKIM survives forwarding where SPF does not, which makes it the more robust of the two. Every service that sends on your behalf should have its own selector and its own key. If you have added a new email platform recently and not published its DKIM record, that alone can explain a sudden deliverability drop.
DMARC — what to do when the checks fail
A TXT record at _dmarc on your domain. It tells receiving servers what to do with mail that fails SPF and DKIM, and where to send reports.
Start with the monitoring-only policy and a reporting address. Read the reports for a few weeks. They will show you every service sending as your domain, including ones you had forgotten. Only when the legitimate senders all pass should you tighten to quarantine, and later to reject.
Do not start at reject. Publishing a strict policy before the reports are clean will block your own invoices, newsletters and application notifications, and you will not necessarily find out quickly.
The order to do this in
- Inventory every system that sends mail as your domain. Marketing, billing, the website contact form, the ticketing system, any device that emails scans or alerts.
- Publish one correct SPF record covering all of them.
- Enable DKIM on each platform and publish each key.
- Publish DMARC in monitoring mode.
- Read the reports, fix what fails, then tighten.
Also check the basics
Authentication is necessary but not sufficient. Sending reputation, a domain with no history, and mail sent from a residential connection all affect delivery. If everything above is correct and mail still filters, tell us the domain and a sample of the full message headers from a filtered message — the headers state exactly which check failed.
