You can write a good email and send it to someone who asked for it, and it can still land in spam. Receiving mail servers decide whether to trust a message before any person sees it, and a large part of that decision rests on three records in your domain's DNS. If they are missing or wrong, delivery suffers, and so does everything built on email: invoices, password resets, lead replies and newsletters.
The problem these records solve
Email was designed without a way to verify the sender. Anyone can send a message that claims to come from your domain. SPF, DKIM and DMARC let the owner of a domain state which servers may send for it and what should happen to messages that fail the check. Receivers use this to separate your real mail from forgeries.
SPF: which servers may send
SPF is a DNS record listing the servers and services allowed to send email for your domain. When a message arrives, the receiving server looks up the record and checks whether the sending server is on the list.
Two practical points. A domain must have only one SPF record, so every sending service has to be included in the same one. And the record may trigger at most ten DNS lookups, a limit that companies with many email tools reach sooner than expected.
DKIM: a signature on each message
With DKIM, the sending server signs each message with a private key. The matching public key is published in DNS. The receiver uses it to confirm that the message really was sent by a holder of the key and was not altered on the way.
The published key alone does nothing. Signing has to be switched on in the sending system as well. A mail server can run for months with a DKIM record in DNS and no signature on any outgoing message, and nothing reports the problem. Check a real message, not only the DNS.
DMARC: the policy and the reports
DMARC builds on the other two. It tells receivers what to do when a message fails both checks, and it requires that the domain validated by SPF or DKIM matches the domain in the visible From address. That matching is called alignment, and it is what stops someone from passing the checks with their own domain while showing yours.
DMARC also asks receivers to send you reports listing who sent mail using your domain and whether it passed. These reports are the only way to see the whole picture.
Set them up in this order
- List every system that sends email as your domain: the mail server, the CRM, the newsletter tool, the invoicing system, the website.
- Publish one SPF record that covers them all.
- Enable DKIM signing in each system and publish its key.
- Publish DMARC with the policy set to none, which only requests reports.
- Read the reports for a few weeks and fix any legitimate sender that fails.
- Move the policy to quarantine, and later to reject.
Going straight to a strict policy is the classic mistake. It blocks your own forgotten senders, typically the invoicing tool or a contact form, on the first day.
How to check your setup
Send a message to a mailbox at a large provider and open the original message headers. Look for the authentication results line. It should show spf=pass, dkim=pass and dmarc=pass. Repeat this for each system that sends mail, since one can pass while another fails.
What they do not do
Passing all three does not guarantee the inbox. Receivers also consider the reputation of the sending address, how recipients react to your mail and what the message contains. Authentication is the entry requirement. Sending wanted mail to people who asked for it is still what keeps you out of spam.
Summary
SPF lists who may send, DKIM signs each message, and DMARC sets the policy and gives you reports. Introduce them in order and tighten the policy only after the reports are clean. We set this up as part of our AI marketing automation service, because follow-up that lands in spam is wasted. If you are unsure whether your domain is configured correctly, ask us to check.