SPF, DKIM and DMARC explained: stop spoofing and reach the inbox

• SPF lists the servers allowed to send mail for your domain.
• DKIM signs every message; the public key for checking it is published in DNS.
• DMARC tells receivers what to do when SPF and DKIM fail and sends you reports. It only passes when the domain in the visible From address matches.
• Start with p=none, read the reports, then move to quarantine and reject once every legitimate sender passes.

Since February 2024 Gmail and Yahoo require SPF or DKIM from every sender. Bulk senders (Google counts more than 5,000 messages a day to Gmail addresses) need SPF, DKIM and a DMARC record (p=none is enough), a From domain aligned with SPF or DKIM, one-click unsubscribe for marketing mail and a spam complaint rate below 0.3%.

Even if you send little mail, missing records make your domain easy to spoof in phishing, and receivers trust mail from such domains less.

SPF is a single TXT record on your domain that starts with v=spf1, lists the allowed senders and ends with a rule for everyone else. include: pulls in a provider's list, ip4:/ip6: add your own servers and mx allows the domain's MX hosts.

• Publish exactly one SPF record. Two v=spf1 records make SPF fail (permerror); merge them into one.
• SPF may use at most 10 DNS lookups (every include, a, mx, exists and redirect counts, nested ones too). Above that SPF fails; remove includes you no longer use.
• -all (fail) asks receivers to reject unlisted senders, ~all (softfail) to treat them as suspicious. With DMARC in place, ~all is common and safe.
• SPF checks the envelope sender (Return-Path), not the From address people see, and it breaks when mail is forwarded. That is why you need DKIM too.

The sending server signs the headers and body with a private key; the receiver fetches the public key from selector._domainkey.example.com and verifies the signature. The selector is a name chosen by your provider (google, selector1, s1, k1…), so every service you send through gets its own key.

Turn DKIM on in every service you send with (mailbox provider, newsletter tool, CRM, online shop) and publish the record it gives you, usually a TXT or CNAME. Use 2048-bit keys where offered. DKIM survives forwarding, which makes it the more reliable half for DMARC.

DMARC lives at _dmarc.example.com. A message passes DMARC when SPF or DKIM passes and the domain it passed for matches (aligns with) the domain in the From address. A provider that signs with its own domain does not help until you set up DKIM for yours.

rua=mailto: asks receivers to send daily aggregate reports (XML) listing which servers sent mail as your domain and whether they passed. These reports are how you find forgotten senders before you tighten the policy.

• List everything that sends mail as your domain: mailboxes, website forms, newsletter, invoicing, support desk.
• Publish one SPF record that covers them all and enable DKIM in each of them.
• Add v=DMARC1; p=none; rua=mailto:… and read the reports for two to four weeks.
• Fix every legitimate sender that fails, then switch to p=quarantine (gradually with pct= if you like) and later to p=reject.
• Domains that never send mail should publish v=spf1 -all and v=DMARC1; p=reject so nobody can spoof them.

• MTA-STS and TLS-RPT make other servers deliver to you only over verified TLS and report problems.
• BIMI shows your logo next to your messages in supporting inboxes; it requires DMARC at quarantine or reject.

The E-mail security check reads MX, SPF (with its DNS lookup count), DKIM for common selectors or your own, DMARC, MTA-STS, TLS-RPT and BIMI, and points out the problems it finds. Run it again after every DNS change; depending on the TTL, new records can take from a few minutes to an hour to appear.