SPF, DKIM and DMARC: the three records that decide if your mail lands

SPF, DKIM and DMARC together make up one of the few areas of infrastructure where twenty minutes of correct configuration produces a large, immediate and measurable result. It is also wrong on a remarkable share of domains, including plenty belonging to companies that should know better.

Three records, in the order they were invented and in the order you should think about them.

SPF: which servers may send

An SPF record is a DNS TXT entry listing the servers permitted to send mail for your domain. A receiving server checks the connecting address against that list.

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

Three things people get wrong:

• More than one SPF record. A domain may have exactly one. Two records is a permanent error and the check fails, not passes. Merge them.
• The ten lookup limit. Each include costs a DNS lookup, and nested includes count too. Exceed ten and the record fails. Audit it if you use several senders.
• Ending with +all. That authorises the entire internet. Use ~all for soft fail while testing and -all once you are confident.

SPF has a structural weakness: it breaks on forwarding, because the forwarding server is not on your list. That is why DKIM exists.

DKIM: a signature that survives the journey

DKIM adds a cryptographic signature to each outgoing message, covering the headers and body. The public key is published in DNS at a selector you choose, and the receiver verifies the signature against it.

Because the signature travels with the message, it survives forwarding. Your sending platform generates the key pair and gives you the record to publish.

The most common failure is subtle: the DNS record is published and signing is never actually switched on in the sending platform’s admin console. Publishing the key is half the job. Verify with a test message and read the Authentication-Results header rather than assuming.

DMARC: the policy that ties it together

DMARC does two things. It tells receivers what to do when SPF and DKIM fail, and it requests reports so you can see what is being sent in your name.

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

The important concept is alignment. DMARC passes only if SPF or DKIM passes and the domain that passed matches the domain in the visible From address. This is why a message can pass SPF and still fail DMARC: the relay authorised its own domain, not yours.

The rest of deliverability

Authentication gets you considered. It does not get you delivered. The other factors:

• Reverse DNS. If you send directly from your own server, the PTR record for the sending address must resolve to a hostname that resolves back to it. Most receivers check.
• IP and domain reputation. Built over time from complaint rates, bounce rates and spam trap hits. A new domain sending at volume on day one looks exactly like a spammer.
• Warm up. Increase volume gradually over days from a new address or domain.
• List hygiene. Remove hard bounces immediately. Continuing to send to dead addresses is the single fastest route to a blocklist.
• One click unsubscribe. Required by the major mailbox providers for bulk senders, and a header rather than just a link in the body.
• Separate streams. Send transactional mail and marketing mail from different subdomains, so a marketing complaint rate cannot bury password resets.

Sending from your own infrastructure

If you are running your own mail server rather than using a relay, everything above still applies and one additional thing does: your provider almost certainly blocks outbound port 25 on new accounts. That policy, and how each provider handles it, is covered in outbound port 25 on cloud servers.

For most application mail, a relay is genuinely the better answer. The relay operator maintains IP reputation, handles feedback loops and manages bounces, which is a full time job you probably do not want.

A twenty minute checklist

1. Publish one SPF record covering every legitimate sender, ending in ~all.
2. Enable DKIM signing in each sending platform and publish the keys.
3. Publish a DMARC record at p=none with a reporting address.
4. Send a test message to an address you control and read the authentication headers.
5. Collect reports for a few weeks, fix what fails, then tighten the policy.

If you are setting up a domain for the first time, the Google Workspace guide covers where these records fit into a migration.