SPF, DKIM and DMARC: how to authenticate your sending domain

SPF: who can send for your domain

SPF is a TXT record that lists the servers allowed to send email for your domain. A receiving server compares the sending server with that list.

A domain can only have one SPF record, so when you add a new sending service, merge it into the existing record instead of adding a second one. SPF also allows at most 10 DNS lookups, and going over that makes it fail.

DKIM: proof the message was not changed

DKIM adds a cryptographic signature to every email. The public key lives in a DNS record, so the receiving server can check that the signature is valid and that the message was not altered on the way.

DMARC: what to do when checks fail

DMARC ties the other two to the address your readers see in the From line, and tells receiving servers what to do when a message fails. It can also send you reports about who is sending as your domain.

Start with a policy of p=none, which only monitors. Once your reports show that your real email passes, move to p=quarantine and then p=reject.

What a basic setup looks like

The exact values come from your sending service, but the records follow this shape:

• SPF: a TXT record starting with v=spf1, naming your sending service
• DKIM: a TXT record under a selector name, holding the public key
• DMARC: a TXT record at _dmarc, starting with v=DMARC1; p=none

How the three work together

Picture a single email arriving at Gmail. The receiving server looks up SPF to see whether the sending server is allowed to send for that domain, then verifies the DKIM signature against the public key in DNS.

DMARC adds the final check, called alignment. At least one of those two results has to match the domain in the From address that your reader sees. An email can pass SPF for a sending service and still fail DMARC if that service used its own domain, which is why a proper setup signs with yours.

Use a subdomain for sending

Many teams send from a subdomain such as mail.example.com instead of the root domain. It keeps the sending records apart from the ones used by your regular inbox, and it gives bulk email its own reputation to manage.

It does not hide your reputation completely, because providers also look at the parent domain. Treat it as tidy organization and not as a way to escape bad sending habits.

How to check that it works

After adding the records, send an email to a Gmail address, open it and choose Show original. Gmail lists the result for SPF, DKIM and DMARC, and each should say PASS.

You can also look up a record from your terminal with dig TXT example.com, or dig TXT _dmarc.example.com for DMARC. DNS changes usually appear within minutes, though they can take longer depending on the record TTL.

Common mistakes

Most failures come from a short list of small errors, so check these first.

• Two SPF records on the same domain, which makes SPF fail
• A registrar that adds your domain to the record name, turning it into mail.example.com.example.com
• Too many services in SPF, which goes over the limit of 10 lookups
• Moving to p=reject before every sending service passes, which blocks your own email
• Forgetting a service that sends on your behalf, such as your helpdesk or billing tool

Why this is no longer optional

Since 2024, Gmail and Yahoo require every sender to have SPF or DKIM. Bulk senders, the ones sending more than 5,000 messages a day to Gmail, need SPF, DKIM and DMARC, plus one-click unsubscribe on marketing email.

Setting it up in Reloops

Add your domain in Settings and Reloops shows the DNS records to add at your registrar. Once they verify, your emails go out from your domain with SPF and DKIM.