SPF, DKIM and DMARC for email at your own domain

You send mail from an address at your own domain, and some of it never arrives. The worst offender is often the contact form on your website: a customer fills it in, the message is sent, and it lands in a spam folder or is rejected without a trace. The usual cause is not the wording of the message. It is that nothing in your domain's public records says the sender is allowed to use your name.

Three records fix that: SPF, DKIM and DMARC. This note explains each in plain terms and gives an order of work that is hard to get badly wrong. You will edit DNS, so keep a copy of every record before you change it.

What each record does

SPF (Sender Policy Framework, RFC 7208) is a list, published in DNS as a TXT record, of the servers allowed to send mail for your domain. A receiving server checks the sending server against that list. Two rules matter. A domain may publish only one SPF record, and if it has more than one, the check returns a permanent error. And evaluating a record may trigger at most 10 DNS lookups, so a record stuffed with include: entries from many services can break.

DKIM (DomainKeys Identified Mail, RFC 6376) is a signature. The sending system signs each message, and the matching public key is published in your DNS at selector._domainkey.yourdomain. The receiver fetches the key and checks the signature. A valid signature tells the receiver that the domain named in the signature took responsibility for the message.

DMARC (RFC 9989, which replaced the older RFC 7489) sits on top. You publish a policy in a TXT record at _dmarc.yourdomain. A message passes if SPF or DKIM passes and the domain it authenticated lines up (the standard's word is "alignment") with the domain in the visible From address. The policy states how you would like receivers to handle failing mail: none, quarantine or reject. You can also ask for daily summary reports with an rua address.

Alignment is where contact forms usually go wrong. A form plugin may send through a hosting server. SPF can pass for the hosting company's domain, but that domain is not yours, so the message does not align with the From address on your own domain.

Why this affects delivery

Google's sender guidelines say every sender to Gmail must set up SPF or DKIM, among other requirements. Senders of more than 5,000 messages a day to Gmail must have SPF, DKIM and DMARC, and the From domain must align with the SPF or DKIM domain. These rules have applied since February 1, 2024. A small business is not a bulk sender, but a receiver has no way to tell unauthenticated mail from forged mail. Authentication does not guarantee the inbox. The original DMARC specification (RFC 7489) says so itself: authenticated mail gets no elevated delivery privilege. Authentication removes a reason to distrust you; it does not earn trust on its own.

A safe order of work

1. List every system that sends as your domain. Your mailbox provider, the website form, an invoicing tool, a newsletter tool. Mail you forgot about is what breaks later.
2. Set up one SPF record. Edit the existing record rather than adding a second. For a domain that sends only through Google Workspace, Google's documented record is v=spf1 include:_spf.google.com ~all. For Microsoft 365 only, it is v=spf1 include:spf.protection.outlook.com -all. The endings differ because the providers recommend different things: ~all is a soft fail and -all a hard fail. Follow your provider's page, and add other services only as their documentation instructs.
3. Turn on DKIM for each sender. In Google Workspace you generate a key in the Admin console, publish it as a TXT record at google._domainkey, then start authentication. Google recommends a 2048-bit key where your DNS host supports it. Changes can take up to 48 hours.
4. Fix the contact form. Send it through your mail provider's authenticated sending, or through a sending service set up with DKIM for your domain. Put the visitor's address in the Reply-To header instead of From, so the From stays an address you control.
5. Test with a real message. Send to an outside mailbox, not to yourself, because self-sent tests do not verify DKIM. Open the message's original headers and read the Authentication-Results line. You want to see SPF and DKIM passing.
6. Publish DMARC at p=none. Google says to turn on SPF or DKIM first and wait at least 48 hours before enabling DMARC. A starting record, for the fictional domain example.com, looks like this:

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

p=none asks receivers to take no action on failures, so it is a monitoring step. Send reports to a dedicated mailbox, not a personal one. Google notes that reports can arrive in high volume.

1. Read the reports for a few weeks. Look for senders you forgot, and fix their SPF or DKIM.
2. Tighten only if you have a reason. Microsoft's guidance is gradual: none, then quarantine, then reject, checking results at each step. If any legitimate sender still fails, stay where you are. A strict policy that blocks your own invoices is worse than none.

Two cautions

Forwarding can break SPF, because the forwarding server is not on the original sender's list. DKIM usually survives forwarding if the message body is not changed. This is one reason to set up both.

Unused domains that you own can be locked down too. Microsoft documents v=spf1 -all and a DMARC p=reject record for domains that should never send mail. That is a separate task from the one above, so do it after your main domain is working.

Checking later

Once a quarter, send a test message and read the headers again. Review your record whenever you add a service that sends email for you, since a new tool is the most common reason a working setup stops passing.

Prepared with AI assistance. Examples are fictional unless stated.