SPF, DKIM and DMARC explained

If your transactional email is landing in spam, or being rejected outright, the cause is almost always email authentication. SPF, DKIM and DMARC are the three DNS records that prove your mail is really from you. Get them right and mailbox providers trust your domain; get them wrong and even a perfectly written password-reset email can disappear.

Here is what each one does and how they fit together.

SPF: which servers may send for your domain

SPF (Sender Policy Framework) is a DNS record that lists the mail servers allowed to send email using your domain in the envelope. When a receiving server gets a message, it checks the sending server's IP against your SPF record. If the server is listed, SPF passes.

SPF is published as a TXT record, for example:

v=spf1 include:_spf.your-provider.com -all

The -all at the end means "reject anything not listed". SPF alone has a well-known weakness: it validates the hidden envelope sender, not the visible From address, and it breaks when a message is forwarded. That is why it is never used on its own.

DKIM: a signature that proves nothing was tampered with

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message, generated with a private key that only your sending provider holds. The matching public key lives in your DNS. The receiver verifies the signature against that public key.

DKIM proves two things: the message really came from your domain, and its content and key headers were not changed in transit. Because the signature travels with the message, DKIM survives forwarding where SPF does not. Your provider generates the key pair; you publish the public half as a DNS record.

DMARC: what to do when authentication fails

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties the other two together and tells receivers what to do with mail that fails. It also fixes SPF and DKIM's blind spot by requiring alignment: the domain that passes SPF or DKIM must match the visible From domain.

A DMARC record is a TXT record on _dmarc.your-domain.com:

v=DMARC1; p=none; rua=mailto:dmarc@your-domain.com

The policy p can be none (monitor only), quarantine (send failures to spam), or reject (bounce them). The rua address receives daily aggregate reports so you can see who is sending as your domain before you tighten the policy.

How they work together

A well-authenticated message passes like this:

• SPF confirms the sending server is allowed to send for the envelope domain.
• DKIM confirms the message is signed by your domain and untampered.
• DMARC confirms that a passing SPF or DKIM result *aligns* with the From address, and enforces your chosen policy if not.

You want at least one of SPF or DKIM to pass and align. DKIM alignment is the more robust of the two, because it survives forwarding.

Rolling it out safely

Publish SPF and DKIM first and confirm real mail is passing both. Then add DMARC at p=none and watch the aggregate reports for a couple of weeks. Once you can see that all your legitimate sources pass and align, move the policy to quarantine, then reject. Jumping straight to reject before you have visibility is the fastest way to lose real email.

Let your provider handle it

Assembling and maintaining these records by hand is fiddly, and a stray character breaks delivery silently. With Mailhuset you verify your domain once: DKIM is generated for you, SPF and the return path are set with a handful of DNS records, and DMARC is monitored, so your transactional email authenticates and arrives.