SPF, DKIM, and DMARC Explained: The Email Authentication Basics

Email was designed to be open, which is why it is so widely used. That openness also makes spoofing possible. Without authentication, someone can try to send a message that appears to come from your domain.

SPF, DKIM, and DMARC are the three core controls that help receiving mail servers decide whether a message is legitimate. To see where these results appear in a real message, see our guide on how to read email headers.

SPF: who is allowed to send?

SPF stands for Sender Policy Framework, defined in RFC 7208. It is a DNS TXT record that lists which mail servers are allowed to send email for your domain.

For example, if you use a marketing platform and a transactional email service, your SPF record should include the systems that send mail on your behalf.

Common SPF problems include:

• No SPF record at all
• More than one SPF record
• Missing sending services
• Too many DNS lookups
• A policy that is too broad

You can start with the SPF checker to see whether your domain publishes a recognizable SPF record.

DKIM: was the message changed?

DKIM stands for DomainKeys Identified Mail, specified in RFC 6376. It adds a cryptographic signature to outbound messages. The public key is published in DNS, and the receiving server uses it to verify that the message was not modified after sending.

DKIM is usually configured per sending service. That is why you often see selectors such as default, google, mail, or a vendor-specific value.

Use the DKIM checker when you need to confirm whether a selector has a public key in DNS.

DMARC: what should receivers do?

DMARC, defined in RFC 7489, builds on SPF and DKIM. It tells receiving servers what to do when authentication fails. The policy can be:

• p=none: monitor only
• p=quarantine: treat suspicious mail as spam
• p=reject: reject unauthenticated mail

DMARC can also send aggregate reports so domain owners can see who is sending mail for their domain.

Use the DMARC checker to inspect the published policy.

Why MX records still matter

MX records do not authenticate outbound mail. They tell the internet where inbound mail for your domain should be delivered.

If your MX records are missing or wrong, people may not be able to send email to your domain. Use the MX lookup to check the receiving side of your domain.

A simple setup order

For most small sites, the practical order is:

1. Confirm MX records for inbound mail.
2. Publish SPF for the services that send mail.
3. Enable DKIM in each email provider.
4. Add DMARC with p=none and reports.
5. Review legitimate senders.
6. Move toward quarantine or reject when confident.

Do not jump straight to a strict DMARC policy if you are not sure all legitimate senders pass authentication. You may block your own mail.

How this relates to deliverability

Authentication does not guarantee inbox placement, but missing authentication can hurt trust. A domain with broken SPF, missing DKIM, and no DMARC policy looks less reliable to receiving systems.

Good authentication gives your legitimate mail a better foundation and makes domain spoofing harder.

Final thought

SPF, DKIM, and DMARC are not optional details for serious email. They are the basic safety rails for modern domain identity. Start by checking what your domain publishes today, then improve one record at a time.