SPF DKIM DMARC explained: a simple guide for business email
SPF DKIM DMARC are three email checks that help prove a message really came from your company. Each one is a short record you add to your domain's DNS settings. Together they make it much harder for scammers to send fake mail in your name. Since February 2024, Google also asks large senders to use them.
What the three checks do
Think of them as three questions a mail server asks about every message.
SPF asks: is this server allowed to send mail for this domain? You publish a list of approved senders. SPF was defined in RFC 7208 in April 2014.
DKIM asks: was this message changed on the way, and did the domain really sign it? Your mail system adds a digital signature. The receiver checks it against a public key in your DNS. DKIM is defined in RFC 6376, from September 2011.
DMARC asks: what should I do if the first two checks fail? It also tells the receiver to send you reports. DMARC was described in RFC 7489 in March 2015.
Sources: IETF, RFC 7208 (SPF, April 2014); RFC 6376 (DKIM, September 2011); RFC 7489 (DMARC, March 2015).
How SPF works
An SPF record is a line of text in your DNS. It lists the servers and services that may send for your domain. For example, it can name your office mail provider and your newsletter tool.
The record ends with a rule for everything else. A "-all" ending means other senders fail. A "~all" ending is a softer "probably not allowed," and receivers should not reject mail on that alone. Many firms start with "~all" and move to "-all" once they are sure the list is complete.
There is one trap. SPF allows only 10 DNS lookups in a check. Each "include" counts. If you add too many tools, the check breaks. Keep the list short and remove services you no longer use. You should also publish only one SPF record per domain.
Sources: IETF, RFC 7208, on the "all" qualifiers and the limit of 10 DNS lookups.
How DKIM works
DKIM uses a pair of keys. Your mail system keeps the private key and signs each outgoing message with it. You publish the public key in DNS. The receiver uses it to check the signature.
Each key sits under a name called a selector. Selectors let you run more than one key at once. That makes it easy to swap in a new key without a gap in service. The signature also carries a "d=" value, which names the domain that signed the message.
You do not usually build this by hand. Most mail providers give you the DNS record to copy. Paste it in, then switch signing on in the provider's admin panel. Google's guidance asks for keys of at least 1024 bits and suggests 2048 bits where your provider supports it.
Sources: IETF, RFC 6376, on selectors and the d= tag; Google Workspace Admin Help, "Email sender guidelines," on key length.
How DMARC ties them together
DMARC checks that the address your reader sees in the "From" line shares a domain with the one that passed SPF or DKIM. This is called alignment. A message passes DMARC if at least one of the two checks passes and lines up.
Your DMARC record also sets a policy, written as p=. There are three choices:
- p=none: take no action, just collect reports. This is the safe place to start.
- p=quarantine: handle failing mail with suspicion, such as routing it to the spam folder.
- p=reject: ask receivers to refuse failing mail.
Add an "rua" address to get daily summary reports. They show who is sending mail with your domain, including tools you forgot about. Read them for a few weeks before you tighten the policy.
Sources: IETF, RFC 7489, on alignment, policy values and aggregate reports.
Why bulk senders need them now
In October 2023, Google said that from February 2024 it would set new rules for bulk senders. A bulk sender is a sender whose daily volume tops 5,000 messages going to Gmail addresses. Yahoo announced similar steps.
Bulk senders must set up both SPF and DKIM, and publish a DMARC record. The policy can be p=none. Marketing mail must offer easy one-click unsubscribe. The spam rate in Google Postmaster Tools must stay below 0.30%. Google suggests aiming for under 0.10%.
Smaller senders are not exempt from the basics. Google asks all senders to set up SPF or DKIM, use TLS, and keep spam rates low. Even a small company gains from the full set, because fake mail in your name hurts your reputation.
Sources: Google, "New Gmail protections for a more secure, less spammy inbox," October 2023; Google Workspace Admin Help, "Email sender guidelines."
A simple setup plan
You can finish this in an afternoon. Follow these steps in order.
- Make a list of each service that sends mail as your domain: office mail, newsletters, billing, support desk.
- Publish one SPF record that covers them all.
- Turn on DKIM signing in each service, and add its DNS record.
- Publish DMARC with p=none and an rua address.
- Send test messages and check the headers for "pass" on all three.
- After a few weeks of clean reports, move to p=quarantine, then p=reject.
Ask your IT team or mail provider if you are unsure. A wrong record can block real mail, so change one thing at a time.
Sources: the setup steps are the editors' practical suggestions, built on the RFCs and Google guidance above.
Sources
- IETF, RFC 7208, "Sender Policy Framework (SPF)," April 2014.
- IETF, RFC 6376, "DomainKeys Identified Mail (DKIM) Signatures," September 2011.
- IETF, RFC 7489, "DMARC," March 2015.
- Google Workspace Admin Help, "Email sender guidelines," support.google.com/a/answer/81126.
- Google, "New Gmail protections for a more secure, less spammy inbox," blog.google, October 2023.